Current behaviour: --- When displaying a malaysian address on an invoice, the state code is shown. Street 12 Cityname KTN 12345 Malaysia In 17.0 and after, KTN is replaced by MY-03 (and other state codes) per ISO standards KUL -> MY-14, PHG -> MY-06, etc. https://github.com/odoo/odoo/commit/a8204fcf6f919cfa85411f96c11c247e1d0a6f35 Expected behaviour: --- The state name should be displayed instead. Street 12 Cityname Kelantan 12345 Malaysia Steps to reproduce: --- 1. G

Current behaviour:
---
When displaying a malaysian address on an invoice, the state code is shown.

Street 12
Cityname KTN 12345
Malaysia

In 17.0 and after, KTN is replaced by MY-03
(and other state codes) per ISO standards
KUL -> MY-14, PHG -> MY-06, etc.
https://github.com/odoo/odoo/commit/a8204fcf6f919cfa85411f96c11c247e1d0a6f35

Expected behaviour:
---
The state name should be displayed instead.

Street 12
Cityname Kelantan 12345
Malaysia

Steps to reproduce:
---
1. Go to Contacts
2. Create a new contact
3. Set country as Malaysia, and choose a state
4. Go to Invoice, create one
5. Select new malaysian contact
6. State code in address instead of name

Fix:
---
Added a custom address_format in res_country_data.xml

opw-4762300

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

Forward-Port-Of: odoo/odoo#212316

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

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

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

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

Because the `location.assign` method also triggers a `beforeunload` event, the `error_service` doesn't handle errors when downloading a file with the action target `download` (for example download vCard). See [1] for more details about the original fix. task-4457865 [1]: https://github.com/odoo/odoo/commit/e96d3aa6d9181d83e34cefd9fe205f37df2e317c --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#213103 Forward-Port-Of:

Because the `location.assign` method also triggers a `beforeunload`
event, the `error_service` doesn't handle errors when downloading a file
with the action target `download` (for example download vCard). See [1]
for more details about the original fix.

task-4457865

[1]: https://github.com/odoo/odoo/commit/e96d3aa6d9181d83e34cefd9fe205f37df2e317c
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#213103
Forward-Port-Of: odoo/odoo#212432

### Description of the issue/feature this PR addresses: Prevent sending unnecessary invitation or update emails for events that have already ended by introducing a method to check if an event is over. ### Current behavior before PR: Event updates/ new syncs with google_calendar might trigger email notifications, even for past events, causing useless invitations/ updated invitations to users. ### Desired behavior after PR is merged: Email notifications are only sent for active or future

### Description of the issue/feature this PR addresses:
Prevent sending unnecessary invitation or update emails for events that have already ended by introducing a method to check if an event is over.

### Current behavior before PR:
Event updates/ new syncs with google_calendar might trigger email notifications, even for past events, causing useless invitations/ updated invitations to users.

### Desired behavior after PR is merged:
Email notifications are only sent for active or future events. Creation-from-sync / Updates to past events that have already ended are no longer triggering emails.

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

Forward-Port-Of: odoo/odoo#213227
Forward-Port-Of: odoo/odoo#208302

- 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

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

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

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

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

In form and list views, the callback given to the CogMenu to reload the view when the clicked cog menu action was done, didn't check the `noReload` flag. Typically, this flag is set to true when we're leaving to another action. However, since [1], and especially [2], this caused an issue as the reloaded view was destroyed while it was being reloaded, so the reload promise was never resolved. As a consequence, we didn't reach the code that actually closes the dialog [3], as `await onClose?.(cl

In form and list views, the callback given to the CogMenu to reload the view when the clicked cog menu action was done, didn't check the `noReload` flag. Typically, this flag is set to true when we're leaving to another action.

However, since [1], and especially [2], this caused an issue as the reloaded view was destroyed while it was being reloaded, so the reload promise was never resolved. As a consequence, we didn't reach the code that actually closes the dialog [3], as `await onClose?.(closeParams)` never resolved.

The faulty behavior could be observed in Employee, open Audrey Peterson, click on the Delete cog menu action, and in the dialog, click on See Timesheets. That dialog was then never closed, and trying to close it manually triggered the "Component is destroyed" error, as it always tried to execute the reload callback.

[1] https://github.com/odoo/odoo/pull/202512
[2] https://github.com/odoo/odoo/pull/202512/commits/d606be75c44fccf0b1ddf5216892f1d4b7162686
[3] https://github.com/odoo/odoo/pull/202512/commits/d606be75c44fccf0b1ddf5216892f1d4b7162686#diff-552aefb62246b1f4fe6a2607ec8f0a01773e53de2d68293266b38bc99c5cb56dR318

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

The commits in this PR address two points: 1. An account move created from a Purchase Order or Sales Order with an Analytic Distribution only has the analytical distribution from the PO/SO. The invoice/vendor bill does not add the Analytic Accounts expected from matching Analytic Distribution Models. 2. When confirming a SO with a product that creates a project, the Analytic Distribution of the line is filled with the Analytic Account of the project. But this does not happen if there is alre

The commits in this PR address two points:

1. An account move created from a Purchase Order or Sales Order with an Analytic Distribution only has the analytical distribution from the PO/SO. The invoice/vendor bill does not add the Analytic Accounts expected from matching Analytic Distribution Models.
2. When confirming a SO with a product that creates a project, the Analytic Distribution of the line is filled with the Analytic Account of the project. But this does not happen if there is already another AA in the line before confirming the SO. Another AA may be there because it was added manually or because of an existing distribution model set on the partner or the product.

More information on each can be found in the commit messages.

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

Forward-Port-Of: odoo/odoo#213065
Forward-Port-Of: odoo/odoo#199763

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

Before this commit, LED status was managed from within Odoo. This could lead to issues: for example, when we stopped Odoo on the iot box, the leds stay in constant green (last used) colour despite odoo not running. We now use a systemd service, separated from the Odoo service, that continues running even if Odoo stops. Task: 4813935 Forward-Port-Of: odoo/odoo#212133

Before this commit, LED status was managed from within Odoo. This could lead to issues: for example, when we stopped Odoo on the iot box, the leds stay in constant green (last used) colour despite odoo not running.

We now use a systemd service, separated from the Odoo service, that continues running even if Odoo stops.

Task: 4813935

Forward-Port-Of: odoo/odoo#212133

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

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

### Steps to reproduce: - Create a storable product P with 10 units in stock. - Inventory > Configuration > Warehouse Management > Operation Types - Change the reservation Method of Delivery orders to Manual - Create confirm and manually assign a delivery order for 3 units of P - Process the DO in the barcode app, scan 1 unit of P > The line should be 1/3 - Leave and come back #### > The line is now at 1/1 Cause of the issue: Leaving the barcode app launch a call of the `split_un

### Steps to reproduce:

- Create a storable product P with 10 units in stock.
- Inventory > Configuration > Warehouse Management > Operation Types
- Change the reservation Method of Delivery orders to Manual
- Create confirm and manually assign a delivery order for 3 units of P
- Process the DO in the barcode app, scan 1 unit of P
> The line should be 1/3
- Leave and come back
#### > The line is now at 1/1

Cause of the issue:

Leaving the barcode app launch a call of the `split_uncompleted_moves` in order to keep track of the initial reservation in the barcode app: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L9-L11 
However, one of the issue of the current system is that these new moves are expected to be assigned by the `_action_confirm`: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L37
But they are not in certain cases and we should therefore force re-assignation in that case:
https://github.com/odoo/odoo/blob/bf0461552effe806fdaa8f85f088be3c3f3be09d/addons/stock/models/stock_move.py#L1427-L1432

Enterprise: https://github.com/odoo/enterprise/pull/86394

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

Forward-Port-Of: odoo/odoo#213041
Forward-Port-Of: odoo/odoo#211616

- Ensure that multiple (rapid) clicks on the order button no longer print duplicate preparation tickets. - Await for the order to be printed, as it's done in `saas-18.2` since the following PR (https://github.com/odoo/odoo/pull/204444). Steps to reproduce: - Connect a preparation printer to the restaurant - Make an order - Spam the order btn to send the order to the kitchen - => Multiple preparation ticket for the same order are printed task-id: 4752376 --- I confirm I have si

- Ensure that multiple (rapid) clicks on the order button no longer print duplicate preparation tickets.
- Await for the order to be printed, as it's done in `saas-18.2` since the following PR (https://github.com/odoo/odoo/pull/204444).

Steps to reproduce:
- Connect a preparation printer to the restaurant
- Make an order
- Spam the order btn to send the order to the kitchen
- => Multiple preparation ticket for the same order are printed

task-id: 4752376



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

Forward-Port-Of: odoo/odoo#210526

The shot value chartJs plugin would show the same value for a waterfall chart than a bar chart (the value of the top of the bar), instead of the correct value for a waterfall chart (the difference between the top and the bottom of the bar). Also the odoo_pyramid_chart would show negative values for the values of the left of the pyramid, instead of the absolute value. Task: 4812692 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port

The shot value chartJs plugin would show the same value for a waterfall
chart than a bar chart (the value of the top of the bar), instead of the
correct value for a waterfall chart (the difference between the top and
the bottom of the bar).

Also the odoo_pyramid_chart would show negative values for the values
of the left of the pyramid, instead of the absolute value.

Task: 4812692

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

Forward-Port-Of: odoo/odoo#213299

Currently, when archiving products, they will still appear in the pos session. Steps to reproduce: ------------------- * Open a shop and close it (to store products in cache) * Archive any product from the previous shop * Open the shop again > Observation: The product is still visible in the product screen. Why the fix: ------------ Compared to previous versions, we are now caching products for performance issue. Currently, when opening a shop, all products that we modified after th

Currently, when archiving products, they will still appear in the pos session.

Steps to reproduce:
-------------------
* Open a shop and close it (to store products in cache)
* Archive any product from the previous shop
* Open the shop again
> Observation: The product is still visible in the product screen.

Why the fix:
------------
Compared to previous versions, we are now caching products for performance issue. Currently, when opening a shop, all products that we modified after the last modification date of the config parameters are loaded to the pos.

This is done to reflect any change like the product price, and more. However, only active product were loaded. This meant that every product that was archived were not loaded and the information was not sent to the backend.

opw-4657471

Forward-Port-Of: odoo/odoo#205108

- 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

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

### Steps to reproduce: - Create a storable product P with 10 units in stock. - Inventory > Configuration > Warehouse Management > Operation Types - Change the reservation Method of Delivery orders to Manual - Create confirm and manually assign a delivery order for 3 units of P - Process the DO in the barcode app, scan 1 unit of P > The line should be 1/3 - Leave and come back #### > The line is now at 1/1 ### Cause of the issue: Leaving the barcode app launch a call of the `spli

### Steps to reproduce:

- Create a storable product P with 10 units in stock.
- Inventory > Configuration > Warehouse Management > Operation Types
- Change the reservation Method of Delivery orders to Manual
- Create confirm and manually assign a delivery order for 3 units of P
- Process the DO in the barcode app, scan 1 unit of P
> The line should be 1/3
- Leave and come back
#### > The line is now at 1/1

### Cause of the issue:

Leaving the barcode app launch a call of the `split_uncompleted_moves` in order to keep track of the initial reservation in the barcode app: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L9-L11 However, one of the issue of the current system is that these new moves are expected to be assigned by the `_action_confirm`: https://github.com/odoo/enterprise/blob/577cb4b74a614d2dd472375b325706525ae591d7/stock_barcode/models/stock_move.py#L37 But they are not in certain cases and we should therefore force re-assignation in that case:
https://github.com/odoo/odoo/blob/bf0461552effe806fdaa8f85f088be3c3f3be09d/addons/stock/models/stock_move.py#L1427-L1432

Community: https://github.com/odoo/odoo/pull/211616

opw-4798349

Forward-Port-Of: odoo/enterprise#87041
Forward-Port-Of: odoo/enterprise#86394

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

**Problem:** When internal transfer operation type has a manadatory destination in barcode, the transfer can still be validated without destination location scanned if it's a package **Steps to reproduce:** - In settings, enable the "packages" settings - Navigate to Inventory/Configuration/Warehouse Management/ Operations Types - Select "Internal Transfers", in the "Barcode App" page for Source Location, select Mandatory Scan - for "Destination Location" select "after each product"

**Problem:**
When internal transfer operation type has a manadatory destination
in barcode, the transfer can still be validated without destination
location scanned if it's a package

**Steps to reproduce:**
- In settings, enable the "packages" settings
- Navigate to Inventory/Configuration/Warehouse Management/
Operations Types
- Select "Internal Transfers", in the "Barcode App" page for Source
Location, select Mandatory Scan
- for "Destination Location" select "after each product"
- create a new storable product
- Navigate to Inventory/Operations/Physical Inventory
- Create a new line and select stock as the location
- Select your product
- In the package column, create a package and give it a name
- Set a quantity > Apply
- Open the barcode app, select operations and then internal
transfers
- Click on New and then Scan WH-Stock and the package name: PACK

**Current behavior:**
 The validate button is higlighted in green and clickable

**Expected behavior:**
Because we didn't scan a destination location it shouldn't be 
green and clickabel

**Cause of the issue:**

When a package barcode is scanned, when _processBarcode calls
_processPackage 
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1007
Inside _processPackage 
barcodeData.stopped is set to true (1)
and this.selectedLineVirtualId is set to false (2) 
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_picking_model.js#L1532-L1533
Because of (1) _processBarcode returns here 
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1008-L1011
and doesn't reach the part of the method where _selectLine is called  
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1181-L1182
(Inside _selectLine the value of selectedLineVirtualId is defined
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L1269-L1274
)

So as a consequence of (1) and (2) the value of this.selectedLineVirtualID is 
false when a package is scanned

When the validate method is called when the user clicks on validate,
the method uses the value of this.selectedLine
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_picking_model.js#L777-L779
Because this.selectedLineVirtualID is false, get selectedLine returns false
https://github.com/odoo/enterprise/blob/a60aea84d68587b1dfe1b6bfd20cb4fced0f7d46/stock_barcode/static/src/models/barcode_model.js#L307-L309
So the if condition is false, the method is allowed to run and 
the error notification is not triggered


**Fix:**
After scanning a package there is no selectedLine so we need another
condition


opw-4590345

Forward-Port-Of: odoo/enterprise#87008
Forward-Port-Of: odoo/enterprise#83710

remove the unnecessary selector that was causing the tour test to fail 00:1 was not found in the view nor the DOM  build_error-163619 Forward-Port-Of: odoo/enterprise#87105

remove the unnecessary selector that was causing the tour test to fail 00:1 was not found in the view nor the DOM

![image](https://github.com/user-attachments/assets/3364ce94-c385-4172-b509-345ffc0da53e)

build_error-163619

Forward-Port-Of: odoo/enterprise#87105

Description ----------- When copying a document, a new attachment is created and linked to the copied document. Since `documents.document.is_multipage` depends on `documents.document.datas`, which is related to `attachment_id.datas`, and `attachment_id` was just written to, `_compute_is_multipage` will be recomputed during flushing before commit, as it's a compute stored field. This is problematic when copying multiple large documents, since this compute reads the entire binary data to dete

Description
-----------
When copying a document, a new attachment is created and linked to the copied document. Since `documents.document.is_multipage` depends on `documents.document.datas`, which is related to `attachment_id.datas`, and `attachment_id` was just written to, `_compute_is_multipage` will be recomputed during flushing before commit, as it's a compute stored field.

This is problematic when copying multiple large documents, since this compute reads the entire binary data to determine if it's more than one page.

This commits explictly writes on `is_multipage` to implicitly add it to the protected fields, which will prevent its' recomputation when flushing.

Benchmark
---------
Copying 5 documents (PDF) of 50MB each takes in total:

| Before | After  | Diff   |
|--------|--------|--------|
| 1.61GB | 1.17GB | -27.3% |

Reference
---------
opw-4829372

Forward-Port-Of: odoo/enterprise#87235
Forward-Port-Of: odoo/enterprise#86885

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

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