GNOME Bugzilla – Bug 143418
Need a new lot policy to handle invoice + payments
Last modified: 2018-06-29 20:43:48 UTC
As mentioned in bug #139677 we could use a new policy to handle invoices/payments in AR and AP accounts. In these accounts the invariant is that each lot contains exactly zero or one invoice and any number of payments against that invoice. Over-payments are "saved" and then applied to future invoices. Note that there is another factor involved here, which is the "owner" (see gncOwnerFromLot() in the business code). Payments can only be applied to invoices by the same owner (and indeed payments should be applyable to a specific invoice, but that's not implemented yet). What this means is that over-payments need to go into a new lot (to remember the owner). For the history from bug #139677 ... comment 4: 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. comment 7: 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).
Oh, I should add that currently all the logic is in src/business/business-core/gncInvoice.c, in particular in the post-invoice and post-payment functions.
Derek, still an issue? This bug is assigned to linas - do you want to take it? Change it back to NEW?
I believe it is, yes. The lot code doesn't understand the GncInvoice policy so if you scrub an AR account it could do things... wrong.
GnuCash bug tracking has moved to a new Bugzilla host. The new URL for this bug is https://bugs.gnucash.org/show_bug.cgi?id=143418. Please continue processing the bug there and please update any external references or bookmarks.