Currently, the system restricts fiscal document types for both sales and 
purchases based on the company’s VAT affiliation, which prevents 
valid vendor bills from being recorded.

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT company`.
- Navigate to Accounting > Vendors > Bills.
- Create a vendor bill.
- Try to select a document type such as `FPEQ` or `FCAP`.

**Observation:**
The system hides valid vendor document types (e.g., `FPEQ`, `FCAP`) 
if they do not match the company’s VAT affiliation.

**Root Cause:**
At [1], the method `_compute_l10n_gt_edi_available_doc_types` 
filters document types using the company’s VAT affiliation 
(`l10n_gt_edi_vat_affiliation`) for all move types.

This logic is correct for sales (where the company is the issuer), 
but incorrect for purchases (where the vendor determines the document 
type). As a result, valid purchase document types are wrongly excluded.

**Fix:**
This commit updates the computation logic to:
- Apply affiliation-based filtering only for sales (`out_*`).
- Bypass the restriction for purchases (`in_*`), allowing all valid document types.

This ensures that vendor bills can include any legally valid document 
type regardless of the company’s affiliation, while preserving the 
existing restrictions for sales workflows.

[1]:
https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_gt_edi/models/account_move.py#L162-L166

opw-6099863

Forward-Port-Of: odoo/enterprise#120363
Forward-Port-Of: odoo/enterprise#113133

Problem:
When printing an invoice for a Latin American (LATAM) company, the company's document layout is not used in the header of the invoice. For example, if an Argentinian company has set up a Bubble layout as its document layout, the header of the invoice will not have the bubble.

Steps to reproduce:
1. Install l10n_ar
2. Create an invoice using Electronic Sales Journal
3. Set document layout to Bubble in the company settings
4. Print the invoice
5. Notice that the header of the invoice does not have the bubble

Cause:
Most LATAM localizations use custom headers for their reports. In report_templates of l10n_latam_invoice_document, it checks if custom_header is set to decide whether to display the custom header. If custom_header is set, the div with class "header" will be hidden, and the custom header will be displayed after the div with class "header". Since the div with class "header" contains the background image that corresponds to the document layout, the background image will not be displayed when div with class "header" is hidden.

Solution:
Instead of hiding the entire div with class "header" when custom_header is set, only hide the table inside the header. This way, the background image of the document layout will still be displayed even when a custom header is used.

opw-6204062

### Issue
When importing an electronic bill (such as a German XRechnung) that uses the Peppol EAS 'EM' (Email) with an email address as the endpoint, the import fails during the automatic partner creation

An error is logged in the chatter stating that the Peppol endpoint is not valid and should contain only letters and digits

Since 'EM' stands for Email, the system should allow the '@' character and validate the endpoint format

### Cause
While the export logic supported the 'EM' EAS, the validation flow triggered during automatic partner creation on import was too restrictive

The global regex `PEPPOL_ENDPOINT_INVALIDCHARS_RE` did not include the '@' character, causing the
validation to fail for any email address

Additionally, there was no specific format check implemented for the 'EM' EAS type to ensure the endpoint is a valid email string

### Steps to reproduce
- Install `account_edi_ubl_cii`
- Go to Accounting / Vendors / Bills
- Upload an electronic invoice containing an EM EAS and an email endpoint (you can use the added test file or the one from the ticket)

Before the fix, an error is raised in the chatter and the partner cannot be created automatically

opw-6205745

Steps to reproduce
1. Configure a Polish company with KSeF enabled.
2. Create a customer invoice using a tax tagged with K_21 (0% EU G, intra-Community supply of goods), K_12 (0% EU S, services taxed in the buyer's EU country) or Triangular Sale.
3. Send the invoice to KSeF and download the generated FA(3) XML.

Issue
The Podmiot1 (seller) block in the rendered FA(3) XML omits the PrefiksPodatnika element, see https://github.com/odoo/odoo/blob/89219a843545d8bb0cad6ea806a1167cee6289da/addons/l10n_pl_edi/data/fa3_template.xml#L34-L42. According to the official Ministry of Finance documentation (https://ksef.podatki.gov.pl/media/4u1bmhx4/information-sheet-on-the-fa-3-logical-structure.pdf, page 11), this conditional field must carry the value "PL" when the invoice documents:
- the intra-Community supply of goods,
- the provision of services referred to in Article 100 sec. 1 item 1 of the Act for EU VAT taxpayers,
- the supply carried out under a simplified triangular transaction by the second taxpayer (Article 135 sec. 1 item 4 (b) and (c)). The XSD marks the element as optional (minOccurs="0", fixed="PL") so KSeF accepts the XML, but the seller's tax reporting is still legally non-compliant for the three cases above, and the field is missing from the KSeF PDF viewer rendering.

opw-6213178

Forward-Port-Of: odoo/odoo#264659

**Steps to reproduce:**
1. Install l10n_mx_hr_payroll.
2. Create an employee with a contract date over 35 years ago (e.g., 1985).
3. Create a payslip for this employee.
4. Click on "Compute Sheet".

```Error: KeyError(36) while evaluating```

**Cause:**
The rule parameter [rule_parameter_holiday_table](https://github.com/odoo/enterprise/blob/c02c4571bb7db7197b07539ba390d4d20fdce9fe/l10n_mx_hr_payroll/data/hr_rule_parameters_data.xml#L722-L758) defines values
only up to 35 years. Seniority exceeding this range causes a KeyError.

**Solution:**
Extended the `rule_parameter_holiday_2024` table from 35 to 60 years,
following the Mexican Federal Labor Law (LFT) reform formula
(+2 days every 5-year milestone from year 6 onwards).

**NOTE:**(Alternative approach)
```python
@staticmethod
def _get_mx_holiday_days(years_worked):
    if years_worked <= 0:
        return 0
    if years_worked <= 5:
        return 12 + (years_worked - 1) * 2
    five_year_periods = (years_worked - 6) // 5
    return 22 + five_year_periods * 2
    
  ```
This approach removes the need for XML data maintenance and handles
all future seniority values mathematically without any cap issues.
  
  
opw-6090590

Forward-Port-Of: odoo/enterprise#113536

Version:
----------
- 18.0+

Steps to reproduce:
-------------------
- Install `stock` module
- Enable `Storage Locations` from Inventory settings
- Create a tracked storable product with on-hand 8 units in `Shelf 1`
- Create Delivery 1 for 5 units and click `Mark as To Do`
- Create Delivery 2 for 5 units and click `Mark as To Do`
- Verify reservations:
  - Delivery 1 reserves 5 units
  - Delivery 2 reserves remaining 3 units
- Relocate all 8 units from `Shelf 1` to `Shelf 2` using the `Relocate` action from `stock quant`
- Reopen both deliveries

Issue:
------
After relocating stock between internal locations, reservations are reassigned
in the wrong order:
- Delivery 2 becomes fully reserved with 5 units
- Delivery 1 is reduced to 3 reserved units

This incorrectly swaps the original reservation priority between deliveries.

Cause:
------
The relocation wizard starts from:
`stock.quant.relocate.action_relocate_quants()`
which calls `move_quants()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/wizard/stock_quant_relocate.py#L70

`move_quants()` validates an internal stock move through `_action_done()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_quant.py#L1572

During validation, `_synchronize_quant()` moves the stock quantity from
`Shelf 1` to `Shelf 2`.

However, the already reserved delivery move lines still reference `Shelf 1`.
This temporarily makes the source quant negative (`available_qty < 0`),
triggering `_free_reservation()`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L695-L700

Inside `_free_reservation()`, move lines are ordered using
`current_picking_first`:
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L816-L821

Since both deliveries share the same scheduled date, the fallback ordering
uses `-cand.id`, causing Delivery 2 (higher id) to be processed before
Delivery 1 (lower id).

The reservation cleanup therefore happens in this order:
- Remove Delivery 2 reservation (3 qty)
- Remove Delivery 1 reservation (5 qty)

The corresponding moves are then added to `move_to_reassign`
in the same order:
`[Delivery 2, Delivery 1]`
https://github.com/odoo/odoo/blob/d3eebbd1c27e8a039bb55cdf2a82d464e06ffa8c/addons/stock/models/stock_move_line.py#L849

Later, `move_to_reassign._action_assign()` processes the moves in recordset
order:
- Delivery 2 reserves 5 units first
- Delivery 1 only gets the remaining 3 units

As a result, reservation priority is unintentionally reversed after relocation.

Fix:
----
Before calling `_action_assign()`, reverse `move_to_reassign` 

This ensures reassignment preserves the original reservation order:
- Delivery 1 is reassigned first and recovers 5 units
- Delivery 2 receives the remaining 3 units

The reservation state therefore remains consistent before and after
internal stock relocation.

---

opw-6218256

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

Forward-Port-Of: odoo/odoo#265169

## Steps to reproduce:
	- Install l10n_be_hr_payroll module
	- Create a flexible working schedule and set the company to the Belgian company
	- Create an employee and assign the created schedule to him
	- Try to take a multi-day leave for this employee
	- Notice number of days is 0
	- Try to validate the leave
	- An exception is raised 'The following employees are not supposed to work during that period'

## Cause:
When fetching the work intervals for a belgian flexible employee we first fetch the normal work intervals then we call the same method but to filter the time credit attendance and since for the flexible employee there are not specific attendances we return the same normal work intervals and it will subtract those from the main work intervals which will result in an empty intervals to be returned

## Fix:
Check if the working schedule is flexible and if so we don't check the time credit attendances at all.

opw-6237642

Forward-Port-Of: odoo/enterprise#118870
Forward-Port-Of: odoo/enterprise#118528

### *Why this commit*: 
---
Ensures Quality Checks and Mass Produce options remain available on the
Shop Floor regardless of the "Auto-close Production" setting.

### *Steps to Reproduce*
---
1. Define a product tracked by Serial Numbers with a Manufacturing BoM.

2. Create a Quality Control Point for the product on the Manufacturing
operation.

3. In Inventory Configuration, disable "Auto-close Production" on the
Manufacturing operation type.

4. Create a Manufacturing Order (MO) and open it in the Shop Floor view.

5. If the MO has no operations, try to use Mass Produce.

### *Before this PR*
---
When auto_close_production was set to False, the Shop Floor card footer
incorrectly hid both the Quality Checks and Mass Produce buttons.
This blocked users from registering Serial Numbers and completing mandatory
quality check steps.

Additionally, for products without BoM operations, clicking Mass Produce 
triggered quality check validation instead leading to errors, preventing the
generation of serial numbers.


### *After this PR*
---
The visibility logic for Shop Floor actions is now decoupled from the closing
permission. The workflow follows this corrected sequence:

Mass Produce: Stays visible to allow serial registration and backorder
creation even if the MO cannot be closed from the Shop Floor.

Quality Checks: Remain accessible to ensure all mandatory tests are
passed before production progresses.

Close Production: Only appears if "Auto-close Production" is enabled
on the operation type.


OPW: 5473839

Forward-Port-Of: odoo/enterprise#119875
Forward-Port-Of: odoo/enterprise#103926

Currently when user adds adds quantity in barcode using lots it leads to incorrect sale order quantities.

## Steps to replicate:
- Install Sales and Barcode (no demo data).
- Enable Lots & Serial Numbers in settings.
- Create Test Product with Tracking by Lots.
- Go to Inventory > Products>Lots & Serial Numbers and create 3 lots for the product.
- Update each lot’s on-hand quantity to 10 from the product page.
- Create and confirm a Sales Order for the product (lines: qty 3 and 2 units).
- Open the delivery in the Barcode app:
   - Scan lot 2 > increase qty to 3 using +1 button
   - Scan lot 3 > increase qty to 2 using +1 button
- Validate and go to the sale order.

## Observed Behavior:
The sale order delivered quantities are flipped and a backorder is created even though the quantity for the product is satisfied.

## Root cause:
The issue occurs because when a sales order is confirmed, the system defaults to
 using lot 1 on the delivery receipt. When a user scans lot 2, the `_processBarcode` function is triggered, which calls `_findLine` at [1] to select the appropriate line on the receipt.

As the loop in `_findLine` iterates through `pageLines` with values like: 
```
[{display_name: "Test product", quantity: 3, lot_id: { name: 'lot1' }}, 
{display_name: "Test product", quantity: 2, lot_id: { name: 'lot1' }}]
```

During the first iteration, `foundLine` is set at [2] for the line with quantity 3 . Since the subsequent if condition is not satisfied, the loop hits the continue block at [3].
On the next iteration, the line with quantity 2 causes `foundLine` to be overwritten at [2], and the continue block is executed again at [3].

This results in the line with quantity 2 being selected as the line to update at the end of the function.

When the user manually increases the quantity to 3, the line that originally required quantity 2 is updated and fulfilled.
Later, when lot 3 is scanned, the line that required quantity 3 is selected for update, and manually increasing the quantity to 2 before validating the order leads to a backorder and causes the delivered quantities to be flipped.

[1]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1335-L1337 [2]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1690-L1699 [3]:
https://github.com/odoo/enterprise/blob/81eaeb4b18d849c644160234def6c69013591abe/stock_barcode/static/src/models/barcode_model.js#L1727-L1729

## Solution:
Avoid grouping lines from different moves unless using batch transfers. This ensures that backorders are not created when the barcode lines are fulfilled.

opw-5423943

Forward-Port-Of: odoo/enterprise#120098
Forward-Port-Of: odoo/enterprise#109032

The display name of the account.report.line in the general ledger report has the format of:

INVOICE NAME (invoice refs)

In the case where a client has hundreds of sales orders batched to a single invoice, the ref can
become extremely long, e.g.:

INV/2026/00001 (S12123, S12152, S12159, S12140, S12165, S12161, S12162, S12110, S12099, S12124, S12145, S12128, S12114, S12131, S12097, S12185, S12154, S12133, S12190, S12118, S12116, S12102, S12155, S12153, S12158, S12150, S12100, S12142, S12121, S12122, S12111, S12187, S12172, S12177, S12095, S12117, S12144, S12137, S12092, S12138, S12186, S12182, S12112, S12148, S12183, S12101, S12178, S12119, S12169, S12115, S12146, S12093, S12126, S12160, S12163, S12129, S12098, S12151, S12096, S12174, S12120, S12130, S12147, S12180, S12191, S12164, S12141, S12105, S12136, S12139, S12109, S12106, S12104, S12103, S12175, S12179, S12188, S12113, S12173, S12167, S12171, S12134, S12094, S12184, S12166, S12170, S12125, S12135, S12143, S12176, S12189, S12156, S12181, S12107, S12157, S12132, S12149, S12127, S12108, S12168...)

Because the length of the account.report.line is unchecked in account_general_ledger.py label
builder, the pdf can clog to one or two account.report.lines per page, skyrocketing the pdf page length.

As wkhtmltopdf processes the report from html to pdf it makes a system call openat() to the /tmp/report.footer.tmp.x.html file for EACH page of the pdf. You can see the TODO comment in the spoolTo function in wkhtmltopdf (both in Odoo and the original repo) saying that the header and footer need to be freed, on each page processing, not just null pointed.

https://github.com/odoo/wkhtmltopdf/blob/2c884bd1545b8a639847de22f24754ee5a6fc44c/src/lib/pdfconverter.cc#L794

I verified that that the number of openat calls to the /tmp/report.footer.tmp.x.html file equals the exact number of pages in the pdf to be generated if the report HAD generated successfully by setting the footer input into
_run_wkhtmltopdf to None, generating the report without footers, then separately running an strace on wkhtmltopdf when the report fails to generate. See related ticket linked at bottom.

The linux machine used on sh instances has a ulimit -n of 1024 file descriptors. Because
the footer file descriptors accumulate, once a pdf has about 1010+ pages (~a dozen fd's are allocated for other purposes), over 1024 file descriptors are opened and the system fails with:

Wkhtmltopdf failed (error code: -6). Message:
QEventDispatcherUNIXPrivate(): Unable to create
thread pipe: Too many open files
QEventDispatcherUNIXPrivate(): Can not continue
without a thread pipe

Since wkhtmltopdf is archived and Odoo has a replacement in development, I suggest that we limit the display_name of the account.report.line to 200 to keep the bloat minimized, preventing one account.report.line's name from taking up an entire page of the general ledger pdf. This allows many more batched invoices to be shown in the report and a much greater time range of data to be printed without hitting the fd limit.

I suggest changing it at the general ledger report level rather than in the account.move.line
_compute_display_name function, as we probably still want to see the full display_names at the invoice level.

On runbot, the machine has different memory constraints than on sh / local, so it hits the following error before the one above:

Wkhtmltopdf failed (error code: -11). Memory limit too low or maximum file number of subprocess
reached. Message :

Steps to Reproduce on 19.0 newdb:

1. newdb -n test_gl -v 19.0
2. ensure ulimit is set to 1024 in shell that runs odoo instance by running ulimit -n 1024 to
mimic ulimit of sh environment
3. run db with python3 odoo-bin, ensuring high enough memory constraints to simulate multi
worker sh instance, i.e.
--limit-memory-soft=12884901888
--limit-memory-hard=1288490188
4. install sales, accounting, stock
5. install demo data
6. create invoices with 100+ associated sales orders
7. generate the pdf
8. Increase the amount of invoices till the general ledger page count hits ~1010+, where you will
hit the error.

Notes:
opw-ticket-6201508

closes #118067

Forward-Port-Of: odoo/enterprise#120137
Forward-Port-Of: odoo/enterprise#118067

Steps to reproduce
1. With a Mexican POS configured, create a POS order and sign a Global Invoice for it.
2. Open a new session and partially return the order; close the session.
3. On the original order, cancel the Global Invoice through the CFDI page.
4. Try to create a new Global Invoice for the original order.

Issue
The wizard raises "Orders <REFUND-NAME> are already sent or not eligible for CFDI."

Validating the refund auto-signs an `invoice_sent` CFDI on the refund pos.order because its parent is `global_sent`, see `_l10n_mx_edi_check_autogenerate_cfdi_refund` at https://github.com/odoo/enterprise/blob/5af8048f0b0956a024d7eaeb10600eec74bdf3ee/l10n_mx_edi_pos/models/pos_order.py#L98. Cancelling the GI only flips its own document to `ginvoice_cancel`; the refund's `invoice_sent` doc stays untouched, so the refund's computed `l10n_mx_edi_cfdi_state` stays `'sent'`. The chain check in `_l10n_mx_edi_check_orders_for_global_invoice` at https://github.com/odoo/enterprise/blob/5af8048f0b0956a024d7eaeb10600eec74bdf3ee/l10n_mx_edi_pos/models/pos_order.py#L184 then rejects the refund as already sent and the new GI cannot be created.

opw-6181136

Forward-Port-Of: odoo/enterprise#120349
Forward-Port-Of: odoo/enterprise#117211

**Steps to reproduce:**
* Install `l10n_co_edi` module with DEMO DIAN mode enabled.
* Go to Accounting > Vendor > Bills and create a new bill.
* Select any Colombian partner different from `Consumidor Final`.
* Set the invoice date to 6 days in the past.
* Select the DIAN Support Documents journal and a product with UNSPSC category.
* Confirm the bill and click `Send Support Document to DIAN` after 5 PM Colombia time.

**Observed behavior:**
* An error is raised stating the issue date cannot be older than 6 days or more than 6 days in the future, even though the invoice date is within the allowed window in Colombia local time.

**Cause:**
* The date window validation in `_check_move_configuration` used `fields.Datetime.now()` which returns UTC time. Since Colombia is UTC-5, after 5 PM local time the UTC clock has already rolled over to the next calendar day, making a 6-day-old invoice appear 7 days old and failing the validation incorrectly.

**Fix:**
* Convert the current UTC datetime to the `America/Bogota` timezone and extract its local date before computing the allowed date window.
* Compare directly against `move.invoice_date` (a `date` field) instead of using `fields.Datetime.to_datetime()`, keeping the comparison consistent as `date` vs `date`.

opw-6011502

Forward-Port-Of: odoo/enterprise#120384
Forward-Port-Of: odoo/enterprise#115256

Currently, the system restricts fiscal document types for both sales and 
purchases based on the company’s VAT affiliation, which prevents 
valid vendor bills from being recorded.

**Steps to reproduce:**
- Install the `l10n_gt_edi` module and switch to a `GT company`.
- Navigate to Accounting > Vendors > Bills.
- Create a vendor bill.
- Try to select a document type such as `FPEQ` or `FCAP`.

**Observation:**
The system hides valid vendor document types (e.g., `FPEQ`, `FCAP`) 
if they do not match the company’s VAT affiliation.

**Root Cause:**
At [1], the method `_compute_l10n_gt_edi_available_doc_types` 
filters document types using the company’s VAT affiliation 
(`l10n_gt_edi_vat_affiliation`) for all move types.

This logic is correct for sales (where the company is the issuer), 
but incorrect for purchases (where the vendor determines the document 
type). As a result, valid purchase document types are wrongly excluded.

**Fix:**
This commit updates the computation logic to:
- Apply affiliation-based filtering only for sales (`out_*`).
- Bypass the restriction for purchases (`in_*`), allowing all valid document types.

This ensures that vendor bills can include any legally valid document 
type regardless of the company’s affiliation, while preserving the 
existing restrictions for sales workflows.

[1]:
https://github.com/odoo/enterprise/blob/7792926504a823590fbbe574a96994002a92fc17/l10n_gt_edi/models/account_move.py#L162-L166

opw-6099863

Forward-Port-Of: odoo/enterprise#120413
Forward-Port-Of: odoo/enterprise#113133

Version:
----------
- 18.0+


Steps to reproduce:
-------------------
1. Install *quality_control* module.
2. Go to *Settings* and enable *Storage Locations*.
3. Open Quality module go to the Quality control -> Quality points 
4. Create a *Quality Point* with:
  * *Product* set.
  * *Control per* set to *Quantity*.
  * *Operation* set to *Receipts*.
  * *Failure Location* set to *WH/Stock/Shelf1*.
5. Create a *Receipt* with demand of *2 units* for the product used in QP.
6. Mark the quality check as *To Do*.
7. Update the *Done Quantity* to *1*.
8. Open the quality check and click *Fail*.
9. Update the *Done Quantity* back to *2* and save.
10. Open the quality check again, click *Pass*, and validate the receipt.
11. Open the *Detailed Operations* to inspect move lines.

Issue:
------
* Both units (failed and passed) are moved to the *failure location*.

Cause:
------
When a user fails a move line via the QC wizard, the flow is:
  do_fail() → show_failure_message() → confirm_fail()
    → check._move_to_failure_location(failure_location_id, failed_qty)

Inside `_move_to_failure_location`, when `failed_qty == move_line.quantity`,
the condition:
 https://github.com/odoo/enterprise/blob/a33f580455a54a81d89a848f7b493d9dcc9ba2b2/quality_control/models/quality.py#L458
e.g. 1 == 1

was True even when `move.product_uom_qty = 2` (demand still 2). It only
compared the done quantities, ignoring that unfulfilled demand remained.
As a result, `move.location_dest_id` was set to the failure location.

Later, when the user increases the quantity from 1 to 2 on the move form,
the flow is:
_set_quantity → process_increase → _set_quantity_done → _prepare_move_line_vals
In `_prepare_move_line_vals` :
    'location_dest_id': self.location_dest_id.id,

https://github.com/odoo/odoo/blob/47bf284e1e9d8be0d4255418e0a3f67c74fa5114/addons/stock/models/stock_move.py#L1688

The new move line inherits `move.location_dest_id` directly, which at this
point is already the failure location. 

When the user then calls `do_pass()` on the second unit, `do_pass()` only
writes `quality_state = 'pass'` and never touches `location_dest_id`. So
the second (passed) move line silently retains the failure location.

Solution:
---------
Add the guard `move.product_uom_qty <= move_line.quantity` to the condition
so the entire move's destination is only redirected when there is genuinely
no remaining unfulfilled demand:

When demand > done qty, the else-branch runs instead: it reduces the
original move's demand and creates a new separate move pointing to the
failure location, leaving the original move's `location_dest_id` pointing
to stock. Any subsequent move lines created on the original move therefore
correctly inherit the stock destination.

---

opw-6080871

Forward-Port-Of: odoo/enterprise#120394
Forward-Port-Of: odoo/enterprise#112859