When user tries to validate Register Production/Serial in shop floor,
A traceback will appear.

Steps to reproduce the error:
- Install ``mrp_workorder`` and ``quality_control`` modules with demo data
- Go to Quality > Create a new Control point > Product: Table Top >
  Operations: Manufacturing > Save
- Create a new MO > Product: Table Top > Confirm > Shop Floor >
  Click on Assembly 1 > Click on 3 dots > Update Instructions > Improvement Suggestion > Add a step > Propose Change > Validate
- Click on 3 dots > Register Production/Serial > Validate
- Go back to MO > Quality Checks > Duplicate the newly created quality check > Shop Floor > Click on Assembly 1 > Click on 3 dots > Register Production/Serial > Validate

Traceback:
``ValueError: Expected singleton: quality.check(1, 5)``

https://github.com/odoo/enterprise/blob/5103383df3ddf23503e2c7817c5129a742a7800f/mrp_workorder/models/mrp_workorder.py#L846-L848
When User clicks on the validate, ``current_check`` may include several quality checks without a ``previous_check_id``.
The code expects only one record, which causes a traceback.

sentry-6839419788

Forward-Port-Of: odoo/enterprise#93624

**step to reproduce:**
- start a database with worker, use `--max-cron-thread=1 --workers=2`
- Add a sample cron, which runs every minute(just so that we can see the status)
- install helpdesk
- uninstall helpdesk

**Observation**
- traceback in console
```
2025-09-25 06:07:26,389 18450 ERROR ? odoo.service.server: Worker WorkerCron (18450) Exception occurred, exiting... 
Traceback (most recent call last):
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/service/server.py", line 1171, in _runloop
    self.process_work()
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/service/server.py", line 1270, in process_work
    base.models.ir_cron.ir_cron._process_jobs(db_name)
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/ir_cron.py", line 139, in _process_jobs
    registry[cls._name]._process_job(db, cron_cr, job)
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/ir_cron.py", line 331, in _process_job
    now = fields.Datetime.context_timestamp(ir_cron, datetime.utcnow())
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
....
....
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/models.py", line 3873, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/res_users.py", line 546, in _fetch_query
    records = super()._fetch_query(query, fields)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/models.py", line 3965, in _fetch_query
    self.env.cr.execute(query.select(*sql_terms))
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/sql_db.py", line 335, in execute
    res = self._obj.execute(query, params)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.UndefinedColumn: column res_users.helpdesk_target_closed does not exist
LINE 1: ...s"."odoobot_state", "res_users"."odoobot_failed", "res_users...
```

Issue:
- traceback occurred, as the system is try to fetch fields related to helpdesk module
which do not exists now after uninstalling it. 
- cron in case of workers, use daemon threads [1]
- the uninstalled happened with main thread and registry is updated.
- the daemon thread is unaware of this change.
- the `_process_jobs` uses the registry, without checking if it needs reload

[1]: https://github.com/odoo/odoo/blob/e82fdfaf621f45515b92c891334595250accbfbd/odoo/service/server.py#L582-L587

FIx:
- when assigning the registry, we check if needs a reload or not.

opw-5062313

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

Forward-Port-Of: odoo/odoo#229556
Forward-Port-Of: odoo/odoo#228515

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

Steps
-----
1. Have a sale order with deliverable products & no payment terms;
2. confirm order & validate delivery;
3. create an invoice;
4. modify the delivery date;
5. save changes;
6. change product quantity of a line & confirm invoice.

Issue
-----
The delivery date got reset.

Cause
-----
The `_compute_show_delivery_date` method gets called, which triggers the recomputation of the `_compute_delivery_date` due it the latter having `line_ids.sale_line_ids.order_id` as its `depends`.

Due to the way how `depends` works, if any of the fields in the record chain gets modified, the compute gets triggered. In this case, because we modified a `line_ids` record by changing the quantity, it will therefore recompute the delivery date, overwriting the custom value.

Solution
--------
As we only want the delivery date to be recomputed when the `effective_date` on the order changes, we should add it to the `depends` to trigger the compute in that scenario.

In other scenarios, e.g. modifying the move or one of its lines, we don't want to trigger a recompute, which we can achieve by always including `delivery_date` via `_get_protected_vals` on create/write.

opw-4996654

Forward-Port-Of: odoo/odoo#229932
Forward-Port-Of: odoo/odoo#223946

[FIX] l10n_in{,_edi}: Sale RCM and SEZ(With LUT)
    
Steps to reproduce:
1. Install `l10n_in_edi`
2. Create an invoice with a RC tax/SEZ (with LUT) tax
3. Confirm and Process for E-invoice
4. See the EDI content, The GST rate is 0%

Before this

For RC and SEZ (with LUT) the tax rate and tax amount were sent
as `0`  and  (data going wrong for SEZ/Exports) for Indian E-invoicing.

Following the fix:

1. We rename the the IGST x% (SZ/EX) -> IGST x% (EX)
2. Introducing new taxes for SEZ with LUT
3. Fiscal for Export and SEZ renamed to Export (same for LUT)
4. Introducing new fiscal for SEZ and SEZ (LUT)
5. In case of Special Economic Zone normal taxes (IGST) should be applied 
because as per the [API Doc](https://einv-apisandbox.nic.in/version1.03/generate-irn.html#validations)
    It states -
    **However, in case of Reverse charge and Export transactions (EXPWP), Total value of Item can match with either with tax values or without tax values. That is, the total value of item can include or exclude the tax values as per the business requirements.**

So SEZ without LUT should be passed as normal IGST


For Export without LUT

Label                                               | Taxes            | credit        | debit| Tags
-------------------------------------------------------------------------------------------------------------
Product A                                       | 18% IGST S (EX)  |    100 |          | Base IGST
IGST 18%                                        |                              |       18 |          | IGST
IGST Paid on SEZ/Export Sales   |                              |             |     18| 
Creditor                                          |                              |             |   180|

Invoice Total 100
EDI with {'rate': 18.0, 'IgstAmt': 18.0, 'TotItemVal': 100}


For SEZ without LUT

Label     | Taxes            | credit | debit | Tags
-----------------------------------------------------------
Product A | 18% IGST S (SEZ) |    100 |       | Base IGST
IGST 18%  |                  |     18 |       | IGST
Creditor  |                  |        |    118|

Invoice Total 118
EDI with {'rate': 18.0, 'IgstAmt': 18.0, 'TotItemVal': 118}


For Export/SEZ with LUT

Label     | Taxes            | credit | debit | Tags
-----------------------------------------------------------
Product A | 18% IGST S (SEZ) |    100 |       | Base IGST
IGST 18%  |                  |     18 |       | IGST
IGST 18%  |                  |        |    18 | IGST
Creditor  |                  |        |    100|

Invoice Total 100
EDI with {'rate': 18.0, 'IgstAmt': 0.0, 'TotItemVal': 100}


For RCM

Label                          | Taxes            | credit | debit | Tags
-------------------------------------------------------------------------------
Product A                      | 18% IGST S RC    |    100 |       | Base IGST || BASE IGST RC
IGST 18% RC                    |                  |     18 |       | IGST
IGST 18% RC                    |                  |        |     18| IGST RC
Creditor                       |                  |        |    118|

Invoice Total 100
EDI with {'rate': 18.0, 'IgstAmt': 0, 'TotItemVal': 100}


task-4878805


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

Forward-Port-Of: odoo/odoo#228871
Forward-Port-Of: odoo/odoo#213931

**Note: issue not reproducible in runbot, but in fresh database** 

**Step to reproduce:**
- in fresh database, install esg module
- go to setting > invoicing > add india as Fiscal Localization
- change company name, ex "test"
- goto setting > load demo data

**Observation:**
- You will receive traceback

```
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/codebase/enterprise/saas-18.4/esg/demo/demo_data.xml:567, somewhere inside
<record id="esg_emission_factor_line_assignation_4" model="esg.assignation.line">
<field name="esg_emission_factor_id" ref="esg_zero_emission_factor"/>
<field name="account_id" model="account.account" search="[('code', '=', '630000')]"/>
</record>
2025-09-11 08:45:07,458 82617 INFO esg184 odoo.addons.base.models.ir_module: module esg: no translation for language en_IN
2025-09-11 08:45:07,479 82617 ERROR esg184 odoo.sql_db: bad query: b'INSERT INTO "esg_activity_type_esg_emission_factor_rel" ("esg_emission_factor_id", "esg_activity_type_id") VALUES (1, 2) ON CONFLICT DO NOTHING'
ERROR: insert or update on table "esg_activity_type_esg_emission_factor_rel" violates foreign key constraint "esg_activity_type_esg_emission_fact_esg_emission_factor_id_fkey"
DETAIL: Key (esg_emission_factor_id)=(1) is not present in table "esg_emission_factor".
```

**Cause:**
- The demo data relies on few account.account record which belong to [USA company](https://github.com/odoo/odoo/blob/9805d09dff64de835de0c764da8c6e213d6b88aa/addons/account/data/template/account.account-generic_coa.csv#L38)
https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L569

https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L620-L628


- when we installed `india` Localization and changed the company name, USA company could not be created when loading demo data and hence the account records were not created, causing traceback

**Fix:**
- make demo data independent of any localization

opw-5048417

Forward-Port-Of: odoo/enterprise#94540

### Issue:

#### Steps to reproduce:
1- Activate routes & locations and enable Reception Report
2- Enable Show reception report at validation from operation type: receipts
3- Create a product with vendor. Put 2 unit on `WH/Stock/Shelf1`
4- Create a Sales Order for 3 units.
5- Create a PO for 1 unit and validate/receive.
6- On the Reception Report, click Assign to link incoming to sales pick
7- Open the sales pick in a new tab, observe there are 2 moves which first one is 1 and 2nd one is 2
8- On the reception report, click Unassign, then Assign again

Back on the Pick, only 1 move (the one with quantity of 2) is reserved; checking availability reserves nothing although stock exists.

#### Cause:
When unassigning from the Reception Report, the system incorrectly unreserves stock that was already in `Shelf1` instead of unreserving the incoming move which the location_id is `WH/Stock`:

User clicks Unassign on the Reception Report.
`report_stock_reception.action_unassign()` is invoked.
That calls `stock_move._do_unreserve()`.
`_do_unreserve()` unpicks quants referenced by the `move.move_line_ids`.
At this moment one of the `move_line_ids` points to `WH/Stock/Shelf1`, so `_do_unreserve()` removes the reservation from that `shelf1` quant.
Consequence: `shelf1` stock(which should have remained reserved) becomes free. The receipt quant at `WH/Stock` remains reserved/ unavailable.

When the user clicks Assign again, the system cannot reserve because it is alreade reserved by another move and therefore it is unavailable.

#### Root cause:
Now we look earlier in the flow to see why the move had a move_line pointing to `WH/Stock/Shelf1` in the first place. Earlier, in `report_stock_reception.action_assign` in the first assign:
We create a new move from current outgoing move:
https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/stock/report/report_stock_reception.py#L224-L231 And we link current move_lines to the new move:
https://github.com/odoo/odoo/blob/35ea3dcb2eeb379c8b1127f0c7b42191853c0bd2/addons/stock/report/report_stock_reception.py#L245-L259 new_out.move_line_ids now contains move lines for multiple source locations, here in our case `[WH/Stock/Shelf1, WH/Stock]` The loop in above code does not check `move_line_id.location_id` when selecting lines. The first matching line in the iteration can be the `shelf1` one, so the code links the `shelf1` move_line to out instead of the `WH/Stock` move_line, which is a mismatch and causes the out move having different location with its move_line, which later will going to cause problem is unassign as explained.

### Fix:
We can sort move_line_ids in a way that which line have the same location as potential ins' dest locations come first
as better candidates:
```diff
- for move_line_id in new_out.move_line_ids:
+ matching_locations = potential_ins.location_dest_id
+ for move_line_id in new_out.move_line_ids.sorted(lambda ml: ml.location_id not in matching_locations):
```

opw-4944047

Forward-Port-Of: odoo/odoo#229687
Forward-Port-Of: odoo/odoo#226120

### Steps to reproduct:

- Create 2 products: Final Product (FP), Kit Product (KP)
- On KP add a Color attribute with 2 values: Blue, Red
- Create a KIT bom for KP wtih 2 operations:
    - OP: paint it Blue, apply on Color: Blue
    - OP: paint it Red, apply on Color: Red
- Create a bom for FP with only one component line:
    - 1 x Red Kit Product
- Create a MO for 1 unit of FP
#### > The operation was not created using the kit bom

### Cause of the issue:

Even if the bom exploded to find the operations to add on the MO: https://github.com/odoo/odoo/blob/2dfcbe53c80d2d8fe5b6d9828eea90a1d214c2e4/addons/mrp/models/mrp_production.py#L579-L599 The `_skip_operation_line`:
https://github.com/odoo/odoo/blob/2dfcbe53c80d2d8fe5b6d9828eea90a1d214c2e4/addons/mrp/models/mrp_routing.py#L164-L174 is checking if the product of the main bom has the attributes of the operation rather than the kit product used as component.

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

Forward-Port-Of: odoo/odoo#229810
Forward-Port-Of: odoo/odoo#228032

Currently an error occurs when the **'Payroll: Generate pdfs'** scheduled action runs and tries to create a document for a payslip belonging to an employee who does not have a related partner.

**Prerequisites:**
- Ensure HR is enabled in `settings>Documents`

**Steps to Reproduce:**
1) Install `documents_hr_payroll` module.(with Demo) 
2) Navigate to the Employees App.
3) Select any Employee(e.g Abigail Peterson) and open form view.
>- click on **contacts** smart button.
>- Delete that Record
4) Create a confirmed Payslip for the selected Employee(e.g Abigail Peterson). 
5) Activate Developer mode and navigate to schedule Actions.
>- Search for 'Payroll: Generate pdfs'.
>- Run Manually.

Error:
`NotNullViolation: null value in column 'partner_id' of relation 'documents_access' violates not-null constraint`

Root Cause:
When the partner is deleted, the value received from `_get_document_partner` at [1]
is `False`, which later on tries to create the `documents.access`
record for the new document, it fails because no partner is available to assign
access rights, resulting in the error.


Solution:
This commit prevent Error by ensuring `_check_create_documents` method doesn't allow document creation without valid partner.

[1]: https://github.com/odoo/enterprise/blob/99a8d83edb42f172d0dd35c91743fa0c9653dcbb/documents_hr_payroll/models/hr_payslip.py#L20C1-L21 

sentry-6814524392

Forward-Port-Of: odoo/enterprise#92865

**step to reproduce:**
- start a database with worker, use `--max-cron-thread=1 --workers=2`
- Add a sample cron, which runs every minute(just so that we can see the status)
- install helpdesk
- uninstall helpdesk

**Observation**
- traceback in console
```
2025-09-25 06:07:26,389 18450 ERROR ? odoo.service.server: Worker WorkerCron (18450) Exception occurred, exiting... 
Traceback (most recent call last):
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/service/server.py", line 1171, in _runloop
    self.process_work()
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/service/server.py", line 1270, in process_work
    base.models.ir_cron.ir_cron._process_jobs(db_name)
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/ir_cron.py", line 139, in _process_jobs
    registry[cls._name]._process_job(db, cron_cr, job)
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/ir_cron.py", line 331, in _process_job
    now = fields.Datetime.context_timestamp(ir_cron, datetime.utcnow())
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
....
....
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/models.py", line 3873, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/res_users.py", line 546, in _fetch_query
    records = super()._fetch_query(query, fields)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/models.py", line 3965, in _fetch_query
    self.env.cr.execute(query.select(*sql_terms))
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/sql_db.py", line 335, in execute
    res = self._obj.execute(query, params)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.UndefinedColumn: column res_users.helpdesk_target_closed does not exist
LINE 1: ...s"."odoobot_state", "res_users"."odoobot_failed", "res_users...
```

Issue:
- traceback occurred, as the system is try to fetch fields related to helpdesk module
which do not exists now after uninstalling it. 
- cron in case of workers, use daemon threads [1]
- the uninstalled happened with main thread and registry is updated.
- the daemon thread is unaware of this change.
- the `_process_jobs` uses the registry, without checking if it needs reload

[1]: https://github.com/odoo/odoo/blob/e82fdfaf621f45515b92c891334595250accbfbd/odoo/service/server.py#L582-L587

FIx:
- when assigning the registry, we check if needs a reload or not.

opw-5062313

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

Forward-Port-Of: odoo/odoo#229556
Forward-Port-Of: odoo/odoo#228515

**Issue**
When creating a down payment invoice for a quotation that includes a reseller, an error is raised and the operation is aborted.

**Steps to Reproduce**
1. Install Accounting, Studio, and l10n_in_sale
2. Open the Quotation view in Studio
3. Set the "Referrer" field (i.e., l10n_in_reseller_partner_id) to be always visible and remove group restrictions
4. Create a new quotation and set a reseller in the Referrer field
5. Confirm the quotation
6. Click "Create Invoice"
7. Choose "Down Payment (percentage)" with 10%
8. Click "Create Draft"

**Root Cause**
The `_prepare_invoice_values()` method was assigning the full `res.partner` record to the `l10n_in_reseller_partner_id` field instead of its ID. Since the `account.move` model expects an integer ID for many2one fields, this caused a `psycopg2.ProgrammingError` due to the database adapter not being able to serialize a recordset.

**Fix**
Ensure the value passed to l10n_in_reseller_partner_id is the .id of the partner record, not the recordset itself.

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

Forward-Port-Of: odoo/odoo#222324
Forward-Port-Of: odoo/odoo#220354

### Issue:

In this bug, the workorder duration being set to duration_expected is causing issues in backorder.

To reproduce:
1- Create a Bill of Materials with at least two operations at two work centers
2- Create a manufacturing order and confirm it.
3- Complete the first operation and edit the quantity on the second operation so there is a backorder for the remaining quantity.
4- In the second work order, the first operation is cancelled, Finish the 2nd operation
5- As you can see, the cancelled operation duration is set to expected duration which is wrong.

### Cause:

This issue is caused because of:
https://github.com/odoo/odoo/blob/8f0e40286da7b144bfa17880a257406dd8585e57/addons/mrp/models/mrp_production.py#L1774-L1779

Which if work.order.state is `cancel`, the duration will set to `duration_expected`.
This will eventually cause issue here:
https://github.com/odoo/odoo/pull/222075/commits/8f0e40286da7b144bfa17880a257406dd8585e57#diff-fac872ffb03b811c4976eb2e52991ec544265332df814d92cfda658a5b917423L348
which is fixed by not making the state into `progres` if the state is `cancel`.
But that doesn't fix the fact that the cancelled workorder has duration set and it might cause inconsistencies in manufacturing costs.

related:
#222075

opw-4931653

Forward-Port-Of: odoo/odoo#229742

**Steps to reproduce:**
- enable "units of measure & packagings" settings
- navigate to "units and packagings" and create a new one called 
"pack of 2"
- set a quantity of 2 and the reference unit as "units"
- create a new storable product
- next to "sale price" change the unit to "pack of 6"
- in the sales tab add "pack of 2" in the packagings
- in the purchase tab add a vendor
- click on the reordering rule smart button and create a new one
- set the min and max to 0 and set the replenishment multiple to 
"pack of 2" (you might have to make this column visible using the filters)
- create and confirm a quotation for 1 pack of 6

**Current behavior:**
a new Purchase Order is created for a quantity of 1.02

**Expected behavior:**
it should be a quantity of 1

**Cause of the issue:**
qty_multiple is rounded (in _compute_quantity) before the computation
of remainder.
https://github.com/odoo/odoo/blob/7a0a246016d50ae80e49f3502a97e82d414ab0b0/addons/stock/models/stock_orderpoint.py#L373-L376
In cases of repeating decimal numbers (like 0.3333333 in our example),
this leads to the remainder not being 0 even though it should be 0.

opw-5040144

Forward-Port-Of: odoo/odoo#228014

### Problem  
When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**:  


This happened because the method assumed that at least one attachment would always be generated, even if no eligible transactions were present.

---

### Steps to Reproduce  
1. Go to **Accounting → Reporting → 325 Form**.  
2. Create a 325 form for a year without any transactions on accounts tagged with **281.50**.  
3. Do not generate any 281.50 forms (`form_281_50_ids` is empty).  
4. Click **Export PDF**.  

**Result before fix:**  
- Crash with `IndexError: list index out of range`.  

---

### Solution  
- Added a safeguard check before accessing attachments.  
- If no attachments exist, raise a **UserError** instead of crashing.  

**New behavior:**  
> *“No 281.50 lines found to generate a PDF. Please record a transaction with a 281.50 tag first.”*  

This gives users a instruction on how to resolve the issue.

---

### Result After Fix  
- **User error message** replaces traceback.  
- **Normal behavior preserved** when attachments exist:  
  - One file → direct download.  
  - Multiple files → zipped download.  

---

task-5090120

Forward-Port-Of: odoo/enterprise#94877

We need to know for each partner if it is a customer or a supplier, even
more for Romania[^1] where it is enfored and validated.
> 1. If the element SD.P.22 CustomerID is reported with value ”0”
  (zero), then the element SD.P.23 SupplierID must be different from ”0”
  (zero), meaning the identity of the partner from which the purchase was
  made (conventionally considered ”supplier”) is reported. Else if SD.P.22
  CustomerID AND SD.P.23 SupplierID are concomitantly equal to ”0” (zero),
  then is return a semantic validation error. (CustomerID and SupplierID
  can not be concomitantly 0 (zero))

In order to fix this, we don't use the Partner Ledger anymore to query
the balance per partner because it is removing the partners with 0
balance automatically.
To keep it simple, we query manually and locally, allowing to reduce the
number of queries from 3 to 1 for that part.

For the performance, the `|=` operator done in a loop has also been
removed, keeping the time complexity in `O(n)` instead of `O(n²)`.

opw-5122910

[^1]: https://www.anaf.ro/anaf/internet/ANAF/despre_anaf/strategii_anaf/proiecte_digitalizare/saf_t

Forward-Port-Of: odoo/enterprise#96355
Forward-Port-Of: odoo/enterprise#95804

When user tries to validate Register Production/Serial in shop floor,
A traceback will appear.

Steps to reproduce the error:
- Install ``mrp_workorder`` and ``quality_control`` modules with demo data
- Go to Quality > Create a new Control point > Product: Table Top >
  Operations: Manufacturing > Save
- Create a new MO > Product: Table Top > Confirm > Shop Floor >
  Click on Assembly 1 > Click on 3 dots > Update Instructions > Improvement Suggestion > Add a step > Propose Change > Validate
- Click on 3 dots > Register Production/Serial > Validate
- Go back to MO > Quality Checks > Duplicate the newly created quality check > Shop Floor > Click on Assembly 1 > Click on 3 dots > Register Production/Serial > Validate

Traceback:
``ValueError: Expected singleton: quality.check(1, 5)``

https://github.com/odoo/enterprise/blob/5103383df3ddf23503e2c7817c5129a742a7800f/mrp_workorder/models/mrp_workorder.py#L846-L848
When User clicks on the validate, ``current_check`` may include several quality checks without a ``previous_check_id``.
The code expects only one record, which causes a traceback.

sentry-6839419788

Forward-Port-Of: odoo/enterprise#93624

**Note: issue not reproducible in runbot, but in fresh database** 

**Step to reproduce:**
- in fresh database, install esg module
- go to setting > invoicing > add india as Fiscal Localization
- change company name, ex "test"
- goto setting > load demo data

**Observation:**
- You will receive traceback

```
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/codebase/enterprise/saas-18.4/esg/demo/demo_data.xml:567, somewhere inside
<record id="esg_emission_factor_line_assignation_4" model="esg.assignation.line">
<field name="esg_emission_factor_id" ref="esg_zero_emission_factor"/>
<field name="account_id" model="account.account" search="[('code', '=', '630000')]"/>
</record>
2025-09-11 08:45:07,458 82617 INFO esg184 odoo.addons.base.models.ir_module: module esg: no translation for language en_IN
2025-09-11 08:45:07,479 82617 ERROR esg184 odoo.sql_db: bad query: b'INSERT INTO "esg_activity_type_esg_emission_factor_rel" ("esg_emission_factor_id", "esg_activity_type_id") VALUES (1, 2) ON CONFLICT DO NOTHING'
ERROR: insert or update on table "esg_activity_type_esg_emission_factor_rel" violates foreign key constraint "esg_activity_type_esg_emission_fact_esg_emission_factor_id_fkey"
DETAIL: Key (esg_emission_factor_id)=(1) is not present in table "esg_emission_factor".
```

**Cause:**
- The demo data relies on few account.account record which belong to [USA company](https://github.com/odoo/odoo/blob/9805d09dff64de835de0c764da8c6e213d6b88aa/addons/account/data/template/account.account-generic_coa.csv#L38)
https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L569

https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L620-L628


- when we installed `india` Localization and changed the company name, USA company could not be created when loading demo data and hence the account records were not created, causing traceback

**Fix:**
- make demo data independent of any localization

opw-5048417

Forward-Port-Of: odoo/enterprise#94540

### Problem  
When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**:  


This happened because the method assumed that at least one attachment would always be generated, even if no eligible transactions were present.

---

### Steps to Reproduce  
1. Go to **Accounting → Reporting → 325 Form**.  
2. Create a 325 form for a year without any transactions on accounts tagged with **281.50**.  
3. Do not generate any 281.50 forms (`form_281_50_ids` is empty).  
4. Click **Export PDF**.  

**Result before fix:**  
- Crash with `IndexError: list index out of range`.  

---

### Solution  
- Added a safeguard check before accessing attachments.  
- If no attachments exist, raise a **UserError** instead of crashing.  

**New behavior:**  
> *“No 281.50 lines found to generate a PDF. Please record a transaction with a 281.50 tag first.”*  

This gives users a instruction on how to resolve the issue.

---

### Result After Fix  
- **User error message** replaces traceback.  
- **Normal behavior preserved** when attachments exist:  
  - One file → direct download.  
  - Multiple files → zipped download.  

---

task-5090120

Forward-Port-Of: odoo/enterprise#94877

**Issue**
When the delivered quantity of a product is less than the originally demanded quantity, the generated Delivery Guide XML shows the demand (product_uom_qty) instead of the actual delivered quantity (quantity). This results in an incorrect quantity being displayed in the DTE.

**Steps to Reproduce**
1. Install the Accounting module, Chilean localization, Sales module, and l10n_cl_edi_stock.
2. Create and confirm a new Sale Order.
3. Click on the Delivery smart button.
4. Adjust the delivered quantity to a value lower than the demand, save, and validate with no backorder.
5. Generate the Delivery Guide.
6. Open the generated DTE XML and observe that the quantity is incorrect.

**Root Cause**
The quantity displayed in the DTE is taken from product_uom_qty, which represents the planned quantity to be moved, not the actual delivered quantity. The correct field to use is quantity, which reflects the real delivered amount.

**Fix**
Change the XML output to use quantity instead of product_uom_qty to accurately reflect the actual delivered quantity in the DTE.

Opw-4892276

Forward-Port-Of: odoo/enterprise#93260
Forward-Port-Of: odoo/enterprise#89633

Currently an error occurs when the **'Payroll: Generate pdfs'** scheduled action runs and tries to create a document for a payslip belonging to an employee who does not have a related partner.

**Prerequisites:**
- Ensure HR is enabled in `settings>Documents`

**Steps to Reproduce:**
1) Install `documents_hr_payroll` module.(with Demo) 
2) Navigate to the Employees App.
3) Select any Employee(e.g Abigail Peterson) and open form view.
>- click on **contacts** smart button.
>- Delete that Record
4) Create a confirmed Payslip for the selected Employee(e.g Abigail Peterson). 
5) Activate Developer mode and navigate to schedule Actions.
>- Search for 'Payroll: Generate pdfs'.
>- Run Manually.

Error:
`NotNullViolation: null value in column 'partner_id' of relation 'documents_access' violates not-null constraint`

Root Cause:
When the partner is deleted, the value received from `_get_document_partner` at [1]
is `False`, which later on tries to create the `documents.access`
record for the new document, it fails because no partner is available to assign
access rights, resulting in the error.


Solution:
This commit prevent Error by ensuring `_check_create_documents` method doesn't allow document creation without valid partner.

[1]: https://github.com/odoo/enterprise/blob/99a8d83edb42f172d0dd35c91743fa0c9653dcbb/documents_hr_payroll/models/hr_payslip.py#L20C1-L21 

sentry-6814524392

Forward-Port-Of: odoo/enterprise#96191
Forward-Port-Of: odoo/enterprise#92865

When user tries to validate Register Production/Serial in shop floor,
A traceback will appear.

Steps to reproduce the error:
- Install ``mrp_workorder`` and ``quality_control`` modules with demo data
- Go to Quality > Create a new Control point > Product: Table Top >
  Operations: Manufacturing > Save
- Create a new MO > Product: Table Top > Confirm > Shop Floor >
  Click on Assembly 1 > Click on 3 dots > Update Instructions > Improvement Suggestion > Add a step > Propose Change > Validate
- Click on 3 dots > Register Production/Serial > Validate
- Go back to MO > Quality Checks > Duplicate the newly created quality check > Shop Floor > Click on Assembly 1 > Click on 3 dots > Register Production/Serial > Validate

Traceback:
``ValueError: Expected singleton: quality.check(1, 5)``

https://github.com/odoo/enterprise/blob/5103383df3ddf23503e2c7817c5129a742a7800f/mrp_workorder/models/mrp_workorder.py#L846-L848
When User clicks on the validate, ``current_check`` may include several quality checks without a ``previous_check_id``.
The code expects only one record, which causes a traceback.

sentry-6839419788

Forward-Port-Of: odoo/enterprise#93624

**step to reproduce:**
- start a database with worker, use `--max-cron-thread=1 --workers=2`
- Add a sample cron, which runs every minute(just so that we can see the status)
- install helpdesk
- uninstall helpdesk

**Observation**
- traceback in console
```
2025-09-25 06:07:26,389 18450 ERROR ? odoo.service.server: Worker WorkerCron (18450) Exception occurred, exiting... 
Traceback (most recent call last):
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/service/server.py", line 1171, in _runloop
    self.process_work()
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/service/server.py", line 1270, in process_work
    base.models.ir_cron.ir_cron._process_jobs(db_name)
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/ir_cron.py", line 139, in _process_jobs
    registry[cls._name]._process_job(db, cron_cr, job)
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/ir_cron.py", line 331, in _process_job
    now = fields.Datetime.context_timestamp(ir_cron, datetime.utcnow())
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
....
....
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/models.py", line 3873, in fetch
    fetched = self._fetch_query(query, fields_to_fetch)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/addons/base/models/res_users.py", line 546, in _fetch_query
    records = super()._fetch_query(query, fields)
              ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/models.py", line 3965, in _fetch_query
    self.env.cr.execute(query.select(*sql_terms))
  File "/home/odoo/odoo/codebase/odoo/17.0/odoo/sql_db.py", line 335, in execute
    res = self._obj.execute(query, params)
          ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
psycopg2.errors.UndefinedColumn: column res_users.helpdesk_target_closed does not exist
LINE 1: ...s"."odoobot_state", "res_users"."odoobot_failed", "res_users...
```

Issue:
- traceback occurred, as the system is try to fetch fields related to helpdesk module
which do not exists now after uninstalling it. 
- cron in case of workers, use daemon threads [1]
- the uninstalled happened with main thread and registry is updated.
- the daemon thread is unaware of this change.
- the `_process_jobs` uses the registry, without checking if it needs reload

[1]: https://github.com/odoo/odoo/blob/e82fdfaf621f45515b92c891334595250accbfbd/odoo/service/server.py#L582-L587

FIx:
- when assigning the registry, we check if needs a reload or not.

opw-5062313

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

Forward-Port-Of: odoo/odoo#229556
Forward-Port-Of: odoo/odoo#228515

[FIX] web: update breadcrumb display name on language switch

Versions
--------
- 19.0+

Steps
-----
1. Switch the user interface language in Odoo
2. Navigate through the application using breadcrumbs
3. Observe the breadcrumb display names

Issue
-----
When switching languages, the breadcrumb display names remain in the
previous language and do not update to reflect the new language.

Cause
-----
The action data cached in sessionStorage retains the display names
in the original language. When language is switched, the cached
action data is not invalidated, causing breadcrumbs to show
outdated translated text.

Solution
--------
Detect language changes by comparing the current user context language
with the cached action's language context. When a language mismatch
is detected, clear the cached action data from sessionStorage to
force a fresh load with properly translated display names.

Signed-off-by: PA Sitthipong <sitthipong114@gmail.com>

<img width="466" height="198" alt="OdooBugLanguageSwitch" src="https://github.com/user-attachments/assets/83302c7f-bc66-40e4-a310-e7087da1e747" />

Currently an error is generated when a user tries to send a message to AI
while the current page is in `Physical Inventory`list view.

Steps:
- Install `Inventory`
- Go to Inventory > Operations > Physical Inventory
- Click the AI icon from the systray menu.
- Ask anything in AI >>> error generated

Error: 
```UnboundLocalError:cannot access local variable 'current_action' where it is not associated with a value```

This issue arises because in line [1] of the code, the variable `current_action` is assigned
a value inside an `if-elif` block based on `action.type`. However, since the `Physical Inventory`
page does not have any associated action, the variable `current_action is` never set.
Consequently, attempting to access this variable results in an error.

This commit fixes the above issue by initializing the `current_action` variable as
`None` outside the `if-elif` block and adding handling for cases when `current_action` is `None`.

[1] - https://github.com/odoo/enterprise/blob/2ea15cc9c7c5f114b3786b256c64e269b3e3a313/ai/models/ai_agent.py#L750-L755

sentry-6913801088

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

Steps
-----
1. Have a sale order with deliverable products & no payment terms;
2. confirm order & validate delivery;
3. create an invoice;
4. modify the delivery date;
5. save changes;
6. change product quantity of a line & confirm invoice.

Issue
-----
The delivery date got reset.

Cause
-----
The `_compute_show_delivery_date` method gets called, which triggers the recomputation of the `_compute_delivery_date` due it the latter having `line_ids.sale_line_ids.order_id` as its `depends`.

Due to the way how `depends` works, if any of the fields in the record chain gets modified, the compute gets triggered. In this case, because we modified a `line_ids` record by changing the quantity, it will therefore recompute the delivery date, overwriting the custom value.

Solution
--------
As we only want the delivery date to be recomputed when the `effective_date` on the order changes, we should add it to the `depends` to trigger the compute in that scenario.

In other scenarios, e.g. modifying the move or one of its lines, we don't want to trigger a recompute, which we can achieve by always including `delivery_date` via `_get_protected_vals` on create/write.

opw-4996654

Forward-Port-Of: odoo/odoo#229932
Forward-Port-Of: odoo/odoo#223946

**Note: issue not reproducible in runbot, but in fresh database** 

**Step to reproduce:**
- in fresh database, install esg module
- go to setting > invoicing > add india as Fiscal Localization
- change company name, ex "test"
- goto setting > load demo data

**Observation:**
- You will receive traceback

```
raise ParseError('while parsing %s:%s, somewhere inside\n%s' % (
odoo.tools.convert.ParseError: while parsing /home/odoo/odoo/codebase/enterprise/saas-18.4/esg/demo/demo_data.xml:567, somewhere inside
<record id="esg_emission_factor_line_assignation_4" model="esg.assignation.line">
<field name="esg_emission_factor_id" ref="esg_zero_emission_factor"/>
<field name="account_id" model="account.account" search="[('code', '=', '630000')]"/>
</record>
2025-09-11 08:45:07,458 82617 INFO esg184 odoo.addons.base.models.ir_module: module esg: no translation for language en_IN
2025-09-11 08:45:07,479 82617 ERROR esg184 odoo.sql_db: bad query: b'INSERT INTO "esg_activity_type_esg_emission_factor_rel" ("esg_emission_factor_id", "esg_activity_type_id") VALUES (1, 2) ON CONFLICT DO NOTHING'
ERROR: insert or update on table "esg_activity_type_esg_emission_factor_rel" violates foreign key constraint "esg_activity_type_esg_emission_fact_esg_emission_factor_id_fkey"
DETAIL: Key (esg_emission_factor_id)=(1) is not present in table "esg_emission_factor".
```

**Cause:**
- The demo data relies on few account.account record which belong to [USA company](https://github.com/odoo/odoo/blob/9805d09dff64de835de0c764da8c6e213d6b88aa/addons/account/data/template/account.account-generic_coa.csv#L38)
https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L569

https://github.com/odoo/enterprise/blob/b8a20b02e27322d0db5781f8d84946e54bbcbf03/esg/demo/demo_data.xml#L620-L628


- when we installed `india` Localization and changed the company name, USA company could not be created when loading demo data and hence the account records were not created, causing traceback

**Fix:**
- make demo data independent of any localization

opw-5048417

Forward-Port-Of: odoo/enterprise#94540

Current behavior before PR:

1. Since [1], in thread actions like `Mark all read` and `Unstar all`, buttons had extra height because aspect-ratio was applied even when there was no icon, making the UI look uneven.
2. Since [2], text in the messaging menu tab in mobile was not centered, leading to misaligned UI.


Desired behavior after PR is merged:

- Aspect-ratio is applied only if an icon exists in the action button, fixing the height issue.
- Added a class to center text in the messaging menu tab, improving visual alignment.

[1]: https://github.com/odoo/odoo/pull/225216
[2]: https://github.com/odoo/odoo/pull/228657

Task-5145022

1. Before/ After
<div style="display: flex;">
<img  style="margin-right: 10%;" height="145" alt="image" src="https://github.com/user-attachments/assets/a9fcffdc-5e56-454f-882a-dc5296decd47" />
<img height="136"style="margin-right: 10%;"  alt="image" src="https://github.com/user-attachments/assets/105ce999-4e15-4c67-9b62-01c666c6fc2d" />
</div>

2. Before/ After
<img width="691" height="114" alt="image" src="https://github.com/user-attachments/assets/6aa4965c-a34f-4058-bdb9-4d91f4ac9146" />
<img width="688" height="94" alt="image" src="https://github.com/user-attachments/assets/ce110144-9314-4b2f-aa30-bf12b7ecf1ec" />





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

### Steps to reproduct:

- Create 2 products: Final Product (FP), Kit Product (KP)
- On KP add a Color attribute with 2 values: Blue, Red
- Create a KIT bom for KP wtih 2 operations:
    - OP: paint it Blue, apply on Color: Blue
    - OP: paint it Red, apply on Color: Red
- Create a bom for FP with only one component line:
    - 1 x Red Kit Product
- Create a MO for 1 unit of FP
#### > The operation was not created using the kit bom

### Cause of the issue:

Even if the bom exploded to find the operations to add on the MO: https://github.com/odoo/odoo/blob/2dfcbe53c80d2d8fe5b6d9828eea90a1d214c2e4/addons/mrp/models/mrp_production.py#L579-L599 The `_skip_operation_line`:
https://github.com/odoo/odoo/blob/2dfcbe53c80d2d8fe5b6d9828eea90a1d214c2e4/addons/mrp/models/mrp_routing.py#L164-L174 is checking if the product of the main bom has the attributes of the operation rather than the kit product used as component.

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

Forward-Port-Of: odoo/odoo#229810
Forward-Port-Of: odoo/odoo#228032

Currently an error occurs when the **'Payroll: Generate pdfs'** scheduled action runs and tries to create a document for a payslip belonging to an employee who does not have a related partner.

**Prerequisites:**
- Ensure HR is enabled in `settings>Documents`

**Steps to Reproduce:**
1) Install `documents_hr_payroll` module.(with Demo) 
2) Navigate to the Employees App.
3) Select any Employee(e.g Abigail Peterson) and open form view.
>- click on **contacts** smart button.
>- Delete that Record
4) Create a confirmed Payslip for the selected Employee(e.g Abigail Peterson). 
5) Activate Developer mode and navigate to schedule Actions.
>- Search for 'Payroll: Generate pdfs'.
>- Run Manually.

Error:
`NotNullViolation: null value in column 'partner_id' of relation 'documents_access' violates not-null constraint`

Root Cause:
When the partner is deleted, the value received from `_get_document_partner` at [1]
is `False`, which later on tries to create the `documents.access`
record for the new document, it fails because no partner is available to assign
access rights, resulting in the error.


Solution:
This commit prevent Error by ensuring `_check_create_documents` method doesn't allow document creation without valid partner.

[1]: https://github.com/odoo/enterprise/blob/99a8d83edb42f172d0dd35c91743fa0c9653dcbb/documents_hr_payroll/models/hr_payslip.py#L20C1-L21 

sentry-6814524392

Forward-Port-Of: odoo/enterprise#96191
Forward-Port-Of: odoo/enterprise#92865

### Problem  
When clicking **"Export PDF"** on a 325 form that has **no generated 281.50 forms**, Odoo raised a **server error**:  


This happened because the method assumed that at least one attachment would always be generated, even if no eligible transactions were present.

---

### Steps to Reproduce  
1. Go to **Accounting → Reporting → 325 Form**.  
2. Create a 325 form for a year without any transactions on accounts tagged with **281.50**.  
3. Do not generate any 281.50 forms (`form_281_50_ids` is empty).  
4. Click **Export PDF**.  

**Result before fix:**  
- Crash with `IndexError: list index out of range`.  

---

### Solution  
- Added a safeguard check before accessing attachments.  
- If no attachments exist, raise a **UserError** instead of crashing.  

**New behavior:**  
> *“No 281.50 lines found to generate a PDF. Please record a transaction with a 281.50 tag first.”*  

This gives users a instruction on how to resolve the issue.

---

### Result After Fix  
- **User error message** replaces traceback.  
- **Normal behavior preserved** when attachments exist:  
  - One file → direct download.  
  - Multiple files → zipped download.  

---

task-5090120

Forward-Port-Of: odoo/enterprise#94877

**Issue:**

Single-day time off requests appear as multi-day events in the Calendar app when using certain tim>

**Cause:**

The `_compute_date_from_to()` method converts user-specified dates to UTC. https://github.com/odoo/odoo/blob/028e7228cb830e47a9726bef4c82793ba4590cd5/addons/hr_holidays/models/hr_leave.py#L316-L317
 The `_prepare_holidays_meeting_values()` method then uses these UTC datetime values (`holiday.date_from`, `holiday.date_to`)

In Los Angeles timezone, and for a one day leave on september 17 2025 this leads to:

- holiday.date_from: September 17, 2025 at 03:00 UTC
- holiday.date_to: September 18, 2025 at 12:00 UTC

causing a single-day leave to be displayed as a two-day event.

**After fix:**

- start_value: September 17, 2025 at 12:00
- stop_value: September 17, 2025 at 11:59

**Steps to Reproduce:**

1. Set the user timezone to "America/Los_Angeles"
2. Set the browser timezone to the same timezone
3. Create a one-day time off request (e.g., September 17, 2025)
4. Open the Calendar app: the event spans across two days

opw-4744817