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 rejection message 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 succeeded, or a batch row succeeded with nothing sitting in a consolidated queue, it refuses with a message saying the request was already made or submitted as consolidated. Usually nobody else made any request at all. The sentence means the sale has already been reported, so there is no pool row left to change — and from there only you, from the pools, can do anything about it.

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 in one sentence. A request writes nothing to the general ledger. It creates no document line, moves no stock, touches no costing, changes no amount, no tax and no receivable. The sale that happened at the till is exactly the sale that happened at the till. All that changes is which shape it takes on its way to the Inland Revenue Board, plus one request-header row recording that somebody asked and what happened. The whole e-invoice applet works this way: it reports your documents, it never posts them.

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. On your monthly comparison, 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: The Month-End E-Invoice Cycle (1st to 7th) — Step 7: Reconcile, and understand the five reasons a tally does not balance

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