David E Jones wrote:
On Nov 28, 2007, at 11:18 PM, Jacopo Cappellato wrote:
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
I'm not sure if I like any of these approaches... but I guess that's
probably because I still think that if something like this happens it
won't be all that big of a deal, ie there aren't really big errors that
would be caused by it.
If we were to do something about it I'd prefer it just be a warning
message when viewing a journal that an entry is associated with another
organization... or something... I'm not even sure what we would warn
about and what the user would do about it. Maybe it's just too late
tonight? ;)
No, no... what you says makes perfect sense!
Mine was only an attempt to resolve a minor issue with the current ui:
when a user is in the context of an organization he can only filters
transactions by journals associated with the organization...
But it is a minor issue and we will find a way to fix this in the future
Jacopo
-David
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
