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

Steps
-----
1. Have a database with GeoIP enabled;
2. have a promotion program that gives a discount on a specific product;
3. use a VPN to browse /shop from California before 7:00 UTC;
4. add the product to your cart;
5. go to checkout;
6. pay for the order.

Issue
-----
Order cannot be confirmed due to incomplete payment.

Cause
-----
The `_frontend_pre_dispatch` method of `website` adds a timezone value to the context based on the request's `geoip`. This context value then gets used to find applicable loyalty programs via `Date.context_today`, and applies them to the order.

Then after payment was initiated, the order gets validated again using server time (UTC), which now considers the applied program expired, and removes the reward before confirming the order.

Consequently, with the discount removed, the paid amount no longer matches the order total, thus the order remains unconfirmed.

Solution
--------
If the order has a confirmed transaction, use its `create_date` to verify loyalty expiration dates.

For time zone, instead of `Date.context_today`, using whatever `tz` value is in the context, use a helper function which retrieves the current day in the company's timezone.

For website orders, if defined, use the eCommerce salesperson's time zone instead.

Also fix an issue where expired coupon lines weren't getting removed from the order.

opw-4765873
opw-4781346
opw-4939268

Forward-Port-Of: odoo/odoo#229749
Forward-Port-Of: odoo/odoo#222428

**Steps to reproduce:**
1. In Settings, enable "Work Orders".
2. Create a product with a BOM that has 2 operations: op1 and op2.
3. Create and confirm an MO for 1 unit.
4. Start op1 and change the Real Duration of op2.
5. Try to save.

**Issue:**
- Traceback : 
`'<' not supported between instances of 'datetime.datetime' and 'bool'`

**Cause of the issue:**
Starting the first operation launches a call of the `button_start` method creating
a `resource.calendar.leaves` to set on the `leave_id` of this first operation:
https://github.com/odoo/odoo/blob/97a70e71c32ea6183f87fd5eb558b32bcbd2d231/addons/mrp/models/mrp_workorder.py#L630-L641

Then, setting the duration of the second operation from the form view of the MO
and saving triggers a call of the write of the MO containing the
`[Command.update(op_2.id, new_duration)]` as vals.This, in turn, calls 
`_plan_workorders`:
https://github.com/odoo/odoo/blob/97a70e71c32ea6183f87fd5eb558b32bcbd2d231/addons/mrp/models/mrp_production.py#L939-L942
while the first operation has a set `leave_id` but the second do not

However, the `min` operator will be applied to both the set and the unset values,
comparing a `boolean` with a `datetime`:
https://github.com/odoo/odoo/blob/97a70e71c32ea6183f87fd5eb558b32bcbd2d231/addons/mrp/models/mrp_production.py#L1581-L1588

**Solution:**
Only workorders with a `leave_id` (i.e., those planned in work-center schedule)
should be considered when computing MO `date_start` and `date_finished`.
Workorders without a `leave_id` are not yet scheduled and therefore should not influence MO start and end dates.

As both `date_start` and `date_finished` of a workorder are related to the `leave_id` record. As per `mrp_workorder._compute_dates`, these dates reflect the work-center scheduling (`leave_id.date_from` and `leave_id.date_to`).
https://github.com/odoo/odoo/blob/6a075fa3c090920499ccbd5fe673819da7e3f95e/addons/mrp/models/mrp_workorder.py#L250-L260
Therefore, when computing MO dates, it logically follows that only workorders with an assigned `leave_id` should be used. This avoids mixing unscheduled operations (`leave_id = False`) with scheduled ones, preventing invalid comparisons and ensuring accurate production timing.


**opw-5068080**

Forward-Port-Of: odoo/odoo#226436

This PR fixes two related bugs happening when printing a receipt with the Italian Fiscal printer
First, before this PR, if the option to skip the receipt screen
was ticked, then the receipt would never print.
This was caused by the printing logic being implemented on
the receipt screen instead of on the pos itself.

steps to reproduce:
1. install l10n_it_pos
2. configure one pos
3. configure the IT printer
4. select to skip the receipt screen (print automatically)
5. open the pos
6. make a sale
=> no ticket printed and the chrome console shows a printer error

With this new verison the printing logic was moved to the pos
so that printing of fiscal receipts with the italian fiscal printer
works, even when receipt screen is skipped.

This put to light another potential bug related to how the `order` variable was treated.
Before this PR, the printReceipt logic in the module would not
pass the order to be printed.
This can become a problem upon context changes, where `pos.get_order()`
does not return the completed order, but a newly created one.
This can for example happen when skipping the receipt screen with
the option to "print automatically" (iface_print_auto).

After this PR, we keep order as an argument, so we always print
the last completed order and not a newly created one.

opw-4882480

Forward-Port-Of: odoo/enterprise#95985
Forward-Port-Of: odoo/enterprise#91412

Chrome iOS wraps some text nodes (like measures, email...) with a
`<chrome_annotation>` tag, which breaks OWL rendering.

This commit works around it by adding the (undocumented) `<meta
name="chrome" content="nointentdetection">` tag to disable this Chrome
behavior. The tag has to be set before the onDOMContentLoaded event to
be taken into account.

Note: Looks like this behavior was present in Chrome iOS 127 and
disabled afterward (because it already had issues) but it appeared again
in version 140-141.

References:
- https://issues.chromium.org/issues/353650041
- https://issues.chromium.org/issues/388718411
- https://stackoverflow.com/questions/78207646/how-do-i-disable-chrome-annotation-tags
- https://stackoverflow.com/questions/78575970/prevent-auto-detection-of-phone-numbers-in-chrome-mobile
- https://stackoverflow.com/questions/78725191/stop-chrome-ios-auto-detecting-numbers-followed-by-letter-m-as-metre-units-an
- https://github.com/solidjs/solid/issues/2235

opw-4969197

Forward-Port-Of: odoo/odoo#230081

### Steps to reproduce:
1. Install mrp + purchase
2. Create a new product (A)
   1. Add the Buy route on the product
   2. Add a vendor line on the Purchase tab
   3. Set the quantity on hands to 2000
3. Create a second product (B) with manufacturing route
4. Create a BoM for this product (B)
   1. Add the product (A) as the component with 1 quantity
   2. Create a new operation with a duration of 600:00
5. On the product B's page, click Replenish
   1. Put 10 quantities to replenish
   2. Select the manufacturing route and confirm
6. Go to the BoM and open the BoM overview
7. 'Impossible to plan. Please check the workcenter availabilities.'

https://github.com/user-attachments/assets/58697fd9-4e3e-4df6-98e1-5de7e8759715


### Before this commit:
When opening the BoM overview, if the producible quantity for this BoM exceed the quantity we can plan in the 700 following days, an error is displayed.

### After this commit:
If the quantity producible cannot be planned, we retry automatically with the requested quantity.

opw-5031724

Forward-Port-Of: odoo/odoo#229745
Forward-Port-Of: odoo/odoo#227433

The previous fix for `message/rfc822` attachments forced binary encoding (`cte='binary'`) to comply with RFC 2046. However it also introduced a new issue: emails containing `.eml` attachments with non-ASCII characters could not be serialized

### Steps to reproduce

1. Send an email via the chatter with a `.eml` file attached containing non-ASCII characters (e.g., "é") in its body.

The sending of that email will fail with a `UnicodeEncodeError` error

### Cause

Commit 6197233ef1611ddd974cfdb06ae2568e4af369de attempted to fix an issue where `.eml` (`message/rfc822`) attachments were not RFC-compliant. It did this by forcing the `Content-Transfer-Encoding` to `binary` for the raw byte content of the attachment.

While this worked for simple ASCII attachments, it failed for attachments containing non-ASCII characters. When Python's `email` library later tried to serialize the entire message, it treated the attachment's content as an opaque binary blob. It did not understand the character encoding within that blob, leading to a `UnicodeEncodeError` during the final serialization process.

### Fix

Instead of attaching the raw bytes, we now:
* Parse `.eml` contents using `email.parser.BytesParser`, producing a proper `Message` object.
* Attach the parsed message directly, letting the email library handle correct encoding and transfer settings automatically.

opw-4655868

Forward-Port-Of: odoo/odoo#230384
Forward-Port-Of: odoo/odoo#223790

Serial number tracked product are marked as pass even when they fail a move_line type of check.

### Steps to reproduce:

* Create a product tracked by serial number
* For this product create a control point:
	- Control per quantity
	- Operations : Receipts
* Create a receipt for this product
* Mark the receipt as Todo
* Start the Quality check from the receipt, without using the smart button.
* Fail the Quality check
* The Quality check still passes

### Issue:

When validating a quality check and it fails:
https://github.com/odoo/enterprise/blob/d48228127c239e45938551d9bbac734afab8b31a/quality_control/wizard/quality_check_wizard.py#L84-L92 I will not go through the standard process with show_faillure_message where the user can select failed_qty, it directly goes to confirme_fail>_move_to_failure_location: https://github.com/odoo/enterprise/commit/49149580d34ec5583559fa0288356fec6cb2c514#diff-2ffdc2ffc25417076b580b772447514c7e9d8b3e2d2fff2d3100721eb5ccbaf4L455-R457 In our case since failed_qty is still at 0 this new condition transfer the quality check to pass. In the case of serial numbers, the quality check is done one by one, the failed_qty can be retrived from check.move_line_id.quantity

opw-5015266

Forward-Port-Of: odoo/enterprise#92966

Currently, an error occurs when computing taxes for an invoice.

**Error:**
    `KeyError: 'manual_tax_amounts'`

**Cause:**
When a user clicks the `Compute Tax` button, the system calculates the tax for that invoice, including the `manual_tax_amount` [1]. However, if no tax is found for a given customer ZIP code, the `tax_values_list` becomes empty [2]. As a result, `manual_tax_amounts` in the base line also becomes empty.

Later, when the system tries to fetch the `manual_tax_amounts` key from extra_tax_data, it raises a KeyError [2], because the key no longer exists.

Additionally, the condition in [3] indicates that there is no guarantee that the `manual_tax_amounts` key will always be present in the base_line.

**FIX:**
This commit ensures that if the manual_tax_amounts key does not exist, an empty dictionary {} is used instead. This prevents the KeyError from occurring during tax computation.

[1]- https://github.com/odoo/enterprise/blob/b17b6b4e5ca3085d831fc763457496b5c5b639c5/account_external_tax/models/account_external_tax_mixin.py#L155-L163

[2]- https://github.com/odoo/enterprise/blob/a51aee8f6e8bce2aa699d3199d6723495464a762/account_external_tax/models/account_external_tax_mixin.py#L88

[3]- https://github.com/odoo/odoo/blob/241c170dbece8c1652db9ca1aa935b2106ede532/addons/account/models/account_tax.py#L1330

sentry-6919182805

Forward-Port-Of: odoo/enterprise#96401

**Steps to reproduce:**

1-Install the purchase_stock module.
2-Create a Purchase Order with a new vendor.
3-In the Purchase Order line, add a product without a category. 
4-Confirm the order and validate the generated receipt. 
5-In the vendor form view, click the On-time Rate smart button → no graph is
 visible.

**Issue:**

https://github.com/odoo/odoo/blob/77b3956ed5635d79ae8dc19423140dc6a10098f1/addons/purchase_stock/report/vendor_delay_report.py#L46-L50

```
The On-time Rate graph is not displayed in the Vendor Delay report.
```

**Cause:**

- From version 18.2, `categ_id` was removed as a required field. The report query still uses an inner join on `categ_id`, which  excludes products without a category and prevents data from being generated.

- Commit which make `categ_id` non require  - https://github.com/odoo/odoo/pull/166323/commits/b039caecbeb04057fbccb1cc88d03a4946f88e8e

**Solution:**

- Replace the inner join with a left join so that products without a `categ_id` are also included in the report (with null values when the category is not set).

**opw** - 4991367

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

Forward-Port-Of: odoo/odoo#230388
Forward-Port-Of: odoo/odoo#225557

**Steps to reproduce:**
1. Go to Accounting > Customers > create a company with child contact (invoice) (both having name and email).
2. Create an invoice with the child contact as customer and confirm it.
3. Go to the child contact and open the Customer Statement smart button.
4. Download the PDF → data is shown correctly.
5. Send the statement → the attachment in the sent mail is empty.

**Issue:**
- When sending customer statements via email from a child contact, the generated
  PDF attachment contains no data, showing empty amounts and transactions.
- Additionally, the "Customer Statement" button was still visible even when
  the total due was zero.

**Cause:**
- The button visibility condition checks for `total_due == 0.0 and not has_moves`,
  which didn’t properly cover all use cases.

**Solution:**
- Update button visibility condition to: `invisible="not has_moves or total_due == 0"`
  ensuring it is hidden when there are no moves or the total due is zero.

**opw-5009182**

Forward-Port-Of: odoo/enterprise#95356
Forward-Port-Of: odoo/enterprise#93162

Currently, an error occurs when no groupby property is found in LLM response
while trying to search records through the AI agent in the chat.

Steps to replicate:
- Install ai_app and sale_management.
- Setup gemini key.
- In the systray click on AI icon.
- Type in: 
  `read group in res partner`
   or
  `read group in partners groupby None`
- Error will occur in terminal.
(If the error doesnt occur the first time, spam the above given prompt.)

Error:
`ValueError: TypeError("'NoneType' object is not iterable") while evaluating
"ai['result'] = record._ai_tool_read_group(model_name, domain, groupby, aggregates, having, offset, limit, order)"`

Cause:
- As the LLM response didnt incude groupby it was passed on as None to the orm,
  which caused the `'NoneType' object is not iterable` at the line [1].
- The groupby was set `None` through line [2], the loop sets every param that 
  is not in the instance as None i.e. Every value that is in `ai_tool_schema`
  but not received in LLM response is set as `None`. 

Solution:
- The method `_ai_tool_read_group` now safely handles cases where `groupby` or
  `aggregates` (similar error occurs when aggregates is none at [3]) are None.
- Fields are assigned default values before calling the method `_read_group`.


[1]: https://github.com/odoo/odoo/blob/c034fed2eeb194961af7e1b3c60203141784acf2/odoo/orm/models.py#L1919

[2]: https://github.com/odoo/enterprise/blob/7e6fe07512b7d897cf6315d45e6a1004e48ef45e/ai/utils/tools_schema/validators.py#L51

[3]: https://github.com/odoo/odoo/blob/c034fed2eeb194961af7e1b3c60203141784acf2/odoo/orm/models.py#L1923
 
sentry-6912361256

Since the fiscal position sequence is used to determin the domestic fiscal position, and hence, the domestic taxes - it is important to properly sequence the fiscal positions.

This commit fixes the following localizations:

**AE**
Sequences are added making Dubai the domestic fiscal position. However this needs to be improved to automatically prioritize the fiscal position based on the company's state.

**IT** (l10n_it_edi_doi)
An additional domestic fiscal position was mistakenly added. The correct domestic FP is defined in it's dependency module l10n_it. The duplicate FP is removed.

**MX**
Sequences are added

**KH**
Sequences are added

No Task - l10n's identified by the fiscal position checks in `test_all_l10n`

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#230654

Currently, an error occurs when a user adds a combo product to the cart.

Steps to Reproduce [video](https://drive.google.com/file/d/1m-zxaIsrIzogeLun_Dj92Hb37-S9g9dO/view?usp=sharing):

 - Install the `website_sale` module.
 - Create a product of type `combo` and add a `combo choice`.
 - Go to the `combo choices` and delete `that combo choice`.
 - Go to the `website` > `Shop` and add that product to the `cart`.

`ValueError: min() arg is an empty sequence`

This error occurs after this [commit](https://github.com/odoo/odoo/pull/198070/files), When user creates a combo product, adds its related combo choice, and then deletes that combo choice, adding the product to the cart causes the system to check the quantities of the order line [1]. Since there is no sale combo choice for that product, the combo line becomes empty and raises an error[2].

This commit ensures combo choice quantities are checked only if they exist.

[1]-  https://github.com/odoo/odoo/blob/df05ae6d9af6abdfd67c49ac7a4d01762472bfc3/addons/website_sale/controllers/cart.py#L189

[2]- https://github.com/odoo/odoo/blob/df05ae6d9af6abdfd67c49ac7a4d01762472bfc3/addons/website_sale/models/sale_order.py#L621

sentry-6924112987


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

Serial number tracked product are marked as pass even when they fail a move_line type of check.

### Steps to reproduce:

* Create a product tracked by serial number
* For this product create a control point:
	- Control per quantity
	- Operations : Receipts
* Create a receipt for this product
* Mark the receipt as Todo
* Start the Quality check from the receipt, without using the smart button.
* Fail the Quality check
* The Quality check still passes

### Issue:

When validating a quality check and it fails:
https://github.com/odoo/enterprise/blob/d48228127c239e45938551d9bbac734afab8b31a/quality_control/wizard/quality_check_wizard.py#L84-L92 I will not go through the standard process with show_faillure_message where the user can select failed_qty, it directly goes to confirme_fail>_move_to_failure_location: https://github.com/odoo/enterprise/commit/49149580d34ec5583559fa0288356fec6cb2c514#diff-2ffdc2ffc25417076b580b772447514c7e9d8b3e2d2fff2d3100721eb5ccbaf4L455-R457 In our case since failed_qty is still at 0 this new condition transfer the quality check to pass. In the case of serial numbers, the quality check is done one by one, the failed_qty can be retrived from check.move_line_id.quantity

opw-5015266

Forward-Port-Of: odoo/enterprise#92966

Currently, with Indian localization, creating a contact from a CRM lead raises an error.

**Steps to Reproduce:**
1) Install CRM,l10n_in (with Demo)
2) Switch to IN Company
3) Navigate to CRM> Click on 'New'
4) For **Contact** value click on 'Search more'>'New'. 'Create contact'
   wizard will open and set the following values
 >- Set contact as 'Company'
 >- Set 'GSTIN' (e.g 22AAFCH6738N1Z8)
5) Click Save

Error:
`ValueError: Wrong value for l10n_in.pan.entity.type: 'contact'`

Root Cause:
since [this commit](https://github.com/odoo/odoo/pull/214189/commits/c943637ef4aef740b97abaf1852ceb6fdfcd55bb), the field `l10n_in_pan_entity_id` at [1] was changed from `char` to `Many2one` which depends on the field `type` in the `l10n_in_pan_entity` as shown at [2]. Now following the above steps, the type of the partner is set as 'contact' from [3], which is not available at [2], raising an error.

Fix:
Updated the context value before creating a record for Pan Entity.

[1]- https://github.com/odoo/odoo/blob/b81d119fae5f5194334cee94bacffefeb1cd8c6e/addons/l10n_in/models/res_partner.py#L27-L35

[2]- https://github.com/odoo/odoo/blob/b81d119fae5f5194334cee94bacffefeb1cd8c6e/addons/l10n_in/models/l10n_in_pan_entity.py#L15-L27

[3]- https://github.com/odoo/odoo/blob/b81d119fae5f5194334cee94bacffefeb1cd8c6e/addons/crm/views/crm_lead_views.xml#L454

sentry-6916949666

### Steps to reproduce
1. Install `l10n_mx_edi` with demo data
2. Switch to the ESCUELA KEMPER URGATE demo company
3. Create an invoice to the INMOBILARIA CVA demo partner
4. Send the invoice CFDI
5. Request cancellation of the CFDI
6. The cancellation fails with the error 'invalid passphrase'.

### Analysis
When calling `_finkok_cancel`, `_solfact_cancel`, or `_sw_cancel`, one of the API call parameters is the `pem_key` of the certificate given by the SAT.

Before 19.0, the PEM key was in an unencrypted format.

Since f88f8258ead, `env['certificate.key'].pem_key` is encrypted.

According to Finkok's API documentation, the private key should be encrypted using DES when given as a SOAP parameter.
https://wiki.finkok.com/home/webservices/ws_cancelacion/cancel

However, in testing, encrypting the private key using DES seems to be rejected by Finkok.

Solucion Factible and SwSapien don't indicate in their documentation whether and how the private key should be encrypted.

### Solution
We send the private key unencrypted, as was already the case before 19.0.

opw-5137549

Chrome iOS wraps some text nodes (like measures, email...) with a
`<chrome_annotation>` tag, which breaks OWL rendering.

This commit works around it by adding the (undocumented) `<meta
name="chrome" content="nointentdetection">` tag to disable this Chrome
behavior. The tag has to be set before the onDOMContentLoaded event to
be taken into account.

Note: Looks like this behavior was present in Chrome iOS 127 and
disabled afterward (because it already had issues) but it appeared again
in version 140-141.

References:
- https://issues.chromium.org/issues/353650041
- https://issues.chromium.org/issues/388718411
- https://stackoverflow.com/questions/78207646/how-do-i-disable-chrome-annotation-tags
- https://stackoverflow.com/questions/78575970/prevent-auto-detection-of-phone-numbers-in-chrome-mobile
- https://stackoverflow.com/questions/78725191/stop-chrome-ios-auto-detecting-numbers-followed-by-letter-m-as-metre-units-an
- https://github.com/solidjs/solid/issues/2235

opw-4969197

Forward-Port-Of: odoo/odoo#230081

**PROBLEM**
When scanning two gs1 barcode with the same serial number, but for different products there is an error and the 2nd product is not added to the inventory count.

**STEP TO REPRODUCE**
1. install stock_barcode
2. activate the gs1 barcode and select the default gs1 nomenclature.
3. scan the following barcode
- 01000000000001232180085 (product barcode: 0000000000123, serial: 80085).
- 01000000000000482180085 (product barcode: 0000000000048, serial: 80085).
4. there is an unexpected error notification, and the 2nd product line isn't added.

**CAUSE**
In _processBarcode (barcode_model.py), we only check if:
- there is already a line with serial tracking with a non-null qty
- this line serial number is the same serial number that we are scanning

**FIX**
We should also verify if the product from the lines we are checking, and the line we want to create are the same.

[opw-5076045](https://www.odoo.com/odoo/project/49/tasks/5076045)

Forward-Port-Of: odoo/enterprise#96430

Steps to reproduce:
1. Create a resource with a "Working Time" calendar set with flexible hours
2. Create an appointment with this resource
3. Go to the website and try to book an appointment with this resource
4. Error 404 not found.

When booking appointments with resources that have flexible calendars, the system returns a 404 error during slot validation.

The issue occurs in `_check_appointment_is_valid_slot` (appointment controller) which validates that a slot is still available before allowing booking. This validation calls `_unavailable_intervals_batch` (resource.calendar) to check resource availability.

For flexible resources, `_unavailable_intervals_batch` generates inverted time intervals (e.g., start=18:30, end=18:00) which causes the overlap check to fail incorrectly, making valid slots appear unavailable.

This regression was introduced when the distinction between "fully flexible" (no calendar) and "flexible" (calendar with flexible_hours=True) was added. The check was only applied for fully flexible resources, leaving regular flexible resources broken.

Solution: Skip unavailable interval computation for both `_is_fully_flexible()` and `_is_flexible()` resources, since flexible resources by definition have no fixed unavailable periods.

opw-5026825

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

**PROBLEM**
Pricelist rules based on a minimum quantity does not work well with lot tracked product, when the quantity is splitted between multiples lots. For example, if you take 2 product from lot A, and 3 product from lot B, a rule defining the price for a minimum quantity of 5 will not trigger (it should).

**STEP TO REPRODUCE**
1. install pos
2. create a lot tracked product
3. create a pricelist rule for the product, with a price based on min qty
4. from the pos, order the min qty but split it accross multiple lots
5. price will not takethe rule into account

**CAUSE**
Order line of lot tracked products are never merged. The quantity used to compute if a pricelist trigger is the quantity of each line individually.

**FIX**
For lot tracked product, to determine the price of a line, we parse find all corresponding lines and add their quantities together. Then we update all of their prices. To know if we should take into account a line, we verify if they would have been merged, if their product wasn't lot tracked.

**REMARK**
Ideally, their would be a way to merged order line of lot tracked product, while being able to edit the quantity taken from each lot directly from the pos. From now, order line doesn't work well with multiple lots, and it would require unstable change on the db.

opw-4751920

Forward-Port-Of: odoo/odoo#219110

## Issue:
Confirming a Sale Order for a product with MTO + Manufacturing routes fails (Validation Error) when Analytic Accounting is enabled and an Analytic Plan is mandatory

## Cause:
The analytic_distribution is first validated one time for the Sale Order line

When the MO will is created later, the `_compute_analytic_distribution()` function in `mrp_account` is triggered
Since no `account.analytic.distribution.model` is defined, the analytic_distribution field is recomputed as {}

This trigger a second validation, which fails because `{}` is invalid when an analytic plan is mandatory

## Steps to reproduce:
- Enable Analytic Accounting and Multi-Step Routes in Settings
- In Accounting > Configuration > Analytic Accounting > Analytic Plans set Projects as Mandatory
- Unarchive the MTO route
- Create a Product with MTO + Manufacturing routes
- Create a Sale Order for this product and set an Analytic Distribution for Projects
- Confirm the SO to get the Validation Error

opw-4863498