[dnplkndll]

post-migration.py

19.0's payment state had an "In Process" step that 20.0 does not.

19.0 ran draft -> in_process -> paid; 20.0 runs draft -> paid ->
reconciled. The middle step is gone, and because the column already holds a
value the stored compute leaves it there: the payment reads as blank in the
interface and matches no branch of a domain over the state.

'paid' is the honest landing point. It states only what is certainly true --
the payment was made -- and 20.0's own _compute_state takes it from there:
for a payment already in 'paid' or 'reconciled' it re-derives which of the
two applies from the liquidity lines' residual. Writing 'reconciled'
directly would assert a bank match this migration has no evidence for.

---

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.

[dnplkndll]

Updated: this branch now also carries 19.0's Reviewed flag into 20.0's review queue.

19.0's checked was a stored compute — posted and (journal is general or the user can review) — with readonly=False, so a user could override it. 20.0 replaces it with review_state and keeps an index named _checked_idx over review_state IN ('todo','anomaly'), which is what makes it a work queue rather than a label.

Only the deviation is carried. A True that merely reproduces the compute records nothing a reader could not re-derive, and writing 'reviewed' for it would assert a review of every posted invoice in the database — 3206 of the seed's 3223 moves, on the strength of a value that is really just "posted". A posted move whose checked is False is the opposite: the compute would have set it True, so somebody put that False there, and 'todo' is what 20.0 calls it.

The seed contains no such row (checked equals state='posted' on all 3223), so the branch is unreachable without the fixture added here — a test over the seed alone would pass against a migration that does nothing. Verified: 1 move in the review queue, exactly the 1 posted-and-unchecked move.