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

[Christopher Lam]

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

> 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.
>

For a regular budget month, let's allocate $400 income to: $100 general
expenses, $200 pay back home loan, $100 savings.
Internally they are currently represented as: income=400,expenses=200,
loan=-200, savings=100.

As Phil reports; income-expenses-assets+liability = 0.
The more consistent approach is: income=-400, expense=200, loan=200,
savings=100.

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).
>

The pending work is at https://github.com/Gnucash/gnucash/pull/585 and
performs a one time sign conversion. It will offer scan the budget amounts,
make an educated guess at the sign-reversal strategy in use, heavily biased
towards using credit-accounts. Then sets a feature flag to trigger the
newer code path and prevent writing datafile by versions prior to 3.8, and
prompt the user to recheck all budgets. If the user elects to delay the
sign conversion, the budget will be read only until the conversion is run.

*But all of this will be stalled until the current budget viewer is
thoroughly debugged.*