Skip to content

[18.0][OU-FIX] account: fill journal_id for all existing payments - #22

Open
eantones wants to merge 2 commits into
18.0from
18.0-ou-fix-account_payment_fill
Open

eantones wants to merge 2 commits into
18.0from
18.0-ou-fix-account_payment_fill

Conversation

@eantones

@eantones eantones commented Jul 19, 2026 •

Copy link
Copy Markdown
Member

At 18.0 account.payment stops delegating to its move (_inherits dropped), and journal_id / company_id become the payment's own stored required fields (both compute=..., store=True, required=True).

company_id is filled from the move upstream since d95d630 («[OU-FIX] account: fill account.payment company_id from its move»). This PR covers the other field.

The current fill_account_payment() sets journal_id from the move only when the move's journal is of type bank/cash/credit. Payments whose move lives in any other journal type (e.g. general, common for netting/compensation flows) are left with journal_id = NULL. The NULLs then block SET NOT NULL on journal_id at load, so the required column ends up without its NOT NULL constraint.

The journal is fully derivable from the payment's move (move_id is never NULL for legacy payments). This patch falls back to the move's journal for payments whose move sits outside bank/cash/credit journals, so historical rows keep their true journal and SET NOT NULL succeeds.

The first commit also filled company_id. The second drops that half, now that upstream does it: merged with upstream, the UPDATE would assign company_id twice, which PostgreSQL rejects.

…ng payments

account.payment at 18.0 turns journal_id and company_id into its own stored
required fields (in <=17.0 they were delegated to the move). The existing
fill only set journal_id when the move journal is bank/cash/credit, and
never set company_id at all, leaving legacy payments with NULLs in required
columns: the SET NOT NULL of both columns fails at load, and the lazy ORM
compute of company_id falls back to self.env.company on first edit,
silently assigning the editing user company.

Both values are fully derivable from the payment move: fill company_id for
every payment, and fall back to the move journal for payments whose move
lives outside bank/cash/credit journals, so historical rows keep their
real journal and both NOT NULL constraints can install.
@eantones eantones added the local-only Contains commits that stay in this repo forever (customer-private modules, local policy). label Jul 19, 2026
OCA/OpenUpgrade d95d630 now adds the account_payment.company_id
column and fills it from the move in the same UPDATE. Merged with this
branch, the UPDATE assigns company_id twice, which PostgreSQL rejects
(multiple assignments to same column), and _new_columns lists the
column twice.

Keep only what upstream still lacks: the journal_id fallback for
payments whose move sits outside bank, cash and credit journals.
@eantones eantones changed the title [18.0][OU-FIX] account: fill company_id and journal_id for all existing payments [18.0][OU-FIX] account: fill journal_id for all existing payments Oct 26, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

local-only Contains commits that stay in this repo forever (customer-private modules, local policy).

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant