Makes sense. I have gone with the individual methods to be consistent with other methods in the UtilAccounting class -- they split out a bunch of them so that they can embed the "known" type under the covers.
As a side note, when I went to run this my JVM would actually die. It turns out that the new method on CommonWorker does not have loop protection, so if the seeded values are incorrect it will infinite loop. I was actually getting a "Invalid access of stack red zone" message to the console before the JVM would die. I have changed CommonWorker as well to (internally) keep a Set of childTypeIds and if it encounters one it has already checked in its recursion, it short circuits and returns false. We would personally fix the bad seeding in the InvoiceType entity (you can see PURCHASE_INVOICE actually has a parent of itself). To do this we would use a notion we had come up with where you could specify an explicit null in the seed data (by default Ofbiz uses unspecified or empty values in the xml as "not specified" and ignores them). There was a JIRA provided for this fix, but it had some push back and not sure if it got in or not. Either way, to correct the seed data (on an existing install) you would have to somehow get the parentId set to null ... -- View this message in context: http://n4.nabble.com/Accounting-transaction-for-commission-invoice-tp1564778p1566534.html Sent from the OFBiz - Dev mailing list archive at Nabble.com.
