Re: double-entry bookkeeping unneeded?



In article <nYCdnXTcTrYAtwvYnZ2dnUVZ_s2vnZ2d@xxxxxxxxxxx>,
"Nick Malik [Microsoft]" <nickmalik@xxxxxxxxxxxxxxxxxx> wrote:

The problem with this system is that you will end up with arbitrary parts of
transactions that don't make any sense.

No, the problem is that your system has already discarded too much
information from the start.

Example:
transaction 12345
debit $10,000 from cash receipts
debit $2,000 from credit-memo
debit $1,000 from marketing program
credit $900 shipping
credit $1200 sales incentive
credit $9,800 inventory
credit $1,100 revenue

What a terrible example. Look, yes, that low level of detail might have
made sense before we had computers but the fact is we have systems that
can deal with billions of objects and cross reference them with ease.

Clearly, the transaction balances. Also clearly, none of the credit amounts
are the same as the debit amounts. So, to make this work, using your
system, you would have to "randomly" allocate balancing amounts from one
account to the other, breaking input and output amounts. One example
break-up is below. Note: it is NOT POSSIBLE, using this particular
transaction, to create a series of records using your system that doesn't
create this effect:

It is not only possible, it is essentially necessary. Things don't make
sense based on your example because you've set up no boundaries to
encapsulate parts of the system. I can't begin to give a counter
example because I have no idea what you're really trying to express.

Now, in come the auditors. they want to know where the money from the
credit memo went... do we say that the 2000 credit memo went to 1200 in
sales incentives on a 700 inventory sale with only 100 going to revenue?
How nuts does THAT part of the transaction look?

That is the fault of your bad design and your traditional accountants.
It is trivial to note that even in your *original* example it is simply
not possible to "know where the money from the credit memo went". It is
all part of one transaction pile. If you really want to track the
*money* that requires an even more advanced system than I'm proposing.

This results is confusion. Auditors WILL DEMAND to see the tables. The
tables need to make sense to them. They will want to use ad-hoc reports.
They will ask why there were two credits to inventory for this transaction,
and why there were three debits from credit memo.

Again, this is merely the result of a square peg and round hole
mismatch. All you've done is show that the systems will differ and that
accountants would have to be smart enough to learn to deal with
computers in a different way. I don't think that is so much to ask
these days.

On the other hand, if we logically store a single table like the first
example above, these questions DO NOT ARISE. It is easier for the business
to use the data if we don't randomly partition it in completely arbitrary
ways.

Uh, just because traditional accounting has standard practices doesn't
make it any less arbitrary. You have done absolutely nothing to show
that grouping by transaction is any more expressive than having a binary
tree. Also, since you are posting to comp.object, please consider that
you have the ability to represent a system in ways other than a single
table and that maybe, just maybe, such a system is easier to use by a
business that isn't run by stodgy old accountants.

What's so bad about this?

I didn't say it was bad, I just said it need not be the only way. I
expressed what I saw as disadvantages that a different system might help
solve. If you want to shoot me down you can refute that instead of just
gushing over the existing system because it has been in place for so
long that everyone knows it.

--
My personal UDP list: 127.0.0.1, 4ax.com, buzzardnews.com, googlegroups.com,
heapnode.com, localhost, x-privat.org
.



Relevant Pages

  • Re: double-entry bookkeeping unneeded?
    ... transaction is itself balanced. ... debit $10,000 from cash receipts ... credit $1200 sales incentive ... Clearly, the transaction balances. ...
    (comp.object)
  • Re: Need help with a tracking table design
    ... Credits and balance due amounts would be associated with a transaction # in most cases but not always. ... Things I would need to track is who, what (credit, balance due, refund and transaction if applicable), when it was settled and a how. ... For the "what", you might want a list of choices (links to a Table listing such choices as "Credit for unneeded late payment", "Refund of unused rent", "Transfer from another account", "Transfer to another account", "Ordinary rent payment"). ...
    (microsoft.public.access.gettingstarted)
  • Re: running balance
    ... LASTAS debit, ... LAST(a.[Deposit Amount]) AS credit, ... GROUP BY a.[date of transaction] ... amount in the credit, if applicable). ...
    (microsoft.public.access.queries)
  • Re: Cheapest phone?
    ... OK thanks Steve, I've ordered one for the XYL, (and joined Quidco) ... The bank told me the transaction was from CPW. ... give a mobile and a landline number, and not giving your landline might ... 'negatively impact on the credit check', words to that effect but defiantly ...
    (uk.telecom.mobile)
  • Re: Express lane?
    ... through the transaction, "is that going to be cash, check, credit, or debit ...
    (rec.food.cooking)