Before this commit, the credit note's tax lines were causing an issue during reconciliation because they were reconciled with both the invoice and with the cash basis entry. Reproduce: * Enable cash basis accounting. * On the tax that will be used, set: Tax Exigibility: Based on Payment. * Allow reconciliation on the associated account. * Add a product without tax and save. * Then, add a tax. * Try to create and post a credit note for this invoice Forward-Port-Of: odoo/odoo#192586

Before this commit, the credit note's tax lines were causing an issue during reconciliation because they were reconciled with both the invoice and with the cash basis entry.

Reproduce:
* Enable cash basis accounting.
* On the tax that will be used, set: Tax Exigibility: Based on Payment.
* Allow reconciliation on the associated account.
* Add a product without tax and save.
* Then, add a tax.
* Try to create and post a credit note for this invoice

Forward-Port-Of: odoo/odoo#192586

Before this commit, the payment smart button included payments for cancelled orders, even though those payments were not captured. This caused discrepancies as it inaccurately reflected payments for orders that were not finalized. opw-4487386 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#194191

Before this commit, the payment smart button included payments for cancelled orders, even though those payments were not captured. This caused discrepancies as it inaccurately reflected payments for orders that were not finalized.

opw-4487386

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

Forward-Port-Of: odoo/odoo#194191

Currently, when closing the session, you would encounter an issue if the a refund payment was done using bank payment method and on the journal, the SEPA Credit Transfer is positionned first in the sequence. Steps to reproduce: ------------------- * Install `l10n_fr`, `point_of_sale`, and `account_sepa` * Switch to the `FR Company` * In the **Invoicing** app, select **Configuration** > **Journals** * Select the `Bank` journal * Set proper IBAN account * In **Outgoing Payments**, move `

Currently, when closing the session, you would encounter an issue if the a refund payment was done using bank payment method and on the journal, the SEPA Credit Transfer is positionned first in the sequence.

Steps to reproduce:
-------------------
* Install `l10n_fr`, `point_of_sale`, and `account_sepa`
* Switch to the `FR Company`
* In the **Invoicing** app, select **Configuration** > **Journals**
* Select the `Bank` journal
* Set proper IBAN account
* In **Outgoing Payments**, move `SEPA Credit Transfer` to the top
* In **Point of sale**, open pos shop
* Select any product, change the price or qty to be negative (or make a refund for an order with no customer)
* Select `Bank` payment method
* Validate
* Try closing session
> Observation: Closing session error: An error has occurred when trying to
close the sesion. You will be redirected to the back-end to manually close the session.
* In the backend, try to close the session
> Observation: To record payments with False, the recipient bank account
must be manually validated. You should go on the partner bank account in order to validate it.

Why the fix:
------------
The first payment_method_line will be used among the available payment method lines:
https://github.com/odoo/odoo/blob/ae4c01ea7c9a5709a5f5ebcaded06fd91bdabae3/addons/account/models/account_payment.py#L461-L465 https://github.com/odoo/odoo/blob/ae4c01ea7c9a5709a5f5ebcaded06fd91bdabae3/addons/account/models/account_payment.py#L470-L475

In the context of the point of sale, using SEPA CT in the context of refunds does not make too much sense. Indeed, in the pos a refund can be done on an order which is not related to a client. By definition, when using SEPA your are supposed to know the client and it bank account number.

We exclude the possibility of using SEPA CT when creating refund account payments coming from the Pos.

opw-4310781

Forward-Port-Of: odoo/odoo#196292
Forward-Port-Of: odoo/odoo#195784

This commit make brazilen fields always display in address form even though b2b fields settings disabled from edition because in LATAM country `ID Type` and `ID Number` field are required for billing. Also revert wrong fixed PR https://github.com/odoo/odoo/pull/194110 task-3628329 Forward-Port-Of: odoo/odoo#196741 Forward-Port-Of: odoo/odoo#196182

This commit make brazilen fields always display in address
form even though b2b fields settings disabled from edition
because in LATAM country `ID Type` and `ID Number` field
are required for billing.

Also revert wrong fixed PR https://github.com/odoo/odoo/pull/194110

task-3628329

Forward-Port-Of: odoo/odoo#196741
Forward-Port-Of: odoo/odoo#196182

This commit : - adds missing VAT 0% export (goods) tax - correct erroneous fiscal position - reactivate taxes that were deactivated with https://github.com/odoo/odoo/commit/401a961258e991151370899d4b61809879d5a5a8 after reconsideration Task: 4453629 Forward-Port-Of: odoo/odoo#196738

This commit :
- adds missing VAT 0% export (goods) tax
- correct erroneous fiscal position
- reactivate taxes that were deactivated with https://github.com/odoo/odoo/commit/401a961258e991151370899d4b61809879d5a5a8 after reconsideration

Task: 4453629

Forward-Port-Of: odoo/odoo#196738

Description of the issue/feature this PR addresses: This PR aims to allow the user to create a CN in a different journal than the one the invoice has. Current behavior before PR: When a user tries to create a CN from a E-invoice with a manual journal, and then changes the journal on the CN wizard, the field "Document number" that is required for manual journals is still visible and required so the wizard can not be confirmed. Desired behavior after PR is merged: When the user creates a

Description of the issue/feature this PR addresses:
This PR aims to allow the user to create a CN in a different journal than the one the invoice has.

Current behavior before PR:
When a user tries to create a CN from a E-invoice with a manual journal, and then changes the journal on the CN wizard, the field "Document number" that is required for manual journals is still visible and required so the wizard can not be confirmed. 

Desired behavior after PR is merged:
When the user creates a CN and then change the journal on the CN wizard, the visibility and requirement of the fields should be adjusted as expected for the journal type selected.



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

Forward-Port-Of: odoo/odoo#192728

Before this commit: when printing request to ePOS printer is in process, if user moves to home screen in POS the currentOrder becomes null and throws exception. after this commit: currentOrder is stored before processing the request to avoid the exception. opw-3859174 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-p

Before this commit:
when printing request to ePOS printer is in process, if user moves to home screen in POS the currentOrder becomes null and throws exception.

after this commit:
currentOrder is stored before processing the request to avoid the exception.

opw-3859174

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#194726
Forward-Port-Of: odoo/odoo#165333

Behavior Before the Commit: Whenever you change the account type of a Cash and Bank account to a different type, please ensure that the Reconcile option is set to True. However, if you later switch the account type back to Cash and Bank, the Reconcile option will remain True and will not automatically revert to False. Fix: explicitly set reconcile to False for account_type 'Cash and Bank' in compute_reconcile method. Behavior After the commit: Reconcile will be changed to false o

Behavior Before the Commit:
Whenever you change the account type of a Cash and Bank account to a different type,
please ensure that the Reconcile option is set to True. However, if you later switch
the account type back to Cash and Bank, the Reconcile option will remain True and
will not automatically revert to False.
    
Fix: explicitly set reconcile to False for account_type 'Cash and Bank' in compute_reconcile
method.

Behavior After the commit:
Reconcile will be changed to false on changing the account type to Cash and Bank.

opw-4450088: https://www.odoo.com/odoo/my-support-tasks/4450088
---
I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr

Forward-Port-Of: odoo/odoo#194358

The nocontent message for inventory counts was still referring to old concepts from before the 17.0 Milk redesign (like the "CREATE" button or the Import action in the Favorites menu). This commit updates the message to correctly reference the new design actions, corrects the English and escapes translations inserted into HTML. [task-4550935](https://www.odoo.com/odoo/project.task/4550935) Forward-Port-Of: odoo/odoo#196886 Forward-Port-Of: odoo/odoo#196835

The nocontent message for inventory counts was still referring to old concepts from before the 17.0 Milk redesign (like the "CREATE" button or the Import action in the Favorites menu).

This commit updates the message to correctly reference the new design actions, corrects the English and escapes translations inserted into HTML.

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

Forward-Port-Of: odoo/odoo#196886
Forward-Port-Of: odoo/odoo#196835

### Steps to reproduce: - In the settings enable: Multi-Step Routes, Operations > Packages - Create a storable prodcut - Update the on hand quantity: - 10 units in package PK - Inventory > Configuration > Warehouse Management > Locations - Create 2 warehouse locations: WH/LOC1, WH/LOC2 - Go to the barcode app and proceed with the scans: 1. Scan the internal transfer picking type 2. Scan WH/STOCK as a source location 3. Scan the package name (PK) 4. Scan WH/LOC1 as

### Steps to reproduce:

- In the settings enable: Multi-Step Routes, Operations > Packages
- Create a storable prodcut
- Update the on hand quantity:
  - 10 units in package PK
- Inventory > Configuration > Warehouse Management > Locations
- Create 2 warehouse locations: WH/LOC1, WH/LOC2
- Go to the barcode app and proceed with the scans:
    1. Scan the internal transfer picking type
    2. Scan WH/STOCK as a source location
    3. Scan the package name (PK)
    4. Scan WH/LOC1 as destination location
- Leave the barcode app without validation
- Go to the barcode app and proceed with the scans: i -> iii,  iv'. Scan WH/LOC2 as destination location
- Try to validate the picking
#### > Invalid operation: You cannot move the same package content more than once in the same transfer or split the same package into two location.

### Cause of the issue:

As both pickings were treated via the barcode app, they generated picked move lines related to the package. Both of these move lines have updated the reserved quantity of the stock.quant present in stock:
- WH/STOCK, quantity: 10, reserved_quantity: 20.

When you try to validate the second picking, you will launch an `_action_done` of its move line that will create a new quant in WH/LOC2 and update the quant in stock:
- WH/STOCK, quantity: 0, reserved_quantity: 10.
- WH/LOC2, quantity: 10, reserved_quantity: 0.

The error is raised just after since 2 quants with either a quantity or reserved quantity are found:
https://github.com/odoo/odoo/blob/6349fb0362d881672616bb4b800bd32be82f9a5f/addons/stock/models/stock_move.py#L1910-L1917

### Fix:

Since the check is made in order to check the consistency of result packages moved by the current validation the "reserved_quantity" should not matter.

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

Forward-Port-Of: odoo/odoo#193214

Description of the issue/feature this PR addresses: This PR is to fix an issue encountered when copying information from an editor for a product for example, and pasting it on the product label. On Odoo the label was appearing fine but when the invoice was confirmed and sent, the XML file content is created with hidden characters.This produced the web service to return an error when trying to validate the electronic invoice. Current behavior before PR: Special or hidden characters appear o

Description of the issue/feature this PR addresses:
This PR is to fix an issue encountered when copying information from an editor for a product for example, and pasting it on the product label. On Odoo the label was appearing fine but when the invoice was confirmed and sent, the XML file content is created with hidden characters.This produced the web service to return an error when trying to validate the electronic invoice. 

Current behavior before PR:
Special or hidden characters appear on the XML file of an electronic invoice.

Steps to reproduce:
1. Install Uruguay - Electronic Invoice module
2. Create EDI invoice, add special character to the description of the product you are using. Example used for testing (copy-paste it): ‭219179120011‬
3. Validate the invoice
4. Print and send it
5. Check "DscItem" field on the XML file created.

Here is a one minute [video](https://drive.google.com/file/d/18JcnKCbaq7cH_NVyPol4CWXHdqZAxAdo/view) reproducing the error on runbot.

Desired behavior after PR is merged:
These characters are cleaned up at the xml level on cleanup_xml_node method to avoid them to appear and prevent errors when validating the XML on localizations web services.

Related PR on v16 regarding the same issue in another context: https://github.com/odoo/odoo/pull/154509

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

Forward-Port-Of: odoo/odoo#193047

When AE localization extends the default invoice report, they replace the `<th name="th_taxes"><span>Taxes</span></th>` with `<th name="th_taxes"><span t-if="...">VAT</span><span t-else="">Taxes</span></th>`. Then when AR localization is installed, it will replace the first div with the t-if. We end up in a situation with a `<span/>` followed by a `<span t-else=""/>` which raise an error because it is expecting a `t-if`. task-no Forward-Port-Of: odoo/odoo#196765

When AE localization extends the default invoice report, they replace the `<th name="th_taxes"><span>Taxes</span></th>` with `<th name="th_taxes"><span t-if="...">VAT</span><span t-else="">Taxes</span></th>`. Then when AR localization is installed, it will replace the first div with the t-if. We end up in a situation with a `<span/>` followed by a `<span t-else=""/>` which raise an error because it is expecting a `t-if`.

task-no

Forward-Port-Of: odoo/odoo#196765

ELM 5.0 Swissdec Certification Forward-Port-Of: odoo/enterprise#78714 Forward-Port-Of: odoo/enterprise#64454

ELM 5.0 Swissdec Certification

Forward-Port-Of: odoo/enterprise#78714
Forward-Port-Of: odoo/enterprise#64454

Prior to this commit, undoing auto plan results in having the shifts remaining in the searchBar, and therefore still highlighted. This commit aims to reset the selection and the highlight after undo auto plan. To reproduce the bug: 1. In planning, clcik auto plan and then undo. 2. Auto planned shifts which are now in unassigned are still highlighted and the search bar contains these shifts. task: 3999600 Forward-Port-Of: odoo/enterprise#73821

Prior to this commit, undoing auto plan results in having the shifts remaining in the searchBar, and therefore still highlighted. This commit aims to reset the selection and the highlight after undo auto plan.

To reproduce the bug:
1. In planning, clcik auto plan and then undo.
2. Auto planned shifts which are now in unassigned are still highlighted and the search bar contains these shifts.

task: 3999600

Forward-Port-Of: odoo/enterprise#73821

Versions -------- - 17.0+ Steps ----- 1. Use Belgian localization; 2. create an invoice for a Belgian customer; 3. pay the invoice using SEPA Direct Debit; 4. go to Accounting / Bank; 5. create a bank statement matching the SDD mandate details; 6. go to payment transactions linked to the invoice. Issue ----- The transaction is still pending, and the SDD Mandate hasn't been confirmed. Cause ----- When matching transactions to bank statement lines, it checks whether `tx.refer

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

Steps
-----
1. Use Belgian localization;
2. create an invoice for a Belgian customer;
3. pay the invoice using SEPA Direct Debit;
4. go to Accounting / Bank;
5. create a bank statement matching the SDD mandate details;
6. go to payment transactions linked to the invoice.

Issue
-----
The transaction is still pending, and the SDD Mandate hasn't been confirmed.

Cause
-----
When matching transactions to bank statement lines, it checks whether `tx.reference == line.payment_ref`. The `tx.reference` is based on the invoice name, whereas `payment_ref` depends on localization, with Belgian payment request being structured as `+++000/0000/12345+++`.

Solution
--------
When creating a SDD mandate transactions, display `tx.reference` as payment communication.

opw-4380832

Forward-Port-Of: odoo/enterprise#78413

In the tree view of the payslip model, we can do mass edit to create a journal entry. Before, we were able to perform this action on a paid payslip which does not make sense. Now we have an error message if we try to do it. Task: 3874129 Forward-Port-Of: odoo/enterprise#78633 Forward-Port-Of: odoo/enterprise#75035

In the tree view of the payslip model, we can do mass edit to create a journal entry. Before, we were able to perform this action on a paid payslip which does not make sense. Now we have an error message if we try to do it.

Task: 3874129

Forward-Port-Of: odoo/enterprise#78633
Forward-Port-Of: odoo/enterprise#75035

## Description Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the `commercial_partner_id` of `self`. This works well for form views, where `self` is a singleton. However, since the field `product_id` is present in the list view, which has a domain depending on `suitable_product_ids`, the computation is triggered for all tickets in the list view, making `self` not a sing

## Description
Following odoo/enterprise@c9ceba2cf5982c244fe1ad3054d1463d9eca0e8c, the set of suitable_partners used to determine which products can be associated with a ticket is based on the `commercial_partner_id` of `self`. This works well for form views, where `self` is a singleton. However, since the field `product_id` is present in the list view, which has a domain depending on `suitable_product_ids`, the computation is triggered for all tickets in the list view, making `self` not a singleton.
This causes the set of suitable partners to be larger than necessary, as it becomes the collective set for *all* tickets referenced in `self`, leading to false positives where products associated with a specific partner's sales/delivery history might appear suitable for another ticket with a different partner.

To address this, we split `self` by `commercial_partner`, as the set of products that could be suitable depends on the partner's sales/delivery history, not on individual tickets.

## Reference
opw-4444078

Forward-Port-Of: odoo/enterprise#78614
Forward-Port-Of: odoo/enterprise#78087

In the recent fix at 904c7c8a, we forgot the inherited allowed facets and removed too many tags when changing folders. opw-4347910 Original PR: https://github.com/odoo/enterprise/pull/75001 Forward-Port-Of: odoo/enterprise#78616

In the recent fix at 904c7c8a, we forgot the inherited allowed facets and removed too many tags when changing folders.

opw-4347910

Original PR: https://github.com/odoo/enterprise/pull/75001

Forward-Port-Of: odoo/enterprise#78616

This PR aims to prevent showing outdated error messages on an uruguayan electronic invoice that has already been amended. When a user creates a CFE invoice with invalid information (for example, the unit price of the product detailed in the invoice is equal to 0.0), the webservice returns an error that is captured on Odoo and shown as a pop-up and added as a banner on the move header. If the user resets the move to draft, corrects the error and for some reason introduces another one (like lea

This PR aims to prevent showing outdated error messages on an uruguayan electronic invoice that has already been amended. 
When a user creates a CFE invoice with invalid information (for example, the unit price of the product detailed in the invoice is equal to 0.0), the webservice returns an error that is captured on Odoo and shown as a pop-up and added as a banner on the move header.
If the user resets the move to draft, corrects the error and for some reason introduces another one (like leaving the "tax" column empty), then confirm and send the invoice again to DGI, a new pop up is raised showing a new error message accordingly but the banner of the header remains showing the same error as before (saying the product unit price is 0). This leads to confusion about what is the current error to be amended to properly send the invoice to DGI.

Steps to reproduce the error:
- Create an uruguayan electronic invoice on a testing enviroment.
- Select a product and change its unit price to 0.
- Try to send & print the invoice, creating the CFE.
- An error like this will be shown: 
![image](https://github.com/user-attachments/assets/224a3755-06a4-4c6a-a77f-66cc988719a4)
- Go back to the move and check that a banner with the error has been added at the top.
![image](https://github.com/user-attachments/assets/e79877ca-073a-48ab-90cd-4b91f96be89a)
- Reset to draft, add a valid unit price and delete the "Taxes" column value. 
- Confirm, Send&Print the invoice. 
- A new pop up like this should raise:
![image](https://github.com/user-attachments/assets/72551e4b-8392-4ea3-8e99-43d84b478a9b)
- Go back to the invoice and check that the banner remains as before, showing an outdated error message.

Forward-Port-Of: odoo/enterprise#77710

This commit avoids calling the toggle cron function with journal_ids recordset after an online account has been unlinked. Previously, this caused an error because the record was already deleted. The journal_ids model is now retrieved from the environment instead of the potentially stale recordset. The bug was introduced by this commit [[1]]. no task id [1]: https://github.com/odoo/enterprise/commit/bc3b9136d4d62fbc1d09267f73cac7ca29f1ba3a Forward-Port-Of: odoo/enterprise#78680

This commit avoids calling the toggle cron function with
journal_ids recordset after an online account has been unlinked.
Previously, this caused an error because the record was already
deleted. The journal_ids model is now retrieved from the environment
instead of the potentially stale recordset.
The bug was introduced by this commit [[1]].

no task id

[1]: https://github.com/odoo/enterprise/commit/bc3b9136d4d62fbc1d09267f73cac7ca29f1ba3a

Forward-Port-Of: odoo/enterprise#78680

### Before this commit: Clicking on a budgetary position opened the list view showing all budget lines, regardless of the selected budgetary position. ### After this commit: Now, clicking on a budgetary position will open the list view filtered to show only the budget lines associated with that specific budgetary position. ### Technical: In `doActionButton`, we use the `args` if the action type is object. so, `domain` is irrelevant in this context. **task-4195738** Forward-Port-Of:

### Before this commit:
Clicking on a budgetary position opened the list view showing all budget lines, regardless of the selected budgetary position.

### After this commit:
Now, clicking on a budgetary position will open the list view filtered to show only the budget lines associated with that specific budgetary position.

### Technical:
In `doActionButton`, we use the `args` if the action type is object. so, `domain` is irrelevant in this context.

**task-4195738**

Forward-Port-Of: odoo/enterprise#73785

The mapping that is currently used can lead to a constraint on accout types being triggered, blocking the import procedure. This commit aims at fixing this by removing the account code range for the recievable and payable types. From now on, these will only be applied when the corresponding 'CENTRALID' matches respectively 'S' for payables and 'C' for receivable. task-4465663 Forward-Port-Of: odoo/enterprise#78700 Forward-Port-Of: odoo/enterprise#77103

The mapping that is currently used can lead to a constraint on accout types being triggered, blocking the import procedure.

This commit aims at fixing this by removing the account code range for the recievable and payable types.

From now on, these will only be applied when the corresponding 'CENTRALID' matches respectively 'S' for payables
and 'C' for receivable.

task-4465663

Forward-Port-Of: odoo/enterprise#78700
Forward-Port-Of: odoo/enterprise#77103

Steps to Reproduce: 1. Enable the Rental Transfers option in Configuration > Settings. 2. Create a rental order with one rental product and one sales product. 3. Confirm the order. 4. Validate the delivery order. Issue: - The delivered quantity is updated for the rental product but not for the sales product. Cause: - This behavior arises because the assign_picking method reuses an existing picking_id if the domain matches, updating subsequent moves' location_dest_id to match

Steps to Reproduce:
1. Enable the Rental Transfers option in Configuration > Settings.
2. Create a rental order with one rental product and one sales product.
3. Confirm the order.
4. Validate the delivery order.

Issue:
- The delivered quantity is updated for the rental product but not for the sales
  product.

Cause:
- This behavior arises because the assign_picking method reuses an existing
  picking_id if the domain matches, updating subsequent moves' location_dest_id
  to match the reused picking.

Fix:
- Override _compute_location_dest_id and update the location_dest_id if conditions are fulfilled.

opw-4298443

Forward-Port-Of: odoo/enterprise#73895

This PR aims to fix an error on PDF reports on UY invoices, that occurs when copy-pasting the addenda text from an editor in Odoo. It happens that sometimes the text has hidden characters inside and those are printed as ? in the pdf. Steps to reproduce: 1) Install l10n_uy_edi 2) Create or duplicate an e-invoice 3) Copy-paste the following text in the "Terms and conditions" section: Estimated Net Weight: 84.000,00 Kg Estimated Gross Weight: 84.240,00 BL Nº: HLCUPN4240969947 ​

This PR aims to fix an error on PDF reports on UY invoices, that occurs when copy-pasting the addenda text from an editor in Odoo. It happens that sometimes the text has hidden characters inside and those are printed as ? in the pdf.

Steps to reproduce:
1) Install l10n_uy_edi
2) Create or duplicate an e-invoice
3) Copy-paste the following text in the "Terms and conditions" section:
Estimated Net Weight: 84.000,00 Kg

Estimated Gross Weight: 84.240,00

BL Nº: HLCUPN4240969947



​



BANK DETAILS: TEST12344
4) Confirm, print and send the invoice.
5) Check the pdf is created like this: 
![image](https://github.com/user-attachments/assets/881fb73c-1f81-42bc-ab71-0b1454184c17)

Expected behavior after this PR:
The text on the "Adenda" section of the pdf should not print hidden characters.

Forward-Port-Of: odoo/enterprise#76972