Derek Atkins wrote:
gncInvoice.cin particular the code that implements the invoice and payment processing and the balancing code to make sure payment are split across invoices properly.
I have found that the current implementation of this particular functionality doesn't work that well, as it assumes payments will always follow invoices/bills.
In the invoice world this is usually the case, but in the case of bills, the payment will often be entered first (the bank statement gets reconciled to ensure the customer paid before shipping the goods, and both the payment from the customer and the payment to the supplier is captured in the process), the supplier takes their time getting their bill to you so the bill is captured long after the payment was made.
On top of this, you may have captured the bills in a different order to the captured payments, so the payment splits end up not making much sense. Then, if you unpost a bill to correct a mistake, it further complicates things, because now the bill total may be different and the payment splits make even less sense.
This seems to affect the payable and receivable aging, I have often seen cases of where payable aging says the vendor is owed X, but the final total on the account is zero. As a result I have learned to ignore payable aging entirely.
Calculating which invoices are paid and which aren't is a non trivial process, for my purposes I implemented a way to flag an invoice as unpaid if all the payments made to date by the supplier don't exceed the sum of all invoices up until that invoice. Getting that right gave me a headache.
I suspect that after an invoice or a payment is posted (or reposted) for an invoice or bill, what should probably happen is that the flags indicating paid / unpaid get reset from scratch each time. This way inaccuracies can get smoothed out over time.
In the XML tree, a transaction that belongs to an invoice has slots attached with additional information saying a) that the transaction is an invoice or a payment (from "trans-txn-type"), and b) which invoice this transaction is associated with.This has nothing to do with the data in the XML file. I honestly forget why the txn-type was created, and I dont remember where it's used.
The data is respected though - if you manually change the sign, load it into gnucash and save it again, the invoice stays an invoice, and the payment stays a payment.
Regards, Graham --
smime.p7s
Description: S/MIME Cryptographic Signature
_______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
