Hi Chris,
Chris Howe wrote:
Let's see how well my "snips" work :)
--- Jacopo Cappellato <[EMAIL PROTECTED]> wrote:
Hi Chris,
IMO all agreement Create/Update/Delete logic should
remain in party component there should also be
retrieve logic that allows allows retrieval of
agreements that a party is party to.
Each other component should have screens that support
the generic agreement TYPES that one would find
related to that component. Any special retrieval
logic would be in the component that the logic is
specific to. If there are complex
Create/Update/Delete logic that is needed, those
logics should in the end call on the party services to
actually change the raw data. This approach keeps
everything modularized.
About where to put the *existing* agreement screens (agreement header,
terms, items, item terms, parties, products): I'm not sure to understand
your comments, could you please be more precise and tell me in which
components you would like to see them?
I think we're allowing the fact that sales pricing is
not consolodated to make us believe that pricing based
on a price list is somehow also special. All you need
to show that a price you have in your system is based
on an agreement is to have a join entity between
AgreementItem and ProductPrice.
I agree that it's beneficial to phase out
SupplierProduct entity, but it should be integrated
into the Product entities as a seperate productType.
The SupplierProduct has nothing to do with an
Agreement. This is shown by being able to conduct
business with most supplier's absent an agreement at
all. While you can argue there is a verbal agreement,
I doubt you would want to maintain that data.
The information in the SupplierProduct are really information that could
be modeled as an agreement (maybe implicit).
The agreement entities should be reference entities.
Calculations should not be based on them as that would
be treating these price lists as if they were somehow
different that other pricing. If you want to show
that a price is based off an agreement create a join
entity that allows you to show this relationship.
This shouldn't be a FK because your price can be based
on several agreements or several agreement items. (ie.
a distributor having an exhibit that contains an
everyday price list + a seperate agreement that if his
supplier offers a discount to the general public, then
the company recieves x discount off of the general
public's discount).
No. I could sell (or buy) the same product at different prices (even
from to the same party) based on different agreements (for example with
different terms). So, if you want to use the ProductPrice entity you'll
have to add the agreementId as a PK. And, as I told you before, there
were reasons against this approach.
The agreement is ancilary information and as such
should be allowed to be looked at seperately when
trying to work with the fruits of agreement. When
your business logic is trying to get a price for to
create a PO, it shouldn't have to be aware that this
price is based on an agreement.
Why?
When you're entering the agreement and you get to the
agreementItem that is talking about the price list,
your screen can have all the input boxes it wants to
enter your price list. When you submit the agreement
your logic should be creating ProductPriceRules (not
ProductPrice as I mentioned earlier) this will allow
you to easily create quantity based pricing, etc.
I'm against using price rules to implement price lists based on
agreements: it is not a natural way of handling this, it leads to
complex (in the negative way) data and business logics to treat them.
Chris, thanks for your comments and time but, by the way, are you
planning to implement this stuff or your comments are only here for the
sake of this discussion?
Jacopo
You'll always have two conditions,
partyId =
and
productId =
Then you're join entity will have the agreementId,
agreementItemId and the productPriceRuleId, etc
This seems a much more natural relationship instead of
imbedding the product into the agreement.
:-)
Jacopo
