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? ;)
-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
smime.p7s
Description: S/MIME cryptographic signature
