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

[David Carlson]

Please keep in mind that budgets may also be used by people with no
accounting training, like myself, who get overwhelmed by the terms debit
and credit and where each is properly used.

On Tue, Apr 28, 2020 at 1:23 PM Adrien Monteleone <
adrien.monteleone at lusfiber.net> wrote:

>
>
> > 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.
> >
> > Great, thanks for that!
> >
> > Geert
>
>
> _______________________________________________
> gnucash-devel mailing list
> gnucash-devel at gnucash.org
> https://lists.gnucash.org/mailman/listinfo/gnucash-devel
>


-- 
David Carlson