Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Now that 3.11 is truly out, the budget editor and report should now behave exactly as in 3.7 4.0 should also behave similarly. Please verify, and any bug reports and fixes will apply onto 4.x series. On Fri, 8 May 2020 at 12:58, Christopher Lam wrote: > 3.11 being due in 3 weeks' time, the candidate fix for budgets is merged > in daily builds. The next build after 4th May in > https://code.gnucash.org/builds/win32/maint/ will have the budgets > reverted to 3.7 behaviour. > > On Wed, 29 Apr 2020 at 20:05, John Ralls wrote: > >> >> >> > On Apr 29, 2020, at 11:45 AM, Phil Longstaff >> wrote: >> > >> > 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. >> > >> >> It is. What's not reasonable is to have a preference (as opposed to a >> book option) that changes which is negative, especially for stored values. >> Even having a book option is dicey unless that option affects exactly one >> place in all of GnuCash's code base. >> >> Regards, >> John Ralls >> >> ___ >> 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
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
3.11 being due in 3 weeks' time, the candidate fix for budgets is merged in daily builds. The next build after 4th May in https://code.gnucash.org/builds/win32/maint/ will have the budgets reverted to 3.7 behaviour. On Wed, 29 Apr 2020 at 20:05, John Ralls wrote: > > > > On Apr 29, 2020, at 11:45 AM, Phil Longstaff > wrote: > > > > 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. > > > > It is. What's not reasonable is to have a preference (as opposed to a book > option) that changes which is negative, especially for stored values. Even > having a book option is dicey unless that option affects exactly one place > in all of GnuCash's code base. > > Regards, > John Ralls > > ___ > 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
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
> On Apr 29, 2020, at 11:45 AM, Phil Longstaff wrote: > > 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. > It is. What's not reasonable is to have a preference (as opposed to a book option) that changes which is negative, especially for stored values. Even having a book option is dicey unless that option affects exactly one place in all of GnuCash's code base. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
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 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 > > > 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 >
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
> On Apr 29, 2020, at 1:42 AM, Geert Janssens > wrote: > > Op dinsdag 28 april 2020 18:35:16 CEST schreef John Ralls: > > > On Apr 28, 2020, at 7:27 AM, Geert Janssens > > > wrote: > > > > > > 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. > > > > Maybe we should change that: Instead of using operator+() and operator-() we > > could have a balance class with functions credit() and debit(). It would > > have subclasses AssetBalance, LiabilityBalance, and EquityBalance (or maybe > > follow the European model and just do ActiveBalance and PassiveBalance) > > whose overrides of credit() and debit() would do The Right Thing. > > > > Regards, > > John Ralls > > That's certainly something to consider for future development. It just > encapsulates the math a bit further. Nice thing there is that we only have to > think about it once, namely the moment we set up this class hierarchy. > > Or not... data still has to enter gnucash and the outside world rarely speaks > in debits or credits. The receipt I get from my last restaurant visit just > mentions an amount to pay, the csv I get from my bank talks of deposit and > withdrawal,... > > So while good for internal representation I think gnucash will always have to > provide the convenience terms for data entry (or display) in addition to the > more formal terms. But the UI has a debit and a credit column and we combine the two into a signed amount. Which one is negative depends on the account type and the value of the sign-reversal preference. The really bad part is that the determination is made in UI code instead of in the engine, so each UI (register, transfer dialog, reports code, budget, business) has its own implementation of the needed behavior and that's how we got in this mess in the first place: The budget code got it wrong. This is completely orthogonal to the words used in the column labels, but it does surface in places like the Transfer Dialog where the user is presented with a single amount field (two if it's a multi-commodity transaction) and enters a signed amount. I think most users would expect the positive amount means to decrease the left-hand account and to increase the (or decrease it too if one is Assets and the other Equity/Liability) right hand one (bet we don't flip that for RTL languages), but it depends on respective account types and the value of the sign-reversal preference. IMO keeping that straight is a lot harder than remembering that Asset balances increase and Equity/Liability balances decrease with debits and that "debit" just means "left-hand column". Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Am 29.04.20 um 10:42 schrieb Geert Janssens: > Op dinsdag 28 april 2020 18:35:16 CEST schreef John Ralls: >>> On Apr 28, 2020, at 7:27 AM, Geert Janssens >>> wrote: >>> >>> 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. >> >> Maybe we should change that: Instead of using operator+() and operator-() we >> could have a balance class with functions credit() and debit(). It would >> have subclasses AssetBalance, LiabilityBalance, and EquityBalance (or maybe >> follow the European model and just do ActiveBalance and PassiveBalance) >> whose overrides of credit() and debit() would do The Right Thing. >> >> Regards, >> John Ralls +1 > That's certainly something to consider for future development. It just > encapsulates the math a > bit further. Nice thing there is that we only have to think about it once, > namely the moment we > set up this class hierarchy. > > Or not... data still has to enter gnucash and the outside world rarely speaks > in debits or credits. > The receipt I get from my last restaurant visit just mentions an amount to > pay, the csv I get > from my bank talks of deposit and withdrawal,... > > So while good for internal representation I think gnucash will always have to > provide the > convenience terms for data entry (or display) in addition to the more formal > terms. > > Regards, > > Geert That level is in theory behind disabling Edit->Preferences->Accounts->Labels:Use formal Accounting Labels and the defaults for the action field. Frank ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
On Wed, 29 Apr 2020 at 08:36, Geert Janssens 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.* ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Op dinsdag 28 april 2020 18:35:16 CEST schreef John Ralls: > > On Apr 28, 2020, at 7:27 AM, Geert Janssens > > wrote: > > > > 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. > > Maybe we should change that: Instead of using operator+() and operator-() we > could have a balance class with functions credit() and debit(). It would > have subclasses AssetBalance, LiabilityBalance, and EquityBalance (or maybe > follow the European model and just do ActiveBalance and PassiveBalance) > whose overrides of credit() and debit() would do The Right Thing. > > Regards, > John Ralls That's certainly something to consider for future development. It just encapsulates the math a bit further. Nice thing there is that we only have to think about it once, namely the moment we set up this class hierarchy. Or not... data still has to enter gnucash and the outside world rarely speaks in debits or credits. The receipt I get from my last restaurant visit just mentions an amount to pay, the csv I get from my bank talks of deposit and withdrawal,... So while good for internal representation I think gnucash will always have to provide the convenience terms for data entry (or display) in addition to the more formal terms. Regards, Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
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 > > 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
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
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.montele...@lusfiber.net> wrote: > > > > 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. > > > > Great, thanks for that! > > > > Geert > > > ___ > gnucash-devel mailing list > gnucash-devel@gnucash.org > https://lists.gnucash.org/mailman/listinfo/gnucash-devel > -- David Carlson ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
> On Apr 28, 2020 w18d119, at 9:27 AM, Geert Janssens > 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@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
> On Apr 28, 2020, at 7:27 AM, Geert Janssens > wrote: > > 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. Maybe we should change that: Instead of using operator+() and operator-() we could have a balance class with functions credit() and debit(). It would have subclasses AssetBalance, LiabilityBalance, and EquityBalance (or maybe follow the European model and just do ActiveBalance and PassiveBalance) whose overrides of credit() and debit() would do The Right Thing. Regards, John Ralls ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Op dinsdag 28 april 2020 15:58:30 CEST schreef 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 > 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. 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. 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. Geert ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
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 > 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
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 Op maandag 27 april 2020 18:59:41 CEST schreef Adrien Monteleone: > I noticed that odd as well. I also noticed it to be odd to choose ‘Inflow’ > for anything but income. > > However, I’m not sure the preface ‘Inflow from’ or ‘Outflow to’ should even > be there. It produces too much confusion with signs. > > Now I have to be concerned with interpreting the sign to be the opposite of > the prefacing term chosen. > > I might be an outlier, but when I budget outlays, I budget positive amounts. > It doesn’t matter if I’m paying a debt or buying something or saving some. > (liability vs. expense, or asset) > > It makes no sense to me to say I’m ‘budgeting negative $100’ on a liability > unless I was pulling money from a liability to make it available to budget. > (thus taking out a loan, similar to pulling money out of savings for > expenses or debt payments) I suppose I could use ‘Income/Expense’ instead > of ‘Credit Accounts’ as my sign reversal strategy but then that messes with > my use of signs for general accounting. > > I see budgeting as a different context and I don’t think it should follow > the same strict adherence to sign preferences. (maybe that is why it didn’t > honor the setting in the first place) > > The entire issue with signs has to do with someone who made the decision to > re-write the accounting equation with all terms on one side and zero on the > other. The real equation given in every text book I’ve seen is not > presented that way. This is partly why a reversal setting exists. > Traditional accounting doesn’t present credit accounts as negative amounts. > Debits and Credits are specifically and strictly not taught as being > ‘positive’ or ’negative’. I know that’s a bigger fish to fry and more > fundamental to the core code, but it seems to be a stumbling block when the > context of the amounts changes. > > I could get over it and manage because I’ve been with GnuCash long enough. > But a fresh new user might well run into an obstacle here. (and some > already do with the general sign issue in the rest of the app) > > Regards, > Adrien > > > On Apr 27, 2020 w18d118, at 9:13 AM, Frank H. Ellenberger > > wrote: > > > > Hi, > > > > Am 27.04.20 um 06:08 schrieb Christopher Lam: > >> [image: budget-view.png] > > > > as translator I have a problem with "Inflow to" in this context. I had > > only expected "Inflow from" and "Outflow to". > > > > Frank > > ___ > 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
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
No sorry, Windows builds are generated only for maint (3.1x) and master (3.9x eventually 4.x) builds. It would be very disruptive for these branches to receive beta commits and reversals. So, derek's script scans the beta branch on my github fork daily for any changes, and builds a flatpak if it has changed. This way we can be much more certain that a change is acceptable before considering merge onto the mainline builds. BTW thanks warlord. On Tue, 28 Apr 2020 at 11:33, Phil Longstaff wrote: > Is there a windows build? I have a linux vm so might be able to test the > flatpak, but windows would be easier > > On Mon, Apr 27, 2020 at 4:52 PM Christopher Lam > > wrote: > > > Labelling issues aside, is there anyone who would be willing to beta > test? > > > > On Tue, 28 Apr 2020, 2:59 am Adrien Monteleone, < > > adrien.montele...@lusfiber.net> wrote: > > > > > Thanks Phil, so I’m not completely insane then. > > > > > > I too try to remember to factor in signs because GnuCash works that > way. > > I > > > was just throwing in my 2¢ for taking a step back for perspective that > > > maybe can be considered in a future release. (5.0 maybe?) > > > > > > As for danger in generating confusion, the app already throws people at > > > least in the middle of the pool of accounting. Being consistent with > > > accounting text resources might reduce confusion. (in my humble > opinion) > > If > > > texts don’t refer to credit accounts as ’normally negative’, or don’t > > > address or present ’sign’ at all, then people learning on their own > would > > > come to GnuCash and see a similar approach. > > > > > > I presently have my reversed balance accounts setting to ‘Credit > > accounts’ > > > because that way, negative values tell me I have a contra-account > > balance. > > > Short of seeing the balance as Dr. or Cr., that’s the best I can get at > > the > > > moment. > > > > > > Christopher, > > > > > > I’ll add a big ’Thank You’ for tackling this. I understand you have > > > program constraints to work in and can’t re-build the house for the > > kitchen > > > sink. Even if it isn't the optimum, if it is at least consistent and > > works > > > properly, that is better than not. > > > > > > Regards, > > > Adrien > > > > > > > On Apr 27, 2020 w18d118, at 1:43 PM, Phil Longstaff < > > > phil.longst...@gmail.com> wrote: > > > > > > > > I agree with what you say about positive and negative with respect to > > > > budgeting assets and liabilities. However, if I have a transaction > > which > > > > pays down a loan, and then add that loan to the budget report, the > > actual > > > > value is displayed as negative. That is why I budget paying down a > loan > > > > with a negative value. > > > > > > > > I understand what you are saying about budget outlays always being > > > > positive. That also makes sense. However, it doesn't match what > gnucash > > > > currently does. > > > > > > > > Yes, it would be more straightforward to budget either a CR or a DB, > > and > > > > then "amount left to budget" would be sum(DB) - sum(CR). However, > that > > > > would make it more confusing for non-accountants. > > > > > > > > > ___ > > > 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 > > > ___ > 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
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Is there a windows build? I have a linux vm so might be able to test the flatpak, but windows would be easier On Mon, Apr 27, 2020 at 4:52 PM Christopher Lam wrote: > Labelling issues aside, is there anyone who would be willing to beta test? > > On Tue, 28 Apr 2020, 2:59 am Adrien Monteleone, < > adrien.montele...@lusfiber.net> wrote: > > > Thanks Phil, so I’m not completely insane then. > > > > I too try to remember to factor in signs because GnuCash works that way. > I > > was just throwing in my 2¢ for taking a step back for perspective that > > maybe can be considered in a future release. (5.0 maybe?) > > > > As for danger in generating confusion, the app already throws people at > > least in the middle of the pool of accounting. Being consistent with > > accounting text resources might reduce confusion. (in my humble opinion) > If > > texts don’t refer to credit accounts as ’normally negative’, or don’t > > address or present ’sign’ at all, then people learning on their own would > > come to GnuCash and see a similar approach. > > > > I presently have my reversed balance accounts setting to ‘Credit > accounts’ > > because that way, negative values tell me I have a contra-account > balance. > > Short of seeing the balance as Dr. or Cr., that’s the best I can get at > the > > moment. > > > > Christopher, > > > > I’ll add a big ’Thank You’ for tackling this. I understand you have > > program constraints to work in and can’t re-build the house for the > kitchen > > sink. Even if it isn't the optimum, if it is at least consistent and > works > > properly, that is better than not. > > > > Regards, > > Adrien > > > > > On Apr 27, 2020 w18d118, at 1:43 PM, Phil Longstaff < > > phil.longst...@gmail.com> wrote: > > > > > > I agree with what you say about positive and negative with respect to > > > budgeting assets and liabilities. However, if I have a transaction > which > > > pays down a loan, and then add that loan to the budget report, the > actual > > > value is displayed as negative. That is why I budget paying down a loan > > > with a negative value. > > > > > > I understand what you are saying about budget outlays always being > > > positive. That also makes sense. However, it doesn't match what gnucash > > > currently does. > > > > > > Yes, it would be more straightforward to budget either a CR or a DB, > and > > > then "amount left to budget" would be sum(DB) - sum(CR). However, that > > > would make it more confusing for non-accountants. > > > > > > ___ > > 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 > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] About budgets in 3.8, 3.9 and 3.10
> as translator I have a problem with "Inflow to" in this context. I had > only expected "Inflow from" and "Outflow to". > > Frank Good point. Should just use Inflow and Outflow to avoid nonsense terms. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
I do some testing this evening. Regards, Adrien > On Apr 27, 2020 w18d118, at 3:51 PM, Christopher Lam > wrote: > > Labelling issues aside, is there anyone who would be willing to beta test? > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Labelling issues aside, is there anyone who would be willing to beta test? On Tue, 28 Apr 2020, 2:59 am Adrien Monteleone, < adrien.montele...@lusfiber.net> wrote: > Thanks Phil, so I’m not completely insane then. > > I too try to remember to factor in signs because GnuCash works that way. I > was just throwing in my 2¢ for taking a step back for perspective that > maybe can be considered in a future release. (5.0 maybe?) > > As for danger in generating confusion, the app already throws people at > least in the middle of the pool of accounting. Being consistent with > accounting text resources might reduce confusion. (in my humble opinion) If > texts don’t refer to credit accounts as ’normally negative’, or don’t > address or present ’sign’ at all, then people learning on their own would > come to GnuCash and see a similar approach. > > I presently have my reversed balance accounts setting to ‘Credit accounts’ > because that way, negative values tell me I have a contra-account balance. > Short of seeing the balance as Dr. or Cr., that’s the best I can get at the > moment. > > Christopher, > > I’ll add a big ’Thank You’ for tackling this. I understand you have > program constraints to work in and can’t re-build the house for the kitchen > sink. Even if it isn't the optimum, if it is at least consistent and works > properly, that is better than not. > > Regards, > Adrien > > > On Apr 27, 2020 w18d118, at 1:43 PM, Phil Longstaff < > phil.longst...@gmail.com> wrote: > > > > I agree with what you say about positive and negative with respect to > > budgeting assets and liabilities. However, if I have a transaction which > > pays down a loan, and then add that loan to the budget report, the actual > > value is displayed as negative. That is why I budget paying down a loan > > with a negative value. > > > > I understand what you are saying about budget outlays always being > > positive. That also makes sense. However, it doesn't match what gnucash > > currently does. > > > > Yes, it would be more straightforward to budget either a CR or a DB, and > > then "amount left to budget" would be sum(DB) - sum(CR). However, that > > would make it more confusing for non-accountants. > > > ___ > 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
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Thanks Phil, so I’m not completely insane then. I too try to remember to factor in signs because GnuCash works that way. I was just throwing in my 2¢ for taking a step back for perspective that maybe can be considered in a future release. (5.0 maybe?) As for danger in generating confusion, the app already throws people at least in the middle of the pool of accounting. Being consistent with accounting text resources might reduce confusion. (in my humble opinion) If texts don’t refer to credit accounts as ’normally negative’, or don’t address or present ’sign’ at all, then people learning on their own would come to GnuCash and see a similar approach. I presently have my reversed balance accounts setting to ‘Credit accounts’ because that way, negative values tell me I have a contra-account balance. Short of seeing the balance as Dr. or Cr., that’s the best I can get at the moment. Christopher, I’ll add a big ’Thank You’ for tackling this. I understand you have program constraints to work in and can’t re-build the house for the kitchen sink. Even if it isn't the optimum, if it is at least consistent and works properly, that is better than not. Regards, Adrien > On Apr 27, 2020 w18d118, at 1:43 PM, Phil Longstaff > wrote: > > I agree with what you say about positive and negative with respect to > budgeting assets and liabilities. However, if I have a transaction which > pays down a loan, and then add that loan to the budget report, the actual > value is displayed as negative. That is why I budget paying down a loan > with a negative value. > > I understand what you are saying about budget outlays always being > positive. That also makes sense. However, it doesn't match what gnucash > currently does. > > Yes, it would be more straightforward to budget either a CR or a DB, and > then "amount left to budget" would be sum(DB) - sum(CR). However, that > would make it more confusing for non-accountants. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
I agree with what you say about positive and negative with respect to budgeting assets and liabilities. However, if I have a transaction which pays down a loan, and then add that loan to the budget report, the actual value is displayed as negative. That is why I budget paying down a loan with a negative value. I understand what you are saying about budget outlays always being positive. That also makes sense. However, it doesn't match what gnucash currently does. Yes, it would be more straightforward to budget either a CR or a DB, and then "amount left to budget" would be sum(DB) - sum(CR). However, that would make it more confusing for non-accountants. On Mon, Apr 27, 2020 at 1:00 PM Adrien Monteleone < adrien.montele...@lusfiber.net> wrote: > I noticed that odd as well. I also noticed it to be odd to choose ‘Inflow’ > for anything but income. > > However, I’m not sure the preface ‘Inflow from’ or ‘Outflow to’ should > even be there. It produces too much confusion with signs. > > Now I have to be concerned with interpreting the sign to be the opposite > of the prefacing term chosen. > > I might be an outlier, but when I budget outlays, I budget positive > amounts. It doesn’t matter if I’m paying a debt or buying something or > saving some. (liability vs. expense, or asset) > > It makes no sense to me to say I’m ‘budgeting negative $100’ on a > liability unless I was pulling money from a liability to make it available > to budget. (thus taking out a loan, similar to pulling money out of savings > for expenses or debt payments) I suppose I could use ‘Income/Expense’ > instead of ‘Credit Accounts’ as my sign reversal strategy but then that > messes with my use of signs for general accounting. > > I see budgeting as a different context and I don’t think it should follow > the same strict adherence to sign preferences. (maybe that is why it didn’t > honor the setting in the first place) > > The entire issue with signs has to do with someone who made the decision > to re-write the accounting equation with all terms on one side and zero on > the other. The real equation given in every text book I’ve seen is not > presented that way. This is partly why a reversal setting exists. > Traditional accounting doesn’t present credit accounts as negative amounts. > Debits and Credits are specifically and strictly not taught as being > ‘positive’ or ’negative’. I know that’s a bigger fish to fry and more > fundamental to the core code, but it seems to be a stumbling block when the > context of the amounts changes. > > I could get over it and manage because I’ve been with GnuCash long enough. > But a fresh new user might well run into an obstacle here. (and some > already do with the general sign issue in the rest of the app) > > Regards, > Adrien > > > On Apr 27, 2020 w18d118, at 9:13 AM, Frank H. Ellenberger < > frank.h.ellenber...@gmail.com> wrote: > > > > Hi, > > > > Am 27.04.20 um 06:08 schrieb Christopher Lam: > >> [image: budget-view.png] > > > > as translator I have a problem with "Inflow to" in this context. I had > > only expected "Inflow from" and "Outflow to". > > > > Frank > > ___ > 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
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
I noticed that odd as well. I also noticed it to be odd to choose ‘Inflow’ for anything but income. However, I’m not sure the preface ‘Inflow from’ or ‘Outflow to’ should even be there. It produces too much confusion with signs. Now I have to be concerned with interpreting the sign to be the opposite of the prefacing term chosen. I might be an outlier, but when I budget outlays, I budget positive amounts. It doesn’t matter if I’m paying a debt or buying something or saving some. (liability vs. expense, or asset) It makes no sense to me to say I’m ‘budgeting negative $100’ on a liability unless I was pulling money from a liability to make it available to budget. (thus taking out a loan, similar to pulling money out of savings for expenses or debt payments) I suppose I could use ‘Income/Expense’ instead of ‘Credit Accounts’ as my sign reversal strategy but then that messes with my use of signs for general accounting. I see budgeting as a different context and I don’t think it should follow the same strict adherence to sign preferences. (maybe that is why it didn’t honor the setting in the first place) The entire issue with signs has to do with someone who made the decision to re-write the accounting equation with all terms on one side and zero on the other. The real equation given in every text book I’ve seen is not presented that way. This is partly why a reversal setting exists. Traditional accounting doesn’t present credit accounts as negative amounts. Debits and Credits are specifically and strictly not taught as being ‘positive’ or ’negative’. I know that’s a bigger fish to fry and more fundamental to the core code, but it seems to be a stumbling block when the context of the amounts changes. I could get over it and manage because I’ve been with GnuCash long enough. But a fresh new user might well run into an obstacle here. (and some already do with the general sign issue in the rest of the app) Regards, Adrien > On Apr 27, 2020 w18d118, at 9:13 AM, Frank H. Ellenberger > wrote: > > Hi, > > Am 27.04.20 um 06:08 schrieb Christopher Lam: >> [image: budget-view.png] > > as translator I have a problem with "Inflow to" in this context. I had > only expected "Inflow from" and "Outflow to". > > Frank ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Hi, Am 27.04.20 um 06:08 schrieb Christopher Lam: > [image: budget-view.png] as translator I have a problem with "Inflow to" in this context. I had only expected "Inflow from" and "Outflow to". Frank ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Thank you Phil. I'm sure you know the issue with existing budgets - they do not behave as expected when the Estimate tool is used to pre-fill cells, when sign-reverse isn't credit-accounts. There is *another* issue (not documented afaik in bugzilla) about budgets: the totals do not total budget-amounts whereby account-type is bank/cash/loan; i.e. it only tallies account-type asset/liability/etc. I *think* this should be fixed. Any ideas? Derek has kindly agreed to create regular flatpak builds for me and these builds need testing. It is very difficult to fix the above without adequate testers using their existing budgets. The next candidate will be available in https://code.gnucash.org/builds/flatpak/christopherlam/beta/ (after 27/4/2020) Your YTD feature has been replicated in the existing budget report - see General / use accumulated amounts Summing children accounts will always be difficult because children accounts may have an incompatible account type. On Mon, 27 Apr 2020 at 11:34, Phil Longstaff wrote: > Hi Chris, > > thanks for taking this on. I am sorry I don't have more time to commit to > the project. > > I don't like the terms "Outflow to Asset" and "Inflow to Liability". > > For Assets, here is how I see a budget being used. > > If I want to plan to put money into savings (an asset), I will have a > budget with a positive value for that month for that account. > If I want to plan to pull money from savings (e.g. a retirement savings > fund), I will have a budget with a negative value for that month for that > account. > > For Liabilities, it is similar. > > If I plan to pay off part of a loan or line of credit, I will have a budget > with a negative value for that month for that account. > If I plan to increase the value of a loan or line of credit, I will have a > budget with a positive value for that month for that account. > > In other words, positive value increase an asset or liability, and negative > values decrease them. > > In this case, the room left in my budget is Income - Expenses - Assets + > Liabilities. > > If I can speak to the budget report for a minute, there are 2 things I see: > > 1) I miss the ability to see YTD. A few years ago, I created a report which > had 3 sets of columns: current month, YTD, and total year. I find YTD > useful because for some accounts, I may have an idea of the total budget > for the year, but do not know the timing. I can then either allocate the > whole budget to one month (January? December? July?) or split it evenly > across all months. I usually split it. An example is car maintenance. I > know that my car will need about $X repairs for the typical year, but I > don't know when the repairs will be. I allocate $X/12 for each month. If I > put the entire value $X in 1 month, it gives me a skewed idea for my budget > room for that month. Putting $X/12 for each month, it is easier to see that > some months, income > expenses, and for other months, income < expenses, > but for the year, it evens out. I use YTD and Total Year columns to see how > well this evening out is working. > > 2) For parent rows, I would like to see the budget and actual values show > the sum of the selected children, not all children. I may wish to produce a > budget report for a subset of all of my expense accounts (e.g. my wife's > and my personal expenses like clothing, haircuts, etc). The problem is that > the "Expenses" parent line shows the actual value of *all* expenses, not > just the ones I have selected. This is > https://bugs.gnucash.org/show_bug.cgi?id=780382. My Scheme is not very > good, but I will see if I can find some time to look at this one. > > Phil > > On Mon, Apr 27, 2020 at 12:10 AM Christopher Lam < > christopher@gmail.com> > wrote: > > > Would anyone object to the following (last) amendment to budget totals: > > separate the account types, and add 'Remaining to budget' line which > > implements the budget-to-zero facility, and *will* replicate the 3.7 > > behaviour. > > (Note the totals *will* be renamed to "Total Assets" "Total Expense" > etc.) > > > > [image: budget-view.png] > > > > > > On Sun, 19 Apr 2020 at 05:07, Christopher Lam > > > wrote: > > > > > Thank you for trying Adrien. This budget bug is proving to be a major > > > headache. I really need more beta testers, especially with ability to > > build > > > from my branch. > > > > > > Of note: > > > * previous methodology was: in a period, budgeted income, minus > budgeted > > > expense and any asset/liability transfers, must result in zero. This > > > assumes credit-accounts sign reversal. > > > * future methodology is: in a period, all natural budget amounts must > > > equal zero. i.e. incomes being negative, will be balanced by positive > > > expenses etc. > > > > > > My plan to try fix this for good is to *remove* all totals except the > > > "Remaining to Budget"; from my understanding this is the only total of > > any > > > use. > > > > > > Alternatively, another plan is to
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Hi Chris, thanks for taking this on. I am sorry I don't have more time to commit to the project. I don't like the terms "Outflow to Asset" and "Inflow to Liability". For Assets, here is how I see a budget being used. If I want to plan to put money into savings (an asset), I will have a budget with a positive value for that month for that account. If I want to plan to pull money from savings (e.g. a retirement savings fund), I will have a budget with a negative value for that month for that account. For Liabilities, it is similar. If I plan to pay off part of a loan or line of credit, I will have a budget with a negative value for that month for that account. If I plan to increase the value of a loan or line of credit, I will have a budget with a positive value for that month for that account. In other words, positive value increase an asset or liability, and negative values decrease them. In this case, the room left in my budget is Income - Expenses - Assets + Liabilities. If I can speak to the budget report for a minute, there are 2 things I see: 1) I miss the ability to see YTD. A few years ago, I created a report which had 3 sets of columns: current month, YTD, and total year. I find YTD useful because for some accounts, I may have an idea of the total budget for the year, but do not know the timing. I can then either allocate the whole budget to one month (January? December? July?) or split it evenly across all months. I usually split it. An example is car maintenance. I know that my car will need about $X repairs for the typical year, but I don't know when the repairs will be. I allocate $X/12 for each month. If I put the entire value $X in 1 month, it gives me a skewed idea for my budget room for that month. Putting $X/12 for each month, it is easier to see that some months, income > expenses, and for other months, income < expenses, but for the year, it evens out. I use YTD and Total Year columns to see how well this evening out is working. 2) For parent rows, I would like to see the budget and actual values show the sum of the selected children, not all children. I may wish to produce a budget report for a subset of all of my expense accounts (e.g. my wife's and my personal expenses like clothing, haircuts, etc). The problem is that the "Expenses" parent line shows the actual value of *all* expenses, not just the ones I have selected. This is https://bugs.gnucash.org/show_bug.cgi?id=780382. My Scheme is not very good, but I will see if I can find some time to look at this one. Phil On Mon, Apr 27, 2020 at 12:10 AM Christopher Lam wrote: > Would anyone object to the following (last) amendment to budget totals: > separate the account types, and add 'Remaining to budget' line which > implements the budget-to-zero facility, and *will* replicate the 3.7 > behaviour. > (Note the totals *will* be renamed to "Total Assets" "Total Expense" etc.) > > [image: budget-view.png] > > > On Sun, 19 Apr 2020 at 05:07, Christopher Lam > wrote: > > > Thank you for trying Adrien. This budget bug is proving to be a major > > headache. I really need more beta testers, especially with ability to > build > > from my branch. > > > > Of note: > > * previous methodology was: in a period, budgeted income, minus budgeted > > expense and any asset/liability transfers, must result in zero. This > > assumes credit-accounts sign reversal. > > * future methodology is: in a period, all natural budget amounts must > > equal zero. i.e. incomes being negative, will be balanced by positive > > expenses etc. > > > > My plan to try fix this for good is to *remove* all totals except the > > "Remaining to Budget"; from my understanding this is the only total of > any > > use. > > > > Alternatively, another plan is to switch to future methodology and forego > > backward compatibility in existing budgets, for use in 4.x or 5.x. > > > > On Fri, 10 Apr 2020 at 17:59, Adrien Monteleone < > > adrien.montele...@lusfiber.net> wrote: > > > >> I just posted my first result and impression to the bug report, though > >> I’m sure you saw that already. (this is more for the benefit of list > >> readers not following the bug) > >> > >> The signs aren’t making sense, and the amounts aren’t adding up > correctly. > >> > >> Regards, > >> Adrien > >> > >> > On Apr 10, 2020 w15d101, at 5:59 AM, Christopher Lam < > >> christopher@gmail.com> wrote: > >> > > >> > Next addendum: your existing budget data will behave well when reverse > >> > balances=credit accounts, but the *featured* data will be stable with > >> *any* > >> > reverse balances global preference option. > >> > > >> > On Fri, 10 Apr 2020, 11:28 am Christopher Lam, < > >> christopher@gmail.com> > >> > wrote: > >> > > >> >> > >> >> > >> >> On Fri, 10 Apr 2020, 10:20 am Christopher Lam, < > >> christopher@gmail.com> > >> >> wrote: > >> >> > >> >>> Deadline is 11 April at noon GMT, so, about 34 hours from now. > >> >>> > >> >>> For both: *existing* datafile and especially
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Would anyone object to the following (last) amendment to budget totals: separate the account types, and add 'Remaining to budget' line which implements the budget-to-zero facility, and *will* replicate the 3.7 behaviour. (Note the totals *will* be renamed to "Total Assets" "Total Expense" etc.) [image: budget-view.png] On Sun, 19 Apr 2020 at 05:07, Christopher Lam wrote: > Thank you for trying Adrien. This budget bug is proving to be a major > headache. I really need more beta testers, especially with ability to build > from my branch. > > Of note: > * previous methodology was: in a period, budgeted income, minus budgeted > expense and any asset/liability transfers, must result in zero. This > assumes credit-accounts sign reversal. > * future methodology is: in a period, all natural budget amounts must > equal zero. i.e. incomes being negative, will be balanced by positive > expenses etc. > > My plan to try fix this for good is to *remove* all totals except the > "Remaining to Budget"; from my understanding this is the only total of any > use. > > Alternatively, another plan is to switch to future methodology and forego > backward compatibility in existing budgets, for use in 4.x or 5.x. > > On Fri, 10 Apr 2020 at 17:59, Adrien Monteleone < > adrien.montele...@lusfiber.net> wrote: > >> I just posted my first result and impression to the bug report, though >> I’m sure you saw that already. (this is more for the benefit of list >> readers not following the bug) >> >> The signs aren’t making sense, and the amounts aren’t adding up correctly. >> >> Regards, >> Adrien >> >> > On Apr 10, 2020 w15d101, at 5:59 AM, Christopher Lam < >> christopher@gmail.com> wrote: >> > >> > Next addendum: your existing budget data will behave well when reverse >> > balances=credit accounts, but the *featured* data will be stable with >> *any* >> > reverse balances global preference option. >> > >> > On Fri, 10 Apr 2020, 11:28 am Christopher Lam, < >> christopher@gmail.com> >> > wrote: >> > >> >> >> >> >> >> On Fri, 10 Apr 2020, 10:20 am Christopher Lam, < >> christopher@gmail.com> >> >> wrote: >> >> >> >>> Deadline is 11 April at noon GMT, so, about 34 hours from now. >> >>> >> >>> For both: *existing* datafile and especially *4.x-featured *datafile >> (in >> >>> bug report). >> >>> >> >>> Please test: >> >>> - creation of budget amounts >> >>> - use estimate to prefill cells >> >>> - all totals in all 5 account types A/L/Inc/Exp/Eq behave >> appropriately >> >>> >> >> >> >> Addendum this is not simply an arithmetic test; it *must also >> >> confirm that the totals and signs are sensible for the purpose of >> >> budgeting. Hence the difficulty of a one person coder to make it work. >> For >> >> example, we can budget a liability account regularly until we have >> enough >> >> deposit for a huge loan, or we can budget a liability account >> regularly for >> >> the loan repayments. IIUC both approaches are "valid" but the signs >> will be >> >> opposite. Other counter examples likely exist. >> >> >> >> - budget.scm report (optionally other budget reports but these are >> lower >> >>> priority) and especially difference column. >> >>> >> >>> On Fri, 10 Apr 2020 at 02:16, Adrien Monteleone < >> >>> adrien.montele...@lusfiber.net> wrote: >> >>> >> Thank You! This makes it so much easier to test. I’ll give the >> flatpak a >> spin and see what I find. I still haven’t set up a build environment >> for >> Mac yet. (and watching a recent thread on the subject makes it look >> daunting compared to Linux) >> >> This is a busy weekend for me though. What kind of time frame do you >> have and is there something in particular you’re looking to find. >> (other >> than just loosely that the totals appear to work) >> >> Regards, >> Adrien >> >> > On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam < >> christopher@gmail.com> wrote: >> > >> > 2020-04-07 nightly available at >> https://code.gnucash.org/builds/win32/maint/ >> > flatpaks available at >> https://code.gnucash.org/builds/flatpak/maint/ >> - use >> > between 2020-04-04 and 2020-04-10 >> > >> > On Fri, 10 Apr 2020 at 01:38, Christopher Lam < >> christopher@gmail.com> >> > wrote: >> > >> >> This topic is about budgets. >> >> >> >> We now know that budgets are currently inherently flawed: they >> *assume* >> >> that sign-reversal = credit-accounts, and do not work well at all >> with any >> >> other sign-reversal option. In addition, there was a feature >> request >> (bug >> >> 781345) that introduced budget equity into the equation, and I >> still >> do not >> >> know whether a budget equity amount is a correct approach. >> >> >> >> In 4.x series there is a planned *fix* which will scan budget >> amounts, >> >> use heuristics to determine the most likely sign-reversal approach >>
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Thank you for trying Adrien. This budget bug is proving to be a major headache. I really need more beta testers, especially with ability to build from my branch. Of note: * previous methodology was: in a period, budgeted income, minus budgeted expense and any asset/liability transfers, must result in zero. This assumes credit-accounts sign reversal. * future methodology is: in a period, all natural budget amounts must equal zero. i.e. incomes being negative, will be balanced by positive expenses etc. My plan to try fix this for good is to *remove* all totals except the "Remaining to Budget"; from my understanding this is the only total of any use. Alternatively, another plan is to switch to future methodology and forego backward compatibility in existing budgets, for use in 4.x or 5.x. On Fri, 10 Apr 2020 at 17:59, Adrien Monteleone < adrien.montele...@lusfiber.net> wrote: > I just posted my first result and impression to the bug report, though I’m > sure you saw that already. (this is more for the benefit of list readers > not following the bug) > > The signs aren’t making sense, and the amounts aren’t adding up correctly. > > Regards, > Adrien > > > On Apr 10, 2020 w15d101, at 5:59 AM, Christopher Lam < > christopher@gmail.com> wrote: > > > > Next addendum: your existing budget data will behave well when reverse > > balances=credit accounts, but the *featured* data will be stable with > *any* > > reverse balances global preference option. > > > > On Fri, 10 Apr 2020, 11:28 am Christopher Lam, < > christopher@gmail.com> > > wrote: > > > >> > >> > >> On Fri, 10 Apr 2020, 10:20 am Christopher Lam, < > christopher@gmail.com> > >> wrote: > >> > >>> Deadline is 11 April at noon GMT, so, about 34 hours from now. > >>> > >>> For both: *existing* datafile and especially *4.x-featured *datafile > (in > >>> bug report). > >>> > >>> Please test: > >>> - creation of budget amounts > >>> - use estimate to prefill cells > >>> - all totals in all 5 account types A/L/Inc/Exp/Eq behave appropriately > >>> > >> > >> Addendum this is not simply an arithmetic test; it *must also > >> confirm that the totals and signs are sensible for the purpose of > >> budgeting. Hence the difficulty of a one person coder to make it work. > For > >> example, we can budget a liability account regularly until we have > enough > >> deposit for a huge loan, or we can budget a liability account regularly > for > >> the loan repayments. IIUC both approaches are "valid" but the signs > will be > >> opposite. Other counter examples likely exist. > >> > >> - budget.scm report (optionally other budget reports but these are lower > >>> priority) and especially difference column. > >>> > >>> On Fri, 10 Apr 2020 at 02:16, Adrien Monteleone < > >>> adrien.montele...@lusfiber.net> wrote: > >>> > Thank You! This makes it so much easier to test. I’ll give the > flatpak a > spin and see what I find. I still haven’t set up a build environment > for > Mac yet. (and watching a recent thread on the subject makes it look > daunting compared to Linux) > > This is a busy weekend for me though. What kind of time frame do you > have and is there something in particular you’re looking to find. > (other > than just loosely that the totals appear to work) > > Regards, > Adrien > > > On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam < > christopher@gmail.com> wrote: > > > > 2020-04-07 nightly available at > https://code.gnucash.org/builds/win32/maint/ > > flatpaks available at https://code.gnucash.org/builds/flatpak/maint/ > - use > > between 2020-04-04 and 2020-04-10 > > > > On Fri, 10 Apr 2020 at 01:38, Christopher Lam < > christopher@gmail.com> > > wrote: > > > >> This topic is about budgets. > >> > >> We now know that budgets are currently inherently flawed: they > *assume* > >> that sign-reversal = credit-accounts, and do not work well at all > with any > >> other sign-reversal option. In addition, there was a feature request > (bug > >> 781345) that introduced budget equity into the equation, and I still > do not > >> know whether a budget equity amount is a correct approach. > >> > >> In 4.x series there is a planned *fix* which will scan budget > amounts, > >> use heuristics to determine the most likely sign-reversal approach > used > >> during budget creation, internally unreverse the amounts, and > upgrade > the > >> datafile so that it cannot be damaged by 3.7 or earlier. > >> > >> Therefore 3.8 was the first release which could handle both old and > fixed > >> budget amounts. Unfortunately, the interpretation of budget signs > was/is > >> very difficult, which explained the switch to > >> asset/liability/equity/income/expense totals, which are impervious > to > >> budget signs. Unfortunately users
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
I just posted my first result and impression to the bug report, though I’m sure you saw that already. (this is more for the benefit of list readers not following the bug) The signs aren’t making sense, and the amounts aren’t adding up correctly. Regards, Adrien > On Apr 10, 2020 w15d101, at 5:59 AM, Christopher Lam > wrote: > > Next addendum: your existing budget data will behave well when reverse > balances=credit accounts, but the *featured* data will be stable with *any* > reverse balances global preference option. > > On Fri, 10 Apr 2020, 11:28 am Christopher Lam, > wrote: > >> >> >> On Fri, 10 Apr 2020, 10:20 am Christopher Lam, >> wrote: >> >>> Deadline is 11 April at noon GMT, so, about 34 hours from now. >>> >>> For both: *existing* datafile and especially *4.x-featured *datafile (in >>> bug report). >>> >>> Please test: >>> - creation of budget amounts >>> - use estimate to prefill cells >>> - all totals in all 5 account types A/L/Inc/Exp/Eq behave appropriately >>> >> >> Addendum this is not simply an arithmetic test; it *must also >> confirm that the totals and signs are sensible for the purpose of >> budgeting. Hence the difficulty of a one person coder to make it work. For >> example, we can budget a liability account regularly until we have enough >> deposit for a huge loan, or we can budget a liability account regularly for >> the loan repayments. IIUC both approaches are "valid" but the signs will be >> opposite. Other counter examples likely exist. >> >> - budget.scm report (optionally other budget reports but these are lower >>> priority) and especially difference column. >>> >>> On Fri, 10 Apr 2020 at 02:16, Adrien Monteleone < >>> adrien.montele...@lusfiber.net> wrote: >>> Thank You! This makes it so much easier to test. I’ll give the flatpak a spin and see what I find. I still haven’t set up a build environment for Mac yet. (and watching a recent thread on the subject makes it look daunting compared to Linux) This is a busy weekend for me though. What kind of time frame do you have and is there something in particular you’re looking to find. (other than just loosely that the totals appear to work) Regards, Adrien > On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam < christopher@gmail.com> wrote: > > 2020-04-07 nightly available at https://code.gnucash.org/builds/win32/maint/ > flatpaks available at https://code.gnucash.org/builds/flatpak/maint/ - use > between 2020-04-04 and 2020-04-10 > > On Fri, 10 Apr 2020 at 01:38, Christopher Lam < christopher@gmail.com> > wrote: > >> This topic is about budgets. >> >> We now know that budgets are currently inherently flawed: they *assume* >> that sign-reversal = credit-accounts, and do not work well at all with any >> other sign-reversal option. In addition, there was a feature request (bug >> 781345) that introduced budget equity into the equation, and I still do not >> know whether a budget equity amount is a correct approach. >> >> In 4.x series there is a planned *fix* which will scan budget amounts, >> use heuristics to determine the most likely sign-reversal approach used >> during budget creation, internally unreverse the amounts, and upgrade the >> datafile so that it cannot be damaged by 3.7 or earlier. >> >> Therefore 3.8 was the first release which could handle both old and fixed >> budget amounts. Unfortunately, the interpretation of budget signs was/is >> very difficult, which explained the switch to >> asset/liability/equity/income/expense totals, which are impervious to >> budget signs. Unfortunately users missed the "Remaining to Budget" facility. >> >> Therefore 3.9 was, during development, tested with >> https://github.com/Gnucash/gnucash/pull/630 and was deemed "good enough" >> to fix to restore the remaining to budget total. Unfortunately the >> liability budget amount issue was tested incorrectly. >> >> For a week, the git-maint contained a candidate fix, discussed in >> https://bugs.gnucash.org/show_bug.cgi?id=797659 -- but there is >> insufficient beta testing on the budgets for now. So, 3.10 will retain 3.9 >> behaviour unless the fix is fully tested. >> >> Conclusion: this is a call for beta testers, using the 2020-04-07 nightly >> (the only one with the fix), to test both their datafiles and the >> *4.x-featured* datafile attached in the bug report. Please *especially* >> test the liability and equity totals, both with existing datafile and >> featured datafile. >> >> Flame away. I will try to be available throughout the day for testing. >> Win32 users have only 1 build to test, Linux users may also build from >> 882fd22ca rather than
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Next addendum: your existing budget data will behave well when reverse balances=credit accounts, but the *featured* data will be stable with *any* reverse balances global preference option. On Fri, 10 Apr 2020, 11:28 am Christopher Lam, wrote: > > > On Fri, 10 Apr 2020, 10:20 am Christopher Lam, > wrote: > >> Deadline is 11 April at noon GMT, so, about 34 hours from now. >> >> For both: *existing* datafile and especially *4.x-featured *datafile (in >> bug report). >> >> Please test: >> - creation of budget amounts >> - use estimate to prefill cells >> - all totals in all 5 account types A/L/Inc/Exp/Eq behave appropriately >> > > Addendum this is not simply an arithmetic test; it *must also > confirm that the totals and signs are sensible for the purpose of > budgeting. Hence the difficulty of a one person coder to make it work. For > example, we can budget a liability account regularly until we have enough > deposit for a huge loan, or we can budget a liability account regularly for > the loan repayments. IIUC both approaches are "valid" but the signs will be > opposite. Other counter examples likely exist. > > - budget.scm report (optionally other budget reports but these are lower >> priority) and especially difference column. >> >> On Fri, 10 Apr 2020 at 02:16, Adrien Monteleone < >> adrien.montele...@lusfiber.net> wrote: >> >>> Thank You! This makes it so much easier to test. I’ll give the flatpak a >>> spin and see what I find. I still haven’t set up a build environment for >>> Mac yet. (and watching a recent thread on the subject makes it look >>> daunting compared to Linux) >>> >>> This is a busy weekend for me though. What kind of time frame do you >>> have and is there something in particular you’re looking to find. (other >>> than just loosely that the totals appear to work) >>> >>> Regards, >>> Adrien >>> >>> > On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam < >>> christopher@gmail.com> wrote: >>> > >>> > 2020-04-07 nightly available at >>> https://code.gnucash.org/builds/win32/maint/ >>> > flatpaks available at https://code.gnucash.org/builds/flatpak/maint/ >>> - use >>> > between 2020-04-04 and 2020-04-10 >>> > >>> > On Fri, 10 Apr 2020 at 01:38, Christopher Lam < >>> christopher@gmail.com> >>> > wrote: >>> > >>> >> This topic is about budgets. >>> >> >>> >> We now know that budgets are currently inherently flawed: they >>> *assume* >>> >> that sign-reversal = credit-accounts, and do not work well at all >>> with any >>> >> other sign-reversal option. In addition, there was a feature request >>> (bug >>> >> 781345) that introduced budget equity into the equation, and I still >>> do not >>> >> know whether a budget equity amount is a correct approach. >>> >> >>> >> In 4.x series there is a planned *fix* which will scan budget amounts, >>> >> use heuristics to determine the most likely sign-reversal approach >>> used >>> >> during budget creation, internally unreverse the amounts, and upgrade >>> the >>> >> datafile so that it cannot be damaged by 3.7 or earlier. >>> >> >>> >> Therefore 3.8 was the first release which could handle both old and >>> fixed >>> >> budget amounts. Unfortunately, the interpretation of budget signs >>> was/is >>> >> very difficult, which explained the switch to >>> >> asset/liability/equity/income/expense totals, which are impervious to >>> >> budget signs. Unfortunately users missed the "Remaining to Budget" >>> facility. >>> >> >>> >> Therefore 3.9 was, during development, tested with >>> >> https://github.com/Gnucash/gnucash/pull/630 and was deemed "good >>> enough" >>> >> to fix to restore the remaining to budget total. Unfortunately the >>> >> liability budget amount issue was tested incorrectly. >>> >> >>> >> For a week, the git-maint contained a candidate fix, discussed in >>> >> https://bugs.gnucash.org/show_bug.cgi?id=797659 -- but there is >>> >> insufficient beta testing on the budgets for now. So, 3.10 will >>> retain 3.9 >>> >> behaviour unless the fix is fully tested. >>> >> >>> >> Conclusion: this is a call for beta testers, using the 2020-04-07 >>> nightly >>> >> (the only one with the fix), to test both their datafiles and the >>> >> *4.x-featured* datafile attached in the bug report. Please >>> *especially* >>> >> test the liability and equity totals, both with existing datafile and >>> >> featured datafile. >>> >> >>> >> Flame away. I will try to be available throughout the day for testing. >>> >> Win32 users have only 1 build to test, Linux users may also build from >>> >> 882fd22ca rather than git-maint which has returned to 3.9 behaviour. >>> I'm >>> >> not sure how MacOS users can test. >>> >> >>> > ___ >>> > gnucash-devel mailing list >>> > gnucash-devel@gnucash.org >>> > https://lists.gnucash.org/mailman/listinfo/gnucash-devel >>> > >>> >>> >>> ___ >>> gnucash-devel mailing list >>> gnucash-devel@gnucash.org >>>
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
On Fri, 10 Apr 2020, 10:20 am Christopher Lam, wrote: > Deadline is 11 April at noon GMT, so, about 34 hours from now. > > For both: *existing* datafile and especially *4.x-featured *datafile (in > bug report). > > Please test: > - creation of budget amounts > - use estimate to prefill cells > - all totals in all 5 account types A/L/Inc/Exp/Eq behave appropriately > Addendum this is not simply an arithmetic test; it *must also confirm that the totals and signs are sensible for the purpose of budgeting. Hence the difficulty of a one person coder to make it work. For example, we can budget a liability account regularly until we have enough deposit for a huge loan, or we can budget a liability account regularly for the loan repayments. IIUC both approaches are "valid" but the signs will be opposite. Other counter examples likely exist. - budget.scm report (optionally other budget reports but these are lower > priority) and especially difference column. > > On Fri, 10 Apr 2020 at 02:16, Adrien Monteleone < > adrien.montele...@lusfiber.net> wrote: > >> Thank You! This makes it so much easier to test. I’ll give the flatpak a >> spin and see what I find. I still haven’t set up a build environment for >> Mac yet. (and watching a recent thread on the subject makes it look >> daunting compared to Linux) >> >> This is a busy weekend for me though. What kind of time frame do you have >> and is there something in particular you’re looking to find. (other than >> just loosely that the totals appear to work) >> >> Regards, >> Adrien >> >> > On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam < >> christopher@gmail.com> wrote: >> > >> > 2020-04-07 nightly available at >> https://code.gnucash.org/builds/win32/maint/ >> > flatpaks available at https://code.gnucash.org/builds/flatpak/maint/ - >> use >> > between 2020-04-04 and 2020-04-10 >> > >> > On Fri, 10 Apr 2020 at 01:38, Christopher Lam < >> christopher@gmail.com> >> > wrote: >> > >> >> This topic is about budgets. >> >> >> >> We now know that budgets are currently inherently flawed: they *assume* >> >> that sign-reversal = credit-accounts, and do not work well at all with >> any >> >> other sign-reversal option. In addition, there was a feature request >> (bug >> >> 781345) that introduced budget equity into the equation, and I still >> do not >> >> know whether a budget equity amount is a correct approach. >> >> >> >> In 4.x series there is a planned *fix* which will scan budget amounts, >> >> use heuristics to determine the most likely sign-reversal approach used >> >> during budget creation, internally unreverse the amounts, and upgrade >> the >> >> datafile so that it cannot be damaged by 3.7 or earlier. >> >> >> >> Therefore 3.8 was the first release which could handle both old and >> fixed >> >> budget amounts. Unfortunately, the interpretation of budget signs >> was/is >> >> very difficult, which explained the switch to >> >> asset/liability/equity/income/expense totals, which are impervious to >> >> budget signs. Unfortunately users missed the "Remaining to Budget" >> facility. >> >> >> >> Therefore 3.9 was, during development, tested with >> >> https://github.com/Gnucash/gnucash/pull/630 and was deemed "good >> enough" >> >> to fix to restore the remaining to budget total. Unfortunately the >> >> liability budget amount issue was tested incorrectly. >> >> >> >> For a week, the git-maint contained a candidate fix, discussed in >> >> https://bugs.gnucash.org/show_bug.cgi?id=797659 -- but there is >> >> insufficient beta testing on the budgets for now. So, 3.10 will retain >> 3.9 >> >> behaviour unless the fix is fully tested. >> >> >> >> Conclusion: this is a call for beta testers, using the 2020-04-07 >> nightly >> >> (the only one with the fix), to test both their datafiles and the >> >> *4.x-featured* datafile attached in the bug report. Please *especially* >> >> test the liability and equity totals, both with existing datafile and >> >> featured datafile. >> >> >> >> Flame away. I will try to be available throughout the day for testing. >> >> Win32 users have only 1 build to test, Linux users may also build from >> >> 882fd22ca rather than git-maint which has returned to 3.9 behaviour. >> I'm >> >> not sure how MacOS users can test. >> >> >> > ___ >> > 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 >> > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Okay, I’ll see what I can do. First, is to figure out how to get that flatpak installed from that link. I’ve never messed with Flatpaks, but I’m guessing I need to add a repo and then I should be able to install. Researching now... Regards, Adrien > On Apr 9, 2020 w15d100, at 9:20 PM, Christopher Lam > wrote: > > Deadline is 11 April at noon GMT, so, about 34 hours from now. > > For both: existing datafile and especially 4.x-featured datafile (in bug > report). > > Please test: > - creation of budget amounts > - use estimate to prefill cells > - all totals in all 5 account types A/L/Inc/Exp/Eq behave appropriately > - budget.scm report (optionally other budget reports but these are lower > priority) and especially difference column. > > On Fri, 10 Apr 2020 at 02:16, Adrien Monteleone > wrote: > Thank You! This makes it so much easier to test. I’ll give the flatpak a spin > and see what I find. I still haven’t set up a build environment for Mac yet. > (and watching a recent thread on the subject makes it look daunting compared > to Linux) > > This is a busy weekend for me though. What kind of time frame do you have and > is there something in particular you’re looking to find. (other than just > loosely that the totals appear to work) > > Regards, > Adrien > > > On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam > > wrote: > > > > 2020-04-07 nightly available at https://code.gnucash.org/builds/win32/maint/ > > flatpaks available at https://code.gnucash.org/builds/flatpak/maint/ - use > > between 2020-04-04 and 2020-04-10 > > > > On Fri, 10 Apr 2020 at 01:38, Christopher Lam > > wrote: > > > >> This topic is about budgets. > >> > >> We now know that budgets are currently inherently flawed: they *assume* > >> that sign-reversal = credit-accounts, and do not work well at all with any > >> other sign-reversal option. In addition, there was a feature request (bug > >> 781345) that introduced budget equity into the equation, and I still do not > >> know whether a budget equity amount is a correct approach. > >> > >> In 4.x series there is a planned *fix* which will scan budget amounts, > >> use heuristics to determine the most likely sign-reversal approach used > >> during budget creation, internally unreverse the amounts, and upgrade the > >> datafile so that it cannot be damaged by 3.7 or earlier. > >> > >> Therefore 3.8 was the first release which could handle both old and fixed > >> budget amounts. Unfortunately, the interpretation of budget signs was/is > >> very difficult, which explained the switch to > >> asset/liability/equity/income/expense totals, which are impervious to > >> budget signs. Unfortunately users missed the "Remaining to Budget" > >> facility. > >> > >> Therefore 3.9 was, during development, tested with > >> https://github.com/Gnucash/gnucash/pull/630 and was deemed "good enough" > >> to fix to restore the remaining to budget total. Unfortunately the > >> liability budget amount issue was tested incorrectly. > >> > >> For a week, the git-maint contained a candidate fix, discussed in > >> https://bugs.gnucash.org/show_bug.cgi?id=797659 -- but there is > >> insufficient beta testing on the budgets for now. So, 3.10 will retain 3.9 > >> behaviour unless the fix is fully tested. > >> > >> Conclusion: this is a call for beta testers, using the 2020-04-07 nightly > >> (the only one with the fix), to test both their datafiles and the > >> *4.x-featured* datafile attached in the bug report. Please *especially* > >> test the liability and equity totals, both with existing datafile and > >> featured datafile. > >> > >> Flame away. I will try to be available throughout the day for testing. > >> Win32 users have only 1 build to test, Linux users may also build from > >> 882fd22ca rather than git-maint which has returned to 3.9 behaviour. I'm > >> not sure how MacOS users can test. > >> > > ___ > > 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 ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Deadline is 11 April at noon GMT, so, about 34 hours from now. For both: *existing* datafile and especially *4.x-featured *datafile (in bug report). Please test: - creation of budget amounts - use estimate to prefill cells - all totals in all 5 account types A/L/Inc/Exp/Eq behave appropriately - budget.scm report (optionally other budget reports but these are lower priority) and especially difference column. On Fri, 10 Apr 2020 at 02:16, Adrien Monteleone < adrien.montele...@lusfiber.net> wrote: > Thank You! This makes it so much easier to test. I’ll give the flatpak a > spin and see what I find. I still haven’t set up a build environment for > Mac yet. (and watching a recent thread on the subject makes it look > daunting compared to Linux) > > This is a busy weekend for me though. What kind of time frame do you have > and is there something in particular you’re looking to find. (other than > just loosely that the totals appear to work) > > Regards, > Adrien > > > On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam < > christopher@gmail.com> wrote: > > > > 2020-04-07 nightly available at > https://code.gnucash.org/builds/win32/maint/ > > flatpaks available at https://code.gnucash.org/builds/flatpak/maint/ - > use > > between 2020-04-04 and 2020-04-10 > > > > On Fri, 10 Apr 2020 at 01:38, Christopher Lam > > > wrote: > > > >> This topic is about budgets. > >> > >> We now know that budgets are currently inherently flawed: they *assume* > >> that sign-reversal = credit-accounts, and do not work well at all with > any > >> other sign-reversal option. In addition, there was a feature request > (bug > >> 781345) that introduced budget equity into the equation, and I still do > not > >> know whether a budget equity amount is a correct approach. > >> > >> In 4.x series there is a planned *fix* which will scan budget amounts, > >> use heuristics to determine the most likely sign-reversal approach used > >> during budget creation, internally unreverse the amounts, and upgrade > the > >> datafile so that it cannot be damaged by 3.7 or earlier. > >> > >> Therefore 3.8 was the first release which could handle both old and > fixed > >> budget amounts. Unfortunately, the interpretation of budget signs was/is > >> very difficult, which explained the switch to > >> asset/liability/equity/income/expense totals, which are impervious to > >> budget signs. Unfortunately users missed the "Remaining to Budget" > facility. > >> > >> Therefore 3.9 was, during development, tested with > >> https://github.com/Gnucash/gnucash/pull/630 and was deemed "good > enough" > >> to fix to restore the remaining to budget total. Unfortunately the > >> liability budget amount issue was tested incorrectly. > >> > >> For a week, the git-maint contained a candidate fix, discussed in > >> https://bugs.gnucash.org/show_bug.cgi?id=797659 -- but there is > >> insufficient beta testing on the budgets for now. So, 3.10 will retain > 3.9 > >> behaviour unless the fix is fully tested. > >> > >> Conclusion: this is a call for beta testers, using the 2020-04-07 > nightly > >> (the only one with the fix), to test both their datafiles and the > >> *4.x-featured* datafile attached in the bug report. Please *especially* > >> test the liability and equity totals, both with existing datafile and > >> featured datafile. > >> > >> Flame away. I will try to be available throughout the day for testing. > >> Win32 users have only 1 build to test, Linux users may also build from > >> 882fd22ca rather than git-maint which has returned to 3.9 behaviour. I'm > >> not sure how MacOS users can test. > >> > > ___ > > 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 > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
Thank You! This makes it so much easier to test. I’ll give the flatpak a spin and see what I find. I still haven’t set up a build environment for Mac yet. (and watching a recent thread on the subject makes it look daunting compared to Linux) This is a busy weekend for me though. What kind of time frame do you have and is there something in particular you’re looking to find. (other than just loosely that the totals appear to work) Regards, Adrien > On Apr 9, 2020 w15d100, at 9:10 PM, Christopher Lam > wrote: > > 2020-04-07 nightly available at https://code.gnucash.org/builds/win32/maint/ > flatpaks available at https://code.gnucash.org/builds/flatpak/maint/ - use > between 2020-04-04 and 2020-04-10 > > On Fri, 10 Apr 2020 at 01:38, Christopher Lam > wrote: > >> This topic is about budgets. >> >> We now know that budgets are currently inherently flawed: they *assume* >> that sign-reversal = credit-accounts, and do not work well at all with any >> other sign-reversal option. In addition, there was a feature request (bug >> 781345) that introduced budget equity into the equation, and I still do not >> know whether a budget equity amount is a correct approach. >> >> In 4.x series there is a planned *fix* which will scan budget amounts, >> use heuristics to determine the most likely sign-reversal approach used >> during budget creation, internally unreverse the amounts, and upgrade the >> datafile so that it cannot be damaged by 3.7 or earlier. >> >> Therefore 3.8 was the first release which could handle both old and fixed >> budget amounts. Unfortunately, the interpretation of budget signs was/is >> very difficult, which explained the switch to >> asset/liability/equity/income/expense totals, which are impervious to >> budget signs. Unfortunately users missed the "Remaining to Budget" facility. >> >> Therefore 3.9 was, during development, tested with >> https://github.com/Gnucash/gnucash/pull/630 and was deemed "good enough" >> to fix to restore the remaining to budget total. Unfortunately the >> liability budget amount issue was tested incorrectly. >> >> For a week, the git-maint contained a candidate fix, discussed in >> https://bugs.gnucash.org/show_bug.cgi?id=797659 -- but there is >> insufficient beta testing on the budgets for now. So, 3.10 will retain 3.9 >> behaviour unless the fix is fully tested. >> >> Conclusion: this is a call for beta testers, using the 2020-04-07 nightly >> (the only one with the fix), to test both their datafiles and the >> *4.x-featured* datafile attached in the bug report. Please *especially* >> test the liability and equity totals, both with existing datafile and >> featured datafile. >> >> Flame away. I will try to be available throughout the day for testing. >> Win32 users have only 1 build to test, Linux users may also build from >> 882fd22ca rather than git-maint which has returned to 3.9 behaviour. I'm >> not sure how MacOS users can test. >> > ___ > 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
Re: [GNC-dev] About budgets in 3.8, 3.9 and 3.10
2020-04-07 nightly available at https://code.gnucash.org/builds/win32/maint/ flatpaks available at https://code.gnucash.org/builds/flatpak/maint/ - use between 2020-04-04 and 2020-04-10 On Fri, 10 Apr 2020 at 01:38, Christopher Lam wrote: > This topic is about budgets. > > We now know that budgets are currently inherently flawed: they *assume* > that sign-reversal = credit-accounts, and do not work well at all with any > other sign-reversal option. In addition, there was a feature request (bug > 781345) that introduced budget equity into the equation, and I still do not > know whether a budget equity amount is a correct approach. > > In 4.x series there is a planned *fix* which will scan budget amounts, > use heuristics to determine the most likely sign-reversal approach used > during budget creation, internally unreverse the amounts, and upgrade the > datafile so that it cannot be damaged by 3.7 or earlier. > > Therefore 3.8 was the first release which could handle both old and fixed > budget amounts. Unfortunately, the interpretation of budget signs was/is > very difficult, which explained the switch to > asset/liability/equity/income/expense totals, which are impervious to > budget signs. Unfortunately users missed the "Remaining to Budget" facility. > > Therefore 3.9 was, during development, tested with > https://github.com/Gnucash/gnucash/pull/630 and was deemed "good enough" > to fix to restore the remaining to budget total. Unfortunately the > liability budget amount issue was tested incorrectly. > > For a week, the git-maint contained a candidate fix, discussed in > https://bugs.gnucash.org/show_bug.cgi?id=797659 -- but there is > insufficient beta testing on the budgets for now. So, 3.10 will retain 3.9 > behaviour unless the fix is fully tested. > > Conclusion: this is a call for beta testers, using the 2020-04-07 nightly > (the only one with the fix), to test both their datafiles and the > *4.x-featured* datafile attached in the bug report. Please *especially* > test the liability and equity totals, both with existing datafile and > featured datafile. > > Flame away. I will try to be available throughout the day for testing. > Win32 users have only 1 build to test, Linux users may also build from > 882fd22ca rather than git-maint which has returned to 3.9 behaviour. I'm > not sure how MacOS users can test. > ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
[GNC-dev] About budgets in 3.8, 3.9 and 3.10
This topic is about budgets. We now know that budgets are currently inherently flawed: they *assume* that sign-reversal = credit-accounts, and do not work well at all with any other sign-reversal option. In addition, there was a feature request (bug 781345) that introduced budget equity into the equation, and I still do not know whether a budget equity amount is a correct approach. In 4.x series there is a planned *fix* which will scan budget amounts, use heuristics to determine the most likely sign-reversal approach used during budget creation, internally unreverse the amounts, and upgrade the datafile so that it cannot be damaged by 3.7 or earlier. Therefore 3.8 was the first release which could handle both old and fixed budget amounts. Unfortunately, the interpretation of budget signs was/is very difficult, which explained the switch to asset/liability/equity/income/expense totals, which are impervious to budget signs. Unfortunately users missed the "Remaining to Budget" facility. Therefore 3.9 was, during development, tested with https://github.com/Gnucash/gnucash/pull/630 and was deemed "good enough" to fix to restore the remaining to budget total. Unfortunately the liability budget amount issue was tested incorrectly. For a week, the git-maint contained a candidate fix, discussed in https://bugs.gnucash.org/show_bug.cgi?id=797659 -- but there is insufficient beta testing on the budgets for now. So, 3.10 will retain 3.9 behaviour unless the fix is fully tested. Conclusion: this is a call for beta testers, using the 2020-04-07 nightly (the only one with the fix), to test both their datafiles and the *4.x-featured* datafile attached in the bug report. Please *especially* test the liability and equity totals, both with existing datafile and featured datafile. Flame away. I will try to be available throughout the day for testing. Win32 users have only 1 build to test, Linux users may also build from 882fd22ca rather than git-maint which has returned to 3.9 behaviour. I'm not sure how MacOS users can test. ___ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
