Terminology Clarification requested

[J. Alex Aycinena]

Thomas,

I think the way you show your 'accounting transaction' example is part
of the confusion; see my comments below:

> ---------- Forwarded message ----------
> From: Thomas Bullock <tbullock at nd.edu>
> To: John Ralls <jralls at ceridwen.fremont.ca.us>
> Date: Fri, 10 Dec 2010 07:34:46 -0500
> Subject: RE: Terminology Clarification requested
> Hi John,

<snip>

>> > My formation long ago as a young accountant contained this
>> understanding of a transaction: it was the accounting expression of an
>> activity that happened in the physical world, which the accounting
>> ledgers were tracking in their own notation.  For example, suppose the
>> activity is buying a car using cash and debt on 11/10/2010.  The
>> accounting transaction is that act of purchase.  The accounting
>> notation was the language of debits and credits with accompanying
>> names describing the purpose of the monetary "buckets" or value
>> holders.
>> >
>> > Thus, in a journal, the transaction would be recorded similarly to
>> this:
>> >                                                                 Debit
>> Credit
>> >     11/10/2010              New car                     15,000
>> >     11/10/2010              New car loan
>>       10,000
>> >     11/10/2010              Cash in bank
>> 5,000
>> >

This 'accounting transaction' has data that applies to all of the
lines: in your example, they all have the same date (if fact they must
in an accounting sense). In addition there might be other data that
applies to the transaction as a whole which you don't show: a
transaction-level description, transaction number, etc. The individual
lines have there own data: the amount debited or credited, the account
they affect, a line-level description (called a memo in GC), a
line-level reference number (which GC doesn't in fact have, a
deficiency in my view, although rather minor). So the structures John
refers to reflects this fact: there is data that is kept at a
'transaction-level' and applies to the transaction as a whole, and all
of it's lines, and there is data that applies to each individual line.
The 'transaction' in both an accounting sense and in a programming
sense is all of that data taken together: all the data stored at the
'transaction-level' plus at the 'split-level' for all the splits that
comprise the specific transaction.



>> > Above John says "...the KVP should be on the split, not the
>> transaction,..." but in a later follow-up
>> > Derek says that the KVP should be on the transaction and not on the
>> split, noting further that the date is resident in the transaction and
>> not the split.
>> >
>> > Which of the above in GC terminology is the "transaction" and which
>> the "split"?  What makes one of the parts of the above the
>> "transaction" and the others the splits?  Can any one of the 3 parts
>> be named the transaction be different people?  What keeps the
>> transaction from being arbitrarily identified?

All three splits together plus the data that is common to them all
(e.g., the date) is the transaction.

>> >
>> > In my mind all three parts are splits and there is no transaction
>> unless all three are there with debits and credits in balance. If one
>> or two parts are missing, the transaction is said to be incomplete or
>> broken, because it would not balance.
>> >
>> > Clearly, GC has a different sense of naming these elements and it is
>> important to include in basic documentation a clear discussion of the
>> terminology as used in the GC world and as used in the Accounting
>> world.  I am not interested particularly in changing GC usage.  I am
>> interested in understanding clearly how developers see things and why
>> things are perceived that way.  Once I see that perspective, then the
>> documentation as presently written will become clearer, at least to
>> this accountant, and I expect others in the Users' List.
>> >
>> > Thanks to all who can help me with this.
>> >
>>
>> Tom,
>>

Alex