Thanks to all for your feedback.
What about the entity definitions? The only lower level component that
is using them is the product component... should we move them from party
to product? This would resolve the dependency to the product data model
caused by the AgreementProductAppl entity.
And, in general, it's ok for me to move the screens to the order
component: however I think that it would be nice to add an agreement tab
to the party detail screen (to show all the agreements associated to a
given party) and also an agreement tab to the product details screen (to
show all the agreements associated to a given product)... this will
imply that, for example, the party manager application will depend on
upper level components (that it is not a good thing) but, in my opinion,
this will greatly improve the usability of the system.
So, in my opinion we should allow for some (not strictly correct)
dependencies between applications (and in fact this already happens here
and there in the system)... what is your opinion about this?
Jacopo
David E. Jones wrote:
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
