Before this commit:
migration script only creates a new tax group.

After this commit:
migration script will create all tax groups that are required for  new taxes if they do not already exist

Why:
During the migration if the tax group is not found then the value error is raised

There are 2 reason of why the tax group is not found :
1. User deletes it by themselves
2. In the upgrade script of account in version saas~16.2.1.2 the pre-migrate script where global scope of tax groups was converted to company-specific, [Ref](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L173) If the tax groups are not associated with any tax or any account_move_line then it is deleted.


User Traceback : 
`  File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2203, in _xmlid_lookup
    raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: account.1_l10n_id_tax_group_non_luxury_goods`


account_tax_group records in production : 
```
kdes_3444743=> select id,name from account_tax_group;
 id |                             name                              
----+---------------------------------------------------------------
  1 | {"en_US": "Taxes", "id_ID": "Pajak"}
  2 | {"en_US": "Luxury Good Taxes", "id_ID": "Pajak Barang Mewah"}
  3 | {"en_US": "Non-luxury Good Taxes", "id_ID": "Pajak Barang"}
  4 | {"en_US": "Zero-rated Taxes", "id_ID": "Pajak Nol"}
  5 | {"en_US": "Tax Exempted", "id_ID": "Bebas Pajak"}
(5 rows)
```

Query executed [here](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L152) : 
```
        WITH company AS (
            SELECT "company_id" AS id,
                   "tax_group_id" AS tg_id
              FROM "account_move_line"
             WHERE "company_id" IS NOT NULL
               AND "tax_group_id" IS NOT NULL
             UNION 
            SELECT "company_id" AS id,
                   "tax_group_id" AS tg_id
              FROM "account_tax"
             WHERE "company_id" IS NOT NULL
               AND "tax_group_id" IS NOT NULL
        )
        INSERT INTO account_tax_group ("country_id", "create_date", "create_uid", "name", "preceding_subtotal", "sequence", "write_date", "write_uid", company_id, _tmp_orig_id)
             SELECT "tg"."country_id", "tg"."create_date", "tg"."create_uid", "tg"."name", "tg"."preceding_subtotal", "tg"."sequence", "tg"."write_date", "tg"."write_uid", company.id, tg.id
               FROM account_tax_group tg,
                    company
              WHERE company.tg_id = tg.id
```


Above selection query on user's DB :
```
kdes_3444743=> SELECT "company_id" AS id,
                   "tax_group_id" AS tg_id
              FROM "account_move_line"
             WHERE "company_id" IS NOT NULL
               AND "tax_group_id" IS NOT NULL
             UNION 
            SELECT "company_id" AS id,
                   "tax_group_id" AS tg_id
              FROM "account_tax"
             WHERE "company_id" IS NOT NULL
               AND "tax_group_id" IS NOT NULL;
 id | tg_id 
----+-------
  1 |     1
  1 |     2
(2 rows)

```
As only 2 tax groups are associated with the account_move_line and account_tax
They are only being inserted to the able along with the company id prefix and company_id field set
, remaining enteries are deleted in [next query](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L173).

Same is the case with the records in [ir_model_data](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L174-L196). 

OPW : 5358546
UPG : 3444743

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

Forward-Port-Of: odoo/odoo#238981

Issue: YouTube has changed its referrer policy to enforce "strict-origin-when-cross-origin". 
Without this, it can throw a 153 error and block the video.

To replicate in runbot ,add "<meta name="referrer" content="no-referrer"/>" to any major page like the main layout or footer. This sets it for the entire page. 
Therefore, to enforce YouTube's calls to have the proper referrerpolicy, I hardcoded it directly.

Fix:
added 'referrerpolicy="strict-origin-when-cross-origin"' to the iframe.

opw-5239363


Description of the issue/feature this PR addresses:
Our website allows for customization, including the ability to modify meta tags. In ticket#523963, the customer added "<meta name="referrer" content="no-referrer" />" which forced all calls to be set with referrerpolicy="no-referrer" when it's required to have 'referrerpolicy="strict-origin-when-cross-origin"' for embeded videos to youtube

Current behavior before PR:
If a customer sets "<meta name="referrer" content="no-referrer" />" on any page, YouTube blocks it on that page; if it's in the header or footer, the entire website is then blocked. 

Desired behavior after PR is merged:
After it now enforces the call to have 'referrerpolicy="strict-origin-when-cross-origin"' even if the tag <meta name="referrer" content="no-referrer" />". Allowing YouTube to be used. 



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

Forward-Port-Of: odoo/odoo#237182

Issue
=====
When scanning a package as result package, if the package is empty, it works, but if this package already has content, it doesn't work.

How to reproduce
================
1. Enable "Packages" and "Storage Locations" settings;
2. Create two packages with some content in WH/Stock/Shelf 1;
3. Create an empty package;
4. Create an internal transfer directly from the Barcode app;
5. Scan Shelf 1 barcode and scan first package;
6. Scan the empty package => It's assigned as the result package;
7. Confirm the operation;
8. Create another internal transfer;
9. Scan Shelf 1 barcode and scan second package;
10. Scan the no more empty package => This time, it's not assigned as the result package.

Reason
======
A package was assigned as the result package only if one of the following conditions is matched:
1. The scanned package is empty (it's what's happening in 6.);
2. The selected line has no result package yet and the scanned package is in the selected line's destination location.

Here, it doesn't work because since we move a package, the barcode line has already a destination package (the same then the source package.)

Fix
===
For the condition 2., adapt the condition to make it works too if the selected line has the same package as the source and result package.

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

Forward-Port-Of: odoo/enterprise#102051
Forward-Port-Of: odoo/enterprise#101357

**Steps to reproduce:**
* Install the **Accounting** and **l10n_sa_edi** modules.
* Go to `Sales` journal and in ZATCA section click on **Re-Onboard**.
* Create Tax with 15% tax with **included price** set as **tax-included**.
* Create a customer invoice.
* Set **price_unit = 200**, **quantity = 7**, with **15% tax included** and confirm the invoice.
* Generate the **ZATCA XML** by clicking **Process Now** in the info banner displayed above the invoice.
* Submit the XML to **ZATCA validation**.

**Observed behavior:**
* ZATCA validation fails with error **BR-KSA-EN16931-11**
* The XML uses **PriceAmount (BT-146)** rounded to **2 decimals** (e.g., 173.91).
* ZATCA computes: **173.91 × 7 = 1217.37**, but the XML’s **LineExtensionAmount (BT-131)** is **1217.39**, creating a mismatch and triggering validation failure.

**Cause:**
* In v19, `_add_document_line_price_nodes()` inherited from `account.edi.xml.ubl_20` uses `float_round` with **product_price_dp = 2 decimals** for **PriceAmount**.
* This precision is insufficient when ZATCA recalculates totals for tax-included prices, causing rounding discrepancies.

**Fix:**
* Override `_add_document_line_price_nodes()` in **l10n_sa_edi** to round `gross_price_unit_currency` to **10 decimal places** instead of 2.
* Ensures PriceAmount has sufficient precision to satisfy ZATCA validation rules.

opw-5346886

For the `Türkiye` localization, sending an invoice by email with a recipient bank causes an error.

Steps to reproduce:
1) Install `accountant` and `l10n_tr_nilvera_einvoice` modules with demo data. 
2) Switch to TR Company.
3) Create a customer with country set to `Türkiye`.
4) Open the TR company contact and on the Accounting page edit an existing bank
   account, add a new bank (e.g., 'Test-Bank'), and set `Send Money` to
   `Trusted`.
5) Create an invoice for the customer, confirm it, and send it by email.

ref video: https://drive.google.com/file/d/1OoUzJ-Dr2uuy4yk9P-CKUS0L6OSgeyJ3/view?usp=sharing

Error:
KeyError: 'country_id'

Root Cause:
When sending the invoice, the system generates the invoice XML. In the method `_get_address_node` (see [1]), there is a special case to determine the correct country for `res.bank`. However, when `vals['partner']` is a `res.bank` record, no `model` is provided in `vals`, so it defaults to `res.partner`. The code then attempts to access `partner['country_id']`, which does not exist on `res.bank`, raising the error.

FIX:
Ensure the `model` is set to `res.bank` when `vals['partner']` is a `res.bank` record, ensuring the correct country value is used.

[1]- https://github.com/odoo/odoo/blob/0190bb7faca1dd5ce38dfdacbb8fa446f06d59a3/addons/l10n_tr_nilvera_einvoice/models/account_edi_xml_ubl_tr.py#L165-L181

opw-5103598

## Issue:
When exporting the XML for a VAT return, the client nihil field was incorrectly set to YES
According to Belgian regulations, this is only allowed on the last report of the calendar year
https://finances.belgium.be/sites/default/files/downloads/165-625-directives-2019.pdf

## Cause:
Prior to 18.3, nihil was a checkbox option on export
Since 18.3, it is automatically selected based solely on a price formula, without checking the report’s date

This PR brings back the Client Nihil checkbox in 19.0
But didn't change the default value
Causing the issue to still be present
https://github.com/odoo/enterprise/pull/99496

## Steps to reproduce:
- Select the Belgian company
- Open the Tax Return and select the VAT Return
- Click Returns and enter an opening date in January
- Click Review for the first available report
- Ignore errors and return to previous page
- Click on Submit -> Download XML
- Before the fix, ClientListingNihil is set to YES

## Potential remaining issue:
The legal document specify that it should also be checked in case of "cessation d’activité"
So it may be interesting to consider adding the option back

opw-5184056

Forward-Port-Of: odoo/enterprise#98982

**Behavior:**
Currently Intrastat reports are exported from the account.return view, and will be exported specifically in their extended mode and will contain both arrivals and dispatches. This causes issues for some users that want more specific formats like standard over extended, only arrivals/dispatches or both, etc... And this can cause them to not be able to submit their reports.

The solution is to currently reenable the user to export their report to XML from a cog menu in the Intrastat Report view. While still leaving the current flow through account.return possible, until a better solution is thought of.

**Steps to reproduce:**
- Connect to a company under Belgian Localisation.
- Create a product and, under the Accounting tab, specify a Commodity code (eg Live asses) and Country of Origin (Belgium)
- Create an Invoice containing the product to a Client in another EU Country (eg Luxembourg) and under the  'Other Info' tab, specify Intrastat Countrt (Belgium) - You can choose to leave out Intrastat Transport Mode and Incoterm, this will make the resulting XML have some  missing informations
- Create a Bill with the product with the same settings
- If you go to Intrastat Report, after changing the 'Report' filter to Intrastat (Goods) you will now be able to see an arrival and a dispatch. The extended mode filter is enabled by default, if you didnt fill Intrastat Transport Mode and Incoterm, you will see these missing.
- From this view there is currently no way to export the XML, to do that click the Returns button (select an Opening Date for accounting if needed), click on 'New' and specify Intrastat in the Return Type and a time window containing your Invoice and Bill.
- Then you will see an Intrastat Report show up and after selecting Review, then Submit, you will be able to download the XML. which will contain dispatches and arrivals and will be in Extended Mode. Which, if missing Transport/Incoterm, will fail when submitted to OneGate

opw-5347238

**Current behavior before PR:**

- When dragging and dropping elements with attributes and classes, any non-whitelisted attributes and classes were removed during the `cleanForPaste` process. This caused structural issues and loss of formatting after the drop.

- When an image had a caption and only the image was selected and cut, the image was removed but the caption incorrectly remained

- When dragging and dropping an image without an active selection on the image, the image was not removed during the drop. This resulted in the image being duplicated, one at the original position and another at the drop location.

- When selecting an image with a caption and performing copy-paste, only the image was copied and pasted.

**Desired behavior after PR is merged:**

- An `application/vnd.odoo.odoo-editor` dataTransfer type is now set during `dragstart` for editor elements. As a result, we no longer need to clean the `dataTransfer` content during drop, preserving the original structure and preventing the loss of attributes and classes.

- Cutting an image that contains a caption now correctly removes both the image and its associated caption.

- The image is now selected on pointerdown event . As a result, when the image is dropped, deleteSelection correctly removes the original image before inserting the new one, preventing duplication.

-  Now, when an image with a caption is selected and copy-pasted, the entire image along with its caption is correctly copied and pasted.


task: 4914451

## Versions
saas-18.3 > saas-18.4
Backport of OE's commit c02eb8584da1cef7d28310d9be947b56a38a5cbd

## Issue
A customer subscribing to a service can checkout without filling its data (incl. country). This leads to a failure of the next payment and a message in the chatter telling that "Automatic payment failed. No country specified on payment_token's partner".

## Steps to reproduce
*Ensure Sales app is installed*
- Create a customer account without filling personal data in;
- Navigate to the shop:
  - Look for a subscription service (ending with "SUB") and add it to cart;
  - Go to the cart and click the checkout button (automatically bypassing the addresses form);
  - Pay with Demo.
- Logout and sign in as admin user:
  - Go to Sales and open the latest SO (related to the test user):
    - Duplicate the SO and activate debug mode;
    - Open "Other Info" tab:
      - Change the subscription starting date for any date in the past;
      - Set the Payment Token selecting the available one; - Confirm the order.
- Navigate to Scheduled Actions:
  - Look for "Sale Subscription: generate recurring invoices and payments" action and open it:
    - Click "Run Manually".
- Come back to the duplicated subscription SO and look at the chatter's last message:
  - OdooBot's message tells that "Automatic payment failed. No country specified on payment_token's partner".

## Cause
Task 4307281 introduced address info bypass to fasten checkout for services but subscriptions, even for services, require the country to be set for recurring payments as per https://github.com/odoo/enterprise/blob/f40e24e67a1664a13acdd01578d8269d084ee421/sale_subscription/models/sale_order.py#L1751-L1757

opw-5412037

Forward-Port-Of: odoo/enterprise#102168

Two related overlay reposition issues are solved separately out of iframe and in the iframe.

**Commit 1:**
[FIX] html_editor: avoid wrong range after insert and popover reposition

Before this commit: The link popover is repositioned at the beginning of the
text when editing url. When insert, we first delete the non-collapsed selection,
then we split the text node by splitTextNode at the collapsed selection. However,
splitTextNode resets the text node's value by its substring, which breaks the
range of the collapsed selection. This range is stored and used to reposition
the overlay when the selection is not in the editable.

Reproduction:
1. selection some text, create a link
2. go the the url field and type something
3. the popover is replaced to the beginning of the text.

After this commit: we use dom function splitText to split the text only when we
need to, e.g. when the currently selection's offset isn't at the beginning or
the end of the text node. The dom function keeps the range properly maintained
after splitting.

However, there is a limitation case from how we create the link on selection,
how the browser manages the selection's range and how the overlay reacts to it.

The limitation case is when the selection is inside one text node and selecting
the whole text node of the range's startContainer (which is the same with
endContainer). When the link is created, we do extractContent on the selection's
range, put it in the link and insert the link at the collapsed selection. During
this process, the browser loses the range's start/end container which leads to
invalid start/end container.

For this range isn't valid case, it triggers the overlay plugin's special
handler which inserts one shadow caret (which is after the inserted link) and
uses it to calculate the position. Because the shadow caret is inserted by the
cloned collapsed range, we can't really have enough context from the range
(about where to re-place the caret) to manipulate the position.


**Commit2:**
[FIX] html_editor: pass selection data to overlay to avoid reposition in iframe

Before this commit: the overlay plugin uses the editable's document's selection
to check if the current selection is in the editable. It works when there's no
iframe, as the overlays are part of the document. However in an iframe's
editable zone, e.g. the website editing zone, the overlays are not under the
iframe document but under the outer window's document. When checking iframe
document's selection, it cannot detect the selection in the overlay, which gives
a wrong "inEditable" value.

After this commit: we pass the getSelectionData to the overlay so it can use the
existing currentSelectionIsInEditable

task-5184799


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

Before this commit:
migration script only creates a new tax group.

After this commit:
migration script will create all tax groups that are required for  new taxes if they do not already exist

Why:
During the migration if the tax group is not found then the value error is raised

There are 2 reason of why the tax group is not found :
1. User deletes it by themselves
2. In the upgrade script of account in version saas~16.2.1.2 the pre-migrate script where global scope of tax groups was converted to company-specific, [Ref](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L173) If the tax groups are not associated with any tax or any account_move_line then it is deleted.


User Traceback : 
`  File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2203, in _xmlid_lookup
    raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: account.1_l10n_id_tax_group_non_luxury_goods`


account_tax_group records in production : 
```
kdes_3444743=> select id,name from account_tax_group;
 id |                             name                              
----+---------------------------------------------------------------
  1 | {"en_US": "Taxes", "id_ID": "Pajak"}
  2 | {"en_US": "Luxury Good Taxes", "id_ID": "Pajak Barang Mewah"}
  3 | {"en_US": "Non-luxury Good Taxes", "id_ID": "Pajak Barang"}
  4 | {"en_US": "Zero-rated Taxes", "id_ID": "Pajak Nol"}
  5 | {"en_US": "Tax Exempted", "id_ID": "Bebas Pajak"}
(5 rows)
```

Query executed [here](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L152) : 
```
        WITH company AS (
            SELECT "company_id" AS id,
                   "tax_group_id" AS tg_id
              FROM "account_move_line"
             WHERE "company_id" IS NOT NULL
               AND "tax_group_id" IS NOT NULL
             UNION 
            SELECT "company_id" AS id,
                   "tax_group_id" AS tg_id
              FROM "account_tax"
             WHERE "company_id" IS NOT NULL
               AND "tax_group_id" IS NOT NULL
        )
        INSERT INTO account_tax_group ("country_id", "create_date", "create_uid", "name", "preceding_subtotal", "sequence", "write_date", "write_uid", company_id, _tmp_orig_id)
             SELECT "tg"."country_id", "tg"."create_date", "tg"."create_uid", "tg"."name", "tg"."preceding_subtotal", "tg"."sequence", "tg"."write_date", "tg"."write_uid", company.id, tg.id
               FROM account_tax_group tg,
                    company
              WHERE company.tg_id = tg.id
```


Above selection query on user's DB :
```
kdes_3444743=> SELECT "company_id" AS id,
                   "tax_group_id" AS tg_id
              FROM "account_move_line"
             WHERE "company_id" IS NOT NULL
               AND "tax_group_id" IS NOT NULL
             UNION 
            SELECT "company_id" AS id,
                   "tax_group_id" AS tg_id
              FROM "account_tax"
             WHERE "company_id" IS NOT NULL
               AND "tax_group_id" IS NOT NULL;
 id | tg_id 
----+-------
  1 |     1
  1 |     2
(2 rows)

```
As only 2 tax groups are associated with the account_move_line and account_tax
They are only being inserted to the able along with the company id prefix and company_id field set
, remaining enteries are deleted in [next query](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L173).

Same is the case with the records in [ir_model_data](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L174-L196). 

OPW : 5358546
UPG : 3444743

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

Forward-Port-Of: odoo/odoo#238981

Issue: YouTube has changed its referrer policy to enforce "strict-origin-when-cross-origin". 
Without this, it can throw a 153 error and block the video.

To replicate in runbot ,add "<meta name="referrer" content="no-referrer"/>" to any major page like the main layout or footer. This sets it for the entire page. 
Therefore, to enforce YouTube's calls to have the proper referrerpolicy, I hardcoded it directly.

Fix:
added 'referrerpolicy="strict-origin-when-cross-origin"' to the iframe.

opw-5239363


Description of the issue/feature this PR addresses:
Our website allows for customization, including the ability to modify meta tags. In ticket#523963, the customer added "<meta name="referrer" content="no-referrer" />" which forced all calls to be set with referrerpolicy="no-referrer" when it's required to have 'referrerpolicy="strict-origin-when-cross-origin"' for embeded videos to youtube

Current behavior before PR:
If a customer sets "<meta name="referrer" content="no-referrer" />" on any page, YouTube blocks it on that page; if it's in the header or footer, the entire website is then blocked. 

Desired behavior after PR is merged:
After it now enforces the call to have 'referrerpolicy="strict-origin-when-cross-origin"' even if the tag <meta name="referrer" content="no-referrer" />". Allowing YouTube to be used. 



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

Forward-Port-Of: odoo/odoo#237182

Since this change: https://github.com/odoo/odoo/pull/185674/commits/b663a6e3dbda6eda84e4a6b051acfc8511476cd3#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR503 It introduces two bugs:
- Create a project A and project B, activate the top bar in both projects
    - Create a new custom embedded action in project A
    - Switch to project B (by changing the URL), the custom action of project A is present in project B
- In a project, create a new custom embedded action, refresh the page, the action is not visible nor available in the top bar.

It enters the if condition, and get the "lastAction", which may not contain the same "embedded_action_ids" than the current action (targeting another project or the same project if we just refreshed the page). It enters the condition because the path of the action is the same ("tasks") and no "active_id" is specified in the context of the action.

We then force the load of the action if the "lastAction" stored in the browser session had embedded actions, to be sure to get the latest embedded actions linked to the current action in case of any, and not keep the ones linked to "lastAction".

task-5269261

Forward-Port-Of: odoo/odoo#237695

**Steps to reproduce:**
- enable "packages" and "batch transfers" settings
- open wharehouse management/operation type
- select internal transfer
- check "automatic batch" and group by "contact"
- create two storable product with an on hand quantity of 10
- create a an internal transfer for the first product for a qty of 10
- mark it as to do
- do the same for the second product and make sure that it's the same 
contact
- open barcode and select batches
- select the last batch created
- scan WH-STOCK
- enter and confirm a quantity of 4 for each line
- click on put in pack
(at this step we can already see that the two new lines created are 
associated wit the second picking, even though it should be one line 
per picking)
- click on the +6 on each line and click on put in pack
- validate

**Current behavior:**
- a back order has been created for the first picking
- the first internal transfer has only delivered 4 units of the first 
product
- the second internal transfer has delivered 10 of the second product 
and 5 of the first product

**Expected behavior:**
both pickings should have delivered 10 of their product

**Cause of the issue:**
The lines created when clicking on "put in pack" for the first time
are both associated with the second picking because the line split:
https://github.com/odoo/enterprise/blob/898e3e47cfe3b86230da2b146960983d7ad144d0/stock_barcode/static/src/models/barcode_picking_model.js#L514
and the picking_id of the new line is set to the values provided by the
`_getNewLineDefaultValues` as the picking_id of the last selected `line`:
https://github.com/odoo/enterprise/blob/24b4e49dbe16cb8bd40170abfc089dd64c3f34dd/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L280-L281
rather than from the values of the initial line it is split from.

opw-4952964

Forward-Port-Of: odoo/enterprise#92891
Forward-Port-Of: odoo/enterprise#91378

**Steps to reproduce:**
- enable "packages" and "batch transfers" settings
- open wharehouse management/operation type
- select internal transfer
- check "automatic batch" and group by "contact"
- create two storable product with an on hand quantity of 10
- create a an internal transfer for the first product for a qty of 10
- mark it as to do
- do the same for the second product and make sure that it's the same 
contact
- open barcode and select batches
- select the last batch created
- scan WH-STOCK
- enter and confirm a quantity of 4 for each line
- click on put in pack
(at this step we can already see that the two new lines created are 
associated wit the second picking, even though it should be one line 
per picking)
- click on the +6 on each line and click on put in pack
- validate

**Current behavior:**
- a back order has been created for the first picking
- the first internal transfer has only delivered 4 units of the first 
product
- the second internal transfer has delivered 10 of the second product 
and 5 of the first product

**Expected behavior:**
both pickings should have delivered 10 of their product

**Cause of the issue:**
The lines created when clicking on "put in pack" for the first time
are both associated with the second picking because the line split:
https://github.com/odoo/enterprise/blob/898e3e47cfe3b86230da2b146960983d7ad144d0/stock_barcode/static/src/models/barcode_picking_model.js#L514
and the picking_id of the new line is set to the values provided by the
`_getNewLineDefaultValues` as the picking_id of the last selected `line`:
https://github.com/odoo/enterprise/blob/24b4e49dbe16cb8bd40170abfc089dd64c3f34dd/stock_barcode_picking_batch/static/src/models/barcode_picking_batch_model.js#L280-L281
rather than from the values of the initial line it is split from.

opw-4952964

Forward-Port-Of: odoo/enterprise#92530
Forward-Port-Of: odoo/enterprise#91378

In #92208 the CAF system was improved to find the next starting value in the right sequence if there are multiple in the system. If no CAFs are found, it will reset to the document types starting number.

This worked except in the case where there are multiple CAFs that are currently marked active in a document type. As it tries to access `caf.start_nb` it hits an ensure_one() which throws a traceback whenever you open most account.moves on the DB.

Steps to reproduce:
- Modify the CAF for Doc Type 33 (Electronic Invoices) to have a smaller range than 1 - 999,999 (1 - 5)
- Create Two new CAF files also for Doc Type 33 that start after this value (6 - 10 and 11 - 15 for example).
- Mark the original to be spent via cancelling it and try to open an invoice. It will find both of the new CAFs and try to get the start_nb of the recordset.

In discussion with the PO, when we have multiple CAFs, we should pick by the lowest start number as it will allow for any gaps that might exist be filled.

opw-5414350

Forward-Port-Of: odoo/enterprise#102385

Steps to reproduce:
- Enable Rental pickings
- Create a rental for a product, for 4 quantity
- Process the delivery
- Open the barcode app and open the reception
- Scan the product once and validate

Issue:
The receipt is validated without issues nor warning, despite being incomplete.

This is due to a bad mix of two changes:
- #60801, which always sets the rental receipt as return of the delivery
- #48788, which removes the backorder check for returns in barcode

For regular returns made in barcode, it makes sense to avoid the backorder check, as from here we're processing a full picking return and we'd have the confirmation pop every time.

However, things are different for rental receipts, as despite them being set as returns of the delivery, they're proper receipts that need to handle the partial receipt.

To avoid the issue, rather than removing the backorder check whenever there's a return linked to the picking, now also checks that there isn't a rental order linked to the picking.

opw-5265874

Forward-Port-Of: odoo/enterprise#101387

Steps to reproduce:
-------------------------
1. Install Salary Configurator module.
2. Create a new user and assign Officer rights in Employees and Recruitment.
3. Login with that user.
4. Create a new application and move it to 'Contract proposal' stage.
5. Click on the 'Generate Offer' button.

Observation:
-------------------------
An Access Error occurs, denying Read access to the `final_yearly_costs` field.

Issue:
-------------------------
In earlier versions, users had an additional access right that allowed them to access contract fields. After the HR modules were refactored, only HR Administrators and Payroll Users retained access to those fields. As a result users with only Officer rights in HR encountered an access error when generating an offer.

Solution:
-------------------------
Use `sudo()` to bypass access restrictions for the `final_yearly_costs` field when generating the offer.

opw-5243280

Forward-Port-Of: odoo/enterprise#102250
Forward-Port-Of: odoo/enterprise#99478

In #92208 the CAF system was improved to find the next starting value in the right sequence if there are multiple in the system. If no CAFs are found, it will reset to the document types starting number.

This worked except in the case where there are multiple CAFs that are currently marked active in a document type. As it tries to access `caf.start_nb` it hits an ensure_one() which throws a traceback whenever you open most account.moves on the DB.

Steps to reproduce:
- Modify the CAF for Doc Type 33 (Electronic Invoices) to have a smaller range than 1 - 999,999 (1 - 5)
- Create Two new CAF files also for Doc Type 33 that start after this value (6 - 10 and 11 - 15 for example).
- Mark the original to be spent via cancelling it and try to open an invoice. It will find both of the new CAFs and try to get the start_nb of the recordset.

In discussion with the PO, when we have multiple CAFs, we should pick by the lowest start number as it will allow for any gaps that might exist be filled.

opw-5414350

Forward-Port-Of: odoo/enterprise#102385

**BUG:** 
Traceback when **suggesting** deleting a BOM step from the shopfoor. 

**STEPS TO REPRODUCE:** 
- Open a shopfloor MO (with PLM installed)
-- Add a suggestion step (MO > cog> Update instructions > Improvement Suggestion > Add a step). 
-- Add a second suggestion step after the first one.
-- Delete the second suggestion step  (MO > cog> Update instructions > Improvement Suggestion > Delete a step).
-- Add a third suggest suggestion step after the second one we just suggested deleting.
-- > Traceback 

**ORIGIN:** 
First, when adding the suggestions:
 - 2 Quality Check (QC) are created on the **new_bom_id** in `add_quality_check_from_tablet.save()` 
 - 2 Quality Point (QP) are also created in  `add_check_in_chain()`, (only in mrp_workorder_plm override) 
- The 2nd new QC is linked to previous QC in `_insert_in_chain`

Secondly, when deleting the 2nd added suggestion (_on the same MO, as suggestions are linked to the new bom_id and wont appear on other MOs until ECO is validated_):
- The QP of the second QC is deleted (but the QC itself is not deleted) here:

https://github.com/odoo/enterprise/blob/f91b0c8c41f40a71cbea3cd4f5ccc6873af3c004/mrp_workorder_plm/wizard/propose_change.py#L72-L74

Finally, when adding a new suggestion after the one we just suggested deleting, in `_add_check_in_chain`, a traceback happens by trying to access the QP point we deleted in the resequencing part of  `_add_check_in_chain` here:
https://github.com/odoo/enterprise/blob/eb716c18944ec50c9c8c74a2888ed5f3032a7b08/mrp_workorder_plm/models/mrp_workorder.py#L62-L63

**FIX:**
We accept that not all QCs must have QPs  `[0]` -> `[:1]` (see note on another approach idea) changing

```diff
- point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[0] 
+ point = check.point_id if check.point_id.operation_id == operation else points.filtered(lambda p: p._get_sync_values() == check.point_id._get_sync_values())[:1] 
```

**NOTES:**
-1 Another fix could have been to delete the QC at the same time as the QP but I did not find any `remove_from_chain` function to safely remove the QC from the chain of QC. Along those lines we could rethink the sequencing / resequencing of QC and QP as the logic seems to differ between both. 
-2 Added some comments to remove the field and the line setting the `is_deleted` field in master as it was not used anywhere in the code (the color highlighting in the ECO is done with `<list decoration-danger="change_type=='remove'" ...>`)

Upgrade PR: https://github.com/odoo/upgrade/pull/9076
ticket #5180122

Forward-Port-Of: odoo/enterprise#101366

When refunding an order that originally had a global discount, if you didn't refund the discount, the refund total amount would exceed the original order total. This would cause issues when trying to generate a global invoice for the mexican localization.

Steps to reproduce:
-------------------
* Activate the global discount option in any PoS
* Open PoS and make a sale with a global discount
* Refund the sale without including the discount
* Go to the backend
* Go to the order list and select the 2 orders you made
* Now try to create a global invoice
> Observation: The global invoice is in error because the negative lines
  cannot be distributed correctly.

Why the fix:
------------
To avoid this issue with the global invoice we simply prevent the user to generate a refund with a greater amount than the original order. We only apply this limit to the mexican localization because it's the only module that is affected by this issue. Other localizations can still refund without restrictions even if this work flow does not really make sense.

opw-4899501

Forward-Port-Of: odoo/enterprise#101752
Forward-Port-Of: odoo/enterprise#93101

In #92208 the CAF system was improved to find the next starting value in the right sequence if there are multiple in the system. If no CAFs are found, it will reset to the document types starting number.

This worked except in the case where there are multiple CAFs that are currently marked active in a document type. As it tries to access `caf.start_nb` it hits an ensure_one() which throws a traceback whenever you open most account.moves on the DB.

Steps to reproduce:
- Modify the CAF for Doc Type 33 (Electronic Invoices) to have a smaller range than 1 - 999,999 (1 - 5)
- Create Two new CAF files also for Doc Type 33 that start after this value (6 - 10 and 11 - 15 for example).
- Mark the original to be spent via cancelling it and try to open an invoice. It will find both of the new CAFs and try to get the start_nb of the recordset.

In discussion with the PO, when we have multiple CAFs, we should pick by the lowest start number as it will allow for any gaps that might exist be filled.

opw-5414350

Forward-Port-Of: odoo/enterprise#102385

Before this commit, whenever we called `/ai/generate_response` from the fron-end we were catching any potential exceptions and calling the `ai/post_error_message`. The `post_error_message` function called from that controller endpoint would take the exception message, and ask the AI to explain the error to the user without the use of technical terms.

The problem with this approach is two-fold.
Firstly, in the `post_error_message` method, we use the `generate_response` method in order for the AI to beauty-fy the error message. But, the `post_error_message` method is called when catching exceptions of the `generate_response` method. Thus, the exception is caught, a nice message is posted in the chat, but then a traceback is shown regardless.
Secondly, beautifying the error messages makes it more difficult for end users to understand what could be going wrong and making it also more difficult for our support to help them out.

In this commit, we removed the `post_error_message` flow. We move the try-except to the `_generate_response_for_channel` method and if the user is an internal user we let the exception bubble up. If not (for website users on livechat), a generic message will be posted on the chat.

task-5177169

## Issue:
When exporting the XML for a VAT return, the client nihil field was incorrectly set to YES
According to Belgian regulations, this is only allowed on the last report of the calendar year
https://finances.belgium.be/sites/default/files/downloads/165-625-directives-2019.pdf

## Cause:
Prior to 18.3, nihil was a checkbox option on export
Since 18.3, it is automatically selected based solely on a price formula, without checking the report’s date

This PR brings back the Client Nihil checkbox in 19.0
But didn't change the default value
Causing the issue to still be present
https://github.com/odoo/enterprise/pull/99496

## Steps to reproduce:
- Select the Belgian company
- Open the Tax Return and select the VAT Return
- Click Returns and enter an opening date in January
- Click Review for the first available report
- Ignore errors and return to previous page
- Click on Submit -> Download XML
- Before the fix, ClientListingNihil is set to YES

## Potential remaining issue:
The legal document specify that it should also be checked in case of "cessation d’activité"
So it may be interesting to consider adding the option back

opw-5184056

Forward-Port-Of: odoo/enterprise#98982

Before this commit:
migration script only creates a new tax group.

After this commit:
migration script will create all tax groups that are required for  new taxes if they do not already exist

Why:
During the migration if the tax group is not found then the value error is raised

There are 2 reason of why the tax group is not found :
1. User deletes it by themselves
2. In the upgrade script of account in version saas~16.2.1.2 the pre-migrate script where global scope of tax groups was converted to company-specific, [Ref](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L173) If the tax groups are not associated with any tax or any account_move_line then it is deleted.


User Traceback : 
`  File "/home/odoo/src/odoo/17.0/odoo/addons/base/models/ir_model.py", line 2203, in _xmlid_lookup
    raise ValueError('External ID not found in the system: %s' % xmlid)
ValueError: External ID not found in the system: account.1_l10n_id_tax_group_non_luxury_goods`


account_tax_group records in production : 
```
kdes_3444743=> select id,name from account_tax_group;
 id |                             name                              
----+---------------------------------------------------------------
  1 | {"en_US": "Taxes", "id_ID": "Pajak"}
  2 | {"en_US": "Luxury Good Taxes", "id_ID": "Pajak Barang Mewah"}
  3 | {"en_US": "Non-luxury Good Taxes", "id_ID": "Pajak Barang"}
  4 | {"en_US": "Zero-rated Taxes", "id_ID": "Pajak Nol"}
  5 | {"en_US": "Tax Exempted", "id_ID": "Bebas Pajak"}
(5 rows)
```

Query executed [here](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L152) : 
```
        WITH company AS (
            SELECT "company_id" AS id,
                   "tax_group_id" AS tg_id
              FROM "account_move_line"
             WHERE "company_id" IS NOT NULL
               AND "tax_group_id" IS NOT NULL
             UNION 
            SELECT "company_id" AS id,
                   "tax_group_id" AS tg_id
              FROM "account_tax"
             WHERE "company_id" IS NOT NULL
               AND "tax_group_id" IS NOT NULL
        )
        INSERT INTO account_tax_group ("country_id", "create_date", "create_uid", "name", "preceding_subtotal", "sequence", "write_date", "write_uid", company_id, _tmp_orig_id)
             SELECT "tg"."country_id", "tg"."create_date", "tg"."create_uid", "tg"."name", "tg"."preceding_subtotal", "tg"."sequence", "tg"."write_date", "tg"."write_uid", company.id, tg.id
               FROM account_tax_group tg,
                    company
              WHERE company.tg_id = tg.id
```


Above selection query on user's DB :
```
kdes_3444743=> SELECT "company_id" AS id,
                   "tax_group_id" AS tg_id
              FROM "account_move_line"
             WHERE "company_id" IS NOT NULL
               AND "tax_group_id" IS NOT NULL
             UNION 
            SELECT "company_id" AS id,
                   "tax_group_id" AS tg_id
              FROM "account_tax"
             WHERE "company_id" IS NOT NULL
               AND "tax_group_id" IS NOT NULL;
 id | tg_id 
----+-------
  1 |     1
  1 |     2
(2 rows)

```
As only 2 tax groups are associated with the account_move_line and account_tax
They are only being inserted to the able along with the company id prefix and company_id field set
, remaining enteries are deleted in [next query](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L173).

Same is the case with the records in [ir_model_data](https://github.com/odoo/upgrade/blob/b4f278aa9f32dc5edab814af0c2a0339cd7400a6/migrations/account/saas~16.2.1.2/pre-migrate.py#L174-L196). 

OPW : 5358546
UPG : 3444743

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

Forward-Port-Of: odoo/odoo#238981

To reproduce:
=============
- Create an accrual plan:
    - Carryover date: allocation
    - One level:
        - Accrues 2 days.
        - Accrual date: monthly on 1st of each month - Starts immediately on allocation start date - Carryover policy: all days carry over - Carried over days validity: 3 months.
- Create an allocation that uses the above accrual plan on 23/09/2025:
    - Starts on 01/07/2024

We should have 30 days in total with 24 expiring on 01/10/2025 but we only have 22 expiring on 01/10/2025.

Problem:
========
When `accrued_gain_time` of the accrual plan is 'start', in the `_process_accrual_plans` method, the property `expiring_days` is set when the first accrual still hasn't been added to the `number_of_days` (it is usually added at the [end of the loop](https://github.com/odoo/odoo/blob/18.0/addons/hr_holidays/models/hr_leave_allocation.py#L596)).

Solution:
=========
In the `_process_accrual_plans`, add the accrued days to the `number_of_days` before the `expiring_days` is set.

[opw-4963163](https://www.odoo.com/odoo/all-tasks/4963163)

Currently, an error occurs when a user sends a customer statement.

**Steps to Reproduce ([Video](https://drive.google.com/file/d/1soOylzCVnNCNsWUBizeBQ9vfFlI5pzSP/view)):**
 - Install the `account_reports` module.
 - Go to `Invoicing` > `Customers` > `Customers`.
 - Switch to `List view`, select `a customer`, then click on `Actions` > `Open Customer Statements`.
 - Click `Send`, remove the `Email Template`, add a `subject`, and then click `Print & Send`.

**Error:**
`ValueError: Expected singleton: mail.template()`

After [this commit], which checks whether the template has an email_from, when a user sends the customer statement and removes the email template, it still tries to access the template to fetch email_from for a particular customer [1]. If no email template is used, this results in an error [2] when going to extract the email_from.

This commit ensures that email_from is taken from the email template if one is used; otherwise, it uses the current user's email address [3], which matches the default behavior.

[this commit]: https://github.com/odoo/enterprise/commit/22c46e4f63e7b2dc0eee16fc807656cd4de21fb7

[1]- https://github.com/odoo/enterprise/blob/dc4d5633407ccc728d30de5ce2072a80c16b2766/account_reports/wizard/account_report_send.py#L246

[2]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_render_mixin.py#L691-L693

[3]: https://github.com/odoo/odoo/blob/0dabb221225fba96c0e55779afadd9f12b369777/addons/mail/models/mail_thread.py#L2891-L2892

sentry-7106576491

## Context
In the barcode app (`stock_barcode`), users can update inventory counts
by scanning a product's barcode or by manually entering the barcode.

## Issue
When the barcode is entered manually, the lot/serial number is created with
the *Company* field set to the current company. This causes issues when
working with intercompany flows, because lots with a company assigned
cannot be used by other companies. This behavior is also inconsistent
with the other ways of updating a company's inventory. In fact, the following
flows create serial/lot numbers with no company assigned:
- Inventory / Products / Products / *Forecasted Report* or *On Hand*
- Inventory / Operations / Adjustments / Physical Inventory
- Barcode / Inventory Count / Add product (add the serial number from
the *Inventory Count* screen, **not** by clicking on the cogwheel in
the top-right corner)

## Cause
The line assigning a `company_id` was added by https://github.com/odoo/enterprise/commit/c0151bce3c60c69e7cadeb719a81c4a702b71c34.
At the time, that behavior was consistent with the backend behavior,
as the `company_id` of a lot/serial number would always be set to `self.env.company`.
In fact, the feature allowing a lot/serial to be shared among multiple
companies was introduced later, in saas-17.2 (https://github.com/odoo/odoo/commit/99b39b72c7e65e85af6f06dcb6b02867623f3f69).
This last commit adds a compute method for the `stock.lot.company_id` field:

https://github.com/odoo/odoo/blob/6026866900fd0ac1bf6495ae249cd08f56c85342/addons/stock/models/stock_lot.py#L130-L136

Since then, lot/serial numbers shouldn't be created with a `company_id`,
as this restrict other companies to use those numbers. Users can always
add a company to a lot/serial number later if necessary.

## Solution
The line assigning a `company_id` to the `stock.lot` can be removed,
as it does not reflect the current behavior (saas-17.2+).
Nowadays, a `company_id` should be set **only** if the user wants a
lot/serial number to be used by a specific company; it should not be
the default behavior.

## Steps to reproduce
1. Install *Barcode* (`stock_barcode`).
2. In Inventory / Configuration / Settings, enable *Lots & Serial Numbers*.
3. In Settings / Users & Companies / Companies, create a second company.
Use either company for the following steps.
4. Create a product tracked *By Unique Serial Number*.
5. Open the Barcode app, then click *Inventory Count*.
6. Scan your product (or add it manually, but **do not** set the *Serial/Lot Number*).
7. Scan "SN001" (or add it manually through the cogwheel menu), then click *Apply*.
8. Go to Inventory / Products / Lots / Serial Numbers.
9. The serial number created from the Barcode app is assigned to the current company.

opw-5264216

Summary:
Refactor `preserveSelection()` to use a stack-based approach (`preservedCursors` array) instead of a single cursor reference. This allows nested calls to `preserveSelection()` to operate independently while keeping cursor updates synchronized across active contexts.

Problem:
Using a single stored cursor caused issues in nested calls to `preserveSelection()`:

1. **State overwrite:** Inner calls could overwrite or clear the outer cursor.
2. **Stale references:** If an inner function replaced a DOM node, the outer cursor could still point to a removed node and fail on restore.

Solution:
Use an array of cursor subscribers

- **Shared updates:** When calling `remapNode` on a cursor, it iterates over all active subscribers in the stack. This ensures node replacements performed in inner contexts also update outer cursor references.
- **Scoped cleanup:** `restore()` now removes only the corresponding cursor instance from the stack, ensuring proper lifecycle management.

Example:
The key improvement is that outer scopes receive updates performed by inner scopes.

```javascript
// Function A (outer)
function wrapperFunction() {
    const cursor = this.preserveSelection();
    replaceTextWithSpan();
    cursor.restore();
}

// Function B (inner)
function replaceTextWithSpan() {
    const innerCursor = this.preserveSelection();
    const oldNode = document.querySelector('text');
    const newNode = document.createElement('span');
    oldNode.replaceWith(newNode);
    innerCursor.remapNode(oldNode, newNode);
    innerCursor.restore();
}
```
opw-5386862

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

Currently, an error occurs when clicking the `Send to eTIMS` button on vendor bills.

Steps to Reproduce:
 - Install `l10n_ke_edi_oscu` module without demo data.
 - Create a New company with `Kenya` as the Country and switch to it.
 - Go to Vendors > Bills, create a new bill, and add an invoice line without tax.
 - Confirm it, then click `Send to eTIMS`.

Traceback:
```py
 File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 551, in action_l10n_ke_oscu_confirm_vendor_bill
    content = move._l10n_ke_oscu_json_from_move()
  File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 199, in _l10n_ke_oscu_json_from_move
    line_items = self._l10n_ke_oscu_get_json_from_lines(tax_details)
  File "/home/odoo/src/enterprise/19.0/l10n_ke_edi_oscu/models/account_move.py", line 250, in _l10n_ke_oscu_get_json_from_lines
    tax, line_tax_details = next(
StopIteration: null
```

This error occurs because when a new company is created, the `eTIMS Server Mode` in Settings is empty. As a result, `l10n_ke_oscu_is_active` field becomes `False`, and at [1] the `l10n_ke_validation_message` field will also be `False`, causing the flow to be skipped. Therefore, no error is raised on the frontend side. The field `l10n_ke_oscu_is_active` is set to `True` only when `eTIMS Server Mode` is set to `Demo`.

Here we raise a warning when the `eTIMS` configuration is not set up correctly.

[1]: https://github.com/odoo/enterprise/blob/7fb7b3168039f00b6d815202bc19ac35aa1d9b5e/l10n_ke_edi_oscu/models/account_move.py#L91-L93

sentry-7083978544

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

The PACs Quadrum and SwSapien both require the exchange rate to have 6 decimal places. This can cause some valid invoices to be rejected for large enough payment values. Pull request [83499](https://github.com/odoo/enterprise/pull/83499) added rounding precision for these PACs.

Now, the remaining PAC (Solution Factible) appears to the same requirement. This commit ensures that the previous bug fix is applied to all PACs.

[opw-5165200](https://www.odoo.com/odoo/project.task/5165200)

## Steps to reproduce:

[Setup](https://drive.google.com/file/d/1BUkNG-Ezk-I47yvbNolOmlj0ne1iqDto/view?usp=sharing)
1. Navigate to Apps and install l10n_mx_edi.
2. Switch to any of the Mexican companies that appear.
3. Navigate to Accounting > Configuration > Currencies.
4. Click into the USD currency.
5. Change the current rate to be 20.101796407186 MXN per USD. (inverse_company_rate field).
6. Navigate to Accounting > Configuration > Settings, and set the PAC to Solution Factible.

[Workflow](https://drive.google.com/file/d/11TFZ78QGDYdnD9R3CoJDAuFI-1_0dNyG/view?usp=sharing)
1. Navigate to Accounting > Customers > Invoices.
2. Select New to create a new invoice.
3. Add a mexican customer (such as XENON INDUSTRIAL ARTICLES).
4. Add the 45 day Payment terms. This should change the payment policy to PPD.
5. Change the currency to USD.
6. Add the product FURN_8220 (or any with the unspsc_code_id set).
7. Set the unit price of the product to 58968.29.
8. Confirm the invoice.
9. Select Send & Print, then ensure that the CFDI option is selected before clicking Send & Print again.
10. Select Register Payment, then Confirm Payment.
11. Select the Update Payments smart button.
12. Navigate to the CFDI tab; there will be a "Payment Send in Error" line.

- The method _compute_l10n_in_transaction_type currently fetches all columns https://github.com/odoo/enterprise/blob/1a67dadd2b1b3f94125f4088d1c36a77057443b4/l10n_in_reports/models/account_move.py#L20-L29
  from the account_move table, whereas only a subset of fields is actually
  required. Since account_move is typically a large table in customer databases,
  this approach can lead to high memory consumption and potentially result in
  MemoryError.

- I used the fetch method to ensure that non-stored fields are ignored and that only the specified fields are retrieved from the database, fetching only what is strictly necessary. 
https://github.com/odoo/odoo/blob/574a67c73633755438d0aff7ff85f380fec9ef0d/odoo/models.py#L3826-L3830

- Moreover, this fix is implemented in version 18.0. As a result, it is not
 applied in version 17.0, which explains why the MemoryError occurs in that
 version.
https://github.com/odoo/enterprise/pull/76502/commits/be655971e7059b79bc3200b83d5e76b3c0b12059

```python3
Traceback (most recent call last):
  File "/home/odoo/src/odoo/17.0/odoo/service/server.py", line 1374, in preload_registries
    registry = Registry.new(dbname, update_module=update_module)
  File "<decorator-gen-16>", line 2, in new
  File "/home/odoo/src/odoo/17.0/odoo/tools/func.py", line 87, in locked
    return func(inst, *args, **kwargs)
  File "/home/odoo/src/odoo/17.0/odoo/modules/registry.py", line 110, in new
    odoo.modules.load_modules(registry, force_demo, status, update_module)
  File "/home/odoo/src/odoo/17.0/odoo/modules/loading.py", line 519, in load_modules
    migrations.migrate_module(package, 'end')
  File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 221, in migrate_module
    exec_script(self.cr, installed_version, pyfile, pkg.name, stage, stageformat[stage] % version)
  File "/home/odoo/src/odoo/17.0/odoo/modules/migration.py", line 239, in exec_script
    migrate(cr, installed_version)
  File "/tmp/tmp259m4qqf/migrations/l10n_mx/saas~16.2.2.0/end-migrate.py", line 9, in migrate
    CoA.try_loading("mx", company=company, install_demo=False)
  File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 155, in try_loading
    return self._load(template_code, company, install_demo)
  File "/home/odoo/src/odoo/17.0/addons/point_of_sale/models/chart_template.py", line 22, in _load
    result = super()._load(template_code, company, install_demo)
  File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 215, in _load
    self._load_translations(companies=company)
  File "/home/odoo/src/odoo/17.0/addons/account/models/chart_template.py", line 1351, in _load_translations
    translation_importer.save(overwrite=False)
  File "/home/odoo/src/odoo/17.0/odoo/tools/translate.py", line 1460, in save
    env.flush_all()
  File "/home/odoo/src/odoo/17.0/odoo/api.py", line 737, in flush_all
    self._recompute_all()
  File "/home/odoo/src/odoo/17.0/odoo/api.py", line 733, in _recompute_all
    self[field.model_name]._recompute_field(field)
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6977, in _recompute_field
    field.recompute(records)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1379, in recompute
    apply_except_missing(self.compute_value, recs)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1352, in apply_except_missing
    func(records)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 431, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value
    fields.determine(field.compute, self)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 102, in determine
    return needle(*args)
  File "/home/odoo/src/enterprise/17.0/l10n_in_reports/models/account_move.py", line 23, in _compute_l10n_in_transaction_type
    if move.country_code == "IN":
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1219, in __get__
    self.compute_value(recs)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1401, in compute_value
    records._compute_field_value(self)
  File "/home/odoo/src/odoo/17.0/addons/mail/models/mail_thread.py", line 431, in _compute_field_value
    return super()._compute_field_value(field)
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 4923, in _compute_field_value
    fields.determine(field.compute, self)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 105, in determine
    return needle(records, *args)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in _compute_related
    values = [first(value[name]) for value in values]
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 695, in <listcomp>
    values = [first(value[name]) for value in values]
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 6695, in __getitem__
    return self._fields[key].__get__(self, self.env.registry[self._name])
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 2933, in __get__
    return super().__get__(records, owner)
  File "/home/odoo/src/odoo/17.0/odoo/fields.py", line 1182, in __get__
    recs._fetch_field(self)
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3824, in _fetch_field
    self.fetch(fnames)
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3874, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
  File "/home/odoo/src/odoo/17.0/odoo/models.py", line 3984, in _fetch_query
    self.env.cache.insert_missing(fetched, field, values)
  File "/home/odoo/src/odoo/17.0/odoo/api.py", line 1135, in insert_missing
    field_cache.setdefault(id_, val)
MemoryError

select COUNT(*) from account_move
+--------+
| count  |
|--------|
| 511738 |
+--------+
SELECT 1
Time: 0.177s
```

opw-5414648
upg-3570209