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 >
