Operator-authorised repair. A counter delivery note is raised when the
customer takes goods off the shelf, so the collection has already
happened — but these lines were created with `qty_collected` at 0.
`qty_collected` is what the invoice path reads to decide how many units
to bill, so every one of these would have produced a zero-quantity
invoice line, which QuickBooks rejects (n8n 400 -> the opaque 502 the
operator reported). New and edited notes are already correct
(`848c483`); this is the backlog.
found: 315 counter lines with qty_collected <= 0
fixed: 301 rows across 114 delivery notes
skipped: 14 — already invoiced, deliberately left alone
Two exclusions are load-bearing:
- Already invoiced. Rewriting a row after the invoice settled
against the old number would leave the note disagreeing with a
document the customer already holds. One carried a real
QuickBooks number (INV29681); the rest are dated "INVOICED…"
markers. Reported by the script so the skip is visible rather
than silent.
- Parent order. On an order-linked note `qty_collected` means "the
driver has this many in the van". Overwriting it with the order
quantity would bill for goods that have not arrived — the exact
irregularity the field exists to prevent.
`scripts/backfill-counter-collected.mts` is DRY RUN by default and
needs `--apply` to write. It is idempotent: a re-run reports 0 to fix.
Verified after the fact that no order-linked line was touched
(0 remaining, same as before).
