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 conditions, and the one that is a date
After this step you will be able to say in one sentence what recovery means here. The automatic run that builds consolidated e-invoices looks for Batch Pool rows on four conditions: a sales document type, unprocessed, not deleted, and, unless your schedule names another month, dated last month. It does not care whether the receipt once had an e-invoice number, or whether that e-invoice has been cancelled. It takes qualifying rows a hundred at a time, on whatever schedule the tenant runs. So recovery reduces to one question, whether these receipts have a Batch Pool row that is unprocessed and not deleted, plus one date check. After a cancellation the answer is no, and nothing changes it by itself. And if the receipts are older than last month, even a new row waits until somebody presses Consolidate.
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, apart from a buyer’s own e-invoice request, which resets a row only for a moment and leaves it processed again. 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 an immediate repeat is safe: 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 while the first new row is still open does not produce two pool rows. Once that row has been consolidated, the guard no longer sees it, so before any later repeat, check the documents have not already reached a new e-invoice. Neither of these endpoints appears in any applet, which is why this is a support action rather than a button. 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 that exactly those are consolidated. If the month is older than last, the new rows then need Consolidate pressed by hand. 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. As soon as the pushed rows have been consolidated and sent, 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. This recovery works when somebody follows it through. The receipts that stay unreported are the ones nobody checked.
How the steps fit together
flowchart TD
s1["Step 1 — Know the conditions, and the one that is a date"]
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 a sales row, unprocessed, not deleted and, by default, dated last month — the run does not look 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
- While the first new row is still open, a document that holds it 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