Re: Money casting too liberal? - Mailing list pgsql-general

Hi Gavan,

It is more about are problems described can be solved just by datatype
at all...

Just SUM values in GL transactions table would not make sense in any
case to accountants - regardless will result be big number or 0 (what
always will/should be in normal situations)...

Maybe better would be to explain proposal better... What datatype
should ensure from your point of view...

GL transactions table can be designed on many (different) ways.. In
this moment, to me is very hard to identify how "special" datatype
could help in that case...

P.S. to me is not first time to hear from people from finance
field... "would be good if there is a special type what can handle... "
- however always ends up that the rule depends on something stored
somewhere (in another table or column) about datatype cant be aware
of...(in my opinion)

Kind Regards,

Misa



From: Gavan Schneider
Sent: 31/03/2013 12:59
To: pgsql-general@postgresql.org
Subject: Re: [GENERAL] Money casting too liberal?
On 30/3/13 at 12:58 AM, D'Arcy J.M. Cain wrote:

>On Sat, 30 Mar 2013 12:04:21 +1100 Gavan Schneider wrote:
>>No MONEY column would be complete without the ability to
>>specify whether it is normally DEBIT or CREDIT (or in my
>>preferred case
>
>That seems extreme.  What use case would there ever be for making a
>column always debit or always credit?  I have a G/L system and most
>money columns either don't know about Dr/Cr or else there is another
>column with the G/L account which implies Dr/Cr.  Where do you see a
>column that would be dedicated to one or the other?
>
If you have a credit card and a bank account you are already
familiar with the concept of Debit and Credit columns. If the
balance figures on your bank account are negative you have
become overdrawn (i.e., it's a Credit column), if the balance of
your credit card becomes negative it means you have paid them
too much money (i.e., it's a Debit column). Notice how the sign
is different when money is paid to the bank account (+ve) as
opposed to the credit card (-ve).

On the G/L system you probably have all the liabilities listed
and when added up they come to a positive number. The assets
should also add up to a positive number. Adding the two together
in simple arithmetic terms should produce a nice big positive
number which is not useful. The accounting convention is to
negate all Debit values before adding them to Credit values,
i.e., the result represents how much assets exceed liabilities.
Obviously a negative number here means bad news for unsecured
creditors if the company is in receivership.

Most people don't notice this process since it is part of an
accounting framework. Deep inside the application is a lookup
table or application code or some other device that applies this
Debit/Credit convention every time it's needed. My proposal is
to make this part of the column characteristic so this logic is
moved to the table design phase (and handled by the backend)
rather than the application needing to keep track of which
column values need to be negated and when.

Basically if MONEY is to be a useful tool it should really
handle money matters in a way that makes accountants happy. If
it can't do that then nobody is going to bother using it for
serious work since NUMERIC and INTEGER will do the job just as
well without the surprises.

Regards
Gavan Schneider



--
Sent via pgsql-general mailing list (pgsql-general@postgresql.org)
To make changes to your subscription:
http://www.postgresql.org/mailpref/pgsql-general