> On Apr 29, 2020, at 1:42 AM, Geert Janssens <geert.gnuc...@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.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
>
> 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
_______________________________________________
gnucash-devel mailing list
gnucash-devel@gnucash.org
https://lists.gnucash.org/mailman/listinfo/gnucash-devel
