Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta

[David E Jones]

-David


On Nov 23, 2007, at 1:09 PM, [EMAIL PROTECTED] wrote:

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.

Jacopo

Traditionally, a general journal is the middle step or "glue" in a GL

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

to inventory, and a debit to cost of goods sold, etc.


having a single "supportingDocumentId" used in conjuction with a

however understand the value of having individual document Ids so
getRelated() can be used.  Its just that it looks so messy.


Sarbanes requirements in the U.S.


manual postings which happen frequently, and no doubt others as well.


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?).


used to produce detailed cash flow statements and other similar

income statements.


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



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)

to it in one batch

My questions are:


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:

system. Every number in a General Ledger account is the sum of it's general 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 This is all provided for in AcctTrans and AcctingTransEntry (although in my view having a product, shipping, invoice, payment, etc ids would be better "documentTypeId" as this would allow for unforseen transaction types). I do 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 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 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 If correctly correlated using a transaction class field, the journal can be sub-documents. The GL itself is traditionally used to produce balance and 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 Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta * a journal can be used to quickly post all the transactions associated 1) who should create a journal and when? automatically by the system? by

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

like
have a property or PartyAcctPreference that flips the switch.

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

The original design I did for the accounting stuff includes journal

manually reviewed, but if there was a switch like this somewhere we

and it could even be configured to queue up certain types of

not sales invoices or inventory changes due to the extreme volume;
assuming a company where that is the case for sake of example).

management for un-posted transactions. The implementation was supposed to put transactions that failed auto-posting into an error journal to be could certainly use the journaling feature for what you are describing, transactions but not others (like all purchase invoices for example, but

I would only like to be involved if we can agree to spend the time to do

user-friendly, intuitive screens.

processes to support (use cases if you will) would be great.

-David

Feedback on screen designs, probably starting with putting down end- user

smime.p7s
Description: S/MIME cryptographic signature