[GNC-dev] About budgets in 3.8, 3.9 and 3.10

[John Ralls]

> On Apr 29, 2020, at 1:42 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> Op dinsdag 28 april 2020 18:35:16 CEST schreef John Ralls:
> > > On Apr 28, 2020, at 7:27 AM, Geert Janssens <geert.gnucash at 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
>  
> 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.


But the UI has a debit and a credit column and we combine the two into a signed amount. Which one is negative depends on the account type and the value of the sign-reversal preference. The really bad part is that the determination is made in UI code instead of in the engine, so each UI (register, transfer dialog, reports code, budget, business) has its own implementation of the needed behavior and that's how we got in this mess in the first place: The budget code got it wrong.

This is completely orthogonal to the words used in the column labels, but it does surface in places like the Transfer Dialog where the user is presented with a single amount field (two if it's a multi-commodity transaction) and enters a signed amount. I think most users would expect the positive amount means to decrease the left-hand account and to increase the (or decrease it too if one is Assets and the other Equity/Liability) right hand one (bet we don't flip that for RTL languages), but it depends on respective account types and the value of the sign-reversal preference. IMO keeping that straight is a lot harder than remembering that Asset balances increase and Equity/Liability balances decrease with debits and that "debit" just means "left-hand column".

Regards,
John Ralls