Am 29.04.20 um 10:42 schrieb Geert Janssens: > Op dinsdag 28 april 2020 18:35:16 CEST schreef John Ralls: >>> On Apr 28, 2020, at 7:27 AM, Geert Janssens <geert.gnuc...@kobaltwit.be> >>> wrote: >>> >>> However numbers are not just meant for displaying, one needs to do >>> calculations on them as well. And at that point signs will matter. >>> Whether a certain number increase or decrease your balance is a matter of >>> sign. >> >> Maybe we should change that: Instead of using operator+() and operator-() we >> could have a balance class with functions credit() and debit(). It would >> have subclasses AssetBalance, LiabilityBalance, and EquityBalance (or maybe >> follow the European model and just do ActiveBalance and PassiveBalance) >> whose overrides of credit() and debit() would do The Right Thing. >> >> Regards, >> John Ralls
+1 > That's certainly something to consider for future development. It just > encapsulates the math a > bit further. Nice thing there is that we only have to think about it once, > namely the moment we > set up this class hierarchy. > > Or not... data still has to enter gnucash and the outside world rarely speaks > in debits or credits. > The receipt I get from my last restaurant visit just mentions an amount to > pay, the csv I get > from my bank talks of deposit and withdrawal,... > > So while good for internal representation I think gnucash will always have to > provide the > convenience terms for data entry (or display) in addition to the more formal > terms. > > Regards, > > Geert That level is in theory behind disabling Edit->Preferences->Accounts->Labels:Use formal Accounting Labels and the defaults for the action field. Frank _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
