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

[Phil Longstaff]

Agreed.

It is correct that Assets = Liabilities + Equity uses only positive values.
However, each balance is a credit balance or a debit balance. It is
perfectly reasonable to associate one of those types of balance with
positive numbers and the other with negative numbers.

On Wed, Apr 29, 2020 at 4:36 AM Geert Janssens <geert.gnucash at kobaltwit.be>
wrote:

> 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.
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>