Versions
--------
- 17.0+

Steps
-----
1. Have a coupon program;
2. add a 10% discount on order reward for 1 point;
3. add a 50% discount on order reward for 5 points;
4. generate a coupon with 10 points;
5. use coupon code on a confirmed order;
6. select 10% discount reward;
7. change to a 50% discount reward;
8. check coupon point total.

Issue
-----
Even though the 5 point reward was used, only 4 out of 10 points remain.

Cause
-----
When updating the reward line of a confirmed order, it keeps track of point cost changes before & after a write. Its purpose is to restore back the point difference on the coupon record.

The issue is that while point changes are stored, coupon changes are not. When updating reward lines, `_reset_loyalty` is used, which removes the `coupon_id` from the lines. As a consequence, attempting to restore the point difference on `line.coupon_id` after an update, it writes to an empty record.

Solution
--------
Store both coupons & their used points before write. After write, restore the previous points to the previous coupon, and subtract the current point cost from the current coupon.

This way, any combination of coupon/point changes should have the points updated as expected.

opw-4910922

Forward-Port-Of: odoo/odoo#230907
Forward-Port-Of: odoo/odoo#222054

### Steps to reproduce:

- In the settings enable: "Batch, Wave & Cluster Transfers"
- Create 2 deliveries
- Barcode > operations > Delivery orders > Batches > New
- Add your two deliveries and confirm
- Scan WH-Stock
#### > The scan fails considering you scanned each letter independently.

### Cause of the issue:

When the barcode is scanned a call of the split barcode will be launched to split the barcode in multiple barcodes according to the `barcode_separator_regex` present in the config:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/models/barcode_model.js#L613-L632 The issue lies in the fact that even thought the is `barcode_separator_regex` was conrrectly populated at the onWillStart of the mainComponent:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/components/main.js#L209-L213 https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/controllers/stock_barcode.py#L97 https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/components/main.js#L229 https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/static/src/models/barcode_picking_model.js#L36-L38 It was reset by the batch confirmation here:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L123-L135 because this part of the config is not meant to be returned by the private method `_get_barcode_data` but rather by public complete version `get_barcode_data`:
https://github.com/odoo/enterprise/blob/aeb9343f4b7dfab0fbc04bca4623ae85b3ea6030/stock_barcode/controllers/stock_barcode.py#L91-L98 Now, since no `barcode_separator_regex` was provided to our new config, each character will be considered to be considered as an independent barcodes and the `WH-Stock` barcode will not match any location.

opw-5062331

Forward-Port-Of: odoo/enterprise#95295
Forward-Port-Of: odoo/enterprise#94056

This bug is in France localization. In some cases employee schedule seems ignored in timesheet entry
(`account.analytic.line`) creation, and the duration field is created using the company schedule.
The reason is the case which the employee schedule starts before company scheudle or ends after it.

To reproduce the bug:
1- Make a db with fr company (install l10n_fr)
2- Make two working schedule:
- Company schedule with working day on Monday from 8:00-12:00 13:00-17:00
- Employee schedule with working day on Monday from 8:30-12:25 13:30-17:15

3- Assign company schedule to company in `Company Working Hours` in Setting and apply employee schedule to an employee from `Payroll` tab of employee
4- Allocate some time off to the employee and take a time off on Monday
5- Check the work entries for the day you took the day off on timesheet app
6- 7:24 `Worked Hour` is shown instead of 7:40

The bug occurs because in calling `adjust_date_range`, the case which employee's schedule ends after company schedule is not considered.

opw-4868643

---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#230621
Forward-Port-Of: odoo/odoo#222262

This commit reverts [1], [2], [3], and [4]. (It actually results in
minimal changes since those commits were already removing parts of
each other.)

Issue before those commits:
1. Setup a auto-fifo category and two storable products (a component
   and a finished product)
2. Receive one compo at 10, then one at 25
3. Produce two MO with one finished product
4. Unbuild the second one

Error:
- For the component, we just use the value of the consumed
  components: IN 1 @ 25
- For the finished product, we process it as a classic out. Reminder,
  we are in FIFO: OUT 1 @ 10

As a result, thanks to the unbuild, we have created
- A over-valuation of the stock (+15)
- An outstanding balance of the "Cost of Production"

This is why [1] has been merged. However, it brought some other
issues, cf [2], [3] and [4]. Unfortunately, it still has some issues
- After the above use case, the difference between the debit and the
  credit of the stock valuation account is no longer the sum of the
  remaining values of the layers
- Adding some landed costs on MOs will lead to a traceback when
  undbuilding
- The over-valuation of the stock (that was already present before [1],
  cf above) is still present

Following some discussions with R&D and the product owners, we have
decided to start over from scratch, which means:
- Revert all commits
- Try another approach (if so, the new PR will be linked to the PR
  related with this commit)

[2], [3], and [4] are partially reverted: the tests can remain, as
they were only failing due to a sequence of changes.

[1] https://github.com/odoo/odoo/commit/84dda968146d2f3743ab7fc516300e50780725e3
[2] https://github.com/odoo/odoo/commit/49565cdd9007ac66a3b835dc073777e2e6c48f2c
[3] https://github.com/odoo/odoo/commit/3a69456a291da593748475c86e7efc6234019e47
[4] https://github.com/odoo/odoo/commit/fb30cde9a320c245cf1321c9dc2ea2e67a53d0a0

OPW-5036574

Forward-Port-Of: odoo/odoo#226380
Forward-Port-Of: odoo/odoo#225728

Currently, when you use a default fiscal position in the pos, if you switch to no fiscal position, upon order validation the tax amount is counted as change.

Steps to reproduce:
-------------------
* Install l10n_es_pos, switch to es company
* In the config of a shop, use fiscal position, set some as available, one as default
* Open shop session
* Add a product that has taxes
* Switch fiscal position to one that has 0% taxes
* There should not be taxes in the cart at this point
* Go to pay the order (cash or bank)
> Observation: On the receipt the previous tax value is counted as
  change

Why the fix:
------------
The issue happens because of the simplified invoice mechanism present in the ES localization. When you validate an order and that order can apply for simplified invoice, if there is no customer on the order the partner is set with the simplified partner. When setting a partner on the order we update the fiscal position and pricelist.
https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/point_of_sale/static/src/app/models/pos_order.js#L929

The fiscal position is updated with the partner's fiscal position or the default one if none on the partner.
https://github.com/odoo/odoo/blob/1358f93a4c73de5a28cda72ec78769625c863efd/addons/point_of_sale/static/src/app/models/pos_order.js#L986-L995

Instead of the fallback on the default fiscal position in the case it is not set on a partner we fallback on the order current fiscal position. If it is different than the default one is means that it was changed intentionally and there's a high chance we want to keep it, otherwise it will already be the default fp.

opw-5051231

Forward-Port-Of: odoo/odoo#229237

Problem: When there is an obligation type code with id greater than 9, and it is selected in the dropdown of the website sale address form for obligation type, the screen keeps loading forever and there is an “expected singleton” traceback in the logs. This is because in the method `_parse_form_data` in `l10n_co_website_sale`, the obligation type field on `form_data` is set to be a  list of “type ids” which leads to an error when `convert_to_cache` is called as the browse function in this attempts to convert the list to a tuple of single characters. For example, if the list is ["10"], it gets converted to ("1","0") hence leading to the expected singleton traceback.

Purpose: Instead of passing a form list to form_data,we pass the record set which will correctly set the values in the address, much like how `default_obligations_ids` is also currently set. After this correction, the website address screen will save the address properly and redirect to the delivery screen for further actions.

Steps to Reproduce on Runbot:
1. Create a Colombian company, make sure l10n_co is installed
2. Set the company on the website to this company
3. Ensure that there is a record in the table `l10n_co_edi_obligation_type_ids` with id > 9. Create one if it does not exist.
4. Open the /shop page in incognito mode as a public user.
5. Add a product, go to the checkout page, proceed to the address page.
6. Enter all the information including the Identification Number (e.g. 623.456.789-1). Choose “NIT” in identification type and select the type code from step 3 in the dropdown for obligation type. Choose country “Colombia” along with a state and city 
7. Click on "Continue checkout". The page gets stuck in a loading state
 forever.

opw-4776301

Forward-Port-Of: odoo/enterprise#90862

Recently pull request https://github.com/odoo/enterprise/pull/86084 introduced an ondelete method on `ir.model` that retrieves some worksheet templates to delete them.  However, this method breaks when uninstalling module `worksheet`:
```
ir.model.data._module_data_uninstall():
    ... records are deleted ...
    ir.model.fields.unlink():
        drop column of corresponding fields
        delete ir.model.field records
    ir.model.unlink():
        drop table of corresponding models
        ir.model._unlink_if_uninstalling():
            self.env['worksheet.template'].search([('model_id', ...)]).unlink()
        delete ir.model records
```
The call to `ir.model.unlink()` crashes when searching for worksheet templates, since column `model_id` has been dropped already.  This makes the transaction fail, and it is rolled back to a savepoint just before the call to `ir.model.unlink()`.  In other words, the uninstallation manages to drop most of the columns that must go, but fails to drop all the tables that must go.  And the uninstallation proceeds anyway...

Now consider uninstalling module `resource`.  That module defines model `resource.calendar` with required field `name`, and also defines a record in that model (a default calendar).  When the module is uninstalled, module `worksheet` is also uninstalled (because it depends on `resource`), and so the situation above happens.  Consequently, most of the columns of table `resource_calendar` are dropped, but the table is not.  If we reinstall module `resource` after that, the ORM re-creates column `name` (which is `NULL` on the default calendar at least), but fails to add the `NOT NULL` constraint on that column.

The fix consists in avoiding the `search()` above in the ondelete method if the column `model_id` does not exist anymore.

Forward-Port-Of: odoo/enterprise#96845