In this PR, we add the possibility to create and manage a complete CSRD/VSME report, integrated with AI, knowledge, survey and HR.

The Corporate Sustainability Reporting Directive (CSRD) is a legal framework in the EU that requires companies to report on their sustainability performance. It aims to standardize ESG reporting across the EU and make the information more comparable and reliable for investors and other stakeholders.
On the other hand, the Voluntary Sustainability Reporting for Micro and Small Enterprises (VSME) is a framework designed to support smaller companies in reporting on their sustainability performance. It encourages clear, comparable, and meaningful ESG disclosures while remaining proportionate to the size and capacity of the business.
Our reporting feature facilitates the steps involved in preparing a CSRD/VSME report by using the data we already have in Odoo, such as emissions (Scope 1, 2, 3), employee data, supplier and client information, or fleet metrics. As well as using AI to make suggestions, and integrating knowledge articles and surveys.

More precisely, the feature is composed of two main models:

- A new model (`esg.metric)` that is only used if the CSRD reporting is enabled (and only used in the context of CSRD reporting).
  It is linked to an ESRS data point (either Environmental, Social or Governance category) and can be of different types (Positive/Negative Impact, Risk or Opportunity).
  It is used to assess if a topic is material or not (Double Materiality Assessment), depending on the impact severity and financial severity scores. As well as scores obtained from the stakeholder reviews (we get those scores from surveys that have been completed, the surveys are sent with the action "Stakeholder Review").
  To help the user to create relevant metrics, we added an AI feature allowing to generate suggestions of metrics. Provided that the user gives a description of the company (size, revenues, activity, etc) to give as much context as possible to the AI prompt (see action "AI Suggest").

- A new model (`esg.report`) where you can specify the type of the report (CSRD or VSME), the dates (reporting date and base reference date), and additional information about the company.
  Once created, the report is linked to a knowledge article that contains the template of a complete CSRD/VSME report that you can edit, fold/unfold sections, add content, etc.
  When printing it to PDF, a lot of information is automatically filled in (data about your employees, accounting data, etc), including the carbon report, dynamic tables. That is done by replacing placeholders from the knowledge article when generating the PDF (an appendix includes all available placeholders with a small explanation for each).
  For CSRD reports only, there is the ability to automatically fold/unfold the ESRS sections of the articles depending on whether the data points we get from the metrics are material or not (see action "Update Materiality").
  For VSME reports only, there is a "Basic Module + Comprehensive Module" type that will include additional sections (C1-C9). Note that you can also load them manually from the root article with the "Load Template" action.

task-5172829

Forward-Port-Of: odoo/enterprise#96759

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

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

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

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

Server actions that were standalone (not a child) and embedded onto a documents folder 
cannot be executed anymore when they are linked to a parent action.
Before saas-18.3, the embedded child action would still be in the documents' 
`available_embedded_actions`, and couldn't be removed, such that a fix was necessary.

From saas-18.3 onwards, children embedded actions are no longer visible.

As this precise case wasn't explicitly tested, we continue the FW-port with the (adapted) test.
Furthermore, we add a garbage collection of the embedded actions for children actions, as they cannot be
executed anymore. 

Initial FIX:
### ISSUE

Certain embedded actions inside a folder may not appear in the folder’s server actions list (accessible via the gear icon), making them impossible to find or delete through the interface.

This occurs because documents.document.get_documents_actions applies overly broad filtering that removes all child server actions, regardless of whether they are embedded in the folder.

As a result, if two embedded actions are created in a folder and one is later set as a child of the other, the embedded child action disappears from the visible list but remains embedded in the folder, leaving no way to remove it from the UI.

### SOLUTION

The method has been updated to exclude only non-embedded child actions.
Embedded child actions are now preserved and correctly displayed in the folder’s actions list, allowing them to be managed and deleted as expected.

opw-5213881

Forward-Port-Of: odoo/enterprise#101527
Forward-Port-Of: odoo/enterprise#100395

*= co, ec, kr, tw, zm

Currently, the `Other Expense(expense_other)` account type, introduced in 
saas-18.3, is missing from the Balance Sheet reports of certain `localizations`, 
even though it's correctly implemented in the standard reports.

**Steps to reproduce:**
- Install the `l10n_co_reports` and `accountant` modules.
- Switch to `CO company `and navigate to Accounting > Reporting > Balance Sheet.
- Ensure the `report` smart button is set to `Balance Sheet (CO)`.
- Equity > Previous Years Unallocated Earnings and click the `info icon`.
- Observe the formula of `balance_domain`.

**Observation:**
The formula does not include the `expense_other` account type.

**Root Cause:**
After PR [1], at [2] `expense_other` was added to the Previous Years Unallocated 
Earnings balance domain only in the main `account_reports` module. The 
corresponding localization reports mentioned above were not updated 
accordingly, resulting in incomplete Balance Sheet formulas.

**Fix:**
This commit updates the Balance Sheet report and includes the `expense_other` 
account type in the Previous Years Unallocated Earnings balance domain, 
aligning them with the standard reports.

[1]:
https://github.com/odoo/enterprise/pull/101591

[2]:
https://github.com/odoo/enterprise/blob/316a5965e5fae83bd7d901929160c87eb28d13cf/account_reports/data/balance_sheet.xml#L205

opw-5491639

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

Forward-Port-Of: odoo/odoo#245542

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

In this PR, we add the possibility to create and manage a complete CSRD/VSME report, integrated with AI, knowledge, survey and HR.

The Corporate Sustainability Reporting Directive (CSRD) is a legal framework in the EU that requires companies to report on their sustainability performance. It aims to standardize ESG reporting across the EU and make the information more comparable and reliable for investors and other stakeholders.
On the other hand, the Voluntary Sustainability Reporting for Micro and Small Enterprises (VSME) is a framework designed to support smaller companies in reporting on their sustainability performance. It encourages clear, comparable, and meaningful ESG disclosures while remaining proportionate to the size and capacity of the business.
Our reporting feature facilitates the steps involved in preparing a CSRD/VSME report by using the data we already have in Odoo, such as emissions (Scope 1, 2, 3), employee data, supplier and client information, or fleet metrics. As well as using AI to make suggestions, and integrating knowledge articles and surveys.

More precisely, the feature is composed of two main models:

- A new model (`esg.metric)` that is only used if the CSRD reporting is enabled (and only used in the context of CSRD reporting).
  It is linked to an ESRS data point (either Environmental, Social or Governance category) and can be of different types (Positive/Negative Impact, Risk or Opportunity).
  It is used to assess if a topic is material or not (Double Materiality Assessment), depending on the impact severity and financial severity scores. As well as scores obtained from the stakeholder reviews (we get those scores from surveys that have been completed, the surveys are sent with the action "Stakeholder Review").
  To help the user to create relevant metrics, we added an AI feature allowing to generate suggestions of metrics. Provided that the user gives a description of the company (size, revenues, activity, etc) to give as much context as possible to the AI prompt (see action "AI Suggest").

- A new model (`esg.report`) where you can specify the type of the report (CSRD or VSME), the dates (reporting date and base reference date), and additional information about the company.
  Once created, the report is linked to a knowledge article that contains the template of a complete CSRD/VSME report that you can edit, fold/unfold sections, add content, etc.
  When printing it to PDF, a lot of information is automatically filled in (data about your employees, accounting data, etc), including the carbon report, dynamic tables. That is done by replacing placeholders from the knowledge article when generating the PDF (an appendix includes all available placeholders with a small explanation for each).
  For CSRD reports only, there is the ability to automatically fold/unfold the ESRS sections of the articles depending on whether the data points we get from the metrics are material or not (see action "Update Materiality").
  For VSME reports only, there is a "Basic Module + Comprehensive Module" type that will include additional sections (C1-C9). Note that you can also load them manually from the root article with the "Load Template" action.

task-5172829

Forward-Port-Of: odoo/enterprise#96759

Purpose: The SICORE report is necessary for company to submit to the government monthly to comply with legal requirements since withholding was implemented for AR. The SICORE report is a tax report that provides a detailed overview of the withholdings performed in a given period. The user will also be able to export the report as a .txt file, containing formatted information about the earnings tax withholdings.

Specification (this specification can be found in the SICORE application of the SIAP application):
| No. | Desde | Hasta | Long | Tipo dato | Descripción                                         |
|-----|-------|-------|------|-----------|-----------------------------------------------------|
| 1   | 1     | 2     | 2    | Entero    | Código del comprobante                              |
| 2   | 3     | 12    | 10   | Fecha     | Fecha de emisión del comprobante (DD/MM/AAAA)       |
| 3   | 13    | 28    | 16   | Texto     | Número del comprobante                              |
| 4   | 29    | 44    | 16   | Decimal   | Importe del comprobante                             |
| 5   | 45    | 48    | 4    | Entero    | Código de impuesto                                  |
| 6   | 49    | 51    | 3    | Entero    | Código de régimen                                   |
| 7   | 52    | 52    | 1    | Entero    | Código de operación                                 |
| 8   | 53    | 66    | 14   | Decimal   | Base de cálculo                                     |
| 9   | 67    | 76    | 10   | Fecha     | Fecha de emisión de la retención                    |
| 10  | 77    | 78    | 2    | Entero    | Código de condición                                 |
| 11  | 79    | 79    | 1    | Entero    | Retención practicada a sujetos suspendidos según:   |
| 12  | 80    | 93    | 14   | Decimal   | Importe de la retención                             |
| 13  | 94    | 99    | 6    | Decimal   | Porcentaje de exclusión                             |
| 14  | 99    | 109   | 11   | Fecha     | Fecha de emisión del boletín                        |
| 15  | 110   | 111   | 2    | Entero    | Tipo de documento del retenido                      |
| 16  | 112   | 131   | 20   | Texto     | Número de documento del retenido                    |
| 17  | 132   | 145   | 14   | Entero    | Número certificado original                         |

task-4837110

Closes #86648

In this PR, we add the possibility to create a complete CSRD reporting tool, integrated with AI.
The Corporate Sustainability Reporting Directive (CSRD) is a legal framework in the EU that requires companies to report on their sustainability performance. It aims to standardize ESG reporting across the EU and make the information more comparable and reliable for investors and other stakeholders. Our tool will guide the user towards the different steps of that specific report while using information they already have in Odoo (like scope 1,2 and 3 emissions, employee data, suppliers, clients or fleet).

The tool is divided in multiple steps:
- General: A complete description of the company (size, revenues, activity, etc) must be provided in order to give as much context as possible to the AI agent that will provide help and suggestions. To go to the next step, an action is available to generate relevant ESRS data points for the next step, and suggesting for each, some IROs (Impact, Risk, Opportunity) using AI generation.

- ESRS: List of all relevant ESRS data points and their IROs for our company. We can add, remove, modify this list as we please. To go to the next step, an action button is provided in order to generate Double Materiality Assessement (AI generation), it will generate scores.

- Materiality: List of relevant ESRS data points, their IROs and scores. The scores will help to know if a topic is material or not (useful to justify why it's the case in the report). There is also the possibility to ask stakeholders for reviews of those data points and score them, we will take the average of those score into account to compute the stakeholder score. A topic is considered as material if its 
`score >= (((impact_severity_score + financial_materiality_score) / 2) + stakeholder_score) / 2`
Again, another action button is added to go to the next step and generate Quantitative data

- Quantitative Data: Contains some interesting data about the company's emissions (scope 1, scope2, scope 3), HR related data (number of employees, pay gap, turnover rate, etc), environmental data, etc. It's interesting to mention this data in the final report.

- The last step is simply the CSRD report generation, integrated with AI suggestions given all the data and context previously given. The generated report will be created as Knowledge articles (Introduction, General Disclosures, Environmental Disclosures, Social Disclosures and Governance Disclosures).

Prior to this commit, the integration of 'itsme' in Odoo Sign lacked visibility regarding IAP credits. Users could not easily see their balance when configuring roles, and the "insufficient credits" email was generic without actionable steps. Additionally, the Sign Editor sidebar did not visually distinguish between authentication methods (SMS vs itsme).

This commit improves the UX for the 'itsme' flow through the following changes:

1. Role Configuration (sign.item.role):
   - Updates the form view to display the current available credits when 'itsme' is selected as the authentication method.
   - Adds a direct link to the IAP service to manage credits.

2. Email Notification (mail.template):
   - Refactors the 'sign_template_mail_not_enough_credits' template to use clearer wording ("due to insufficient credits") for all auth methods.
   - Adds a specific condition for 'itsme': if verification fails due to lack of credits, the email now includes a direct link to the IAP purchase page.

3. IAP Account View (iap.account):
   - Customizes the IAP account form specifically for the 'itsme_proxy' service.
   - Relocates the credit balance display to a more prominent position under the account title.
   - Hides the standard boolean status badges for this specific service to reduce clutter.

4. Sign Editor Sidebar (JS/XML):
   - Adds visual badges to the signer list in the sidebar to indicate the selected authentication method (e.g., specific icon for itsme).
   - Updates the backend model to inject 'auth_method' data into the sidebar props.
   - Ensures the itsme badge remains visible in dark mode using inline styling.
   
   Task: 5862540

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

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

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

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

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

Before this commit, when you clicked on an input that didn’t have focus inside a bottom sheet, the virtual keyboard popped up on top of the bottom sheet, hiding the input. As a result, you couldn’t see what you were typing.

This happens because, in this case, the browser opens the virtual keyboard in overlay mode and does not resize the viewport. This seems to be a common behavior for inputs inside fixed or overlay-based layouts such as bottom sheets.

Strangely, when you clicked on an input that was already the active element, the keyboard still popped up, but the viewport was resized and the bottom sheet remained visible. In this situation, the browser treats the keyboard appearance as a viewport change and recomputes the layout to keep the active element visible (safe mode?).

To fix this inconsistency, we now explicitly control how the virtual keyboard affects the layout by forcing the bottom sheet to resize with the viewport. This is done by using `interactive-widget: resizes-content`, which ensures the viewport is resized when the keyboard appears and prevents the bottom sheet from being covered.

Note that we should probably apply this change on the web as well, but it seems that we currently don’t have any inputs inside bottom sheets there. Since this is a fix, we prefer to apply it only where it is necessary for now.

https://developer.mozilla.org/en-US/docs/Web/HTML/Reference/Elements/meta/name/viewport#interactive-widget

opw-5491343

Description of the issue/feature this PR addresses:

Current behavior before PR:

Desired behavior after PR is merged:




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

Steps to reproduce
-----
- Enable routes
- Unarchive MTO
- Create a MTO product with a vendor
- Create a final product
- Create a MO for final product
- Confirm MO
- Open catalog
- Add 0.5 of the MTO product
- Open the linked purchase

> Quantity on the PO is 1

Cause
-----
The catalog creates a move with a default quantity of 1 when the product is clicked. Then, when the user updates the quantity in the catalog, it triggers a `write` of the `product_uom_qty` (which triggers a procurement).

Error comes from the code added in commit c0f00e4, which changed the `_run_procurement` of `stock.move` to avoid creating returns for done moves.

https://github.com/odoo/odoo/blob/07198521ea1defb6abb9a6e619b8824bbb1d16a7/addons/mrp/models/stock_move.py#L493-L497

In our case, all of the conditions are met:
- the quantity update is negative
- the move is MTO
- `move_orig_ids` is empty, so the `all()` is also true

This means the move gets skipped for procurement, although that was not the goal of the commit.

Even if we were to fix this last condition, there is also a problem with

https://github.com/odoo/odoo/blob/07198521ea1defb6abb9a6e619b8824bbb1d16a7/addons/mrp/models/stock_move.py#L505-L507

that was also affected by the mentioned commit. Since `move_orig_ids` is empty, `possible_reduceable_qty` is 0. And because `procurement_qty` is negative, taking the max of the 2 will always mean `procurement_qty` is 0.

This again does not match the goal of the original commit.

-----
Ticket:
opw-5440296

Description of the issue/feature this PR addresses:

Fixes timer not showing to participants of a live session after submitting an answer.

Current behavior before PR:

Steps to reproduce:

Create a Survey with two questions of any type.
Set some Question Time Limit on both.
Create Live Session for that Survey.
Access Live Session as a participant.
Start Survey as the host.
The first question appears to the participant, with the timer on the top right. Answer the question as the participant and click Submit or press Enter. On the host side move to the next question.
Bug: timer for the second question does not appear to the participant.

Desired behavior after PR is merged:

Fix:
The logic to hide the timer is on `survey_form.js`. In the `_nextScreen` function.
Specifically, when `options.isFinish` is set to `true`. It is set to `true` in the `_onSubmit` function.
This function triggers when the participant submits an answer. The fix: only set that flag to `true` if there isn't a session in progress. This aligns with the other calls to `_nextScreen` for live sessions. That is, when a timer expires and the form is submitted: `'isFinish': !this.options.sessionInProgress`
and when a notification is received for the session: `isFinish: nextPageEvent.type === 'end_session'`
Meaning that for live sessions the only time `isFinish` should be set to `true`, is when the `end_session` notification is received.

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