>>For partial payments you can always split the debited amount into the paid and unpaid part. My system works when the total amount of partial payments matches the total amount of some invoices - where the number of each may be "any or more". For a single invoice (one among the many) and a payment that doesn't match any invoice, the user has a choice to apply it against any or not at all.
>>

>I'm not sure we're on the same wavelength. If a customer pays $3989.31 and has outstanding invoices of $1200, $2500, $1800, and $950, there is no way to determine where the money should be applied. You could pay the first one and the second one and then pay $289.31 on the third one, but what if they intended to pay only $1000 on the first one and $489.31 on third one? There are just too many variations to figure it out. The user has to manually indicate which invoices are paid and how much on each one. My algorithm only works when each invoice is paid in full (for instance, they send $3950 and my algorithm figures out that they are paying the first, third, and fourth invoice so the user doesn't have to enter that). I think you may be doing somethig a little different.

The times were different, country was different, and rules were different when I was writing that. All invoices were equal. It absolutely didn't matter which one was paid, because of that - the conditions were the same across the board. There weren't no special clauses on one invoice that wouldn't be on the other.

There was also on-the-fly binding during payment entry; if the invoice was stated on the payment, then it would bind automatically (if paid in full) or offer to bind partially, which was done in a, well, AfterSave code.

Nowadays yes, it's more complicated, if the answer to the questions "which invoices are paid by this" matters.