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
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
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
A discount on products with different taxes will result in as many discount
lines as there is different taxes.
Before this commit, removing one of these lines would not do anything else.
Then, recomputing the coupon would regenerate/add back this line.
On e-commerce, it means you would never be able to remove the program by
deleting its reward lines if there are multiple taxes (and so multiple lines)
since it would `recompute_coupon_lines` right away, adding it back directly.
Now, this commit will ensure that removing one of these lines will also remove
the other ones coming from this program on other taxes.
It means removing a regular product will remove it's reward line that will also
now remove the other program's discount line on other taxes and ultimately will
remove the program from the SO since all the program reward lines got removed.
(It won't affect auto applied program since it will be regenerated afterward)
task-1866977
Related to #2224
Previous commit fixed some bugs on `sale_coupon` (#2224).
This commit add some tests to be sure these bugs are fixed and won't appear
again.
task-1866977
Related to #2224
PURPOSE
=======
1. Unified product demo data
2. Less demo: one per use case
3. Demo data for all models
Specification
=============
1. Refactor all the brol in the demo data
2. Adapt the tests to make them green, as some products are
renamed, removed, created in python instead of as demo data
...
Before this commit:
1. With a coupon set on 'specific_product', the discount amount was multiplied
by the product quantity twice.
(Introduced by a42c27f which apply discount on the full price by using
price_total (already multiplied by quantity) over price_unit.
2. With a coupon set on 'cheapest_product', the discount was not discounting taxes.
3. With a coupon set on 'cheapest_product' and `sale_coupon_delivery` installed, it
would simply crashes and throws an error since `sale.order.line` has no
`program_id` attribute.
Now:
1. We no longer multiply by the quantity twice;
2. We apply discount on the full price (with taxes);
3. We use correct attribute to avoid crash.
opw-1830986
Commit a42c27f99e0061b7c4f recently fixed some bugs on sale_coupon.
This commit add some tests to be sure theses bugs are fixed and won't appear
again.
This closes#1744
Purpose
=======
Currently we are updating the coupon rewards on the fly when creating/modifying/deleting a sales order line.
To avoid multiple searches on res_partners and product to know whether the customer/product is valid on the sale coupon program, we store the applicable customers and products on the program according to the domain defined on it.
This brings 2 issues:
- The customers/products stored on the program are not updated (Was the original spec)
- The checks are numerous and maybe overkill for the given results
Specification
=============
- Don't recompute the reward lines on SO modifications. Add a button to compute the line by hand and make an automatic compute on the SO validation or on the page shop/payment.
- When recomputing the reward lines, make a search on the res_partners and products instead. Now that the action is not triggered so often we can afford to make a search.
- Don't use the fields rule_partners_domain and rule_products_domain. This should be removed in master.
- The field is_public_included is useless now. And we decided to make the coupon available for all the partners if they fit the domain on the program.
Introduces 2 new concepts:
Promotion programs:
===================
Using promotion programs allows you to propose to your customers:
- Promotional offers limited in time or a limited order number.
- Public code printed in advertisements, magasines, etc.
- Specific offers based on a customers group or a product set.
- A combination of the preceeding points.
You may choose to apply the program reward immediately on the sales order or to propose the reward for a next order. In the second case a coupon will be generated at the order confirmation for the customer to use it later.
Coupon programs:
================
Using coupon programs allows you to propose to your customers:
- Free products or discounts if some conditions on products or purchased amount are met.
- Promotional offers limited in time.
- Generate coupons for a customers group.
- Specific offers based on a customers group or a product set.
- A combination of the preceeding points.
A coupon is applied by entering a valid code if the program rules are met and if the reward is already in the order lines.
Christophe Simonis