Stop a settled debit note being received a second time
A return settled before the receive workflow (first purchase_return_order
2026-03-16) wrote the warehouse SALE_RET scan, a returnorderinfo row and a
wallet refund, but never touched the debit note: it stayed CREATED with no
purchase_return_order. Those are exactly the two things the receive screens
read, so 5,557 fully settled notes looked like they were still awaiting
receipt, Receive button included.
Receiving one of them (DN UPBLY975/4, IMEI 864973083197734, Antu Enterprises)
restored to the partner a phone that had already been returned, refunded
Rs 38,999 and resold to another partner, and a duplicate debit note followed
that Finance could not refund.
- receiveDebitNoteItems: refuse a note that already has a return order, one
whose status is not CREATED, and one whose every unit is already back at the
warehouse. Checked BEFORE the condition-mismatch gate - a mismatch there
returns into rejectOnConditionMismatch without reaching any later check, and
acknowledging that rejection hands the stock back to the partner. That is
how the Antu case slipped through.
- getAlreadyReturnedDebitNotes: the last of those checks, batched for a page of
notes. Mirrors applyReceipt - SALE_RET/DOA_IN/SALE_RET_UNUSABLE for the unit
against the order its invoice was billed on - so a screen can never disagree
with what the refund step will accept.
- processInvoiceReturn: one open return per document.
- sql/backfill_debit_note_status_old_flow_20260924.sql: APPLIED on hadb1
2026-09-24. 4,154 notes -> APPROVED, 6,639 items -> RETURNED, on the same
evidence (returned and refunded). Open notes 5,557 -> 1,404; the rest are
left CREATED for review, bucketed in fofo._dn_backfill_20260922.