Let's see how well my "snips" work :) --- Jacopo Cappellato <[EMAIL PROTECTED]> wrote:
> Hi Chris, > > We have two options: keeping all the agreement > related screens in one > component (party or product or order instead of > accounting) or splitting > the agreement screens in more than one component > (party, product, > accounting and order). > There are pros and cons but I'd prefer the former > solution. 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. > I'm not saying I want to move all the > SupplierProduct fields to > agreement, but there are some fields that could be > integrated in the > agreement data model. > My preference (as a long term goal) would be that of > slowing suppressing > the SupplierProduct entity and expanding instead the > agreement data model... 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. > I'm *not* trying to find a quick and dirty solution > to my needs, I want > to model correctly these processes, and price lists > agreed with > suppliers and customers are definitely agreements. > One option (that we discussed some time ago in the > old dev list) was to > add a new field "agreementId" as a primary key to > the ProductPrice > entity but after discussing this we ended up that it > was better to keep > the agreement prices in a new entity. > > However, in general, keeping things simple is > important, I always prefer > to have some basic features in place (maybe with > some limitations that > can be implemented when someone needs them) instead > of a huge nothing. 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). 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. 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. 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 >
