Subversion Repositories SmartDukaan

Last modification

• Rev 37797 2026-09-28 16:50:59
• Author: amit

• Log message:

  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.