[OFBiz] Dev - New Transactional Inventory Implemented

[Adrian Crum]

Daniel L. Kunkel wrote:
> Ok...  to put in in other terms, you're trying to create something of a 
> "double entry" system for tracking the inventory.  If everyone 
> remembers the recent discussions on accounting, the double entry 
> system was designed to make it possible to find and fix any single 
> accounting or arithmetic error.
> 
> This, however, seems to run in the face of a "normalized database" 
> where data is only ever stored in a single place.  What is the plan of 
> attack when the differences doesn't add up to the total?  

The designer of OFbiz's datastore, Len Silverston, mentions that there 
will be real world implementations that will require straying from the 
"ideal" data structure. He even gives examples of how the "ideal" data 
structure should be modified for real world use.

In the accounting applications I've worked with in the past, there is 
usually a mechanism to recalculate the form's totals - be it a Sales 
Order, a Purchase Order, or an Invoice. (I've also seen the same 
mechanism in GL - to recalculate the General Ledger.) These mechanisms 
usually appear in the form of a menu item labeled "Recalculate."

Having summary fields in "form master" entities is convenient from a 
programmer's perspective, and as David mentioned, it can also be a 
performance enhancement. Using the summary fields requires the 
understanding that their contents may not reflect the actual sums of 
line item records.

 From my perspective, it would be nice to have a standard "Recalculate" 
service for every entity that has summary fields. The OFBiz implementer 
could decide when/how the service is used.