SEPA credit transfer files no longer include duplicate issuer or LEI identifier entries. This helps prevent payment file validation issues and reduces the risk of bank rejections caused by repeated information.

Issr and LEI nodes were added twice, because they were handled both in the generic ISO20022 code and the SEPA Credit Transfer override.

Fixed an issue where batch validation and export buttons could stay hidden for bank journals without payment initiation configured when online payments were installed. This ensures accounting teams can validate and export batch payments from the affected journals as intended.

Before this commit, when account_online_payment was installed and no payment initiation was configured on a bank journal, the batch validation and export buttons never appeared on the batch payments made on this journal.

SEPA direct debit batch validation now handles missing setup information more gracefully, such as absent mandates or creditor identifiers. Users receive clearer, better-timed error messages instead of system crashes, making payment batch preparation easier to correct.

[IMP] account_sepa_direct_debit: better sequence of error messages
    
    The check validating the collection date was made before we've checked all mandates are in the right state, yet it depended on the mandates to check the minimum collection date available for this batch. We now make it so we first check all the mandates are valid, for usability.

===================================================

[FIX] account_sepa_direct_debit: Don't crash when validating a batch when the company has no creditor identifier

A check for that already existed in validate_batch, raising an error, but it wasn't called in time, and this caused a traceback because the super call had been moved at the beginning of the function.

===================================================

[IMP] account_sepa_direct_debit: clearer error message

===================================================

    [FIX] account_sepa_direct_debit: don't crash when trying to generate a batch containing a single SDD payment without mandate
    
    To reproduce:
    
    1) Create a payment for some new partner, using SEPA Direct Debit. Make sure no mandate exists for this partner.
    2) Add the payment created in 1 into a new batch. It must be the only payment in it
    3) Try validating the batch
    ====> Traceback
    
    This is because the query checking which mandates are used for the first time receives an empty tuple for its "mandate_ids" parameter. SQL tries to run "... IN ()", which crashes.
    
    After fixing this bug, the same flow still crashes because we're trying to call max() on an empty sequence in validate_batch in order to compute the pre_notification_period. We fix that by adding a new check in order to redirect the user in case some payments of the batch are missing a mandate.

This update corrects problems when registering SEPA Direct Debit payments, especially when creating payments for multiple customers at once. It also improves mandate visibility and ensures collection dates account for payments that are already fully paid, reducing payment processing errors.

This fixes issues that arose in 6aa473d, including:
 - Payments creations in batch from the list view do not handle the multiple partners case
 - The blue "Valid mandate available" banner does not show when you're not already using the SDD payment method

The trial balance report now opens correctly when horizontal groups are configured. This prevents users from hitting an error screen and keeps financial reporting accessible in affected setups.

Steps to reproduce
 - Create a horizontal group
 - open the trial balance -> Traceback

Cause of the issue:
a None value is set in the 'no_format' key of a line of the report.

Manufacturing order operation costs are now calculated more accurately when production starts or finishes without an expected duration. This improves cost reporting by using actual duration and the relevant machine, labor, and workcenter employee costs where appropriate.

This commit modifies the MO cost of operations.

Now, when the production is started and if there is no duration expected on the operation, the mo cost of the operation will be the theorical cost of the real duration (i.e. it will be the result of machine + labour cost for that duration).

When the production is done, the same behaviour will be applied, but without the labour cost.
The timesheet cost of an operator for the MO cost column is now computed based on the operation's workcenter employee cost.

This fix ensures document access updates run correctly when performed with elevated system rights. It prevents permission checks from incorrectly blocking internal access updates, improving reliability for document sharing and membership changes.

Purpose
=======
Skip user permission check, when calling `_action_update_access` in SUDO, like it has been done for `_action_update_members`

Portal users can now preview documents without the Documents portal crashing. This fix improves reliability for external users accessing shared documents.

The commit prevents the Documents portal from crashing when portal users try to preview a document.

We prevent the client from raising an error when trying to access an undefined available embedded actions records (not available for portal users.)

task-3373836

Before this commit, entering a payment amount with cash rounding higher than one (e.g., 10) incorrectly triggered an error popup every time. opw-4124332 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#179859 Forward-Port-Of: odoo/odoo#177547

Before this commit, entering a payment amount with cash rounding higher than one (e.g., 10) incorrectly triggered an error popup every time.

opw-4124332

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

Forward-Port-Of: odoo/odoo#179859
Forward-Port-Of: odoo/odoo#177547

In https://github.com/odoo/odoo/pull/152286, we changed the documents that are added to the chatter of a BoM to be added to the product_product directly (or the template if there are no product on the BoM). However, some changes in mail made the just-added document not appear untill reload. This commit fixes it by reloading the chatter when adding an attachment. --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#178990

In https://github.com/odoo/odoo/pull/152286, we changed the documents that are added to the chatter of a BoM to be added to the product_product directly (or the template if there are no product on the BoM).

However, some changes in mail made the just-added document not appear untill reload. This commit fixes it by reloading the chatter when adding an attachment.


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

Forward-Port-Of: odoo/odoo#178990

In a Spanish company if you don't have a certificate set on the company, the PoS would generate a proforma invoice instead of a normal invoice. Steps to reproduce: ------------------- * Install l10n_es_pos * Remove the l10n_es_edi_facturae_certificate_id from the company * Open PoS * Make an order and invoice it > Observation: The invoice generated is a proforma invoice instead of a normal invoice Why the fix: ------------ When generating the invoice data in `_generate_pdf_and_sen

In a Spanish company if you don't have a certificate set on the company, the PoS would generate a proforma invoice instead of a normal invoice.

Steps to reproduce:
-------------------
* Install l10n_es_pos
* Remove the l10n_es_edi_facturae_certificate_id from the company
* Open PoS
* Make an order and invoice it
> Observation: The invoice generated is a proforma invoice instead of a
normal invoice

Why the fix:
------------
When generating the invoice data in `_generate_pdf_and_send_invoice` the wizard would have `l10n_es_edi_facturae_checkbox_xml` checked by default This leads to the generation of a specific invoice that will fail because there are no certificate setup on the company. This will then fallback to the proforma invoice.

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

Forward-Port-Of: odoo/odoo#179107

Before this commit, draft order line products not loaded into the PoS could cause errors during PoS loading. This fix addresses the issue by ensuring that all products referenced in order lines are loaded into the PoS, preventing such errors. opw-4167214 --- I confirm I have signed the CLA and read the PR guidelines at www.odoo.com/submit-pr Forward-Port-Of: odoo/odoo#180886

Before this commit, draft order line products not loaded into the PoS could cause errors during PoS loading. This fix addresses the issue by ensuring that all products referenced in order lines are loaded into the PoS, preventing such errors.

opw-4167214

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

Forward-Port-Of: odoo/odoo#180886

when ecommerce access is restricted to logged in users, so that the products are not publicly accessible on the sitemap. Fixes #165222 Finetuning of 5bde2e42c8ec5e943a779ad4b3e1b7142f2d2fcf Forward-Port-Of: odoo/odoo#176391

when ecommerce access is restricted to logged in users, so that the products are not publicly accessible on the sitemap.

Fixes #165222
Finetuning of 5bde2e42c8ec5e943a779ad4b3e1b7142f2d2fcf

Forward-Port-Of: odoo/odoo#176391

Before this commit: - In the branch's TDS Entry wizard, In the journal field no journal is displayed. After this commit: - In the branch's TDS Entry wizard, In the journal field main company's journal should be displayed. - When a new branch is created, the TDS Journal from the main company should be automatically assigned to the branch. Task-4154543 Forward-Port-Of: odoo/odoo#178933

Before this commit:
- In the branch's TDS Entry wizard, In the journal field no journal is displayed.

After this commit:
- In the branch's TDS Entry wizard, In the journal field main company's journal should be displayed.
- When a new branch is created, the TDS Journal from the main company should be automatically assigned to the branch.

Task-4154543

Forward-Port-Of: odoo/odoo#178933

Issue 1: ======== To reproduce: ------------- - on an appraisal request -> ask for feedback -> set a deadline - the employee can answer after the deadline Problem: -------- the method `_check_validity` was overriden in `hr_appraisal_survey` module to do different checks than the original method in `survey` module in case of `validity_code = answer_wrong_user`, but this override bypasses the other checks in the original method like the deadline check. Solution: --------- call

Issue 1:
========

To reproduce:
-------------
- on an appraisal request -> ask for feedback -> set a deadline
- the employee can answer after the deadline

Problem:
--------

the method `_check_validity` was overriden in `hr_appraisal_survey` module to do different checks than the original method in `survey` module in case of `validity_code = answer_wrong_user`, but this override bypasses the other checks in the original method like the deadline check.

Solution:
---------

call the original method `_check_validity` in the override, to make sure all the checks are done, then if the original method returns `validity_code = answer_wrong_user` we can do our specific checks.

Issue 2:
========

To reproduce:
-------------

- on an appraisal request -> ask for feedback -> set a deadline
- manager can't see the answers after the deadline

Problem:
--------

- to display answer in appraisal module we rely on the url of the survey
that contains the tokens for suervey/answer
- the deadline handling is done in the survey module where the url is dead
after the deadline which is not suitable for the appraisal module

Solution:
---------

- override the method `_get_access_data` and bypass the deadline check
in case of appraisal feedback for manager.

opw-4128638

Forward-Port-Of: odoo/enterprise#69502

Implement support for the generation of EFT files following the requirement of the most popular banks in New Zealand Task id # 3639230 Forward-Port-Of: odoo/enterprise#70930 Forward-Port-Of: odoo/enterprise#69494

Implement support for the generation of
EFT files following the requirement of
the most popular banks in New Zealand

Task id # 3639230

Forward-Port-Of: odoo/enterprise#70930
Forward-Port-Of: odoo/enterprise#69494

Community PR: odoo/odoo#181747 Forward-Port-Of: odoo/enterprise#70905 Forward-Port-Of: odoo/enterprise#70844

Community PR: odoo/odoo#181747

Forward-Port-Of: odoo/enterprise#70905
Forward-Port-Of: odoo/enterprise#70844

Steps: - create a bom for product A with 1 operation - add 2 steps to that operation with the same title, the same test_type_id and the same component(s) - create a 2 MOs for that bom - in the shopfloor, go on the workcenter for the operation - do: Update Instructions > Improvement Suggestion > Add a Step > validate - do the same for the other MO Issue 1: you get a traceback 'Expected singleton' because it cannot differentiate between the 2 pre-existing steps (same title, same test_t

Steps:
- create a bom for product A with 1 operation
- add 2 steps to that operation with the same title, the same test_type_id
and the same component(s)
- create a 2 MOs for that bom
- in the shopfloor, go on the workcenter for the operation
- do: Update Instructions > Improvement Suggestion > Add a Step > validate
- do the same for the other MO

Issue 1:
you get a traceback 'Expected singleton' because it cannot differentiate
between the 2 pre-existing steps (same title, same test_type_id, same
component(s))

Issue 2:
you get a traceback 'Expected singleton' because with at least 2 open MOs,
it will select all checks without `previous_check_id` across all MOs of
the same bom

Fix:
1) if more than 1 step can be selected, take the first and remove it from
the `points` list all the points in that list will be processed only once
so it's ok to remove them after using them.
2) make sure that the selected check corresponds to the MO on which we
are adding a step.

Forward-Port-Of: odoo/enterprise#70753

…ights The setup of the password from a related field would throw errors to user with accountant rights but no administration (settings) rights. This showed other access rights problems with the SBR implementation. The way we want to work with this is: an accountant without settings rights can set up the password through the wizard if no password is stored on the company (for databases that didn't start SBR with the status info module). Once the password is set and is correct (it is the ri

…ights

The setup of the password from a related field would throw errors to user with accountant rights but no administration (settings) rights. This showed other access rights problems with the SBR implementation.

The way we want to work with this is: an accountant without settings rights can set up the password through the wizard if no password is stored on the company (for databases that didn't start SBR with the status info module). Once the password is set and is correct (it is the right one for the certificate), it shouldn't ask the user to put it again and is thus hidden in the wizard.

ticket-4024344

Forward-Port-Of: odoo/enterprise#66096