Bug in purchase order creation

[Anne Jessel]

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.

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

[BJ Freeman]

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.
>

[BJ Freeman]

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.
>>
>
>

[Anne Jessel]

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 <[hidden email]> 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.
>>>
>>>
>>
>>

--
Coherent Software Australia Pty Ltd
PO Box 2773
Cheltenham Vic 3192
Phone: [phone]
Fax: [phone]
Web: http://www.cohsoft.com.au/
Email: [hidden email]

Bonsai ERP, the all-inclusive ERP system
http://www.bonsaierp.com.au/

[BJ Freeman]

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<[hidden email]>  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.
>>>>
>>>>
>>>
>>>
>
>

[BJ Freeman]

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<[hidden email]> 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.
>>>>>
>>>>>
>>>>
>>>>
>>
>>
>
>