When using QR code self-ordering with "service at table" and "payment at the end of the meal", self-orders were only visible individually on the POS terminal when clicking on the table, even though multiple orders existed for the same table. Only the last order made was visible.

Steps to reproduce:
-------------------
* Configure POS with self-ordering mode 'mobile', pay_after='meal', service_mode='table'
* Open POS session
* Scan QR code from table and create a self-order
* Create another order from POS terminal on the same table
* Click on the table from the floor plan

> Observation:
Only the last order was visible when clicking on the table, even though both orders appeared in the Orders tab with the same table tag.

Why the fix:
------------
Self-orders created via QR scan initially only had `self_ordering_table_id` set, but not `table_id`. The existing `DevicesSynchronisation` merge logic only merges orders that have the same `table_id`. By setting `table_id` on self-orders when the conditions are met (pay_after='meal' and preset.service_at='table') self-orders can now be automatically merged with regular POS orders on the same table during sync, ensuring all orders are visible when clicking on a table.

opw-5250653

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

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

Forward-Port-Of: odoo/odoo#235000

**Issue:**
When invoices in a journal enabled to "Use Documents" for LATAM legal invoicing have a sequence prefix with numbers, the next invoice will restart the sequence and try to use already-used sequences.

**Steps to Reproduce:**
- Install l10n_pe_edi
- Change to PE Company
- Duplicate the Customer Invoice journal, give it shortcode "01A"
- Create an invoice in dupe journal, set customer to "Comercial Constructora los Patitos S.A.", set product and tax, Document Type = (01) Factura
- Confirm the invoice, it will have name "F F01-00000001"
- Duplicate the invoice

-> The new invoice has the same sequence number, and the document number is visible

Expected: Invoice is called "Draft" (/), document number is not visible, and upon confirming the invoice, it will have the name "F F01-00000002"

**Cause:**
- LATAM invoices do not follow the standard formats in sequence_mixin.py, so _deduce_sequence_number_reset will always return "never"
- However, the result of this method is used in _get_last_sequence_domain, and assumes that the sequence follows the corresponding format to "never" (_sequence_fixed_regex)
- This isn't the case if the prefix has numbers, it will be captured in the _sequence_yearly_regex
- anti-regex is used to filter sequences that aren't _sequence_fixed_regex, but this causes prefixes with numbers to never be found, and always restart the sequence

**Solution:**
- Add context value "no_anti_regex" to skip sequence exclusion
- If the invoice is LATAM, call _get_last_sequence_domain with context "no_anti_regex" = True so no sequences are excluded.
- Because LATAM invoices are always in a fixed format, we don't need to filter out sequences in other formats

opw-5111844

Forward-Port-Of: odoo/enterprise#101620

### 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

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

**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

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

### [[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