Prior to this commit, the Deferred GST (DGST) tax was configured with a positive rate. When applied to a Vendor Bill, this generated a Debit entry, incorrectly treating the tax as a Receivable rather than a Liability to the ATO.

This commit corrects the accounting and reporting logic by:

- Inverting the tax rate: The tax now generates a Credit entry on Vendor Bills, correctly recording the Deferred GST as a liability in the General Ledger.
- Adjusting BAS formulas: Updated the formulas for labels 7 and 7A to display a positive liability amount on the statement following the change in 1.
- Adding Label 7A: Added support for the Deferred GST (7A) line to BAS variations where it was missing.
- Reordering WET: Updated the Wine Equalisation Tax (WET) sequence so it no longer appears at the top of the list, as it is not applicable to all businesses.

Task-5870092

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

Forward-Port-Of: odoo/odoo#245368

In **l10n_ec**, negative lines are not accepted in the XML.
They must be dispatched as discounts on positive lines.
The dispatching logic implemented in `60e1b41734f76a2d9268edc41286462a9d01a501` can cause rounding issues when the decimal accuracy for `price_unit` is increased.

## Steps to reproduce

With **l10n_ec**:
1. Change the decimal accuracy to 6 digits.
2. Set the rounding method to *global rounding*.
3. Create an invoice with the following lines:

| Quantity | Price    | Taxes     |
|-----------|----------|-----------|
| 20        | 1.4235   | VAT 0% G  |
| 20        | 1.6425   | VAT 0% G  |
| 20        | 1.2337   | VAT 0% G  |
| 20        | 1.2337   | VAT 0% G  |
| 20        | 1.4235   | VAT 0% G  |
| 6         | 3.747768 | VAT 15% G |
| 6         | 3.747768 | VAT 15% G |


In the generated XML, some product lines show a `descuento` of `0.01` or `-0.01`.

This happens due to rounding differences in how the `descuento` is computed in the
`common_details_info_template` from **l10n_ec_edi**:

format_num_2(line_edi_values['price_discount'] + abs(line.balance) - line_items[1]['base_amount'])

where `line.balance` and `line_items[1]['base_amount']` can differ by 0.01 due to global rounding applied during tax aggregation, and that difference must be redistributed somewhere.

This commit changes how negative lines are dispatched onto positive ones, aligning the behavior with **l10n_mx**.
Instead of using `tax_details_per_record` to build the XML, we now use `base_lines`, where the negative lines have already been distributed.

opw-5128612

Forward-Port-Of: odoo/enterprise#104659
Forward-Port-Of: odoo/enterprise#97337

Description of the issue/feature this PR addresses:
- A pricelist rule never apply to a product variant, always its template when edited in "expanded" mode
- This is because the `applied_on` field is missing on the `product.pricelist.item` form view.

Current behavior before PR:
- Install `sale_management`
- Enable "Pricelist" setting
- Go to Sales - Products - Pricelists and create a new "Sample" Pricelist.
- Create 3 rules for the same product (template), one with price at 6666, a second one at 6667 and the last one at 3333 <img width="1416" height="649" alt="image" src="https://github.com/user-attachments/assets/1d50499e-cb49-4341-971c-5a2a5111b9ca" />
- Next step, edit 2 first rules for price 6666 and 6667 to set a variant **BUT before starting editing, open the form in expanded mode using two-arrows button** <img width="1416" height="889" alt="image" src="https://github.com/user-attachments/assets/056cb862-3dc6-4868-b6d3-a0917f3e7242" />
- Set the variant to the first price rule (as you can see, the rule name is immediately updated with "Variant: [REF] Product name" <img width="1421" height="428" alt="image" src="https://github.com/user-attachments/assets/168ad5fb-902b-494f-888a-419983324607" />
- Save the price rule (_note that the display name incorrectly resets to default_) <img width="634" height="370" alt="image" src="https://github.com/user-attachments/assets/ec915985-b1a3-4a69-9153-7384abdb190d" />
- Same thing for second rule  <img width="695" height="375" alt="image" src="https://github.com/user-attachments/assets/69b9ae62-493c-4f0e-ae87-438975e1bceb" /> <img width="621" height="369" alt="image" src="https://github.com/user-attachments/assets/e1dc0342-7b87-42df-bf7d-6a3aace61253" />
- Create a new sale quotation with pricelist set to our "Sample"
- Add product [6666] <img width="1207" height="420" alt="image" src="https://github.com/user-attachments/assets/07d4fb94-03b3-45ae-aeb4-feca4fee9c2c" />
- Add product [6667] <img width="1209" height="431" alt="image" src="https://github.com/user-attachments/assets/03e3a76a-2bb1-44e9-a819-ce3ca35703c7" />
- Incorrect prices in sale order <img width="1415" height="828" alt="image" src="https://github.com/user-attachments/assets/3626028d-31d0-4687-b09d-094c0212042a" />


Desired behavior after PR is merged:
- Each variant must have its own price.
- The added test simply edit the pricelist item using its own form.
- The `applied_on` field is added to the pricelist item form to ensure that its value is saved.
- If we edit the rule without expanded mode, it works fine only because the `applied_on` field exists in the list view as an invisible column.

_Note 1_: `applied_on` is updated by `_onchange_rule_content` using `update` instead of `write` (for caching ?).
But if the `applied_on` field is not on the form, then its value is never sent to low level `_write_multi`.

_Note 2_: to clear the field value with the Form test component, we must set `=self.env["product.product"]` instead of `=False` ....

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

Forward-Port-Of: odoo/odoo#245603
Forward-Port-Of: odoo/odoo#245444

linked to https://github.com/odoo/odoo/pull/245469, there is another case in the uninstallation flow that can raises a traceback in case of a `ir.model.data` where `res_id = 0`

This commit adds an additional filter to the domain used to browse `ir.model.data` in `_module_data_uninstall` in order to avoid selecting any that would contain a falsy `res_id` and thus cause the above-mentioned assertion to fail.

One way to reproduce this in a new trial:
- Create a new trial with several modules: `account`, `crm`, `project`, `sales`
- Install `web_studio`
- Uninstall `base_automation`
- Traceback
```
  File “/home/odoo/src/odoo/saas-19.1/odoo/orm/models.py”, line 5200, in browse
    assert all(ids) or all(isinstance(x, NewId) or x for x in ids), “Invalid falsy real id”
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
AssertionError: Invalid falsy real id
```

This is due to an `ir.model.data` containing a falsy res_id in the internal code of `saas_trial` (`installed-17`)

This fix will avoid any additional traceback like this one.

opw-5865316

Versions
--------
- 18.0+

Steps
-----
1. Have a way to check the `specific_property_product_pricelist` field;
2. create a pricelist for EU countries;
3. delete all other regional pricelists;
4. create a new partner in a EU country;
5. create a new partner outside a EU country;
6. create a new partner without a country.

Issue
-----
Inconsistent behavior:
- EU partner has no `specific_property_product_pricelist` value set, as it's identical to the default `property_product_pricelist`.
- The other partners do have a `specific_property_product_pricelist` value set to the default value, as if a user manually assigned them.

Cause
-----
In the `_inverse_product_pricelist` method, the `default_for_country` pricelist is an empty recordset if the partner has no `country_id` or none of the pricelists have a country groups with the partner's `country_id` in it.

Solution
--------
Introduce a `_get_country_pricelist_multi` method that can be used by `_get_partner_pricelist_multi` and `_inverse_product_pricelist` to ensure that they both return the same result for any given country (including none), and use this as the `default_for_country`.

> [!Note]
> An alternative approach could be to replace the `_inverse_product_pricelist` method with an `onchange` method, as the docstring of the `_get_partner_pricelist_multi` method states:
>> First, the pricelist of the specific property (res_id set), this one is created when saving a pricelist on the partner form view.
>
> This suggests a behavior that more closely resembles the purpose of an `onchange` method, instead of an `inverse`.

opw-5385213

Enterprise PR: https://github.com/odoo/enterprise/pull/103116 (only modifies a test)

Forward-Port-Of: odoo/odoo#245681
Forward-Port-Of: odoo/odoo#241736

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

**PROBLEM**
1. When generating a global invoice with a user without super user access, a access error may occur on the ir.sequence model.
2. There is an issue with the cache of the field `l10n_mx_edi_global_invoice_sequence_id`. (this is why problem can sometimes resolves itself on restarting the odoo instance).

 **STEP TO REPRODUCE**
1. Create 1 invoice with CFDI to public checked.
2. Goes to the list view for invoices, select the invoice, and apply the action "create global invoice" to it.
4. A access error may appear (depending on cache value).

**CAUSE**
1. In `_get_global_invoice_cfdi_sequence()`, we get or create the ir.sequence used for global invoices. We are creating it with sudo(), so a user without sudo privilege can write to it. But, when we are retrieving a ir.sequence record that already exist, when don't use sudo(), this causes an access error for user without sudo privilege.
2. In `_get_global_invoice_cfdi_sequence()`, we try to get the computed field `l10n_mx_edi_global_invoice_sequence_id`. If it doesn't exist, we create a ir.sequence, but we forget to assign it to the field. Because we already trigger the compute method of the field by trying to access it, there is a None value in cache for it. This means we will always create a ir.sequence, despite one already existing for the company until the cache expires or the compute method is re-triggered.

opw-5472552

Forward-Port-Of: odoo/enterprise#104181

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

**PROBLEM**
1. When generating a global invoice with a user without super user access, a access error may occur on the ir.sequence model.
2. There is an issue with the cache of the field `l10n_mx_edi_global_invoice_sequence_id`. (this is why problem can sometimes resolves itself on restarting the odoo instance).

 **STEP TO REPRODUCE**
1. Create 1 invoice with CFDI to public checked.
2. Goes to the list view for invoices, select the invoice, and apply the action "create global invoice" to it.
4. A access error may appear (depending on cache value).

**CAUSE**
1. In `_get_global_invoice_cfdi_sequence()`, we get or create the ir.sequence used for global invoices. We are creating it with sudo(), so a user without sudo privilege can write to it. But, when we are retrieving a ir.sequence record that already exist, when don't use sudo(), this causes an access error for user without sudo privilege.
2. In `_get_global_invoice_cfdi_sequence()`, we try to get the computed field `l10n_mx_edi_global_invoice_sequence_id`. If it doesn't exist, we create a ir.sequence, but we forget to assign it to the field. Because we already trigger the compute method of the field by trying to access it, there is a None value in cache for it. This means we will always create a ir.sequence, despite one already existing for the company until the cache expires or the compute method is re-triggered.

opw-5472552

Forward-Port-Of: odoo/enterprise#104181

**PROBLEM**
1. When generating a global invoice with a user without super user access, a access error may occur on the ir.sequence model.
2. There is an issue with the cache of the field `l10n_mx_edi_global_invoice_sequence_id`. (this is why problem can sometimes resolves itself on restarting the odoo instance).

 **STEP TO REPRODUCE**
1. Create 1 invoice with CFDI to public checked.
2. Goes to the list view for invoices, select the invoice, and apply the action "create global invoice" to it.
4. A access error may appear (depending on cache value).

**CAUSE**
1. In `_get_global_invoice_cfdi_sequence()`, we get or create the ir.sequence used for global invoices. We are creating it with sudo(), so a user without sudo privilege can write to it. But, when we are retrieving a ir.sequence record that already exist, when don't use sudo(), this causes an access error for user without sudo privilege.
2. In `_get_global_invoice_cfdi_sequence()`, we try to get the computed field `l10n_mx_edi_global_invoice_sequence_id`. If it doesn't exist, we create a ir.sequence, but we forget to assign it to the field. Because we already trigger the compute method of the field by trying to access it, there is a None value in cache for it. This means we will always create a ir.sequence, despite one already existing for the company until the cache expires or the compute method is re-triggered.

opw-5472552

Forward-Port-Of: odoo/enterprise#104181

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

Each Odoo tab establishes a WebSocket connection with the VoIP provider. This causes problems with incoming calls: each tab receives the notification, which leads to the associated callbacks being called as many times as there are open tabs. This used to be particularly annoying with the ringtone, which would play in unison. To solve this problem, we decided that only the "main tab" should be responsible for playing the ringtone. Since there can only be one main tab at a time, there can only be one ringtone at a time. Problem solved. This seemed to be an easy and effective solution.

However, we were informed that sometimes the call wouldn't ring at all 🤬
This called the reliability of the system into question. What would happen if:
- The main tab loses the WebSocket connection?
- The main tab is throttled?
- The main tab was never interacted with, preventing us from playing audio?
 - The notification arrives after the main tab is killed and before a new main tab is elected?

This commit attempts a new approach ⋆✴︎˚｡⋆
All tabs receiving incoming call notifications will now send a message to a central authority—The _SharedWorker_ 🙀—along with information about whether or not they can play audio. The SharedWorker then selects the first tab that can play audio and assigns it the task of playing the incoming ringtone.

This is expected to solve the problems mentioned above, as it guarantees that the "player tab" is a tab that:
- effectively received the incoming call notification
- is allowed to play audio

[Task-5411760](https://www.odoo.com/odoo/project.task/5411760)

Steps to reproduce:
-------------------
1. Install l10n_au_hr_payroll.
2. Enable multi-company and switch to an AU company.
3. Change an existing employee’s company to the AU company
([employee created more than 28 days ago](https://github.com/odoo/enterprise/blob/7adab8bfdccf5f0e97eb2894e065b63ea8200d20/l10n_au_hr_payroll/data/hr_payroll_dashboard_warning_data.xml#L31)).
4. Under the payroll tab, set the TFN Status to:
"Employee applied for TFN but didn't receive it yet, less than 28 days ago".
5. Open Payroll.

Issue:
--------
A traceback occurred:
```
Error: NameError("name 'invalid_employees' is not defined")
```
Cause:
------
The evaluation code computes `warning_count` using
an undefined `invalid_employees` variable.

Solution:
---------
Define `invalid_employees` before using it to compute
`warning_count` and `warning_records`.

**NOTE:**
The [upgrade script](https://github.com/odoo/upgrade/blob/ed5bc3fd99ef6fba4bc7162934df36396ae9fc3f/migrations/l10n_au_hr_payroll/saas~18.4.1.0/end-migrate.py#L30) is already available from version 18 to 19.

opw-5459998

Forward-Port-Of: odoo/enterprise#103777

## Issue
When completing an *Inventory Count* from the Barcode app, the *Inventory Reason* requested to the user is not registered anywhere.

## Steps to reproduce
1. Install the *Barcode* app (`stock_barcode`)
2. In the *Barcode* app, click *Count Inventory*
3. Add a product and set a quantity for it
4. Click *Confirm* (do not scan to confirm)
5. Write an *Inventory Reason* and click *Apply Now*
6. Go to Inventory > Reporting > Moves History
    - **The _Inventory Reason_ given in step 5 does not appear anywhere**

If the inventory adjustment is done through Inventory > Operations > Physical Inventory, the user can also provide an *Inventory Reason*, but this time, it will appear in the *Moves History* in the *Reference* (`stock.move.line.reference`) column.

## Cause
Since https://github.com/odoo/enterprise/commit/3efea75a88120519ef4be1a41c8faa7278bc332c, the value provided by the user is never passed to the Python side.

opw-5423934

Forward-Port-Of: odoo/enterprise#104763

**Commit 1:** 
[FIX] account_reports: translation of account returns states
Steps to reproduce:
 - Open the tax returns
 - Set an account opening date to generate some returns
 - Add another language to the database and select it

 -> The states of the returns (the little bubble in the
 kanban cards) aren't translated even though the translation
 is present in the pot and po files.

**Commit 2:**
[FIX] account_reports: translation of date in returns title
Steps to reproduce:
 - Have 2 languages on the db
 - Generate the tax returns by going to Accounting/Tax Returns and set the opening date
 - Switch to the second language

 -> The period displayed in the name of each return isn't translated

**Commit 3:**
[FIX] account_reports: translate account returns name after lang installation

Steps to reproduce:
 - Generate the tax returns by going to Accounting/Tax Returns and
   set the opening date
 - Install another language

 -> The names of the returns aren't translated in the new language.

Solution: When installing a new language, generates the translation
 of the title for all existing returns

task-5421659

Forward-Port-Of: odoo/enterprise#102559

The `_parse_bnb_data` method assumed that the Bulgarian National Bank (BNB) provides exchange rates against BGN (Bulgarian Lev). However, since Bulgaria joined the Eurozone on January 1, 2026, the BNB now provides rates against EUR.

This caused the error "Your main currency (EUR) is not supported by this exchange rate provider" when Bulgarian companies with EUR as their main currency tried to sync exchange rates.

refs:

We can compare the data here from 31 December using the WayBackMachine:
https://web.archive.org/web/20251231193558/https://www.bnb.bg/Statistics/StExternalSector/StExchangeRates/StERForeignCurrencies/index.htm

Compared to today:
https://www.bnb.bg/Statistics/StExternalSector/StExchangeRates/StERForeignCurrencies/index.htm

And see the comparison used to be to BGN but is now for EUR

Steps To Reproduce:
1. Create a company for Bulgaria with EUR as the main currency.
2. Go to Accounting Settings -> Automatic Currency Rates.
3. Select "[BG] Bulgaria National Bank" as the service provider.
4. Click the sync button.
5. Error appears: "Your main currency (EUR) is not supported by this exchange rate provider. Please choose another one."

The fix updates the base currency from BGN to EUR, matching the current BNB XML format which now provides rates against EUR.

Note: Companies with BGN as main currency will now get the same error, which is expected since the BNB no longer provides BGN-based rates. This behavior was discussed and confirmed with the PO.

Ticket [link](https://www.odoo.com/odoo/project.task/5483771)
opw-5483771

Forward-Port-Of: odoo/enterprise#105074

Each Odoo tab establishes a WebSocket connection with the VoIP provider. This causes problems with incoming calls: each tab receives the notification, which leads to the associated callbacks being called as many times as there are open tabs. This used to be particularly annoying with the ringtone, which would play in unison. To solve this problem, we decided that only the "main tab" should be responsible for playing the ringtone. Since there can only be one main tab at a time, there can only be one ringtone at a time. Problem solved. This seemed to be an easy and effective solution.

However, we were informed that sometimes the call wouldn't ring at all 🤬
This called the reliability of the system into question. What would happen if:
- The main tab loses the WebSocket connection?
- The main tab is throttled?
- The main tab was never interacted with, preventing us from playing audio?
 - The notification arrives after the main tab is killed and before a new main tab is elected?

This commit attempts a new approach ⋆✴︎˚｡⋆
All tabs receiving incoming call notifications will now send a message to a central authority—The _SharedWorker_ 🙀—along with information about whether or not they can play audio. The SharedWorker then selects the first tab that can play audio and assigns it the task of playing the incoming ringtone.

This is expected to solve the problems mentioned above, as it guarantees that the "player tab" is a tab that:
- effectively received the incoming call notification
- is allowed to play audio

[Task-5411760](https://www.odoo.com/odoo/project.task/5411760)
Backport of https://github.com/odoo/enterprise/pull/104885

…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

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

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

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

**Description of the issue/feature this PR addresses:**
When selecting a payment method line on a contact, lines related to journals still appear even if the journal has been archived. This can lead to the accidental use of payment method lines that should no longer be available. There should be no need to delete payment method lines when archiving a journal; doing so causes a loss of configuration if the journal is reactivated later, and leads to data duplication when having to recreate them.

**Current behavior before PR:**
When selecting a payment method line on a contact, lines from archived journals are still visible. Currently, payment method lines must be manually deleted from archived journals to prevent them from appearing in the selection list.
Payment Method Line domain doesn't include `('journal_id.active', '=', True)` domain part.

**Desired behavior after PR is merged:**
Archiving a journal is now sufficient to stop its payment method lines from appearing as selectable options on contacts.

https://www.loom.com/share/05981419c7dd4584b67d27d84e27892a

OPW-5413309 MT-13011 @moduon @rafaelbn @EmilioPascual @Gelojr @yajo please review if you want 😄 

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

Issue:

When using negative amounts, for example to explicitly show a discount, the tax calculation is incorrect due to the application of the `abs` function. Furthermore, the way to find out if a tax is of the withholding type is based on the sign of the value, which can lead to error in these cases.

Cause:

A previous change (#237235) added the `abs` function so the `TotalTaxesWithheld` would be always with positive value. But this also affects the calculation of taxes `TotalTaxOutputs` in some cases, such as if the invoice line has negative values.

Steps to reproduce:

- Install `l10n_es_edi_facturae`
- With the ES company, create an invoice with some standard lines and one line with negative amounts, as an explicit discount
- Confirm the invoice and send (facturae)
- Open the XML attached in the chatter
- Observe that the taxes amounts (VAT and WITHHOLDING) are erroneous

A correct invoice should be for example:

```
Product        Price       Taxes       Amount
---------------------------------------------
PRODUCT-A       1000    21%VAT 15%WHI    1000
Discount        -100    21%VAT 15%WHI    -100
---------------------------------------------
                       Untaxed amount     900
                      Withholding 15%    -135
                              VAT 21%     189
                      -----------------------
                                 TOTAL    954
```

This PR replaces #240808 

---
I confirm I have signed the [CLA](https://github.com/odoo/odoo/pull/157955) and read the PR guidelines at www.odoo.com/submit-pr

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

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