[dnplkndll]

payment_method_ids was a many2many in 19.0, so one payment.method record
served every provider of every company. 20.0 makes it a one2many and each
provider owns its own copies — payment.provider.copy() creates them when a
fresh install duplicates a provider into a company.

An upgrade never calls copy(). On the 585-module seed only the 16
providers the module data names came out with methods, and all 117 companies but
one were left with none. The only symptom in the log was one line the upgrade
does not fail on:

Constraint not added: column "provider_id" of relation "payment_method" contains null values

The fix

end-migration replays that copy against the 19.0 relation table, which
pre-migration renames and unhooks from its foreign keys so that deleting the
obsolete methods cannot empty the evidence. Result on the seed: 32250 methods
across 2090 providers and all 117 companies.

rename_tables is deliberately not used for that rename: it renames the
constraints too, and both foreign key names prefixed with the legacy name
truncate to the same 63-character identifier, so the second rename collides with
the first.

The 19.0 records themselves are provider-agnostic and have no place in 20.0.
Transactions and tokens are moved onto their own provider's method of the same
code first; anything still referenced is left alone rather than cascading a
delete into a customer's history.

The transformation file

The analyser sees the 20.0 data files no longer setting payment_method_ids and
emits eval="None". On a one2many that does not clear a relation table — it
unlinks the provider's payment methods, and core refuses with "You cannot
delete the default payment method." noupdate_changes-transformation.xml drops
those nodes.

Known gap

8 custom providers are still left without methods and say so via
openupgrade.message: 19.0 had three custom modes (wire_transfer,
cash_on_delivery, on_site) and 20.0 ships two against providers 19.0 never
had. That is a payment_custom question and is deliberately not answered here.

Draft until fork CI is green on this branch alone. Depends on #119 for the rest
of the analysis sweep.

AI-assisted (Claude Code); every change reviewed, tested, and owned by the author.

---

CI: red by construction until #118 lands

The test job fails on duplicate key value violates unique constraint "res_country_state_name_code_uniq" (Ladakh / Odisha). That is not this branch:
base's pre-migration, which renames base.state_in_or → base.state_in_od
and l10n_in.state_in_la → base.state_in_la, lives in #118 and is not on
20.0 yet. Every branch cut from 20.0 alone hits it, which is why #117 is red
for the same reason.

Per the fork's model the per-PR test check is the lean one; the real migration
gate is the integration branch (#120), where this module's scripts run green as
part of the full 585-module seed.