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 <tbull...@nd.edu> > To: John Ralls <jra...@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 _______________________________________________ gnucash-devel mailing list gnucash-devel@gnucash.org https://lists.gnucash.org/mailman/listinfo/gnucash-devel
