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@xxxxxxxxxxxxxx Subject: Re: 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@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general -- Sent via pgsql-general mailing list (pgsql-general@xxxxxxxxxxxxxx) To make changes to your subscription: http://www.postgresql.org/mailpref/pgsql-general
