**Steps to reproduce:** (only reproducible in production)
- Install accountant and l10n_co_dian
- Switch to a Colombian company (e.g. CO Company)

- In Accounting settings, configure the Colombian localization with valid DIAN credentials
- Create an invoice for a Colombian customer
- Confirm the invoice
- Send the invoice to DIAN
- Cancel and delete the invoice

- Create another invoice for another Colombian customer with the same name (sequence) than the previously deleted invoice
- Confirm the invoice
- Send the invoice to DIAN

**Issue:**
A previous fix (https://github.com/odoo/enterprise/commit/4d782030631350cfaa8f2993e68f33c9f66929e4) had been made to sync together a DIAN document from Odoo and DIAN when the following error was returned by DIAN:
"Regla: 90, Rechazo: Documento procesado anteriormente."
It can happen when an invoice is sent to DIAN but due to a connection issue, the DIAN response is not received and the invoice is flagged as rejected.
In that case, the "Regla: 90" error is returned by DIAN when trying to send the invoice again and the fix is linking the identifier returned by the DIAN error with the invoice to prevent this issue.
However, the fix wasn't taking into account the case in which the error returned by DIAN is legit and the identifier is linked to another document.
It results of having an invoice that is linked to an incorrect document in DIAN.
The customer, date and other info, completely different.

**Solution:**
When "Regla: 90" error is returned by DIAN, a check is performed to make sure that the customer, the issue date and time on the document in Odoo and on the XML from DIAN are the same before assigning the identifier from DIAN to the document in Odoo.

opw-5095212

Forward-Port-Of: odoo/enterprise#99936

When importing a large file in multiple batches , Odoo incorrectly displays a "Resume" prompt at the end of the process, even though all records have been successfully imported.

Steps to reproduce:

1. Create a CSV file with enough records to trigger at least 2 batches
2. Go to any list view and select "Import records".
3. Upload the file and click "Import".
4. Wait for the import to complete.
5. Observe that despite an "X records successfully imported" notification, a warning "Click 'Resume' to proceed..." appears.

The issue occurs because the `importRes.nextrow` state variable is updated during intermediate batches but is not cleared when the final batch completes.

* In `_executeImportStep`, if `nextrow` is returned (intermediate batch), `importRes.nextrow` is updated.
* If `nextrow` is falsy (final batch), the loop is stopped, but `importRes.nextrow` retains the value from the previous batch.
* `executeImport` checks `importRes.nextrow` to decide whether to show the `"Resume"` message, leading to a false positive caused by the stale value.

This commit fixes the issue by explicitly setting `importRes.nextrow` to `0` in `_executeImportStep` when the server indicates completion (returns a falsy `nextrow`).

opw-5343837

Forward-Port-Of: odoo/odoo#241490

Steps to reproduce:
1. Install the Sale app.
2. Enable developer mode and go to Decimal Accuracy.
3. Set the "Product Price" precision to 3 digits.
4. Create a quotation and print the report.

Issue:
The decimal precision of the unit price is not respected in the report.

Cause:
The unit price field in the report uses the `monetary` widget, which ignores the Decimal Accuracy configuration and enforces currency precision instead.

Solution:
Remove the `monetary` widget from the unit price field in the report so that Decimal Accuracy is applied correctly.

Before:
<img width="570" height="97" alt="image" src="https://github.com/user-attachments/assets/dda22b25-0ade-40ae-b585-c6251ba89c89" />


After :
<img width="584" height="87" alt="image" src="https://github.com/user-attachments/assets/b51d3040-e7b5-41d6-bdd9-7ec799b8005d" />

opw-5418665

Revert [PR #224219](https://github.com/odoo/odoo/pull/224219/files#diff-92dda03d204cc6ea8b7aacd0c07939843c83b1841f4a3049903844777d83c07bR201) to the original implementation so that the configured Decimal Accuracy is correctly applied in reports as other apps i.e. Purchase or Account

Forward-Port-Of: odoo/odoo#241255

Steps to reproduce:
1. Open the Documents app and select an uploaded file.
2. Click the action "Create Vendor Bill" (or any journal entry action).
3. The Invoice is created and the document is attached to it.

**Current Behavior:**
The document remains in its original folder (e.g., Finance) and does not receive the tags defined on the journal settings.

**Expected Behavior:**
The Document should be moved to the specific folder linked to the Journal (e.g., "Vendor Bills") and receive the configured tags.

**Cause:**
The `write` method attempts to identify documents to sync by calling `_get_document_attachments_to_sync`, which inspects the current record (`self`). However, when an invoice is being linked to a document for the first time, the attachment ID exists only in `vals` and has not yet been applied to `self` via `super().write()`. Consequently, the code assumes there are no documents to sync and skips the folder/tag update.
This issue  was introduced in 2333367.

**Fix:**
Detect the specific case where `attachments_to_sync` is empty (no current link) but `vals` contains a `message_main_attachment_id`. In this scenario, force the synchronization flag to `True` so the document is updated after the changes are saved.

Note: The loop logic was also refactored to flatten the structure and accommodate the new check more cleanly.

Task-5452880

**Steps to reproduce:**
- Go to the sequence interface, and chose the config number 1 for a pos.order
- In the prefix field, enter something with characters that are not numbers
- Go to a PoS with config number 1 active and make a purchase
- A traceback appears saying that we can't convert the sequence to an Integer

**Why the fix:**
Having a custom prefix with letters used to work, but in version 19, we now store the sequence_number with the prefix, which can be composed of characters which can not be stored in an Integer field such as sequence_number.

To prevent this error, we remove the prefix and the suffix (which has the same issue) from the sequence_number before storing it. We then add the prefix and the suffix back when computing the order's name, so that it's consistant with the prefix and the suffix the user chose.

This is the way the order's name was computed before version 19.0, which saw the prefix and suffix disappear from the order's name.

opw-5386575

Forward-Port-Of: odoo/odoo#239515

**Description of the issue this PR addresses:**
------------------------------------------------

When reaching the last chatbot step, the frontend stopped before calling `/chatbot/step/trigger` due to the `isLast` check in `_goToNextStep()`. As a result, `_process_answer()` was not executed, and the user's final answer was not saved, which resulted in the `rawAnswer` field remaining empty and the answer not appearing in the side panel. The chat session was also not marked as closed since the backend route was never called.

**Current behavior before PR:**
---------------------------------

- The final chatbot answer is not visible in the side panel  
- The chat session remains open after the final step  

**Desired behavior after PR is merged:**
-----------------------------------------

- The final chatbot answer is saved and displayed in the side panel  
- The backend route is triggered for the last step  
- The chat session is properly marked as closed  

**Task:** 5172125

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

**Steps to reproduce:** (only reproducible in production)
- Install accountant and l10n_co_dian
- Switch to a Colombian company (e.g. CO Company)

- In Accounting settings, configure the Colombian localization with valid DIAN credentials
- Create an invoice for a Colombian customer
- Confirm the invoice
- Send the invoice to DIAN
- Cancel and delete the invoice

- Create another invoice for another Colombian customer with the same name (sequence) than the previously deleted invoice
- Confirm the invoice
- Send the invoice to DIAN

**Issue:**
A previous fix (https://github.com/odoo/enterprise/commit/4d782030631350cfaa8f2993e68f33c9f66929e4) had been made to sync together a DIAN document from Odoo and DIAN when the following error was returned by DIAN:
"Regla: 90, Rechazo: Documento procesado anteriormente."
It can happen when an invoice is sent to DIAN but due to a connection issue, the DIAN response is not received and the invoice is flagged as rejected.
In that case, the "Regla: 90" error is returned by DIAN when trying to send the invoice again and the fix is linking the identifier returned by the DIAN error with the invoice to prevent this issue.
However, the fix wasn't taking into account the case in which the error returned by DIAN is legit and the identifier is linked to another document.
It results of having an invoice that is linked to an incorrect document in DIAN.
The customer, date and other info, completely different.

**Solution:**
When "Regla: 90" error is returned by DIAN, a check is performed to make sure that the customer, the issue date and time on the document in Odoo and on the XML from DIAN are the same before assigning the identifier from DIAN to the document in Odoo.

opw-5095212

Forward-Port-Of: odoo/enterprise#99936

**Steps to reproduce:** (only reproducible in production)
- Install accountant and l10n_co_dian
- Switch to a Colombian company (e.g. CO Company)

- In Accounting settings, configure the Colombian localization with valid DIAN credentials
- Create an invoice for a Colombian customer
- Confirm the invoice
- Send the invoice to DIAN
- Cancel and delete the invoice

- Create another invoice for another Colombian customer with the same name (sequence) than the previously deleted invoice
- Confirm the invoice
- Send the invoice to DIAN

**Issue:**
A previous fix (https://github.com/odoo/enterprise/commit/4d782030631350cfaa8f2993e68f33c9f66929e4) had been made to sync together a DIAN document from Odoo and DIAN when the following error was returned by DIAN:
"Regla: 90, Rechazo: Documento procesado anteriormente."
It can happen when an invoice is sent to DIAN but due to a connection issue, the DIAN response is not received and the invoice is flagged as rejected.
In that case, the "Regla: 90" error is returned by DIAN when trying to send the invoice again and the fix is linking the identifier returned by the DIAN error with the invoice to prevent this issue.
However, the fix wasn't taking into account the case in which the error returned by DIAN is legit and the identifier is linked to another document.
It results of having an invoice that is linked to an incorrect document in DIAN.
The customer, date and other info, completely different.

**Solution:**
When "Regla: 90" error is returned by DIAN, a check is performed to make sure that the customer, the issue date and time on the document in Odoo and on the XML from DIAN are the same before assigning the identifier from DIAN to the document in Odoo.

opw-5095212

Forward-Port-Of: odoo/enterprise#99936

Versions
--------
- saas-18.3+

Steps
-----
1. In Accounting/Invoicing settings, enable "Add QR-code link on PDF";
2. create an automation rule for the `account.move` model;
3. set "Trigger" to "Create & Edit";
4. set "Apply on" domain to `[("state", "=", "posted")]`;
5. set "When updating" to "Status";
6. add an action to execute the following code:
    ```python
    env['account.move.send']._generate_and_send_invoices(records)
    ```
7. call `action_post` on an invoice via RPC or Odoo Shell.

Issue
-----
> odoo.addons.base.models.ir_qweb.QWebException: Error while render the template
> RuntimeError: object is not bound

Cause
-----
In order to add a payment link QR code to the invoice[^1], it needs to generate an access token for the portal. This happens via the `generate_access_token` function from `odoo.addons.payment.utils`. Issue is that it relies on having access to a `odoo.http.request` object, so that it can use its `env` to retrieve the `database.secret` config parameter.

When this flow gets triggered via an API call (or Odoo Shell), the `request` object is unbound, causing the error.

[^1]: feature added via commit bcb73cd159885

Solution
--------
Introduce an optional `env` kwarg to `generate_access_token`, falling back on `request.env` if it's not provided.

opw-5487075

**Steps to reproduce:**
- Create a portal user
- Go to the documents app
- Click on the marketing folder
- Share the marketing folder through a link (Anyone with a link = viewer + discoverable)
- Copy the share link
- Login with the portal user in an incognito window
- Paste the share link in an incognito browser
- Click on "brand 1" folder, result nothing is showing while there should be a folder and a picture
- Click on "brand 2"
- Click back on "brand 1" and now the folder and picture are visible
- If you click on a subfolder of "brand 1" you also get an error

**Issue:**
Discoverable subfolders accessed using `accessToken` are not available on
the first read of a user and this happens for each level of the
hierarchy (refresh is needed each time).

When using sharing link to display folders with a user,
the subfolder document access is created on `/documents/touch/` using
`_from_access_token`.

But on the js side the call is delayed (with debounce) and occurs after
the `web_search_read`. This means that subfolders are only accessible
after a refresh or by switching back and forth between folders.
Also, even after the folder is displayed, if there are other subfolders
in it, going deeper in the hierarchy won't work as well without a refresh
due to the `search_panel_select_range` missing the new folder.

**Fix:**
Not sure on the best way to fix this, the issue will always be related to
performance. Current fix checks if a reload is needed by sending a flag in the
`/documents/touch/<access_token>` request result when a new document
access was created.

opw-5156297

Forward-Port-Of: odoo/enterprise#104451
Forward-Port-Of: odoo/enterprise#99820

- for more then one records having same code it's raising an singleton error at fetching the name

- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```

- OPW-5450360

Forward-Port-Of: odoo/enterprise#103460

## [FIX] website: add versioning for GallerySlider interaction
    
    The GallerySlider interaction (and its edit mode counterpart) is not up
    to date: the logic is still written for old snippets (before [9042b1c],
    so before 18.0).
    
    In the meantime, the pagination for the indicators was lost, meaning
    that if you add too many images, the indicators will have less and less
    space.
    
    Steps to reproduce:
    - Drop an Image Gallery snippet
    - Set the indicators to squared or rounded miniatures
    - Add 15 or more images
    => All the indicators are crammed into the same line.
    
    With this commit, we deprecate the old `GallerySlider` interaction and
    create a `GallerySlider001` for the snippets dropped since 18.0.
    For the indicators, instead of a pagination, we now use a horizontal
    scrolling container which centers on the active indicator.
    
[9042b1c]: https://github.com/odoo/odoo/commit/9042b1c 

## [FIX] website: preload available carousel images
    
    As images are lazy loaded, it means that in the context of a carousel or
    an image gallery, they only start loading once the user clicks either on
    its indicator or on the previous / next button (or after completing an
    auto-slide). While Chrome seems to optimize that to make it seemless, on
    Firefox this causes the carousel slide to appear blank for a moment
    before the image suddenly pops up, as the sliding animation arrives to
    its end.
    In effect, this causes a flicker and a feeling that the carousels, and
    especially the gallery, is extremely laggy.
    
    To mitigate that while trying to keep the advantages of image lazy
    loading, this commit partially backports [08d837e], which loads the
    images of the next and the previous carousel items.
    
    Additionally, we prefetch the target images on pointerdown / keydown on
    an indicator. That may seem like too small of a difference to be
    interesting, but it actually gives a little bit of time between the
    pointerdown and pointerup (which triggers the slide event) to start
    loading the images, which with a correct connexion already goes a long
    way towards mitigating the laggy feeling.
    
[08d837e]: https://github.com/odoo/odoo/commit/08d837e70f28a84a9bd97974f5d15d387a42b7c0
    
task-5245513

**Steps to reproduce:** (only reproducible in production)
- Install accountant and l10n_co_dian
- Switch to a Colombian company (e.g. CO Company)

- In Accounting settings, configure the Colombian localization with valid DIAN credentials
- Create an invoice for a Colombian customer
- Confirm the invoice
- Send the invoice to DIAN
- Cancel and delete the invoice

- Create another invoice for another Colombian customer with the same name (sequence) than the previously deleted invoice
- Confirm the invoice
- Send the invoice to DIAN

**Issue:**
A previous fix (https://github.com/odoo/enterprise/commit/4d782030631350cfaa8f2993e68f33c9f66929e4) had been made to sync together a DIAN document from Odoo and DIAN when the following error was returned by DIAN:
"Regla: 90, Rechazo: Documento procesado anteriormente."
It can happen when an invoice is sent to DIAN but due to a connection issue, the DIAN response is not received and the invoice is flagged as rejected.
In that case, the "Regla: 90" error is returned by DIAN when trying to send the invoice again and the fix is linking the identifier returned by the DIAN error with the invoice to prevent this issue.
However, the fix wasn't taking into account the case in which the error returned by DIAN is legit and the identifier is linked to another document.
It results of having an invoice that is linked to an incorrect document in DIAN.
The customer, date and other info, completely different.

**Solution:**
When "Regla: 90" error is returned by DIAN, a check is performed to make sure that the customer, the issue date and time on the document in Odoo and on the XML from DIAN are the same before assigning the identifier from DIAN to the document in Odoo.

opw-5095212

Forward-Port-Of: odoo/enterprise#99936

**Description of the issue/feature this PR addresses:**
This PR adds the AFIP document type 110 - CREDIT NOTE TICKET, which is required for the Argentinian localization

**Current behavior before PR:**
When users in Argentina tried to create a credit note for a ticket, the corresponding document type was not available as an option.

**Desired behavior after PR is merged:**
After this change, users can now select "110 - CREDIT NOTE TICKET" to issue the document correctly.

[HERE](https://app.screencastify.com/watch/fVBWwSD6DAcodKO57qUZ) is a video replicating the issue
1) In localization Argentina, check document types and see that 110 CREDIT NOTE TICKET exists
2) Create a new journal as shown in the video
3) Create an invoice selecting that journal, and (83) TICKET as Document Type
4) Confirm the invoice and try to create a credit note. See that (110) CREDIT NOTE TICKET does not appear as an option

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

Forward-Port-Of: odoo/odoo#228256

In the barcode application, scanning a picking order containing a kit product variant with packaging will raise a Traceback.

### Steps to reproduce:

1. Enable packagings on inventory configuration.
2. Create a product, that as a least 2 variants.
3. Add a packaging to one of the variants.
4. Create a BoM for created product (kit type).
5. Create a picking order for the variant with packaging.
6. Print the picking operation to scan the code through barcode.
7. Go to barcode and try to scan it, this will trigger the traceback.

### Cause of the issue:
Scaning a barcode will call get_barcode_data during this call it will retrieve the information about the picking order and call _get_stock_barcode_data:
https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode/controllers/stock_barcode.py#L91
_get_stock_barcode_data will obtain the packaging methode for the products.
https://github.com/odoo/enterprise/blob/f2dd6326c2084ed467c3e4c3e9d931f41309ad79/stock_barcode_mrp/models/stock_picking.py#L13-L16
since in our use case the product has variant the packaging information is not inside product_tmpl_id.packaging_ids and thereof it will not retrieve the packaging information.

### Fix:
We don't need to use product_tmpl_id.packaging_ids because of its compute and set methods (and the fact that the product_variant_ids field is required), the product_tmpl_id.packaging_ids will always be included in the product_tmpl_id.product_variant_ids.packaging_ids:
https://github.com/odoo/odoo/blob/eb88370e2fc1887e8c88dfd8dbeadce23bb7abe5/addons/product/models/product_template.py#L430-L441
our fix will allow for packaging in the variant to be considered when there is more than only one variant.

opw-4852875

Forward-Port-Of: odoo/enterprise#103860
Forward-Port-Of: odoo/enterprise#87867

### Issue:
The cron "Sale Subscription: generate recurring invoices and payments" runs several times when there is a subscription with no payment method.

### Steps to reproduce:
- Install "sale_subscription"
- In the Settings, activate "Online payment" AND "Consolidate subscriptions billing"
- Activate Stripe
- As admin, connect to /my/ page
- Add a payment method using Stripe VISA test card: 4000000000000341
- Create a subscription for a newly created user:
	- Recurring plan: monthly
	- Start date in the past to make it "to renew"
	- Gear > Mark quotation as sent
	- Confirm
- Create another similar subscription for the admin:
	- this time also add the payment method in "Payment Token"
- Go to "Scheduled Actions" and run "Sale Subscription: generate recurring invoices and payments" manually
- In the second subscription, there should be several messages (~10) saying the payment failed

### Cause:
When `grouped` is `True`, `_get_subscriptions_to_invoice()` is called for each partner. As one partner only has a subscription for which we can't create a payment, the method returns `sale.order()`.

So `all_subscriptions` is something like `[sale.order(2), sale.order()]`. Then in `_create_recurring_invoice()` the empty sale orders are ignored but the progress is not notified to the cron. So the cron is always in the "partially done" state and retries up to its max number of tries.

### Solution:
Exclude the null values returned by `_get_subscriptions_to_invoice()`.

opw-5242298

The \_retrieve \_product() function relies on a query with multiple domains OR'ed together. As the search will require a LEFT JOIN with the product_template table, the use of OR in the query prevents Postgres from utilizing indexes. This becomes a problem in databases with a large number of products since a seq scan would be very slow.

This commit changes the way this is done by performing separate queries instead of a single query with multiple conditions within an OR statement. Although this might seem a performance degradation, it actually allows these separate queries to utilize indexes and run much faster compared to the original approach. It also simplifies the priority logic and allows for faster early exits compared to the original one.

This function is mainly used with EDI crons (such as PEPPOL where this problem was noticed), which could require hundreds of product searches as it does a search per invoice line.

Benchmarks:

Importing a peppol document of 173 invoice lines.

| Num products | Num invoice lines | Before   | After   |
| ------------ | ----------------- | -------- | ------- |
| 864873       | 173               | 868.18 s | 19.43 s |
| 397005       | 173               | 468.91 s | 20.68 s |
| 8064         | 173               | 125.08 s | 20.1 s  |
| 564          | 173               | 119.9 s  | 20.21 s |

opw-5245007


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

Forward-Port-Of: odoo/odoo#240753
Forward-Port-Of: odoo/odoo#238853

**Issue:**
The forecasted inventory view assumed that line.reservation was always a `stock.picking`. In manufacturing flows, the reservation can be an `mrp.production`, which caused incorrect navigation to a `stock.picking` record.

Fix this by comparing both model and id when checking if the reservation differs from the outgoing document, and by opening the reservation using its actual model. This ensures the correct document is shown and avoids duplicate or invalid links in the "Used by" column.

**Steps to reproduce:**
- Create a v19 db with sale,mrp,sale_stock with `--demo-true`.
- Go to products -> search for 'FURN_0269' product and open form view.
- open forecasted smart button for forecasted reeport.
- check the used by column for mrp reservation
   - i.e,: `WH/MO/00001 - WH/MO/00001` appears twice.
   - clicking on first, opens correct record of `mrp.production` where the units is reserved.
   - clicking on the second, navigate to false record of `stock.picking` by taking the id of `mrp.produciton` as the reserve is having `_name: "mrp.production"`

**Screenshots from UI:**
- Product page:

<img width="1253" height="572" alt="stock_1" src="https://github.com/user-attachments/assets/13cd7f0a-34b0-48ea-a8d5-5337cbf9f5a5" />

- Forecasted report for that product:

<img width="1908" height="994" alt="stock_2" src="https://github.com/user-attachments/assets/ce0af8a3-9f37-469c-8119-36b6e7be9c4a" />

- Clicking on First `WH/MO/00001` button:

<img width="1265" height="568" alt="stock_3" src="https://github.com/user-attachments/assets/a8cb8a08-5c24-45f7-ad2e-5e3987f9ee70" />

- Clicking on second `WH/MO/00001` button, navigating to incorrect `stock.picking` by taking id of `mrp.production` even though there is no picking avaiable:

<img width="1264" height="519" alt="stock_4" src="https://github.com/user-attachments/assets/3a2d1613-ccbb-4994-898c-c885690c507e" />


**Final view Before and After the Fix:**
- For final view, In order to check the reservation done by `stock.picking`, I have created a `sale.order` having delivery for the same product to showcase both of them are working.

- **Before Fix:**
<img width="1907" height="994" alt="stock_5" src="https://github.com/user-attachments/assets/4441910e-348b-4270-ab1b-db903b334c97" />

- **After Fix:**
<img width="1905" height="940" alt="stock_66" src="https://github.com/user-attachments/assets/ba288e6b-b2c9-47ed-b752-233ff876fb55" />


opw-[5481220](https://www.odoo.com/odoo/70/tasks/5481220?debug=1)
upg-[3804157](https://upgrade.odoo.com/odoo/upgrade.request/3804157?debug=1)

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

This commit fixes the computation of excluded fields for the studio
export models.

Before this commit, the excluded fields computation was considering
computed and related fields in a similar way but there are subtle
differences that cause the excluded fields to sometimes be wrong.

While analyzing the heuristic with the ORM team, we decided to separate
the computation of related and computed fields.
After this commit, we have a refined computation of excluded fields for
related and computed fields:
- for computed fields (that are not related ones), we always exclude
  them except when they are writeable (i.e. stored or with inverse)
- for related fields, we always exclude them when the relation is in the
  list of related models to exclude.
  We also exclude them when they are not writeable on the current record
  only (not the source record), except if they are required.

Some export scenarios have been tested manually and brought with them
adaptations in the hardcoded lists of default fields to exclude.
The Industry team agreed with these changes.

Task id: opw-4974787

The base `_get_party_node` uses `commercial_partner.ref` for `PartyIdentification` and `commercial_partner.vat` for `CompanyID`. There was no logic to prefer `company_registry` when available.

Refs:
An independent invoice example: https://developer.vertexinc.com/einvoicing/docs/belgium-example-documents

https://github.com/odoo/odoo/blob/40c862476382c68d7f452284074f5b44955d1f98/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1564-L1566

https://github.com/odoo/odoo/blob/40c862476382c68d7f452284074f5b44955d1f98/addons/account_edi_ubl_cii/models/account_edi_xml_ubl_20.py#L1585

Steps To Reproduce:
- Have accounting, account_edi_ubl_cii and contacts installed.
- Create a Belgian company and set the VAT, Company ID and Reference (under Sales & Purchase tab).
- Create a contact and set his eInvoice format in Accounting tab to EU Standard (Peppol Bis 3.0) and make sure to give him a country.
- Go to accounting -> Customers -> Invoices and create an invoice for the contact you created.
- Send the invoice to the contact and download the XML from the chatter and inspect it.
- PartyIdentification/ID shows the partner's ref field value (e.g., "(odoobe)") instead of the company registration number.
- PartyLegalEntity/CompanyID uses the VAT number instead of the company registration number (ondernemingsnummer).


Ticket [link](https://www.odoo.com/odoo/project.task/5418190)
opw-5418190

Forward-Port-Of: odoo/odoo#243143

Before this commit, it could happen the test `test_inventory_packaging` fails sometime. It fails while checking the last assert:
```python
self.assertEqual(self.product1.qty_available, 15.0)
```
The error message is: `AssertionError: 16.0 != 15.0`

In the tour, we do a first inventory adjustment where we set the `proquct1` qty to 16, then we do a second inventory adjustment where we set its qty to 15.
Now, the assert sometime fails because in the tour, the last step check the success message is visible:
```javascript
trigger: ".o_notification_bar.bg-success",
```
The issue with that is that we already do a first inventory adjstment and its success notification is still visible while processing the second inventory adjustment, creating a race condition.

To fix that, we just need to close the first notification message, and to do so, this commit back-ports and uses the step utils' method `checkNotificationMessage` (see [1]) since this method checks a notification message is there and close it.

[1]: https://github.com/odoo/enterprise/pull/101495

runbot-build-error: [227692](https://runbot.odoo.com/odoo/runbot.build.error/227692)

Forward-Port-Of: odoo/enterprise#104481

**Steps to reproduce:** (only reproducible in production)
- Install accountant and l10n_co_dian
- Switch to a Colombian company (e.g. CO Company)

- In Accounting settings, configure the Colombian localization with valid DIAN credentials
- Create an invoice for a Colombian customer
- Confirm the invoice
- Send the invoice to DIAN
- Cancel and delete the invoice

- Create another invoice for another Colombian customer with the same name (sequence) than the previously deleted invoice
- Confirm the invoice
- Send the invoice to DIAN

**Issue:**
A previous fix (https://github.com/odoo/enterprise/commit/4d782030631350cfaa8f2993e68f33c9f66929e4) had been made to sync together a DIAN document from Odoo and DIAN when the following error was returned by DIAN:
"Regla: 90, Rechazo: Documento procesado anteriormente."
It can happen when an invoice is sent to DIAN but due to a connection issue, the DIAN response is not received and the invoice is flagged as rejected.
In that case, the "Regla: 90" error is returned by DIAN when trying to send the invoice again and the fix is linking the identifier returned by the DIAN error with the invoice to prevent this issue.
However, the fix wasn't taking into account the case in which the error returned by DIAN is legit and the identifier is linked to another document.
It results of having an invoice that is linked to an incorrect document in DIAN.
The customer, date and other info, completely different.

**Solution:**
When "Regla: 90" error is returned by DIAN, a check is performed to make sure that the customer, the issue date and time on the document in Odoo and on the XML from DIAN are the same before assigning the identifier from DIAN to the document in Odoo.

opw-5095212

Forward-Port-Of: odoo/enterprise#99936

Reverting this Commit: https://github.com/odoo/odoo/commit/0cda08f0c215ae6c7db0c4226a8b60ad3884e6b7
Before this commit:
The product comparison bottom bar had a z-index of only 3 (or 4 when expanded). This low z-index value caused it to be overlapped by any website snippets using grid mode with more than 3 items, as grid items conventionally have incremental z-index values (1, 2, 3, 4, ...) for JavaScript consistency.

The issue was not limited to s_banner_categories but affected all grid-based snippets, making the comparison bar inaccessible when positioned behind snippet content.

Solution:
Increase the comparison bar's z-index to -modal (1055 in Bootstrap), ensuring it always appears above regular page content including grid snippets, while still remaining below actual modals and dialogs.

After this commit:
The comparison bar consistently appears on top of all snippet content, ensuring users can always access and interact with product comparisons regardless of the page layout or snippet configuration. 
opw:5426163




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

Steps to reproduce [18.2+]:

1. Add a dynamic snippet to a website page (e.g., Events).

2. Unpublish all event records.

3. The snippet first appears with a visible header, which then
disappears.

[A]- Starting from [1], the `o_dynamic_empty` class was introduced to
handle the dynamic snippets visibility, and an upgrade script (see [3])
set this class by default on them.

Later in 18.0 (after [2]), the class was changed to `s_dynamic_empty` in
the XML template, while on the JS side, the class used to toggle snippet
visibility was `o_dynamic_snippet_empty`. This class was also added to
snippets on destroy (before saving).

[B]- As a result, a dynamic snippet may end up with:

- `o_dynamic_empty` & `o_dynamic_snippet_empty`: for old (before 18.0) but
edited snippets.
- `o_dynamic_empty`: for old snippets never updated in edit mode on 18.0.
- `s_dynamic_empty` & `o_dynamic_snippet_empty`: for new snippets created
in 18.0.

Remark: the `s_dynamic_empty` class was introduced by mistake and does
not have any associated CSS

Since only `o_dynamic_snippet_empty` has `display: none` in CSS, the
interaction flow became inconsistent (starting from 18.2): snippets were
initially visible, then hidden if no content was found... which caused
the flickering behavior described above.

And because of [B], old snippets with the `o_dynamic_empty` class
will be visible by default in 18.0.

This commit restores the intended (and original) behavior:

- A dynamic snippet should be invisible by default,

- Then the interaction decides (based on actual content) whether the
snippet should be displayed.

[1]: https://github.com/odoo/odoo/commit/63def9c87305dd7773e0592a28fe19d0b63c0878
[2]: https://github.com/odoo/odoo/commit/76cf201e1fc356ad00b27bcdec408c54949df33b
[3]: https://github.com/odoo/upgrade/commit/af5821d9aeb75d09653fc33f14e98fae5f5ba906

opw-5354523

Forward-Port-Of: odoo/odoo#240475
Forward-Port-Of: odoo/odoo#238305

Description of the issue/feature this PR addresses: Odoo can create two contacts for the same VAT number

Current behavior before PR:
If you have two incoming vendor bills (over a period of time) where the first bill has these details:
- VAT number: `BE0477472701`
- Name: `Odoo`

And the second bill (e.g three months later) has these details:
- VAT number: `BE0477.472.701`
- Name: `Odoo S.A`

Odoo will do something interesting and will create a second new contact.
The reason is because the fallback on `name` from `res.partner` fails (since "Odoo S.A" is not equal to "Odoo".
However, the `vat` number matching also fails! Since the VAT number "BE0477.472.701" is not identical to "BE0477472701".
Throughout Odoo however VAT numbers are parsed and stored without dots in it.
The function `_retrieve_partner_with_vat` however is an exception because the `vat` number here is sanitized for spaces but not for dots.
Because of the combination of no exact match on neither `name` nor `vat` it now creates a second contact although the VAT number is technically the same.

Desired behavior after PR is merged:
Both an incoming vendor bill with `0477.472.701` and `0477472701` match to the same contact even if there are dots in it and if the name of the company is different.


P.S: please find two sample XML's here: 
[sample_odoo_sa_bill.xml](https://github.com/user-attachments/files/24718225/sample_odoo_sa_bill.xml)
[sample_odoo_bill.xml](https://github.com/user-attachments/files/24718226/sample_odoo_bill.xml)

If you upload both back to back on a default V19 you will see two contacts.
After this code change you will only see one contact where both bills are mapped to the same contacts.

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

### Issue:
Due to this issue, the free product reward line might have a non-zero price.

#### To reproduce:
1- Install `website_sale_loyalty` and `sale_subscription`.
2- Enable `Discounts` on configuration.
3- Create a `promotion`:
   - rule: minimum quantity: 0, minimum purchase: 10
   - reward: free product, quantity: 1

4- Set a non-zero price on reward product from product page.
5- Create a product with price of 6 and publish it on the website.
6- On website, add 1 unit of created product to cart.
7- Open cart, and increase the quantity.
8- As you see the free product is added to cart but the price is non-zero.

### Cause:
Based on #89397, the reward line have the discount of 100. In the `_compute_discount` this discount is set to 0: https://github.com/odoo/odoo/blob/e48a7f1b03f23a4c96e35ee4350029439ec73e47/addons/sale/models/sale_order_line.py#L797

As `compute_discount` only depends on `product_id`, `product_uom_id`, `product_uom_qty` this shouldn't cause issue.

However, in `sale_subscription` its override includes `sale_order.plan_id` as dependency:
https://github.com/odoo/enterprise/blob/d0375627c6f8de6098dfe93a80f522f31e3a4174/sale_subscription/models/sale_order_line.py#L86-L90
Which setting `plan_id` to `False` here makes discount to be recomputed: https://github.com/odoo/enterprise/blob/d0375627c6f8de6098dfe93a80f522f31e3a4174/website_sale_subscription/models/sale_order.py#L27-L30

### Fix:
This can be avoided by filtering reward lines in a `_compute_discount` override. As none of reward lines regardless of reward type are expected to have a discount calculated this fix will not break any other flows.

It's noteworthy to mention that in the test, `_compute_discount` is directly called in order to mimic the flow without the need to install `sale_subscription`, as the `sale_subscription` is not root cause of the issue and the same issue could reproduced by any other modules overriding `_compute_discount`.

opw-5485796

### [[FIX] web: cleanup string-related utils](https://github.com/odoo/odoo/pull/241068/changes)

This commit cleans up several utility files relating to string-parsing
and translations. Main changes are:

- fixed `sprintf` and related functions: before this commmit, string
substitutions were incorrectly inserted in the template string, and it
was actually reflected in a test (template : `"<p>%s</p>%s"` => test
incorrectly asserted that both strings were inserted in the first "%s"
and "undefined" was inserted in the second);

- to replicate the Python homonymous behaviour: "%s" characters can now
be escaped in "sprintf-ed" strings by adding an additional "%" sign
before the expression;

- unification of translations via a TranslatedString class (which will
also simplify external overrides);

- unified API for some utility functions sharing the same purpose
(typically: accepting an iterable instead of a list, etc.);

- filling missing docstring, re-ordering functions and constants for
clarity;

- added "headless" tag to some utility functions' tests, when UI is not
needed.

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

- for more then one records having same code it's raising an singleton error at fetching the name

- error:
```py
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 6097, in template_l10n_mx_edi_report_invoice_document_6403
File "<6403>", line 6083, in template_l10n_mx_edi_report_invoice_document_6403_content
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 616, in __str__
self.html = ''.join(self.irQweb._render_iterall(
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/addons/base/models/ir_qweb.py", line 753, in _render_iterall
for item in frame.iterator:
File "<6403>", line 1723, in template_l10n_mx_edi_report_invoice_document_6403_t_call_0
File "/home/odoo/src/enterprise/l10n_mx_edi/models/account_move.py", line 424, in _l10n_mx_edi_get_extra_invoice_report_values
cfdi_infos['payment_way'] = f'{payment_way} - {payment_method.name}'
^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/odoo/odoo/orm/fields.py", line 1659, in __get__
record.ensure_one()
File "/home/odoo/src/odoo/odoo/orm/models.py", line 5934, in ensure_one
raise ValueError("Expected singleton: %s" % self)
ValueError: Expected singleton: l10n_mx_edi.payment.method(23, 24)
```

- OPW-5450360

Forward-Port-Of: odoo/enterprise#103460

Steps to reproduce:
- Activate the GS1 nomenclature
- Create a product with barcode: 15099590483921
- Scan the product from the Barcode app main menu

Problem:
A ValidationError is raised:
"A GS1 barcode nomenclature pattern was matched. However, the barcode failed to be converted to a valid date."

Explanation:
GS1 barcodes must follow a strict nomenclature based on well-defined
rules.
For example, a GS1 product barcode should start with the Application
Identifier 01 followed by 14 digits.

The GS1 parser processes the barcode rule by rule and applies the first
matching rule. In this case, the barcode 15099590483921 is interpreted
as a date because it starts with "15", which corresponds to a GS1
Application Identifier for a date. As a result, the parser attempts to
convert the first six digits into a date and raises a ValidationError.

Solution:
Catch the ValidationError raised during GS1 date parsing in main_menu
and explicitly reset parsed_results to False, allowing the normal main
menu resolution logic to continue. This prevents GS1 parsing errors
from blocking valid barcodes and ensures that product, picking, or
location detection still works as expected.

opw-5357611

**Steps to reproduce:** (only reproducible in production)
- Install accountant and l10n_co_dian
- Switch to a Colombian company (e.g. CO Company)

- In Accounting settings, configure the Colombian localization with valid DIAN credentials
- Create an invoice for a Colombian customer
- Confirm the invoice
- Send the invoice to DIAN
- Cancel and delete the invoice

- Create another invoice for another Colombian customer with the same name (sequence) than the previously deleted invoice
- Confirm the invoice
- Send the invoice to DIAN

**Issue:**
A previous fix (https://github.com/odoo/enterprise/commit/4d782030631350cfaa8f2993e68f33c9f66929e4) had been made to sync together a DIAN document from Odoo and DIAN when the following error was returned by DIAN:
"Regla: 90, Rechazo: Documento procesado anteriormente."
It can happen when an invoice is sent to DIAN but due to a connection issue, the DIAN response is not received and the invoice is flagged as rejected.
In that case, the "Regla: 90" error is returned by DIAN when trying to send the invoice again and the fix is linking the identifier returned by the DIAN error with the invoice to prevent this issue.
However, the fix wasn't taking into account the case in which the error returned by DIAN is legit and the identifier is linked to another document.
It results of having an invoice that is linked to an incorrect document in DIAN.
The customer, date and other info, completely different.

**Solution:**
When "Regla: 90" error is returned by DIAN, a check is performed to make sure that the customer, the issue date and time on the document in Odoo and on the XML from DIAN are the same before assigning the identifier from DIAN to the document in Odoo.

opw-5095212

Before this PR:

Everything works fine, but if the user change the decimal precision for foreign currency (i.e. USD, usually needed for export invoices, for example to three decimals), the SII system rejects the invoice. The rejectment cause is cryptic, and difficult to undertand, since it says: That is expecting a `<Documento>` tag, while this tag is not used in Exports invoices (the correct tag is `<Exportaciones>`.

The real cause of the error is that if the `<TotClauVenta>` tag has more than 2 decimals is ignored, and if it is ignored, the SII system assumes that the invoice is not an export invoice, and that's why an incorrect tag is expected by the validator.

After this PR:

We simply forced the decimals of the tag `<TotClauVenta>`to 2. This definitely solves the issue.

Source:

https://www.sii.cl/factura_electronica/formato_dte.pdf

Capture of this portion of the normative:

<img width="626" height="118" alt="Captura de pantalla 2026-01-07 a la(s) 18 21 06" src="https://github.com/user-attachments/assets/3b9ec8f0-d343-4819-8589-67afeeeba807" />

Forward-Port-Of: odoo/enterprise#103600

**Problem:**
When merging two tables in the middle of their service, the moving table's order would be deleted and then made again. The problem is that this order would be sent to the kitchen, making the order cancelled and displaying another one with the same content. This would lead to food wastage as the order would be made twice.

**Steps to reproduce:**
- Open the restaurant, chose two tables and make an order for the two of them.
- Confirm the order.
- Drag and drop the tables next to each other to merge them.
- The dragged table's order will be deleted and made again in the kitchen.

**Why the fix**
https://github.com/odoo/odoo/blob/cf525d2a981515d39a126c6dfb5a612338cc8d14/addons/pos_restaurant/static/src/overrides/models/pos_store.js#L349 The order was deleted, causing the kitchen to receive the same order two times. It was done because when merging the tables, the order would be cancelled, and put in the new table's orders that need to be confirmed (order button). It was only when pressing this button that the order was sent again to the kitchen. This was done in two steps, because we needed to first cancel the order and then manually confirm it again. The order is no longer cancelled, the kitchen doesn't get the order twice, as the order is not replaced.

opw-4654226

**Problem:**
When merging two tables in the middle of their service, the moving table's order would be deleted and then made again. The problem is that this order would be sent to the kitchen, making the order cancelled and displaying another one with the same content. This would lead to food wastage as the order would be made twice.

**Steps to reproduce:**
- Open the restaurant, chose two tables and make an order for the two of them.
- Confirm the order.
- Drag and drop the tables next to each other to merge them.
- The dragged table's order will be deleted and made again in the kitchen.

**Why the fix**
https://github.com/odoo/odoo/blob/cf525d2a981515d39a126c6dfb5a612338cc8d14/addons/pos_restaurant/static/src/overrides/models/pos_store.js#L349 The order was deleted, causing the kitchen to receive the same order two times. 
It was done because when merging the tables, the order would be cancelled, and put in the new table's orders that need to be confirmed (order button). 
It was only when pressing this button that the order was sent again to the kitchen. This was done in two steps, because we needed to first cancel the order and then manually confirm it again. 
The order is no longer cancelled, the kitchen doesn't get the order twice, as the order is not replaced. 
The deleteOrders function would make those two steps, first sending another ticket in the kitchen, then deleting the one that was duplicated and just sent to the kitchen.

opw-4654226

**Problem:**
When grouping the commissions, the achieved_rate field was computed by making the average of the achieved_rates, making a regular average. This average doesn't really make sense as a commission of 1 euros would have the same weight as a commission of 1000 euros. It made sense to compute the average of the achieved rate as a weighted average, so that the commissions worth more would have more weight in the computed result.

**Steps to reproduce:**
- Go to commissions in the sales app
- Make the achieved rate field visible by clicking on the dots on the right
- Make a Group By
- The average of the achieved rate is not computed correctly

**Cause of the issue:**
https://github.com/odoo/enterprise/blob/7d52febd7d870d381c887e171217b9a13fed4b4a/sale_commission/report/commission_report.py#L19 The default average aggregator was given, but didn't take into account that some commissions should weight more in the average result.

**Fix:**
The read_group function was overrided to compute the achieved_rate depending on the achieved and the target_amount fields.

opw-4512739

**Steps to reproduce:**
* Install `Accounting` and `sales` modules.
* Create two companies and enable **Inter-Company Transactions** with **Synchronize invoices/bills** in settings for both companies.
* Create a **payment term** assigned to **Company A**.
* Create a **sale order** from Company A to Company B using that payment term.
* Confirm the sale order and create the **invoice**.
* Post the invoice to trigger the inter-company vendor bill.

**Observed behavior:**
* The generated **vendor bill** for Company B uses **Company A’s payment term**.
* Posting fails because the payment term is incompatible with Company B.

**Cause:**
* Inter-company document creation reuses payment terms without checking whether they belong to the **target company**.
* Payment terms from the source company can be propagated to the destination document.

**Fix:**
* Ensure only **company-compatible** payment terms are applied when creating inter-company sale orders, purchase orders, and invoices.
* Payment terms belonging to a different company are now ignored.

**NOTE**: test is not implemented due to technical limitations. Inter-company invoice synchronization relies on UI context propagation that cannot be replicated in unit tests. The payment term validation logic depends on web client context flags that are only set during real UI interactions, not programmatic execution.

opw-5392745

**Steps to reproduce:**

- Install the `purchase_stock` module.
- Create a product and configure a Vendor Pricelist for a vendor.
Include a discount on the vendor pricelist line.
- Create a Purchase Order for the same vendor.
- In the Purchase Order, add a Purchase Order Line using 
the catalog (vendor catalog popup) and add a configured product.

**Observed behavior:**
- The unit price on the Purchase Order Line becomes vendor `unit price − discount`
The `discount` field remains empty, causing incorrect price calculations.

---
**Example**
---

Product-A  - > Vendor Price list - > Vendor - > Test Vendor, Unit price = 100 and discount 10

- Create PO with `Test Vendor` and add a Product to POL via catalog then

 **Current behavior:**
Product - A , qty - >1, unit price -> 90, discount->0% , subtotal ->90 

 **Expected behavior :**
Product-A , qty->1, unit_price->100, discount->10%, subtotal->90

---

**Cause:**
- The catalog selection applies the vendor pricelist discount directly to 
the unit price instead of populating the discount field.

**Fix:**
- Use the vendor pricelist's price as the `unit_price` and apply 
vendor pricelist discount to the discount field on the Purchase Order Line.

---
`NOTE` - This issue is resolved from version 18.2, In this [Commit](https://github.com/odoo/odoo/pull/227695/commits/6b91f393353bcdaeed076d58dcac3149ed587e77#diff-1281da5f4d0a3daaf162a2e6456469537d1b74b8034437783c9c717307aa8fcd)

---
opw-5217345

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

**Problem:**
When splitting a MO that has products with components tracked by
lots, the new MOs won't follow the removal strategy assigned to
said product. The first MO will have the first lot, and the
second MO will have the second lot, even if some products are still
available in the first lot. Once every lot has been used once,
the removal strategy is applied as intended on the remaining MOs.

**Steps to reproduce:**
- Make a product, that has a BoM with a component that is tracked by lots
- Make two lots for this components
- Set the removal strategy for this component to FIFO (or another one)
- Make a manufacturing order with quantity high enough to use multiple lots
- Confirm the MO and then split it in as much parts as components were used
- Look at the lot of the second MO, it is the second lot, even though there are still components available in the first lot

**Cause of the issue:**
The removal strategy was not taken into account as a whole
when splitting the MO. Thus resulting in values that seems
kind of random. As the components were assigned one at a time
to the backorders, they did not synchronize between
themselves before being assigned, which explains why they
did not have a correct lot assigned.

**Fix:**
As the components are assigned one at a time during the MO
splitting, it is not an option to try and sort them according
to the removal strategy during the assignation. We instead
wait for all of the components to be assigned (in a wrong way)
then unassign them all just to assign them the right way right
afterwards. This is done by calling *_action_assign* which takes
the removal strategy into account. This time around, all the
components are assigned at them same time, making the
removal strategy applicable.

opw-4678932