Purchase Order v. Sales Order

[cjhowe]

Aside from the volume of code that exists to make the distinction
between which side of the order the user is on, is there a reason to
maintain this division?  IMO, this is more generically handled(and thus
"better")  if the OrderRole determines whether the user perceives the
order as a PO or an SO.

That would leave (again, IMO) the orderTypes of
PURCHASE_ORDER,
RETURN_ORDER,
QUOTE,
TRANSFER_ORDER, and I'm still on the fence for SHOPPING_LIST

[Jacopo Cappellato]

Chris,

just my two cents.
In *theory* you are perfectly right: an order is an order and it is both
a sales or purchase order depending on the side you look at it.
There are several other places where the same reasoning can be used: for
example, saying that a party is a "supplier" is not totally correct, we
should always define relationships between parties.
However we are not trying to capture the whole universe in our data
model and processes - not now, by the way :-)
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.

Jacopo

Chris Howe wrote:

> Aside from the volume of code that exists to make the distinction
> between which side of the order the user is on, is there a reason to
> maintain this division?  IMO, this is more generically handled(and thus
> "better")  if the OrderRole determines whether the user perceives the
> order as a PO or an SO.
>
> That would leave (again, IMO) the orderTypes of
> PURCHASE_ORDER,
> RETURN_ORDER,
> QUOTE,
> TRANSFER_ORDER, and I'm still on the fence for SHOPPING_LIST

[cjhowe]

Thanks for the feedback Jacopo!
questions inline...

--- Jacopo Cappellato <[hidden email]> 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 :-) ?

> 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?

If it is just convention that allows ease of writing applications or
performance related, would denormalizing the value be more prudent
(having the value in the theoretical correct place AND in the ease of
use place)?   Or are there other advantages that I'm overlooking?

IMO, in an ERP system, data is data and isn't particularly fascinating.
 The application(s) that read and process the data are what bring about
the value and insight of ERP systems.  Having an arbitrary scope turns
the fascination to the data and has its dangers.  For instance, I think
the redundant structures and logic to support a quote and a return
order as well as the structures used to maintain a supplier's pricing
illustrate that danger. (Note: I'm not suggesting those are bad
implementations or don't get the job done, just more costly to create
and to maintain).  

In addition, I think that scope puts a limit on the creation of
additional applications.  Competitor Intelligence and Customer
Intelligence applications would require building out redundant entities
and redundant logic because they go against the scope.

[David E Jones]

Chris Howe wrote:
> Thanks for the feedback Jacopo!
> questions inline...
>
> --- Jacopo Cappellato <[hidden email]> 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 haven't been able to recruit any omniscient contributors to OFBiz yet. If you know anyone good who is up for the job, please let us know!

>> 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?
>
> If it is just convention that allows ease of writing applications or
> performance related, would denormalizing the value be more prudent
> (having the value in the theoretical correct place AND in the ease of
> use place)?   Or are there other advantages that I'm overlooking?
>
> IMO, in an ERP system, data is data and isn't particularly fascinating.
>  The application(s) that read and process the data are what bring about
> the value and insight of ERP systems.  Having an arbitrary scope turns
> the fascination to the data and has its dangers.  For instance, I think
> the redundant structures and logic to support a quote and a return
> order as well as the structures used to maintain a supplier's pricing
> illustrate that danger. (Note: I'm not suggesting those are bad
> implementations or don't get the job done, just more costly to create
> and to maintain).  
>
> In addition, I think that scope puts a limit on the creation of
> additional applications.  Competitor Intelligence and Customer
> Intelligence applications would require building out redundant entities
> and redundant logic because they go against the scope.

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.

The main reason for this is that for each use of the model you would end up with a whole bunch of fields or even whole entities that are not used or that might be used in special circumstances, but when? For example the order model is very complex and has far more complex requirements than requests or quotes or returns and if we used the same model for these everything we do with requests or quotes or returns would be made artificially and unnecessarily complex, which means right there it's a bad design decision.

For customization and refactoring and so on over time it would also cause big problems. This goes back to the omniscience problem... If we could have a perfect, meet-all-requirements model right now we would. But we really can't. So, we need to plan for the fact that things WILL change in the project, and when implementing for specific clients or industries things will also HAVE to be changed. That's life, and so in the framework and applications (of which the data model is a part) we've tried to design for that, and improve the design for that iteratively over time.

-David

[cjhowe]

--- David E Jones <[hidden email]> 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

[Jacopo Cappellato]

Hi Chris,

Chris Howe wrote:
> Thanks for the feedback Jacopo!
> questions inline...
>
> --- Jacopo Cappellato <[hidden email]> 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" :-)

>
>> 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.

Jacopo

[cjhowe]

--- Jacopo Cappellato <[hidden email]> wrote:

> Hi Chris,
>
> Chris Howe wrote:
> > Thanks for the feedback Jacopo!
> > questions inline...
> >
> > --- Jacopo Cappellato <[hidden email]> 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.

[David E Jones]

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

[cjhowe]

--- David E Jones <[hidden email]> 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