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

[Adrien Monteleone]

Geert,

I concur.

As long as the internals treat the equation as set to equal zero, then signage is necessary and it should be consistent. I appreciate the efforts being made to achieve this.

My (pie in the sky) request for consideration is the idea that such a treatment of the equation is inconsistent with accounting texts and practice (as best I can tell) and should one day be changed so that GnuCash more closely follows how accountancy treats the equation. This would eliminate issues with signage as there wouldn’t be any. All ‘normal’ values (unless contra-balanced) would be positive. (and even then, signage would still be a display consideration that is based on a choice to not present the balance as either a debit or credit, but with a sign)

The equation is:

Assets = Liabilities + Equity

It is *not*:

Assets - Liabilities - Equity = 0

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.

Regards,
Adrien

> On Apr 28, 2020 w18d119, at 8:18 AM, Geert Janssens <geert.gnucash at kobaltwit.be> wrote:
> 
> My simplistic view on this: if there is going to be confusion anyway, let's at least make it consistent.
>  
> We have the sign reversal strategies in there to alter gnucash number presentation behavior. To me it would make sense this affects normal transactions the same way as it would reports as it would budgetting.
>  
> That's currently not the case, which means users have to keep two mental models in their head: one for transactions (is liability interpreted such or so, and so on) and another for budgets. I personally think that's a big hurdle.
>  
> Keep in mind that these reversal strategies (should) only be relevant for the display of information. Internally numbers should always be stored according to the signs in the accounting equation. Again budget values didn't follow this rules. So besides being inconsistent to users it is also inconsistent and confusing to developers.
>  
> That's what prompted the work to bring this all in line.
>  
> No doubt this may change the interpretation of certain numbers. We can't avoid this completely. What we had was inconsistent and created interpretations based on the inconsistent behavior. Change that and the interpretation has to change with it.
>  
> Regards,
>  
> Geert