1. Set "My US Company" state to California,
2. Go to Employees > Employees > Contract Templates,
3. Click New,
4. Fill in a name and save,
5. Invalid Operation: "The employee state filing status is empty..."

A constraint ensures an l10n_us_state_filing_status is set on `hr.version`. The field is used by the salary rules.

This field used to be on `hr.employee` and was moved to `hr.version` [1]. There's two types of `hr.version` records: templates without employee_id and actual contract versions linked to an employee.

We don't want to evaluate the constraint for the templates, the only way to set a filing status is through the employee so it will always raise. This is functionally correct as well, contract templates should not have a hardcoded filing status, this should be determined per employee.

The constraint will now only raise when loading a contract template on the employee or editing the field through the employee.

[1] odoo/enterprise#83136

opw-5458566

Forward-Port-Of: odoo/enterprise#105575
Forward-Port-Of: odoo/enterprise#104990

Opening the Shop Floor via the replenishment/forecast flow can
raise a js traceback.

**Steps to produce:**
- Install `mrp` module.
- Enable `multi-step routes` from the settings.
- Inventory > Configuration > Warehouse Management > Routes.
- In Manufacture route, make sure route is Applicable On `products`.
- Inventory > Products > Products > New.
- Click on forcasted button on product > Click on replenish button > Confirm.
- Click the Manufacturing Order shown in the notification.
- Confirm the MO and click Shop Floor.

**Issue:**
A JavaScript error occurs: `TypeError: Cannot read properties of null.`

**Root cause:**
The Shop Floor view relies on the menu service to determine the current
 application name by calling `this.menu.getCurrentApp().name`. When the
 Shop Floor is opened from the replenishment/forecast flow,
 the navigation occurs through action-based triggers rather than through
 the main menu. As a result, no menu selection is performed and
 `setCurrentMenu()`[1] is not executed beforehand.This leaves the current
 application undefined, causing `menu.getCurrentApp()` to return undefined
 and leading to a js traceback when `.name` is accessed.

[1]: https://github.com/odoo/odoo/blob/c646cb61d0752250b2600413d6d63deabd1d3e6d/addons/web/static/src/webclient/menus/menu_service.js#L57-L64

simillar fix : https://github.com/odoo/enterprise/pull/93043

Note: A tour is possible but unnecessary for this small use-case.

opw-5462965
---

Forward-Port-Of: odoo/enterprise#104706

**Steps to reproduce:**
1. Install modules `sale_management` and `l10n_din5008_sale`
2. Go to Settings, Configure Document Layout and set layout to DIN 5008
3. Create a new Sale Order
4. Set a customer, add a product, and fill in the Delivery Date (Other Info)
5. Click on Print and Preview

**Issue:**
The Delivery Date (commitment_date) is not displayed on:
- The DIN 5008 sale order report
- The sale order preview (portal view)

Functional experts confirmed that the Delivery Date must be visible when using the DIN 5008 layout.

**Cause:**
The `commitment_date` field was not included in the DIN 5008 sale order report template nor in the preview view.

**Solution:**
This commit adds the Delivery Date information to:
- The DIN 5008 sale order report template
- The sale order portal/preview view

**opw-5490651**

**Before:**
<img width="560" height="145" alt="image" src="https://github.com/user-attachments/assets/fb29cda1-d668-4682-aa04-12c613f248d8" />
<img width="861" height="268" alt="image" src="https://github.com/user-attachments/assets/615f259f-e0ff-4fb5-9852-1fdd75cda4c9" />

**After:**
<img width="589" height="145" alt="image" src="https://github.com/user-attachments/assets/3f1a8d25-783a-4600-b07e-11b547bb326b" />
<img width="824" height="271" alt="image" src="https://github.com/user-attachments/assets/46b37469-5c72-4556-95e2-eaea0824c166" />

Forward-Port-Of: odoo/odoo#244917

An error currently occurs when a user tries to confirm an account move using a document number that isn’t purely numeric and contains ASCII characters other than digits.

Steps to replicate:
- Install `l10n_cl` with demo and switch to CL company.
- Create a new invoice and add customer as `Andes Innovación SpA`.
- Add a move line > Add a product, price and tax.
- Give Document Number as `11-11`.
- Save and Confirm.

Error:
```
  File /home/odoo/odoo18/enterprise/account_accountant/models/account_move.py, line 119, in action_post
    res = super().action_post()
  File /home/odoo/odoo18/community/addons/account/models/account_move.py, line 5478, in action_post
    self._post(soft=False)
  File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 161, in _post
    move._l10n_cl_create_dte()
  File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 646, in _l10n_cl_create_dte
    folio = int(self.l10n_latam_document_number)
ValueError: invalid literal for int() with base 10: '11-11'
```

Cause:
- Trying to convert the document number to integer which includes some characters that are not numeric causes the error.

Solution:
- Specifically for Chile, the document number (folio) cant include anything other than numbers (Check the Sources listed below).
- Added a constraint on the field `l10n_latam_document_number` which only allows numbers using regex.

Sources:
- https://www.sii.cl/pagina/clave/folio.htm : The official Internal Revenue Service website for Chile provides information on the standard folio, along with a sample.
- https://www.sii.cl/factura_electronica/formato_dte.pdf : Refer to PG:11, Sr No:3, which specifies that the Folio should be of type NUM, meaning it must contain only numeric characters.
- The folio is created [here] that will be sent later to the authorities in the form of xml.

[here]: https://github.com/odoo/enterprise/blob/5a8bdb586e2d0bf9948a2d0b4c5e30b3849c0414/l10n_cl_edi/template/dte_template.xml#L8

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

Forward-Port-Of: odoo/odoo#241505

Step to reproduce:
- install `l10n_it_pos`
- setup Italian fiscal printer for a pos
- refund a order and print receipt

Observation:
receives a traceback
```js
Caused by: TypeError: ctx.this.order.getRefundInfo is not a function
    at Header.template (eval at compile (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:16388:20), <anonymous>:11:62) (/web/static/lib/owl/owl.js:5807)
    at Fiber._render (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:12364:38) (/web/static/lib/owl/owl.js:1783)
    at Fiber.render (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:12356:18) (/web/static/lib/owl/owl.js:1775)
    at ComponentNode.initiateRender (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:13036:23) (/web/static/lib/owl/owl.js:2455)

```

Cause:
- A <Header/> component is used in invoices, which requires a method `getRefundInfo`.
- commit [1]  removes <Header> and its related files,
- commit [2]  removes dead code, hence removed `getRefundInfo`
- commit [3] brings back <Header>, but the method was not reintroduced

[1] https://github.com/odoo/enterprise/commit/3d532f6ee99884bce58a577eb68464e670fb059a
[2] https://github.com/odoo/enterprise/commit/1b03fe15916b7b86f79efcbb63895ae0c4363ef9
[3] https://github.com/odoo/enterprise/commit/d745a72e3f43febb3b39054dc9315eca13d86e36

Fix:
- Add the method back

After fix: 
**image from simulator**
<img width="600" height="300" alt="image" src="https://github.com/user-attachments/assets/f6caccca-caf6-477f-bf37-f942090535cc" />


opw-5485350

Forward-Port-Of: odoo/enterprise#105048

The "Not Sent" filter in Payments list view was not returning the expected records. This was due to an incorrect domain condition in the search view.

This commit updates the filter logic to properly identify payments that haven't been processed or sent, ensuring the filter displays the correct records to the user.

**Description of the issue/feature this PR addresses:**
This PR fixes a bug in the "Not Sent" search filter within the Payment views (Account Payments). Currently, the filter fails to accurately identify and display records that have not been sent, leading to an empty or incorrect list of results regardless of the sending payment's actual status.

**Current behavior before PR:**
When a user applies the "Not Sent" filter in the Payments list view (including both Customer and Vendor payments), the system returns incorrect records or no records at all. This is caused by an inconsistent domain definition that doesn't align with the internal field tracking the "sent" status of the payment.

**Desired behavior after PR is merged:**
The "Not Sent" filter will correctly filter the list to show only those payments where the "Sent" status is not True. This will provide users with an accurate view of pending actions for both Customer and Vendor payments, ensuring consistency across the accounting module.

**Steps to reproduce:**
1. Navigate to the Accounting (or Invoicing) module.
2. Go to Vendors > Payments or Customers > Payments (the issue is global).
3. Ensure there are several payments in the list, some marked as "Sent" and others not yet sent.
4. Click on the Filters dropdown menu in the search bar.
5. Select the "Not Sent" filter.
6. Observe the results: Notice that the list either becomes empty or continues to show records that do not match the "Not Sent" criteria, failing to filter the data correctly.

**video**
https://drive.google.com/file/d/1NTKQ1tHWyZWfs3CPolfDTOMrqaDD9OcN/view
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#245487

The SYSCOHADA gross margin is defined on page 330 - 331 of the document [Guide-d-application-du-SYSCOHADA.pdf](https://www.ohada.com/uploads/actualite/3504/Guide-d-application-du-SYSCOHADA.pdf). It is TA (701) - RA (601) +/- RB (6031). TA and RA should always be positive and negative, respectively.

In the report "Profit and Loss (SYSCOHADA)", the line RA is negated. XA then subtracts this value from TA, adding the two values instead of subtracting them.

Steps to reproduce:

1. Create a new company on runbot.
2. In Accounting > Configuration > Settings, set their Fiscal Localization to Ginea - SYSCOHADA for Companies.
3. Make a MISC journal entry.
    1. Set a credit of 110,000,000 on account 701100 and balance it with 411100.
    5. Set a debit of 75,000,000 on account 601100 and balance it with 401100.
    6. Set a credit of 5,000,000 on account 603100 and balance it with 411100.
7. Post the entry.
8. Navigate to Accounting > Reports > Profit and Loss.
9. Set the l10n version, Profit and Loss (SYSCOHADA).
10. Set the current date.
11. See XA = 110 million + 75 million + 5 million = 190 million; this does not match the example given on pg 357 of Guide-d-application-du-SYSCOHADA.pdf, where XA = 40 million.

[opw-5482300](https://www.odoo.com/odoo/project.task/project.task/5482300)

Forward-Port-Of: odoo/enterprise#104736
Forward-Port-Of: odoo/enterprise#104479

…records in hr_recruitment_reports demo data

Steps to reproduce:
1. Load demo data for hr_recruitment_reports module
2. Check applicant records in chatter
3. Observe that stage change messages don't show "Stage changed" label
4. Review mail.tracking.value records for applicant stage changes
5. Observe incorrect stage name "Initial Qualification" instead of "Qualification"

Bug cause:
mail.message records for applicant stage changes were missing the subtype_id field, which defaults to an incorrect subtype (mt_note instead of mt_applicant_stage_changed). This caused the messages to be treated as internal notes rather than stage change notifications.

Additionally, mail.tracking.value records used "Initial Qualification" as the old_value_char or new_value_char, which doesn't match the actual stage name defined in hr_recruitment module. The correct stage name is simply "Qualification" (ref: hr_recruitment.stage_job1).

Solution:
- Add subtype_id field with reference to hr_recruitment.mt_applicant_stage_changed to all mail.message records that track applicant stage transitions
- This ensures stage change events are properly identified and displayed in chatter with the correct "Stage changed" label
- Update old_value_char and new_value_char fields in mail.tracking.value records to use the correct stage name "Qualification" instead of "Initial Qualification"
- Ensures consistency with actual stage names and proper display in applicant chatter history

Affected records: 20 mail.message records in hr_recruitment_reports_demo.xml

Task Id:5454691

Forward-Port-Of: odoo/enterprise#105278

### Issue:
On a Mexican sale order, it was possible to have an invalid partner address while `CFDI to Public` was not enabled
In this situation, an online payment could be initiated, but a silent error occurred during move validation:
the transaction was created, but the payment was never recorded, and no error appeared in the portal or the SO chatter

### Cause:
The CFDI validation error is raised internally but never surfaced to the user
https://github.com/odoo/enterprise/pull/91655
The PO (MIAL) recommended automatically enabling `CFDI to Public` when the partner address is incomplete,
forcing the user to complete the data This also ensures that the payment can be confirmed properly

### Steps to reproduce:
- Install `l10n_mx_edi_sale` and switch to the MX company
- Configure a Payment Provider and Payment Method (e.g., demo)
- Create a customer without ZIP or country
- Create a Sale Order for that customer
- In Other Info, set Online Payment to 100%
- Send the quotation and open the link in a private window
- Sign and Pay

Before the fix: the transaction is created, but no payment is recorded, and no error is shown

opw-5023724

Forward-Port-Of: odoo/enterprise#101881

### Issue:

Applying a push rule in attempt to reach a precise sublocation will not adapt the destination of the move based on the `final_location_id` but solely base the destination based on the push rule.

This is sub-optimal as the existence of an other push rule from this parent location to the sublocation is quite unlikely and validating that new move will therefore not push the product to its `location_final_id`.

### Concrete problematic example:

For instance, the `property_stock_customer` (Customer location) provides a precise `final_dest_id` to deliver the customer. While, in one step delivery (not relying on push mechanic), confirming a delivery will generate a delivery with `location_dest` set to the precise Customer location because of pull rules, in two steps, the final delivery ends up targeting the general `Partner/Customer` location.

This is particularly impactful in case of automatic batching based on destination location.

### Steps to reproduce:

- In the settings enable: Multi-Steps routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Set your warehouse to delivery in 2 steps
- Create a contact say BOB and in the sale & purchase tab of its form set the Customer Location to a sublocation of Partners/Customers say: Partners/Customers/BOB
- Create and confirm a sale order for BOB for 1 unit of a any product
- Validate the pick
#### > The delivery and its move have `Partner/Customer` as `move_dest_id`.

### Cause of the issue:

During the `_run_push`, we only adapt the `location_dest_id` to match the `location_final_id` in the case where the new move skip push: https://github.com/odoo/odoo/blob/61d2fb3bb3281f3455490ac6033b95e3c50b4e2b/addons/stock/models/stock_rule.py#L241-L245 However, in the present case where you push to a parent location of `location_final_id` the move does not `skip_push`: https://github.com/odoo/odoo/blob/61d2fb3bb3281f3455490ac6033b95e3c50b4e2b/addons/stock/models/stock_move.py#L2034-L2037 and the `location_dest` is the one of the rule:
https://github.com/odoo/odoo/blob/61d2fb3bb3281f3455490ac6033b95e3c50b4e2b/addons/stock/models/stock_rule.py#L241-L242 https://github.com/odoo/odoo/blob/61d2fb3bb3281f3455490ac6033b95e3c50b4e2b/addons/stock/models/stock_rule.py#L266

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

Forward-Port-Of: odoo/odoo#245701
Forward-Port-Of: odoo/odoo#243828

The SYSCOHADA gross margin is defined on page 330 - 331 of the document [Guide-d-application-du-SYSCOHADA.pdf](https://www.ohada.com/uploads/actualite/3504/Guide-d-application-du-SYSCOHADA.pdf). It is TA (701) - RA (601) +/- RB (6031). TA and RA should always be positive and negative, respectively.

In the report "Profit and Loss (SYSCOHADA)", the line RA is negated. XA then subtracts this value from TA, adding the two values instead of subtracting them.

Steps to reproduce:

1. Create a new company on runbot.
2. In Accounting > Configuration > Settings, set their Fiscal Localization to Ginea - SYSCOHADA for Companies.
3. Make a MISC journal entry.
    1. Set a credit of 110,000,000 on account 701100 and balance it with 411100.
    5. Set a debit of 75,000,000 on account 601100 and balance it with 401100.
    6. Set a credit of 5,000,000 on account 603100 and balance it with 411100.
7. Post the entry.
8. Navigate to Accounting > Reports > Profit and Loss.
9. Set the l10n version, Profit and Loss (SYSCOHADA).
10. Set the current date.
11. See XA = 110 million + 75 million + 5 million = 190 million; this does not match the example given on pg 357 of Guide-d-application-du-SYSCOHADA.pdf, where XA = 40 million.

[opw-5482300](https://www.odoo.com/odoo/project.task/project.task/5482300)

Forward-Port-Of: odoo/enterprise#104736
Forward-Port-Of: odoo/enterprise#104479

### Issue:
On a Mexican sale order, it was possible to have an invalid partner address while `CFDI to Public` was not enabled
In this situation, an online payment could be initiated, but a silent error occurred during move validation:
the transaction was created, but the payment was never recorded, and no error appeared in the portal or the SO chatter

### Cause:
The CFDI validation error is raised internally but never surfaced to the user
https://github.com/odoo/enterprise/pull/91655
The PO (MIAL) recommended automatically enabling `CFDI to Public` when the partner address is incomplete,
forcing the user to complete the data This also ensures that the payment can be confirmed properly

### Steps to reproduce:
- Install `l10n_mx_edi_sale` and switch to the MX company
- Configure a Payment Provider and Payment Method (e.g., demo)
- Create a customer without ZIP or country
- Create a Sale Order for that customer
- In Other Info, set Online Payment to 100%
- Send the quotation and open the link in a private window
- Sign and Pay

Before the fix: the transaction is created, but no payment is recorded, and no error is shown

opw-5023724

Forward-Port-Of: odoo/enterprise#101881

### Issue:
On a Mexican sale order, it was possible to have an invalid partner address while `CFDI to Public` was not enabled
In this situation, an online payment could be initiated, but a silent error occurred during move validation:
the transaction was created, but the payment was never recorded, and no error appeared in the portal or the SO chatter

### Cause:
The CFDI validation error is raised internally but never surfaced to the user
https://github.com/odoo/enterprise/pull/91655
The PO (MIAL) recommended automatically enabling `CFDI to Public` when the partner address is incomplete,
forcing the user to complete the data This also ensures that the payment can be confirmed properly

### Steps to reproduce:
- Install `l10n_mx_edi_sale` and switch to the MX company
- Configure a Payment Provider and Payment Method (e.g., demo)
- Create a customer without ZIP or country
- Create a Sale Order for that customer
- In Other Info, set Online Payment to 100%
- Send the quotation and open the link in a private window
- Sign and Pay

Before the fix: the transaction is created, but no payment is recorded, and no error is shown

opw-5023724

Forward-Port-Of: odoo/enterprise#101881

Backport of https://github.com/odoo/enterprise/pull/101643.

Original commit message for completeness:

Calling Avatax without lines results in an error and blocks flows:

```
Odoo could not fetch the taxes related to MXXX - SOXXX/XXX.
Please check the status of `Sales Order XXX` in the AvaTax portal.
Transactions must have at least one line.
```

There are various cases this can happen:

1/ if industry_fsm_stock is installed, empty orders are confirmed [1], 2/ if you put the end_date of a subscription before the next_invoice_date,
   then none of the lines are considered invoiceable [2] and you get the
   error when viewing the subscription in the portal

This commit filters out orders without lines.

It's also possible to filter this on the level of the models by doing it in _get_and_set_external_taxes_on_eligible_records(). However, this means doing it separately for each model, and requires every implementer do it manually.

[1] https://github.com/odoo/enterprise/blob/703e7fd413e93a8287da98286aa93b9699ae3e96/industry_fsm_stock/models/project_task.py#L159
[2] https://github.com/odoo/enterprise/blob/c7bf4367a9bf6757a36a9f34a872a6e35a19a3a5/sale_subscription/models/sale_order_line.py#L475

opw-5214609
opw-5247727
opw-5311132
opw-5385960

Forward-Port-Of: odoo/enterprise#105587

Description of the issue/feature this PR addresses:
This issue occured because in the previous update we add a condition to restrict multiple tax groups excluding the STLG.
Apparently there is a case where some users create their own tax groups (for example for PPH) so when they want to print an efaktur it will raise an error.

Current behavior before PR:
If a user create their own tax with a new tax group (outside of the 6 groups defined in `l10n_id`) and use it in invoice line along with one of the 6 tax groups excluding the STLG then it will blocked the print efaktur because it will raise an error  

Desired behavior after PR is merged:
- The restriction in tax groups only applied for the 6 tax groups in l10n_id so if an invoice line
  has multiple tax groups as long as there no more than one of the 6 tax groups excluding the STLG then
  it should be able to print the efaktur.
- Also when building the efaktur coretax value, the new tax group should not be included in the regular_tax
  variable which will cause the value to be 11/12 of the original value.
- Add new condition to block the print efaktur if there is a tax inside the invoice but none of it
  belong to the 6 ppn tax groups (there is already a condition to block if no tax is given, but now since there
  are cases where they use tax group outside of the defined tax groups then it will print the efaktur)
- If an invoice line does not have any ppn_tax_groups but there are other line in the same invoice
  that has it then it will still be able to print the efaktur, but the line without the ppn tax will
  have the OtherTaxBase and VATRate set to zero which will calculate the VAT as 0 too.

[5434656](https://www.odoo.com/odoo/project.task/5434656)


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

Forward-Port-Of: odoo/odoo#244760
Forward-Port-Of: odoo/odoo#241979

An error currently occurs when a user tries to confirm an account move using a document number that isn’t purely numeric and contains ASCII characters other than digits.

Steps to replicate:
- Install `l10n_cl` with demo and switch to CL company.
- Create a new invoice and add customer as `Andes Innovación SpA`.
- Add a move line > Add a product, price and tax.
- Give Document Number as `11-11`.
- Save and Confirm.

Error:
```
  File /home/odoo/odoo18/enterprise/account_accountant/models/account_move.py, line 119, in action_post
    res = super().action_post()
  File /home/odoo/odoo18/community/addons/account/models/account_move.py, line 5478, in action_post
    self._post(soft=False)
  File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 161, in _post
    move._l10n_cl_create_dte()
  File /home/odoo/odoo18/enterprise/l10n_cl_edi/models/account_move.py, line 646, in _l10n_cl_create_dte
    folio = int(self.l10n_latam_document_number)
ValueError: invalid literal for int() with base 10: '11-11'
```

Cause:
- Trying to convert the document number to integer which includes some characters that are not numeric causes the error.

Solution:
- Specifically for Chile, the document number (folio) cant include anything other than numbers (Check the Sources listed below).
- Added a constraint on the field `l10n_latam_document_number` which only allows numbers using regex.

Sources:
- https://www.sii.cl/pagina/clave/folio.htm : The official Internal Revenue Service website for Chile provides information on the standard folio, along with a sample.
- https://www.sii.cl/factura_electronica/formato_dte.pdf : Refer to PG:11, Sr No:3, which specifies that the Folio should be of type NUM, meaning it must contain only numeric characters.
- The folio is created [here] that will be sent later to the authorities in the form of xml.

[here]: https://github.com/odoo/enterprise/blob/5a8bdb586e2d0bf9948a2d0b4c5e30b3849c0414/l10n_cl_edi/template/dte_template.xml#L8

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

Forward-Port-Of: odoo/odoo#241505

**Steps to reproduce:**
1. Install modules `sale_management` and `l10n_din5008_sale`
2. Go to Settings, Configure Document Layout and set layout to DIN 5008
3. Create a new Sale Order
4. Set a customer, add a product, and fill in the Delivery Date (Other Info)
5. Click on Print and Preview

**Issue:**
The Delivery Date (commitment_date) is not displayed on:
- The DIN 5008 sale order report
- The sale order preview (portal view)

Functional experts confirmed that the Delivery Date must be visible when using the DIN 5008 layout.

**Cause:**
The `commitment_date` field was not included in the DIN 5008 sale order report template nor in the preview view.

**Solution:**
This commit adds the Delivery Date information to:
- The DIN 5008 sale order report template
- The sale order portal/preview view

**opw-5490651**

**Before:**
<img width="560" height="145" alt="image" src="https://github.com/user-attachments/assets/fb29cda1-d668-4682-aa04-12c613f248d8" />
<img width="861" height="268" alt="image" src="https://github.com/user-attachments/assets/615f259f-e0ff-4fb5-9852-1fdd75cda4c9" />

**After:**
<img width="589" height="145" alt="image" src="https://github.com/user-attachments/assets/3f1a8d25-783a-4600-b07e-11b547bb326b" />
<img width="824" height="271" alt="image" src="https://github.com/user-attachments/assets/46b37469-5c72-4556-95e2-eaea0824c166" />

Forward-Port-Of: odoo/odoo#244917

The SYSCOHADA gross margin is defined on page 330 - 331 of the document [Guide-d-application-du-SYSCOHADA.pdf](https://www.ohada.com/uploads/actualite/3504/Guide-d-application-du-SYSCOHADA.pdf). It is TA (701) - RA (601) +/- RB (6031). TA and RA should always be positive and negative, respectively.

In the report "Profit and Loss (SYSCOHADA)", the line RA is negated. XA then subtracts this value from TA, adding the two values instead of subtracting them.

Steps to reproduce:

1. Create a new company on runbot.
2. In Accounting > Configuration > Settings, set their Fiscal Localization to Ginea - SYSCOHADA for Companies.
3. Make a MISC journal entry.
    1. Set a credit of 110,000,000 on account 701100 and balance it with 411100.
    5. Set a debit of 75,000,000 on account 601100 and balance it with 401100.
    6. Set a credit of 5,000,000 on account 603100 and balance it with 411100.
7. Post the entry.
8. Navigate to Accounting > Reports > Profit and Loss.
9. Set the l10n version, Profit and Loss (SYSCOHADA).
10. Set the current date.
11. See XA = 110 million + 75 million + 5 million = 190 million; this does not match the example given on pg 357 of Guide-d-application-du-SYSCOHADA.pdf, where XA = 40 million.

[opw-5482300](https://www.odoo.com/odoo/project.task/project.task/5482300)

Forward-Port-Of: odoo/enterprise#104736
Forward-Port-Of: odoo/enterprise#104479

Steps to reproduce the bug

- Create a storable product P1:
  - Tracking: Serial Number
- Log in as Marc Demo
- Create a sales order with 1 unit of P1
- Validate the delivery using serial number SN1
- Log in as Mitchell Admin
- Go to Settings:
  - Manage Users
    - Mitchell Admin
      - Sales: User: own documents only
- Go to the Serial Numbers list view:
  - Try to open SN1

**Problem:**
An access error is triggered:

```
Uh-oh! Looks like you have stumbled upon some top-secret records.

Sorry, Mitchell Admin (id=2) doesn't have 'read' access to:
- Sales Order Line, S00025 - P1 (Deco Addict) (sale.order.line: 51)

Blame the following rules:
- Personal Order Lines
```

When clicking on SN1, the `stock.lot` form view.
it's contains the field "sale_order_count", which is a computed field that needs to access all `sale.order` records using the serial number in order to compute the count.

Since Mitchell Admin is restricted to his own sales orders only, an access error is raised during the computation.

There is also a many2many view widget that triggers an access errors. This widget can be removed since the smart button is now available. The widget has already been removed in v19.

**Solution:**
In this view, any stock user, admin or not, must be able to see how many sales orders use a given serial number, regardless of whether those sales orders belong to them or not.

opw-5400731

Forward-Port-Of: odoo/odoo#244570

The "Not Sent" filter in Payments list view was not returning the expected records. This was due to an incorrect domain condition in the search view.

This commit updates the filter logic to properly identify payments that haven't been processed or sent, ensuring the filter displays the correct records to the user.

**Description of the issue/feature this PR addresses:**
This PR fixes a bug in the "Not Sent" search filter within the Payment views (Account Payments). Currently, the filter fails to accurately identify and display records that have not been sent, leading to an empty or incorrect list of results regardless of the sending payment's actual status.

**Current behavior before PR:**
When a user applies the "Not Sent" filter in the Payments list view (including both Customer and Vendor payments), the system returns incorrect records or no records at all. This is caused by an inconsistent domain definition that doesn't align with the internal field tracking the "sent" status of the payment.

**Desired behavior after PR is merged:**
The "Not Sent" filter will correctly filter the list to show only those payments where the "Sent" status is not True. This will provide users with an accurate view of pending actions for both Customer and Vendor payments, ensuring consistency across the accounting module.

**Steps to reproduce:**
1. Navigate to the Accounting (or Invoicing) module.
2. Go to Vendors > Payments or Customers > Payments (the issue is global).
3. Ensure there are several payments in the list, some marked as "Sent" and others not yet sent.
4. Click on the Filters dropdown menu in the search bar.
5. Select the "Not Sent" filter.
6. Observe the results: Notice that the list either becomes empty or continues to show records that do not match the "Not Sent" criteria, failing to filter the data correctly.

**video**
https://drive.google.com/file/d/1NTKQ1tHWyZWfs3CPolfDTOMrqaDD9OcN/view
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#245487

### Issue:

Applying a push rule in attempt to reach a precise sublocation will not adapt the destination of the move based on the `final_location_id` but solely base the destination based on the push rule.

This is sub-optimal as the existence of an other push rule from this parent location to the sublocation is quite unlikely and validating that new move will therefore not push the product to its `location_final_id`.

### Concrete problematic example:

For instance, the `property_stock_customer` (Customer location) provides a precise `final_dest_id` to deliver the customer. While, in one step delivery (not relying on push mechanic), confirming a delivery will generate a delivery with `location_dest` set to the precise Customer location because of pull rules, in two steps, the final delivery ends up targeting the general `Partner/Customer` location.

This is particularly impactful in case of automatic batching based on destination location.

### Steps to reproduce:

- In the settings enable: Multi-Steps routes
- Inventory > Configuration > Warehouse Management > Warehouses
- Set your warehouse to delivery in 2 steps
- Create a contact say BOB and in the sale & purchase tab of its form set the Customer Location to a sublocation of Partners/Customers say: Partners/Customers/BOB
- Create and confirm a sale order for BOB for 1 unit of a any product
- Validate the pick
#### > The delivery and its move have `Partner/Customer` as `move_dest_id`.

### Cause of the issue:

During the `_run_push`, we only adapt the `location_dest_id` to match the `location_final_id` in the case where the new move skip push: https://github.com/odoo/odoo/blob/61d2fb3bb3281f3455490ac6033b95e3c50b4e2b/addons/stock/models/stock_rule.py#L241-L245 However, in the present case where you push to a parent location of `location_final_id` the move does not `skip_push`: https://github.com/odoo/odoo/blob/61d2fb3bb3281f3455490ac6033b95e3c50b4e2b/addons/stock/models/stock_move.py#L2034-L2037 and the `location_dest` is the one of the rule:
https://github.com/odoo/odoo/blob/61d2fb3bb3281f3455490ac6033b95e3c50b4e2b/addons/stock/models/stock_rule.py#L241-L242 https://github.com/odoo/odoo/blob/61d2fb3bb3281f3455490ac6033b95e3c50b4e2b/addons/stock/models/stock_rule.py#L266

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

Forward-Port-Of: odoo/odoo#245314
Forward-Port-Of: odoo/odoo#243828

The SYSCOHADA gross margin is defined on page 330 - 331 of the document [Guide-d-application-du-SYSCOHADA.pdf](https://www.ohada.com/uploads/actualite/3504/Guide-d-application-du-SYSCOHADA.pdf). It is TA (701) - RA (601) +/- RB (6031). TA and RA should always be positive and negative, respectively.

In the report "Profit and Loss (SYSCOHADA)", the line RA is negated. XA then subtracts this value from TA, adding the two values instead of subtracting them.

Steps to reproduce:

1. Create a new company on runbot.
2. In Accounting > Configuration > Settings, set their Fiscal Localization to Ginea - SYSCOHADA for Companies.
3. Make a MISC journal entry.
    1. Set a credit of 110,000,000 on account 701100 and balance it with 411100.
    5. Set a debit of 75,000,000 on account 601100 and balance it with 401100.
    6. Set a credit of 5,000,000 on account 603100 and balance it with 411100.
7. Post the entry.
8. Navigate to Accounting > Reports > Profit and Loss.
9. Set the l10n version, Profit and Loss (SYSCOHADA).
10. Set the current date.
11. See XA = 110 million + 75 million + 5 million = 190 million; this does not match the example given on pg 357 of Guide-d-application-du-SYSCOHADA.pdf, where XA = 40 million.

[opw-5482300](https://www.odoo.com/odoo/project.task/project.task/5482300)

Forward-Port-Of: odoo/enterprise#104736
Forward-Port-Of: odoo/enterprise#104479

After this commit https://github.com/odoo-dev/enterprise/commit/6c33bde74342b634d9f6fbda4ef407ffe9bac54f we introduced a new left
join which seems that it slowed down the query a lot. So the report doesn't load at all if we have a lot of records.

In this PR we are introducing CROSS LATERAL JOIN as we want to generate only the
the relevant dates not all dates between the min starting date and max ending date
of all slots.

Query plan after modification https://explain.dalibo.com/plan/eh5293ba2354f43c

The testing cardinality of the tables:
`planning.slot` 7178 rows
`hr.employee` 332 rows
`resource.resource` 332 rows
`resource_calendar_leaves` 4061 rows
`account_analytic_line` 267376 rows
`generate_series()` will produce 206417 rows

| Before                                  | After |
|-----------------------------------------|-------|
| Query keep being active with no results | ~2s   |

opw-5089052

Forward-Port-Of: odoo/enterprise#105538
Forward-Port-Of: odoo/enterprise#102283

**Steps to reproduce:**
- Go to Appointment app
- Edit an appointment type
- Ensure its availability is on resources
- Set duration to 1 hour
- Add a schedule slot ending in 00:00
- Save and go to the website page of the appointment
- Last slot is not showing (23:00-00:00)

**Issue:**
When computing the appointment slots of a resource using time range,
the end of day is considered as an unavaibility resource slot with this interval
in `_get_unavailable_intervals`:
`i_start = 23:59:59.999999` `i_stop = 00:00`
this conflicts with the given range (23:00-00:00)
in `self._slot_availability_is_resource_available`

It comes from `_attendance_intervals_batch`, as `float_to_time(24.0)`
is converted to `time.max` (23:59:59.999999) by:
`day_to = datetime.combine(day, float_to_time(attendance.hour_to))`
This introduces the microsecond unavaibility at the end of the day, which
blocks the booking.

(it's working properly for availability on users appointments)

**Fix:**
Changed the condition so that 23:59:59.999999 is considered as equal to 00:00.

opw-5163892

Forward-Port-Of: odoo/enterprise#104927
Forward-Port-Of: odoo/enterprise#100853

1. Set "My US Company" state to California,
2. Go to Employees > Employees > Contract Templates,
3. Click New,
4. Fill in a name and save,
5. Invalid Operation: "The employee state filing status is empty..."

A constraint ensures an l10n_us_state_filing_status is set on `hr.version`. The field is used by the salary rules.

This field used to be on `hr.employee` and was moved to `hr.version` [1]. There's two types of `hr.version` records: templates without employee_id and actual contract versions linked to an employee.

We don't want to evaluate the constraint for the templates, the only way to set a filing status is through the employee so it will always raise. This is functionally correct as well, contract templates should not have a hardcoded filing status, this should be determined per employee.

The constraint will now only raise when loading a contract template on the employee or editing the field through the employee.

[1] odoo/enterprise#83136

opw-5458566

Forward-Port-Of: odoo/enterprise#105575
Forward-Port-Of: odoo/enterprise#104990

Previously, generating the budget.report table was necessary to trigger _compute_all for budget.line fields. This table was built using three separate queries with a UNION operator. Because of the UNION, any filtering (like on specific budget_line_ids) happened after the full, unfiltered table was generated.

This post-filtering caused slowness, especially in nested loop joins with large tables like account.analytic.line. This commit optimizes performance by pushing the filter condition (using specific budget_line_ids) directly down into the three underlying queries. This reduces the number of budget.line records processed, speeding up joins and overall computation.

The benchmark below is done on a database that has **66396** `budget.line` records and **928567** `account.analytic.line` records. Opening a budget report for a specific year, only applied the filter with **40** `budget.line` records.

| Scenario | Execution Time |
| :--- | :--- |
| **Before this Commit** | **60.00 seconds**
| **After this Commit** | **1.84 seconds**

opw-5150569

Forward-Port-Of: odoo/enterprise#102918
Forward-Port-Of: odoo/enterprise#99096

Steps to reproduce:
-------------------
1. Install pos_settle_due and accountant
2. In Accounting settings, enable "Sales Credit Limit"
3. Create a new customer, enable its "Partner Limit" and set it to 100
4. Open PoS, select that partner, and select products such that the total exceeds 100

Notice that even though we have exceeded that partner's limit of 100, there are no indicators on the customer button (orange background on hover), nor there are warnings on the partners list modal nor on the payment page.

Why the bug
-----------
In `getPartnerCredit`, we are using `order.amount_total` to get the current ordre amount, however, this field is `undefined` for a new order and it's been assigned a value in `setOrderPrices`, which since [9538698](https://github.com/odoo/odoo/commit/9538698), is only called before sending the order to the backend.

The fix
-------
Now we read the total amount from the getter `order.priceIncl`, and round it as we would do in `setOrderPrices`.

opw-5489975

Forward-Port-Of: odoo/enterprise#105548
Forward-Port-Of: odoo/enterprise#104591

Opening the Shop Floor via the replenishment/forecast flow can
raise a js traceback.

**Steps to produce:**
- Install `mrp` module.
- Enable `multi-step routes` from the settings.
- Inventory > Configuration > Warehouse Management > Routes.
- In Manufacture route, make sure route is Applicable On `products`.
- Inventory > Products > Products > New.
- Click on forcasted button on product > Click on replenish button > Confirm.
- Click the Manufacturing Order shown in the notification.
- Confirm the MO and click Shop Floor.

**Issue:**
A JavaScript error occurs: `TypeError: Cannot read properties of null.`

**Root cause:**
The Shop Floor view relies on the menu service to determine the current
 application name by calling `this.menu.getCurrentApp().name`. When the
 Shop Floor is opened from the replenishment/forecast flow,
 the navigation occurs through action-based triggers rather than through
 the main menu. As a result, no menu selection is performed and
 `setCurrentMenu()`[1] is not executed beforehand.This leaves the current
 application undefined, causing `menu.getCurrentApp()` to return undefined
 and leading to a js traceback when `.name` is accessed.

[1]: https://github.com/odoo/odoo/blob/c646cb61d0752250b2600413d6d63deabd1d3e6d/addons/web/static/src/webclient/menus/menu_service.js#L57-L64

simillar fix : https://github.com/odoo/enterprise/pull/93043

Note: A tour is possible but unnecessary for this small use-case.

opw-5462965
---

Forward-Port-Of: odoo/enterprise#104706

Step to reproduce:
- install `l10n_it_pos`
- setup Italian fiscal printer for a pos
- refund a order and print receipt

Observation:
receives a traceback
```js
Caused by: TypeError: ctx.this.order.getRefundInfo is not a function
    at Header.template (eval at compile (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:16388:20), <anonymous>:11:62) (/web/static/lib/owl/owl.js:5807)
    at Fiber._render (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:12364:38) (/web/static/lib/owl/owl.js:1783)
    at Fiber.render (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:12356:18) (/web/static/lib/owl/owl.js:1775)
    at ComponentNode.initiateRender (https://97822380-19-0-design-theme.runbot118.odoo.com/web/assets/debug/point_of_sale.assets_prod.js:13036:23) (/web/static/lib/owl/owl.js:2455)

```

Cause:
- A <Header/> component is used in invoices, which requires a method `getRefundInfo`.
- commit [1]  removes <Header> and its related files,
- commit [2]  removes dead code, hence removed `getRefundInfo`
- commit [3] brings back <Header>, but the method was not reintroduced

[1] https://github.com/odoo/enterprise/commit/3d532f6ee99884bce58a577eb68464e670fb059a
[2] https://github.com/odoo/enterprise/commit/1b03fe15916b7b86f79efcbb63895ae0c4363ef9
[3] https://github.com/odoo/enterprise/commit/d745a72e3f43febb3b39054dc9315eca13d86e36

Fix:
- Add the method back

After fix: 
**image from simulator**
<img width="600" height="300" alt="image" src="https://github.com/user-attachments/assets/f6caccca-caf6-477f-bf37-f942090535cc" />


opw-5485350

Forward-Port-Of: odoo/enterprise#105048

The SYSCOHADA gross margin is defined on page 330 - 331 of the document [Guide-d-application-du-SYSCOHADA.pdf](https://www.ohada.com/uploads/actualite/3504/Guide-d-application-du-SYSCOHADA.pdf). It is TA (701) - RA (601) +/- RB (6031). TA and RA should always be positive and negative, respectively.

In the report "Profit and Loss (SYSCOHADA)", the line RA is negated. XA then subtracts this value from TA, adding the two values instead of subtracting them.

Steps to reproduce:

1. Create a new company on runbot.
2. In Accounting > Configuration > Settings, set their Fiscal Localization to Ginea - SYSCOHADA for Companies.
3. Make a MISC journal entry.
    1. Set a credit of 110,000,000 on account 701100 and balance it with 411100.
    5. Set a debit of 75,000,000 on account 601100 and balance it with 401100.
    6. Set a credit of 5,000,000 on account 603100 and balance it with 411100.
7. Post the entry.
8. Navigate to Accounting > Reports > Profit and Loss.
9. Set the l10n version, Profit and Loss (SYSCOHADA).
10. Set the current date.
11. See XA = 110 million + 75 million + 5 million = 190 million; this does not match the example given on pg 357 of Guide-d-application-du-SYSCOHADA.pdf, where XA = 40 million.

[opw-5482300](https://www.odoo.com/odoo/project.task/project.task/5482300)

Forward-Port-Of: odoo/enterprise#104736
Forward-Port-Of: odoo/enterprise#104479

The SYSCOHADA gross margin is defined on page 330 - 331 of the document [Guide-d-application-du-SYSCOHADA.pdf](https://www.ohada.com/uploads/actualite/3504/Guide-d-application-du-SYSCOHADA.pdf). It is TA (701) - RA (601) +/- RB (6031). TA and RA should always be positive and negative, respectively.

In the report "Profit and Loss (SYSCOHADA)", the line RA is negated. XA then subtracts this value from TA, adding the two values instead of subtracting them.

Steps to reproduce:

1. Create a new company on runbot.
2. In Accounting > Configuration > Settings, set their Fiscal Localization to Ginea - SYSCOHADA for Companies.
3. Make a MISC journal entry.
    1. Set a credit of 110,000,000 on account 701100 and balance it with 411100.
    5. Set a debit of 75,000,000 on account 601100 and balance it with 401100.
    6. Set a credit of 5,000,000 on account 603100 and balance it with 411100.
7. Post the entry.
8. Navigate to Accounting > Reports > Profit and Loss.
9. Set the l10n version, Profit and Loss (SYSCOHADA).
10. Set the current date.
11. See XA = 110 million + 75 million + 5 million = 190 million; this does not match the example given on pg 357 of Guide-d-application-du-SYSCOHADA.pdf, where XA = 40 million.

[opw-5482300](https://www.odoo.com/odoo/project.task/project.task/5482300)

Forward-Port-Of: odoo/enterprise#104736
Forward-Port-Of: odoo/enterprise#104479

Backport of https://github.com/odoo/enterprise/pull/101643.

Original commit message for completeness:

Calling Avatax without lines results in an error and blocks flows:

```
Odoo could not fetch the taxes related to MXXX - SOXXX/XXX.
Please check the status of `Sales Order XXX` in the AvaTax portal.
Transactions must have at least one line.
```

There are various cases this can happen:

1/ if industry_fsm_stock is installed, empty orders are confirmed [1], 2/ if you put the end_date of a subscription before the next_invoice_date,
   then none of the lines are considered invoiceable [2] and you get the
   error when viewing the subscription in the portal

This commit filters out orders without lines.

It's also possible to filter this on the level of the models by doing it in _get_and_set_external_taxes_on_eligible_records(). However, this means doing it separately for each model, and requires every implementer do it manually.

[1] https://github.com/odoo/enterprise/blob/703e7fd413e93a8287da98286aa93b9699ae3e96/industry_fsm_stock/models/project_task.py#L159
[2] https://github.com/odoo/enterprise/blob/c7bf4367a9bf6757a36a9f34a872a6e35a19a3a5/sale_subscription/models/sale_order_line.py#L475

opw-5214609
opw-5247727
opw-5311132
opw-5385960

Forward-Port-Of: odoo/enterprise#105587

Steps to reproduce:
-------------------
1. Install `l10n_in` and `l10n_in_hr_holidays`
2. Switch to an Indian company
3. Create a user and related employee without Time Off rights
4. Log in with the new user and create a past time off
5. Approve the time off as an time off manager/admin
6. Open the validated time off record as the employee

Issue:
------
Opening a validated time off raises the following UserError:
 ```python
You must have manager rights to modify/validate a time off that already begun.
```

Cause:
------
The `_get_durations` method in `l10n_in_hr_holidays` was updating the
`l10n_in_contains_sandwich_leaves` field every time it was executed.

When a user opened a validated time off record, this triggered a `write()` operation. Since non-manager users are not allowed to write on already started validated leaves, this caused a [UserError](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/hr_holidays/models/hr_leave.py#L793-L798)

The field `l10n_in_contains_sandwich_leaves` does not need to be updated
when `l10n_in_is_sandwich_leave` is False.
See [[1]](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/l10n_in_hr_holidays/models/hr_leave.py#L156-L157) & [[2]](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/l10n_in_hr_holidays/models/hr_leave.py#L62)

And this [part of the code](https://github.com/odoo/odoo/blob/047d5b61a5f3fc5c41f5bc3975938a53b5da49a7/addons/l10n_in_hr_holidays/models/hr_leave.py#L160-L173) is responsible to update `l10n_in_contains_sandwich_leaves` value.

**NOTE:**
Opening future validated time off records as a non-manager user triggers
`AccessError` as it is not allowed to update the validated time off record.

Solution:
---------
Ensure that `l10n_in_contains_sandwich_leaves` is updated
only when `indian_leaves` is applicable.

opw-5373055





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

When adding a product with never variant, their name and values are not translated in the language of the partner.

### Steps to reproduce:

* Activate the setting Variants and Variant Grid Entry.
* Create a product , add a translation for its name.
* Create a attribute  and a translation for its name, with variant creation set to never.
* Create values for the attribute and add translation for their name.
* Add the attribute and it's values to the product .
* Create a contact and change it's language to the language of the translation.
* Create a purchase order set the contact as the vendor
* Add the product, and set the grid number to 1
-> the attribute and attribute value is not translated.

### Observation:

When adding a product via the variant grid, the attribute and value names are added. For other attribute creation types, this information is retrieved directly from the product:
https://github.com/odoo/odoo/blob/f95bcc097fd7e70af8d28a66c010ae9b9490f439/addons/purchase/models/purchase_order_line.py#L283-L288
But in case of never attribute, the name it retrieved after and we don't set the context:
https://github.com/odoo/odoo/blob/f95bcc097fd7e70af8d28a66c010ae9b9490f439/addons/purchase_product_matrix/models/purchase.py#L173-L174
-> we retrieve the information but in the wrong language

opw-5396058

**Steps to produce:**
- Install `sale_management` module.
- `Create a SO > Click on Preview > Sign and Pay`.
- Remove all text from the Full Name`.

**Issue:**
- The `Accept & Sign` button remains enabled even when the Full Name field is empty.

**Root cause:**
- At [1], When the `drawCurrentName` method is called, it retrieves text using `getCleanedName`. This method returns an empty string when no name is provided
- Despite this, the code still generates an image and passes it to `printImage`, which keeps the button enabled.

**Solution:**
- If the cleaned name is empty or contains only spaces, do not generate image.
- Instead, immediately clear the signature pad so the button remains disabled.

[1]https://github.com/odoo/odoo/blob/9dedf75810bd6b7a92fe5bd279bf6bae98834750/addons/web/static/src/core/signature/name_and_signature.js#L103-L109

**Before:**
<img width="400" height="400" alt="before" src="https://github.com/user-attachments/assets/5ebdf852-4cba-4e1d-9ae4-7373e4b8b91d" />

**After:**
<img width="400" height="400" alt="after" src="https://github.com/user-attachments/assets/9280aa66-4f22-40d6-8a22-326cec24378d" />


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

### Steps to reproduce:

- In the settings enable: Batch, Wave & Cluster transfers
- Inventory > Configuration > > Warehouse Management > Operation types
- Enable Auto-batches, Batch grouping by partner on Delivery orders
- Create and confirm a delivery for 2 units of a storable product that you do not have in stock.
- Change the quantity of the move to 1 unit
#### > The delivery is not auto-batched

### Expected behavior:

As the delivery becomes ready a batch transfer containing your delivery should be created. This is by the way what happens if you had at least 1 unit in stock when you confirm the deliver.

### Cause of the issue:

The auto-batching is suppose to be applied on assigned pickings via the `_find_auto_batch` method:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_picking.py#L194-L198 That being said a picking is only batchable if it is Ready hence his state is 'assigned'. Now, the issue is that the `_find_auto_batch` is only callable in two places in our workflow:
First at confirmation:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_picking.py#L138-L142 Which will fail in our case but wokrs in the use case where you have at least one unit in stock since the delivery is respectively not "assigned" or "assigned" at this point. And, else, wehn the sate of a move of the delivery is assigned:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock_picking_batch/models/stock_move.py#L30-L38 Now, the only issue with this call is that the picking becomes assigned if a move is partially assigned:
https://github.com/odoo/odoo/blob/604d07ab324caa5f3aa6f3baa9902c2137ea24db/addons/stock/models/stock_picking.py#L841-L845 But since the move is not "assigned" but only "partially_vailable" this will not trigger a call of the `_find_auto_batch`.

opw-5441718

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