**Steps to reproduce:**
* Install the **Accounting** and **l10n_br_edi** modules.
* Create and post a Brazilian customer invoice using an **Avatax fiscal position**
* [Guide to setup EDI for l10n_br](https://docs.google.com/document/d/1CSUKpnyhty5WBqUDBE-7dGvu0qxaC5vQ0loz0fYNg04/edit?tab=t.0)
* Confirm the invoice and **send it to e-invoice (Brazil)**.
* Confirm the **Brazil E-Invoice Status** shows **'Accepted'**.
* Click **Request Cancellation**, enter a cancellation reason, and submit the request.

**Observed behavior:**
* The invoice moves to **Cancelled** state.
* The cancellation XML is generated and attached in the chatter.
* SEFAZ returns a successful cancellation response.
* However, the **BR EDI Status** becomes **empty**, instead of reflecting **'Cancelled'**.

**Cause:**
* In the wizard `l10n_br_edi.invoice.update`, both `_finalize_update()` and `_submit_services()` assign `l10n_br_last_edi_status = 'cancelled'` **before** calling `button_cancel()`.
* `button_cancel()` internally triggers `button_draft()` for posted invoices.
* The Brazil EDI override of `button_draft()` resets `l10n_br_last_edi_status = False`.
* This clears the status that was just set, leaving the field blank.

**Fix:**
* move `l10n_br_last_edi_status = "cancelled"` to `button_cancel()` method.

opw-5378542

Forward-Port-Of: odoo/enterprise#101438

This commit fixes three issues occurring when editing nested s_card snippets.

**Problem 1 - Incorrect cover image detection**

Issue: An `s_card` without a cover image displayed the cover-image option if it contained a child `s_card` with a cover image.
Cause: `CardImageOption` and `CardImageAlignmentOption` relied on `querySelector`, which could detect images inside child snippets.
Fix: The cover image detection now checks that the closest `s_card` element corresponds to the snippet being edited.

**Problem 2 - Ratio settings applied to all child cards**

Issue: Changing the cover image ratio on an `s_card` applied the setting to all nested `s_card` elements.
Cause: The `BuilderSelect` in `CardImageOption` targeted `.o_card_img_wrapper`, causing `classAction` to apply to all descendants.
Fix: The selector is now `:scope > .o_card_img_wrapper`, ensuring the option acts only on the current snippet.

**Problem 3 - Parent image positioning leaking to children**

Issue: Adjusting the cover image position on a parent `s_card` affected the rendering of all child card images.
Cause: CSS rules for `.o_card_img_horizontal` applied to all descendant elements mathcing `.o_card_img_wrapper`.
Fix: The rules now apply only to direct children of `.o_card_img_horizontal`. The same correction was applied to `.o_card_img_ratio_custom`.

task-5349540

Steps to Reproduce
===================
1. Upload more than 40+ files in a folder. (One page displays upto 40 docs)
2. Use the checkbox to select all files on the page (this selects only 40 files)
3. Click the 'Select All' button in the control panel to select all 40+ files.
4. Now, try duplicating or moving them to the trash.
=> Only the first 40 selected files (on the single page) are considered for
   action, not all the selected files.

Technical
==========
For documents control panel action we have custom handling for selecting records
and executing action. We use `model.root.selection` which only consider records
in current page, case of select all records from other pages is missed here.

After this PR
==================
- All selected records are considered for the actions
- Added custom `getResIds` method to get filtered `resIds` as per domain.

Note: `getResIds` in DynamicList doesn't have custom domain feature so create
our own as per use case

Task-4700841

Forward-Port-Of: odoo/enterprise#100791
Forward-Port-Of: odoo/enterprise#87634

Currently, an incorrect shipping address is assigned to invoices generated from 
POS orders when the customer has multiple delivery addresses.

**Steps to reproduce:**

- Install the `point_of_sale` and `contacts` modules.
- Enable `Customer Addresses` from the settings.
- Create a contact with `two` delivery addresses.
- Open POS and create an order using the `second delivery address` as the customer.
- Confirm the order with the `invoice`.
- Observe the `shipping address` on the invoice.

**Observation:**
The invoice incorrectly shows the first delivery address instead of the 
second delivery address.

**Cause:**
At invoice creation in POS, only `partner_id` is set and `partner_shipping_id` 
is missing at [1]. As a result, the invoice defaults to the customer's first 
delivery address instead of the delivery address selected in POS.

**Fix:**
This commit adds `partner_shipping_id` to the invoice values to ensure the 
POS invoice uses the exact delivery address selected during order creation. 
same as the `sale` module behaviour.

[1]:
https://github.com/odoo/odoo/blob/1d1cd8648ed1c3f13febbde8d48e28928e18583f/addons/point_of_sale/models/pos_order.py#L667-L684

opw-5350137

Forward-Port-Of: odoo/odoo#239663
Forward-Port-Of: odoo/odoo#238055

Currently, when a user adds a combo to an order line, and remove the name of combo and click on Edit Configuration (pencil icon) error is encountered.

Steps to replicate:
- Install `sale_management` with demo and create a new SO.
- Add a combo product and remove the combo name and click Edit Configuration (pencil icon).

Error:
`TypeError: SaleProductConfiguratorController.sale_combo_configurator_get_data() missing 1 required positional argument: 'product_template_id'`

Cause:
- When a user clicks on Edit configuration, the client-side JavaScript makes an RPC call to the server, targeting the `sale_combo_configurator_get_data()` which expects `product_template_id` at [1] and since it is removed from order line the error is encountered.

Solution:
- Changed the content of method `isCombo()` to use the product_template_id to make sure the Edit Configuration is only visible when product template is present.

Similar PR for reference: https://github.com/odoo/odoo/pull/217464

[1]: https://github.com/odoo/odoo/blob/fa4307b9758800f26c9ee87cf3698fd60bfd1ab5/addons/sale/controllers/combo_configurator.py#L12-L14

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

Forward-Port-Of: odoo/odoo#238536

When registering to an event, customers are asked questions before reaching the payment page. By default, a *Name* question is included, but it can be removed by the organizer of the event. If the *Name* question is removed, but a name is asked in the delivery form, Odoo will try to compare the (missing) name from the event's questions with the (required) name from the delivery form.

https://github.com/odoo/odoo/blob/828a9504c7d43aa35ed91141268d04e0a55782c3/addons/portal/controllers/portal.py#L551

The issue is that if there's no *Name* question among the event's questions, a `res.partner` with its `name` field set to `False` is created. When attempting to call `.strip()` on its name, an `AttributeError` is raised (*'bool' object has no attribut 'strip'*).

This fix prevents the error by considering the name field as an empty string in case no name is provided.

### Steps to reproduce:
1. Install *Online Event Ticketing* (`website_event_sale`)
2. In Settings > Website, set *Sign in/up at checkout* to *Disabled (buy as guest)*
3. In Events, create a new Event
    - Give it any name
    - Add a product line for the Event Registration with a price greater than 0
    - In the *Questions* tab, remove the *Name* question
    - Click the *Go to website* smart button and publish the event
4. On the website, in incognito mode:
    - Click *Events*
    - Click the new event we created in Step 3
    - Click *Register*, (set the quantity to one ticket,) click *register*
    - Answer the questions (there should **not** be a *Name* question) and click *Confirm Registration*
    - Fill out the required fields of the delivery form (there **should** be a *Name* field)
    - Open the console, then click *Confirm* in the delivery form: An error appears, and the Payment page does not appear

opw-5259781

Forward-Port-Of: odoo/odoo#237154

This fix addresses an issue where selling multiple gift cards in a single POS order results in only one gift card being created with the total amount, instead of multiple gift cards with the correct individual amounts.

Step to reproduce:
- Create a new gift card and enable the option to sell this card in the POS
- Open the POS and try to sell multiple gift cards in the same order
- Validate the order
- Check the generated gift cards, only one gift card will be created with the total amount instead of multiple gift cards with the correct individual amounts

This issue occurs because the field `reward_point_split` is missing from the kanban view of loyalty rules. So, when creating a new gift card, this field value, which should be True for gift cards, is not returned by the onchange method, and since nothing triggers a new computation unless the program type is changed, the field remains False.

This fix simply restores this field in the kanban view (like before https://github.com/odoo/odoo/pull/172561) so that its value is correctly taken into account when creating a new gift card.

opw-5103652

Forward-Port-Of: odoo/odoo#238993

Steps to reproduce:
1. Install `loyalty` and `sale_management`
2. Activate another language with another date format, eg. English (AU)
3. Set that language on a contact
4. Sales > Product > Discount & loyalty
5. Create a record with program type coupons
6. Generate a coupon for that AU contact with an expiration date

Issue:
The coupon email received by the customer shows the expiration date using the yyyy-MM-dd format, and the attachment shows the same technical format instead of the customer’s localized date format.

Cause:
We are not using a formatted date according to the customer

before: Customer with English AU language
<img width="601" height="563" alt="image" src="https://github.com/user-attachments/assets/faea2840-aca6-4850-bfc9-b0d24da65a3b" />

<img width="1510" height="883" alt="image" src="https://github.com/user-attachments/assets/b0ebc0cc-6243-450d-ad12-cecda4858e26" />


After:
<img width="603" height="543" alt="image" src="https://github.com/user-attachments/assets/5be2332b-3237-4ce5-8122-0766cd274650" />

<img width="1482" height="886" alt="image" src="https://github.com/user-attachments/assets/99d31b4c-33fa-4f92-9970-56720181911e" />


opw-5247621

Forward-Port-Of: odoo/odoo#237880

Currently, an incorrect shipping address is assigned to invoices generated from 
POS orders when the customer has multiple delivery addresses.

**Steps to reproduce:**

- Install the `point_of_sale` and `contacts` modules.
- Enable `Customer Addresses` from the settings.
- Create a contact with `two` delivery addresses.
- Open POS and create an order using the `second delivery address` as the customer.
- Confirm the order with the `invoice`.
- Observe the `shipping address` on the invoice.

**Observation:**
The invoice incorrectly shows the first delivery address instead of the 
second delivery address.

**Cause:**
At invoice creation in POS, only `partner_id` is set and `partner_shipping_id` 
is missing at [1]. As a result, the invoice defaults to the customer's first 
delivery address instead of the delivery address selected in POS.

**Fix:**
This commit adds `partner_shipping_id` to the invoice values to ensure the 
POS invoice uses the exact delivery address selected during order creation. 
same as the `sale` module behaviour.

[1]:
https://github.com/odoo/odoo/blob/1d1cd8648ed1c3f13febbde8d48e28928e18583f/addons/point_of_sale/models/pos_order.py#L667-L684

opw-5350137

Forward-Port-Of: odoo/odoo#239663
Forward-Port-Of: odoo/odoo#238055

**Steps to reproduce:**
* Install the **Accounting** and **l10n_br_edi** modules.
* Create and post a Brazilian customer invoice using an **Avatax fiscal position**
* [Guide to setup EDI for l10n_br](https://docs.google.com/document/d/1CSUKpnyhty5WBqUDBE-7dGvu0qxaC5vQ0loz0fYNg04/edit?tab=t.0)
* Confirm the invoice and **send it to e-invoice (Brazil)**.
* Confirm the **Brazil E-Invoice Status** shows **'Accepted'**.
* Click **Request Cancellation**, enter a cancellation reason, and submit the request.

**Observed behavior:**
* The invoice moves to **Cancelled** state.
* The cancellation XML is generated and attached in the chatter.
* SEFAZ returns a successful cancellation response.
* However, the **BR EDI Status** becomes **empty**, instead of reflecting **'Cancelled'**.

**Cause:**
* In the wizard `l10n_br_edi.invoice.update`, both `_finalize_update()` and `_submit_services()` assign `l10n_br_last_edi_status = 'cancelled'` **before** calling `button_cancel()`.
* `button_cancel()` internally triggers `button_draft()` for posted invoices.
* The Brazil EDI override of `button_draft()` resets `l10n_br_last_edi_status = False`.
* This clears the status that was just set, leaving the field blank.

**Fix:**
* move `l10n_br_last_edi_status = "cancelled"` to `button_cancel()` method.

opw-5378542

Forward-Port-Of: odoo/enterprise#101438

Currently, an error occurs when a user includes an XML encoding declaration in the studio XML editor.

**Steps to produce:**

- Install the `web_studio` module and enable `developer mode`
- Open `Apps` > `studio` > `view` > `</> xml`
- Declare encoding as: `<?xml version='1.0' encoding='utf-8'?>` and click `save`

**Error:**
`ValueError: Unicode strings with encoding declaration are not supported. 
Please use bytes input or XML fragments without declaration.`

**Root cause:**
At [1], an error is raised when the XML declaration contains an `encoding`
attribute, as encoding declarations are invalid in Unicode strings.

**Fix:**
This commit ensures that a `UserError` is raised, improving the error message clarity.

A similar fix was applied in https://github.com/odoo/odoo/pull/205324.

[1]:
https://github.com/odoo/odoo/blob/8a22b6ca09e1da3ccba3540bc4851a5174e035cc/odoo/tools/translate.py#L316

sentry-6981234548

Forward-Port-Of: odoo/odoo#239630
Forward-Port-Of: odoo/odoo#233571

Currently, when a user adds a combo to an order line, and remove the name of combo and click on Edit Configuration (pencil icon) error is encountered.

Steps to replicate:
- Install `sale_management` with demo and create a new SO.
- Add a combo product and remove the combo name and click Edit Configuration (pencil icon).

Error:
`TypeError: SaleProductConfiguratorController.sale_combo_configurator_get_data() missing 1 required positional argument: 'product_template_id'`

Cause:
- When a user clicks on Edit configuration, the client-side JavaScript makes an RPC call to the server, targeting the `sale_combo_configurator_get_data()` which expects `product_template_id` at [1] and since it is removed from order line the error is encountered.

Solution:
- Changed the content of method `isCombo()` to use the product_template_id to make sure the Edit Configuration is only visible when product template is present.

Similar PR for reference: https://github.com/odoo/odoo/pull/217464

[1]: https://github.com/odoo/odoo/blob/fa4307b9758800f26c9ee87cf3698fd60bfd1ab5/addons/sale/controllers/combo_configurator.py#L12-L14

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

Forward-Port-Of: odoo/odoo#238536

When registering to an event, customers are asked questions before reaching the payment page. By default, a *Name* question is included, but it can be removed by the organizer of the event. If the *Name* question is removed, but a name is asked in the delivery form, Odoo will try to compare the (missing) name from the event's questions with the (required) name from the delivery form.

https://github.com/odoo/odoo/blob/828a9504c7d43aa35ed91141268d04e0a55782c3/addons/portal/controllers/portal.py#L551

The issue is that if there's no *Name* question among the event's questions, a `res.partner` with its `name` field set to `False` is created. When attempting to call `.strip()` on its name, an `AttributeError` is raised (*'bool' object has no attribut 'strip'*).

This fix prevents the error by considering the name field as an empty string in case no name is provided.

### Steps to reproduce:
1. Install *Online Event Ticketing* (`website_event_sale`)
2. In Settings > Website, set *Sign in/up at checkout* to *Disabled (buy as guest)*
3. In Events, create a new Event
    - Give it any name
    - Add a product line for the Event Registration with a price greater than 0
    - In the *Questions* tab, remove the *Name* question
    - Click the *Go to website* smart button and publish the event
4. On the website, in incognito mode:
    - Click *Events*
    - Click the new event we created in Step 3
    - Click *Register*, (set the quantity to one ticket,) click *register*
    - Answer the questions (there should **not** be a *Name* question) and click *Confirm Registration*
    - Fill out the required fields of the delivery form (there **should** be a *Name* field)
    - Open the console, then click *Confirm* in the delivery form: An error appears, and the Payment page does not appear

opw-5259781

Forward-Port-Of: odoo/odoo#237154

### Issue:
In multicompany, when we generate the Partena export file of the 'not active' company, the partena code of the active company is inputted in the file.

### Steps to reproduce:
- Install 'l10n_be_hr_payroll_partena' and switch to a Belgian company
- Make sure the company has a "Partena Affiliation Number"
- Create an employee for this company, with a "Partena code"
- Create a contract for this employee, set it a running
- Create a new Belgian company with a different "Partena Affiliation Number"
- Activate both Belgian companies, but set the second one as active
- Payroll > Reporting > Export work entries to Partena
- Create a new one, populate it with the employee just created
- Click "Generate Export File"

### Cause:
When getting the data for the CSV file, we use `self.env.company` which is the active company. So when this company is not the one of the export record, we input the wrong code values.

### Solution:
Use `self.company_id` instead of `self.env.company_id`.

Also adds the test class with basic tests.

opw-5345786

Forward-Port-Of: odoo/enterprise#101110

This fix addresses an issue where selling multiple gift cards in a single POS order results in only one gift card being created with the total amount, instead of multiple gift cards with the correct individual amounts.

Step to reproduce:
- Create a new gift card and enable the option to sell this card in the POS
- Open the POS and try to sell multiple gift cards in the same order
- Validate the order
- Check the generated gift cards, only one gift card will be created with the total amount instead of multiple gift cards with the correct individual amounts

This issue occurs because the field `reward_point_split` is missing from the kanban view of loyalty rules. So, when creating a new gift card, this field value, which should be True for gift cards, is not returned by the onchange method, and since nothing triggers a new computation unless the program type is changed, the field remains False.

This fix simply restores this field in the kanban view (like before https://github.com/odoo/odoo/pull/172561) so that its value is correctly taken into account when creating a new gift card.

opw-5103652

Forward-Port-Of: odoo/odoo#238993

Steps to reproduce:
1. Install `loyalty` and `sale_management`
2. Activate another language with another date format, eg. English (AU)
3. Set that language on a contact
4. Sales > Product > Discount & loyalty
5. Create a record with program type coupons
6. Generate a coupon for that AU contact with an expiration date

Issue:
The coupon email received by the customer shows the expiration date using the yyyy-MM-dd format, and the attachment shows the same technical format instead of the customer’s localized date format.

Cause:
We are not using a formatted date according to the customer

before: Customer with English AU language
<img width="601" height="563" alt="image" src="https://github.com/user-attachments/assets/faea2840-aca6-4850-bfc9-b0d24da65a3b" />

<img width="1510" height="883" alt="image" src="https://github.com/user-attachments/assets/b0ebc0cc-6243-450d-ad12-cecda4858e26" />


After:
<img width="603" height="543" alt="image" src="https://github.com/user-attachments/assets/5be2332b-3237-4ce5-8122-0766cd274650" />

<img width="1482" height="886" alt="image" src="https://github.com/user-attachments/assets/99d31b4c-33fa-4f92-9970-56720181911e" />


opw-5247621

Forward-Port-Of: odoo/odoo#237880

Currently a user that connected to a pos user cannot go backend if he was not the person who opened the session the first time.

Steps to reproduce:
-------------------
* Modify settings of the shop to use employee feature
* Make sure admin and demo can access the shop, set them advenced employee for example.
* Logged as Mitchell Admin, open the pos (It should have been closed before)
* Use Mitchel admin employee
* Complete cash control
* Go backend
* Log out
* Log back in with Marc Demo
* Enter the shop (it was already "opened" by Admin)
* Use Marc demo employee
* Now try to see the backend button
> Observation: Backend button is not available

Why the fix:
------------
Quoting this commit: https://github.com/odoo/odoo/commit/61df2871e1aac0144d26022a2a49c75ea9ecad4a
> Now, the only employees that can go back to the backend are those binded to the user connected.

However, `this.pos.session.user_id` only reflects the user who opened the pos the first time, in our case Mitchell Admin. It does not represent the connected user.

opw-5276950

Forward-Port-Of: odoo/odoo#239627
Forward-Port-Of: odoo/odoo#238636

**Steps to reproduce:**
* Install the **Accounting** and **l10n_br_edi** modules.
* Create and post a Brazilian customer invoice using an **Avatax fiscal position**
* [Guide to setup EDI for l10n_br](https://docs.google.com/document/d/1CSUKpnyhty5WBqUDBE-7dGvu0qxaC5vQ0loz0fYNg04/edit?tab=t.0)
* Confirm the invoice and **send it to e-invoice (Brazil)**.
* Confirm the **Brazil E-Invoice Status** shows **'Accepted'**.
* Click **Request Cancellation**, enter a cancellation reason, and submit the request.

**Observed behavior:**
* The invoice moves to **Cancelled** state.
* The cancellation XML is generated and attached in the chatter.
* SEFAZ returns a successful cancellation response.
* However, the **BR EDI Status** becomes **empty**, instead of reflecting **'Cancelled'**.

**Cause:**
* In the wizard `l10n_br_edi.invoice.update`, both `_finalize_update()` and `_submit_services()` assign `l10n_br_last_edi_status = 'cancelled'` **before** calling `button_cancel()`.
* `button_cancel()` internally triggers `button_draft()` for posted invoices.
* The Brazil EDI override of `button_draft()` resets `l10n_br_last_edi_status = False`.
* This clears the status that was just set, leaving the field blank.

**Fix:**
* move `l10n_br_last_edi_status = "cancelled"` to `button_cancel()` method.

opw-5378542

Forward-Port-Of: odoo/enterprise#101438

### Issue:
In multicompany, when we generate the Partena export file of the 'not active' company, the partena code of the active company is inputted in the file.

### Steps to reproduce:
- Install 'l10n_be_hr_payroll_partena' and switch to a Belgian company
- Make sure the company has a "Partena Affiliation Number"
- Create an employee for this company, with a "Partena code"
- Create a contract for this employee, set it a running
- Create a new Belgian company with a different "Partena Affiliation Number"
- Activate both Belgian companies, but set the second one as active
- Payroll > Reporting > Export work entries to Partena
- Create a new one, populate it with the employee just created
- Click "Generate Export File"

### Cause:
When getting the data for the CSV file, we use `self.env.company` which is the active company. So when this company is not the one of the export record, we input the wrong code values.

### Solution:
Use `self.company_id` instead of `self.env.company_id`.

Also adds the test class with basic tests.

opw-5345786

Forward-Port-Of: odoo/enterprise#101110

This pull request introduces a new Odoo module, which adds support for compliant electronic delivery guides (e-Remitos) for Uruguay, integrating with the EDI system and enhancing stock picking operations. The main changes include configuration for managing and generating e-Remitos according to Uruguayan fiscal requirements.

**Steps to create an e-Remito**

1. Install l10n_uy_edi_stock
2. Create a new delivery order.
3. Select a value for the field "Type of Operation". This will indicate that we are creating the electronic document, and also add a tab named "UY EDI" with some configurations for the e-Remito.
<img width="1231" height="585" alt="image" src="https://github.com/user-attachments/assets/c4c0baa8-8f9b-4453-b0c0-ce1b1503c536" />

<img width="1211" height="565" alt="image" src="https://github.com/user-attachments/assets/c827f787-27ed-4d55-a660-42a6b617e7df" />

The field "Addenda and disclosures" works as in invoices, the user will be able to select the addenda to add to the e-Remito report. 
The field "EDI Reference" is used to indicate that the e-Remito is a correction of another, so it will suggest previous e-Remitos made for the same partner, and it will add "Correction of e-Rem XXX" on the addenda.

4. Validate the delivery order and click on "Create Delivery Guide" button. This will send the document to DGI for validation and add the PDF returned by Uruware. 
<img width="1705" height="618" alt="image" src="https://github.com/user-attachments/assets/8bb36b08-ab08-4240-b3bb-f593a7f2a462" />



Odoo Task 1334
Adhoc Task 53147

Forward-Port-Of: odoo/enterprise#100332
Forward-Port-Of: odoo/enterprise#89706

When importing a bank statements xlsx in a bank journal, the wizard would
not match the "Cumulative Balance", not even proposing it for manual setup.

Steps to reproduce:
- Go to the accounting dashboard
- On a bank journal tile, in the right corner menu "New > Import File"
- Upload a file (there is one attached to the ticket)
- Cumulative Balance is not matched

This commit adds module.init() that is skipped in the "onWillStart"
override (it's present in the parent onWillStart). This has for consequence
that the "bank_stmt_import" key is now present in the context when
get_fields_tree() from Base_ImportImport is called, allowing the addition
of missing field.
See https://github.com/odoo/enterprise/blob/19.0/account_bank_statement_import_csv/wizard/account_bank_statement_import_csv.py#L18

This commit also adds a check to only add debit & credit in the added
field list if they are not actual field on the bst line model (see:
https://github.com/odoo/enterprise/commit/af863c5a53d0ab50fe67cb9ea910391d4a1979dd)
This commit also checks that those fields are only added when the model
is account bank statement line (only useful in this case).

opw-5222326

Forward-Port-Of: odoo/enterprise#100693

### Steps to reproduce:

- Create a rentable, storable product
- Create and confirm a rental order for 1 unit of this product
- Click on pickup
- Inventory > Reporting > Moves History
#### > Your pickup move appears without any reference

### Cause of the issue:

The issue has been introduced in d0c1e7845feeee1c2e85a21b5d40570d051458d3 which purpose was to remove the `name` field of the `stock.move` model. However, the `_compute_reference` compute method use to rely on this `move.name` to propagate the info that the move was related to a rental order (since there is no picking). Indeed prior to saas-18.4, the compute method was:
https://github.com/odoo/odoo/blob/404cb10283cbc706eae67dd793ced363273f3602/addons/stock/models/stock_move.py#L325-L328 
And the reference to the rental order was set on the move at pickup: https://github.com/odoo/enterprise/blob/1466a0139ee64ecd059738bc414f6e7e5a9f4354/sale_stock_renting/models/sale_order_line.py#L303-L313 https://github.com/odoo/enterprise/blob/1466a0139ee64ecd059738bc414f6e7e5a9f4354/sale_stock_renting/models/sale_order_line.py#L248-L257

### Fix:

Since the reference field is a computed and stored fields and since some of its dependencies are set at creation the rental move we can not set the `reference` directly in the creation of the record as we used to do for its name since the compute method will then override and erase or reference.

opw-5385004

Forward-Port-Of: odoo/enterprise#101670

#### [FIX] snailmail_account_followup: fix address, cover page and layout

Currently there is the following potential problem when sending
the followup report via snailmail.
1. The address generation is not adjusted for snailmail. That can
   lead to problems with the service we use to send the actual letter.
   They validate the address rather strictly.
2. The cover page option does not work; it does not add a cover page.
   So we can not work around problems with the address generation
   by adding a cover page.
3. The layout / dimensions / margins of the generated document / PDF may not work
   with our current snailmail provider (Pingen). But there is no error
   message about it. (Although we do have something in the usual
   snailmail flow)
4. In case the address is invalid we do not try to "print" / send the letter,
   so the user does not receive any feedback.
   This could be an issue in case multiple follow-up reports are sent
   at the same time.

This commit fixes these issues. (See below for details.)

(1)
The logic for this already exists but it is only activated when
a context key is set. This is not the case currently.
After this commit we do set the key.

(2) & (3)
The issue is that we generate the PDF attachment before creating the
'snailmail.letter' record.
In the usual snailmail flow the PDF attachment generation is handled during the sending and
printing (in function `_fetch_attachment` on model 'snailmail.letter').
There is some special logic to
- add a cover page to the report PDF (if the option is selected)
- make sure the page dimensions of the PDF are okay
- overwrite the margins of the PDF with white to make sure the PDF is
  not rejected by Pingen because of this

But all this only happens if we do not have an attachment already.
(So it does not happen currently with the followup report)
For this a function called `_generate_report_pdf` was extracted from `_fetch_attachment`
in the related community commit to generate the report PDF (and its
filename). The function is extended here to be able to generate the
followup report.

(4)
We try to print / send the letter even if the address is invalid

Reproduce (i.e. for the cover page issue; but it explains how to get
the PDF that will be sent in general)

1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Set the "Add a Cover Page" option
   (Settings -> Accounting -> section "Customer Invoices")
   - enabled to test for the cover page
   - disabled to test that the address generation is adjusted
4. Send a follow-up report:
   - On 17.0: Accounting -> menu: "Customers" /  "Follow-up Reports"
     -> click on a line / partner -> button "Follow up"
   - On 18.0+: partner form view -> tab "Accounting"
     -> section "invoice follow-ups" -> button "Send"
5. Go to the snailmail letter:
   In debug mode: Settings -> menu: "Technical" -> section: "Email" -> "Snailmail Letters"
   (or just search for "snailmail" in the main screen)
   And select the letter
6. Download the PDF document

#### [FIX] snailmail_account_followup: forbid regenerating failed letters

The wizard to resend failed letters which allows to change the
cover page option is broken: The follow-up report can not be regenerated
correctly because it requires special follow-up specific `options` that are
lost after the initial pdf generation for the letter.

Currently it can happen that the follow-up PDF is regenerated but
without (actual) content (table listing the overdue amounts).

After this commit we cancel the snailmail letters and show an
error notification indicating that the followup needs to be done again to
create a new letter.

Reproduce
(needs credit on IAP or locally edit this function https://github.com/odoo/odoo/blob/3ffd51f1cb18e3f4fb0367c4a498d7438e0c0357/addons/snailmail/static/src/core_ui/message_patch.js#L11
to open the resend wizard `this.openFormatLetterAction()` for `sn_credit` error or always)

1. Install `snailmail_account_followup`
2. Create an overdue invoice
3. Ensure the address of the partner causes issues with Pingen
4. Ensure the cover page option is disabled:
   Settings -> Accounting -> section "Customer Invoices"
5. Send a follow-up report:
   - On 17.0: Accounting -> menu: "Customers" /  "Follow-up Reports"
     -> click on a line / partner -> button "Follow up"
   - On 18.0+: partner form view -> tab "Accounting"
     -> section "invoice follow-ups" -> button "Send"
6. Make some modifications like editing the follow-up message or a custom attachment
7. Download the snailmail letter PDF (see previous commit for details)
8. In the chatter go to the message saying "Letter sent by post with Snailmai"
9. Click on the red symbol (paper plane) next to the name
10. A "Format Error" wizard should show up
11. Select "Add a Cover Page"
12. Click the button "Update Config and Re-Send"
13. Download the snailmail letter PDF (see previous commit for details)
14. Compare PDFs from 7 and 13; they are different (not just the cover page)

#### references

opw-5160121
opw-5209504
opw-5226366

Forward-Port-Of: odoo/enterprise#101737
Forward-Port-Of: odoo/enterprise#99491

Steps to reproduce:
--------------------------
1. Install the Quality module.
2. Create a Quality Control Point with:
   * Control per: Control on Operation.
   * Operation: Receipts (set in the Operations field).
3. Create a Receipt containing one product.
4. Click the Mark as To Do button.
5. Add another product to the same Receipt and save it.

Observation:
--------------------------
Two quality checks are generated for the same picking, despite the tooltip indicating that only one check should be created per operation.

Issue:
--------------------------
No validation existed to verify whether an operation-based quality check had already been created for the picking when adding additional stock moves after confirmation.

Solution:
--------------------------
Add a check ensuring that if a quality check already exists for the same picking type and operation (with no product or category criteria), no additional operation-based quality checks are created.

opw-5249233

Forward-Port-Of: odoo/enterprise#101788
Forward-Port-Of: odoo/enterprise#100118

**Steps to reproduce:**
* Install the **Accounting** and **l10n_br_edi** modules.
* Create and post a Brazilian customer invoice using an **Avatax fiscal position**
* [Guide to setup EDI for l10n_br](https://docs.google.com/document/d/1CSUKpnyhty5WBqUDBE-7dGvu0qxaC5vQ0loz0fYNg04/edit?tab=t.0)
* Confirm the invoice and **send it to e-invoice (Brazil)**.
* Confirm the **Brazil E-Invoice Status** shows **'Accepted'**.
* Click **Request Cancellation**, enter a cancellation reason, and submit the request.

**Observed behavior:**
* The invoice moves to **Cancelled** state.
* The cancellation XML is generated and attached in the chatter.
* SEFAZ returns a successful cancellation response.
* However, the **BR EDI Status** becomes **empty**, instead of reflecting **'Cancelled'**.

**Cause:**
* In the wizard `l10n_br_edi.invoice.update`, both `_finalize_update()` and `_submit_services()` assign `l10n_br_last_edi_status = 'cancelled'` **before** calling `button_cancel()`.
* `button_cancel()` internally triggers `button_draft()` for posted invoices.
* The Brazil EDI override of `button_draft()` resets `l10n_br_last_edi_status = False`.
* This clears the status that was just set, leaving the field blank.

**Fix:**
* move `l10n_br_last_edi_status = "cancelled"` to `button_cancel()` method.

opw-5378542

Forward-Port-Of: odoo/enterprise#101438

Steps to reproduce:
--------------------------
1. Install the Quality module.
2. Create a Quality Control Point with:
   * Control per: Control on Operation.
   * Operation: Receipts (set in the Operations field).
3. Create a Receipt containing one product.
4. Click the Mark as To Do button.
5. Add another product to the same Receipt and save it.

Observation:
--------------------------
Two quality checks are generated for the same picking, despite the tooltip indicating that only one check should be created per operation.

Issue:
--------------------------
No validation existed to verify whether an operation-based quality check had already been created for the picking when adding additional stock moves after confirmation.

Solution:
--------------------------
Add a check ensuring that if a quality check already exists for the same picking type and operation (with no product or category criteria), no additional operation-based quality checks are created.

opw-5249233

Forward-Port-Of: odoo/enterprise#101788
Forward-Port-Of: odoo/enterprise#100118

```
  File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 100, in _register_hook
    self.env.registry._delayed_account_translator(self.env)
  File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 90, in load_account_translations
    env['account.chart.template']._load_translations(langs=langs)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 1449, in _load_translations
    ._get_chart_template_data(chart_template)
  File "/home/odoo/src/enterprise/19.0/account_accountant/models/account_chart_template.py", line 31, in _get_chart_template_data
    data = super()._get_chart_template_data(chart_template)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 803, in _get_chart_template_data
    data = func(self, template_code)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 59, in wrapper
    return func(*args, **kwargs)
  File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py", line 52, in _get_be_account_reconcile_model
    prepayment_communication = self.env['qr.code.payment.wizard']._be_company_vat_communication(self.env.company).replace('+++', '')
  File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/qr_code_payment_wizard.py", line 14, in _be_company_vat_communication
    number = int(vat)
ValueError: invalid literal for int() with base 10: 'LU19038918'
```
```sql
kmod_3311837=> select id,name,chart_template,parent_id from res_company;
 id |        name         | chart_template | parent_id
----+---------------------+----------------+-----------
  3 | C.R.O.Qu.E.T. S.A.  | be_comp        |
  2 | KG5380              | be_comp        |
  1 | KNOWLEDGE GATE S.A. | lu             |
(3 rows)

kmod_3311837=> select id,model,module,res_id from ir_model_data where name = 'main_company';
 id |    model    | module | res_id
----+-------------+--------+--------
  2 | res.company | base   |      1
(1 row)
```
```
> /home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py(52)_get_be_account_reconcile_model()
-> if template_code in ['be', 'be_comp', 'be_asso']:
(Pdb) template_code
'be_comp'
(Pdb) self.env.company
res.company(1,)
(Pdb) self.env.company.chart_template
'lu'
(Pdb)
```
- The traceback occurs because during the translation loading process, the system calls [_get_chart_template_data](https://github.com/odoo/odoo/blob/38cffd1d1580693c56f0d897b8c8e60b938a8e85/addons/account/models/chart_template.py#L1465)
for all available template codes. In the customer’s database, there are three companies: Company 2 and Company 3 use the BE_COMP localization, while Company 1 uses the LU localization.
- When _get_chart_template_data is executed for the BE_COMP chart template, it eventually calls [_get_be_account_reconcile_mode](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/account_chart_template.py#L49) During this call, the function receives the correct template code (be_comp) as an argument. However, self.env.company returns Company 1, because Company 1 is set as the main_company.
- As a result, [_be_company_vat_communication](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/qr_code_payment_wizard.py#L14) is called with Company 1, even though this company uses the LU localization. Since LU localization does not support the BE VAT communication logic, an error is raised from this method.
- I have made a fix that uses the chart_template of self.env.company to avoid the blocking issue during the upgrade. However, I am not fully sure whether this is the correct solution. Since the load_translation method does not pass with_company when retrieving the chart template, this issue will always occur because the methods are executed in the context of the main company instead of the company that the chart template actually belongs to.

opw-5342498

[FIX] account_reports: returns: fix generations of files as attachments

_generate_submission_attachments does not exist anymore ; it's been renamed to _generate_locking_attachments. Because of that, some intended overrides were not executed properly, and several XML/CSV export files were not generated and added as attachments to the return.

Moreover, the functions generating export files used to be called by account.report's export_file function (from a button defined in options['buttons']). export_file always forced the 'export_mode' key into the options it passed tp those file generators; we reintroduce this behavior for consistency, to avoid messy situations due to forward-port or functions being converted from the former paradigm to the new one. Note, however, it's always better to fully regenerate the options from such a generator.


=================================================================================


[FIX] account_reports: returns: homogenize the reset behavior

Before this fix, resetting a tax report deleted all the attachments of the return, while resetting for example the Partner VAT Listing (in Belgium), left them untouched. We now introduce a common helper for all reset functions, defining the behaviors they should share.

**Steps to reproduce:**
* Install the **Accounting** and **l10n_br_edi** modules.
* Create and post a Brazilian customer invoice using an **Avatax fiscal position**
* [Guide to setup EDI for l10n_br](https://docs.google.com/document/d/1CSUKpnyhty5WBqUDBE-7dGvu0qxaC5vQ0loz0fYNg04/edit?tab=t.0)
* Confirm the invoice and **send it to e-invoice (Brazil)**.
* Confirm the **Brazil E-Invoice Status** shows **'Accepted'**.
* Click **Request Cancellation**, enter a cancellation reason, and submit the request.

**Observed behavior:**
* The invoice moves to **Cancelled** state.
* The cancellation XML is generated and attached in the chatter.
* SEFAZ returns a successful cancellation response.
* However, the **BR EDI Status** becomes **empty**, instead of reflecting **'Cancelled'**.

**Cause:**
* In the wizard `l10n_br_edi.invoice.update`, both `_finalize_update()` and `_submit_services()` assign `l10n_br_last_edi_status = 'cancelled'` **before** calling `button_cancel()`.
* `button_cancel()` internally triggers `button_draft()` for posted invoices.
* The Brazil EDI override of `button_draft()` resets `l10n_br_last_edi_status = False`.
* This clears the status that was just set, leaving the field blank.

**Fix:**
* move `l10n_br_last_edi_status = "cancelled"` to `button_cancel()` method.

opw-5378542

Forward-Port-Of: odoo/enterprise#101438

**Steps To Reproduce:-**

1. Install point_of_sale in 17.0
2. Activate flexible taxes setting
3. set default fiscal position  and after that archived that fiscal position.
4. try edit and save the POS config any operation below mentioned recursion error will come.

**Issue :-**

Due to archived record of fiscal postion is keep updating due to not satisfying this condition [config.default_fiscal_position_id.id not in config.fiscal_position_ids.ids](https://github.com/odoo/odoo/blob/62652ba3a7a90699e7aa8ff98e2d4980f1b43694/addons/point_of_sale/models/pos_config.py#L529) here ``config.fiscal_position_ids`` on this active filter is applying and it coming empty and going to update many2many field this process goes infinite due to archive fiscal position record

**FIX:-**
       adding the check of active record fiscal position

```
 File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 442, in _set_fiscal_position
    config.fiscal_position_ids = [(4, config.default_fiscal_position_id.id)]
  File "/data/build/odoo/odoo/fields.py", line 1337, in __set__
    records.write({self.name: write_value})
  File "/data/build/odoo/addons/pos_restaurant/models/pos_config.py", line 52, in write
    return super(PosConfig, self).write(vals)
  File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 420, in write
    self.sudo()._set_fiscal_position()
  File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 442, in _set_fiscal_position
    config.fiscal_position_ids = [(4, config.default_fiscal_position_id.id)]
  File "/data/build/odoo/odoo/fields.py", line 1337, in __set__
    records.write({self.name: write_value})
  File "/data/build/odoo/addons/pos_restaurant/models/pos_config.py", line 52, in write
    return super(PosConfig, self).write(vals)
  File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 420, in write
    self.sudo()._set_fiscal_position()
  File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 442, in _set_fiscal_position
    config.fiscal_position_ids = [(4, config.default_fiscal_position_id.id)]
  File "/data/build/odoo/odoo/fields.py", line 1337, in __set__
    records.write({self.name: write_value})
  File "/data/build/odoo/addons/pos_restaurant/models/pos_config.py", line 52, in write
    return super(PosConfig, self).write(vals)
  File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 420, in write
    self.sudo()._set_fiscal_position()
  File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 442, in _set_fiscal_position
    config.fiscal_position_ids = [(4, config.default_fiscal_position_id.id)]
  File "/data/build/odoo/odoo/fields.py", line 1337, in __set__
    records.write({self.name: write_value})
  File "/data/build/odoo/addons/pos_restaurant/models/pos_config.py", line 52, in write
    return super(PosConfig, self).write(vals)
  File "/data/build/odoo/addons/point_of_sale/models/pos_config.py", line 418, in write
    result = super(PosConfig, self).write(vals)
  File "/data/build/odoo/odoo/models.py", line 3820, in write
    field.write(self, value)
  File "/data/build/odoo/odoo/fields.py", line 4287, in write
    return self.write_batch([(records, value)])
  File "/data/build/odoo/odoo/fields.py", line 4308, in write_batch
    return self.write_real(records_commands_list, create)
  File "/data/build/odoo/odoo/fields.py", line 4835, in write_real
    old_relation = {record.id: set(record[self.name]._ids) for record in records}
  File "/data/build/odoo/odoo/fields.py", line 4835, in <dictcomp>
    old_relation = {record.id: set(record[self.name]._ids) for record in records}
  File "/data/build/odoo/odoo/models.py", line 6007, in __getitem__
    return self._fields[key].__get__(self, self.env.registry[self._name])
  File "/data/build/odoo/odoo/fields.py", line 2824, in __get__
    return super().__get__(records, owner)
  File "/data/build/odoo/odoo/fields.py", line 1270, in __get__
    return self.convert_to_record(value, record)
  File "/data/build/odoo/odoo/fields.py", line 4199, in convert_to_record
    corecords = corecords.filtered(Comodel._active_name).with_prefetch(prefetch_ids)
  File "/data/build/odoo/odoo/models.py", line 5496, in filtered
    return self.browse([rec.id for rec in self if func(rec)])
  File "/data/build/odoo/odoo/models.py", line 5496, in <listcomp>
    return self.browse([rec.id for rec in self if func(rec)])
  File "/data/build/odoo/odoo/models.py", line 5493, in <lambda>
    func = lambda rec: any(rec.mapped(name))
  File "/data/build/odoo/odoo/models.py", line 5470, in mapped
    recs = recs._fields[name].mapped(recs)
  File "/data/build/odoo/odoo/fields.py", line 1299, in mapped
    return self.convert_to_record_multi(vals, records)
  File "/data/build/odoo/odoo/fields.py", line 942, in convert_to_record_multi
    return [convert(value, record) for value, record in zip(values, records)]
  File "/data/build/odoo/odoo/fields.py", line 942, in <listcomp>
    return [convert(value, record) for value, record in zip(values, records)]
  File "/data/build/odoo/odoo/models.py", line 5844, in __iter__
    yield self.__class__(self.env, (id_,), self._prefetch_ids)
RecursionError: maximum recursion depth exceeded
```

**OPW** - 5208462
**UPG** - 3248441


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

Forward-Port-Of: odoo/odoo#233358

Accrual plan for leave days gets blocked, even when the remaining leave balance is below the cap. As a result, no additional leaves are accrued beyond a certain point, even though they should be.

# Steps to reproduce:
Go to time off app
* Create a new leave type.
* Create a new accrual plan with:
        - one milestone :
		- 2 days accrued per month
		- Cap: 10 days
		- start accruing 1 days after
		- No expiration
		- Carry over: All
* Create and validate a leave allocation 
       - 1 year ago
       - new leave type
       - new accrual plan
* Take the maximum number of leaves available.
* Advance the computer calendar by 1 year.
* Again, take the maximum number of leaves.
* Advance the computer calendar by another year.
* Try to take a future leave.
-> Issue: It’s not possible to take a future leave, the number of accrued days has stopped increasing. The accrual plan appears blocked.

Objective : The accrual plan should continue to allocate leave days even if leaves have been consumed regularly, as long as the remaining leaves are under the cap.

## Issue
Before going further: the property `leaves_taken` of the `hr.leave.allocation` is supposed to contain the number of leaves this allocation cover until "today".

In the `_test_get_allocation_future_leaves1` added test, in the last line of the test :
`assert_virtual_leaves_equal(self, leave_type_day, 2, self.employee_emp, date='2023-02-01')`

When calling `get_allocation_data` with a `target_date` set in the future, the result is wrong. Here is how it works :
`get_allocation_data`
...
.....`_get_consumed_leaves` (1)
...........`_get_future_leaves_on` (2)
...............`_process_accrual_plans` (3)
....................`_compute_leaves` (4)
.........................`_get_consumed_leaves` (5)
..............................`get_future_leaves_on` (6)
...................................`process_accrual_plans` (7)

**A)** The method **(2)** try to calculate the added number of days each allocation will have on `target_date`. So it creates a copy of the allocation in memory using the 'new' method:
`fake_allocation = self.env['hr.leave.allocation'].with_context(default_date_from=accrual_date).new(origin=self)`
It will then update it to `target_date` using `_process_accrual_plans` and will return the difference of days between the
updated `fake_allocation` and the current allocation (`self`)

**B)** Before iterating over each accrual date, the `_process_accrual_plans` **(3)** will get the `leaves_taken` property which is a computed field. It will trigger `_compute_leaves`.

**C)** The method **(4)** will call `_get_consumed_leaves`, and so the nightmare begins.

**D)** The method **(6)** will create a second `fake_allocation` based on the origin of the first `fake_allocation` (see **A)**).

**E)** This time, `_process_accrual_plans` **(7)** will also look at the `leaves_taken`, but won't trigger the `_compute_leaves` probably because the current allocation is a `fake_allocation` of a `fake_allocation`, and one property of the `new` method is that `Two new records with the same origin record are considered equal.`. Therefore, the `leaves_taken` is considered to be already computed (but it's not).

So `_process_accrual_plans` read the `leaves_taken` which is 0 (probably the default value of `leaves_taken`), but it should be 20 !

**F)** As the value of `leaves_taken` is wrong, the fake_allocation n°2 is also wrong, and its `number_of_day` is 10 but the `number_of_days` of the origin allocation is 20. So `get_future_leaves_on` **(6)** will return -10 which makes no sense, and all the previous calls computations will be wrong. And the final `virtual_remaining_leaves` value will be 0 instead of 2.

## Source of the issue
In the `_process_accrual_plans` method, for each allocation, `leaves_taken` is only computed once at the start of the loop over the allocation "important" dates (see `nextcall` property of `hr.leave.allocation`). At this moment, the method calculates the `leaves_taken` the allocation will have on the `accrual_date` parameter. Yet, this property can change depending on the date the allocation is on (`nextcall` property) which leads to some issues in the computation of the `allocation.number_of_days`.

## Solution
For each allocation, compute the `leaves_taken` at every iteration trough the values of `nextcall`. BUT, this can trigger an infinite loop as computing `leaves_taken` calls `_get_consumed_leaves` which calls `_get_future_leaves_on`, which calls `_process_accrual_plans` ... To avoid this, this PR add the context variable `precomputed_allocations` (will be converted into a function parameter in master) which will prevent `_get_consumed_leaves` from calling `_get_future_leaves_on` for the allocations already up to date (contained by this very `precomputed_allocations` context variable).

opw-4934391

```
  File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 100, in _register_hook
    self.env.registry._delayed_account_translator(self.env)
  File "/home/odoo/src/odoo/19.0/addons/account/models/ir_module.py", line 90, in load_account_translations
    env['account.chart.template']._load_translations(langs=langs)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 1449, in _load_translations
    ._get_chart_template_data(chart_template)
  File "/home/odoo/src/enterprise/19.0/account_accountant/models/account_chart_template.py", line 31, in _get_chart_template_data
    data = super()._get_chart_template_data(chart_template)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 803, in _get_chart_template_data
    data = func(self, template_code)
  File "/home/odoo/src/odoo/19.0/addons/account/models/chart_template.py", line 59, in wrapper
    return func(*args, **kwargs)
  File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py", line 52, in _get_be_account_reconcile_model
    prepayment_communication = self.env['qr.code.payment.wizard']._be_company_vat_communication(self.env.company).replace('+++', '')
  File "/home/odoo/src/enterprise/19.0/l10n_be_reports/models/qr_code_payment_wizard.py", line 14, in _be_company_vat_communication
    number = int(vat)
ValueError: invalid literal for int() with base 10: 'LU19038918'
```
```sql
kmod_3311837=> select id,name,chart_template,parent_id from res_company;
 id |        name         | chart_template | parent_id
----+---------------------+----------------+-----------
  3 | C.R.O.Qu.E.T. S.A.  | be_comp        |
  2 | KG5380              | be_comp        |
  1 | KNOWLEDGE GATE S.A. | lu             |
(3 rows)

kmod_3311837=> select id,model,module,res_id from ir_model_data where name = 'main_company';
 id |    model    | module | res_id
----+-------------+--------+--------
  2 | res.company | base   |      1
(1 row)
```
```
> /home/odoo/src/enterprise/19.0/l10n_be_reports/models/account_chart_template.py(52)_get_be_account_reconcile_model()
-> if template_code in ['be', 'be_comp', 'be_asso']:
(Pdb) template_code
'be_comp'
(Pdb) self.env.company
res.company(1,)
(Pdb) self.env.company.chart_template
'lu'
(Pdb)
```

- The traceback occurs because during the translation loading process, the system calls [_get_chart_template_data](https://github.com/odoo/odoo/blob/38cffd1d1580693c56f0d897b8c8e60b938a8e85/addons/account/models/chart_template.py#L1465) for all available template codes. In the customer’s database, there are three companies: Company 2 and Company 3 use the BE_COMP localization, while Company 1 uses the LU localization.
- When _get_chart_template_data is executed for the BE_COMP chart template, it eventually calls [_get_be_account_reconcile_mode](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/account_chart_template.py#L49) During this call, the function receives the correct template code (be_comp) as an argument. However, self.env.company returns Company 1, because Company 1 is set as the main_company.
- As a result, [_be_company_vat_communication](https://github.com/odoo/enterprise/blob/d13dc2d7b54d7e43f3b27b19131d0a277d0498b8/l10n_be_reports/models/qr_code_payment_wizard.py#L14) is called with Company 1, even though this company uses the LU localization. Since LU localization does not support the BE VAT communication logic, an error is raised from this method.
- There is no context of the company passed when calling _get_chart_template_data from _load_translations, so I have applied with_company, so _get_chart_template_data is called in the context of a specific company.
opw-5342498
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr