I would say that the error journal should be a match of the AcctgTrans/AcctgTransEntry set so that when the errors were corrected, they could be easily moved.
Skip -----Original Message----- From: David E Jones [mailto:[EMAIL PROTECTED] Sent: Saturday, November 24, 2007 12:09 PM To: dev@ofbiz.apache.org Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta On Nov 24, 2007, at 1:05 PM, Jacopo Cappellato wrote: > David E Jones wrote: >> On Nov 24, 2007, at 9:55 AM, [EMAIL PROTECTED] wrote: >>> I am thinking about the implementation of this. >>> >>> As I mentioned, I am strongly motivated to make each entry in >>> AcctgTrans/AcctgTransEntry an atomic part of the underlying reason >>> for the >>> enter, say an Invoice creation. If the AcctgTrans/AcctgTransEntry >>> creation >>> fails, the Invoice creation should be rolled back as well to the >>> integrity >>> of the business is maintained. >> What I'd prefer to see happen (by default anyway...) is that if the >> GL posting fails for some reason the triggering operation >> (finalizing an invoice or payment or whatever) would NOT roll back, >> instead the partial GL post would be places into an error journal >> (if that failed, then a general error resulting in rollback would >> be appropriate). >> -David > > This would be optimal. > > David, how do you think we can specify the error journal for a > company (or other types of journals)? Should we implement an entity > similar to GlAccountTypeDefault? I guess it depends on if we want to implement one error journal per organization, of if we want more than one so we could have different error journals for different accounts or somethings too. Initially I'd say just one because even if someone wants to implement the many most companies should do fine with the one. For the one the errorGlJournalId or whatever could just go on the organization accounting prefs entity (can't remember the exact name of that one off the top of my head right now). -David
