Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Algorithm for splitting payment across invoices
Message
 
To
17/09/2007 13:55:54
Dragan Nedeljkovich (Online)
Now officially retired
Zrenjanin, Serbia
General information
Forum:
Visual FoxPro
Category:
Other
Environment versions
Visual FoxPro:
VFP 9 SP1
OS:
Windows XP SP2
Miscellaneous
Thread ID:
01254618
Message ID:
01254982
Views:
12
>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.
>
>Generally, I've found this whole thing annoying - why do the accountants bother to know which invoices are paid and which are not? A debt is a debt is a debt. The total owed is a total owed, and if they need to calculate an interest on it, they only need to calculate it on the running total. But them being pesky as they usually are, there was a demand for this routine, so I eventually got to be the software hero of the week (several times :) when I got this to work. Although I think it's a bit pointless.
>
>Um, yes, there was a legal obligation for any entity to compare the so-called "extract of open items", i.e. to match their reports on unpaid bills - customer with the supplier. So they did have to do this binding at least once a year, and they soon learned that the more often they run my autobind routine, the easier their life gets, as these reports get to be shorter and shorter, and they look smart and diligent in the eyes of their business partners.

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.
eCost.com continues to rip people off
Check their rating at ResellerRatings.com
Previous
Next
Reply
Map
View

Click here to load this message in the networking platform