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

[Geert Janssens]

Adrien,

As David Carlson points out not everyone knows how to interpret debit and credit. So moving 
away from a signed representation towards Debit/Credit representation simply moves the 
confusion with it. Now one has to know whether a number marked as debit was really a debit or 
not. That would raise the barrier for many people (actually including myself; I continue to 
struggle with those terms even if I understand them in theory :)

Having said that, I'm agnostic to what internal representation we use as long as it's consistent 
across the board. The current implementation is sign-based so fixes are/were focused on doing 
that consistently. If debit/credit would make more sense, I'm fine with that as well. Will not 
make it for 4.x obviously and someone will have to take the time to implement this (which I 
estimate is a lot of work).

Finally I want to clearly point out the actual inconsistency in the budget code is not whether it 
uses a signed representation or a debit/credit notation. The issue is it stores the budget data in 
a way that's dependent on the Sign reversal strategy chosen in the preferences. The result is 
that the data in your book will be interpreted *differently* depending on the value of that 
preference when saving or loading your book. That is very bad and the sole reason this change 
was proposed in the first place.

The side effects of this fix have sparked a lot of discussion on how budgets really should be 
interpreted. Which is fine, but not the core issue we're at this point trying to address. The goal 
for 4.x is to separate data storage format from that preference so that internally the data will 
always be stored consistently and the preference only affects how it's displayed to the user.

We can't fix this for 3.x as this is a data format change. However what we are trying for 3.x is to 
limit the damage by some code tweaks. I don't remember all the details as I'm not the one 
doing this work. It has something to do however with fixing the interpretation for one specific 
sign reversal strategy (which looks like it covers most of the cases).

Regards,

Geert

Op dinsdag 28 april 2020 20:22:26 CEST schreef Adrien Monteleone:
> > On Apr 28, 2020 w18d119, at 9:27 AM, Geert Janssens
> > <geert.gnucash at kobaltwit.be> wrote:
> > 
> > What I take from all this is that as long as you display data in two
> > columns (a debit and a credit) you can follow the logic as you suggest.
> Most likely, that’s what I thought at first too, but I suppose a notation
> like “Dr./Cr.” or “D/C” could be used instead, though it might be more
> visual clutter than two columns. Two columns might also be much easier to
> spot if balances are correct or contra for an account. (such as, "is the
> balance in the proper column?”)
> 
> Two columns might also be easier on translators than
> abbreviations/notations.
> > 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.
> Not necessarily.
> 
> If the equation is treated in code as:
> 
> Assets = Liabilities + Equity
> 
> then those values are all positive. You don’t test for zero, you test for
> equality between left and right. (I don’t know if that is more
> computationally expensive or not. I’m not as up to par as I should be on
> modern processor instructions and what is available.) My conception is the
> value of each side would be stored, you then do a <,>,=,!= test. (whichever
> seems saner in code and is faster)
> 
> The idea is also that each account would keep debit and credit balances.
> (just like in the ’T’ accounts) The overall account balance is the absolute
> value of the difference. (still no negative numbers, but a subtraction with
> two positives, and the result being positive)
> 
> Whether the balance is represented as Debit or Credit is done by an
> additional check for which term was greater before the difference was
> taken.
> 
> This would happen probably everywhere. (individual transactions, integrity
> checks, reports, budgets)
> 
> Again, I don’t know if such logic is more expensive computationally. But it
> does model traditional accounting better and removes the need for signs
> presentationally, and computationally.
> 
> The only place I might think signs would be appropriate in this case would
> be in reports that show variances. (an increase or decrease in absolute
> value, without regard to debit or credit) For example, if a Balance Sheet
> comparison report (doesn’t exist yet) showed liabilities increased, both
> numbers would be positive, as would the variance. If liabilities decreased,
> both would be positive with a negative variance. The same would hold for a
> multi-period income statement with a variance column (doesn’t exist yet) or
> the current budget report, or transaction comparison report. (still
> not-official I think)
> 
> Just a few thoughts...
> 
> Regards,
> Adrien
> 
> > So regardless of how you interpret the equations at some point it all
> > boils down to dry maths. The exact internal representation is less
> > important as long as it's consistent.
> > 
> > How to display this internal representation to the user is mostly a matter
> > of taste. And clearly various opinions on that exist based on user's
> > background and experience.> 
> > > I’m sure there was a reasonable basis for the decision decades ago to
> > > employ the equation in this form, I question whether the reasoning
> > > still holds and posit that it might have produced more work and effort
> > > than it has saved, or will. (not just for developers, but for the many
> > > users as well) I don’t know if this reasoning ever made it into any
> > > sort of documentation or code comments. (I admit, I haven’t looked
> > > –yet)
> > > 
> > > I understand that saying such a change would be ‘major’ is a gross
> > > understatement.
> > :
> > :)
> > :
> > > I’ll keep testing the beta build(s) and reporting anything that appears
> > > inconsistent with sign treatment, or incorrect with the basic math
> > > results.