let me approach then from the top.
when a party is created an agreements blank Agreement should be created.
I use _NA_ agreement.
once a role is assigned then template should be copied to the party that
is appropiate for that party.
This next is optional in current systems, but will be mandatory in the
Setup of ofbiz, the agreement should be filled out to a level. This
maybe already in the template but should be should be reviewed.
this is different than the flow of ofbiz,but the products for a supplier
should be handled at this timme. The product link to to their products
not necessarily the product sold.
when a product to be sold is entered then a link to the Supplier and the
product in their agreement is selected.
the price component is updated from the agreement. If it is already
filled in because more than one supplier the price componets is update
based on the custom service.
in short term schedule server that checks all parties has a agreement
would allow a upgrade path and solve you problem.
=========================
BJ Freeman
Strategic Power Office with Supplier Automation
<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
BJ Freeman sent the following on 1/9/2011 3:13 AM:
Pricing component in the book is ProductPrice
and partyrelationship and roles should define a supplier and the product
not have a supplierproduct.
Use the Productassoc (pgn98 and page103).
for supplier pattern use (page 102)
but current pattern does not support this.
So maybe refactore the supplierproduct to more pattern in page 102
=========================
BJ Freeman
Strategic Power Office with Supplier Automation
<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com <http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Anne sent the following on 1/8/2011 7:09 PM:
Thank you for your responses, BJ. I was at first confused by what you
said,
and after a lot more research it looks like the Agreements for
purchases are
very different to those for sales. This does not agree with my
understanding
of the data model book. Based on the datamodel book, I was expecting
sales
agreements and purchase agreements to be basically the same, but with
to and
from parties around the other way. I had sorted out sales agreements a
long
time ago, and therefore thought purchase agreements wouldn't take
long. :-(
More importantly, the way purchase pricing agreement details are
stored in
OfBiz is not useful to me (nor, I would have thought, many
businesses). I am
hoping I have misunderstood. Here is a summary of the main points as I
understand them:
datamodel book: (fig 4.15, p154)
Agreement Item relates to Price Component holding the agreed price,
for both
sales and purchase agreements
OfBiz:
AgreementItem relates to AgreementProductAppl for a sales agreement
(AgreementProductAppl can be thought of as a type of Price Component, so
matches book)
AgreementItem relates to SupplierProduct for a purchase agreement.
SupplierProduct is not a type of Price Component, so different to book.
Some problems with using SupplierProduct to hold the agreed price:
1) SupplierProduct holds the lastPrice the product was supplied at,
and is
updated (I think) when goods are received. So any agreed price will be
lost
if a one-off special price is used for a single shipment
2) I can't see a way to record a history of changes to supplier prices,
agreed or otherwise.
3) A new agreed price can only be created by deleting or updating the old
agreement, as the SupplierProduct entity can't hold both old and new
prices
at the same time.
I thought of creating new SupplierProduct entities, but the primary key
wouldn't allow this.
Item 3) means that if a supplier says "from Feb 1 our agreed price for
gizmo
product changes from 2.50 to 3.00", we can't record that until Feb 1. And
when we do, we lose any record of the old price.
Have I understood correctly? If so, are there any advantages to using
SupplierProduct in this way, or things I have missed that will avoid the
problems?
Cheers,
Anne.
On 9 January 2011 06:37, BJ Freeman<bjf...@free-man.net> wrote:
as a side note
agreements are generated in setup of the company based on roles.
These are
template agreements that are determined by the business model they use.
these templates are in the accounting/data (yet to introduced by
jira) and
pulled when the company party is created, during setup.
the time to create and agreement is when the party is created.
the autocreateagreements was generated to fill in the logic in many
places.
so when a supplier role party is created sets up the Party
relationship as
well.(page 43 datavolume book.) and it copies the template agreement
(page
145)
so the bug is not where you are but in the create party role type
supplier.
=========================
BJ Freeman
Strategic Power Office with Supplier Automation<
http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com<http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
BJ Freeman sent the following on 1/8/2011 7:31 AM:
that is the solution I use.
auto create a agreement(s) based on the first order.
In the autocreateAgreement It gets the default Currency from
partyid,preference passed in, if one exist, if not then
Organization Party Id (company) AccountingPreferences
if all failes then it send the user to the accounting agreemments
screen
to have it filled in.
=========================
BJ Freeman
Strategic Power Office with Supplier Automation
<http://www.businessesnetwork.com/automation/viewforum.php?f=52>
Specialtymarket.com<http://www.specialtymarket.com/>
Systems Integrator-- Glad to Assist
Chat Y! messenger: bjfr33man
Anne sent the following on 1/8/2011 1:45 AM:
Hi
I think I've found a bug in purchase order creation, and would
appreciate
some advice as to the best solution.
The following lines can be found in setOrderCurrencyAgreementShipDates
method in org.ofbiz.order.shoppingcart.ShoppingCartEvents.java,
near line
1784:
// set the agreement if specified otherwise set the currency
if (UtilValidate.isNotEmpty(agreementId)) {
result = cartHelper.selectAgreement(agreementId);
} else if (UtilValidate.isNotEmpty(currencyUomId)) {
result = cartHelper.setCurrency(currencyUomId);
}
So if agreementId is not empty for a purchase order, the currency
is not
set. This causes problems when trying to add an item to the cart. The
ShoppingCart calls its getSupplierProduct method to check for a
suitable
SupplierProduct entity. This check fails because it uses the
currency as
part of this check.
I am assuming that the specific non-setting of currency when an
agreement
exists was done on purpose, and hence the correct fix is *not* to
set the
currency whether or not there's an agreement. However if that is
correct,
should the cart be getting a currency some other way, or should the
getSupplierProduct method not insist on currency being set? Or is the
data
expected to be set up differently than the way I have it set up?
I can't find any use of agreements with purchase orders OOTB, so I've
set up
test data based upon the sales order agreements, but with from and to
around
the other way.
Cheers,
Anne.
