>Yes, I know. There is a subjective element to all of this that we can't ignore. I am doing it as I explained and this seems fine with them but in the initial implementations, they are pointing out that they need a little more traceability from the credit memo back to the original invoice. This is easy enough to provide, so I'm providing it, but it still requires a change of mindset and tradition on their part (so far the have been fairly willing to change if I provide the info they need to keep track of everything, but sometimes they whine more than other times <g>).

When I was doing accounting (in another decade, in some other countries) we tried to keep things simple and elegant - and to keep them working regardless of their particulars. A record can be either a credit or a debit; I don't really care whether it's an invoice, invoice cancellation, payment, advance payment, payment cancellation, whatever. It's either credit or debit, and it has two dates: date when it happened, and the date it was posted. Some records may have due dates, and may relate to entities outside the bare ledger (like suppliers, buyers, loan issuers, loan payers, our workers), but that doesn't change their nature. They still are credit xor debit, and have two historic dates, and maybe one future date.

As for the trace and what pays for what, we used binding, simulating what the accountants were doing on paper. In the simplest case, one invoice would bind with a payment, or with a cancellation. Or multiple invoices would bind with a payment. Or there would be other records (interest charges, loan payments, maturity of anything) which would cancel out in the same manner. They'd all be connected in a bind (a simple humble integer written into a ledger.binding field) and thus out of the picture. I got this process mostly automated (by mid 1990, IIRC). A year later it was already quite optimized, and would automatically bind about 70% of records. Then code was added to finish the rest manually (in a coded browse window), to allow for rounding (some people never ever made a payment which ended with decimals), to check for the validity of bindings etc.

The whole point here is that, other than writing the binding number, nothing touched the invoice or payment record - all of their other fields remained completely intact. Their nature and content never changed. You can imagine how "the invoice now becomes an invoice credit" makes my skin crawl on teeth edge (or whatever is the expression). Invoice is a credit when it's from my supplier, that's his credit and my debit; it's my credit when I issue it to a customer - then it becomes his debit. Anything contrary to that would create a firing squad composed of a dozen of fierce accountants I eventually befriended over the years (but only eventually and not without a fight ;).