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

[David E Jones]

-David


On Nov 23, 2007, at 8:15 PM, [EMAIL PROTECTED] wrote:

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


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.


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

reference for the audit trail.


unless some similiar pair of entities is invented to replace them.


much data there to manipulate regularly.  However, so long as each

atomic operation, it is in fact balanced.


does not  represent a debit or credit" unless you are talking about
transactions not associated with the general ledger and in particular

then the GL will balance when the posting is made.  I have made my

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

Ofbiz entities except for a manual entry "document" entity for manual

other day which I think is a splendid idea).


you can do for large, multi-departmental organizations).


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




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:

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 I do not agree that AcctgTrans are optional unless you do not desire to worthless, actually, worse that worthless. Providing a field to specify the originating document is optional I agree, but it gives one more point of 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 I also agree that journals are not meant to be balanced. There is just too AcctgTrans and associated AcctgTransEntrys balance and committed as one I do not agree that "a transaction is not associated with a GL account and 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, production postgres server require glaccountId and debitCreditFlag or the structured and auditable general ledger is fully represented in existing postings (except for the possibility of error journal you mentioned the 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 Given your superior experience here (mine is many years old), I am betting Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta

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

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.

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?

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:

journal entries. In computer terms, the general ledger typically also I did some research (existing data model and services) and it seems to 4) should we create a GlJournal.journalTypeId field to define an error

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

smime.p7s
Description: S/MIME cryptographic signature