### Issue:
When setting Vendor Bills to Digitize on demand, it is no longer possible in 19.0 to trigger digitization manually if the Bill Date is not set 
A missing required fields error is raised

### Cause:
This PR: https://github.com/odoo/odoo/pull/238911
introduced a required field to prevent an error modal from appearing 
While this works as intended, it also blocks the `Digitize Document` action, which is supposed to populate the Bill Date automatically

### Fix:
A condition similar to the one used for the Digitize Document button is applied to allow triggering digitization without a Bill Date

The validation modal is still enforced afterward to ensure data consistency in case of manual edits

### Steps to reproduce:
- Install `account`
- In Settings, set `Document Digitization` for `Vendor Bills` to `Digitize on demand only`
- Create and print an invoice (any data) or use an existing one
- Import it into Vendor Bills
- Click Digitize Document

### Before the fix:
A missing required fields notification is raised, preventing digitization

opw-5886012

Forward-Port-Of: odoo/enterprise#112585

### Issue:
Negative values in the Mod 390 report were not properly marked with the N indicator for several fields

### Cause:
The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export

### Note:
According to the official specification, negative amounts must be explicitly marked with N
Latest documentation:
https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx

### Steps to reproduce:
- Install `l10n_es_reports` with demo data and switch to the ES company
- Create a Bill (Price: 100, Taxes: 21% G)
- Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year
- Open the VAT Deductible tab
- The last line (65) should be negative
- Export the BOE file using the gear menu
- Check the last value of section 4 in the file

### Before the fix:
Negative values were not marked with N

opw-5482706

Forward-Port-Of: odoo/enterprise#113200
Forward-Port-Of: odoo/enterprise#111262

### Issue before this commit:
Before this commit, validating an Italian withholding tax return could incorrectly include taxes that are not related to withholding. In particular, pension fund taxes such as 4% INPS were included in the computed total amount to pay, even though they should not be part of the withholding tax return. As a result, the final amount shown in the return was incorrect.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it and switch to italian company
2. Create an invoice and a bill with a witholding tax (ex. 20% RIT PF)
3. Mark them as paid and reconcile them
4. Open a tax return and validate it
5. See that the total amount calculated includes also other taxes than only witholding taxes

### Cause of the issue:
The issue was caused by a missing domain restriction when computing the tax closing entries. The method _get_vat_closing_entry_additional_domain did not properly apply a filter on tax tags for the withholding tax return type l10n_it_reports.it_withh_tax_return_type. Because of this, the query used to compute tax balances included all taxes matching the generic conditions (date, company, posted state, etc.), without restricting them to the relevant withholding tax tags. Consequently, unrelated taxes were included in the computation.

### Reason to introduce the fix:
To restore the correctness of the tax return totals.

opw-5905355

Forward-Port-Of: odoo/enterprise#112638

# How to reproduce
- Install the eLearning module
- Log in as a portal user
- Make sure this portal user has more than 0 karma (Use demo Joel Willis or go through a quick Course)
- Go to Courses > View your profile (on the right side) > Edit Profile
- Edit any value and confirm by clicking on the Update button

# The problem
The popup is not saved and a warning notification is displayed with : "You are not allowed to modifiy 'User' (res.users) records"

# Why
In 19.0, there was no access rights problem because the write operation was done in `sudo` due to this code that checked that every edited field was safe :

https://github.com/odoo/odoo/blob/4f77b4c8f7a3ee9f85f045eea02a5749affd4b6a/odoo/addons/base/models/res_users.py#L615

This was the case because we preventively filtered only the safe fields in the save controller :

https://github.com/odoo/odoo/blob/355643291e2f4bb05185b996adce6e1f403ecbd4/addons/website_profile/controllers/main.py#L153

In 19.1 though, this commit totally changed the way the acces rights for the fields of the user model were handled :

https://github.com/odoo/odoo/commit/a816d151ae16afc62d7980cedc492942bc181884

One of the purpose of this improvement was to make sure a `sudo` is not automatically introduced and rather should be done explicitely when it is needed.

# Proposed solution
We first check that the current user can modifiy the specified user. If that is the case, we write with `sudo`

opw-6032339

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

Forward-Port-Of: odoo/odoo#256888

Issue:
Export XML button doesn't produce the same file as the send button.

Steps to reproduce:
- Company in Spain with Peppol (work with any Peppol country)
- Partner in Croatia
- Select eInvoice Type as "EU Standard (Peppol Bis 3.0)"
- Create an invoice
- Confirm it
- Click on the Wheel -> Download

Current behavior:
- without l10n_hr_edi: only "PDF" and "PDF without Payment"
- with l10n_hr_edi: "Export XML" appear, but try to create an "ubl_hr" file

Cause:
"Export XML" button appear only if:
- there is a default ubl option for the partner country
- there is an XML attached to the invoice when clicked it exports the corresponding one.

Whereas, the 'send' button rely on:
1) the partner defined edi format,
2) the default ubl option for the partner country
3) "ubl_bis3"

To be noted:
The route to download the XML doesn't keep the context of the active company and fallback to the first allowed company. As invoice_edi_format is company dependent it needs to be exported in the format defined for the company of the invoice.

opw-5943500

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

Forward-Port-Of: odoo/odoo#257990
Forward-Port-Of: odoo/odoo#253650

Steps to reproduce:
1. Install modules `account_batch_payment` and `l10n_ch`.
2. Configure SEPA Credit Transfer for a CH company.
3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer.
4. Create a batch payment with the SEPA payment and validate it.

Issue:
The `&` character is exported as `&amp` in the generated PAIN XML,
while according to the SIX specification it should be replaced with `+`

Cause:
The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed.

Solution:
Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML.

Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf

opw-5941724

Co-authored by @bhra-odoo

Forward-Port-Of: odoo/enterprise#110809

Currently, when a rental product's quantity on hand drops to 0, the out-of-stock ribbon is displayed on the website for that product.

Steps to produce:
---
- Install the `eCommerce Rental with Stock Management` module.
- Create a rental product and set Quantity On Hand to 1.
- Under the Sales tab, disable `Sell when Out of Stock`.
- Under the Rental Prices tab, add pricing.
- Go to `website > ecommerce > products > product ribbons`.
- Open `out of stock` ribbon > set assign as `when out of stock`.
- Create and Confirm a rental order for that product and validate the pickup.
- The product's Quantity On Hand drops to 0.
- Opening the product on the website

Observation:
---
- The product shows the out-of-stock ribbon.

Cause:
---
- At [1], the or condition evaluates to True because the ribbon is configured
  as `when out of stock`, `Sell when Out of Stock` is disabled under the
  Sales tab, and `_is_sold_out` also returns True since the quantity dropped to
  0 after the pickup was validated. As all conditions are met, the ribbon
  is returned and displayed without ever checking whether the product is
  a rental.

Skip the out-of-stock ribbon assignment for rental products, since their
stock availability is time-based.

[1]: https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/addons/website_sale_stock/models/product_ribbon.py#L21-L28

opw-6081483
---

Forward-Port-Of: odoo/enterprise#113280
Forward-Port-Of: odoo/enterprise#112660

When creating tasks from a project template via a Sales Order, the main
task is created with its sale_line_id set correctly, but subtasks from
the template do not inherit the sale_line_id from their parent.

Steps to reproduce:
1. Create a project template with a parent task and subtasks
2. Create a service product that uses this project template
3. Create and confirm a Sales Order with this product
4. Check the created tasks: main task has sale_line_id, subtasks don't
5. Log hours on a subtask: the timesheet's so_line remains empty

Root cause:
When copying a project template, the copy_data() method for subtasks
was resetting the default dict to only contain 'parent_id': False. This
meant that whitelisted fields like sale_line_id from the parent task
were not propagated to the subtasks during the copy operation.

Solution:
When copying from a template (copy_from_template context), preserve
whitelisted fields (including sale_line_id) in the default dict before
copying subtasks. This allows subtasks to naturally inherit sale_line_id
from their parent during creation, so the compute method works correctly.

opw-5185519

Forward-Port-Of: odoo/odoo#236342

Currently, when a rental product's quantity on hand drops to 0, the out-of-stock ribbon is displayed on the website for that product.

Steps to produce:
---
- Install the `eCommerce Rental with Stock Management` module.
- Create a rental product and set Quantity On Hand to 1.
- Under the Sales tab, disable `Sell when Out of Stock`.
- Under the Rental Prices tab, add pricing.
- Go to `website > ecommerce > products > product ribbons`.
- Open `out of stock` ribbon > set assign as `when out of stock`.
- Create and Confirm a rental order for that product and validate the pickup.
- The product's Quantity On Hand drops to 0.
- Opening the product on the website

Observation:
---
- The product shows the out-of-stock ribbon.

Cause:
---
- At [1], the or condition evaluates to True because the ribbon is configured
  as `when out of stock`, `Sell when Out of Stock` is disabled under the
  Sales tab, and `_is_sold_out` also returns True since the quantity dropped to
  0 after the pickup was validated. As all conditions are met, the ribbon
  is returned and displayed without ever checking whether the product is
  a rental.

Skip the out-of-stock ribbon assignment for rental products, since their
stock availability is time-based.

[1]: https://github.com/odoo/odoo/blob/12dd03fb678870ddd3f1f8dca66aa3f934aa7985/addons/website_sale_stock/models/product_ribbon.py#L21-L28

opw-6081483
---

Forward-Port-Of: odoo/enterprise#112660

### Issue:
When setting Vendor Bills to Digitize on demand, it is no longer possible in 19.0 to trigger digitization manually if the Bill Date is not set 
A missing required fields error is raised

### Cause:
This PR: https://github.com/odoo/odoo/pull/238911
introduced a required field to prevent an error modal from appearing 
While this works as intended, it also blocks the `Digitize Document` action, which is supposed to populate the Bill Date automatically

### Fix:
A condition similar to the one used for the Digitize Document button is applied to allow triggering digitization without a Bill Date

The validation modal is still enforced afterward to ensure data consistency in case of manual edits

### Steps to reproduce:
- Install `account`
- In Settings, set `Document Digitization` for `Vendor Bills` to `Digitize on demand only`
- Create and print an invoice (any data) or use an existing one
- Import it into Vendor Bills
- Click Digitize Document

### Before the fix:
A missing required fields notification is raised, preventing digitization

opw-5886012

Forward-Port-Of: odoo/enterprise#112585

### Issue:
Negative values in the Mod 390 report were not properly marked with the N indicator for several fields

### Cause:
The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export

### Note:
According to the official specification, negative amounts must be explicitly marked with N
Latest documentation:
https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx

### Steps to reproduce:
- Install `l10n_es_reports` with demo data and switch to the ES company
- Create a Bill (Price: 100, Taxes: 21% G)
- Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year
- Open the VAT Deductible tab
- The last line (65) should be negative
- Export the BOE file using the gear menu
- Check the last value of section 4 in the file

### Before the fix:
Negative values were not marked with N

opw-5482706

Forward-Port-Of: odoo/enterprise#113200
Forward-Port-Of: odoo/enterprise#111262

### Issue before this commit:
Before this commit, validating an Italian withholding tax return could incorrectly include taxes that are not related to withholding. In particular, pension fund taxes such as 4% INPS were included in the computed total amount to pay, even though they should not be part of the withholding tax return. As a result, the final amount shown in the return was incorrect.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it and switch to italian company
2. Create an invoice and a bill with a witholding tax (ex. 20% RIT PF)
3. Mark them as paid and reconcile them
4. Open a tax return and validate it
5. See that the total amount calculated includes also other taxes than only witholding taxes

### Cause of the issue:
The issue was caused by a missing domain restriction when computing the tax closing entries. The method _get_vat_closing_entry_additional_domain did not properly apply a filter on tax tags for the withholding tax return type l10n_it_reports.it_withh_tax_return_type. Because of this, the query used to compute tax balances included all taxes matching the generic conditions (date, company, posted state, etc.), without restricting them to the relevant withholding tax tags. Consequently, unrelated taxes were included in the computation.

### Reason to introduce the fix:
To restore the correctness of the tax return totals.

opw-5905355

Forward-Port-Of: odoo/enterprise#112638

Steps to reproduce:
1. Install modules `account_batch_payment` and `l10n_ch`.
2. Configure SEPA Credit Transfer for a CH company.
3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer.
4. Create a batch payment with the SEPA payment and validate it.

Issue:
The `&` character is exported as `&amp` in the generated PAIN XML,
while according to the SIX specification it should be replaced with `+`

Cause:
The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed.

Solution:
Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML.

Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf

opw-5941724

Co-authored by @bhra-odoo

Forward-Port-Of: odoo/enterprise#110809

### Issue:
Negative values in the Mod 390 report were not properly marked with the N indicator for several fields

### Cause:
The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export

### Note:
According to the official specification, negative amounts must be explicitly marked with N
Latest documentation:
https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx

### Steps to reproduce:
- Install `l10n_es_reports` with demo data and switch to the ES company
- Create a Bill (Price: 100, Taxes: 21% G)
- Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year
- Open the VAT Deductible tab
- The last line (65) should be negative
- Export the BOE file using the gear menu
- Check the last value of section 4 in the file

### Before the fix:
Negative values were not marked with N

opw-5482706

Forward-Port-Of: odoo/enterprise#113200
Forward-Port-Of: odoo/enterprise#111262

# How to reproduce
- Create a new Journal
- Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity account
- Go to the Transactions of the Journal
- Add a new Transaction for partner X and amount Y
- Add a second Transaction also for partner X and amount Y

# The issue
A popup appears that can never be saved

# Cause
When we click on "Add & New" or "Add & Close", we run the `validate()` function :

https://github.com/odoo/enterprise/blob/9abb50b9b29e01897b4fb90ae228beecbdfcd5af/account_accountant/static/src/components/bank_reconciliation/quick_create/quick_create.xml#L14-L16

Which tries to do a model save, but it fails so it show the Form dialog :

https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/web/static/src/views/kanban/kanban_record_quick_create.js#L159-L163

The save fails because :
This commit (https://github.com/odoo/enterprise/commit/e2b3439dcda26f84b9a290c8d5fb819dd3250825) changed the the logic behind auto-reconcilation with an outstanding account. When there is an outstanding account, we try to auto-reconcile the bank statement with that account and succesfully do so :

https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L381-L385

https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L245

But this should not happen when the outstanding account is the liquidity account, because it will end up throwing an error when the amount is matched more than once:

https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/account/models/account_bank_statement_line.py#L727-L737

opw-6063654

Forward-Port-Of: odoo/enterprise#112750

Problem:
'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend.

Solution:
Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty.

Transcript from Easypost support:
<< I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >>

opw-5402415

Forward-Port-Of: odoo/enterprise#111833

Steps to reproduce:
1. Install modules `account_batch_payment` and `l10n_ch`.
2. Configure SEPA Credit Transfer for a CH company.
3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer.
4. Create a batch payment with the SEPA payment and validate it.

Issue:
The `&` character is exported as `&amp` in the generated PAIN XML,
while according to the SIX specification it should be replaced with `+`

Cause:
The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed.

Solution:
Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML.

Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf

opw-5941724

Co-authored by @bhra-odoo

Forward-Port-Of: odoo/enterprise#110809

### Issue:
Negative values in the Mod 390 report were not properly marked with the N indicator for several fields

### Cause:
The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export

### Note:
According to the official specification, negative amounts must be explicitly marked with N
Latest documentation:
https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx

### Steps to reproduce:
- Install `l10n_es_reports` with demo data and switch to the ES company
- Create a Bill (Price: 100, Taxes: 21% G)
- Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year
- Open the VAT Deductible tab
- The last line (65) should be negative
- Export the BOE file using the gear menu
- Check the last value of section 4 in the file

### Before the fix:
Negative values were not marked with N

opw-5482706

Forward-Port-Of: odoo/enterprise#113200
Forward-Port-Of: odoo/enterprise#111262

[FIX] html_editor: undo link autoconvert before space insertion

When adding a space after an URL, the URL text is converted to an URL.
When pressing undo, first the space is undone, then the link is undone.
This is wrong because if the user did not want a link, after undoing the
link, inserting a new space will again convert to a link.

This commit splits `handleAutomaticLinkInsertion` into two parts:
determining if a link must be created, and actually inserting the link.
This makes it possible to execute code within the condition before and
after the insertion.
To fix the similar behavior for enter and shift-enter, another before
input handler is also added in order to let the default before input be
executed before creating the link.

Steps to reproduce:
- Go to a "To do" note
- Type "odoo.com"
- Press space/enter/shift-enter
- Undo a single time

=> The insertion was undone instead of the link transform.

task-5936310


[FIX] html_editor: not include surrounding backtick in pasted URL

When pasting an URL surrounded by backticks, the ending backtick is included inside the link's HREF.

This commit fixes the regex for URL to also exclude backticks (like it did with `"` and `'`).

Steps to reproduce:
- Copy the following text in the clipboard:
```
`odoo.com`
```
- Go to a "To do" note
- Paste

=> The link's URL was
```
odoo.com`
```

task-5936310

Forward-Port-Of: odoo/odoo#257647
Forward-Port-Of: odoo/odoo#248619

Problem:
'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend.

Solution:
Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty.

Transcript from Easypost support:
<< I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >>

opw-5402415

Forward-Port-Of: odoo/enterprise#111833

The _compute_cumulated_balance() method performs a query over every
existing move lines to get a dict associating the record id with
the cumulated sum at this point.

When there is a lot of move lines, the result returned by fetchall()
hits the memory limit and the server crashes.

We propose to encapsulate the original query to only return
the result for the account move lines present in self.

Benchmarks
---------------

The following benchmarks were generated with a customization of
the account.move.line list view to display the cumulated_balance
field.

Memory usage during the self.env.cr.execute and the dictionary
population:

|     Operation | Before the fix | After the fix |
|---------------|----------------|---------------|
| populate dict |         1.5 GB |       17.1 MB |
| execute query |         430 MB |        8.3 MB |

100 000 lines were displayed at the same time to get a significant
size.
So the number of records in self is more than 7 000 000 without
the fix and 100 000 with the fix.

Time spent in the _compute_cumulated_balance method:

| No of AML | Before the fix | After the fix |
|-----------|----------------|---------------|
| 7 000 000 |         10.4 s |         6.8 s |

opw-6053720

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

Forward-Port-Of: odoo/odoo#256658
Forward-Port-Of: odoo/odoo#255780

Steps to reproduce:
1. Install modules `account_batch_payment` and `l10n_ch`.
2. Configure SEPA Credit Transfer for a CH company.
3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer.
4. Create a batch payment with the SEPA payment and validate it.

Issue:
The `&` character is exported as `&amp` in the generated PAIN XML,
while according to the SIX specification it should be replaced with `+`

Cause:
The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed.

Solution:
Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML.

Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf

opw-5941724

Co-authored by @bhra-odoo

Forward-Port-Of: odoo/enterprise#110809

### Issue:
Negative values in the Mod 390 report were not properly marked with the N indicator for several fields

### Cause:
The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export

### Note:
According to the official specification, negative amounts must be explicitly marked with N
Latest documentation:
https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx

### Steps to reproduce:
- Install `l10n_es_reports` with demo data and switch to the ES company
- Create a Bill (Price: 100, Taxes: 21% G)
- Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year
- Open the VAT Deductible tab
- The last line (65) should be negative
- Export the BOE file using the gear menu
- Check the last value of section 4 in the file

### Before the fix:
Negative values were not marked with N

opw-5482706

Forward-Port-Of: odoo/enterprise#113200
Forward-Port-Of: odoo/enterprise#111262

# How to reproduce
- Install the l10n_th module
- Use the demo TH company
- Ensure you have the demo invoices and credit notes associated to that company
- Go to the Tax Report
- Select Tax Report (TH)
- Click on "Sales Tax Report (xlsx)"

# The problem
The Credit Notes' Total Amount, Total Excl and Vat Amount are positives. They should be negative instead. The same issue appear for "Purchase Tax Report (xlsx)".
This issue also concerns Credit Notes created manually in the Journal Entries

# Why
The logic for the sign of the value fields in the reports is the following :

```py
sign = move.reversed_entry_id.payment_state == 'partial' and -1 or 1
```

This is unreliable because a Credit Note will not always have a reversed_entry_id associated or if it has one, it's payment_state may change

A refactor of theses reports has been made for versions 19.0+ but it seems too big to backport (https://github.com/odoo/enterprise/pull/75645/changes)

Instead, we just check if the current move's type is a refund. If yes, we reverse the sign.

opw-6006720

Forward-Port-Of: odoo/enterprise#113372
Forward-Port-Of: odoo/enterprise#110816

*: stock_barcode_mrp, stock_barcode_picking_batch

## Issue Before This PR:
When navigating from the Barcode client action
(e.g. picking, inventory, etc.) to related form views
(such as lot, product, or company), the breadcrumb
would sometimes display an unnamed entry instead
of the originating document name.
This caused confusion for users, as they could not
easily identify which document they were coming from
when navigating to related records from the Barcode interface.

## Steps to Reproduce:
- Install the Barcode module.
- Open the Barcode app and navigate to:
     - Delivery Orders.
     - Manufacturing Orders
     - Batch Pickings
     - Inventory Count
- From any of these open a record
  (e.g. picking, MO, batch, inventory line)
- Click on document name or edit button on the line.
- Click on an external link (e.g. product, lot, company).
- Observe that the breadcrumb shows an unnamed entry.

## Cause of the Issue:
- When switching views inside the Barcode client action,
  the FormController calls `setDisplayName(this.displayName())`.
  In some cases, this returns an empty string, overwriting the
  previously set breadcrumb name.
- In several form views, the `display_name` field was not present,
  preventing the controller from retrieving a proper name.

## With This PR:
The Barcode views now display the correct document names in the
breadcrumb when navigating to external links, allowing users to easily
identify the originating document when opening related records from
the Barcode app.

TaskID: 4978997

Forward-Port-Of: odoo/enterprise#112988
Forward-Port-Of: odoo/enterprise#99165

### Issue:
When setting Vendor Bills to Digitize on demand, it is no longer possible in 19.0 to trigger digitization manually if the Bill Date is not set 
A missing required fields error is raised

### Cause:
This PR: https://github.com/odoo/odoo/pull/238911
introduced a required field to prevent an error modal from appearing 
While this works as intended, it also blocks the `Digitize Document` action, which is supposed to populate the Bill Date automatically

### Fix:
A condition similar to the one used for the Digitize Document button is applied to allow triggering digitization without a Bill Date

The validation modal is still enforced afterward to ensure data consistency in case of manual edits

### Steps to reproduce:
- Install `account`
- In Settings, set `Document Digitization` for `Vendor Bills` to `Digitize on demand only`
- Create and print an invoice (any data) or use an existing one
- Import it into Vendor Bills
- Click Digitize Document

### Before the fix:
A missing required fields notification is raised, preventing digitization

opw-5886012

Forward-Port-Of: odoo/enterprise#112585

### Issue:
Negative values in the Mod 390 report were not properly marked with the N indicator for several fields

### Cause:
The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export

### Note:
According to the official specification, negative amounts must be explicitly marked with N
Latest documentation:
https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx

### Steps to reproduce:
- Install `l10n_es_reports` with demo data and switch to the ES company
- Create a Bill (Price: 100, Taxes: 21% G)
- Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year
- Open the VAT Deductible tab
- The last line (65) should be negative
- Export the BOE file using the gear menu
- Check the last value of section 4 in the file

### Before the fix:
Negative values were not marked with N

opw-5482706

Forward-Port-Of: odoo/enterprise#113200
Forward-Port-Of: odoo/enterprise#111262

### Issue before this commit:
Before this commit, validating an Italian withholding tax return could incorrectly include taxes that are not related to withholding. In particular, pension fund taxes such as 4% INPS were included in the computed total amount to pay, even though they should not be part of the withholding tax return. As a result, the final amount shown in the return was incorrect.

### Steps to reproduce the issue:
1. Download Accounting and l10n_it and switch to italian company
2. Create an invoice and a bill with a witholding tax (ex. 20% RIT PF)
3. Mark them as paid and reconcile them
4. Open a tax return and validate it
5. See that the total amount calculated includes also other taxes than only witholding taxes

### Cause of the issue:
The issue was caused by a missing domain restriction when computing the tax closing entries. The method _get_vat_closing_entry_additional_domain did not properly apply a filter on tax tags for the withholding tax return type l10n_it_reports.it_withh_tax_return_type. Because of this, the query used to compute tax balances included all taxes matching the generic conditions (date, company, posted state, etc.), without restricting them to the relevant withholding tax tags. Consequently, unrelated taxes were included in the computation.

### Reason to introduce the fix:
To restore the correctness of the tax return totals.

opw-5905355

Forward-Port-Of: odoo/enterprise#112638

Steps to reproduce:
1. Install modules `account_batch_payment` and `l10n_ch`.
2. Configure SEPA Credit Transfer for a CH company.
3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer.
4. Create a batch payment with the SEPA payment and validate it.

Issue:
The `&` character is exported as `&amp` in the generated PAIN XML,
while according to the SIX specification it should be replaced with `+`

Cause:
The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed.

Solution:
Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML.

Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf

opw-5941724

Co-authored by @bhra-odoo

Forward-Port-Of: odoo/enterprise#110809

### Issue:
Negative values in the Mod 390 report were not properly marked with the N indicator for several fields

### Cause:
The parameter `signed=True` was missing on some fields where negative values should include the N indicator in the BOE export

### Note:
According to the official specification, negative amounts must be explicitly marked with N
Latest documentation:
https://sede.agenciatributaria.gob.es/static_files/Sede/Disenyo_registro/DR_300_399/archivos_25/dr390e2025.xlsx

### Steps to reproduce:
- Install `l10n_es_reports` with demo data and switch to the ES company
- Create a Bill (Price: 100, Taxes: 21% G)
- Go to Tax Report and select Tax Report (Mod 390) (ES) for the full year
- Open the VAT Deductible tab
- The last line (65) should be negative
- Export the BOE file using the gear menu
- Check the last value of section 4 in the file

### Before the fix:
Negative values were not marked with N

opw-5482706

Forward-Port-Of: odoo/enterprise#113200
Forward-Port-Of: odoo/enterprise#111262

Steps to reproduce:
- Set a journal with documents folder sync (by default with demo data)
- Create and post a customer invoice
- Add an image or pdf attachment via a log note (it becomes message_main_attachment_id and creates a documents.document with res_model=False)
- Click Send & Print

Issue:
KeyError: `proforma_pdf_attachment`

Cause:
During Send & Print, _link_invoice_documents creates the invoice pdf attachment (res_model='account.move', res_field='invoice_pdf_report_file') and sets it as invoice.message_main_attachment_id.

During the acoun_move write, in `documents_account`, it searches for an existing document matching the previous `message_main_attachment_id` (`initial_attachment`) and sets `document.attachment_id` to the invoice pdf. https://github.com/odoo/enterprise/blob/6bdcc357b195faa0aad8c05eac23aa0a762dd76b/documents_account/models/account_move.py#L41-L54

This triggers the versioning logic which
resets the parent of the attachment when its `res_model` and `res_id` differs from the document. Because the document has res_model=False, the condition always matches and the pdf is re-parented to `documents.document`, deleting res_field's binding to account.move.

After invalidate_recordset
https://github.com/odoo/odoo/blob/95666545fcd934bf4084f680e692633783ae5603/addons/account/models/account_move_send.py#L477 invoice_pdf_report_id recomputes to an empty
recordset.
https://github.com/odoo/odoo/blob/7b384a6ec13c372b44e2a58134c61d54de152395/addons/account/models/account_move.py#L2205 _get_invoice_extra_attachments returns empty,
Eventually, we try to access move_data['proforma_pdf_attachment'] which was never set (fallback for otehrscenario) https://github.com/odoo/odoo/blob/95666545fcd934bf4084f680e692633783ae5603/addons/account/models/account_move_send.py#L856 -> KeyError.

Solution:
We prevent the creation of a document if no res_model is set.
And extra guard-rail is kept:
Skip re-parenting in DocumentsDocument.write() when the incoming attachment
has res_field set. Attachments linked via a Binary field are owned by their
model and must never be moved to documents.document regardless of the
document's own res_model.

opw-5930888

Problem:
'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend.

Solution:
Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty.

Transcript from Easypost support:
<< I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >>

opw-5402415

Forward-Port-Of: odoo/enterprise#111833

Steps to reproduce:
1. Install modules `account_batch_payment` and `l10n_ch`.
2. Configure SEPA Credit Transfer for a CH company.
3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer.
4. Create a batch payment with the SEPA payment and validate it.

Issue:
The `&` character is exported as `&amp` in the generated PAIN XML,
while according to the SIX specification it should be replaced with `+`

Cause:
The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed.

Solution:
Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML.

Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf

opw-5941724

Co-authored by @bhra-odoo

Forward-Port-Of: odoo/enterprise#110809

# How to reproduce
- Create a new Journal
- Go to the Configuration of the Journal > Outgoing Payments > Set the Outstanding Payment accounts for the Manual payment Payment Method to the liquidity account
- Go to the Transactions of the Journal
- Add a new Transaction for partner X and amount Y
- Add a second Transaction also for partner X and amount Y

# The issue
A popup appears that can never be saved

# Cause
When we click on "Add & New" or "Add & Close", we run the `validate()` function :

https://github.com/odoo/enterprise/blob/9abb50b9b29e01897b4fb90ae228beecbdfcd5af/account_accountant/static/src/components/bank_reconciliation/quick_create/quick_create.xml#L14-L16

Which tries to do a model save, but it fails so it show the Form dialog :

https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/web/static/src/views/kanban/kanban_record_quick_create.js#L159-L163

The save fails because :
This commit (https://github.com/odoo/enterprise/commit/e2b3439dcda26f84b9a290c8d5fb819dd3250825) changed the the logic behind auto-reconcilation with an outstanding account. When there is an outstanding account, we try to auto-reconcile the bank statement with that account and succesfully do so :

https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L381-L385

https://github.com/odoo/enterprise/blob/e2b3439dcda26f84b9a290c8d5fb819dd3250825/account_accountant/models/account_bank_statement.py#L245

But this should not happen when the outstanding account is the liquidity account, because it will end up throwing an error when the amount is matched more than once:

https://github.com/odoo/odoo/blob/6e77d840a2876e45544b21a911be05b2f32b8afb/addons/account/models/account_bank_statement_line.py#L727-L737

opw-6063654

Forward-Port-Of: odoo/enterprise#112750

Problem:
'tracker' object in response from GET /orders/:id request can sometimes be null. This means that when the mail template 'mail_template_data_delivery_confirmation' is sent, a traceback occurs with error: TypeError: 'NoneType' object is not subscriptable. As a result the picking is not validated in odoo but a shipping has succesfully been created in the easypost backend.

Solution:
Prevent traceback form happening, picking gets correctly validated and carrier_tracking_url field is empty.

Transcript from Easypost support:
<< I'm also seeing the tracker showing as null when reviewing the response. I'll go ahead and create a ticket for the engineering team to investigate. I can see that the tracking code is being returned in the request, but the full tracking object is not. Since this appears to be happening on a case-by-case basis, you may want to allow more time between the BUY and the GET requests, as I noticed they are being triggered very close together. I'm not certain if that's related, but it may be worth trying as a troubleshooting step while we have this under review. >>

opw-5402415

Forward-Port-Of: odoo/enterprise#111833

Steps to reproduce:
1. Install modules `account_batch_payment` and `l10n_ch`.
2. Configure SEPA Credit Transfer for a CH company.
3. Create a vendor bill with a reference containing `&` (e.g. "Net & Cost"), confirm it and register a payment using SEPA Credit Transfer.
4. Create a batch payment with the SEPA payment and validate it.

Issue:
The `&` character is exported as `&amp` in the generated PAIN XML,
while according to the SIX specification it should be replaced with `+`

Cause:
The payment reference is inserted into the PAIN XML file without replacing the '&' character. During XML generation this produces an invalid entity (`&`) which results in an `XMLSyntaxError` and prevents the payment file from being processed.

Solution:
Replace the `&` character with `+` when sanitizing the payment communication so that the generated value complies with the SEPA/SIX character set and produces valid XML.

Reference[Pg: 9]: https://www.europeanpaymentscouncil.eu/sites/default/files/KB/files/EPC217-08%20Draft%20Best%20Practices%20SEPA%20Requirements%20for%20Character%20Set%20v1.1.pdf

opw-5941724

Co-authored by @bhra-odoo

Forward-Port-Of: odoo/enterprise#110809

# How to reproduce
- Install the l10n_th module
- Use the demo TH company
- Ensure you have the demo invoices and credit notes associated to that company
- Go to the Tax Report
- Select Tax Report (TH)
- Click on "Sales Tax Report (xlsx)"

# The problem
The Credit Notes' Total Amount, Total Excl and Vat Amount are positives. They should be negative instead. The same issue appear for "Purchase Tax Report (xlsx)".
This issue also concerns Credit Notes created manually in the Journal Entries

# Why
The logic for the sign of the value fields in the reports is the following :

```py
sign = move.reversed_entry_id.payment_state == 'partial' and -1 or 1
```

This is unreliable because a Credit Note will not always have a reversed_entry_id associated or if it has one, it's payment_state may change

A refactor of theses reports has been made for versions 19.0+ but it seems too big to backport (https://github.com/odoo/enterprise/pull/75645/changes)

Instead, we just check if the current move's type is a refund. If yes, we reverse the sign.

opw-6006720

Forward-Port-Of: odoo/enterprise#110816

# How to reproduce
- Install the l10n_th module
- Use the demo TH company
- Ensure you have the demo invoices and credit notes associated to that company
- Go to the Tax Report
- Select Tax Report (TH)
- Click on "Sales Tax Report (xlsx)"

# The problem
The Credit Notes' Total Amount, Total Excl and Vat Amount are positives. They should be negative instead. The same issue appear for "Purchase Tax Report (xlsx)".
This issue also concerns Credit Notes created manually in the Journal Entries

# Why
The logic for the sign of the value fields in the reports is the following :

```py
sign = move.reversed_entry_id.payment_state == 'partial' and -1 or 1
```

This is unreliable because a Credit Note will not always have a reversed_entry_id associated or if it has one, it's payment_state may change

A refactor of theses reports has been made for versions 19.0+ but it seems too big to backport (https://github.com/odoo/enterprise/pull/75645/changes)

Instead, we just check if the current move's type is a refund. If yes, we reverse the sign.

opw-6006720

**Steps to reproduce:**
1. Install l10n_nl_report.
2. Go to Accounting → Configuration  →  Accounting Reports.
3. Open Profit and loss report (tags).
4. Click on Cost of Goods Sold or Cost of Sales and check the related codes.

**Issue:**
In the Dutch Profit and Loss report, the names "Cost of Goods Sold" and "Cost of Sales" are swapped.
Currently:
- Cost of Goods Sold is linked to code: NL_SALE
- Cost of Sales is linked to code: NL_COGS

According to Dutch accounting standards:
- Cost of goods sold should represent direct costs ([mapping to NL_COGS / 7xxx](https://github.com/odoo/odoo/blob/master/addons/l10n_nl/data/template/account.account-nl.csv#L288-L317)).
- Cost of sales should represent indirect selling costs ([mapping to NL_SALE/45xx](https://github.com/odoo/odoo/blob/master/addons/l10n_nl/data/template/account.account-nl.csv#L249-L260))

**Cause:**
The names were incorrectly applied, leading to reversed definitions between Cost of Goods Sold and Cost of Sales.
See: https://www.investopedia.com/terms/c/cogs.asp

**Solution:**
Swap the definitions so that:
- Cost of Goods Sold is correctly linked to NL_COGS
- Cost of Sales is correctly linked to NL_SALE

Related community PR : https://github.com/odoo/odoo/pull/245185

**opw-5407885**