This begins to sounds quite right :o) Jacques
De : "David E Jones" <[EMAIL PROTECTED]> > > 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
