Description of the issue/feature this PR addresses:
German regulations specify that the LeitwegID appears in the field BT-10. However, this field is usually filled with the value of the "ref" field of the customer, potentially creating a situation where the Odoo user thinks they have entered the data into Odoo correctly (Having set the Peppol Endpoint Type to "Leitweg ID" and entered the Leitweg-ID into the Peppol Endpoint field), but their invoice is still rejected because the Leiweg ID does not appear in the correct spot.

Current behavior before PR:
To generate a valid X-Rechnung to a German government office, the Leitweg-ID has to be put into the "Reference" field of the contact, conflicting with other potential uses for that field.

Desired behavior after PR is merged:
If the Peppol Endpoint is set to be a LeitwegID, the X-Rechnung also fills it into the BT-10 Field to ensure conformity to the German regulations.


References:
[German FAQ regarding Leitweg-ID](https://e-rechnung-bund.de/faq/#leitweg-id)
[Specification of the LeitwegID](https://xeinkauf.de/app/uploads/2022/11/Leitweg-ID-Formatspezifikation-v2-0-2-1.pdf)

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

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

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