**Steps to reproduce:**
1. Install Inventory.
2. Open Inventory → Configuration
3. Barcode Nomenclature and select the default GS1 Nomenclature.
4. Open Barcode → scan the code:154105510000000244.

**Observation:**
- Scanning a GS1 barcode with an invalid date crashes Odoo and raises a traceback.

**Cause:**
- The translated ValidationError message uses the wrong interpolation syntax:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L58
and therefore fails during rendering.

- Correct syntax should be:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/account/models/account_move.py#L5647

**Fix:**
- Fix faulty interpolation placeholder in  ValidationError message to use `%(error_message)s` instead of `'%(error_message)'`, preventing the traceback and allowing the error message to display correctly.

**opw-5253564**

Forward-Port-Of: odoo/odoo#236858

### Issue:
During the loading of fiscal position data for LATAMs the option "Use Documents" on Journals is not set-up.

### Steps to reproduce:
- Install 'l10n_ar'
- Settings > Accounting
- Make sure the "Fiscal Localization" have a value (not Argentina)
- Change the "Fiscal Localization" to "Argentine - Generic Chart of Accounts [...]"
- Go in Accounting > Configuration > Journals
- Click on "Ventas Preimpreso"
- The journal don't have "Use Documents" ticked but it should

### Cause:
When loading the data, `_get_chart_template_data()` calls `_get_ar_base_res_company()` and `_get_latam_document_account_journal()`.

The first one returns the data to change `res.company.account_fiscal_country_id` to `base.ar`. The second one [checks](https://github.com/odoo/odoo/blob/26a5384af0af8fc6e6b5a10bea277f937e2b3481/addons/l10n_latam_invoice_document/models/account_chart_template.py#L12) that [`self.env.company.account_fiscal_country_id.code == "AR"`](https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/l10n_ar/models/res_company.py#L36) before returning the data to change `l10n_latam_use_documents` to `True`. As `res.company.account_fiscal_country_id` has not been updated, it's not Argentina during the check and `_get_latam_document_account_journal()` returns nothing.

### Solution:
When loading the template, we cannot use `res.company.account_fiscal_country_id` to know if we are in LATAM or not. So instead we check on `chart_template`.

opw-5221931

Forward-Port-Of: odoo/odoo#237725
Forward-Port-Of: odoo/odoo#236217

**Issue**
In shopfloor, a traceback occurs when clicking on the add button if the associated operation has a `quality_check` of type `register_consumed_materials`.

**Steps to reproduce**
1. Create two products (product and component)
2. Create a BOM for this product that consumes that component
3. Create an operation linked to that BOM (Manufacturing > Configuration > Operations)
4. Add a quality check of type “Register Consumable Material” for this operation
5. Create a MO from that BOM and confirm it
6. Click on the shopfloor smart button → If debug mode is activated, a traceback occurs → Otherwise
7. Click on the 'add' button → A traceback occurs

**Cause**
In the method [`subRecordProps`](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_display_record.js#L190C9-L194C14), when a quality check of type `register_consumed_materials` is done, the variable `production` is not propagated into the props. And [this](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L184) tries to access the production in the props, which is [called](https://github.com/odoo/enterprise/blob/d180235b7946c7219385df263f13f780e7faea50/mrp_workorder/static/src/mrp_display/mrp_record_line/stock_move.js#L163) when the user clicks the 'add' button.

**Solution**
Add the `production` variable to the props.

opw-5165259

**Steps to Reproduce:**

1. create test ``Float`` field in model ``A`` with ``digits`` args
2. create ``Many2One`` field with comodel ``A``  and then create Float Field in ``B Model`` with related ``A`` model test and store True

**Issue:**
  1. ``column_type`` for both model table will be different. For ``test field in model A`` the ``column_type`` will be ``numeric``. But for the related field ``column_type`` ``float`` it should be ``numeric``. This happen because the @lazy_propery it hold the ``column_type`` which is ``float8`` and other related attributes from ``setup_related`` before that ``_digits`` have the null value. So, from [here](https://github.com/odoo-dev/odoo/blob/a9398502260fa57573b88fd62ca3f554e0685c7b/odoo/fields.py#L772) it remains ``float8`` it should update with ``numeric``

   **Second issue comes From odoo 18.3**:=

during upgrade if any new ``module`` is intalled due to dependency change and inherits the same model that is ``A``. 
Due to ``_auto_init`` it will recompute this related field  because due to this newly [commit](https://github.com/odoo/odoo/commit/f5ce6784fce1ae27c3e92090b3723e9d4ce45808) clear the columns column becomes [``False``] and [``not column``] becomes true  from ``update_db`` and same reason as above  it didn't return from [here](https://github.com/odoo/odoo/commit/f5ce6784fce1ae27c3e92090b3723e9d4ce45808#diff-956d895aa67961bac940841f7c3d1e10eb8ecabec82ef017803c4a6a3bb7cd22R1074) because column type is ``float8`` which leads to  memory of unecessary compute which shouldn't do in first place.

**FIX:**

Remove the ``column_type`` and let it get again as soon ``_digits`` attribute add.

before fix:-
```
SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'account_move_line' AND column_name = 'test_line_id';
 column_name  |    data_type
--------------+------------------
 test_line_id | double precision
(1 row)

```

After fix:-
```
SELECT column_name, data_type FROM information_schema.columns WHERE table_name = 'account_move_line' AND column_name = 'test_line_id';
 column_name  | data_type
--------------+-----------
 test_line_id | numeric
(1 row)

```
opw-5222760
upg-3253635

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

Forward-Port-Of: odoo/odoo#237050
Forward-Port-Of: odoo/odoo#235112

**Steps to reproduce:**
1. Install Inventory.
2. Open Inventory → Configuration
3. Barcode Nomenclature and select the default GS1 Nomenclature.
4. Open Barcode → scan the code:154105510000000244.

**Observation:**
- Scanning a GS1 barcode with an invalid date crashes Odoo and raises a traceback.

**Cause:**
- The translated ValidationError message uses the wrong interpolation syntax:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L58
and therefore fails during rendering.

- Correct syntax should be:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/account/models/account_move.py#L5647

**Fix:**
- Fix faulty interpolation placeholder in  ValidationError message to use `%(error_message)s` instead of `'%(error_message)'`, preventing the traceback and allowing the error message to display correctly.

**opw-5253564**

Forward-Port-Of: odoo/odoo#236858

Steps to reproduce:
1. Install website_sale_subscription
2. Enable Comparison Price from the settings
3. Create a Subscriptions product with a recurring plan and 'compare to price' > recurring price
4. Go to product page via smart button

Issue:
- The comparison price is not visible beside the recurring plan.

Cause:
- The product page updates the pricing display dynamically using client-side rendering when the subscription plan information is loaded. The XML template `website_sale_subscription.SubscriptionPricingSelect` used the <field> tag `<field name="product.compare_list_price"/>` to render the comparison price. The <field> tag is a server-side QWeb element and is not supported by the client-side Owl engine, causing the rendering to display nothing.
Additionally, client-side templates do not have automatic access to server-side field formatting (like currency symbols) when simply escaping raw values.

Solution:
- In `variant_mixin.js`, extract the already formatted comparison price text from the existing DOM element (the `<del>` tag inside the pricing selector) before the element is replaced and pass this formatted string to the rendering context. Update the XML template to use `t-esc` to display this pre-formatted string instead of using `<field>`

before:
<img width="426" height="79" alt="image" src="https://github.com/user-attachments/assets/fe34b4c5-5cd6-4877-80e3-9ed4481cd86f" />

After:
<img width="392" height="115" alt="image" src="https://github.com/user-attachments/assets/ed043fef-bfd3-46de-aeb2-1a48cacc89ed" />

opw-5248297

Forward-Port-Of: odoo/enterprise#100140

### Issue:
During the loading of fiscal position data for LATAMs the option "Use Documents" on Journals is not set-up.

### Steps to reproduce:
- Install 'l10n_ar'
- Settings > Accounting
- Make sure the "Fiscal Localization" have a value (not Argentina)
- Change the "Fiscal Localization" to "Argentine - Generic Chart of Accounts [...]"
- Go in Accounting > Configuration > Journals
- Click on "Ventas Preimpreso"
- The journal don't have "Use Documents" ticked but it should

### Cause:
When loading the data, `_get_chart_template_data()` calls `_get_ar_base_res_company()` and `_get_latam_document_account_journal()`.

The first one returns the data to change `res.company.account_fiscal_country_id` to `base.ar`. The second one [checks](https://github.com/odoo/odoo/blob/26a5384af0af8fc6e6b5a10bea277f937e2b3481/addons/l10n_latam_invoice_document/models/account_chart_template.py#L12) that [`self.env.company.account_fiscal_country_id.code == "AR"`](https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/l10n_ar/models/res_company.py#L36) before returning the data to change `l10n_latam_use_documents` to `True`. As `res.company.account_fiscal_country_id` has not been updated, it's not Argentina during the check and `_get_latam_document_account_journal()` returns nothing.

### Solution:
When loading the template, we cannot use `res.company.account_fiscal_country_id` to know if we are in LATAM or not. So instead we check on `chart_template`.

opw-5221931

Forward-Port-Of: odoo/odoo#237725
Forward-Port-Of: odoo/odoo#236217

In the Accounting app, users can print checks created to
pay Vendor Bills. When using any of the US Checks Layout (from
`l10n_us_check_printing`), the payment date would overlap
the table beneath it when the journal's manual sequencing option was
disabled.

<img width="1201" height="624" alt="image" src="https://github.com/user-attachments/assets/cd3aa46a-1952-4652-9034-e4bc2ea9a44d" />

This occured because the `.summary_line` container collapsed to a height
of 0 whenever its first child wasn't displayed, as the remaining child
elements are absolutely positioned and therefore do not contribute to
the parent's height.

https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/l10n_us_check_printing/report/print_check.xml#L24-L34

By assigning a minimum height to the `.summary_line` class, we make sure
that it always occupies space above the table, even when only the date
is shown.

### Steps to reproduce:
**/!\ To reproduce the bug locally, you must have a version of wkhtmltopdf with patched qt. Use `wkhtmltopdf -V` and make sure that _"(with patched qt)"_ is specified after your wkhtmltopdf version.**
1. Install Accounting (`accountant`) and US Checks Layout (`l10n_us_check_printing`)
2. In Settings > Accounting, toggle on *Checks* if it is not, and set *Check Layout* to any "US" layout.
3. Go to Accounting > Vendors > Bills
4. Create a new Vendor Bill:
    - Set any Vendor
    - Set any Bill Date
    - Add any Product (with a positive price, the total price of the bill must be positive)
    - Confirm
5. Click *Pay*, set the *Payment Method* to *Checks* and click *Create Payment*
6. Click on the *Payments* smart button
7. Click *Print Check* > *Print* (> *Continue*)
8. In the generated PDF, the date overlaps the table beneath it.

This fix moves the date right above the table.

<img width="1189" height="634" alt="image" src="https://github.com/user-attachments/assets/8858098e-b39b-4ad2-aa65-cc0cea550343" />


opw-5165112

Forward-Port-Of: odoo/enterprise#100487

Same issue already fixed for 18.4+ here:
https://github.com/odoo/odoo/pull/231399

Issue:
When setting up a payment reference and linking a bank to an invoice, sending an E-Factura (SPV) triggers an exception: state_id not defined for res.bank.

Repro Steps:
1- Create invoice for romanian localization.
2- Link payment account to invoice.
3- Add bank to payment account.
4- Confirm and send invoice with "Send E-Factura SPV" checked.

Cause:
The state field is defined differently for res.bank and res.partner. res.partner uses state_id, while res.bank uses state. The code that retrieves addresses assumes the same field for both, leading to an exception when accessing state for res.bank.

Fix:
The fix checks the type of the input and selects the appropriate field (state or state_id) accordingly.

opw-5362000

(cherry picked from commit a2af8d434bfc7f77008959c8179e8f158bcf9e93)

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

Forward-Port-Of: odoo/odoo#237615

Version - 17.0

Issue:
- When creating and confirming an alternative sale order (SO) from an upsell order, attempting to generate an invoice would raise a deferred end date error
- As a result, the invoice was not created, and even though the customer's payment succeeded, no invoice was issued.

Steps to reproduce:
- Create an upsell order of a subscription.
- Click Create Alternative to generate an alternative SO.
- Confirm the SO and click on Create Invoice to make the invoice
- This will throw an error of defferred end date

Cause:
- The `next_invoice_date` was not copied from the previous upsell order to the new alternative SO.
- Without this value, the deferred end date was incorrectly computed as today’s date - 1, triggering the error.

Fix:
- Copy the `next_invoice_date` from the previous upsell order to the new alternative SO to ensure proper deferred date computation.

Impact:
Invoices for alternative upsell sale orders can now be created successfully without errors.

task-5241150

Forward-Port-Of: odoo/enterprise#99831
Forward-Port-Of: odoo/enterprise#98983

Steps to reproduce:
1. Install website_sale_subscription
2. Enable Comparison Price from the settings
3. Create a Subscriptions product with a recurring plan and 'compare to price' > recurring price
4. Go to product page via smart button

Issue:
- The comparison price is not visible beside the recurring plan.

Cause:
- The product page updates the pricing display dynamically using client-side rendering when the subscription plan information is loaded. The XML template `website_sale_subscription.SubscriptionPricingSelect` used the <field> tag `<field name="product.compare_list_price"/>` to render the comparison price. The <field> tag is a server-side QWeb element and is not supported by the client-side Owl engine, causing the rendering to display nothing.
Additionally, client-side templates do not have automatic access to server-side field formatting (like currency symbols) when simply escaping raw values.

Solution:
- In `variant_mixin.js`, extract the already formatted comparison price text from the existing DOM element (the `<del>` tag inside the pricing selector) before the element is replaced and pass this formatted string to the rendering context. Update the XML template to use `t-esc` to display this pre-formatted string instead of using `<field>`

before:
<img width="426" height="79" alt="image" src="https://github.com/user-attachments/assets/fe34b4c5-5cd6-4877-80e3-9ed4481cd86f" />

After:
<img width="392" height="115" alt="image" src="https://github.com/user-attachments/assets/ed043fef-bfd3-46de-aeb2-1a48cacc89ed" />

opw-5248297

Forward-Port-Of: odoo/enterprise#100140

Sometimes, the seconds of the duration appear as a floating point
number in the call summary page. This happens because the duration in the
database is stored in hours. So when converting it, at creation, from
seconds to hours, you can have an irrational number. For example, if the
call lasted 3 seconds: 3/3600=0.00083333333...

This number has infinite repeating digits, and then an approximation is
stored. When the JS frontend receives the approximation value and multiples
it back by 36000 to get the seconds: 0.0008333333334*3600 might result
in 2.999999999 instead of 3.

This commit fixes that by rounding the seconds after being multiplied in
the frontend.

[Task-5363712
](https://www.odoo.com/odoo/project/5778/tasks/5363712)<img width="418" height="266" alt="image" src="https://github.com/user-attachments/assets/4f17721f-55c5-40b9-81b1-7c75f7ee6158" />

<img width="438" height="457" alt="image" src="https://github.com/user-attachments/assets/68de4ea2-1e97-4fe3-be61-0a728317f6ae" />

Currently a `ParseError` arises when the user installs the `hr_work_entry_attendance` module after deleting all `Overtime Rules' in the 'Rulesets` Configuration.

Steps to reproduce:
---
- Install `hr_attendance` module(without demo)
- Attendance > Configurations > Overtime Rulesets
- Delete all `Overtime Rules` in `Default Ruleset`
- Now install `hr_work_entry_attendance` module

Traceback:
---
```py
Exception: Cannot update missing record 'hr_attendance.hr_attendance_overtime_employee_schedule_rule'

ParseError
while parsing /home/odoo/src/enterprise/19.0/hr_work_entry_attendance/data/hr_attendance_overtime_rule_data.xml:4, somewhere inside <record id="hr_attendance.hr_attendance_overtime_employee_schedule_rule" model="hr.attendance.overtime.rule">
            <field name="work_entry_type_id" model="hr.attendance.overtime.rule" eval="obj()._get_default_work_entry_type_id()"/>
        </record>
```

The error occurs because the user deleted all `Overtime Rules` and then installed the `hr_work_entry_attendance` module. which requires particular records.

This commit solves the above issue by using `noupdate="1"`and `forcecreate="0"` to skip the creation of record if it doesn't exists.
https://github.com/odoo/odoo/blob/b794f0f332f473deb2c04eba60baf4761db3b508/odoo/tools/convert.py#L364-L366

sentry-7023182659

Forward-Port-Of: odoo/enterprise#99347

**Steps:**
- open documents in list view in dark mode
- select and deselect a record

**Observation:**
- the selected record's background becomes white and text was already white
- hence nothing can be seen clearly

**Cause:**
- Commit [1] introduces a scss change for list view, but used hardcoded values for color, which works well for light mode but not in dark mode

https://github.com/odoo/enterprise/blob/f73626fa778fd96de213a0fae61ced6fd5012d36/documents/static/src/scss/documents_views.scss#L29-L36

[1]: https://github.com/odoo/enterprise/commit/009fddcd20b0e7b81b8959f73e39d840d96167c7

**Fix:**
- instead of hardcoding color, we use already available variable, which adjust the color, according to theme.

**Before:**
<img width="1150" height="176" alt="image" src="https://github.com/user-attachments/assets/33d0688c-d9cd-4266-bcc8-189e830bc391" />

<img width="1319" height="203" alt="image" src="https://github.com/user-attachments/assets/cd8fa68e-76ff-411d-8d37-4e61e2ce99e8" />


<br><br>
**After:**
<img width="1028" height="141" alt="image" src="https://github.com/user-attachments/assets/470365b0-c18f-497d-b3b2-11cd8fea371a" />

<img width="996" height="164" alt="image" src="https://github.com/user-attachments/assets/74d6b71b-852e-41ee-acb3-4b58d8eace9e" />


opw-5261669

Forward-Port-Of: odoo/enterprise#100665
Forward-Port-Of: odoo/enterprise#100114

## **Issue Before This Commit:**
When a work order is assigned to an employee (not linked to the current user),
and the current user marks it as done, the time log is wrongly created
under the current user’s employee instead of the assigned one.
This behavior caused confusion for the user as the
wrong person was shown as working on the order.

## **Steps to Reproduce:**
- Create an MO with work orders and confirm it.
- Assign another employee to a work order.
- Mark the work order as done with the current user from the work order line.
- Open the workorder and notice that the time log is created for the current user’s employee.

## **Cause of the Issue:**
The bug was introduced in PR (https://github.com/odoo/enterprise/pull/84790),
where the logic for assigning the main employee was overridden,
ignoring the case of an already assigned employee.

## **With This Commit:**
The time log is now created for the assigned employee,
This resolves the confusion by ensuring
the right person is tracked on the work order.

TaskID: 4983514

Forward-Port-Of: odoo/enterprise#100604
Forward-Port-Of: odoo/enterprise#93378

In the Accounting app, users can print checks created to
pay Vendor Bills. When using any of the US Checks Layout (from
`l10n_us_check_printing`), the payment date would overlap
the table beneath it when the journal's manual sequencing option was
disabled.

<img width="1201" height="624" alt="image" src="https://github.com/user-attachments/assets/cd3aa46a-1952-4652-9034-e4bc2ea9a44d" />

This occured because the `.summary_line` container collapsed to a height
of 0 whenever its first child wasn't displayed, as the remaining child
elements are absolutely positioned and therefore do not contribute to
the parent's height.

https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/l10n_us_check_printing/report/print_check.xml#L24-L34

By assigning a minimum height to the `.summary_line` class, we make sure
that it always occupies space above the table, even when only the date
is shown.

### Steps to reproduce:
**/!\ To reproduce the bug locally, you must have a version of wkhtmltopdf with patched qt. Use `wkhtmltopdf -V` and make sure that _"(with patched qt)"_ is specified after your wkhtmltopdf version.**
1. Install Accounting (`accountant`) and US Checks Layout (`l10n_us_check_printing`)
2. In Settings > Accounting, toggle on *Checks* if it is not, and set *Check Layout* to any "US" layout.
3. Go to Accounting > Vendors > Bills
4. Create a new Vendor Bill:
    - Set any Vendor
    - Set any Bill Date
    - Add any Product (with a positive price, the total price of the bill must be positive)
    - Confirm
5. Click *Pay*, set the *Payment Method* to *Checks* and click *Create Payment*
6. Click on the *Payments* smart button
7. Click *Print Check* > *Print* (> *Continue*)
8. In the generated PDF, the date overlaps the table beneath it.

This fix moves the date right above the table.

<img width="1189" height="634" alt="image" src="https://github.com/user-attachments/assets/8858098e-b39b-4ad2-aa65-cc0cea550343" />


opw-5165112

Forward-Port-Of: odoo/enterprise#100487

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#99676
Forward-Port-Of: odoo/enterprise#89706

Enterprise PR: https://github.com/odoo/enterprise/pull/100331

**This PR contains 2 commits:**

- **[IMP] iot_base: allow use of LNA for IoT requests**
Chromium 142 added support for HTTPS -> HTTP requests on the local network (Local Network Access). This commit adds a flag to the IoT longpolling class to enable LNA support. The flag forces all requests to use HTTP even in an HTTPS environment. It also sets the `targetAddressSpace` option to `local` in the `fetch` request.

- **[IMP] point_of_sale: use_lna support for IoT requests**
Since https://github.com/odoo/odoo/pull/235702, there is a `point_of_sale.use_lna` system parameter. When it is set, ePOS requests will use HTTP instead of HTTPS, and the `targetAddressSpace: "local"` option is used in the `fetch` request. This bypasses the need for a HTTPS certificate.

This commit adds the same functionality to all IoT requests from the POS. This should allow the IoT box to function correctly without a HTTPS certificate.

task-5353672

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

Forward-Port-Of: odoo/odoo#237340
Forward-Port-Of: odoo/odoo#237147

Steps to reproduce the bug:
1. install hr_contract_salary_payroll
2. check "My US Company"
3. go on "Work Entries", then click on the arrow to view the next month. -> This will generate work entries for the next month
4. Go back to employees / Troy Cruz / Offers (smart button) -> You should be on the form view of a new offer. Do not save it.
5. Change the contract template to (e.g.) Experienced Developer -> A validation Error should appear

The validation error would tell us that we are trying to set a new contract to the employee, but the employee already had a running contract.

This happens because `self.employee_id` would be set to false just after the write of it's version's `contract_date_end`:
https://github.com/odoo/enterprise/blob/9ea4c1382a75024acacba7af1529d0c5cc762827/hr_contract_salary_payroll/models/hr_contract_salary_offer.py#L78C1-L78C7

This only happens when there are work entries after the specified end date. This is why we had to look at the next month's work entries.

The problematic code gets rolled back at some point, but `self.employee_id` stays empty if we don't save the form, since self is a `newId` in this case, which is not stored in the DB (and thus not rolled back)

The issue was that the context was supposed to have the `salary_simulation` key present, since we are doing a salary simulation.
But, the backend would still try to unlink the work entries of current_version during the simulation. Which is not needed and causes `self.current_employee_id` to be set to `False`

The context variable and a check before `_remove_work_entries()` has thus been added to fix that.

task-5207567

Steps to reproduce the bug:
1. install hr_contract_salary_payroll
2. check "My US Company"
3. go on "Work Entries", then click on the arrow to view the next month. -> This will generate work entries for the next month
4. Go back to employees / Troy Cruz / Offers (smart button) -> You should be on the form view of a new offer. Do not save it.
5. Change the contract template to (e.g.) Experienced Developer -> A validation Error should appear

The validation error would tell us that we are trying to set a new contract to the employee, but the employee already had a running contract.

This happens because `self.employee_id` would be set to false just after the write of it's version's `contract_date_end`:
https://github.com/odoo/enterprise/blob/9ea4c1382a75024acacba7af1529d0c5cc762827/hr_contract_salary_payroll/models/hr_contract_salary_offer.py#L78C1-L78C7

This only happens when there are work entries after the specified end date. This is why we had to look at the next month's work entries.

The problematic code gets rolled back at some point, but `self.employee_id` stays empty if we don't save the form, since self is a `newId` in this case, which is not stored in the DB (and thus not rolled back)

The issue was that the context was supposed to have the `salary_simulation` key present, since we are doing a salary simulation.
But, the backend would still try to unlink the work entries of current_version during the simulation. Which is not needed and causes `self.current_employee_id` to be set to `False`

The context variable and a check before `_remove_work_entries()` has thus been added to fix that.

task-5207567

Currently an error occurs when there are multiple stock references of same name, and user assigns references on Reception report.

Steps to replicate:
- Install `sale_stock`.
- Load Demo data from Settings.
- From settings, check `Reception Report`.
- Go to Operations > Reference > S00004 > Duplicate it (from the form view).
- Open Receipts > WH/IN/00002 > Allocation (Smart button) > Click 'Assign All' or the S00004 line.

Error:
```
File "/home/odoo/odoo18/community/addons/stock/report/report_stock_reception.py", line 271, in action_assign
    self._action_assign(in_move, out)
  File "/home/odoo/odoo18/community/addons/stock/report/report_stock_reception.py", line 343, in _action_assign
    in_move._get_source_document()._add_reference(out_ref)
  File "/home/odoo/odoo18/community/addons/stock/models/stock_picking.py", line 2102, in _add_reference
    self.move_ids.reference_ids = [Command.link(reference.id)]
  File "/home/odoo/odoo18/community/odoo/orm/fields_misc.py", line 112, in __get__
    raise ValueError("Expected singleton: %s" % record)
ValueError: Expected singleton: stock.reference(3, 19)
```

Cause:
- As the user duplicated the record, there were two records received in the variable `reference` at [1] that caused the expected singleton error.

Solution:
- The methods `_add_reference()` and `_remove_reference()` can now handle multiple reference records.

[1]: https://github.com/odoo/odoo/blob/4b2154870eebcce449f53d8f593386ae6af04a83/addons/sale_stock/models/sale_order.py#L329

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

Before this commit, rendering BuilderList with many elements caused noticeable delays.

How to reproduce:
=======================
- Use a runbot with all demo data
- Switch to edit mode in the website builder
- Add a form
- Link the form to the Contact model
- Add the "State" field

Before this commit:
The options related to the "State" field took more than one second to render.

After this commit:
Rendering is several hundred milliseconds faster. Additional commits will follow to further improve the situation.

Reason for the slowdown:
=======================
BuilderList is not optimized to render several thousand records (about 1900 in this example). This commit addresses the identified bottlenecks to reduce rendering time.

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Forward-Port-Of: odoo/odoo#237462

- Earlier, when downloading an invoice, invoices that were never sent didn’t have a generated PDF.
This happened because the method _get_invoice_legal_documents_all had allow_fallback=False by default.
As a result, those invoices returned no attachments, leading to blank pages or missing files in the ZIP download —
since the invoices weren’t sent and no fallback was allowed.

**Steps to reproduce:**
**1:** Go to Invoices
**2:** Try to use Export ZIP for any non-sent invoice → you’ll see a blank page

**What this patch does:**
- It limits the Export ZIP option to the list view only. This doesn’t fix the missing PDF issue, but it makes sense — having “Export ZIP” on every single invoice form view isn’t useful.

**Possible improvements to consider:**
**1:** Restrict Export ZIP so it’s only available for sent invoices. This would improve performance since sent invoices already have PDFs stored in the filestore.

**2:** Allow a fallback for invoices that haven’t been sent, so their PDFs are generated when exporting — but this may cause performance issues if too many non-sent invoices are processed at once.

**3:** Instead of showing a blank page for non-sent invoices, show a user-friendly
 error message. (I noticed this was in the original commit
odoo/odoo@c81ab09d0404cc57f48c202360361a1700f060db where this was
 introduced but was later removed — not sure why.)

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

Forward-Port-Of: odoo/odoo#234886

Currently, if a user overpays while using a different language, like French, the receipt does not show the change.

**Steps to replicate:**
* Install POS with demo data and change language to French .
* POS > Furniture Shop > Open the register
* Select a product, overpay with cash, and validate.

**Issue:**
* As seen in [1], the `Change` field doesn’t appear when overpaying with cash, even though it shows in the English version.

**Root cause:**
* The issue happens because changing the language translates the payment line name at [2] (coming from the translated return at [3]). This makes it get included in the sum at [4], which incorrectly subtracts it from the total cash paid and causes the change amount to disappear on the receipt.

**Solution:**
* Check and add up the payment lines where `is_change` is `false`, and use that instead of relying on the payment line’s name at [3].

**Before:**
<img width="830" height="556" alt="image" src="https://github.com/user-attachments/assets/5aaddfe0-fe46-49e1-a877-4fe4de2fb5c7" />

**After:**
<img width="931" height="596" alt="image" src="https://github.com/user-attachments/assets/4215d6b8-14b4-4e59-85bc-4d0f43f1d09c" />

[1]:
https://www.odoo.com/web/image/91240289?access_token=bef22d9abd1232e34f510648a34f7709d82b848ed852fccdb893f2d1149067abo0x69505fa6&filename=image.png&unique=dd2a62fbe180532cf5cf00c27adc60742f113ddc 
[2]:
https://github.com/odoo/odoo/blob/0581b7fb6abc8e856cedf13254ba1f9d362d6d34/addons/point_of_sale/static/src/app/models/accounting/pos_order_accounting.js#L146 
[3]:
https://github.com/odoo/odoo/blob/0581b7fb6abc8e856cedf13254ba1f9d362d6d34/addons/point_of_sale/models/pos_order.py#L188-L195 
[4]:
https://github.com/odoo/odoo/blob/0581b7fb6abc8e856cedf13254ba1f9d362d6d34/addons/point_of_sale/static/src/app/models/accounting/pos_order_accounting.js#L147

opw-5344903

**Steps to reproduce:**
1. Open database with version 19.0
2. Install module l10n_fr_hr_payroll_with_accounting
3. Set `Salary Journal` in: `Configuration` -> `Structure` -> `FR: Employe Carde` -> `Employe Carde`
4. In Payroll app create a payslip for any employee
5. In `structure` Employee cadre be choosen, And also
6. Make sure in salary inputs you make new type and in that in the
`availability in structure` has Employee cadre chosen.
7. Now with that Salary Input type click on `Compute sheet` button.
8. The `Invalid Operation` error card will appear.

**Description:**

After this changes in the [commit](https://github.com/odoo/enterprise/pull/100112/files) you will face another issue for which the steps are there in steps to reporduce.

In this [commit](https://github.com/odoo/enterprise/commit/bd2ee7546df3f31c73e8aaae0244ac6767f982fb#diff-5b26ac7c31dbf0286aa98671d7dadb50c117ea2ffb0d52d55a8f4e5d16d7ee88R709) Instade of `company_id` there is `company_20id`, which is not valid field. As in this code:
https://github.com/odoo/enterprise/blob/e29aadef1a81c662d9a4d33879b440dbe4390c0b/l10n_fr_hr_payroll/models/res_config_settings.py#L11 we can see that `company_id ` is set as related field for nombre_employes, so I have changed from `company_20id ` to `company_id`

**opw**: [5259362](https://www.odoo.com/odoo/project/70/tasks/5259362)

**Steps to reproduce:**
1. Install Inventory.
2. Open Inventory → Configuration
3. Barcode Nomenclature and select the default GS1 Nomenclature.
4. Open Barcode → scan the code:154105510000000244.

**Observation:**
- Scanning a GS1 barcode with an invalid date crashes Odoo and raises a traceback.

**Cause:**
- The translated ValidationError message uses the wrong interpolation syntax:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L58
and therefore fails during rendering.

- Correct syntax should be:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/account/models/account_move.py#L5647

**Fix:**
- Fix faulty interpolation placeholder in  ValidationError message to use `%(error_message)s` instead of `'%(error_message)'`, preventing the traceback and allowing the error message to display correctly.

**opw-5253564**

Forward-Port-Of: odoo/odoo#236858

**Steps to reproduce:**
* Install the **pos_sale** module.
* In **Settings**, enable the *Units of Measure & Packagings* option.
* Create two products, each using a different **Unit of Measure** (e.g., *Unit*, *Hours*),
and ensure both are available in POS.
* Open the **Sales** app and create a quotation including both products. Confirm the order.
* Open the **POS Store** and go to **Quotation/order** options , and select
*Created Sale Order* with the option **Settle the order**.
* Proceed to the payment screen and attempt to validate the payment.

**Observed behavior:**
* A **singleton error** is raised when validating the payment for a sale order
containing multiple lines with different UoMs.

**Cause:**
* The code incorrectly passes `self`, which may contain multiple sale order lines,
leading to a singleton expectation failure.

**Fix:**
* Pass a single sale order line to avoid the singleton error during payment validation.
---
opw-5251840

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

Currently, an error occurs when a user replaces a `combo product` with another 
product in a sale order line before the order is saved.

**Steps to produce:**

- Install the `sale_management` module with demo data.
- Open `sale order`, click `Add a product`, and add a `combo product` (Office Combo). 
  (`Make sure the form is not saved`)
- Click on the `combo name` (Office combo x 1) and replace it with another product.

**Error:**
`IndexError: tuple index out of range`

**Root cause:**
After PR [1], at [2], when a combo product is replaced before the order is
saved, the code attempts to update the combo item lines even though the
template type (`product_template_id.type`) is not `combo`. This leads to an
update of `product_uom_qty`, which triggers the `_compute_price_unit` method
and results in the error at [3].

**Fix:**
This commit prevents errors when a user replaces a combo product with another product.

[1]:
https://github.com/odoo/odoo/pull/194496

[2]:
https://github.com/odoo/odoo/blob/47e561bd1f6bc14724d60ebf09a66e458dfd4799/addons/sale/models/sale_order.py#L966-L970

[3]:
https://github.com/odoo/odoo/blob/c758b93a57cd98ab76c26c03bd0097f2eef50961/addons/sale/models/sale_order_line.py#L766

sentry-7009976704

### Issue:
During the loading of fiscal position data for LATAMs the option "Use Documents" on Journals is not set-up.

### Steps to reproduce:
- Install 'l10n_ar'
- Settings > Accounting
- Make sure the "Fiscal Localization" have a value (not Argentina)
- Change the "Fiscal Localization" to "Argentine - Generic Chart of Accounts [...]"
- Go in Accounting > Configuration > Journals
- Click on "Ventas Preimpreso"
- The journal don't have "Use Documents" ticked but it should

### Cause:
When loading the data, `_get_chart_template_data()` calls `_get_ar_base_res_company()` and `_get_latam_document_account_journal()`.

The first one returns the data to change `res.company.account_fiscal_country_id` to `base.ar`. The second one [checks](https://github.com/odoo/odoo/blob/26a5384af0af8fc6e6b5a10bea277f937e2b3481/addons/l10n_latam_invoice_document/models/account_chart_template.py#L12) that [`self.env.company.account_fiscal_country_id.code == "AR"`](https://github.com/odoo/odoo/blob/d985ec2e9b61b5e6c36a278654d526aaa5b512e2/addons/l10n_ar/models/res_company.py#L36) before returning the data to change `l10n_latam_use_documents` to `True`. As `res.company.account_fiscal_country_id` has not been updated, it's not Argentina during the check and `_get_latam_document_account_journal()` returns nothing.

### Solution:
When loading the template, we cannot use `res.company.account_fiscal_country_id` to know if we are in LATAM or not. So instead we check on `chart_template`.

opw-5221931

Forward-Port-Of: odoo/odoo#237725
Forward-Port-Of: odoo/odoo#236217

**Steps to reproduce:**
1. Install Inventory.
2. Open Inventory → Configuration
3. Barcode Nomenclature and select the default GS1 Nomenclature.
4. Open Barcode → scan the code:154105510000000244.

**Observation:**
- Scanning a GS1 barcode with an invalid date crashes Odoo and raises a traceback.

**Cause:**
- The translated ValidationError message uses the wrong interpolation syntax:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/barcodes_gs1_nomenclature/models/barcode_nomenclature.py#L58
and therefore fails during rendering.

- Correct syntax should be:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/account/models/account_move.py#L5647

**Fix:**
- Fix faulty interpolation placeholder in  ValidationError message to use `%(error_message)s` instead of `'%(error_message)'`, preventing the traceback and allowing the error message to display correctly.

**opw-5253564**

Forward-Port-Of: odoo/odoo#236858

In the Accounting app, users can print checks created to
pay Vendor Bills. When using any of the US Checks Layout (from
`l10n_us_check_printing`), the payment date would overlap
the table beneath it when the journal's manual sequencing option was
disabled.

<img width="1201" height="624" alt="image" src="https://github.com/user-attachments/assets/cd3aa46a-1952-4652-9034-e4bc2ea9a44d" />

This occured because the `.summary_line` container collapsed to a height
of 0 whenever its first child wasn't displayed, as the remaining child
elements are absolutely positioned and therefore do not contribute to
the parent's height.

https://github.com/odoo/enterprise/blob/f54585f84b0fa7a73efb3f0e14266972d510f0a6/l10n_us_check_printing/report/print_check.xml#L24-L34

By assigning a minimum height to the `.summary_line` class, we make sure
that it always occupies space above the table, even when only the date
is shown.

### Steps to reproduce:
**/!\ To reproduce the bug locally, you must have a version of wkhtmltopdf with patched qt. Use `wkhtmltopdf -V` and make sure that _"(with patched qt)"_ is specified after your wkhtmltopdf version.**
1. Install Accounting (`accountant`) and US Checks Layout (`l10n_us_check_printing`)
2. In Settings > Accounting, toggle on *Checks* if it is not, and set *Check Layout* to any "US" layout.
3. Go to Accounting > Vendors > Bills
4. Create a new Vendor Bill:
    - Set any Vendor
    - Set any Bill Date
    - Add any Product (with a positive price, the total price of the bill must be positive)
    - Confirm
5. Click *Pay*, set the *Payment Method* to *Checks* and click *Create Payment*
6. Click on the *Payments* smart button
7. Click *Print Check* > *Print* (> *Continue*)
8. In the generated PDF, the date overlaps the table beneath it.

This fix moves the date right above the table.

<img width="1189" height="634" alt="image" src="https://github.com/user-attachments/assets/8858098e-b39b-4ad2-aa65-cc0cea550343" />


opw-5165112

Forward-Port-Of: odoo/enterprise#100487

This improvement enhances user control over cookie preferences by making
the Cookie Policy page (/cookie-policy) more accessible and allowing
users to modify their consent at any time.

**Issue:**

- Previously, the only way to access the Cookie Policy page was through
  the link in the cookie consent popup. However, once users accepted
  cookies, the popup was no longer displayed, making it impossible to
  navigate to the policy page later.

- Additionally, the Cookie Policy page had a button to reopen the cookie
  consent popup, but it was only visible if cookies were not accepted.
  Once cookies were accepted, the button was hidden, preventing users
  from changing their preferences.

**Improvements:**

- Added a permanent link to the Cookie Policy page in the copyright
  footer, ensuring it remains accessible at all times.

- The cookie consent toggle button now remains visible even after a user
  has accepted cookies, allowing them to update their preferences at any
  time.

task-[4502416](https://www.odoo.com/odoo/project/974/tasks/4502416)