Fix crash when a retention tax is applied on an invoice that includes a down payment line. Steps to reproduce: 1. Create a retention tax (negative, with retention checked) 2. Create a sale order with product A 3. Create and validate a down payment invoice 4. Create the full invoice and add the retention tax to the line of product A 5. Try to submit to ZATCA This raises: `IndexError: list index out of range → tax_category_vals = self._get_tax_category_list(...)[0]` The issue occur

Fix crash when a retention tax is applied on an invoice that includes a down payment line.

Steps to reproduce:
1. Create a retention tax (negative, with retention checked)
2. Create a sale order with product A
3. Create and validate a down payment invoice
4. Create the full invoice and add the retention tax to the line of product A
5. Try to submit to ZATCA

This raises:
`IndexError: list index out of range
→ tax_category_vals = self._get_tax_category_list(...)[0]`

The issue occurs because the retention tax is not filtered due to a missing `filter_to_apply` parameter.

opw-4771567

Forward-Port-Of: odoo/odoo#213352
Forward-Port-Of: odoo/odoo#208946

\*: website_mail This PR addresses several issues in the blog module, including: Commit [1]: retain follow-us input button when logged in - Steps to reproduce: 1. Go to any blog post. 2. Enable the sidebar. 3. Select any category (e.g., Travel). Issue: A subscribe button appears in the 'Follow Us' section. - Solution: Currently, the input field is only shown to public users. This happens because the input element is restricted by the `base.groups_public` group in the XML code. Si

\*: website_mail

This PR addresses several issues in the blog module, including:

Commit [1]: retain follow-us input button when logged in

- Steps to reproduce:
1. Go to any blog post.
2. Enable the sidebar.
3. Select any category (e.g., Travel).
Issue: A subscribe button appears in the 'Follow Us' section.

- Solution: Currently, the input field is only shown to public users. This happens because the input element is restricted by the `base.groups_public` group in the XML code. Since this is an XML change in v17.0 (stable version), we need to implement the fix in JS instead. After that, we will adapt the code from the master branch.


Commit [2]: remove unnecessary months from blog category

- Steps to reproduce:
1. Have a blog post in a category (e.g., Astronomy) published in Feb-2025.
2. In another category (e.g., Travel), have blog posts in both Jan-2025 and Feb-2025.
3. When selecting the Astronomy category, the sidebar `Archives` filter shows all months, even if no blog post exists in Jan 2025.

- Solution: It will now show only months that contain blog posts for the selected category. Filter out from the backend according to their publishing date.


Commit [3]: correct tag redirection to backend in blog posts

- Steps to reproduce:
1. Go to any blog post.
2. Turn on the sidebar.
3. Create a new blog post.
4. Save it. 
Issue : clicking `add some` on tags redirects to the homepage instead of the backend of that blog post.

- Solution: a wrong URL was inserted in the anchor tag. For stable, we changed it from JS, but it will be applied to XML in master.

task-4546888

Forward-Port-Of: odoo/odoo#210999
Forward-Port-Of: odoo/odoo#197172

1. Have sales and project installed 2. Create a service product which creates a project on order 3. Set up a distribution model for this service 4. Create a sales order with this service. Confirm it. 5. The project account is added to the analytic distribution in a separate line In odoo/odoo#199763, `_compute_analytic_distribution()` in the SO line was changed to add both project account and ditribution model accounts in the analytic distribution. However, the project account should not h

1. Have sales and project installed
2. Create a service product which creates a project on order
3. Set up a distribution model for this service
4. Create a sales order with this service. Confirm it.
5. The project account is added to the analytic distribution in a separate line

In odoo/odoo#199763, `_compute_analytic_distribution()` in the SO line was changed to add both project account and ditribution model accounts in the analytic distribution. However, the project account should not have its own line and should instead be added to all lines coming from Analytical Distribution Models.

no-task

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

Forward-Port-Of: odoo/odoo#213310

This commit fixes an action service concurrency test that fails randomly. The way the test was written was prone to errors as we didn't wait for the router to be updated before doing browser back. As a matter of fact, we even asserted that we went 2 actions back in the breadcrumbs, whereas it should be only one as we did one browser.history.back(). runbot error~163078 Description of the issue/feature this PR addresses: Current behavior before PR: Desired behavior after PR is merged:

This commit fixes an action service concurrency test that fails randomly. The way the test was written was prone to errors as we didn't wait for the router to be updated before doing browser back. As a matter of fact, we even asserted that we went 2 actions back in the breadcrumbs, whereas it should be only one as we did one browser.history.back().

runbot error~163078

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

Forward-Port-Of: odoo/odoo#213377

Currently the signature of function `_notify_by_email_prepare_rendering_context` in `account_peppol` is not compatible with all ways to call the super function. This can lead to code breaking when `account_peppol` is installed (although it works fine without). This is fixed in this commit. Detail: In module `mail` the (super) function has signature ```python def _notify_by_email_prepare_rendering_context(self, message, msg_vals=False,

Currently the signature of function `_notify_by_email_prepare_rendering_context` in `account_peppol` is not compatible with all ways to call the super function. This can lead to code breaking when `account_peppol` is installed (although it works fine without).

This is fixed in this commit.

Detail:

In module `mail` the (super) function has signature
```python
    def _notify_by_email_prepare_rendering_context(self, message, msg_vals=False,
                                                   model_description=False,
                                                   force_email_company=False,
                                                   force_email_lang=False):
```

Currently in `acccount_peppol` the signature is
```python
    def _notify_by_email_prepare_rendering_context(self, message, **kwargs):
```

The super function can be called as follows while the function in `account_peppol` can not.
```python
    _notify_by_email_prepare_rendering_context(self, message, msg_vals)
```

opw-4846106

Forward-Port-Of: odoo/odoo#213516

- Vendor bills with taxes of l10n_es_type == 'sujeto_agricultura' (REAGYP) must be reported with regime code '19', as per TicketBAI specifications. - This fix ensures that such invoices include '19' in `regime_key`, avoiding schema validation errors and ensuring legal compliance. https://www.batuz.eus/fitxategiak/batuz/ticketbai/ticketbaiv1-2-2.xsd OPW-4532600 Forward-Port-Of: odoo/odoo#212926 Forward-Port-Of: odoo/odoo#211229

- Vendor bills with taxes of l10n_es_type == 'sujeto_agricultura' (REAGYP) must be reported with regime code '19', as per TicketBAI specifications.
- This fix ensures that such invoices include '19' in `regime_key`, avoiding schema validation errors and ensuring legal compliance.

https://www.batuz.eus/fitxategiak/batuz/ticketbai/ticketbaiv1-2-2.xsd

OPW-4532600

Forward-Port-Of: odoo/odoo#212926
Forward-Port-Of: odoo/odoo#211229

Added new tax and tax group for the 24% VAT rate effective from 1 July 2025. Updated account.tax.report to include a new line for the 24% VAT rate (Line 1) to ensure backward compatibility with reports generated before 1 July 2025. Updated account.tax.report to include a new line for the 22% VAT rate (Line 1_2). Ensured automatic creation of new taxes and tax groups during module upgrade. Adjusted related tax report data and views reflect the updated VAT rate. Maintained compatibility wi

Added new tax and tax group for the 24% VAT rate effective from 1 July 2025. 
Updated account.tax.report to include a new line for the 24% VAT rate (Line 1) to ensure backward compatibility with reports generated before 1 July 2025. 
Updated account.tax.report to include a new line for the 22% VAT rate (Line 1_2). 
Ensured automatic creation of new taxes and tax groups during module upgrade. Adjusted related tax report data and views reflect the updated VAT rate. 
Maintained compatibility with existing data and reports by preserving the 22% VAT rate for historical records. 

For technical info please see:
https://www.emta.ee/en/business-client/e-services-training-courses/how-use-e-services/technical-information-services#value-added-tax-return
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#207751

Steps to reproduce: - Have a [TAX] configured with: - Affect Base of Subsequent Taxes: True - Base Affected by Previous Taxes: True - Tax Exigibility: Based on payment - Distribution for invoices: - Base, Tax grids: +A, +B - 100% of tax, Tax grids: +C - -100% of tax, Tax grids: -D, -E - Distribution for refunds: - Base, Tax grids: -A, -B - 100% of tax, Tax grids: -C - -100% of tax, Tax grids: +D, +E - Create a BILL with [TAX] - Create a matching Ba

Steps to reproduce:
- Have a [TAX] configured with:
  - Affect Base of Subsequent Taxes: True
  - Base Affected by Previous Taxes: True
  - Tax Exigibility: Based on payment
  - Distribution for invoices:
    - Base, Tax grids: +A, +B
    - 100% of tax, Tax grids: +C
    - -100% of tax, Tax grids: -D, -E
  - Distribution for refunds:
    - Base, Tax grids: -A, -B
    - 100% of tax, Tax grids: -C
    - -100% of tax, Tax grids: +D, +E
- Create a BILL with [TAX]
- Create a matching Bank statement and reconcile with BILL
- Check the created Cash Basis Entry

Issue:

VAT line will feature base tags +A, +B in addition to the tax tags +C
This occurs because in the source bill 2 tax lines are created, the first one got the origin tax assigned
When the cash basis move is created the tax tags will be taken also from that tax

opw-4729298

Forward-Port-Of: odoo/odoo#209284

Improve the error message when the response is HTTP 403. Currently, the content is empty for such errors, making it difficult to identify the source of the problem for users. Step to reproduce: - Try to send an invoice with wrong credentials. - The error message is empty, making it hard to understand what went wrong. Error message before this commit:  After: ![image](https://github.com/user-at

Improve the error message when the response is HTTP 403. Currently, the content is empty for such errors, making it difficult to identify the source of the problem for users.

Step to reproduce:
- Try to send an invoice with wrong credentials.
- The error message is empty, making it hard to understand what went wrong.

Error message before this commit:
![image](https://github.com/user-attachments/assets/52296dbe-7aff-4efb-ace4-6e882b60a5fa)


After:
![image](https://github.com/user-attachments/assets/23ae92d4-1c23-4bd2-8169-a88add306f28)


Also added the missing .pot file.

opw-4823950
opw-4628908

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

Forward-Port-Of: odoo/odoo#212379

- Install l10n_it_edi. - Install l10n_it_edi_withholding - Uninstall l10n_it_edi_withholding - Attempt an install of l10n_it_edi_withholding The following error appears: Invoice and credit note distribution should each contain exactly one line for the base. When uninstalling l10n_it_edi_withholding, the account.tax data are not unlinked which causes issues when _l10n_it_edi_withholding_post_init tries to _load_data with them. This commit prevents already existing account tax from bei

- Install l10n_it_edi.
- Install l10n_it_edi_withholding
- Uninstall l10n_it_edi_withholding
- Attempt an install of l10n_it_edi_withholding

The following error appears: Invoice and credit note distribution should each contain exactly one line for the base.

When uninstalling l10n_it_edi_withholding, the account.tax data are not unlinked which causes issues when _l10n_it_edi_withholding_post_init tries to _load_data with them.

This commit prevents already existing account tax from being loaded from data during the installation.

Ticket [link](https://www.odoo.com/odoo/project/967/tasks/4798659)
opw-4798659

Forward-Port-Of: odoo/odoo#211910

Problem: When a video is added to the `website_description` field using the website editor, it appears visually shifted to the left (by 50%) when viewed from the Contacts page in the "Website Partner Full Description" field. Cause: The class `o-position-absolute` sets `left: auto` which was evaluated as `50%`, and`margin-left: -50%` was added to center absolutely positioned elements. However, this causes issues when rendered in `html_field` context, where `left: auto` evaluates to `0px`. As

Problem:
When a video is added to the `website_description` field using the website editor, it appears visually shifted to the left (by 50%) when viewed from the Contacts page in the "Website Partner Full Description" field.

Cause:
The class `o-position-absolute` sets `left: auto` which was evaluated as `50%`, and`margin-left: -50%` was added to center absolutely positioned elements. However, this causes issues when rendered in `html_field` context, where `left: auto` evaluates to `0px`. As a result, the `-50%` margin shifts the video offscreen.

Solution:
Set both `left` and `right` to `0` in `.o-position-absolute` to ensure proper centering. Remove `margin-left: -50%` to prevent misalignment in non-editor contexts.

**Before**:
In website editor:
![image](https://github.com/user-attachments/assets/c8affa50-bc83-4f7f-ad24-df1c7dc882ca)
In contacts (html_field):
![image](https://github.com/user-attachments/assets/d77c23cf-7205-4ac4-943b-05c9291b3fe3)

**After**
In website editor:
![image](https://github.com/user-attachments/assets/814d3704-9f10-49f9-8b4d-04821c5ad5db)
In contacts (html_field):
![image](https://github.com/user-attachments/assets/816aec60-671f-468f-8d0a-0b1c5590f5cf)

Steps to reproduce:
- Go to Contacts > "Gemini Furniture".
- Add a video in the "Website Partner Full Description" field.
- Save and open the partner on the website (`partners/gemini-furniture-11`).
- Return to the Contacts page. → The video appears shifted 50% to the left.

opw-4752567

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

Forward-Port-Of: odoo/odoo#212344

**Steps to reproduce 1:** - Install l10n_tz_account - Switch to a Tanzanian company (e.g. TZ Company) - Check the taxes **Issue 1:** Each tax has the same tax grids (i.e. same number and same sign) for the invoice section and the refund section, which leads to have the amount of the credit notes being added (instead of subtracted) in the Tax report. **Solution 1:** Invert the sign of the tax grids in the refund section. **Steps to reproduce 2:** - Create an invoice for a Tanzanian

**Steps to reproduce 1:**
- Install l10n_tz_account
- Switch to a Tanzanian company (e.g. TZ Company)
- Check the taxes

**Issue 1:**
Each tax has the same tax grids (i.e. same number and same sign) for the invoice section and the refund section, which leads to have the amount of the credit notes being added (instead of subtracted) in the Tax report.

**Solution 1:**
Invert the sign of the tax grids in the refund section.

**Steps to reproduce 2:**
- Create an invoice for a Tanzanian customer without VAT

**Issue 2:**
The default fiscal position will be "International", instead of "Domestic".
A domestic fiscal position for customer without VAT is missing.

**Solution 2:**
Add a "Domestic individual" fiscal position that is the same as the "Domestic" one except for the VAT that is not required.

opw-4840609



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

Forward-Port-Of: odoo/odoo#213416
Forward-Port-Of: odoo/odoo#213107

Description of the issue/feature this PR addresses: The system enforced a strict check that the delivery carrier partner must be located in Romania. This was limiting for companies that work with international carriers or operate across borders. Current behavior before PR: Delivery carriers not based in Romania triggered an error and could not be used in the delivery process. Desired behavior after PR is merged: Delivery carriers can now be located in any country. This provides greater

Description of the issue/feature this PR addresses:
The system enforced a strict check that the delivery carrier partner must be located in Romania. This was limiting for companies that work with international carriers or operate across borders.

Current behavior before PR:
Delivery carriers not based in Romania triggered an error and could not be used in the delivery process.

Desired behavior after PR is merged:
Delivery carriers can now be located in any country. This provides greater flexibility in managing logistics and integrating international shipping partners.



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

Forward-Port-Of: odoo/odoo#212476

Exported the SignatureForm class to allow overriding from other modules. Forward-Port-Of: odoo/odoo#213510

Exported the SignatureForm class to allow overriding from other modules.

Forward-Port-Of: odoo/odoo#213510

This error occurs when attempting to create a submenu item under a menu item. Steps to reproduce: - Go to `menu items`. - Click `New` > In `Submenus` click `Add a line` `TypeError: unsupported operand type(s) for +: 'bool' and 'str'` This error occurs when attempting to create a submenu item under a menu item that does not have a name. Since the menu item record has not been saved yet, the system assigns a new ID to the menu item and sets its name to False. When computing the comp

This error occurs when attempting to create a submenu item under a menu item.

Steps to reproduce:

 - Go to `menu items`.
 - Click `New` > In `Submenus` click `Add a line`

`TypeError: unsupported operand type(s) for +: 'bool' and 'str'`

This error occurs when attempting to create a submenu item under a menu item that does not have a name. Since the menu item record has not been saved yet, the system assigns a new ID to the menu item and sets its name to False. When computing the complete name for the submenu item, the menu(parent menu) item's name is False, which causes the error.

https://github.com/odoo/odoo/blob/d2ea23f252f0f8f329e2b0ff96de6ee2a14b922f/odoo/addons/base/models/ir_ui_menu.py#L56

This commit ensures that if the parent menu item record has not been saved and its name is False, an empty string is used in its place.

sentry-6368548342

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

Forward-Port-Of: odoo/odoo#210291

The E-way Bill date was previously displayed in the `YYYY-MM-DD` format. ---- **In this commit** - This change updates the date formatting logic to display dates in the `DD/MM/YYYY` format for better readability and consistency in ewaybill report. --- task-4807690 Forward-Port-Of: odoo/odoo#210583

The E-way Bill date was previously displayed in the `YYYY-MM-DD` format.

----
**In this commit**
- This change updates the date formatting logic to display dates in the `DD/MM/YYYY` 
   format for better readability and consistency in ewaybill report.

---
task-4807690

Forward-Port-Of: odoo/odoo#210583

**Steps to reproduce:** - Install base_vat and website_sale - Execute the following steps as a public user - From website, go to the Shop - Add a product to the cart - Proceed to checkout - Enter an address in Romania - Enter a valid CUI as VAT (e.g. 8001011234567) - Validate the address - Edit the address to see the issue **Issue:** The country code (i.e. RO) has been prepended to the input VAT, which is not correct. If the Romanian localization is installed and an invoice is crea

**Steps to reproduce:**
- Install base_vat and website_sale
- Execute the following steps as a public user
- From website, go to the Shop
- Add a product to the cart
- Proceed to checkout
- Enter an address in Romania
- Enter a valid CUI as VAT (e.g. 8001011234567)
- Validate the address
- Edit the address to see the issue

**Issue:**
The country code (i.e. RO) has been prepended to the input VAT, which is not correct.
If the Romanian localization is installed and an invoice is created from the order and sent to the government, it will be rejected because of the incorrect VAT.

**Solution:**
Romania can accept the CUI as tax identifier.
The CUI only contains digits.
When formatting the VAT from Romania, the country code will not be prepended automatically.
To reduce the effect of the fix, the code prepend will only be skipped if the country of the customer is the same than the country of the website.

opw-4655064




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

Forward-Port-Of: odoo/odoo#211693

Consider this situation: - Customer invoice. - All invoice lines use a tax type with l10n_es_type=no_sujeto_loc. - The sum of the invoice is 0€. - Sent to SII. Before this patch, the process would raise a wrong `UserError`. If the process was being executed by the cron, **no invoice would be sent**, even if there was only one failing. After this patch, the invoice will be notified nevertheless. If there's any kind of real validation problem, the SII servers will return an error that wi

Consider this situation:
- Customer invoice.
- All invoice lines use a tax type with l10n_es_type=no_sujeto_loc.
- The sum of the invoice is 0€.
- Sent to SII.

Before this patch, the process would raise a wrong `UserError`. If the process was being executed by the cron, **no invoice would be sent**, even if there was only one failing.

After this patch, the invoice will be notified nevertheless. If there's any kind of real validation problem, the SII servers will return an error that will get logged in the invoice. No exceptions raised in Odoo. The process can continue. Faulty invoices are marked; others work.

Apart from that, there's also the fix to support the specific case outlined above.

@moduon MT-7949 OPW-4344661



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

Forward-Port-Of: odoo/odoo#189667
Forward-Port-Of: odoo/odoo#189529

Description of the issue/feature this PR addresses: When fetching videos from vimeo, if the video is deleted, an error is shown to the user which also block test `test_snippet_background_video`. Current behavior before PR: 1. Install website 2. Start `website_snippet_background_video` tour 3. You'll get an error if a video is missing Desired behavior after PR is merged: Now, with the error handling, a warning will be simply outputed for the missing video instead of a blocking mess

Description of the issue/feature this PR addresses:
When fetching videos from vimeo, if the video is
deleted, an error is shown to the user which also
block test `test_snippet_background_video`.

Current behavior before PR:
1. Install website
2. Start `website_snippet_background_video` tour
3. You'll get an error if a video is missing

Desired behavior after PR is merged:
Now, with the error handling, a warning will be
simply outputed for the missing video instead
of a blocking message



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

Forward-Port-Of: odoo/odoo#213297
Forward-Port-Of: odoo/odoo#210307

Versions -------- - 17.0+ Steps ----- 1. Create a Stripe transaction; 2. check server logs. Issue ----- The `client_secret` value gets logged, Stripe documentation says this value should not be stored or logged[^1]. [^1]: https://docs.stripe.com/api/payment_intents/object#payment_intent_object-client_secret Cause ----- Currently we're just raw-logging the processing values. Solution -------- Add a `_get_specific_secret_keys` method to `payment.transaction`, to be used w

Versions
--------
- 17.0+

Steps
-----
1. Create a Stripe transaction;
2. check server logs.

Issue
-----
The `client_secret` value gets logged, Stripe documentation says this value should not be stored or logged[^1].

[^1]: https://docs.stripe.com/api/payment_intents/object#payment_intent_object-client_secret

Cause
-----
Currently we're just raw-logging the processing values.

Solution
--------
Add a `_get_specific_secret_keys` method to `payment.transaction`, to be used when logging processing values that may contain secret information.

Also mute the logger when redirecting to `/payment/status` from Stripe, as the `client_secret` would otherwise be logged by `werkzeug`.

opw-4818301

Forward-Port-Of: odoo/odoo#211979

This new module adds necessary features to support JoFotara properly with the following features: 1. Support for different invoice types and payment methods 2. Demo mode These features were added in a new module in stable, but will be merged with the main module in master. The commit also adds support for reporting invoices in their currency. task-4534862 task-4656902 Forward-Port-Of: odoo/odoo#205890

This new module adds necessary features to support JoFotara properly with the following features:
1. Support for different invoice types and payment methods
2. Demo mode
These features were added in a new module in stable, but will be merged with the main module in master.
The commit also adds support for reporting invoices in their currency.

task-4534862
task-4656902

Forward-Port-Of: odoo/odoo#205890

- Before this commit: The tax with ID `attn_VAT-OUT-00-S`, which represents a `0% Service Tax`, had an incorrect description `6% VAT (Services)` instead of `0% VAT (Service)`. - After this commit: The typo has been corrected by updating the description to accurately reflect the tax rate as `0% VAT (Service)`. Task-4855172 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213752

- Before this commit: The tax with ID `attn_VAT-OUT-00-S`, which represents a `0% Service Tax`, had an incorrect description `6% VAT (Services)` instead of `0% VAT (Service)`.

- After this commit: The typo has been corrected by updating the description to accurately reflect the tax rate as `0% VAT (Service)`.

Task-4855172




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

Forward-Port-Of: odoo/odoo#213752

…Inter-Company sync ### Steps to reproduce: - With Company B in the settings Enable Inter-Company Transactions > Synchronize Sales and Purchase Order - Sales > Configurations > Sales Teams, Archive all sales team - With COMP A create a sales team with a set company_id: COMP A - With COMP A create and confirm a PO with COMP B as customer #### > Invalid operation: while generating the SO, the sales team belongs to COMP A and the SO to COMP B. ### Cause of the issue: The `team_i

…Inter-Company sync

### Steps to reproduce:

- With Company B in the settings Enable Inter-Company Transactions
   > Synchronize Sales and Purchase Order
- Sales > Configurations > Sales Teams, Archive all sales team
- With COMP A create a sales team with a set company_id: COMP A
- With COMP A create and confirm a PO with COMP B as customer
#### > Invalid operation: while generating the SO, the sales team belongs to COMP A and the SO to COMP B.

### Cause of the issue:

The `team_id` field of the `sale.order` model is a stored pre-computed and company checked field. As such, when the SO is created and even if no sales team is provided to the create vals:
https://github.com/odoo/enterprise/blob/c61ce5a8e46e706bfb2025d4c9c79a39598e8827/sale_purchase_inter_company_rules/models/purchase_order.py#L70 a default sales team will be computed and set on the SO based on the "allowed_company_ids" (including both COMP A and COMP B): https://github.com/odoo/odoo/blob/1fa8678a33ab35195005d1b65b5eecb1d089fe56/addons/sale/models/sale_order.py#L453-L460 https://github.com/odoo/odoo/blob/1fa8678a33ab35195005d1b65b5eecb1d089fe56/addons/sales_team/models/crm_team.py#L81-L88
While the domain checks that the sales team is either not tight to a company or belong to comp B, since no such teams were found, we fallback the invalid sales team of COMP A. The invalid operation is then raised during the `_check_company` of the created record.

opw-4627851

Forward-Port-Of: odoo/enterprise#86102
Forward-Port-Of: odoo/enterprise#83487

**Issue** In version 18.0, the Customer Statement smart button only appears if the customer has an invoice, unlike in 17.0 where it also appeared if the customer simply had a balance in their ledger **Steps to Reproduce** 1. Install the Accounting module 2. Go to Accounting > Accounting > Journal Entries 3. Create a new Journal Entry 4. Set one line to account 121000 (Accounts Receivable), assign partner "Administrator", and debit $100 5. Set the other line to account 101401 (Bank), and

**Issue**
In version 18.0, the Customer Statement smart button only appears if the customer has an invoice, unlike in 17.0 where it also appeared if the customer simply had a balance in their ledger

**Steps to Reproduce**
1. Install the Accounting module
2. Go to Accounting > Accounting > Journal Entries
3. Create a new Journal Entry
4. Set one line to account 121000 (Accounts Receivable), assign partner "Administrator", and debit $100
5. Set the other line to account 101401 (Bank), and credit $100
6. Post the journal entry
7. Navigate to Accounting > Customers > Customers
8. Open the "Administrator" customer record
9. Notice that the Customer Statement smart button is not displayed

**Root Cause**
The visibility of the smart button is incorrectly tied to the presence of posted invoices (account.move), instead of the existence of any outstanding balance on the customer account

**Fix**
Adjust the visibility logic to show the Customer Statement button if the customer has any ledger balance, even without invoices. This restores the behavior present in 17.0

Opw-4787174

Forward-Port-Of: odoo/enterprise#86446

Sorting by something else than write date desc makes it very difficult to retrieve new documents, especially if never accessed before. Task-4737096 Forward-Port-Of: odoo/enterprise#83681

Sorting by something else than write date desc makes it very difficult to retrieve new documents, especially if never accessed before.

Task-4737096

Forward-Port-Of: odoo/enterprise#83681

Context: The Belgian localisation has two Intrastat report handlers: - Goods: `l10n_be_intrastat.models.account_intrastat_report` - Services: `l10n_be_intrastat_services.models.account_intrastat_services_report` `account_intrastat_report.be_intrastat_export_to_xml()` is the single export entry-point for both. It always calls an internal helper named `_be_intrastat_get_xml_file_content(options, results, company)` and then serialises the returned string. Why it failed: 1. Signature dri

Context:
The Belgian localisation has two Intrastat report handlers:

- Goods: `l10n_be_intrastat.models.account_intrastat_report`
- Services: `l10n_be_intrastat_services.models.account_intrastat_services_report`

`account_intrastat_report.be_intrastat_export_to_xml()` is the single export entry-point for both. It always calls an internal helper named `_be_intrastat_get_xml_file_content(options, results, company)` and then serialises the returned string.

Why it failed:
1. Signature drift The services override expected a fourth positional argument (`date`), so the shared entry-point raised a `TypeError`.

2. Wrong template prefix The helper tried to render `l10n_be_intrastat.intrastat_services_report_export_xml`, but the template is stored under `l10n_be_intrastat_services`, leading to a `ValueError`.

This commit drop the unused `date` parameter and compute the period from options the same way we do in the other function.

opw-4834279

Forward-Port-Of: odoo/enterprise#86759

Following page 35 of the documentation here https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps2024-2.1.1-en.pdf In Switzerland, SEPA and ISO20022 are considered as subsets of the Swiss standard, and it is hence possible to include within the Swiss file nodes that are generated following these formats. We didn't support that before this commit. To allow that, we also remove the ability to force the value of the ChrgBr node when using SEPA ; ot

Following page 35 of the documentation here https://www.six-group.com/dam/download/banking-services/standardization/sps/ig-credit-transfer-sps2024-2.1.1-en.pdf

In Switzerland, SEPA and ISO20022 are considered as subsets of the Swiss standard, and it is hence possible to include within the Swiss file nodes that are generated following these formats. We didn't support that before this commit.

To allow that, we also remove the ability to force the value of the ChrgBr node when using SEPA ; other values as SLEV are not supported by that format anyway.

opw-4535542

Forward-Port-Of: odoo/enterprise#86996

The certification reports for Colombian withholdings (Fuente, ReteIVA, ReteICA) incorrectly referenced the current year (i.e., the year when the report is generated) as the "año gravable" in the certificate body: "Durante el año gravable de 2025..." This caused a mismatch when generating certificates for the previous fiscal period (e.g., 2024), especially when the user filtered movements from a prior year. This change ensures that the "año gravable" corresponds to the selected period ye

The certification reports for Colombian withholdings (Fuente, ReteIVA, ReteICA) incorrectly referenced the current year (i.e., the year when the report is generated) as the "año gravable" in the certificate body:

"Durante el año gravable de 2025..."

This caused a mismatch when generating certificates for the previous fiscal period (e.g., 2024), especially when the user filtered movements from a prior year.

This change ensures that the "año gravable" corresponds to the selected period year, taken from the date_from filter in the report wizard, which reflects the actual accounting or fiscal period being certified.

Justification
According to Colombian tax practices and DIAN guidelines, the "año gravable" mentioned in retention certificates must match the period in which the income or payment was made and the tax was withheld. Using the current date instead of the actual reporting period could lead to confusion or even legal inconsistencies during audits.

Reference:

Estatuto Tributario Art. 378: Certificates must include the fiscal year in which the withholding was applied.

Common practice requires companies to issue certificates reflecting the year of the transactions, not the year of report generation.

Forward-Port-Of: odoo/enterprise#86838

Before this commit a traceback was occurring when opening an app using palette and then immediately passing a value in palette search input. After this commit the traceback will not occur anymore. task-4735048 Forward-Port-Of: odoo/enterprise#86066

Before this commit a traceback was occurring when
opening an app using palette and then immediately
passing a value in palette search input.

After this commit the traceback will not occur anymore.

task-4735048

Forward-Port-Of: odoo/enterprise#86066

**Steps to Reproduce :** 1. Install l10n_cl_edi. 2. Navigate to Contacts create an invoice for CL Company 3. Choose the document type: (33) Electronic Invoice. 4. Confirm the invoice. 5. Ensure the partner has only the street value set (e.g., "Name"), and street2 is empty. **Issue:** When generating the DTE, if street2 is empty, a trailing space appears in the <DirOrigen> tag ex: `DirOrigen>Name </DirOrigen>` **Solution:** Applied strip() to remove the extra space when stre

**Steps to Reproduce :** 

1. Install l10n_cl_edi.
2. Navigate to Contacts create an invoice for CL Company
3. Choose the document type: (33) Electronic Invoice.
4. Confirm the invoice.
5. Ensure the partner has only the street value set (e.g., "Name"), and street2 is empty.

**Issue:**

When generating the DTE, if street2 is empty, a trailing space appears in the <DirOrigen> tag
ex:  `DirOrigen>Name </DirOrigen>`

**Solution:**

Applied strip() to remove the extra space when street2 is empty. 
This ensures no trailing space when street2 is empty and proper 
spacing when both street and street2 is present.

opw-4765451

Forward-Port-Of: odoo/enterprise#85110

Previously, the link used by the “test_winbooks_import” test to download sample data (PARFILUX) from Winbooks was unavailable. This commit changes the url to use directly Winbooks server instead of Amazon, which will allow the test to run without any problem. Forward-Port-Of: odoo/enterprise#87090

Previously, the link used by the “test_winbooks_import” test to download sample data (PARFILUX) from Winbooks was unavailable.

This commit changes the url to use directly Winbooks server instead of Amazon, which will allow the test to run without any problem.

Forward-Port-Of: odoo/enterprise#87090

### Steps to reproduce: - Have an overdue invoice - Go to Accounting > Customers > Follow-up Reports and click the partner - Change the state of the report to something different than the first state - Click "Follow-up", select "By post" and send - Settings > technical > Email > Snailmail Letters find the letter corresponding to the report - Check the PDF, it is using the mail template of the first followup level ### Cause: When sending a followup report, the followup level of the repo

### Steps to reproduce:
- Have an overdue invoice
- Go to Accounting > Customers > Follow-up Reports and click the partner
- Change the state of the report to something different than the first state
- Click "Follow-up", select "By post" and send
- Settings > technical > Email > Snailmail Letters find the letter corresponding to the report
- Check the PDF, it is using the mail template of the first followup level

### Cause:
When sending a followup report, the followup level of the report is recomputed for it to have the correct value.
Then the report is generated.
But the option to send a letter uses methods from the module `snailmail` for example `` which don't have options. The options are then recomputed to generate the report, reading [`partner.followup_line_id`](https://github.com/odoo/enterprise/blob/c8dac822cf3df23922488f33c07a114bbea05198/account_followup/models/account_followup_report.py#L42) so getting the wrong value.

### Solution:
Add a context key to pass the value of `followup_line` to the report generation after snailmail.

opw-4766804

Forward-Port-Of: odoo/enterprise#86706
Forward-Port-Of: odoo/enterprise#85717

Added compatibility with Estonia tax report version KMD6 that is valid from 1. July 2025. For technical info please see: https://www.emta.ee/en/business-client/e-services-training-courses/how-use-e-services/technical-information-services#value-added-tax-return Forward-Port-Of: odoo/enterprise#84306

Added compatibility with Estonia tax report version KMD6 that is valid from 1. July 2025. 

For technical info please see:
https://www.emta.ee/en/business-client/e-services-training-courses/how-use-e-services/technical-information-services#value-added-tax-return

Forward-Port-Of: odoo/enterprise#84306

When the post_invoice_hook failed, and sale_subscription_stock was installed, all subscription invoiced would have a "Delivery creation failed" activity created, even if no delivery needed to be created. This commit filter out the subscriptions without any stock lines that needs the stock rule to be run. OPW-4618930 Forward-Port-Of: odoo/enterprise#86190 Forward-Port-Of: odoo/enterprise#85604

When the post_invoice_hook failed, and sale_subscription_stock was installed, all subscription invoiced would have a "Delivery creation failed" activity created, even if no delivery needed to be created.

This commit filter out the subscriptions without any stock lines that needs the stock rule to be run.

OPW-4618930

Forward-Port-Of: odoo/enterprise#86190
Forward-Port-Of: odoo/enterprise#85604

Before this commit: === - The delivery status buttons (New, Ongoing, Done) and the toggle Switches were misaligned on smaller screens due to the use of grid layout, After this commit: === - The layout uses a flex-based structure, which ensures better alignment and spacing across screen sizes. Task: 4844890 Forward-Port-Of: odoo/enterprise#86904

Before this commit:
===
- The delivery status buttons (New, Ongoing, Done) and the toggle Switches were misaligned on smaller screens due to the use of grid layout,

After this commit:
===
- The layout uses a flex-based structure, which ensures better alignment and spacing across screen sizes.

Task: 4844890

Forward-Port-Of: odoo/enterprise#86904

In Gstr-3B section 3.1(a) credit note/debit note should be calculated. This PR adds credit note/debit note into section 3.1(a). **Older Version PR:** https://github.com/odoo/enterprise/pull/87160 **opw**-https://www.odoo.com/odoo/project/49/tasks/4845457 **Task**-4852947 Forward-Port-Of: odoo/enterprise#87171

In Gstr-3B section 3.1(a) credit note/debit note should be calculated.
This PR adds credit note/debit note into section 3.1(a).
**Older Version PR:** https://github.com/odoo/enterprise/pull/87160

**opw**-https://www.odoo.com/odoo/project/49/tasks/4845457
**Task**-4852947

Forward-Port-Of: odoo/enterprise#87171

Fixed the computation of `is_vat_duplicated` to avoid false positive in case of partners having both invoices and refunds in the selected period. Forward-Port-Of: odoo/enterprise#87247

Fixed the computation of `is_vat_duplicated` to avoid false positive in case of partners having both invoices and refunds in the selected period.

Forward-Port-Of: odoo/enterprise#87247

In test_generate_all_export_files, PDF and XLSX reports were not generated due to them timing-out the runbot, which was happening randomly. This has been fixed here by only testing the generation of the data then given to wkhtmltopdf, since wkhtmltopdf is quite slow and can randomly create errors. This is taking about 4 minutes with this fix when all reporting modules are enabled in v17.0 but taking around 20 minutes when creating PDFs. task-3603619 Forward-Port-Of: odoo/enterprise#872

In test_generate_all_export_files, PDF and XLSX reports were not generated due to them timing-out the runbot, which was happening randomly.

This has been fixed here by only testing the generation of the data then given to wkhtmltopdf, since wkhtmltopdf is quite slow and can randomly create errors.

This is taking about 4 minutes with this fix when all reporting modules are enabled in v17.0 but taking around 20 minutes when creating PDFs.

task-3603619

Forward-Port-Of: odoo/enterprise#87232
Forward-Port-Of: odoo/enterprise#86307