File a pending correction draft for a posted supplier debit note (human approves in Taokeh)
update_supplier_debit_note_draftFILES A PENDING DRAFT ONLY — NOTHING CHANGES UNTIL A HUMAN REVIEWS AND APPROVES IT IN TAOKEH. Propose a correction to a BUY-SIDE DEBIT NOTE already posted in Taokeh — a purchase return raised against a SUPPLIER's bill (Taokeh's /debit-notes page). This is NOT the sell-side debit note that create_debit_note_draft files (an additional charge on your own invoice); that document has no correction lane at all — the owner voids it and issues a new one. An ADMIN reviews this as a DIFF (current → proposed) and approves; only that tap re-books the note, and it keeps the SAME debit-note number, the bill it was raised against and any attached document. Pass debitNoteId, the note's REAL id from search_documents (docType debit_note). ROUTING — (1) THE RETURN NEVER HAPPENED (keyed twice, wrong bill): the owner VOIDS the note in Taokeh (Debit notes → the note → Void); voiding keeps it on the register marked VOID. (2) THE RETURN IS RIGHT BUT TYPED WRONG (a wrong line, quantity, cost, date or reason): THIS tool. (3) MORE GOODS WENT BACK LATER: a new debit note, raised by the owner in Taokeh — there is no AI lane for creating a buy-side debit note. WHAT YOU CAN CHANGE: dnDate, reason, and lines — the FULL REPLACEMENT SET. ⛔ EVERY LINE MUST ANSWER goodsReturned (true = these goods physically went back to the supplier and leave stock, false = money only). There is no default. Your answer only PRE-FILLS the admin's per-line question on the full review page; a ONE-TAP approval never moves stock and is refused whenever the note already took goods off the shelf or any line says goods went back. Stock only ever leaves for a product the BILL actually received, never more than the bill still has standing. SST is inherited from the bill — there is no tax code to send. WHAT YOU CANNOT, each refused by name: the SUPPLIER, the debit-note NUMBER, the BILL it was raised against. BLOCKED OUTRIGHT, checked when you file (the server runs the real correction and rolls it back) and again when the admin taps: the note is voided; it is validated or exported for MyInvois as a self-billed document; a supplier refund is allocated to it; the bill it was raised against is gone; its date is inside a LOCKED period; or the corrected note would credit more than the bill still owes. A proposal that changes nothing is refused. If the note is edited after you read it, the one-tap approval is refused — call revise_draft (kind 'supplier_debit_note_update').
Input Schema
| Name | Required | Description | Default |
|---|---|---|---|
| notes | No | A SHORT reviewer note: what was wrong, what you changed, and whether the goods really went back. | |
| proposed | Yes | ONLY what you want changed. An unknown or not-patchable key is refused by name. | |
| debitNoteId | Yes | REQUIRED — the posted BUY-side debit note's real id, from search_documents (docType debit_note). | |
| needsReview | No | Set true when something gave you pause. |