That is the confusion then, I have always associated a General Journal as the detail and audit trail behind General Ledger number. The GLJournl entity is not that. The AcctgTrans/AcctgTransEntry entities are, hence my assuming that they were the general journal we were talking about.
Skip -----Original Message----- From: David E Jones [mailto:[EMAIL PROTECTED] Sent: Saturday, November 24, 2007 4:20 AM To: dev@ofbiz.apache.org Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta It sounds here like you are confusing a transaction (AcctgTrans) with a journal (GlJournal). When I say journal I really do mean journal, aka GlJournal as I made explicit in my previous message. -David On Nov 23, 2007, at 8:15 PM, [EMAIL PROTECTED] wrote: > David > > Based on experience as well as "Accounting and Budgeting" page 271, > every GL > account is associated with one (the one being the beginning balance > entry) > or more AcctgTrans/AcctgTransEntry. If you cannot reproduce how you > got to > some figure in the GLAccount, what's the point? > > Each AcctgTransEntry has a field for glAccountId which is thankfully > specified as "id-ne". > > I agree that it is only required to make sure that each AcctgTrans and > associated AcctgTransEntrys zero's out. > > I do not agree that AcctgTrans are optional unless you do not desire > to > maintain a General Ledger at all. The whole point of a journal is to > provide an audit trail and without it, the contents of GLAccount are > worthless, actually, worse that worthless. Providing a field to > specify the > originating document is optional I agree, but it gives one more > point of > reference for the audit trail. > > Ofbiz does have a GLJournal entity, but I don't see the point of it > noone > uses it. The AcctgTrans/AcctgTransEntry is the Journal and audit > trail > unless some similiar pair of entities is invented to replace them. > > I also agree that journals are not meant to be balanced. There is > just too > much data there to manipulate regularly. However, so long as each > AcctgTrans and associated AcctgTransEntrys balance and committed as > one > atomic operation, it is in fact balanced. > > I do not agree that "a transaction is not associated with a GL > account and > does not represent a debit or credit" unless you are talking about > transactions not associated with the general ledger and in particular > AcctgTrans/AcctgTransEntry for Ofbiz. Every tupple in > AcctgTransEntry needs > a glaccountId and debitCreditFlag, and if the sum of debits and > credits in > the AcctgTransEntry that are associated with a single AcctgTrans > balance, > then the GL will balance when the posting is made. I have made my > production postgres server require glaccountId and debitCreditFlag > or the > commit is rejected. If I could enforce this in Ofbiz, I would. > > I agree that document reference is already well represented in Ofbiz > AcctgTrans/AcctgTransEntry. I will go further and say that a well > structured and auditable general ledger is fully represented in > existing > Ofbiz entities except for a manual entry "document" entity for manual > postings (except for the possibility of error journal you mentioned > the > other day which I think is a splendid idea). > > It is only required to make sure to implement the code in such a way > all GL > transactions (those creating entries in AcctgTrans/AcctgTransEntry) > are > atomic and debits balance with credits within themselves to end up > with a > world class system accounting (leaving aside some of the really > nifty things > you can do for large, multi-departmental organizations). > > Given your superior experience here (mine is many years old), I am > betting > we are disagreeing over semantic issues. > > Skip > > -----Original Message----- > From: David E Jones [mailto:[EMAIL PROTECTED] > Sent: Friday, November 23, 2007 6:20 PM > To: dev@ofbiz.apache.org > Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In > Beta > > > > Some notes on journals (GlJournal), transactions (AcctgTrans), > transaction entries (AcctgTransEntry), etc: > > 1. they are optional, transactions do not have to be associated with a > journal > 2. a transaction is not associated with a GL account and does not > represent a debit or credit, each entry in a transaction does > 3. journals are not meant to be balanced, individual transactions are > (checking to see whether or not an entire journal is balanced is > simply a matter of seeing if each transaction is balanced > 4. origin "documents" (detail records) are associated with the > transaction entry, and there are structures for this in OFBiz > > I think this is mostly a difference in terminology, most of the rest > of what you wrote sounds correct to me based on my understanding based > on my research and collaboration with others on accounting systems. > > -David > > > On Nov 23, 2007, at 1:09 PM, [EMAIL PROTECTED] wrote: > >> Jacopo >> >> Traditionally, a general journal is the middle step or "glue" in a GL >> system. Every number in a General Ledger account is the sum of it's >> general >> journal entries. In computer terms, the general ledger typically >> also >> contains a reference to the creating document. >> >> There can never be a single journal entry except for maintenance in >> correcting errors (rounding errors and the like). A journal entry >> consists >> of two or more transactions, a debit and a credit, the sum of which >> is zero >> when subtracting the debits from the credits for that transaction. >> There >> should also be a reference document that is the basis for the >> transaction, >> e.g. an invoice number, shipping number, payment number etc. In >> other >> words, all activity in the system that involves something of value >> whether >> or not it involves an outside party should have at least a pair of >> journal >> entries and this includes non-cash things like moving inventory >> between >> stores, depreciating fixed assets, good-will rightoffs, etc. I say >> "at >> least" because several transactions have many journal entries. An >> invoice >> for example involves at least a debit to cash or receivables, a >> credit to a >> sales account and maybe a credit to a tax and or shipping account, a >> credit >> to inventory, and a debit to cost of goods sold, etc. >> >> This is all provided for in AcctTrans and AcctingTransEntry >> (although in my >> view having a product, shipping, invoice, payment, etc ids would be >> better >> having a single "supportingDocumentId" used in conjuction with a >> "documentTypeId" as this would allow for unforseen transaction >> types). I do >> however understand the value of having individual document Ids so >> getRelated() can be used. Its just that it looks so messy. >> >> Journal entries are always made in conjuction with and at the same >> time as >> the original document is produced, and should be in my view part of >> the >> database begin/commit. This ensures that if the underlying document >> is >> written, the required journal entries are written or none are. It >> therefore >> should be difficult to impossible for the journal to get out of wack >> with >> the business and most large businesses I have been involved with >> over the >> years is VERY concerned with the accounting of their money, not to >> mention >> Sarbanes requirements in the U.S. >> >> You should be able to select a journal transaction, and see the >> entries that >> comprise it and view the original document(s) that created it using >> related >> entities. If we insist that every journal entry has a supporting >> document >> (which I think we should), we will have to create another entity to >> hold >> manual postings which happen frequently, and no doubt others as well. >> >> In some businesses, the general ledger is auto-posted from the >> journal in >> real time. In others, the transaction is marked as isposted="F" and >> the >> posting to the GL is handled by an accounting type human who reviews >> all the >> unposted journal transactions before posting them to the GL (batch >> mode >> posting). This is a prime candidate for a SECA on the AcctTrans >> commit if >> we just add a single entry "autopost"="T/F" to it (or maybe there is >> somewhere else we can get this flag from for a SECA?). >> >> If correctly correlated using a transaction class field, the journal >> can be >> used to produce detailed cash flow statements and other similar >> sub-documents. The GL itself is traditionally used to produce >> balance and >> income statements. >> >> How you end up implementing it is of course up to you, but all the >> pieces >> that I have described are provided for in the data model with the >> possible >> exception of supportingDocumentId. >> >> Skip >> >> >> >> -----Original Message----- >> From: Jacopo Cappellato [mailto:[EMAIL PROTECTED] >> Sent: Friday, November 23, 2007 2:40 AM >> To: dev@ofbiz.apache.org >> Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In >> Beta >> >> >> David, all, >> >> I'm really interested in knowing more about the design for journal >> management. >> I did some research (existing data model and services) and it seems >> to >> me that: >> >> * a journal (GlJournal) is used to group together a set of accounting >> transactions (AcctgTrans) >> * a journal can be used to verify the correctness of all the >> transactions associated to it (there is a service to check the trial >> balance of a journal) >> * a journal can be used to quickly post all the transactions >> associated >> to it in one batch >> >> My questions are: >> >> 1) who should create a journal and when? automatically by the >> system? by >> users? or manager? >> 2) can a transaction be created without specifying a journal? >> 3) can a journal contain both posted and unposted transactions? >> 4) should we create a GlJournal.journalTypeId field to define an >> error >> journal for transactions that failed auto-posting (as suggested by >> David) and possibly other types (e.g. to group automatically posted >> transactions from manually posted ones) >> >> I've also created a new Wiki page to help to get this ball rolling: >> >> http://docs.ofbiz.org/x/sgw >> >> I'll do my best to add relevant information there as well. >> >> Jacopo >> >> David E Jones wrote: >>> >>> On Nov 23, 2007, at 12:02 AM, [EMAIL PROTECTED] wrote: >>> >>>> I have some strong feelings about how Si has done this though. My >>>> primary >>>> concern is that some organizations prefer to post to the G/L in >>>> real time >>>> and others prefer to do batch review/post. I hope we can do >>>> something >>>> like >>>> have a property or PartyAcctPreference that flips the switch. >>> >>> The original design I did for the accounting stuff includes journal >>> management for un-posted transactions. The implementation was >>> supposed >>> to put transactions that failed auto-posting into an error journal >>> to be >>> manually reviewed, but if there was a switch like this somewhere we >>> could certainly use the journaling feature for what you are >>> describing, >>> and it could even be configured to queue up certain types of >>> transactions but not others (like all purchase invoices for >>> example, but >>> not sales invoices or inventory changes due to the extreme volume; >>> assuming a company where that is the case for sake of example). >>> >>>> I would only like to be involved if we can agree to spend the time >>>> to do >>>> user-friendly, intuitive screens. >>> >>> Feedback on screen designs, probably starting with putting down end- >>> user >>> processes to support (use cases if you will) would be great. >>> >>> -David >>> >> >> > >
