Can your tenant unpost what it posts? — 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 owns the books at GadgetSphere and has to answer for a number. In about eleven minutes you will know how to prove that your own tenant reverses everything it posts, and how to read a void that has only half happened.

Step 1 — Know that the void list is a subscription, not a code path

After this step you will stop assuming the manual applies to you. Voiding a document queues one primary job, and that job looks up which secondary processors are subscribed to it on your tenant and queues one for each. The platform registry offers ten: the journal, the tax, the stock ledger, the cash book, the knock-off queue, the contra, the loyalty points, the customer spending limit, the cash transfer and the warehouse picking queue. Which of them actually run is a row in your own database. There is no screen anywhere in the product that shows you your own list, so this is a question for your BigLedger contact.

Reference: What a Void Undoes — What actually happens when you press it

Step 2 — Know that posting and unposting are two separate subscriptions

After this step you will know the question worth asking. Subscribing to the processor that posts a journal on Finalise and subscribing to the one that reverses it on Void are two different rows, and nothing provisions them together. Measured across every tenant database, roughly one tenant in seven that posts a journal has no journal reversal subscribed at all. For stock it is about one in five, for the cash book about one in eight, and for loyalty points it is close to half. On those tenants the Void button still works, the document still reads void, and the journal is still posted, because nobody is subscribed to unpost it.

Reference: What a Void Undoes — Which of the ten run on your tenant, and where the two lists differ

Step 3 — Read the Posting tab, because a document has more than one status

After this step you will have a routine you can run on any document. A document does not have one posting status. It has one per subsystem — journal, inventory, cash book, tax, membership and more besides — and they move independently. That is precisely what makes a half-finished void diagnosable. Open the document, open its Posting tab, and read the columns. Every one of them saying void means the chain finished. Some still saying posted means part of it has not. All of them blank means nothing was ever posted in the first place, so there was nothing for the void to undo.

Reference: What a Void Undoes — What success looks like: the thirty-second check

Step 4 — Separate a job that failed from a job that never existed

After this step you will stop treating two different problems as one. A column still reading posted after a void has exactly two causes and they need opposite responses. Either the reversal job ran and threw, or no such job was ever queued because your tenant has no subscriber for it. The Posting tab cannot tell them apart, and Trace Document can: a job that failed leaves a record with a message, and a job that was never queued leaves nothing at all. One of those you fix by correcting a mapping and pressing Resolve. The other is a conversation about your tenant’s configuration.

Reference: Sales Invoice (Internal) — Troubleshooting

Step 5 — Know why nothing retries the failure for you

After this step you will stop waiting for a recovery that is not coming. A worker claims a queued job by deleting the row and taking the deleted data back in the same statement, then runs the handler on it. If the handler throws there is no row left to retry: the failure is written to a separate error table carrying the event code and the document, and nothing re-drives it. So a reversal that failed stays failed until somebody looks. That is why the thirty-second check is worth running on the first void you do after any change to a company, a mapping or a subscription.

Reference: How Work Actually Runs — As a queue — work waits in a table, and a worker claims it

Step 6 — Prove it once, with a test document

After this step you will have the answer for good rather than for today. Key a small document in a quiet company, finalise it, wait for the chain, void it, wait again, and read the Posting tab. If every subsystem that reached posted has come back to void, your tenant reverses what it posts and you never have to ask again. If one of them sticks, you have found it on a document that costs nothing rather than on a customer’s invoice at month-end. Do it once per company, and repeat it after anyone changes what your tenant subscribes to.

Reference: What a Void Undoes — What success looks like: the thirty-second check

How the steps fit together

    flowchart TD
  s1["Step 1 — Know that the void list is a subscription, not a code path"]
  s2["Step 2 — Know that posting and unposting are two separate subscriptions"]
  s3["Step 3 — Read the Posting tab, because a document has more than one status"]
  s4["Step 4 — Separate a job that failed from a job that never existed"]
  s5["Step 5 — Know why nothing retries the failure for you"]
  s6["Step 6 — Prove it once, with a test document"]
  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.

Next: Undo to Draft is not a rewind · Back to the series · Play this as a presentation