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

[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.
> 
> Great, thanks for that!
>  
> Geert