Level Extreme platform
Subscription
Corporate profile
Products & Services
Support
Legal
Français
Accounting system techniques and principals
Message
 
To
17/06/2008 16:25:08
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
Network:
Novell 6.x
Database:
Visual FoxPro
Miscellaneous
Thread ID:
01324672
Message ID:
01324925
Views:
13
>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 ;).

I'm still a little unclear. If an invoice is overpaid by $10, does that invoice now become a credit for $10? I do change the original invoice in that I change the balance, taking off whatever was paid (full invoice amount or partial). I just don't let the invoice balance go negative (which turns an invoice into a credit). I create a separate invoice (a credit invoice) for any amount overpaid.
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