Steps to Reproduce:
-------------------------
1. Install the Website and Employees modules.
2. Create a Test User and It's Employee.
3. On the Employee record, go to Private Information, create a Bank Account
with a custom Account Holder Name.
4. Log in to the Website using the Test User.
5. Navigate to My Account and click Edit Information.
6. Fill in the address details (without changing the Name) and click Save.
7. Go back to the Employee’s Bank Account and check the Account Holder Name.

Observation:
-------------------------
The Account Holder Name was overwritten to the partner's name.

Issue:
-------------------------
In `_compute_account_holder_name` method,
https://github.com/odoo/odoo/blob/c3b543631bde96260082484a3baac19d942f6b9f/odoo/addons/base/models/res_bank.py#L104-L107
The Account Holder Name is always recomputed using the Partner’s name.
When submitting the form from the frontend, the name field is included in the
values sent to update the Partner, even if the user did not actually change
the name.
https://github.com/odoo/odoo/blob/be3a4283c383d187570f5a73f337030e6ae9d05c/addons/portal/controllers/portal.py#L196-L205
which re-triggers this compute and as a result, the Partner’s name overwrites
the Account Holder Name on the linked Bank Account

Solution:
 -------------------------
Prevent the Account Holder Name compute method from being triggered when
updating information from the frontend if the Partner’s name has not been
changed.


opw-5059247

Forward-Port-Of: odoo/odoo#232723
Forward-Port-Of: odoo/odoo#229210

Behavior before:
Exporting the TPAR report using the TPAR option failed with a line length error because the SQL query returned the full JSON object for country names (e.g., {'en_US': 'Australia'}) instead of plain text, resulting in incorrect line lengths. Additionally, PDF export failed with a KeyError for the missing 'level' key, as dynamically generated report lines did not include a level field, which the QWeb template requires.

Behavior after:
SQL query uses the JSONB text extraction operator (->>) to retrieve only the country name string (e.g., 'Australia'), ensuring correct line lengths during export. All dynamic report lines are assigned 'level': 1 so that PDF export works correctly without errors.

Root cause:
Country names are stored as translatable JSONB fields, and the previous query did not extract the localized text, returning the full JSON structure. Dynamic report lines for partners did not include a level key by default, causing the PDF template rendering to fail.

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

Forward-Port-Of: odoo/enterprise#98020
Forward-Port-Of: odoo/enterprise#97990

Since this commit: 766ec99

We try to clean reservations because, for some reason, there could be a discrepancy between the sum of “stock.move.line” and the quantity/reserved quantity on “stock.quant”.
However, there are cases where a user creates a storable product, updates its quantity, and then uses it in a “stock.move.line”, confirms it, and later changes the product type to a kit. So, when trying to clean the reservations for these “stock.move.line”, a user error occurs because the system attempts to create a quant for a kit-type product: https://github.com/odoo/odoo/blob/c07778bbce4311c142bd8e2ce3013998d4f126ae/addons/mrp/models/stock_quant.py#L6-L11 As a result, each time users try to access the quant list, clean_reservation is triggered, causing a user error that prevents them from modifying the quantity of any quant.

Solution:
For kits, we can skip cleaning their quant to avoid unnecessary errors.

This is a manual forward-port of #200595

opw-4625002
opw-4624008
opw-4621175
opw-4625465
opw-4621504
opw-4623523
opw-4621508
opw-4623329
opw-4629386
opw-5179369

Forward-Port-Of: odoo/odoo#234417
Forward-Port-Of: odoo/odoo#232646

**Issue**
When an invoice is issued in a currency different from the company currency, the VIES summary report incorrectly displays the total value as if it were already converted. This results in incorrect totals in the report.

**Steps to Reproduce:**
1. Install the Accounting app and the l10n_cz_reports_2025 module.
2. Go to Accounting > Customers > Invoices.
3. Create a new invoice using a currency other than CZK.
4. Add a product with Code Supply set to Gold and Transaction Code set to 0 Goods. Confirm the invoice.
5. Navigate to Accounting > Reporting > VIES Summary Report.
6. Observe that the total value is not correctly converted to the company currency.

**Expected Behavior:**
The total amounts in the VIES summary report should be correctly converted to the company currency if the invoice was created in a foreign currency.

**Actual Behavior:**
Amounts are displayed in the invoice currency without conversion, leading to incorrect totals when the invoice currency differs from the company currency.

**Root Cause**
The report fetches raw invoice data without handling currency conversion. Specifically, it retrieves the unconverted total value, even when the invoice currency differs from the company’s.

**Fix**
To solve the issue the balance field is used, which correctly reflects the value in the company currency.

opw-4688638

Forward-Port-Of: odoo/enterprise#97894
Forward-Port-Of: odoo/enterprise#82978

****Behavior:****
**Current:**
When generating the inventory valuation report, if the default stock valuation account is removed in the company settings, the system assumes that there will be an account linked to the debit/credit and will attempt to access it without any other check which will lead to an IndexError.

**Expected:**
We want to avoid blocking users as much as we can, so we will allow users to generate the report without the account and later fallback to stopping them with a warning if they try to generate an accounting entry from the valuation. Since we are now checking that there is an account before trying to access it, it doesn't matter if it is empty.

**Steps to reproduce:**

- Enable warehouse locations
- Make sure the Production location has a 'Cost of Production' account.
- Create two products with costs and prices
- Create a bom and manufacture one of the products.
- Go to Settings/Inventory Valuation and remove the Valuation Account
- When trying to generate the Inventory Valuation, you should get an error

opw-5184300

The system will crash when user tries to create new bank statement line.

**Steps to produce:**
- Install `Invoicing` module without demo data.
- Go to `Configuration > Journals` and duplicate the default Bank journal to create Bank (Copy).
- `Dashboard` and Click on 3 dots of Bank(Copy) and click on `Transactions`.
- Create a new transaction and set the Statement also(Create new and assign it).
- Go to that statements and Add a line and set the foreign currency as `USD`.

**Error:**
`ValueError: Wrong value for account.bank.statement.journal_id: account.journal(7, 6)`

**Cause:**
- During an onchange on a new, unsaved `statement line`, our code tried to read the `statement_id.journal_id` ([1]). This forced to compute the journal on the unsaved parent statement, which failed with a error.

**Solution:**
- We use `self.statement_line_id.statement_id._origin.journal_id` to read the journal's stored value

[1]
https://github.com/odoo/odoo/blob/ec2d8d026d9f13c8fb869ad1f7b8026a144e85ec/addons/account/models/account_move.py#L887

**sentry-6928858335**

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

Issue:
Currently minimum rental duration uses a hardcoded 30 days. This cause issue for non-30 days month e.g. Feb. which is 28 days.

To reproduce:
1- Install `website_sale_renting`
2- From Setting, set `Minimum Rental Duration` to 1 month.
3- Create a rental product and from website, choose the date:
- 01/02/2026 - 28/02/2026

4- This fails. The earliest end date it accepts is 03/03/2026.

Cause:
This is due to hardcoded 30 days:
https://github.com/odoo/enterprise/blob/7ffb9f3cb0d818cf3616d6972df424bf0ca251a4/website_sale_renting/static/src/js/renting_mixin.js#L7-L12 https://github.com/odoo/enterprise/blob/7ffb9f3cb0d818cf3616d6972df424bf0ca251a4/website_sale_renting/static/src/js/renting_mixin.js#L47-L53

We can use luxon plus method instead.
```diff
+ const minEndDate = startDate.plus(Object.fromEntries([[unit, duration]]));
```
In all usages of `msecPerUnit` we can do the same.

Also we can keep remove `msecPerUnit` from master.

opw-5094534

Forward-Port-Of: odoo/enterprise#98899
Forward-Port-Of: odoo/enterprise#98168

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.
  Video:
    https://drive.google.com/file/d/1rweJgknjbKrpouJRTQ2cluKHsIXNZtSz/view?usp=drive_link

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.

Test:
Linked the bank in the test suite. The test fails without this fix, confirming the issue is resolved.

opw-5099816

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

Forward-Port-Of: odoo/odoo#231399

Versions
--------
- 17.0+

Steps
-----
1. Enable anglo-saxon accounting;
2. have a product category with automated AVCO;
3. assign category to a deliverable product;
4. set product to invoice on delivery;
5. add product to a sales order;
6. confirm order & delivery;
7. create invoice;
8. change the delivery on the invoice;
7. confirm the invoice.

Issue
-----
The delivery date gets reset.

Cause
-----
Commit 818cf04f05767 added `delivery_date` as a permanently protected field when modifying moves or move lines, protecting the records on `write`. With anglo-saxon accounting however, new move lines are created when confirming an invoice, which in turn recalculate the delivery date, as `_get_protected_vals` isn't used for their move on `create`.

Solution
--------
Add `self.env['account.move'].protecting(_get_protected_vals({}, moves))` when creating new lines for a move, to avoid recomputing fields that should always be protected.

opw-4965036

Forward-Port-Of: odoo/odoo#231186

**PROBLEM**
When creating a backorder, the quantity to produce during an operation is correctly displayed on the shop floor step. But when clicking to modify it, the pop over display the total quantity to produce, and not the quantity to produce in that specific operation.

**STEP TO REPRODUCE**
1. create a BoM of product with 3 or more operations
2. Create a Manufacturing order for i.e. 10 unit
3. Open shop floor
4. Register the production in shopfloor:
- Op1 – 10 units registered
- Op2 – 7 units registered
- Op3 – 5 units registered

5. At the end, a backorder is created for 5 units.
6. When we open the wizard to register the production on the Op2, the quantity to produce that is displayed is 5, which is wrong because we only need to produce 3 unit for that step.

**CAUSE**
When creating the confirmation dialog, we pass the wrong value `qty_remaining` which is the quantity of product we will end after finishing the Manufacturing Order.

**FIX**
We should pass `qty_production` instead which is the quantity to produce for the specific step.

opw-5011739

Forward-Port-Of: odoo/enterprise#98036
Forward-Port-Of: odoo/enterprise#93599

When creating a purchase order for a partner without a name, a traceback occurs.

Steps to reproduce the error:

- Install purchase with demo data
- Enable purchase warning from settings
- Open `Azure Interior` Contact > In Contact, Add Contact > Type: invoice >
Save & close
- Add warning in newly created contact
- Create a purchase order with the newly created partner and create an invoice with the newly created partner

Traceback:
`TypeError: unsupported operand type(s) for +: 'bool' and 'str'`

https://github.com/odoo/odoo/blob/96887e0b9e7a9b01482b9dc1fcf99040e9de6b2c/addons/purchase/models/purchase_order.py#L298
https://github.com/odoo/odoo/blob/96887e0b9e7a9b01482b9dc1fcf99040e9de6b2c/addons/purchase/models/account_invoice.py#L131

Here, `partner_id.name` is `False`, which leads to string concatenation with a boolean in purchase warning messages and results in the above traceback.

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

Forward-Port-Of: odoo/odoo#231603