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

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#245951
Forward-Port-Of: odoo/odoo#241979

****Behavior:****
When a user who is Time off Responsible but not Officer or Admin and is marked as responsible for an employee tries to refuse a fully accepted leave an access error occurs.
This occurs because approving a leave creates a resource.calendar.leave linked to the hr.leave, and when refusing it, the system will try to unlink it.
https://github.com/odoo/odoo/blob/72e8a29dd0edb0ca3d464142ce869f38f96c730a/addons/hr_holidays/models/hr_leave.py#L896-L901

According to access rules of r.calendar.leaves, Time-off Responsibles are not allowed any access for entries of other employees.
Approving them doesn't cause an error because the create operation uses sudo(), assuming that the user must have had valid rights to access the function. This is not the case for the unlink.

**Solution:**
This fix checks wether the user has write access to the related hr.leave record, then uses sudo().
The idea is that if they are allowed to modify the state of the leave, they can refuse the leave, and therefore should be able to go through the following operations.
This is in a similar fashion as the behavior for approving the leaves.

****Steps to Reproduce:****
- Create a Leave Type that requires validation from a manager, and assign one to an employee.
- Remove any access rights to Time-Off for the user, but leave Time off Responsible checked.
- Assign the user as time-off responsible for the employee
- Log in as the user and approve the leave
- When refusing the leave, you should get an access error.

opw-5178783

Forward-Port-Of: odoo/odoo#243405
Forward-Port-Of: odoo/odoo#238205

**Description of the problem**
In the website editor, the user can manipulate the page in such a way to generate a
problematic `SelectionPlugin.activeSelection`, which still points to an existing
`anchorElement`, but has an invalid `offset`.

**How to reproduce**
This seems to be reproducible only on Chrome.
1. Enter in the website edit mode
2. Drop the `s_newsletter` snippet
3. Drop the `s_popup` snippet
4. Click on the popup, and delete it
5. Click on the blank space inside the `s_newsletter` snippet
6. Delete the `s_newsletter` snippet
7. The error occurs

Notes:
1. Snippet different than `s_newsletter` can be used to reproduce the problem, as
long as they contain a blank space.
2. It is important to make sure that the movement of the mouse pointer does not
trigger any preview when going from step 5 to step 6.

**Why the problem happens**
On Chrome, clicking on a blank area can cause `document.getSelection()` to return a
selection with a null `anchorNode.` When this happens, `SelectionPlugin.getSelectionData()`
will use the already existing `activeSelection` if `activeSelection.anchorNode` is still
connected. Before this commit, this method only checked that `anchorNode` was connected,
without validating offsets. This leads to the following edge case:
1. The user removes the `s_popup`
2. At this point, `document.getSelection()` would point to the `s_newsletter` snippet, so if the
user just deletes the snippet nothing bad would happen. But instead, if:
3. The user clicks on a blank area in `s_newsletter`, `document.getSelection()` will now return
a null `anchorNode`
4. The user delete the `s_newsletter` snippet, and `SelectionPlugin.getSelectionData()` is called
by an handler after the deletion
5. At this point: `document.getSelection()` has a null `anchorNode`, so the method will check if
`activeSelection.anchorNode` is still connected, WITHOUT validating the offsets.
6. Since `anchorNode` is still connected, this selection will be used, and an error will be
triggered shortly after, because the offset is too high (pointing to `s_popup` which does not
exist anymore).

**Fix**
After this commit, when `SelectionPlugin.getSelectionData()` checks that `activeSelection.anchorNode`
is still connected it also checks that the offsets are valid (meaning that they are smaller than the
number of nodes).

task-5430500

Forward-Port-Of: odoo/odoo#245818
Forward-Port-Of: odoo/odoo#244331