Skip to content

[16.0][IMP] account_payment_partner: company flag to control partner_bank_id without payment mode#3

Closed
felipemotter wants to merge 2 commits into16.0from
16.0-fix-compute-partner-bank-no-payment-mode-v2
Closed

[16.0][IMP] account_payment_partner: company flag to control partner_bank_id without payment mode#3
felipemotter wants to merge 2 commits into16.0from
16.0-fix-compute-partner-bank-no-payment-mode-v2

Conversation

@felipemotter
Copy link
Copy Markdown

@felipemotter felipemotter commented Feb 16, 2026

Context

This PR is a proof of concept to resolve the stalemate in the OCA/bank-payment#1418 discussion, which has been stuck for over a year.

The core issue: the else: move.partner_bank_id = False in _compute_partner_bank_id unconditionally clears the bank account when no payment mode is set. This breaks Odoo core behavior (which now uses allow_out_payment to auto-select trusted bank accounts), affecting Peppol, QR codes, Swiss localization, and l10n-brazil tests.

Our PR #1555 simply removes the else, which fixes the problem but doesn't satisfy those who depend on the legacy behavior (e.g. direct debit orders, as pointed out by @pedrobaeza).

Proposed solution

The consensus solution suggested by Pedro himself in the original discussion: a company-level flag that controls which behavior to use.

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 flag
  • models/__init__.py - imports for new models
  • __manifest__.py - version bump to 16.0.1.3.0

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.

Important

This PR is a proof of concept only. The goal is to validate the approach before formally proposing it on OCA/bank-payment. It should not be merged directly — the idea is to use it as the basis for a new upstream PR replacing OCA#1555, if the approach is approved.

…thout payment mode

Add a company-level setting keep_partner_bank_without_payment_mode
(default True) that controls whether partner_bank_id is preserved or
cleared when no payment mode is set on an invoice.

When enabled (default), invoices without a payment mode keep the bank
account auto-selected by Odoo core. When disabled, the bank account is
cleared (legacy behavior).

This resolves the long-standing disagreement in OCA#1418
by letting each company choose the behavior that fits their workflow.
@felipemotter felipemotter force-pushed the 16.0-fix-compute-partner-bank-no-payment-mode-v2 branch from b667057 to 9d65b1d Compare February 16, 2026 17:45
Update test_onchange_payment_mode_id to reflect the new default
behavior (flag=True keeps bank account).

Add test_no_payment_mode_clears_bank_when_flag_disabled to verify
that disabling the flag restores the legacy clearing behavior.

Add test_refund_no_payment_mode_preserves_partner_bank to verify
that refunds without payment mode preserve the bank account.
@felipemotter felipemotter force-pushed the 16.0-fix-compute-partner-bank-no-payment-mode-v2 branch from 9d65b1d to aa8e643 Compare February 16, 2026 17:47
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant