*: mrp_subcontracting

Issue:
---------------------------------
When subcontracting a lot/serial-tracked product and generating multiple subcontracting MOs by generating SN numbers or the "Create New Production" action, only the `first serial number line` appears in the "Move" detail operations smart button.
Although all move lines are correctly created on the move, this behaviour is confusing for the user.

Steps to reproduce:
---------------------------------
1. Install the `mrp_subcontracting_purchase` module.
2. Create a serial-tracked product and its subcontracting BoM.
3. Create a PO with a subcontracting vendor and a product quantity greater than 1.
4. Confirm the PO and validate the resupply.
5. Open the receipt and click on the "Subcontracting Production" smart button.
6. Generate serial numbers for the product.
7. Validate the receipt and open the "Move" detail operations smart button.
8. Only one line (the first serial number) is shown, while the move actually contains all move lines.

Cause:
---------------------------------
When serial numbers are generated from the subcontracting MO view, or when a new MO is created using the "Create New Production" action introduced in [PR](https://github.com/odoo/odoo/pull/218377), new move lines are created without setting the `picking_id`.
As a result, these move lines are linked to the stock move but not directly to the picking.
Since the "Move" detail operations smart button relies on the picking’s `move_line_ids`, the newly created move lines are not displayed.

With this commit:
---------------------------------
The `picking_id` is now set on newly created move lines. This ensures that all move lines are directly linked to the picking, allowing the "Move" detail operations smart button to display all serial/lot lines correctly and improving traceability for the user.

And also When working with a subcontracting order, if the user opens the lot/serial number generation wizard from the subcontracting production and directly clicks 'Apply' without creating or assigning any lot/serial number, Odoo raises the following traceback:
`IndexError: tuple index out of range`
This issue has also been fixed here.

Forward-Port-Of: odoo/odoo#243988

Fix 1:
-------
Using the early receipt printing option leads to a traceback when using the italian fiscal printer.

Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: Traceback

Why the fix:
------------
Initially the traceback is related to trying to read `decimal_places` out of undefined. The current order doesn't have yet a currency.

To solve this initial issue we can just take the currency of the config if there's none on the order. The pos does not handle multicurrency so the order will always have the same currency as the config anyway.

After solving this part another issue would still happen. If the order was no sent to the kitchen yet. Such orders are not yet synced to the backend and do not have an id of type number. If the order had been send to the display.

This scenario was sending the printer, the data to print and with a successful print we were trying to sync data to the server with
```
await this.data.write("pos.order", [order.id], updateData);
```
which was triggering an error in `orm_services` with `validatePrimitiveList`.
> Invalid ids list: pos.order_4

If we try to reprint AGAIN the bill for some reason, we get another traceback. It's because the nb_print is now 1 and therefore we now try to print with
```
printResult = await this.fiscalPrinter.printContentByNumbers({
    order: order,
});
```
which will try to split undefined here
```
this.receiptNumber = this.props.order.it_fiscal_receipt_number;
const dateParts = this.props.order.it_fiscal_receipt_date.split("/");
```

Those two last issues are solved by not syncing the data to the server when we simply print the bill early.

-------
-------
Fix 2:
-------
Currently the early printing option does not work as desired. The fiscal printer does not print the receipt.

Steps to reproduce:
-------------------
* Setup the italian fiscal printer for a restaurant
* Enable Early Receipt printing
* Open restaurant
* Open a table, add an item to cart
* Try the early print option
> Observation: the printer stops in the middle of printing the receipt

Why the fix:
------------
The early receipt was trying to be printed as a fiscal document. However it cannot be considered as such.

We backport this fix that enables basic receipt printing and alter it to also work with early printing.

Fix being backported: https://github.com/odoo/enterprise/commit/b8fd13b802729ccee080ab14f2958d59f57d0f97

There are a few differences between the early receipt and the basic print, mainly the fact that prices need to be shown on the early receipt.

There are a few differences with the original commit. In the documentation of the printer, `printNormal` uses data and the original commit mixes between `data` and `message` so it is harmonized here.

opw-5387572


Results:
-----------
Basic receipt:
<img width="672" height="835" alt="image" src="https://github.com/user-attachments/assets/3de96523-22db-4a27-adbd-3464802604aa" />

Early receipt:
<img width="658" height="842" alt="image" src="https://github.com/user-attachments/assets/f6b7ab24-e27b-4deb-8d5f-1b0c41bb28f0" />

Forward-Port-Of: odoo/enterprise#108161
Forward-Port-Of: odoo/enterprise#105511

Currently, when a user tries to print a resume with an invalid template there’s no traceback to show what went wrong.

**Steps to produce:**
* Install `hr` with demo data
* Modify the view `report_employee_cv`  by adding `<div t-if=o.no/>`
* Print resume of any employee

**Observed Behavior:**
Currently it only shows the error in [1], with no context or traceback to explain what went wrong.

**Root cause:**
* This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6].

**Solution:**
* Catching and raising UserError shows appropriate traceback.

**Before:**
<img width="1606" height="796" alt="image" src="https://github.com/user-attachments/assets/d5432fbf-d016-46a9-bade-8e8408848c66" />

**After:**
<img width="1832" height="928" alt="image" src="https://github.com/user-attachments/assets/6f0413ca-a82a-487d-888f-81be6f0fab03" />

[1]:
https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing 
[2]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 
[3]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 
[4]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 
[5]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 
[6]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575
Related: https://github.com/odoo/enterprise/pull/100142

opw-5167898

Forward-Port-Of: odoo/odoo#250286
Forward-Port-Of: odoo/odoo#237262

Currently, when a user tries to print a PDF report with an invalid document layout template, there’s no traceback to show what went wrong.

**Steps to produce:**
* Install payroll with demo data.
* Settings > Configure Document Layout then Edit Layout
* Add non-existent field `<div t-if='o.no'/>`
* Payroll > All payslips > print any payslip

**Observed Behavior:**
* Currently it only shows the error in [1], with no context or traceback to explain what went wrong.

**Root cause:**
* This happens because the route doesn’t include the website parameter. Without it, the system treats the route as non–front end [2], so the error handler never reaches [3].That means [4] never loads the templates [5], and the browser just gets a plain response at [6].

**Solution:**
* Catching and raising UserError shows appropriate traceback.

**Before:**
<img width="1601" height="507" alt="image" src="https://github.com/user-attachments/assets/f7f208f0-cdd7-410e-87e7-32a9651df9d8" />

**After:**
<img width="1847" height="928" alt="image" src="https://github.com/user-attachments/assets/c73522d6-2632-422b-b1d1-234e6c61ed2e" />

[1]:
https://drive.google.com/file/d/1qJLkFGw4bEclqKihdUI-4bjJofdFArEc/view?usp=sharing 
[2]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L386 
[3]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L611 
[4]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L573-L576 
[5]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/views/http_routing_template.xml#L139 
[6]:
https://github.com/odoo/odoo/blob/e4e2dca73213c33c487033dd404a7ca335960a66/addons/http_routing/models/ir_http.py#L575
Related:https://github.com/odoo/odoo/pull/237262

opw-5167898

Forward-Port-Of: odoo/enterprise#108438
Forward-Port-Of: odoo/enterprise#100142

Clicking the Work Entries smart button raises a traceback when an overtime record has no Stop (time_stop).

Steps to reproduce the error:
- Install ``hr_work_entry_attendance`` module with demo data
- Activate developer mode
- Create an Employee A > Settings > Set Default Ruleset in Overtime Ruleset
  In Payroll Tab, Work Entry Source: ``Attendances`` and set Contract
- Create an overtime attendance > Save > Open the Overtime Details > Unset the ``Stop(time_stop)`` > Save
- Open Employee A > Click on Work Entries smart button

Traceback:
```py
TypeError: '<' not supported between instances of 'bool' and 'datetime.datetime'
```

https://github.com/odoo/enterprise/blob/56c3723a925f718ba39d11cde12933542ebcd7c1/hr_work_entry_attendance/models/hr_version.py#L49-L52
When ``stop(time_stop)`` is unset in the overtime,
``ot.time_stop`` is False,
causing ``min()`` to compare a ``datetime`` with ``False``, which raises the above traceback.

sentry-7169332615

Forward-Port-Of: odoo/enterprise#103764

### Steps to reproduce the bug:
- Install mrp
- Go to manufacturing app
- Go to products -> bills of materials
- Create a new bill of material for a product
- Go to the operations tab
- No 'copy existing operations' button appears if at least one operation
 is already created

### The problem:
In version 19.0, the "Copy Existing Operations" button is missing from
the BoM operations tab when no operations have been defined yet for the
current BoM. While this feature was fully functional in version 18.4,
it became inaccessible in 19.0 to users due to a UI reorganization
introduced in commit https://github.com/odoo/odoo/commit/80e6ed658fb43584bc2fad673ca40d9af6cf0ab6 that accidentally omitted the "Copy
Existing Operations" button. Currently, users are forced to manually
create at least one operation before they can see the option to copy
from other BoMs.

### The reason to introduce the fix:
The ability to copy operations is useful also when starting with an
empty BoM if operations in other BoM's have been already created. Since
this fix has already been implemented in version 19.1 via commit https://github.com/odoo/odoo/commit/02e837c959381523170c653da099328e9855a4e4,
this PR backports that changes to 19.0 to restore feature parity and
improve the user experience.

opw-5906667

Forward-Port-Of: odoo/odoo#250411
Forward-Port-Of: odoo/odoo#248225

**Steps to reproduce:**
- Create a DB with l10n_ar and l10n_ar ecommerce
- Go to Settings > Invoicing > Fiscal Localization
- Select the 'Argentina - Argentine Generic Chart of Accounts for Registered Accountants' package
- Create a website, and a portal user
- Add a main and a secondary address to the user using the website form in 'My Account'
- Go to the secondary address and change any field
- Click on Save Address
- Multiple errors will appear on the form (reproducible with other similar config)
(and in logs: `UserWarning: unsupported operand type(s) for "==": 'l10n_latam.identification.type()' == '1'`)

**Issue:**
In `address_form_fields` some hidden input field are used to add specific non-editable values to the forms.

This breaks the address validation of `CustomerPortal` in `def _validate_address_values` due to the following comparison: `partner_sudo[commercial_field_name] != address_values[commercial_field_name]`
which try to compare recordsets with the given ids.

**Fix:**
Cast relational field to their id values to ensure they can be properly compared to the website form values.

related fix which introduces the input issue: https://github.com/odoo/odoo/commit/0ee91631214c34b650342a0210ee8db27764f252

opw-5247171

Forward-Port-Of: odoo/odoo#244532

__Before commit__
When using `makeButtonHandler`, a loading effect is applied to the
button if the handler takes more than 400ms to execute. However, if
the handler finishes sooner, the effect is still briefly added and
removed, triggering a DOM mutation.

If a button is clicked and the website builder opens immediately
after, this mutation may be recorded in the current history step
despite being unnecessary.

This causes the `design-themes` tour `theme_menu_hierarchies` to fail
in a non-deterministic way with the following warning:
"should not have any 'characterData', 'remove' or 'add' mutations in
current step when you update the selection"

__Fix__
Ensure the loading effect is never added if the handler execution
time is shorter than the debounce duration.

This fix is applied to both `makeButtonHandler` functions in the
codebase. The test case is only added for the interaction use case,
as the other instance resides in legacy code.

runbot-229803

Forward-Port-Of: odoo/odoo#248242

Before this commit, the following discuss call test may fail non-deterministically:

```
@mail/discuss/call/call/auto-focus participant video in one-to-one call in chat window
```

This happens at the step where it checks that when inside the discuss meeting view, having another participant enable a video stream does not auto-focus the card.

The test was failing and auto-focusing the card because the simulated toggling of enabling the video stream happens before the side-effect of rendering to toggle the flag that meeting view is on. So the handling of event that video stream is toggled on was mistakenly considering outside of meeting view.

This commit fixes the issue by awaiting a `data-active` on the UI if meeting view, which ensures the rendering of meeting view is complete and store is aware of meeting view being open, before triggering the event that simulates toggling of video stream. This technique is borrowed from `DiscussApp` component that requires a similar technique to determine whether a chat window must auto-open or not, which also requires making sure the store knows precisely when `DiscussApp` is logically open.

Fixes runbot-error-240554

Forward-Port-Of: odoo/odoo#250174

### Steps to detect the bug:
  - Download stock apps
  - Enable "storage locations" settings under warehouse index
  - Change name of warehouse with a name composed only of numbers (ex. 01)
  - Create a product (with barcode number)
  - Insert a number of products available with smart button "on hand"
  - Create a new delivery for that product
  - Go to barcode app and search for the delivery you just created
  - Click on it and see that the name of the warehouse will be stock/01 instead of the correct 01/stock
    
### The problem:
The previous configuration used direction: rtl; on the warehouse name
element in the barcode app. So if the string contains only letters the
standard visual order is maintained, however, when the string consists
entirely of numbers the rtl property forces the browser to reorder them
from right to left.

### The reson to introduce the fix:
By removing this property, it is ensured that numerical warehouse codes are displayed in their natural sequence without being flipped.
    
opw-5730199

Forward-Port-Of: odoo/enterprise#107920

Steps to reproduce
------------------

1. Enable Units of Measure and Automatic Valuation.
2. Create:
  Product KIT, stockable, UoM category Unit, UoM = Units.
  BoM for KIT with at least one component whose UoM is in a different
     category (e.g. m from Length).
3. Go to the product's category and set the Costing Method to Average
   Cost (AVCO) and the Inventory Valuation to Automated.
4. Create a PO for KIT in a currency different from the company currency.
5. Confirm the PO and validate the receipt.

Issue
-----

Validating the receipt raises:

> The unit of measure m defined on the order line doesn't belong to the
> same category as the unit of measure kit defined on the product…

If you keep the PO currency equal to the company currency, the same kit
and BoM work and the receipt posts correctly.

Cause of the issue
------------------

Validating the receipt will call the `_action_done` of stock.move's and generate the related accounting entries. During this call and the currency of the PO is different from the company currency the `_generate_valuation_lines_data` will call the `_get_currency_convert_date` method:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L134-L140
This call will in turn call the `_get_qty_received_without_self`:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L121-L122
which was not written to handle kit products since it assumes that the product of the PO is the same as the one of the related move:
https://github.com/odoo/odoo/blob/751d54207c6214a25a5a1def57137e2f2f9106e3/addons/purchase_stock/models/stock_move.py#L102-L108

Fix
---

The qty_received is relevant to the _get_currency_convert_date as the method compares the qty_invoiced with the qty_received to determine whether to use the Invoice Date (when qty_invoiced > qty_received) or the Receipt Date.

https://github.com/odoo/odoo/blob/888e086dc6c7823b07993e90f70e2849e988fa7a/addons/purchase_stock/models/stock_move.py#L122-L126

  For kits, `qty_received` must be calculated by aggregating component
  moves to accurately determine this status. Since the standard logic
  crashes due to UoM mismatch, the override in `purchase_mrp` is
  necessary to provide the correct quantity for this date selection.

opw-5030761

Forward-Port-Of: odoo/odoo#248883
Forward-Port-Of: odoo/odoo#236276

__

## Short functional explanation of the error
Let's say we create a role containing employees with fixed schedules. Then, we create a shift template that applies on this role. When we create a shift, the starting and ending hours will take into consideration the hours of the employee's fixed schedule, instead of aligning with the shift template start and end hours.

As discussed with XBO, the start and end hours of the shift should align with the shift template, despite the fixed working schedules having different start and end hours.

## Reproduction Steps
1. Go to Planning. Click on Configuration tab > roles.
2. Create a role and add an employee as a resource This employee has to have a fixed working schedule.
3. Click on Configuration tab > Shift Templates.
4. Create a new Shift Template. Select starting and ending hours different from the employee's fixed schedule. Select the role you just created.
5. Click on Schedule tab > By resource and click on New.
6. Select the role you just created.

### Expected behavior
The start and end hours should align with the shift template start and end hours.

### Unexpected behavior
The start and end hours are aligned on the employee's fixed working schedule: if the employee has a schedule from 8 to 16h36 and the shift template goes from 10 to 18, the starting and ending hours will be 10 to 16h36.

## Origin of the issue
We kept computing the working intervals of employees, even if a shift template was set:
https://github.com/odoo/enterprise/blob/8b00363e5e461f11b9736354d94e520e21932e71/planning/models/planning.py#L656-L664 Which isn't necessary in the case where a shift template has been set, as the start and end time are determined by the shift template, and not the employee's schedule.
__
opw-5898509

Forward-Port-Of: odoo/enterprise#108187
Forward-Port-Of: odoo/enterprise#107018

To reproduce
-------------
1. Install `l10n_es_edi_verifactu_pos`, and select the ES company
2. Make an order in PoS with a price less than 400, and don't invoice it.
3. Close the PoS session, then go to PoS > Orders, and select the previously made order
4. It will have a Verifactu generated document with invoice type as 'F2', which is correct since it's a simplified order.
5. Click invoice to invoice the order; the invoice is no longer simplified.

Notice now that the new Verifactu document has an invoice type of 'F1', which corresponds to a normal non simplified invoice. However, since the new invoice is replacing an old simplified one, it should be of type 'F3' instead.

The fix
-------
When fully invoicing, we check if the order had a linked Veri*factu document of type F2, which means we are now replacing it and should set the type of the new invoice to F3 instead of F1.

Sources:
--------
Difference between 'F1', 'F2', and 'F3' invoice types: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html?faqId=bdbd20022fe06910VgnVCM100000dc381e0aRCRD

opw-5343973

Forward-Port-Of: odoo/odoo#242274

1. Create a contact (with minimal details).
2. Create a customer invoice for that contact **last month** with `quantity = 300`.
3. Create a credit note for that invoice **this month**.
4. Create another customer invoice for the same contact **this month** with `quantity = 100`.

In the FAIA report (XML), within the General Ledger section, the partner is incorrectly classified as a supplier instead of a customer.

In the method _saft_fill_report_partner_ledger_values from account_saft, he partner type is determined based on whether the balance is negative.

However, a negative balance can result from a credit note, where the partner is still a customer and not a supplier. Furthermore, a partner can be both a supplier and a customer.

This commit allows a partner to be both a customer and a supplier. If both receivable and payable are 0 we set the partner type to customer to keep the behavior from e9640caf29e967fe7d8c6fe303b5a8d7a866437e

opw-5360924

Forward-Port-Of: odoo/enterprise#106559
Forward-Port-Of: odoo/enterprise#100749

**Steps to reproduce:**
- Create a DB with l10n_ar and l10n_ar ecommerce
- Go to Settings > Invoicing > Fiscal Localization
- Select the 'Argentina - Argentine Generic Chart of Accounts for Registered Accountants' package
- Create a website, and a portal user
- Add a main and a secondary address to the user using the website form in 'My Account'
- Go to the secondary address and change any field
- Click on Save Address
- Multiple errors will appear on the form (reproducible with other similar config)
(and in logs: `UserWarning: unsupported operand type(s) for "==": 'l10n_latam.identification.type()' == '1'`)

**Issue:**
In `address_form_fields` some hidden input field are used to add specific non-editable values to the forms.

This breaks the address validation of `CustomerPortal` in `def _validate_address_values` due to the following comparison: `partner_sudo[commercial_field_name] != address_values[commercial_field_name]`
which try to compare recordsets with the given ids.

**Fix:**
Cast relational field to their id values to ensure they can be properly compared to the website form values.

related fix which introduces the input issue: https://github.com/odoo/odoo/commit/0ee91631214c34b650342a0210ee8db27764f252

opw-5247171

Forward-Port-Of: odoo/odoo#244532

__Before commit__
When using `makeButtonHandler`, a loading effect is applied to the
button if the handler takes more than 400ms to execute. However, if
the handler finishes sooner, the effect is still briefly added and
removed, triggering a DOM mutation.

If a button is clicked and the website builder opens immediately
after, this mutation may be recorded in the current history step
despite being unnecessary.

This causes the `design-themes` tour `theme_menu_hierarchies` to fail
in a non-deterministic way with the following warning:
"should not have any 'characterData', 'remove' or 'add' mutations in
current step when you update the selection"

__Fix__
Ensure the loading effect is never added if the handler execution
time is shorter than the debounce duration.

This fix is applied to both `makeButtonHandler` functions in the
codebase. The test case is only added for the interaction use case,
as the other instance resides in legacy code.

runbot-229803

Forward-Port-Of: odoo/odoo#248242

Currently, an error occurs when user tries to validate a domain with no field name.

Steps to install:
- Install `sale_management` > Open sale order list view > Turn on debug mode.
- Click on search bar > Custom filter > Click on field and remove its field name written below the list of fields.
- Click validate.

Error:
```
TypeError: Empty field name in condition ('', '=', 1)
```

Cause:
- As the field name was emptied by the user the [line] will raise a TypeError during the domain validation.
- Till `19.0` any error during domain validation was handled  through [here] which was later changed to handle only ValueErrors through this [commit].

Solution:
- Handled TypeErrors during domain validation.

[line]: https://github.com/odoo/odoo/blob/260b9c0417ed2278429fcdd7f50d61786d4e9beb/odoo/orm/domains.py#L841

[here]: https://github.com/odoo/odoo/blob/a220fb71c036c93fa1e75d4d37127e5eda0118f9/addons/web/controllers/domain.py#L34

[commit]: https://github.com/odoo/odoo/commit/a1434c32e9f4dd226d512677fd96e3051b908d8b#diff-e5da86414a8020b2843fb359453238e4977027d30f73f1fa792ca63ddd8fa2a7L34-R23

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

### Steps to detect the bug:
  - Download stock apps
  - Enable "storage locations" settings under warehouse index
  - Change name of warehouse with a name composed only of numbers (ex. 01)
  - Create a product (with barcode number)
  - Insert a number of products available with smart button "on hand"
  - Create a new delivery for that product
  - Go to barcode app and search for the delivery you just created
  - Click on it and see that the name of the warehouse will be stock/01 instead of the correct 01/stock
    
### The problem:
The previous configuration used direction: rtl; on the warehouse name
element in the barcode app. So if the string contains only letters the
standard visual order is maintained, however, when the string consists
entirely of numbers the rtl property forces the browser to reorder them
from right to left.

### The reson to introduce the fix:
By removing this property, it is ensured that numerical warehouse codes are displayed in their natural sequence without being flipped.
    
opw-5730199

Forward-Port-Of: odoo/enterprise#107920

In the `industry_fsm_report` and `quality_control_worksheet` modules, worksheet fields created during onboarding was moved from XML to Python (https://github.com/odoo/enterprise/commit/d619aa4d0d042be3f899b777081b7fb90f851c84). They were noupdate=1 before moving to Python ([quality_control_worksheet](https://github.com/odoo/enterprise/blob/d619aa4d0d042be3f899b777081b7fb90f851c84/quality_control_worksheet/data/quality_worksheet_demo.xml#L3), [industry_fsm_report](https://github.com/odoo/enterprise/blob/d619aa4d0d042be3f899b777081b7fb90f851c84/industry_fsm_report/data/fsm_report_demo.xml#L3)).

The issue is without this patch, the dbs which loaded those fields in version `19.0` will have referencing xmlid, with noupdate=0. On the other side as they do not have record in xml files, during the upgrade to > 19.0 it will introduce an issue like this:

```
odoo.upgrade.util.exceptions.UpgradeError: 💥 It looks like you forgot to call `util.remove_field` on the following fields: x_project_task_worksheet_template_2.x_worker_signature
2026-02-15 20:17:38,149 23 INFO db_3904048 odoo.service.server: Initiating shutdown
```

tbg-2468

Forward-Port-Of: odoo/enterprise#108276

To reproduce
-------------
1. Install `l10n_es_edi_verifactu_pos`, and select the ES company
2. Make an order in PoS with a price less than 400, and don't invoice it.
3. Close the PoS session, then go to PoS > Orders, and select the previously made order
4. It will have a Verifactu generated document with invoice type as 'F2', which is correct since it's a simplified order.
5. Click invoice to invoice the order; the invoice is no longer simplified.

Notice now that the new Verifactu document has an invoice type of 'F1', which corresponds to a normal non simplified invoice. However, since the new invoice is replacing an old simplified one, it should be of type 'F3' instead.

The fix
-------
When fully invoicing, we check if the order had a linked Veri*factu document of type F2, which means we are now replacing it and should set the type of the new invoice to F3 instead of F1.

Sources:
--------
Difference between 'F1', 'F2', and 'F3' invoice types: https://sede.agenciatributaria.gob.es/Sede/iva/sistemas-informaticos-facturacion-verifactu/preguntas-frecuentes/procedimientos-facturacion.html?faqId=bdbd20022fe06910VgnVCM100000dc381e0aRCRD

opw-5343973

Forward-Port-Of: odoo/odoo#242274

Steps to reproduce:
1. Setup an employee with a bank account where the account holder is different from the employee (e.g., a spouse).
2. Generate a payslip for this employee.
3. Print the payslip (PDF) or generate a payment export (SEPA, NACHA, ABA, CSV).
4. Observe that the employee's name is displayed instead of the account holder's information.

Issue:
Payroll reports and payment exports were frequently hardcoded to use the employee's legal name or work contact ID. This is incorrect when a bank account belongs to a different partner, as payment records should reflect the actual account holder.

Solution:
Unified logic across standard and localized payroll modules (AU, BE, CH, IN, SA, US) to prioritize the bank account's linked partner:
- Updated QWeb templates to display bank.partner_id.name for account allocations.
- Modified payment wizards (CSV, NACHA, ABA, SEPA) to use the bank account's partner ID.
- Ensured a fallback to the employee's legal name remains in place.

opw-5357652

Forward-Port-Of: odoo/enterprise#106718

Problem:
-------
In several scenarios, Worked Days are incorrectly computed when the employee
has no contract or when the contract does not fully overlap with the payslip
period.

Case 1:
- Create an employee without a contract
- Create a payslip for this employee for the current month:
You'll see X days of attendance (= today until the end of the payslip period)
and Y days of out of contract (= number of days from the start of the payslip period until today)
- Create a payslip for this employee for the previous month:
you'll see ( Z_prev + Y )  days out of contract ( Z_prev = number of working days in the previous month)
- Create a payslip for this employee for the next month:
you'll see Z_next days of attendance (Z_next = number of working days in the next month)

Case 2:
- Create a new employee with a contract starting during the current month
- Create a payslip for this employee for the previous month
- Out-of-Contract days are incorrectly computed as:
  contract_start_date - previous_month_start.

Case 3:
- Create an employee with a contract ending during this month
- Create a payslip for this employee for the next month
- Out-of-Contract days are incorrectly computed as:
  next_month_end - contract_end_date.

Solution:
--------
When generating work days lines:
- Explicitly handle employees without a contract.
- Use adjusted date bounds when the contract does not overlap the payslip
  period.

Several tests were added to cover these scenarios, as well as the tests the corresponding commit
in odoo/odoo (PR odoo: 241978)

task-5430759

When scaning a lot after a packaging, the lot won't recognize the packaging and will not work properly

### Steps to reproduce:

* In the settings enable packagings
* Create a storable product P with Units as uom, a barcode and tracked by lots
* Create new lots with barcode for Product P
* Inventory > Configuration > Product > Units & Packagings
* Click on pack of 6 > Packaging Barcodes > New
* Create one for your product with a different barcode
* Go to barcode > Operations > eg. internal transfer > New
* Scan packaging barcode
* Scan one of the lots
-> Issue, the lot create a new line, and will not find the packaging

### Observation:

When scanning a barcode, it will first try to find a match with existing lines,
In our case, it will find a match with the line of the packaging, but since the line is considered as "completed" since there was no expected quantity since we create a new picking:
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_picking_model.js#L1497-L1501
It will erase the line, to avoid to overfill a completed line:
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1459-L1460
and since, it decided to ignore that line, it will not find another lines, and will create a new one :
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1535

Additional Issues
-----------------
Issue 1 : When scaning a packaging, lot1, packaging, lot2, all the packagings will be linked to the first lot, which doesn't allow us to scan multiple lots.
Issue 2 :  When having sublines with different uoms, it will add the quantity without considering the differences in uoms

### Steps to reproduce:

* In the settings enable packagings
* Create a storable product P with Units as uom, a barcode and tracked by lots
* Create new lots with barcode for Product P
* Inventory > Configuration > Product > Units & Packagings
* Click on pack of 6 > Packaging Barcodes > New
* Create one for your product with a different barcode
* Create a packaging 2 with barcode for product A
* Go to barcode > Operations > eg. internal transfer > New
* Scan packaging 1 barcode
* Scan one of the lot 1
* Scan packaging 1
* Scan lot 2
-> Issue 1, the packaging 2 will be link to lot 1, it won't be possible to link any packaging to another lot.
* Scan packaging 2
-> Issue 2, it create a subline (excpeted), but the sum that appear on the main grouped line is wrong, it doesn't considere the difference in uoms

### Observation:
Issue one :
When scanning a barcode, it will first try to find a match with existing lines, since the uom is the same it will not be erased by the full line check
https://github.com/odoo/enterprise/blob/13d815457d47846d5391c9a2dc1ed244ef64b6c4/stock_barcode/static/src/models/barcode_model.js#L1456-L1460
and since, it found a line, it will just add it's self to the line

Issue Two:
When creating the group lines it will first calculate the sum of all the quantities:
https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_model.js#L248-L254
And after inside of groupSublines it will choose the main line and it's uom and use the previous sum for the total quantity:
https://github.com/odoo/enterprise/blob/8774388a7b1b2ca2c08c752026ac1a20dbc10347/stock_barcode/static/src/models/barcode_picking_model.js#L1456-L1461

opw-5189492
opw-5408372

Forward-Port-Of: odoo/enterprise#108214
Forward-Port-Of: odoo/enterprise#98701

**Steps to Reproduce:**
1 - create an employee in Belgium company with hourly rate 20.62 and 40h/week working schedule 2 - Set 10 paid time off to this employee
3 - Set 2000 euros in recovery amount holiday n-1
4 - Set 10 days in recovery day holiday n-1
5 - Employee takes 5 paid time off in February and 5 in December 6 - Do one payslip for this employee for February  and validate it 7 - Do one payslip for this employee for December

Current behaviour :
- the holiday n-1 amount for February = 824.80
- the holiday n-1 amount for December = 742.32

Expected behaviour :
- the holiday n-1 amount for December should be 20.62 (hourly_rate) * 5 (days) * 8 (hours) = 824.80

**Reason**
- The daily recovery amount was calculated using hardcoded standard working hours (38h/week) instead of the employee's actual schedule (40h/week), causing an incorrect deduction rate for non-standard schedules.

**Solution**
- Replace the hardcoded reference with the actual hours per week from the employee's resource calendar to ensure the correct hourly rate is applied.

Forward-Port-Of: odoo/enterprise#107941
Forward-Port-Of: odoo/enterprise#106205

### Steps to detect the bug:
  - Download stock apps
  - Enable "storage locations" settings under warehouse index
  - Change name of warehouse with a name composed only of numbers (ex. 01)
  - Create a product (with barcode number)
  - Insert a number of products available with smart button "on hand"
  - Create a new delivery for that product
  - Go to barcode app and search for the delivery you just created
  - Click on it and see that the name of the warehouse will be stock/01 instead of the correct 01/stock
    
### The problem:
The previous configuration used direction: rtl; on the warehouse name
element in the barcode app. So if the string contains only letters the
standard visual order is maintained, however, when the string consists
entirely of numbers the rtl property forces the browser to reorder them
from right to left.

### The reson to introduce the fix:
By removing this property, it is ensured that numerical warehouse codes are displayed in their natural sequence without being flipped.
    
opw-5730199

Forward-Port-Of: odoo/enterprise#107920

*:ae,au,bd,be,ch,eg,id,jo,ke,lt,lu,ma,my,nl,pk,pl,ro,sk,tr,us

When the ``Standard 40 hours/week`` working schedule is deleted
and the ``Payroll: Update data`` cron runs, a traceback is raised.

For ``l10n_us_hr_payroll`` module
Steps to reproduce the error:
- Install ``l10n_us_hr_payroll`` module with demo data
- Go to Employees > Configuration > Settings > Change Company Working Hours
- Go to Working Schedules > Delete ``Standard 40 hours/week`` working schedule
- Run the ``Payroll: Update data`` cron

Traceback:
```py
ValueError: External ID not found in the system: resource.resource_calendar_std

ParseError: while parsing /home/odoo/src/enterprise/l10n_us_hr_payroll/data/hr_payroll_structure_type_data.xml:3, somewhere inside <record id="structure_type_employee_us" model="hr.payroll.structure.type">
    <field name="name">United States: Employee</field>
    <field name="default_resource_calendar_id" ref="resource.resource_calendar_std"/>
    <field name="country_id" ref="base.us"/>
</record>
```

The ``Payroll: Update data`` cron updates payroll data that references
the ``Standard 40 hours/week`` working schedule.
If the user has deleted this working schedule, the external ID no longer exists,
leading to the above traceback.

sentry-7166574553

**Problem:**
When users in debug mode manually add the planning report action through Settings/Technical/Reports and then print from the list or form view, they receive a blank/invalid PDF report.

**Steps to reproduce:**
1. Go to Settings app and enable debug mode
2. Navigate to Technical → Reports
3. Search for "slot_report"
4. Click "Add to print menu" button
5. Refresh the browser
6. Go to Planning app and switch to list view
7. Select a few planning.slot records
8. Click Print → Planning

**Current behavior:**
A blank or invalid PDF is generated.

**Expected behavior:**
Users should receive a clear error message directing them to use the correct print method from the calendar view.

**Cause of the issue:**
The planning report requires a pre-processed data structure (weeks, grouped slots per day/week, and group-by mappings) that is only prepared by the action_print_plannings() method called from the custom Print button in the calendar view. The standard print menu invokes _render_qweb_pdf() directly without this data preparation, and there is no mechanism to pass this complex data structure through the standard print workflow. This results in the template receiving empty data contexts, producing blank reports.

**Fix:**
Block the planning report from being printed through _render_qweb_pdf() when called without the proper data context. This is done by checking if the report name is 'planning.slot_report' and raising a UserError with a clear message directing users to use the Print button in the calendar view instead. This prevents the generation of invalid reports while guiding users to the correct workflow that properly prepares the required data.

opw-5477184

[FIX] account_reports: journal audit tax display

**Problem:**
The tax summary tables in the Journal Audit report overflow and collide
when displaying large monetary amounts (9+ digits).

**Steps to reproduce:**
1. Create and post invoices/bills with large amounts (e.g. 999,999,999)
2. Go to Accounting > Reporting > Audit Reports > Journal Audit
3. Observe the tax summary tables overflow their columns

**Current behavior:**
Large numbers overflow and collide because the sub-tables use
`table-layout: fixed` and are placed in separate `<td>` elements with
hardcoded `colspan`, preventing them from adapting to content width.

**Expected behavior:**
The tax summary tables should adapt their widths to accommodate large
monetary amounts without overflow or collision.

**Cause of the issue:**
Several layout issues combined to waste space and cause overflow:
- The sub-tables were in separate `<td>` elements with fixed `colspan`
  values (2 and 5), unrelated to actual content width
- `table-layout: fixed` forced thin columns (e.g. country code) to take
  equal space as wider columns (amounts), causing larger values to
  overflow
- The "Taxes Applied" header colspan used `taxesByCountry.length` which
  doesn't work on objects (always undefined), so the header never
  spanned the full width in multi-country scenarios
- Full country names (e.g. "United States") consumed unnecessary
  horizontal space
- Long tax names (common with OSS) wrapped to multiple lines, making
  the table very tall

**Fix:**
By placing both sub-tables inside a single `<td>` with a flex container,
they can share the available width dynamically based on content rather
than being constrained by arbitrary colspan splits. Removing
`table-layout: fixed` lets columns size naturally to their content.
Using country codes instead of full names and adding ellipsis on long
tax names further reduces the space pressure.

Backport of: ba8099ab7bad7a7a9fe445ed6fda8c4daa7abcbd

opw-5477029

**Steps to reproduce:**
- Install 'account_iso20022', 'l10n_ch' and switch to a Swiss company
- Have a bank with a BIC number and an account for that bank with a clearing number
- Create a vendor bill for a Swiss partner or payrun report
- Pay with "Swiss ISO20022" > generate xml pain001
- Validate against xsd or any swiss pain001 test plateform > Incorrect rules usage ! not valid xml !

**Cause:**
In the XML the field BIC and ClrSysMmbId are present. Only one of them can be present. See the [documentation (page 27 and 33)](https://www.six-group.com/dam/download/banking-services/interbank-clearing/fr/standardization/iso/swiss-recommendations/archives/implementation-guidelines-ct/implementation-guidelines-ct_v1_6_1.pdf).

**Solution:**
Create the method `_get_ClrSysMmbId()` which will only return for Swiss if there is no BIC number. This is a partial unrevert of [this commit](https://github.com/odoo/enterprise/commit/177c7bbc890c3d142010de2cb7d0d9d6752c7fd9#diff-282e44e861d61542f3bc6d40e61b73fd1556f659d53ecd8bf9430dcec79c2fd6).

opw-4872507