[16] product_margin_classification changes template list_price instead of variant_extra_price
Hi guys,
In the current implementation, product_margin_classification is completely unusable for products with variants that have different costs. Changing the sale price of a variant will change the sale price of all the other variants.
How to reproduce in runboat:
-
create a new attribute "Pins", radio, dynamically. Add 3 values: 5,10,15
-
create a new product "Test1", at Attributes and Variants select Pins, add all 3 values
-
make a new sales order, select product Test1, when popup appears, select Pins - 5. Repeat to create all 3 variants.
-
go to the Test1 template, set list_price 50$.
-
click on 3 Variants, edit each and set cost the same as pins value. After it should look like this:
-
go to margin classifications, create a 33% margin like this:
- go to Inventory - Products - Product variants, select Test1 with Pins: 5 and set the margin classification
- click on Decrease price
What I expected to happen:
- variant_extra_price to be set at -42.5 resulting in a sales price of 7.5 for the variant and the sale price of the other variants to remain unchanged
What happens:
- list_price of the template Test1 is set to 7.5 affecting the sales price of all the other variants
- now if I go to another variant, select the same classification and set the price:
This changed the price for the 5 pin version as well:
Proposed fix
def use_theoretical_price(self):
for product in self:
product.lst_price = product.theoretical_price
should be
def use_theoretical_price(self):
for product in self:
product.variant_extra_price = product.theoretical_price - product.list_price
From my very limited experience, lst_price should not be edited directly as it affects the template list_price. Every modification of a variant's price should be via variant_extra_price. Can anyone with more experience chime in?
There hasn't been any activity on this issue in the past 6 months, so it has been marked as stale and it will be closed automatically if no further activity occurs in the next 30 days. If you want this issue to never become stale, please ask a PSC member to apply the "no stale" label.
Could you provide a patch, with according new tests ?
thanks !