--- Jacopo Cappellato <[EMAIL PROTECTED]> wrote: > Hi Chris, > > Chris Howe wrote: > > Thanks for the feedback Jacopo! > > questions inline... > > > > --- Jacopo Cappellato <[EMAIL PROTECTED]> wrote: > > > >> However we are not trying to capture the whole universe in our > data > >> model and processes - not now, by the way :-) > > > > Why not now :-) ? > > Because we are building a universal and generic ERP system and not > "The > Matrix" :-)
lol, There seems to be just as large an expanse between the scope of a user company and a universal and generic ERP as there is between a universal and generic ERP as there is "The Matrix". :-) > > > > >> And there are *huge* advantages of limiting our scope to some > >> assumptions: OFBiz, as an ERP system, can be used by a Company, > with > >> many divisions under it (possibly playing various roles in the > supply > >> chain) etc... but where you can pretty clearly identify who are > the > >> suppliers, the customers, the agents etc... (and combinations of > >> these) what are purchase orders and what are sales orders. > > > > That really is the crux of my question. What are the _huge > advantages? > > I'm sure you can think of many existing services that would require > much > more code to do the same things with the new data model; just think > for > example at the MRP algorithm. > I haven't looked at the MRP stuff at all. But I can't fathom why it would have a problem with determining its scope without relying on the current convention of a Purchase Order v. Sales Order. There is no problem using a denormalized field for convenience or performance sake, but problems arise when you use a denormalized field where a fundamental convention exists. When we override fundamental conventions, we lose the benefit of the convention. In addition, when we write applications that aren't responsible for their scope, every other application is restricted to the assumptions of the non-scoped application. That by definition keeps us from producing a "universal and generic" ERP.
