Hi Chris,
Chris Howe wrote:
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.
This is fair.
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.
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.
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'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 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.
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.
:-)
Jacopo
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
