Thanks David,
your notes are of great help.
I'd say that we could improve the errorGlAccountId setup in the
following ways:
a) allow to enter the errorGlJournalId only if the party is the parent
of all the organizations and
a1) automatically propagate the value into the children's
errorGlJournalId or
a2) create a service that retrieves the error journal for a given
organization by looking at the error journal of the parent record
This is probably a low priority task, but I'm going to file it in Jira
in a few hours.
Jacopo
David E Jones wrote:
I would give this proposed change a solid no.
The organizationPartyId being in both places could introduce errors, but
the one on the journal is meant for the primary organization, preferably
one that is a parent to all organizations referred to in AcctgTransEntry
records (we could even add something to enforce that if it is a great
concern).
Moving the journal (GlJournal) ID from the transaction (AcctgTrans) to
the transaction entry (AcctgTransEntry) seems like it would defeat the
purpose of a journal. A journal is a place to keep track of a set of
transactions, usually temporarily while preparing them for posting. Once
a set is all balanced out (checked through a trial balance) and
everything that is in it needs to be, then the whole journal or any
individual transaction in the journal can be posted. Splitting different
entries in a single transaction into multiple journals would make it
impossible to do a reliable trial balance of a journal or generally keep
order in manual journal management efforts.
The concept of a journal comes from the days of 100% manual accounting,
when journals were the day to day primary work books of book keepers.
Transactions and entries were written in journals, and then individual
transaction entries were copied into the ledger for each GL account, aka
the "posting" process.
Some of that translated into electronic data structures, but of course
the database driven ones are far more flexible and because we can have
many dimensions in a single table and the management of the data
relationships and reporting on or interpretation of them can be
automated it is easier and cleaner use a slightly different structure
and avoid redundancy. That is why we don't have journal transactions and
gl entries, the AcctgTrans/Entry entities are both used for both places.
-David
On Nov 28, 2007, at 10:13 AM, Jacopo Cappellato wrote:
In rev. 599065 I've implemented some code to assign an accounting
transaction that fails when posted to the error journal.
However, while writing the code, I've realized that maybe we have to
move the glJournalId from the AcctgTrans to the AcctgTransEntry entity.
In fact, in theory the entries of an AcctgTrans could belong to
different organizationPartyId; and each journal is associated to one
organizationPartyId.
Can I move the field and modify the code?
Jacopo
Jacopo Cappellato wrote:
As a followup to the recent discussion about GL journals to group the
failed accounting transactions, I've implemented the base screens to
create/edit journals and to define the error journal in rev.597976
It is also possible to search for transactions and transaction
entries by journal id.
The details are here:
http://docs.ofbiz.org/x/sgw
Jacopo
