### Contains the following commits:

https://github.com/odoo/o-spreadsheet/commit/44237c04a0 [REL] 19.1.26 [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/ac1974039f [FIX] config: bump node version in GH action [Task: 0](https://www.odoo.com/odoo/2328/tasks/0)
https://github.com/odoo/o-spreadsheet/commit/9fa87aa588 [IMP] pivot: give full dimension to pivot normaliser [Task: 6023622](https://www.odoo.com/odoo/2328/tasks/6023622)

Co-authored-by: Florian Damhaut (flda) <flda@odoo.com>
Co-authored-by: Anthony Hendrickx (anhe) <anhe@odoo.com>
Co-authored-by: Alexis Lacroix (laa) <laa@odoo.com>
Co-authored-by: Lucas Lefèvre (lul) <lul@odoo.com>
Co-authored-by: Adrien Minne (adrm) <adrm@odoo.com>
Co-authored-by: Ronak Mukeshbhai Bharadiya (rmbh) <rmbh@odoo.com>
Co-authored-by: Dhrutik Patel (dhrp) <dhrp@odoo.com>
Co-authored-by: Rémi Rahir (rar) <rar@odoo.com>
Co-authored-by: Pierre Rousseau (pro) <pro@odoo.com>
Co-authored-by: Vincent Schippefilt (vsc) <vsc@odoo.com>
Co-authored-by: Marceline Thomas (matho) <matho@odoo.com>

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT Company`.
- Create a new vendor bill with:
  - Vendor: GT Company
  - GT Document Type: `FESP`
  - Add taxes `VAT Withholding 12%` and `ISR Withholding 5%` in Invoice lines.
- `Confirm` the bill and `Send to SAT`.
- From the gear icon, click `Download` > `PDF`.

**Error1:**
`KeyError: 'gran_total'`

**Error2:**
`KeyError: 'retencion_grand_total'`

**Root Cause:**
In commit [1], the code at [2] missed calling `_l10n_gt_edi_add_base_values()` 
before `_l10n_gt_edi_add_withholding_values()`. However, 
`_l10n_gt_edi_add_withholding_values()` uses the `gran_total` value, which is 
initialized by `_l10n_gt_edi_add_base_values()`, resulting in a `KeyError`.

Additionally, the report template at [3] references `retencion_grand_total` 
instead of the correct key `retencion_gran_total`, causing another `KeyError`.

**Fix:**
This commit prevents errors and ensures users can successfully download 
the PDF by applying a fix similar to [4],

[1]:
https://github.com/odoo/enterprise/commit/44afd19e4ed0827e343af0e584c81e579935c9e8

[2]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L305-L328

[3]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/views/report_invoice.xml#L72

[4]:
https://github.com/odoo/enterprise/blob/9846b337cfe1876017c7c2ce3041569d7a2ac03f/l10n_gt_edi/models/account_move.py#L790-L800

opw-6323049

Forward-Port-Of: odoo/enterprise#122030

### Steps to reproduce:

- In the settings enable: Multi-Steps Routes
-  Set your warehouse to manufacture in 2 steps (pick then manufacture).
- Create a final product (FP) with a BOM in flexible consumption:
  - 1 x COMP (lot tracked)
- Create and confirm an MO for 1 units of FP
- Set the quantity producing on the MO to 1
> The consumed qty was updated to 1 unit
- Set a lot on the pre-production pikcing and validate
#### > The lot is not transfered to the MO which you are not able to validate since the registered component is lot less

### Cause of the issue:

The issue is caused by https://github.com/odoo/odoo/commit/3223deb871ca4cb4ac0381e4321f2dbf79a60189 as the `qty_waiting` is based on the reservation state of the move origin of the move rather than its actual demand:
https://github.com/odoo/odoo/blob/00118002bd6eab2f4c34a32e993a9219fded06ac/addons/mrp/models/mrp_production.py#L1419-L1426
In particular, since the backorder of the pre-production picking was not reserved (since nothing was available in stock), it was not taken into account as it should have been.

Issue 2:

Steps to reproduce:

- In the settings Enable Multi-Steps Routes
- Unarchive MTO
- Create 3 products: 
  - Final Product: Tracked by SN with a BOM: 1 X Super Component
  - Super Component: Tracked by SN, MTO with a BOM: 1 X Component
  - Basic Component: Put 10 units in stock
- Create and confirm an MO for 3 units of Final Product
> This should create an MO for 3 units of Super Component
- Go to the Child MO > Cogs wheel > Split in 3 MO's
- Click "Generate serial" on each Child MO and validate the first one
- On the MO for Final Product > Cogs wheel > Split in 3 MO's
- On the first MO, click "Generate Serial"
> Error: Reserving a negative quantity is not allowed.

### Cause of the issue:

The `action_generate_serial` calls in turn the `set_qty_producing`:
https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/mrp/models/mrp_production.py#L1601
However, since the main MO was split the Super component demand is of 1 but each child MO provide an origin quantity of 1 so that the `new_qty` will be set to a negative one here:
https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/mrp/models/mrp_production.py#L1418-L1426
But, since the first child MO was validated, there is already a move line associated to the Super component move and the `_set_quantity_done` will therefore try to adapt the reservation to a negative quantity which leads to the error:
https://github.com/odoo/odoo/blob/9fac1400fe5a8e665732c2ee3701c17c3495318f/addons/stock/models/stock_move_line.py#L469-L470

opw-6128575
opw-6317083

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

Forward-Port-Of: odoo/odoo#271123

Currently, an error occurs on an invoice when user selects a payment term and removes the currency.

Steps to replicate:
- Install account
- Turn on multiple currencies
- Open invoices.
- Create a new invoice 
- Add a line
- Add a customer
- Save
- Select payment term as `30% Now, Balance 60 Days`
- Remove the currency.

Error:
```
ValueError: Expected singleton: res.currency()
```

Cause:
- This error only occurs when the selected payment term contains at least two due term lines [1].

- When the selected payment term has atleast two lines the check [1] assigns `on_balance_line` as  false and the `else` block is evaluated where currency being an empty recordset (as the user removed it) causes the error from [line] when trying to perform `round()` on an empty res.currency recordset.

Solution:
- As the currency is a required field, user will not be able to save the record until a currency is assigned.

- Used journal's currency or company's currency as a fallback when computing payment terms if the current currency is empty.


[1]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L229

[line]: https://github.com/odoo/odoo/blob/177002c0aca95de2de6458bb65bedf5c74541ac0/addons/account/models/account_payment_term.py#L240

sentry-7569922293

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

Forward-Port-Of: odoo/odoo#272073

**Current behavior before PR,**
Computing `main_user_id` of a partner involved filtering active users within a
loop. To avoid losing the prefetching, we manually forced all partner users to
be kept in the prefetch during each iteration. This caused performance issues as
the recordset grew large (e.g., during auto-subscription).

**Desired behavior after PR is merged,**
All partner users are prefetched and filtered once, removing the need for a
repetitive manual prefetch.

**Benchmark,**
The following observations were recorded when auto-subscribing users to a
discuss channel at different scales.
The _Before_ and _After_ results represent the max values from three consecutive
tests.

|  Records |   Before |      After |
| :--------| -------: | ---------: |
|    3k    |   ~2.3s  |    <90ms   |
|    5k    |   ~3.8s  |    <160ms   |
|    10k   |   ~7.6s  |    <300ms  |

part of task-6116079



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

Forward-Port-Of: odoo/odoo#271549

[FIX] stock,*: properly compute forecast availability after PO resupply scrap
* : mrp_subcontracting_purchase

# How to reproduce
- Enable Subcontracting in the settings
- Create Product A with :
	- Quantity : > 0
	- Routes : Buy & Resupply Subcontractor on Order
- Create Product B
- Create BOM for that Product with
	- BOM Type : Subcontracting
	- Subcontractors : any
	- Component : Product A
- Create a PO for Product B
- Confirm the PO Order
- Use the Resupply smart button
- Click on the gear icons > Scrap
- Scrap Product A

# The problem
A traceback will appear.

# Cause
There are two main ways to get the picking type's code of a move. Either :

- `product_code` which is a related field to `picking_id.picking_type_id.code` :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_move.py#L174

- `picking_type_id.code` where `picking_type_id` is a computed field :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_move.py#L283-L287

When we scrap the products, we call the `do_scrap()` function that creates a new
scrap move :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_scrap.py#L158

When we do so, the create move's `picking_code` wil be the code of the picking type
of the current picking (The subcontractor resupply) :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_scrap.py#L151

But `picking_type_id.code` will be different because there is a
`default_picking_type_id` value set in the context by :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/purchase_stock/models/purchase_order.py#L223

In our case, theses values end up not being the same. Later, when we compute the forecast
information of the move, we prefetch virtual available keys and put the moves in a dict
based on those keys.
The computation of the virtual available key is based on the `picking_code` of the move :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_move.py#L488-L490
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_move.py#L496-L499

When later we try to fetch back the move, we compute the virtual available key based on
`picking_type_id.code` :
https://github.com/odoo/odoo/blob/0442c66d26b0c23313f17c566b16e34e7b22c2b6/addons/stock/models/stock_move.py#L529-L536

But since `picking_code` and `picking_type_id.code` are different, the output
`key_virtual_available` is also different. Essentially, we add the move in the
dict with key A and then try to fetch it back using key B, which gives us a KeyError.

opw-6145887

Forward-Port-Of: odoo/odoo#272171
Forward-Port-Of: odoo/odoo#263799

# How to reproduce
You need to simulate the fact that you are creating an appraisal late so either : 
A) Directly edit the `next_appraisal_date` in SQL
B) Go to Employee App > any Employee > Settings, set Next Appraisal Date to tomorrow and wait for 2 days

Then :
- Click on Request Appraisal
- Save

# The problem
An error is shown saying "You cannot set 'Next Appraisal Date' in the past.". You can workaround this by changing the Next Appraisal Date to a date in the future, but the problem is not every user has the right to do this.

# Cause
`next_appraisal_date` is also defined in hr.appraisal as a relate field of hr.employee : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_appraisal.py#L56-L57

When creating an hr.appraisal, `next_appraisal_date` is present in `vals_list` because it is defined in the view since : https://github.com/odoo/enterprise/commit/58fba3098f33db82dfbccca2db229550402ed3ab https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/views/hr_appraisal_views.xml#L92

This triggers a write on `next_appraisal_date` of hr.employee which triggers a constraint : https://github.com/odoo/enterprise/blob/0226ad15abc8db70f8e379fddec3d83d15749c85/hr_appraisal/models/hr_employee.py#L81-L85

opw-6147865

Forward-Port-Of: odoo/enterprise#114876

**Steps to Reproduce:**
- Install the Accounting and Contacts modules.
- Enable Quick Encoding for Customer Invoices and Vendor Bills in the company 
  settings.
- Create a new customer: Assign a salesperson.
- Ensure:
  - The salesperson is not a login user.
  - The customer language, salesperson's language, and Login user's language 
    are different. Example:
     - Customer language: English
     - Salesperson language: French
     - Login user language: French
- Create a customer invoice using the Upload Document functionality.
- Select the customer created above.
- Use Quick Edit mode and enter an amount and Click Confirm.

**Issue:**
- When the invoice notification is rendered in a language different from the one
  used during the write operation, the notification rendering flow calls 
  _notify_by_email_prepare_rendering_context().
- During rendering, the code executes:
```
self.tax_totals.get('total_amount_currency', 0)
```
- Since tax_totals is protected, the ORM returns False instead of the expected
  dictionary, leading to:
```
AttributeError: 'bool' object has no attribute 'get'
```

**Root Cause:**
- This issue occurs in Quick Edit mode because tax_totals is [not read-only](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/views/account_move_views.xml#L1359) 
  in Quick Edit mode and is included in [the values](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/web/static/src/model/relational_model/record.js#L708) sent by the web client during write().
- During create()/write(), _get_protected_vals() marks tax_totals as protected.
- Since tax_totals is a [@api.depends_context('lang')](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L975) computed field, it 
  maintains a separate cache per language. [During write()](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L3955), the [field becomes 
  protected](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/addons/account/models/account_move.py#L3863) by [env.protecting()](https://github.com/odoo/odoo/blob/1f7a62d38303a992f501b4ecdb1bee437f7279b8/odoo/orm/fields.py#L1738). While the protection is still active, the mail 
  notification flow renders the email using the recipient's language. If the 
  corresponding language-specific cache entry for tax_totals is not available, 
  the ORM cannot recompute the protected field and returns False instead 
  of the expected dictionary.

- The rendering code assumes tax_totals is always a dictionary and directly 
  calls  .get(), leading to the crash.

**Solution:**
- Exclude tax_totals from _get_protected_vals().
- tax_totals is already handled explicitly after create()/write(), so protecting 
  it is unnecessary. This allows the field to be recomputed during notification 
  rendering when required.

**Result:**
- Invoice notifications render correctly in all languages.
- No RPC crash occurs when rendering notifications after Quick Edit.

**Runbot reproduction: [video](https://github.com/user-attachments/assets/5f045efb-37de-40aa-b135-1368b1601d61)**

**opw-6209647**

Forward-Port-Of: odoo/odoo#266335

When Google sends an all-day event, the payload only contains a date (no time), so the inbound sync stores start and stop at 00:00 UTC. The list view renders those Datetime fields in the viewing user's timezone, so any user west of UTC sees the previous day. The calendar view stays correct because it reads the date part directly.

The rest of Odoo stores all-day events at 08:00 and 18:00 UTC, which keeps the stored datetime inside the same calendar day:
https://github.com/odoo/odoo/blob/327ad9b737b0f1d4c547c71a52c45d8433f2b3f4/addons/calendar/models/calendar_event.py#L408-L414

Apply the same 08:00 / 18:00 normalization when building values from a Google all-day payload, so events created on Google match events created in Odoo.

Steps to reproduce:
1. Set your user timezone to America/Winnipeg.
2. Connect a Google account and run the calendar sync.
3. In Google Calendar, create an all-day event on January 31.
4. Sync, then open Calendar in list view in Odoo.

=> Start Date and End Date columns show January 30.

Ticket [link](https://www.odoo.com/odoo/project.task/6145880)
opw-6145880

Forward-Port-Of: odoo/odoo#262282

Steps to reproduce:
- Install `l10n_in_reports` module(Indian Localisation)
- Create a branch in `IN Company` > Select both
- Create separate invoices for each company
- Created the GSTR-1 report for both company
- While generating Excel, select only main company

Traceback:
```py
File "/home/odoo/src/enterprise/19.0/l10n_in_reports/models/account_return.py", line 2537, in action_generate_gstr1_xlsx
gstr1_json = self._get_l10n_in_gstr1_json()
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/19.0/l10n_in_reports/models/account_return.py", line 1071, in _get_l10n_in_gstr1_json
'b2cs': _get_b2cs_json(AccountMoveLine.search(self._get_section_domain('b2cs'))),
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
File "/home/odoo/src/enterprise/19.0/l10n_in_reports/models/account_return.py", line 672, in _get_b2cs_json
for line, line_tax_details in tax_details.items():
^^^^^^^^^^^^^^^^^
AttributeError: 'NoneType' object has no attribute 'items'
```

Cause:
This issue occurs because, while generating the GSTR-1 Excel report for a particular month, [journal_items] contains account moves from both companies. This happens because the [domain] fetches records for both companies, resulting in move [lines] from both companies being included.

However, while generating the Excel report, only one company is selected. As a result, [tax_details_by_move] does not contain the move data for the branch company, which returns None, causing the error to be raised.

Solution:
Pass an empty `{}` for `tax_details` when only a single company is selected.

[journal_items]: https://github.com/odoo/enterprise/blob/3c3641d9f0753c1ca62285667c4a2786c15e2444/l10n_in_reports/models/account_return.py#L877 
[domain]: https://github.com/odoo/enterprise/blob/770ffaac14bfcd2c54a7ce6aca27e0010e7884d4/l10n_in_reports/models/account_return.py#L1387-L1393 
[lines]:
https://github.com/odoo/enterprise/blob/3c3641d9f0753c1ca62285667c4a2786c15e2444/l10n_in_reports/models/account_return.py#L1074 
[tax_details_by_move]:
https://github.com/odoo/enterprise/blob/3c3641d9f0753c1ca62285667c4a2786c15e2444/l10n_in_reports/models/account_return.py#L880

opw-6242824

Forward-Port-Of: odoo/enterprise#118614

**Steps to reproduce:**
* Install the **l10n_gt_edi** module.
* Configure a Guatemalan company with valid Infile credentials in the settings.
* Create a product or customer with special characters (e.g. `ñ`, `á`, `é`) in their name.
* Create a customer invoice containing this product/customer.
* Confirm the invoice to trigger the EDI send to the SAT (Infile).

**Observed behavior:**
* Infile intermittently rejects the invoice due to validation errors, or accepts it but the resulting certified XML has truncated or malformed text exactly where the special characters were located.

**Cause:**
* Odoo uses the `requests.post()` library to send the XML payload to Infile. By default, `requests` encodes string payloads using `latin-1` unless told otherwise.
* Because the request was missing the explicit `Content-Type: application/xml` header and the XML string was not explicitly encoded to `utf-8` before sending, Infile parsed the payload using an incorrect encoding. This caused it to drop or misinterpret special characters, leading to validation failures or corrupted XML content.

**Fix:**
* Explicitly include the `'Content-Type': 'application/xml'` header in the request to Infile.
* Explicitly encode the `xml_data` payload to `utf-8` (`xml_data.encode('utf-8')`) before passing it to `requests.post()` to guarantee the correct encoding is sent over the wire.

opw-6315654

Forward-Port-Of: odoo/enterprise#121729

When using Dutch (or similar locales where the decimal separator is a comma), a configured global discount percentage with decimals is misapplied in POS. For example, a default discount of 8,33% is shown in the discount popup as 8.33% and, when confirmed without editing, applies a 100% discount on the order instead of 8,33%.

Steps to reproduce:
-------------------
* Activate Belgian localization for accounting
* Set the user language to Dutch (Netherlands) or Dutch (Belgium)
* In Point of Sale settings, enable global discounts and set the default discount percentage to 8,33%
* Open a POS session, add a product to the cart, and click Discount
* Confirm the popup without changing the value

> Observation:
The popup displays 8.33% (with a dot). After confirmation, the order receives a full discount instead of 8,33%.

Why the fix:
------------
The discount popup initialized its value with `String(discount_pc)`, which always uses a dot as decimal separator. POS then parses the input with locale-aware rules where `.` is the thousands separator, so "8.33" is read as 833 and capped to 100%. Format the default discount percentage with `formatFloat` so the popup starts with the correct localized value (e.g. "8,33").

opw-6334367