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