What one buyer's request does to your month — transcript

Play this as a presentation — one slide per step, with the same narration. Every word of every step is on this page.

This lesson is for you if you would like to know exactly what happens inside BigLedger when one shopper fills in one form. It is about eleven minutes of following a single RM 4,300 laptop sale from a Klang Valley branch through the machinery, and it is worth it because the answer changes what your month-end report says.

Step 1 — Know what the receipt was going to be

After this step you will know the state the request interrupts. The cash bill for that laptop was finalised at the till with no buyer details, so it went to the Batch Pool and waited there. Left alone, it would have been swept into next month’s consolidation and reported inside one document covering thousands of GadgetSphere sales, under the buyer General Public with a fixed tax number, a fixed identity and every address field set to a placeholder. Each receipt inside that document is linked back to its source, but none of them carries a name. That is the default, and it is perfectly correct until somebody asks.

Reference: Consolidated e-invoices — How it behaves in BigLedger

Step 2 — Watch the submission type change underneath you

After this step you will understand the single most consequential thing a request does, which no screen announces. When the processor takes a batch-pool request, it writes the buyer onto the pool row and onto the sales document header, marks the pool row unprocessed again, and then sets the document’s e-invoice submission type to Individual. Your cash bill has just changed category. It is no longer a receipt destined for the monthly gathering-up; it is a document that will be submitted on its own, in the shopper’s name, and it will now be held to the full mandatory-field check that individual submissions face.

Reference: Storefront E-Invoice Request — Lifecycle and effects

Step 3 — Understand why a consolidated document is rebuilt

After this step you will know why a late request is more expensive than an early one, in machinery rather than in words. If the receipt has not yet reached a consolidated payload, the request is simply queued and processed. If it has already been gathered into one that is waiting to go, BigLedger queues a second job behind the first: a rebuild of that consolidated document without this receipt in it. The consolidation is reconstructed so the same sale is not reported twice, once by name and once anonymously. That rebuild is automatic, and it is the reason a request made before submission costs you nothing.

Reference: Storefront E-Invoice Request — Lifecycle and effects

Step 4 — Read the refusal, and know what it really means

After this step you will be able to explain a refusal that reads as though somebody else beat the shopper to it. Before queuing anything, the endpoint looks at the pool row. If a single-general or individual row already reads success, or a batch row reads success with nothing sitting in a consolidated queue, it refuses with a message saying the request was already made or submitted as consolidated. Success here means BigLedger has already built an e-invoice for the sale, individually or inside a consolidated one — not that the tax authority has accepted it, or even received it yet. Somebody may genuinely have asked first, so look the document up before you answer. The web store never shows this sentence anyway: its form says a request was already made for every failure of any kind.

Reference: Storefront E-Invoice Request — Lifecycle and effects

Step 5 — Know everything the request does not touch

After this step you will be able to reassure an anxious colleague, accurately. A request writes nothing to the general ledger. It creates no document line, moves no stock, touches no costing, and leaves the sale’s amount, tax and receivable in your books exactly as they were. What does change is on the e-invoice side: the buyer and the submission type on the document, a new e-invoice record queued for the Inland Revenue Board, one request record, and — when a rebuild runs — a consolidated e-invoice whose totals are now smaller by this receipt. Your books stay the same; your e-invoices change.

Reference: My E-Invoice Admin Applet — 9. What this applet writes

Step 6 — Expect your month to move by one receipt

After this step you will recognise this in your own reconciliation instead of investigating it. That laptop has moved from inside the consolidated total to its own individual e-invoice, and the consolidated total is smaller by RM 4,300 than the pool count would have led you to expect. Nothing is missing and nothing is duplicated. If you reconcile by counting receipts into the consolidation, a handful of buyer requests will make the count wrong every month, and the fix is to reconcile on the documents rather than on the pool.

Reference: Storefront E-Invoice Request — Lifecycle and effects

How the steps fit together

    flowchart TD
  s1["Step 1 — Know what the receipt was going to be"]
  s2["Step 2 — Watch the submission type change underneath you"]
  s3["Step 3 — Understand why a consolidated document is rebuilt"]
  s4["Step 4 — Read the refusal, and know what it really means"]
  s5["Step 5 — Know everything the request does not touch"]
  s6["Step 6 — Expect your month to move by one receipt"]
  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: Read the buyer’s screen before you answer · Back to the series · Play this as a presentation