[dnplkndll]

post-migration.py

pos.payment.method.type was computed in 19.0 and is stored in 20.0.

19.0 derived it on the fly and kept no column, so the stored column 20.0
adds starts empty against a required field -- the upgrade reports
"Constraint not added: column type of relation pos_payment_method contains
null values" and carries on without the constraint.

The rule is 19.0's own _compute_type, which reads the journal rather than
anything on the method itself::

if pm.journal_id.type in {'cash', 'bank'}:
    pm.type = pm.journal_id.type
else:
    pm.type = 'pay_later'

A method with no journal falls to pay_later, which is why the join is outer.
Not is_cash_count: that agrees with the journal on a cash method but is a
different field, and 20.0 drops it.

---

CI: red until #118 lands

The test job fails on duplicate key value violates unique constraint "res_country_state_name_code_uniq" (Ladakh / Odisha). Not this branch:
base's pre-migration, which renames those two external ids, lives in #118 and
is not on 20.0 yet, so every branch cut from 20.0 alone hits it. Per the
fork's model the per-PR check is the lean one; the real migration gate is the
integration branch (#120), where all of this runs green over the full
585-module seed.

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