Perfect Jacopo And I learned something too. Sync calls are part of the begin/commit transaction and async calls are not. Thanks for the feedback.
In this way, especially if we put all the seca definitions for accounting stuff in one file, people can just comment them out or uncomment them if they don't want or do want GL accounting done. Skip -----Original Message----- From: Jacopo Cappellato [mailto:[EMAIL PROTECTED] Sent: Saturday, November 24, 2007 9:19 AM To: dev@ofbiz.apache.org Subject: Re: [OFBiz] Users - Accounting Extension (GL, etc) Now In Beta [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. > > On the other hand, it is my expectation that most Ofbiz users will not use > this or want the overhead. > > So, my question. Can a SECA be used? If the code in a SECA that is Yes, this is what we should really implement. > associated with a commit on some entity generates an exception, is the > associated transaction rolled back? For example, if a SECA was tied to an > Invoice commit and that code caused an exception, would the Invoice commit > be rolled back too? Yes... and no :-) If in the seca you set the service call as sync then everything will be rolled back (if the accounting transaction fails); if you set the seca as async then it will not. I'd say that by default we should keep the accounting secas as async, but some customer could change them to async. Does it make sense? Jacopo > > Skip
