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

### 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

**Issue**
When accessing the EC Sales List report via the smart button from the VAT Return page, downloading the XML without explicitly selecting a period omits the <Month> element—even though a month is visibly preselected.

**Steps to Reproduce**
1. Install the Accounting module and Belgium localization.
2. Go to the Accounting dashboard.
3. Open the VAT Return via the "Miscellaneous Operations" section.
4. Click the smart button to access the EC Sales List report.
5. Use the gear icon to export the XML.
6. Observe that the XML <Period> section only includes the <Year>—the <Month> is missing.

**Root Cause**
If no period is explicitly selected, the report uses a period_type of "tax_period". However, this value was not handled when generating the XML, so the logic to include the \<Month> or \<Quarter> elements skipped it. As a result, only the \<Year>, which is always included, was rendered.

**Fix**
Extend the handling of tax_period to derive the period from the company’s tax periodicity settings and adjust the filter accordingly. This ensures that the generated XML always includes the \<Month> or \<Quarter> element, in addition to \<Year>, whenever the report is based on a tax period.

Opw-4702613

Forward-Port-Of: odoo/enterprise#93647
Forward-Port-Of: odoo/enterprise#89290

### 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#229975
Forward-Port-Of: odoo/odoo#229742

# Problem

Unreserve issue preventing users from validating a delivery order with 2-step delivery warehouse configuration. Introduced in the following commit: https://github.com/odoo/odoo/commit/13567aa27250f5798bbe42648eeac82241dbb780

# Steps to reproduce on the runbot:

- Activate packages
- Edit the warehouse to deliver in 2-steps
- Create a product tracked by lot
- Create two lots with 5 qty each
- Create a sale order with 10 qty and confirm
- Check the delivery order and assign: 
=> 2 units to lot1 and create a pkg for it
=> 1 units to lot1 without pkg
=> 3 to lot2 without package
- Validate the delivery and create a backorder
- go to pick backorder and try to validate
- Unreserve issue pops up
- For further details, check: [#225948](https://github.com/odoo/odoo/issues/225948)

# Solution:

Conditional subtracting limited to new lines only.

Task ID: opw-5086289


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

Forward-Port-Of: odoo/odoo#229994
Forward-Port-Of: odoo/odoo#229420