Skip to content

v2.16.0

v2.16.0 — Three sprints: over-receipt recorded, labels that scan back, credit and aging

New - **Over-receipt on Removals is recorded, never refused** (MP-RETURNS-02): a completed Removal still classifies; extra units post with witness, `CHANNEL_RETURN_OVER_RECEIPT` becomes a derived n…

New

  • Over-receipt on Removals is recorded, never refused (MP-RETURNS-02): a completed Removal still classifies; extra units post with witness, CHANNEL_RETURN_OVER_RECEIPT becomes a derived notice, and the terminal document states its outcome — Closed: exact / short / over — with an Over marker on the line.
  • Location labels that scan back (LOC-LABEL-01): print Code 128 labels from Location Master — per row or multi-select, through the same dialog pattern as SKU labels (4×3 / 3×2, copies). The encoded value is location.code verbatim and round-trips through the PDA’s directed-scan verify.
  • Credit standing and allocation aging (SO-CREDIT-AGING-01): a derived credit semaphore (RED / AMBER / GREEN from posted invoices — never stored) renders where decisions happen: on the SO detail beside Allocation Status and on the create form the moment a customer is selected. Every order now says how long it has held its allocation; the Stale Allocations report (Inventory → Reports) lists frozen orders by age and bucket. One tenant threshold in Company Settings.

Migration

  • One, additive (20260901120000_so_credit_aging_01_allocated_at): SalesOrder.allocatedAt + Company.soAgingThresholdDays, with a backfill that reads each allocated order’s most recent ledger ALLOCATE row — recorded fact, not approximation; orders with no ledger row stay null and render “allocated before tracking”. Zero DROP/RENAME — code rollback to v2.15.0 is safe.

Other releases

See how DockingWare handles this →