GNOME Bugzilla – Bug 139677
Cap gains computation/scrubber errors out on Business Transactions
Last modified: 2018-06-29 20:42:44 UTC
Use the business features to create some business transactions. In particular create some client invoices and vendor bills. Make sure some of them are paid, and some are not. When you close gnucash, it spews a bunch of errors: ** (gnucash:25325): CRITICAL **: Error: xaccSplitComputeCapGains(): Malformed Lot! (too thin!) Perhaps it should see if the commodity of the LOT and the commodity of the Account are the same and, if so, DON'T try to compute capital gains?
Three notes: -- cap gains shouldn't be computed if transaction currency and lot commodity are the same. -- The 'too thin' message seems to be coming from the fact that a lot got overpaid by a few pennies, and now the scrub routines are trying to steal a few pennies from elsewhere, and can't. (???? I don't quite get it. ???) -- Lots shouldn't be scrubbed during shutdown anyway. They're being scrubbed 'by accident', due to the current mis-design of the shutdown proceedure.
There are patches now in CVS head to fix the mixed-currency errors that 'make check TESTS=test-lots' complains about. However, test-lots is still failing, appearently due to bad math in gnc_numeric!
For example 1151724258946/52524 times -1347734904569/61463 = 742605974375755662/3228282612 when gnc_numeric_mul (... , ... GNC_DENOM_AUTO, GNC_RND_NEVER); is used. The sign is clearly wrong.
Re: comment #3 ... gnc_numeric has known problems with large numbers of high precision, however I do not know why _this_ is failing... Re: comment #1 ... The "too thin" message is coming from a couple potential sources: 1) If multiple invoices are posted for the same owner (customer, vendor, etc), a single "payment" can process all of them. This is implemented as a single transaction to the oldest invoice for the full amount, and then "balancing transactions" down the line until there is no more payment (or no more invoices). 2) If there is an extra payment, it's put into a lot of its own (assigned to the particular owner). When the next invoice comes in for that owner it's applied to that lot/payment, and any leftover payment is then moved into a new lot just like #1 The invariant is that lots always apply to invoices. There can be exactly zero or one invoices in a lot. All the rest of the transactions are payment or "adjustment" transactions. Adjustment transactions move money from one lot to another within the same account/owner. Payment transactions "pay" invoices from another account.
Actually, looking at those numbers, of course that's not going to work. n1 * n2 == 1151724258946 * -1347734904569 == -1552218984220389554524274 (n1*n2) but the max integer of a longlong is 2^63 == 9223372036854775808. Notice that abs(n1*n2) >> 2^63. That's why this math is failing.
I've changed the gnc-numeric code to detect overflow. The code now passes the test 1 out of 4 times, and fails with overflow 3 out of 4 ... the test should be changed to not pass extreme values in ... Am changing sttus to 'fixed awaiting test' reopen if the business-core message persists.
Re: overpayments and how they are grouped into lots, if you want to change that behaviour, open a new bug and asssign to me (and cut-n-paste comments from above to new bug). I think it might not be too hard to create a new "policy" (see src/engine/policy.h) to always make lots with a particular sign for the opening balance, so that overpayments never start new lots, and instead are applied forward to new charges. (If you do open that bug, cut-n-paste these coments in too).
Looks like the business-core messages are gone. Thanks. I'll open another bug report for the payments issues...
GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=139677. Please update any external references or bookmarks.