Odoo Addons (MOVED TO GITHUB)

PO does wrongly take into account supplier information in product when using purchase UOM

Series 5.0
Bug #423124

Bug #423124 reported by Jan Verlaan on 2009-09-02

This bug affects 4 people

	Status	Importance	Assigned to	Milestone
Odoo Addons (MOVED TO GITHUB)	Status tracked in Trunk
5.0	Triaged	Undecided	Unassigned
Trunk	Fix Released	Low	OpenERP R&D Addons Team 2	Odoo Addons (MOVED TO GITHUB) 6.0

Bug Description

SITUATION IDENTIFIED IN:
Purchase order, price calculation of order line.

REPRODUCTION ENVIRONMENT:
Stable version 5.0.3 via bazaar updated today via bazaar.
revision-id: <email address hidden>
date: 2009-09-01 18:56:12 +0530
build-date: 2009-09-02 13:37:30 +0200
revno: 2372
branch-nick: addons

PROBLEM DESCRIPTION:
When using different product UOM's for storage and purchase, the price calculation for purchase order line is wrongly computed when making use of supplier information

SPECIFIC PARAMETER SETUP:
Go pricelist on PO --> Select the pricelist version --> Select Pricelist item.
Set based on selection field to be ''Partner section of the product form'.
See https://answers.launchpad.net/openobject-addons/+question/74021 where this process is answered.

STEPS TO BE FOLLOWED:
Create a product with storage unit is pair ( defined as 2 pcs) and purchase unit is Box (defined as 30 pcs = 15 pairs)
A Box of 15 pairs costs to purchase 47,93 euro excl. tax, resulting that a pair costs 3.1953333 euro.
The cost price of this product is stored as pair and rounded to 3.20 euro. No problem as we can set in purchase supplier information on the third tab that we purchase 1 box for 47,93 euro.

OBSERVED RESULT:
The PO is not taken into account the purchase unit. It will calculate always on storage unit, not on the purchase unit. This will result in using always rounded purchase prices of 3.20 euro, and not the 47,93 euro for 1 box. This way we never get the right purchase price on the purchase order.

EXPECTED RESULT:
That purchase price calculation will be based on the purchase unit defined in the product and that the supplier information does take the purchase unit into account (instead of the storage unit).

ADDITIONAL COMMENTS:
Tested on standard Manufacturing environment and Manufacturing environment with account_anglo_saxon module installed.
Please check when providing a standard solution if account_anglo_saxon needs a modification too (you may contact hda internally for this if needed).

Related branches

lp://staging/~openerp-community/openobject-addons/jan@synkronized.be_5.0-fix

lp://staging/~openerp-dev/openobject-addons/rpa-dev-addons2

Merged into lp://staging/~openerp-dev/openobject-addons/trunk-dev-addons2 at revision 3987

OpenERP Core Team: Pending requested 2011-01-25

lp://staging/~openerp-dev/openobject-addons/trunk-dev-addons2

Rejected for merging into lp://staging/~openerp/openobject-addons/trunk-fix-osvmem-read

OpenERP Core Team: Pending requested 2011-02-07

Diff: 18513 lines (+5368/-1663)

160 files modified

account/account.py (+1/-1)
account/account_bank_statement.py (+1/-3)
account/i18n/gl.po (+4/-2)
account/i18n/it.po (+24/-5)
account/i18n/pt_BR.po (+7/-3)
account/i18n/ru.po (+64/-46)
account/i18n/zh_CN.po (+14/-12)
account/invoice.py (+1/-60)
account/project/project_view.xml (+2/-2)
account/report/account_balance.py (+2/-2)
account/report/account_balance_landscape.py (+0/-1)
account/report/account_balance_sheet.py (+2/-2)
account/report/account_partner_balance.py (+0/-1)
account/report/account_profit_loss.py (+2/-2)
account/wizard/account_state_open.py (+1/-1)
account/wizard/account_use_model.py (+1/-1)
account_accountant/i18n/gl.po (+37/-0)
account_analytic_analysis/i18n/gl.po (+17/-10)
account_analytic_default/i18n/gl.po (+34/-13)
account_analytic_default/i18n/hu.po (+4/-4)
account_analytic_plans/i18n/gl.po (+70/-36)
account_analytic_plans/i18n/hu.po (+6/-6)
account_budget/i18n/zh_CN.po (+18/-18)
account_cancel/i18n/gl.po (+37/-0)
account_followup/i18n/pt_BR.po (+76/-43)
account_invoice_layout/i18n/hu.po (+18/-4)
account_payment/wizard/account_payment_create_order_view.xml (+1/-0)
account_voucher/account_voucher.py (+0/-2)
account_voucher/voucher_payment_receipt_view.xml (+1/-1)
analytic/analytic.py (+5/-5)
association/i18n/hu.po (+11/-4)
auction/i18n/es.po (+7/-7)
base_calendar/i18n/es_EC.po (+39/-35)
base_calendar/i18n/hu.po (+16/-16)
base_contact/i18n/ro.po (+4/-4)
base_iban/i18n/ro.po (+9/-4)
base_module_quality/i18n/hu.po (+3/-3)
base_module_quality/i18n/pt_BR.po (+22/-2)
base_report_creator/i18n/hu.po (+35/-26)
base_report_creator/i18n/zh_CN.po (+6/-6)
base_report_designer/i18n/hu.po (+4/-4)
base_report_designer/i18n/zh_CN.po (+12/-2)
base_setup/i18n/hu.po (+20/-19)
base_vat/i18n/hu.po (+4/-3)
board/i18n/gl.po (+37/-37)
board/i18n/hu.po (+6/-6)
crm/i18n/hu.po (+34/-32)
crm/i18n/pt_BR.po (+5/-5)
crm_caldav/i18n/pt_BR.po (+5/-5)
crm_claim/i18n/hu.po (+4/-4)
crm_claim/i18n/pt_BR.po (+1/-1)
crm_claim/i18n/tr.po (+749/-0)
crm_fundraising/i18n/hu.po (+8/-8)
crm_fundraising/i18n/pt_BR.po (+1/-1)
crm_helpdesk/i18n/hu.po (+5/-5)
crm_partner_assign/i18n/hu.po (+17/-13)
crm_partner_assign/i18n/pt_BR.po (+1/-1)
crm_profiling/i18n/hu.po (+3/-3)
crm_profiling/i18n/pt_BR.po (+1/-1)
crm_profiling/i18n/sv.po (+1/-1)
decimal_precision/i18n/hu.po (+3/-3)
delivery/i18n/hu.po (+54/-35)
document/i18n/hu.po (+12/-12)
document_ftp/i18n/hu.po (+5/-5)
document_ics/i18n/hu.po (+6/-4)
document_webdav/i18n/hu.po (+3/-3)
email_template/i18n/hu.po (+6/-4)
email_template/i18n/pt_BR.po (+1/-1)
event/i18n/hu.po (+25/-16)
event/i18n/pt_BR.po (+24/-6)
event_project/i18n/hu.po (+4/-4)
hr/i18n/hu.po (+36/-28)
hr_attendance/i18n/hu.po (+12/-12)
hr_contract/i18n/hu.po (+15/-11)
hr_evaluation/i18n/hu.po (+3/-3)
hr_expense/hr_expense.py (+3/-2)
hr_expense/i18n/hu.po (+10/-9)
hr_holidays/hr_holidays.py (+3/-3)
hr_holidays/hr_holidays_view.xml (+1/-0)
hr_holidays/i18n/hu.po (+3/-3)
hr_holidays/report/available_holidays_view.xml (+1/-0)
hr_payroll/i18n/hu.po (+50/-40)
hr_payroll/report/report_payroll_advice.rml (+2/-2)
hr_payroll_account/i18n/hu.po (+10/-9)
hr_payroll_account/i18n/it.po (+4/-4)
hr_recruitment/__openerp__.py (+1/-1)
hr_recruitment/i18n/hu.po (+16/-16)
hr_timesheet/i18n/hu.po (+22/-11)
hr_timesheet_invoice/i18n/hu.po (+7/-7)
hr_timesheet_sheet/i18n/hu.po (+51/-13)
idea/i18n/hu.po (+10/-7)
knowledge/i18n/hu.po (+17/-5)
l10n_ch/i18n/pt_BR.po (+4/-4)
l10n_ch/test/l10n_ch_report.yml (+8/-4)
l10n_ch/wizard/create_dta.py (+1/-1)
l10n_fr/fr_pcg_taxes_demo.xml (+3/-3)
marketing_campaign/i18n/hu.po (+3/-3)
membership/i18n/hu.po (+3/-3)
membership/i18n/pt_BR.po (+29/-29)
mrp/i18n/es_AR.po (+140/-101)
mrp/i18n/hu.po (+47/-43)
mrp/i18n/ro.po (+207/-90)
mrp/mrp.py (+2/-1)
mrp_operations/i18n/hu.po (+7/-7)
mrp_operations/i18n/ro.po (+31/-17)
mrp_repair/i18n/hu.po (+8/-8)
mrp_subproduct/i18n/hu.po (+3/-3)
multi_company/i18n/hu.po (+18/-3)
pad/i18n/hu.po (+3/-3)
process/i18n/hu.po (+3/-3)
procurement/i18n/hu.po (+8/-8)
procurement/i18n/nl.po (+98/-68)
procurement/i18n/ro.po (+4/-4)
procurement/procurement_view.xml (+3/-2)
product/i18n/hu.po (+7/-7)
product/i18n/id.po (+105/-55)
product/i18n/pt_BR.po (+4/-4)
product/i18n/ro.po (+9/-7)
product/i18n/zh_CN.po (+3/-3)
product/pricelist.py (+1/-1)
product_expiry/i18n/tr.po (+176/-0)
project/i18n/hu.po (+4/-3)
project_mrp/project_procurement.py (+1/-1)
purchase/purchase.py (+1/-1)
purchase_analytic_plans/i18n/hu.po (+5/-5)
purchase_requisition/i18n/ca.po (+410/-0)
report_designer/i18n/ca.po (+98/-0)
report_intrastat/i18n/hu.po (+16/-12)
report_webkit/i18n/ca.po (+560/-0)
report_webkit_sample/i18n/ca.po (+143/-0)
report_webkit_sample/i18n/hu.po (+6/-6)
resource/i18n/ca.po (+346/-0)
sale/i18n/hu.po (+65/-14)
sale/i18n/pt_BR.po (+4/-4)
sale/i18n/ro.po (+6/-6)
sale/sale.py (+19/-15)
sale_analytic_plans/i18n/hu.po (+8/-4)
sale_crm/i18n/hu.po (+10/-9)
sale_journal/i18n/hu.po (+33/-2)
sale_layout/i18n/ca.po (+292/-0)
sale_layout/i18n/hu.po (+26/-16)
sale_layout/i18n/ro.po (+5/-5)
sale_margin/i18n/hu.po (+16/-7)
sale_mrp/i18n/ca.po (+66/-0)
sale_mrp/i18n/hu.po (+4/-4)
sale_order_dates/i18n/ca.po (+70/-0)
stock/i18n/hu.po (+20/-16)
stock/i18n/id.po (+32/-29)
stock/i18n/ro.po (+92/-92)
stock/i18n/zh_CN.po (+23/-23)
stock/stock.py (+12/-10)
stock/wizard/stock_invoice_onshipping.py (+2/-2)
stock/wizard/stock_location_product.py (+1/-1)
stock/wizard/stock_partial_picking.py (+19/-3)
stock/wizard/stock_return_picking.py (+1/-1)
stock_planning/i18n/hu.po (+36/-27)
subscription/i18n/hu.po (+5/-5)
survey/i18n/hu.po (+15/-14)
warning/i18n/hu.po (+15/-15)
wiki/i18n/hu.po (+3/-3)

Merged into lp://staging/openobject-addons at revision 4493

OpenERP Core Team: Pending requested 2011-02-03

Revision history for this message

Husen Daudi (husendaudi) wrote on 2009-09-03:

Hello jan,
I have following configuration for my product A.
Default UOM : 2PCS
Category : Unit
Rate: 0.5
rounding : 0.01

Purchase UOM: 30pcs
Category : Unit
Rate: 0.033333
rounding : 0.01

Cost Price of product A is 3.20.
Now I have created PO and select product A.
by selecting product A I am getting
Product UOM : 30PCS
Unit Price : 48.00

It means I am getting correct price for 30PCS.
Tell me if I am testing wrongly and reopen this post.

Changed in openobject-addons:
status:	New → Incomplete

Revision history for this message

Jan Verlaan (jan-verlaan) wrote on 2009-09-03:

Yes I see :-) , your test will give the same result I have when testing the same. :-) :-) 3.20 x 15 2PCS = 48,00

Difference in our test is that I have defined a supplier info record at product level and the pricelist is taken from there.
Into the supplier info record is defined that a box (your 30PCS) cost 47,93
This unit box (your 30PCS) is not taken into account when computing the purchase order line. It handles if it is the storage unit.

The problem that does exist now is that a box of 15 pairs cost real 47,93 thus 3.1953333 per pair.
This is rounded correct by OpenERP to 3.20 for a pair on the product record.
But when generating the purchase order, now it multiply the 3.20 x 15 = 48 instead of taken the purchase unit for this purchase order and the linked defined supplier purchase price which is 47,93
Resulting in always to have to correct manually the corresponding invoices.

Hope I'm clear, do not hesitate to request more explanation if needed.

With kind regards,
Jan

Changed in openobject-addons:
status:	Incomplete → New

Revision history for this message

Husen Daudi (husendaudi) wrote on 2009-09-04:

You mean the pricelist in supplier info field under prices & suppliers tab of product form?

It will not be considered anywhere. Its just for prioritize suppliers. Pricelist in Purchase Order will be consider. I have checked and price is calculated correctly with Purchase pricelist.

Revision history for this message

Jan Verlaan (jan-verlaan) wrote on 2009-09-04:

Correct, I mean pricelist in supplier info field under prices & suppliers tab of product form.
See https://answers.launchpad.net/openobject-addons/+question/74021 where this configuration process is answered.
If setup correctly it will take the above created supplier pricelist.

The fault is that in this case the purchase unit is not taken into account while creating a purchase order. It always takes the storage unit. Resulting in confusion because you buy always a box, but have to store the price in pricelist in storage unit? Resulting in having rounding issues as described in bug registration.

As used everywhere in the program, when purchasing, use the purchase unit and purchase price for this unit if defined.

Revision history for this message

Vinay Rana (OpenERP) (vra-openerp) wrote on 2009-12-02:

Hello Jan Verlaan,

*Create a product with storage unit is pair ( defined as 2 pcs) and purchase unit is Box (defined as 30 pcs = 15 pairs)
=> I want ask you related to storage unit and purchase unit because in product we have 2 field related to UOM one is default UOM and another one is purchase UOM.
=>So I have put PCE as default and new Box as another unit with different rate.
=>So when i will create PO in PO line onchange of product show me purchase UOM by default and as the unit price(taken from supplier information) with UOM factor multiplication and Minimum qty which is also taken from supplier information.

So I got the unit price correct so i don't understand the following problem which you have defined above :

*That purchase price calculation will be based on the purchase unit defined in the product and that the supplier information does take the purchase unit into account (instead of the storage unit).

In Supplier information there is not any field available related to UOM how can you say the following statement :

"the supplier information does take the purchase unit into account (instead of the storage unit)"

Thanks.

Changed in openobject-addons:
status:	New → Incomplete

Revision history for this message

jan@synkronized.be (jan-synkronized.be) wrote on 2009-12-16:

An attempt to redefine the problem.

OpenERP 5.0.6, Manufacturing profile, standard demo data.

Case: I want to buy boxes of shoes (consisting of 15 pairs) at 47.93 € excl. tax. I want to sell them and keep inventory in pairs.

Steps:
Define an new Product: Pair of Shoes
  Default UoM: Pair, Category: Unit, Rate: 0.5
  Purchase UoM: Box, Category: Unit, Rate: 0.033333
  Tab Prices and Suppliers I add a new line for Supplier Information:
    Partner: Asustek
    Minimal Quantity: 1.00
    Pricelist: Quantity:1.00, Unit Price: 47.93 (I assume the Unit Price in the Prices and Suppliers listing refers to the purchase UoM, since we're talking suppliers here)

Change Default Pricelist Line to take prices from the Partner section of the product form

Now, I enter a purchase order for a pair of shoes. The Product UoM shows correctly: Box, but the Unit Price shows incorrectly 718.96

Now, I could change the Unit Price in the tab Prices and suppliers to 3.20 (which would be illogical, since we're talking suppliers here and I'd assume the unit price refers to the purchase UoM). But then purchase order shows a Unit Price of 48 €, which is incorrect.

Cheers,
Jan Blondé

Revision history for this message

Jan Verlaan (jan-verlaan) wrote on 2009-12-16:

Thank you Jan, good write up! Glad we see the same inconsistency.

Changed in openobject-addons:
status:	Incomplete → Confirmed

Revision history for this message

jan@synkronized.be (jan-synkronized.be) wrote on 2009-12-16:

patch_423124.diff Edit (1.7 KiB, text/plain)

Proposed patch

Revision history for this message

Jan Verlaan (jan-verlaan) wrote on 2010-06-03:

#10

See also https://bugs.launchpad.net/openobject-addons/+bug/588663

The minimal quantity define on supplier info is expressed in purchase UOM (see action_po_assign of procurement) but the price on it is expressed in default UOM (see price_get on pricelist).

Revision history for this message

Rucha (Open ERP) (rpa-openerp) wrote on 2010-12-09:

#11

Hello Jan,
Thanks for pointing out,
It has been fixed in lp:~openerp-dev/openobject-addons/rpa-dev-addons2 with
revision-id: <email address hidden> and improved later in <email address hidden> and <email address hidden>

You need to give 1.5977 (which is price of 1pcs) while defining supplier information,
[Also need to change Decimal Accuracy of Purchase Price to 4 in order to get proper price unit in PO line]

Thanks

Revision history for this message

Nathan (nathan-bowden-kiwi) wrote on 2011-08-02:

#12

will we shut this bug down , we use v6 and we find it ok!