Just like the majority of responses I agree that the order component
is most likely the best home for this.
Originally the Agreement data model was in the party package because
that is in essence what agreements relate directly too (and because
that is the section of The Data Model Resource Book where they are
described). Over time though Agreements have become closer to an
Order because even though they could perhaps be used for other
things, they are mostly used to track the terms between a customer
and the company for future orders. In a way an agreement in this way
is more like a Quote, but one that is meant to be used many times and
in combination with other quotes or agreements, or even retail level
purchases. A quote is a bit more rigid in the implied constraints.
So, from the most generic and future-proof perspective the party
component would be the best. However, given how it has evolved and
how it is now used and will most likely be used in the future, the
order component makes more sense - especially for the UI since in
this area it does tie into other parts of an ordering process, kind
of an alternative for a quote (even perhaps in response to an RFQ...).
So, unless we can come up with other likely future uses that would
make putting it in the party component make the most sense, I'd say
we put it in the order component.
-David
On Aug 16, 2006, at 1:24 AM, Jacopo Cappellato wrote:
Hi all,
what is the right component for the agreement stuff (entity defs,
services, screens)?
Right now, the entity definitions are in the "party" component and
the service definitions and screens are in the "accounting" component.
Since I'm planning some enhancements for the agreements'
implementation, I'd like to put some order.
I don't see any reason to keep them in the accounting component and
I'd like to move them to the right spot.
My first choice is to move everything to the party component (where
the entities are already defined): in fact, after you have created
parties (suppliers, customers, agents...), it's 'natural' to define
agreements with them in the same application (I'd like to add a
party subscreen to list all the available agreements).
However there are some issues with this approach, since agreements
are also associated to the "product" component
(AgreementProductAppl, AgreementPromoAppl) that is an higher level
component.
So, what we can do? Should we move all the agreement ui to the
"catalog" application? Or just the product related screens? (I
don't like too much this approach since it is not easy for users to
jump from one application to the other to set up one agreement).
Your feedback is welcome!
Jacopo
