Getting the receipts reported again, and asking for it in the right words — 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 now has to get four hundred cash bills reported after the consolidated e-invoice that carried them was cancelled. In about twelve minutes you will learn the two conditions that decide whether a receipt is ever collected again, which of two similarly named tools does the job, and exactly what to write in the request.
Step 1 — Know the two conditions, and stop looking for a third
After this step you will be able to say in one sentence what recovery means here. The run that builds consolidated e-invoices looks for Batch Pool rows on two conditions, and only two: the row must be unprocessed, and it must not be deleted. It does not care what month the receipt is from, whether it once had an e-invoice number, or whether the e-invoice that number belonged to has been cancelled. It sweeps every qualifying row, a hundred at a time, on whatever schedule the tenant runs. So the whole of recovery reduces to a single question — do these receipts have a Batch Pool row that is unprocessed and not deleted? After a cancellation the answer is no, and nothing changes it by itself.
Reference: My E-Invoice Admin Applet — 3. Pools — what the buttons do
Step 2 — Do not expect the old row to be revived
After this step you will stop hoping. It is a reasonable guess that cancelling would reopen the Batch Pool rows the submission closed, and it is worth knowing that it was checked properly rather than assumed. Every place in the BigLedger backend that sets a Batch Pool row to unprocessed does so on a row it has just created; not one of them reaches for a row that already exists. There is no reset, no undelete, no recovery sweep and no scheduled repair. The used row stays used for ever. That is why the fix is always a new row rather than a revived one, and why it can be done safely more than once — a new row for a receipt that already has an open one is refused.
Step 3 — Tell the two endpoints apart, because their names lie
After this step you will never let the wrong one be tried. BigLedger has two endpoints whose names both promise the batch pool. One is push invalid to batch pool, and it takes e-invoice record identifiers: for each one it finds that record’s source document and gives it a pool row. That is the right tool for an individual e-invoice that failed. Hand it a consolidated e-invoice and it finds no source document, skips it, writes nothing at all — and still answers with a cheerful processed invalid submission documents to batch pool. The other is push gendoc to batch pool, and it takes document identifiers. That one is the tool for this job, because the documents are the thing you actually have.
Step 4 — Understand why the right tool is safe to ask for
After this step you will ask without worrying about double-reporting. Push gendoc to batch pool creates one fresh pool row per document you name, and before it creates any of them it checks whether that document already holds an open pool row. If it does, the document is skipped and reported back in the response as skipped, with the row that already holds it. So asking twice does not produce two pool rows, and two pool rows is precisely the fault that would put one cash bill into two consolidated e-invoices. Neither of these endpoints appears in any applet, which is why this is a support action rather than a button: there is no screen anywhere in BigLedger that does it. That is the reason the guide says to ask, not the reason to be nervous about asking.
Step 5 — Ask for named documents, never for a re-run
After this step your request will be unambiguous. There is a wrong version of this request that sounds identical: please re-run consolidation for March. That instruction is not the same job — the run would gather everything in range that has an open pool row, which on a busy month means documents you never meant to touch, grouped into e-invoices you did not ask for. Write instead: the consolidated e-invoice for March was cancelled; please push the documents that were inside it back to the batch pool, by document, so the next consolidation run picks up exactly those. Attach the cancelled e-invoice’s number, and the list of documents you took from its drill-down. Support has everything it needs and nothing to interpret.
Step 6 — Know about the route that exists and that you cannot press
After this step you will understand a gap rather than be surprised by it. BigLedger already contains a route that does this whole job in one action. Resubmit as New E-invoice has a branch for consolidated records that mints a new e-invoice, relinks every member document to it, rebuilds the pool links and queues it for submission, and it refuses only records that are still Valid — a Cancelled one is eligible. The button, though, is only drawn when the record reads Invalid or Submitted, and only when a master setting is turned on, so a Cancelled consolidated record can never reach it from that screen. It is worth mentioning in your request, because it is a one-step answer to a job otherwise done by hand.
Reference: My E-Invoice Admin Applet — 5. Fixing an Invalid e-invoice from To IRB E-Invoice
Step 7 — Check the work, and close the month honestly
After this step you will know when you are actually finished. A week later, open the documents that were inside the cancelled e-invoice and look at the e-invoice number on any one of them: if recovery worked, it now shows a different number belonging to a Valid consolidated e-invoice, not the cancelled one. Confirm that new e-invoice reads Valid, and confirm its document count matches what you asked for. Across BigLedger’s customers this recovery does happen and does work — roughly two thirds of the receipts behind cancelled consolidated e-invoices end up on a later one. The other third never do, and the difference between the two groups is entirely whether somebody checked.
How the steps fit together
flowchart TD
s1["Step 1 — Know the two conditions, and stop looking for a third"]
s2["Step 2 — Do not expect the old row to be revived"]
s3["Step 3 — Tell the two endpoints apart, because their names lie"]
s4["Step 4 — Understand why the right tool is safe to ask for"]
s5["Step 5 — Ask for named documents, never for a re-run"]
s6["Step 6 — Know about the route that exists and that you cannot press"]
s7["Step 7 — Check the work, and close the month honestly"]
s1 --> s2
s2 --> s3
s3 --> s4
s4 --> s5
s5 --> s6
s6 --> s7
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
- It must be unprocessed and not deleted — the run does not look at the month or at any previous e-invoice — My E-Invoice Admin Applet — 3. Pools — what the buttons do
- It writes nothing and still answers as though it had succeeded — My E-Invoice Admin Applet — After a consolidated cancellation: where the receipts are, and what puts them back
- A document that already holds an open pool row is skipped and reported back as skipped, so no second row is created — My E-Invoice Admin Applet — After a consolidated cancellation: where the receipts are, and what puts them back
- A receipt from that month now carries a different e-invoice number, belonging to a Valid consolidated e-invoice — My E-Invoice Admin Applet — After a consolidated cancellation: where the receipts are, and what puts them back