Chris Howe wrote:
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.
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
