Re: double-entry bookkeeping unneeded?

Thomas Gagne wrote:
topmind wrote:
Thomas Gagne wrote:

topmind wrote:

Thomas Gagne wrote:


I've written multiple financial OLTP systems and can confidently say
there's no such thing as "john bill 5".

A transaction system must be able to record:

Check for $10.
Cash for $20.
Deposit to checking $15.
Payment to line-of-credit: $15.


These are 4 *separate* transactions, aren't they? It is still:

A, B, 10.00
C, D, 20.00
E, F, 15.00
G, H, 15.00


Think of it as:
A: $10
B: $20
C: $15
D: $15


What are the letters here? In my example, they were account codes, such
as "cash", "accounts payable", etc.

The same--they're accounts.

<snip>
Isn't it: A = L + E rather than "= 0"? Summing to zero is not enough.

It is enough. In fact, its how accounting is done. 0 = debits +
credits. If everything your accounting transaction does adds to 0,
you're in good shape. Money going into one account must come from
another account. Adding 100 to a credit account and adding 100 to a
debit account = 0.

There is no such thing as a "debit account" and "credit account".
Perhaps we are at a semantics snag.

Adding 100 to a debit account and subtracting 100
from a debit account also = 0. That's good, too.

Anyhow, a brainstormer at c2.com figured it out:

http://c2.com/cgi/wiki?AccountingModeling

Quote:

Assume Balance

I think I finally figured this out. It is a matter of what you do to
both sides. Example table:

From To Amt.
---- ---- -----
A001 E001 50.00
A002 L002 10.00
E003 L002 20.00


The letters of the account codes indicate what "kind" of account it is
(from "A=E+L"). This is not proposing some kind of actual letter coding
(HungarianNotation), but letter prefixing is merely used to simplify
the example. In practice the account table would track the kind, not a
letter prefix. This just makes the example more visual.

In the 50.00 transaction, the amount is assumed to be added to both
A001 and to E001. The equation is still balanced. Same with 10.00. Now
with the 20.00, it is assumed to be reducing E003 by 20 and increasing
L002 by 20. Thus, the "E + L" side stays the same in total, satisfying
the equation.

This technique "assumes balance". You cannot put a wrong combination
in, at least not in a technical sense (assuming valid account codes).
If the accounts are not the ones you intended, that is a data-entry
error on your part. But, it still balances dispite any such errors. You
cannot go wrong. Any "problems" encountered you can rightfully blame on
the data entry person. It dumps the responsibility on the user; that's
why I dig it.

This is the interpretation table I believe:

From To Arith.-Type
-- -- -----
A A -/+ (subtract value from "A-from" account and add it to
"A-to" account)
A E +/+
A L +/+
E A +/+
E E -/+
E L -/+
L A +/+
L E -/+
L L -/+

(end quote)

-T-



--
Visit <http://blogs.instreamfinancial.com/anything.php>
to read my rants on technology and the finance industry.

.

Relevant Pages

  • Re: Design Question - Accounts/Transactions
    ... 'Balance' column to the transaction, ... Further, when you need to compute the balance for an account, you only need to scan the part of the table for that account. ... A trigger is certainly a possibility. ...
    (microsoft.public.sqlserver.programming)
  • Re: New Method for Authenticated Public Key Exchange without Digital Certificates
    ... have the account disabled. ... then the next time you do a financial transaction ... ... eventually arrives at your financial institution ... ... in order to do credit card transactions, the merchant has to ...
    (sci.crypt)
  • Re: ComboBox Problem... Please, help me out!
    ... and tblTransDtl (transaction detail). ... You also have tables for SheetRegister and Account. ... Every sheet belongs to an only single ...
    (microsoft.public.access.formscoding)
  • Re: (LONG) More newbie questions on constructor/set+get methods
    ... Seeing as you couldn't figure out how to access your transAction method ... > * a transAction method, a getBalance method, and a setBalance method. ... > * to compute the final balance for each account. ... > * the initial and final balances for each account. ...
    (comp.lang.java.help)
  • (LONG) More newbie questions on constructor/set+get methods
    ... I set the starting balance to 0. ... I input the "initial" balance (that is, the opening account balance ... I immediately assign it to 'transaction'. ... I set up my calculation method. ...
    (comp.lang.java.help)