--- David E Jones <[EMAIL PROTECTED]> wrote: > > Sorry, I still think this is dead wrong and if you think it is an > important change you'll really have to look at the details and see > just how much work such a change would create (and that aside from > the rest of the model changes, like eliminating the return, request, > quote, etc models). The distinction between purchase and sales orders > is used all over the place for different user interfaces and services > and high level business processes. If we didn't have that type field > we would have a heck of a time figuring it out in things like ECA > rules and such. > > We don't live in an abstract world where we model for theory. Things > are modeled the way they are to pragmatically represent reality in as > generic and customizable way as possible. That is the goal anyway, > and I don't see how these changes help that goal. > > Chris: unless you have something that addresses how this would help > in a pragmatic, rubber-on-the-pavement way then discussing this is a > waste of time. To be honest the main reason I'm answering is to make > sure other people are clear to so that no one will start doing stuff > like this, especially without reviewing the impact and problems it > would cause first!
David, Being correct in theory and being able to complete work in a pragmatic way are not mutually exclusive. OrderHeader.orderTypeId does not currently use the same convention as every other *.*TypeId field in OFbiz does. This causes a problem in teaching OFBiz development to others. I don't see you arguing that my distinction is incorrect, just that there is work involved to allow OFBiz to make the correct distinction. I think this change can be done in step wise fashion and not be as destructible as you make it out to be. The pragmatic solution to this is to place the distinction between SO and PO in a de-normalized field (e.g. OrderHeader.useScopeId or something similar). It is considered a de-normalized field, because the distinction is already appropriately made as an OrderRole. Using this de-normalization eliminates your ECA woes so long as it is looking at that new field instead of orderTypeId. Once that is done, the quotes, returns and transfers can be evaluated for their appropriateness in the order model. Again, this addresses the pragmatic problem of teaching others OFBiz development. Upon the evaluation of the other entity groups, it is likely to address the pragmatic problem of duplicated effort and maintenance of duplicated effort. -Chris
