What un-does a knock-off, and what each route leaves behind — transcript
Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.
This presentation is for whoever at GadgetSphere has to take a settlement back: the receipt was against the wrong invoice, the money never arrived, the invoice itself should not exist. In about twelve minutes you will learn what each of five routes does to a contra and to the quantity knock-off, which of them leave an invoice reading paid by a document that is no longer final, why a settlement never stops you voiding, and what no route un-does at all.
Step 1 — Know what voiding the receipt does to the settlement
After this step you will know what a void of a receipt actually removes. On a tenant that holds the contra reversal subscription, the void job finds every contra row the receipt takes part in, on either side, deletes them, and then re-sums the Contra and Balance figures of every document that was in one of them: the invoices go back to outstanding, and the receipt’s own balance returns to its full amount. This is a deletion, not a reversal: there is no opposite row left behind, and if a contra was cross-currency the exchange-difference journal it posted is deleted outright, never reversed. It happens inside the void job, not on a schedule. And it is a subscription: the void page’s test-document routine is how you learn whether your tenant holds it, because a minority post on Finalise without the void counterpart, and on those the receipt reads void and the invoice still reads paid.
Reference: What a Void Undoes — Shape 3 — removed: the row is taken away, not reversed
Step 2 — Know that voiding the invoice does the same from the other side, and that the settlement never blocks it
After this step you will not expect a payment to protect an invoice. The void refusal you meet most often lists the documents raised from this one and tells you to void them first. That refusal reads the document-link table, the knock-off between an order and the invoice raised from it, and a receipt never writes a row there; it writes a contra. So an invoice at GS-JB-02 that has been fully paid by contra can still be voided, unless e-invoicing has taken Void away from sales invoices altogether, and the void takes the settlement with it: every contra on either side of the invoice goes, and the receipt that paid it becomes an unapplied credit on the customer’s account again. Nobody is told. The money is still in the cash book, the receipt’s journal still stands, and the customer now has a credit that will be applied to something, or not, by whoever next opens the Contra tab.
Reference: What a Void Undoes — When BigLedger refuses to void at all
Step 3 — Know what delete-contra does, and does not
After this step you will reach for the smallest tool first. When the money is right and only the allocation is wrong, there is no need to void anything. A login holding the delete-contra permission sees a Delete button on the voucher’s Contra tab. It finds the mirror row by its negated amount, deletes both rows of the pair, re-sums both documents’ figures, and if the contra was back-dated, rebuilds the aging months it touched. Then you apply a new contra to the right invoice. Nothing else changes: no journal is touched, because a contra posted none; the cash book line and the bank reconciliation are untouched, because the receipt is untouched. It announces itself nowhere except the Contra tab. What it cannot do is reduce a contra without removing it; that exists only as an API operation gated on an administrator permission, so from a screen the choice is remove whole, or leave it.
Step 4 — Know what Undo to Draft leaves in place
After this step you will know why an undone receipt still shows as paying an invoice. Pulling a finalised document back to Draft publishes to exactly one subscriber, the knock-off open queue, so what it undoes is quantity linkage and nothing else. The journal stays posted, the cash book line stays, and the settlements stay too: pull a receipt back to Draft and every invoice it paid still reads paid, by a receipt that is no longer final. A processor that would set a document’s contras back to draft on undo is registered in the platform, and nothing publishes to it. Discard is the other button that is not a void: it releases contras and knock-offs, and it is refused outright on anything already FINAL or VOID, so it is a drafts-only route and it reverses nothing because a draft posted nothing.
Reference: What a Void Undoes — Undo to Draft releases links. It does not unpost anything
Step 5 — Know what the quantity knock-off gives back, and when
After this step you will know why the order’s balance comes back before the stock does. The third knock-off, the quantity an invoice took off a sales order, has its own subscriber on the void primary, and it is also the one subscriber the undo primary has. Void the invoice and the job marks the invoice’s document links deleted and gives the quantity back to the order’s open-queue row, re-creating the row if it had been deleted at zero, all inside the void job. So the order’s KO For tab shows the quantity outstanding again immediately, and available stock at the branch drops by that much at once, while the stock movement itself is being negated by a different subscriber a moment later. Undo to Draft does exactly the same for the quantity and nothing for the money, which is why an undone invoice can hold an order open and still show as paid.
Step 6 — Know what nothing un-does
After this step you will send three kinds of correction to the right place. First, the settlement line on the document itself, the money taken at the counter: that is Doc Open, not a contra, and no contra route touches it; a wrong method, reference or amount on a finalised receipt is corrected in Settlement Adjustment, and only voiding the document removes the line. Second, part of a contra: reducing without removing is API-only, so from a screen you remove whole and re-apply. Third, the historical aging: creating settlements in bulk rebuilds the months a back-dated contra touches, but correcting or voiding a single settlement updates the document and leaves the photograph of past months as it was, so last month’s aging can still show the invoice open after the contra is gone, and only a rebuild request changes that. Know which of the three you are holding before you press anything.
Reference: Recording a Customer Payment — If you got it wrong
How the steps fit together
flowchart TD
s1["Step 1 — Know what voiding the receipt does to the settlement"]
s2["Step 2 — Know that voiding the invoice does the same from the other side, and that the settlement never blocks it"]
s3["Step 3 — Know what delete-contra does, and does not"]
s4["Step 4 — Know what Undo to Draft leaves in place"]
s5["Step 5 — Know what the quantity knock-off gives back, and when"]
s6["Step 6 — Know what nothing un-does"]
s1 --> s2
s2 --> s3
s3 --> s4
s4 --> s5
s5 --> s6
Check yourself
Three to five questions on what you just heard. Every correct answer links to the page that makes it correct, so you can check the source, not just the mark.
Answer key
- Every contra on either side is deleted and both documents are re-summed inside the void job, so the invoices are outstanding again — What a Void Undoes — Shape 3 — removed: the row is taken away, not reversed
- Yes, unless e-invoicing has removed Void for sales invoices; the receipt becomes an unapplied credit — What a Void Undoes — When BigLedger refuses to void at all
- They still read paid; the undo has one subscriber and it is the quantity knock-off — What a Void Undoes — Undo to Draft releases links. It does not unpost anything
- Delete the contra from the Contra tab with the delete-contra permission, then apply a new one — I knocked it off and the outstanding balance hasn't changed — Four ordinary reasons Contra reads lower than you expected
Next: Reading a knock-off that half-worked · Back to the series · Play this as a presentation