Pricing Does Not Work When Multiple UOM On A Product

Bug #716289 reported by Robin (www.cgbs.com.au)
30
This bug affects 5 people
Affects Status Importance Assigned to Milestone
Odoo Addons (MOVED TO GITHUB)
Invalid
Undecided
Unassigned
6.0
Confirmed
Low
OpenERP Publisher's Warranty Team

Bug Description

The price lists enable you to establish pricing on the quantity that is purchased.

Lets imagine that 64 units of an item constitute a pallet. You set up pricing to say that if 64 units are purchased, then there is a discount of say 10% (purchase by the pallet and get a 10% discount).

Now sell 1 pallet to a customer (as you have already set up a UOM with a bigger than reference at a ratio of 64).

The pricing will not give a 10% discount until you sell 64 of any units of measure.

I would have thought that because of the pallet constituting 64 units, that the pricing applied for this single pallet would get the 10% discount.

This pattern can be replicated across all combinations where the UOM is different to the UOS.

This is making it impossible to set up price rules if sell by multiple UOM.

Related branches

Revision history for this message
Robin (www.cgbs.com.au) (robin-cgbs) wrote :

This is happening in [6.0.1 stable].

Revision history for this message
snook (snook) wrote :

+1
Impossible to use pricelist rules based on quantities when multiple UOM exist on a product.

OpenERP pricing code needs to be reviewed urgently before a company burns themselves badly.

Essential for one of our prospects but not possible to demonstrate how this works in OpenERP as unstable at present.

Changed in openobject-addons:
status: New → Confirmed
Revision history for this message
Robin (www.cgbs.com.au) (robin-cgbs) wrote :

Name of bug not moving anyone to acknowledge it. Maybe a rename to actually hilight implications on system MIGHT attract more attention. Changed name of bug from Quantity On Pricelist Not Specific To Unit Of Sale (UOS) to Pricing Does Not Work When Multiple UOM On A Product.

summary: - Quantity On Pricelist Not Specific To Unit Of Sale (UOS)
+ Pricing Does Not Work When Multiple UOM On A Product
Revision history for this message
Amit Parik (amit-parik) wrote :

Hello Robin,

I have tested your scenario with the latest trunk at my end. But it is working fine.

I have created a one product with cost price 1.0 and set it 's Default UOM as a PCE and purchase UOM as a pallet from your scenario.

Then created a purchase price-list related to your scenario and create a purchase order for the 1 pallet and which is give the correct price.

There is 64 PCE=1 pallet and in price-list there is 10% discount for minimum qty for 64 PCE.

So the purchase order take the unit price 57.60 which is correct.

I have attached a video for your reference, So please check it and notify me where you faced the problem.
And would you please provide the proper steps to reproduce this bug.

Thanks.

Revision history for this message
Amit Parik (amit-parik) wrote :
Changed in openobject-addons:
status: Confirmed → Incomplete
Revision history for this message
Robin (www.cgbs.com.au) (robin-cgbs) wrote :

Thank you for your help so far.

The issue has to do with the "stable" version 6, not the trunk. (This was mentioned).

I found that the issue appears to have resurfaced again - https://bugs.launchpad.net/openobject-addons/+bug/595246.

I am getting the factor of the UOM, which was the problem back then.

Hopefully this gives you a clue.

Revision history for this message
Amit Parik (amit-parik) wrote :

Hello Robin,

Thanks for your reply and I am confirming this issue in stable 6.0.

Changed in openobject-addons:
status: Incomplete → Invalid
Revision history for this message
Jay Vora (Serpent Consulting Services) (jayvora) wrote :

Robin,

Thanks for reporting.

This has been fixed in stable 6.0.2 by revision <email address hidden>.

Kindly let me know if you faced regression with any case.

Thanks.

Revision history for this message
Robin (www.cgbs.com.au) (robin-cgbs) wrote :

Jay Vora,

Thanks for attempting to address the issue. However it still remains.

The code seems to handle purchases, which is what you tested in your video.

Notice this line in pricelist.py

    qty_in_product_uom = product_uom_obj._compute_qty(cr, uid, product_default_uom, qty, to_uom_id=seller_uom)

This code converts the qty to qty_in_product_uom.

The problem however is that this is only done for purchases and not sales.

The repercussions of not doing this means the following:

I generally sell CARTONS OF wine. However, sometimes I will break a carton open and sell individual bottles (12 bottles to a carton).

However, when I sell in bottles rather than cartons, I wish to apply a 4% surcharge on the price.

Say a carton is worth $120.00, then I wish to sell bottles of wine for $10.40 each.

To achieve that, I have price rules set up as follows:

Product Min Quantity Sequence Price Discount
    Wine 1 1 0
    Wine 0 5 0.04

You will notice that I am trying to configure OpenERP that if I sell less than a carton, then the surcharge is to apply.

What is happening when I sell 1 BOTTLE is that it is saying that I have met my quantity of 1 and hence not applying the surcharge.

I hope this makes things more clear.

Revision history for this message
Robin (www.cgbs.com.au) (robin-cgbs) wrote :

I am getting the correct results by inserting the code between the XXXXXXXX into product.pricelist.py. The surrounding code just shows the context of where the new code fits in.

                categ_id = products_dict[product_id].categ_id and products_dict[product_id].categ_id.id or False
                categ_ids = _create_parent_category_list(categ_id, [categ_id])
                if categ_ids:
                    categ_where = '(categ_id IN (' + ','.join(map(str, categ_ids)) + '))'
                else:
                    categ_where = '(categ_id IS NULL)'

XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
                # convert sale uom qty into default_uom_qty
                if 'uom' in context:
                    sale_uom = context['uom']
                    product_default_uom = product_template_obj.read(cr, uid, [tmpl_id], ['uom_id'])[0]['uom_id'][0]
                    if sale_uom and product_default_uom and product_default_uom != sale_uom:
                        qty = product_uom_obj._compute_qty(cr, uid, sale_uom, qty, to_uom_id=product_default_uom)
XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX
                cr.execute(
                    'SELECT i.*, pl.currency_id '
                    'FROM product_pricelist_item AS i, '
                        'product_pricelist_version AS v, product_pricelist AS pl '
                    'WHERE (product_tmpl_id IS NULL OR product_tmpl_id = %s) '
                        'AND (product_id IS NULL OR product_id = %s) '
                        'AND (' + categ_where + ' OR (categ_id IS NULL)) '
                        'AND price_version_id = %s '
                        'AND (min_quantity IS NULL OR min_quantity <= %s) '
                        'AND i.price_version_id = v.id AND v.pricelist_id = pl.id '
                    'ORDER BY sequence',
                    (tmpl_id, product_id, plversion_ids[0], qty))
                res1 = cr.dictfetchall()

Please note that in addition to this code, the rounding on the default UOM needs to be set to a 0.001. This ensures that fractions of the default UOM quantity are passed into the query.

I hope this is of some help.

Revision history for this message
Jay Vora (Serpent Consulting Services) (jayvora) wrote :

Robin,

Thanks for coming back on this, I am currently configuring my system as per your example.

A more details steps would be welcomed.

Thanks.

Revision history for this message
Jay Vora (Serpent Consulting Services) (jayvora) wrote :

Robin,

I just rechecked, and I got 0.0 as a price on Sale order.

May I please request you to tell me here the exact configuration with following?
1. Product config Uom,uos, co-eff.
2. pricelist config
3. supplier config of product

Hope this helps.

Thanks.

Revision history for this message
Robin (www.cgbs.com.au) (robin-cgbs) wrote :

I created a new database with demo data.

I installed the CRM, Warehouse Management, Purchase Management, Sales Management, Accounting & Finance Applications.

(png images - screenshots attached in zip file)

Set up a UOM for a Carton - (see 1 - setup of carton uom.png)

Set up a UOM for Bottles - (see 2 - setup of UOM for bottles.png)

Set up the new product (Red Wine) normally sold by the carton. Note default UOM and also Sale Price of $120 - (see 3 - new product config for wine normally sold in carton.png)

Now in the first example I use a price rule against the Default Public Price List Version to sell the Red Wine if selling a full carton. Note the Min Quantity of 1 and the sequence of 1. (see 4 - price rule for red wine at normal price if full carton ordered.png)

I then set another price list rule for a broken carton surcharge of 4% if selling less than a carton. Note sequence of 2 and surcharge of 4%. (see 5 - price rule for red wine broken carton surcharge of 4 percent.png)

Image (6 - default price rule.png) shows that the default rule is left in place and is left with sequence 5.

Notice results on the sales order. One carton of red wine is correctly priced at $120.00. One bottle however is priced at $10.00 per unit, when in fact it should have $10.40 per unit (because of the 4% surcharge). Yet if I sell 0.5 cartons, (6 bottles as a carton), it gets the 4% surcharge. (see image 7 - sale order using default config so far.png)

NOW I REMOVE THE TWO RULES i SET UP IN THE DEFAULT PRICE LIST TO HIGHLIGHT ANOTHER RELATED ISSUE.

The original Public Pricelist is now back to its original format.

I create a new Sale Pricelist called Test Pricelist. I set up similar rules to my original issue, but this time the rules are based on OTHER PRICELIST, in this case the PUBLIC PRICELIST. (see images 8, 9 and 10).

Notice the results of the new sale order based on the new test pricelist. My carton gets the correct price, but my bottles not only do not get the surcharge (when under 12 bottles), but they are also 120 / 12 /12 = 0.83. Factoring has reared its ugly head again. (see image 11 - sale order using pricelist based on another prcielist).

Revision history for this message
Amit Dodiya (OpenERP) (ado-openerp) wrote :

Hello Robin,

Thank you for details, I am working on it.

Thanks.

Revision history for this message
Amit Dodiya (OpenERP) (ado-openerp) wrote :

Hello Robin,

Thanks for providing the fix, we are testing and analyzing more on it.

We will let you know the updates on it.

Thanks.

To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.