The coupon program applies only one rule based on the sequence.
Steps to reproduce the bug:
Create a promotion with 5% if untaxed amount is greater than 1,000$
Create a promotion with 10% if untaxed amount is greater than 2,000$
Create a promotion with 15% if untaxed amount is greater than 3,000$
Create a SO for 3500$
Click on "Update Promotions"
Bug:
The 5% promotion is applied because it is the first one in the list.
Solution:
Display the sequence field in the list view with a handle to sort the different
promotions.
closesodoo/enterprise#3209
The copy() is unnecessary, and it is introducing an issue because
product.template.attribute.value are not created correctly for copied templates.
The test can be done on the original data, the transaction is going to be
reverted either way.
closesodoo/enterprise#3301
This commit complements the removal of pycompat PY2 helpers and shims
from base by removing / adapting references to these helpers from the
enterprise code.
Before this commit:
When a coupon_program's coupon was giving a reward on a SO and then the
recompute was removing that reward (eg the SO did not met the requirements
anymore) the coupon would not be reset and would be lost.
Now:
If a coupon's reward got removed for some reason, the coupon got reset to a
valid state (`new`) so it can be used again.
Step to reproduce:
- Generate a coupon from a coupon program that needs requirements (eg $300)
- Add that coupon to a SO that has a total over $300
- Coupon is set as `used` and the reward is granted
- Remove some products to set the SO total below $300
- Recompute coupon, the reward is correctly removed but the coupon is still
set as `used` so it won't be usable again and is basically lost.
Closes#3062
Before this commit:
If a reward had been given on the SO with a coupon_program code and that the
program had requirements and that these requirements are not met anymore,
recomputing the SO would not remove the reward.
Now:
If the SO does not met the program requirements anymore, we remove the reward
Step to reproduce:
- Create a coupon_program with quantity or amount requirements (eg: $200)
- Generate a coupon for that program
- Add $200 worth of products (matching the program domain) in the SO
- Add the generated coupon to that SO
- You should get the reward as you have $200 in the SO
- Remove some products from the SO to go below $200
- Recompute coupons, the reward won't be removed
Closes#3062
Before this commit:
We would never unvalid a `next_order` program (and thus it's generated coupon)
Now:
We also retrieve applied `next_order` programs as we need to check if they are
still valid too
Step to reproduce:
- Create a program on `next_order` that require $300
- Add $300 worth of product on a SO
- Apply program, it will generate a coupon
- Make the SO total go below $300
- The generated coupon is still Valid and the client will receive that coupon
even if it is not supposed to anymore
Closes#3062
Before this commit:
1. We were checking if the rewards were in the SO even if it was 'next_order'
program.
2. We were deducing the rewards quantity for 'next_order' program when checking
if we had enough products to meet the program requirements.
Now:
1. We don't verify if the reward is on the SO if the program is 'next_order'
2. We don't deduce reward quantity when checking if enough products to meet the
program requirements if the program is 'next_order'
opw-1907211
Closes#3062
Before this commit:
Everytime the SO met a 'on_next_order' program requirements, a coupon would be
generated on that SO. Even if there was already a coupon for that program set to
'expired', for instance when the SO did not met the requirements anymore.
Now:
When the requirements are met, it checks that an `expired` coupon does not
already exist.
It it does, it will set that coupon back to `reserved` state.
Step to reproduce:
- Create a program on `next_order` with requirements, eg $300 amount
- Create a SO and add $300 worth of products
- Update promotion, a coupon is created and set to `reserved`
- Now update the SO to go below $300
- Update promotion, the coupon is set to `expired` as it should
- Update again the SO to meet the $300 requirements again
- Update promotion, a new `reserved` coupon is generated instead of updating
the state of the previous one from `expired` to `reserved`
Closes#3062
This optimizes the confirmation of a sale_order in the ecommerce by ~73%,
for a cart with 160 unique items, the processing time goes from
7m46s to 39s, which is roughly the same amount of processing time if the
module `sale_coupon` is not installed.
This optimization is achieved in two steps:
1. By validating promotional/discounted products in batch instead of
validating each product one at a time.
2. By performing an unlink() on invalid reward lines instead of sending
a delete command by writing to the one2many, as delete commands are not
(yet) performed in batch, which means record recomputation after every
delete.
opw-1893277
This optimizes the confirmation of a sale_order in the ecommerce by ~73%,
for a cart with 160 unique items, the processing time goes from
7m46s to 39s, which is roughly the same amount of processing time if the
module `sale_coupon` is not installed.
This optimization is achieved in two steps:
1. By validating promotional/discounted products in batch instead of
validating each product one at a time.
2. By performing an unlink() on invalid reward lines instead of sending
a delete command by writing to the one2many, as delete commands are not
(yet) performed in batch, which means record recomputation after every
delete.
opw-1893277
closesodoo/enterprise#2905
Steps to reproduce the bug:
- Create a promotion program P with a fixed amount discount
- Set a customer tax T on the discount product generated for P
- Create a SO with one line
- Apply the promotion program by clicking on "Update promotions"
Bug:
The SO line with the discount product is generated but the tax T was missing.
opw:1888484
Purpose
=======
display_name is equal to doing name_get()[0][1]
Replacing name_get()[0][1] by display_name could be good for 2 things:
- Uniformization of the code
- Probable optimization if name_get is used inside a for loop on a recordset (as the values will be prefetched and put in the cache).
TaskID: 1849250
closesodoo/enterprise#2515
Commit 092200073 broke the discount computation for discount of type
fixed_amount. Indeed the appropriate method was not called anymore and such
discount type would be computed as percentage discount with default value of
10% (field default for percentage).
opw-1888484
This commit adapts the business code to changes introduced by
the change to related field's default readonly value in order to
keep the same behaviour as before.
All readonly=False fields will have to be checked afterwards to confirm
that the business case requires write access to the source field.
Purpose of this commit is to give description more "business oriented"
because those descriptions appears in Odoo Studio which is supposed to be used by end users, not only by developers.
Related Task ID : 37311
67c3de295e9 wrongly adapt coupon to multi-websites as website references should
have been written in website_sale_coupon and not sale_coupon.
Closes#2673
Using a pricelist set as `without_discount` will show a strikethrough price on
reward line (discount and free product).
This is happening because the program reward line (discount_line_product_id) is
created with the default 1$ price as this price is not usefull when computing
coupons. Only the line price is checked.
Now, we create a reward line with a -1 000 000$ price to prevent this UI
behavior.
Step to reproduce:
- Activate pricelist (Sales>Config>Settings>Pricelist formulas)
- Activate discounts in Sales Configuration (Manual discount on order lines)
- Set pricelist to 'Show public price & discount to the customer'
- Add a discount in your cart
- There in a strikethrough price of $1 above the discount line price
task-1878245
Christophe Simonis