--- David E Jones <[EMAIL PROTECTED]> wrote: > > > How redundant are these really? I'd ask you to review the data models > one more time. They really don't have many similarities beyond things > like the header/item and role patterns, and those are patterns. > > If we were working with an object model we could have a base object > that handles those things and extended objects for orders, returns, > shopping lists, requests, quotes, and various other things too. But > it's a relational data model so it doesn't work that way, and very > much no, we don't want to go down the road of trying to make it > object oriented and doing the O-R mapping and such. That is a huge > overhead easily an order of magnitude higher than the small > redundancy in model and code we currently have. > > I am very much against trying to make a consolidated model of this. > We've discussed this before and my opinion has not changed. The order > model is WAY more complex than the return or quote models, and even > those have very different purposes and have some fairly different > data needs and it would make the project in general far more > difficult to understand and work with and customize if we tried to > consolidate them.
This argument confuses me. Every major entity in OFBiz uses the distinction of *TypeId. OFBiz currently suggests that there are only two order types: PURCHASE_ORDER SALES_ORDER However, a purchase order IS a sales order depending on what side the interested party is on (which can be easily determined by the orderRoleTypeId). Given this, that means OFBiz is suggesting that there is only ONE type of order and that orderTypeId is a denormalized field. Since the other *TypeId fields aren't denormalized fields, I don't know why Order should use its TypeId field as one. Are there other order types? Yes! Those are Transfer Orders, Return Orders, Quotes, etc. -Chris
