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.
Purpose
=======
People doesn't understand that the reward line product is the product that will be used in the discount line, not the product the be rewarded
If they set another product before the program is created, the product they set will be renamed, which is wrong.
Specification
=============
- Don't display the field before it's set
- Make the field readonly on the program form view
Purpose
=======
On a sale coupon program, the allowed partners are the customers by default.
That way, users like the Administrator aren't allowed to use coupon on a fresh database
Specification
=============
Allow all the partners by default and the user restrict the partners as he wishes.
Before this commit:
Coupon Program: Only customers have access to rewards
Promotional Program: Only customers have access to reward and this can be retricted with a domain
After this commit:
Coupon Program: All partners have access to rewards
Promotional Program: All partners have access to reward and this can be retricted with a domain
This is possible that `unlink` is called without any record in self.
In the given case, this is because of
`self.env['sale.order.line'].search([('order_id', 'in', self.ids), ('is_delivery', '=', True)]).unlink()`
in the `undelivery_set` method of the module delivery.
`Unlink` on an empty set is supported, and it should therefore be the case here as well.
This is not because `self.order_id.no_code_promo_program_ids` expects a singleton
for the `self.order_id` part, and this is actually an empty set as `self` is an empty set.
Besides, it makes sense to loop on the lines passed to `self`,
as you could pass several lines, not all having the same
`product_id`, for the above line
`related_program = self.env['sale.coupon.program'].search([('discount_line_product_id', '=', self.product_id.id)])`
opw-746084
The methods delivery_set and delivery_unset are called everywhere (mostly on the ecommerce). The reasons for that is that we do not want several shipping lines on the same order. A better way to achieve this would have been to create the line if it doesn't exist or write on it to modify the 'price_unit' instead.
The side effect of that behavior is:
- A delivery line is set on the order.
- We apply a coupon to get a free shipping
- We go on the payment page. The method _cart_update is called, which calls delivery_set, so delivery_unset. The shipping line is unlinked to create again a new shipping line with the price updated. As the shipping line is removed, a recomputation of the reward lines is made. The program isn't applicable anymore as there's no shipping line on the order. The reward is thus removed.
That way, it's impossible to have a free shipping reward on the ecommerce and achieve the full checkout process.
What's done in this commit:
If a free shipping is applicable by code or if a free shipping can be automatically applied. It will be done with a price of 0.0 if there's no shipping line or the price_unit on the shipping line if set. If the shipping line is removed (every 2 seconds on a checkout process), the reward line is not unlinked and the price is set to 0.0.
That way, it's now possible to make a full flow.
NB: If a line is unlinked on an order, we unlink the reward line if it's the last one set on the order. This is to avoid free shipping line coming back on a new order in the ecommerce even if not applicable.
Use Case
========
In the coupon module, a call to a write, a create or an unlink on a sales order line may trigger a write, a create or an unlink on another line. Example: I have a promotional offer "If you buy for more than 100 euros, you got a 10 percent discount on the sales order. On my sales order, I buy 2 imac at 999 euros. At that moment my total amount is over 1000 euros and I got another line, the discount. I write on the sales order line that I only buy one imac, a unlink is trigger on the reward line to remove it from the sales order.
Current Solution
================
At the beginning, I was overwriting the write, the create and the unlink methods on the sales order line to perform the correct actions according to the promotional offers that were still applicable, not applicable anymore of newly applicable. This solution was followed by side effects on the computed fields. For example, a write on the SO line that was triggering an unlink on another line was triggering a computed field that depended on the sales order line. In that case, the environment I received on the compute method was the environment before the line unlink. As the compute method was looping on the sales order line, it was taking values on a line that wasn't existing anymore and that way it was triggering an 'This record doesn't exist or has been deleted' error.
After a discussion with @rco-odoo, we realized that the only way to achieve this was to override the write method on a sales order to avoid quadratic computation loop when creating/editing/deleting sale order lines. As coupon are recorded as sale.order.line, it may effectively blow up.
We also overrode the create method on a sales order line to make an ORM command on the sales order instead of a simple create on the sales order. See: https://github.com/odoo/enterprise/blob/saas-14/sale_coupon/models/sale_order.py#L253
For the write and the unlink, this is a little more complicated because a write may trigger a write and an unlink may trigger an unlink, resulting in an infinite loop.
New Solution
============
Having a method _recompute_coupon_lines on sale.order. This method do nothing if there is a key coupon_recompute in the context.
```python
@multi
def _recompute_coupon_lines(self):
if self.env.context.get('coupon_recompute'):
return
self = self.with_context(coupon_recompute=True) # avoid loop
[...do actual stuff...]
```
The create/write/unlink method on sale.order.line call super before calling the method _recompute_coupon_lines
```python
@multi
def write(self, values):
result = super(SaleOrderLine, self).write(values)
self.mapped('order_id')._recompute_coupon_lines()
return result
```
In order (pun intended) to accelerate mass creation/edition of lines, the method create/write/unlink of sale.order should call recompute themself
```python
@mutli
def write(self, values):
result = super(SaleOrder, self.with_context(coupon_recompute=True)).write(values)
self._recompute_coupon_lines()
return result
```
Use case
========
If apply base on a product, it takes only the first line of this product !
Eg: 1 free if 3 buy,
- add 2 line of 2 will not work,
- add 1 line of 1 (eg: discounted, descr, ...) and one ligne with 10... will be ignored
When creating a program, we should always create a discount_line_product_id. Now on a product creation, if a product is not specified, the `vals` dictionary contains `discount_line_product_id: False` and the product is not created. It seems that the behavior on record creation has changed.
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