> On Aug 13, 2019, at 12:12 AM, Christopher Lam <[email protected]> > wrote: > > Maybe I'm being thick here, but it's still not easy. We need to start with > the knowledge that *internally* income amounts are negative -- after all they > usually balance with positive asset amounts. Also, liability amounts are also > internally negative, but no one seems to have a problem with that.
Maybe I’m not understanding something, but... I don’t see how this is an issue. (Equity is also negative in this case) Note that they are only stored as negatives to facilitate addition for all operations for simplicity. Always keep the accounting equation in mind and don’t do something non-sensical with the terms. If you reverse signs before calculation, that means you can’t use only addition operations. You’d have to change the relevant operations of the calculation to make the equation still balance. I haven’t tried to grok this report’s code yet, but I can’t see how such an approach would be any fun to work out. > > Second, the Transaction Report historically needs to handle multiple types of > grouping and sorting -- not only account-name, but also other-account-name. > Running a TR with sort=other-account-name may not be that common, but is > still supported. Good to know. I don’t see any reason to change this. > > Third, we can select both income and expense accounts for reporting. If > during a period I earn $100 and spend $80, I expect the grand total to be $20 > (or -$20) rather than $180. Conversely if we select both asset and liability > accounts, we'd expect the grand-total to be a net-worth-type amount. Again, as long as the sign reversal is done merely for display purposes, this shouldn’t be an issue. You’d get a retained earnings/net income result if you choose income and expense accounts and you’d get a net-worth result if you choose asset and liability. (discounting retained earnings and other equity that is) I think that is called the "liquidity ratio" in such a case. > > The TR internally will: > 1) get all splits from all specified accounts > 2) sort them accordingly - typically stable-sort by account-name (or > other-account-name) and date. > 3) keep a tally of subtotals, adding split-amounts which are currently > negative for income amounts. > 4) add split details onto table. When the sort-criteria (e.g. account-name) > changes between rows, render the subtotals. 5) Reverse the signs of the subtotals and splits when printing them on the report according to the preference. > > How to design a subtotal strategy that handles all possibilities as above? Do > we want the *split* amounts to be negative for expenses and liability? You want to follow the preference but not as part of the calculation or that can get messy as noted above. > I don't know. A better strategy can be used as along as it can handle all gnc > peculiarities as above. I would hope that the TR can produce a useful output, > with subtotals & grand-totals which are consistent irrespective of the global > sign-reversing strategy. > > Anyone wishing to try the old strategy, can patch trep-engine.scm as follows: > (map (lambda (cell) > (let ((cell-monetary (vector-ref cell 0)) > + (reverse? (and (vector-ref cell 1) reversible-account?)) > (subtotal? (vector-ref cell 2))) > - (and subtotal? cell-monetary))) > + (and subtotal? > + (if reverse? > + (gnc:monetary-neg cell-monetary) > + cell-monetary)))) > cells))) I guess it is time for me to dive into scheme. But it looks like sign reversal is happening before each split is added to the subtotal. That is the problem. Am I not reading that correctly? Regards, Adrien _______________________________________________ gnucash-user mailing list [email protected] To update your subscription preferences or to unsubscribe: https://lists.gnucash.org/mailman/listinfo/gnucash-user If you are using Nabble or Gmane, please see https://wiki.gnucash.org/wiki/Mailing_Lists for more information. ----- Please remember to CC this list on all your replies. You can do this by using Reply-To-List or Reply-All.
