[16.0][IMP] account_payment_partner: add flag to control partner_bank_id without payment mode

[felipemotter]

Summary

After OCB commit 7763099c (backported to OCB 16.0 on Feb 10, 2026), the core _compute_partner_bank_id method now filters bank accounts by the allow_out_payment field and the reversal wizard explicitly calls _compute_partner_bank_id() after creating reversed moves.

The account_payment_partner override of _compute_partner_bank_id had an else branch that unconditionally set partner_bank_id = False when no payment_mode_id was present. This discarded the value computed by super(), preventing trusted bank accounts (with allow_out_payment=True) from being auto-selected.

Why PR #1554 is not sufficient

PR #1554 (already merged) added allow_out_payment=True to test bank accounts, which fixed the account_payment_partner own tests. However, it did not address the root cause in the code logic.

The issue is specifically in _compute_partner_bank_id at account_payment_partner/models/account_move.py:

@api.depends("bank_partner_id", "payment_mode_id")
def _compute_partner_bank_id(self):
    res = super()._compute_partner_bank_id()
    for move in self:
        payment_mode = move.payment_mode_id
        if payment_mode:
            # ... handles payment mode cases
        else:
            move.partner_bank_id = False  # ← THIS LINE clears what super() set
    return res

When no payment_mode_id is set, the else branch overrides whatever super() computed. After the OCB change, super() correctly auto-selects trusted bank accounts filtered by allow_out_payment=True, but this override discards the result.

This is particularly visible in the OCA/l10n-brazil multi-localization tests (test_force_out_invoice_create_refund), where:

1. The reversal wizard creates a reversed move with partner_bank_id=False as default
2. Then explicitly calls _compute_partner_bank_id() to recompute
3. OCB's super() correctly finds the partner's bank account (with allow_out_payment=True)
4. But account_payment_partner's else branch immediately clears it to False

Since the test uses a US company (no Brazilian fiscal operations, no payment modes), payment_mode_id is empty, and the bank account is always cleared — causing all open PRs in OCA/l10n-brazil to fail CI.

Root cause

The else: move.partner_bank_id = False was added to prevent auto-filling bank accounts without a payment mode. However, since OCB now uses allow_out_payment (default False, opt-in) to control which accounts are trusted for auto-selection, this guard is no longer needed — the core already ensures only explicitly trusted accounts are used.

Solution

• Remove the else: move.partner_bank_id = False branch from _compute_partner_bank_id, so the value computed by super() is preserved when no payment mode is set
• Update test_onchange_payment_mode_id to expect the bank account to remain set after removing the payment mode (since the bank has allow_out_payment=True, core auto-selects it)

How to reproduce

Install account_payment_partner with OCB 16.0 (commit ada7a398f or later, which includes 7763099c). Then run the OCA/l10n-brazil multi-localization test:

test_force_out_invoice_create_refund

• Before the fix: partner_bank_id is False (test fails)
• After the fix: partner_bank_id is correctly set to the partner's trusted bank account (test passes)

[CristianoMafraJunior]

LGTM

[kaynnan]

cc @marcelsavegnago @pedrobaeza @victoralmau

[felipemotter]

Added a dedicated test (test_refund_no_payment_mode_preserves_partner_bank) that reproduces the exact scenario:

1. Creates a partner without customer_payment_mode_id
2. Creates a bank account with allow_out_payment=True for that partner
3. Creates and posts an out_invoice with payment_mode_id=False
4. Creates a refund via the reversal wizard
5. Asserts that partner_bank_id on the refund is correctly set to the trusted bank account

This test fails without the code fix and passes with it.

[marcelsavegnago]

LGTM

[antoniospneto]

cc @rvalyi

[kaynnan]

ping @OCA/banking-maintainers

[grindtildeath]

Thanks for the PR, but did you check #1418 before?

[felipemotter]

@grindtildeath Thanks for pointing that out — we were not aware of #1418 when we opened this PR. We've now reviewed the full discussion there and understand the concerns from both sides.

Update: company-level flag approach

Based on the consensus suggested by @pedrobaeza in #1418 (comment), we've updated this PR to add a company-level flag instead of simply removing the else branch. This way each company can choose the behavior that fits their workflow.

New field

keep_partner_bank_without_payment_mode (Boolean) on res.company:

• True (default): no payment mode → keeps whatever super() computed (new behavior, respects Odoo core)
• False: no payment mode → clears partner_bank_id = False (legacy behavior)

What changes in practice

• Fresh installs get the correct behavior out of the box (flag=True by default)
• Those who need the legacy behavior (e.g. direct debit orders) can disable the flag in company settings
• The setting appears in the "Customer Payments" section of Accounting settings

Files modified

• models/res_company.py (new) - Boolean field on company
• models/res_config_settings.py (new) - related field for settings UI
• views/res_config_settings.xml (new) - checkbox in settings
• models/account_move.py - else branch now checks the company flag
• models/__init__.py - imports for new models
• __manifest__.py - new view added to data

Tests

• test_onchange_payment_mode_id updated to reflect the default (flag=True keeps bank)
• test_no_payment_mode_clears_bank_when_flag_disabled (new) - verifies flag=False clears the bank
• test_refund_no_payment_mode_preserves_partner_bank (new) - verifies refund without payment mode preserves the bank

All 20 tests passing, 0 failures.

---

@sbidoul Would you be OK with us addressing this in our PR? We're in urgent need of this fix because the OCA/l10n-brazil CI is completely blocked — all open PRs are failing due to account_payment_partner clearing partner_bank_id on invoices without a payment mode. The flag approach should satisfy both sides of the #1418 discussion while unblocking the Brazilian localization.

[pedrobaeza]

Thanks for doing the changes to reconcile both behaviors. I accept to switch the default behavior to the new one to preserve the bank account.

Let's merge this one:

/ocabot merge patch

[OCA-git-bot]

On my way to merge this fine PR!
Prepared branch 16.0-ocabot-merge-pr-1555-by-pedrobaeza-bump-patch, awaiting test results.

[antoniospneto]

@pedrobaeza ocabot fail?

[pedrobaeza]

/ocabot merge patch

[OCA-git-bot]

On my way to merge this fine PR!
Prepared branch 16.0-ocabot-merge-pr-1555-by-pedrobaeza-bump-patch, awaiting test results.

[OCA-git-bot]

@pedrobaeza your merge command was aborted due to failed check(s), which you can inspect on this commit of 16.0-ocabot-merge-pr-1555-by-pedrobaeza-bump-patch.

After fixing the problem, you can re-issue a merge command. Please refrain from merging manually as it will most probably make the target branch red.

[antoniospneto]

The pre-commit checks are currently failing due to setuptools. I’m going to open a PR updating the repository (via copier update) to switch from setup.py to pyproject.toml, which should fix the issue.

[antoniospneto]

@pedrobaeza

I opened a PR with the pre-commit fix here: #1559

[pedrobaeza]

/ocabot merge patch

[OCA-git-bot]

Hey, thanks for contributing! Proceeding to merge this for you.
Prepared branch 16.0-ocabot-merge-pr-1555-by-pedrobaeza-bump-patch, awaiting test results.

[OCA-git-bot]

Congratulations, your PR was merged at 5cd82ff. Thanks a lot for contributing to OCA. ❤️

[remi-filament]

Thanks @felipemotter for this PR and for the addition of configuration parameter !
Do you plan to port this change on other versions ?

[felipemotter]

@remi-filament i can do this.

[felipemotter]

@remi-filament Done! Ports are open:

• 17.0: [17.0][PORT] account_payment_partner: add flag to control partner_bank_id without payment mode #1560
• 18.0: [18.0][PORT] account_payment_partner: add flag to control partner_bank_id without payment mode #1561