My 2 cents... Agreement is a party concept. It is always a party concept. It is sometimes also an accounting concept. It is sometimes also an order concept. It is sometimes also a product concept. It is sometimes also a human resources concept.
That said, Adding screens for simpler support in an order is a good idea. Moving screens (adding it in one place and removing it from another) is a bad idea because you're taking away support. In addition a price list is generally not a term of an agreement (contract), it is an exhibit. If you wanted to show that a price from a supplier was contract based, you would have a join entity between AgreementTerm and SupplierProduct. (A lot of this confusion comes from the fact that products for sale are treated differently than supplier products. This might even be easier if supplier pricing was moved over to the rest of the product stuff, but that is perhaps off topic for now). SupplierProductAgreement entity would have as fields, agreementId, agreementTermSeqId, productId, price, currencyUomId, fromDate, thruDate. agreementId and agreementTermSeqId, would reference the term that specificies the exhibit, productId would reference the supplier's productId, fromDate and thruDate would be the time periods of the pricing. Price and currencyUomId are only there as solutions to supplier product being treated differently from products for sale. re: jacopo's comment about moving SupplierProduct fields to agreement, they would be better moved to the Product entity stuff as they only have something to do with an agreement when an agreement document exists. I understand the want in making it easy to do this. The solution in making it easy is through the creating the presentation and business logic to support it, not in changing the data model. Thanks for listening :) --- Rodrigo Aguinaga <[EMAIL PROTECTED]> wrote: > Yes it does makes sense, but this would be like a > big change in the > agreement concept I think (it started as a > accounting feature), but since > it's going to be move to order managment, I belive > this change could be done > with this modifications. > > Now that you mentioned the supplier product entity, > I wanted to know if > theres like a supplier price list that groups this > entites. I haven't found > it and I actually belive there isn't, so it would be > a good thing to add > this feature, what do you think?? > > -- > Rodrigo > > > > 2006/9/2, Jacopo Cappellato <[EMAIL PROTECTED]>: > > > > Hi Rodrigo, > > > > at the moment agreement prices are only considered > in "sales" > > agreements: in its current implementation, the > prices set in the > > SupplierProduct entity are the only one considered > when you create > > purchase orders. > > However I think that it's time to review the role > of the SupplierProduct > > entity in the system: this entity has some fields > that could be moved to > > the Agreement* entities but also has some advanced > features not > > currently implemented in the Agreement* stuff (for > example the prices > > per quantity)... > > The first simple thing we could implement is this: > > in the "calculatePurchasePrice" service, add a new > optional input field > > - "agreementId" - and if a valid SupplierProduct > record is not found > > then the price from the agreement is returned. > > Does it make sense? > > > > Jacopo > > > > > > Rodrigo Aguinaga wrote: > > > Yes, I see. And seems to be completely > integrated, it's just that I > > haven't > > > take a look into this functionality in a very > long time, so I didn't > > > realize > > > the products part just the terms part. > > > > > > I've been trying to create a PO from a Agreement > but I haven't been able > > to > > > use the products from the agreement (I mean > their prices), it's just > > that > > > the don't show up when I create the order, so I > thougth that they could > > be > > > on the shopping list and they were not. So I > manually add one of the > > > products, but the unit price is the one from the > supplier, not the one > > > defined on the agreement. > > > > > > I think I must be doing something wrong or maybe > there is a bug here, so > > if > > > somebody could give some directions on this > issue I would appreciate it. > > > > > > Rodrigo > > > PS. I do belive that move this function to > orger manager it's a good > > idea, > > > but someone with accounting admin privileges, > should also be able to > > modify > > > this, since there are agreement types like > employment and all the > > agreement > > > terms options that they should take a look into. > > > > > > 2006/9/2, David E Jones > <[EMAIL PROTECTED]>: > > >> > > >> > > >> These are represented in OFBiz using > Agreements. You can specify > > >> products and agreed on prices and there is a > lot of support for > > >> creating POs from these. Agreements are in the > Accounting Manager > > >> right now, but we plan to move them to the > order manager soon. > > >> > > >> -David > > >> > > >> > > >> On Sep 1, 2006, at 3:24 PM, Rodrigo Aguinaga > wrote: > > >> > > >> > Hi, > > >> > > > >> > I wanted to know if there's a way to define > a PO contract ( or > > >> > open PO ) > > >> > on OFBiz. > > >> > What I mean as PO contract, it's a "PO" that > could be used many > > >> > times with > > >> > the same supplier and the same prices (at > least on a define period > > >> > of time). > > >> > Let's say I always buy supplies on each end > of month and I would > > >> > like to > > >> > create the PO every time, so what this does > it's to have a pre- > > >> > build PO so > > >> > you can enter the date and release it. > > >> > I think that it could be done like a new > type of Quote, one that > > >> > after you > > >> > create a PO from it, let's you create > another. > > >> > If this doesn't exist I would like to open a > JIRA about it, so > > >> > please let > > >> > me know what you think. > > >> > > > >> > > > >> > -- > > >> > Rodrigo Aguinaga Lira > > >> > > >> > > > > > > > > > > > > > -- > -- > Rodrigo Aguinaga Lira >
