Two doors, one machine, and no bell — transcript

Presentation 1 of 5 in Handle the e-invoice requests your buyers raise · about 9 minutes · for the whole-system operator — you run the books.

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 keep GadgetSphere’s books and buyers have started asking for e-invoices in their own names. There are two different ways that request can arrive, both run straight through the same machine without waiting for you, and one screen quietly writes every one of them down. About nine minutes, and by the end you will know which of your screens is really the inbox.

Step 1 — Know what your buyer is actually asking for

After this step you will know what is at stake in a request that looks trivial. A shopper who paid at a GadgetSphere counter and gave the cashier nothing has a receipt and nothing else. Their purchase is waiting to be reported once a month inside a single consolidated e-invoice, with the buyer written down as General Public and every identity and address field fixed at a value nobody can type over. They are not asking you to reprint anything. They are asking you to pull their receipt out of that monthly document and report it on its own, with their name and tax number on it.

Reference: Consolidated e-invoices — Why it exists

Step 2 — Tell the two doors apart

After this step you will know which door a request came through, which decides who the buyer is on your records. The first door is the customer portal: a buyer you gave a login to signs in, picks the account they are acting for, finds the receipt and supplies their details there. That is the door for corporate customers who buy from GadgetSphere Distribution every month, and their details are saved to their customer record. The second is a widget on the web store, open to anyone with a receipt and no account at all. That is the door for the walk-in shopper at a Klang Valley branch who went home and thought about it.

Screen: the storefront e-invoice widget’s search form beside the portal applet’s Request E-Invoice panel, opened one after the other

Reference: Storefront E-Invoice Request — Overview

Step 3 — Accept that both doors run without you

After this step you will stop waiting for a request to reach your desk. Whichever door the buyer used, the request goes straight into the same queue processor, and the processor does the work at once. There is no approval step and nobody on your side presses anything. The buyer’s name, identification and tax number are written onto the pool row, and if the row passes the mandatory-field check an e-invoice record is created and queued for the Inland Revenue Board of Malaysia, which you will see called LHDN. Nothing e-mails you, and nothing counts up on a dashboard. The work that is left for you is the request that did not go through.

Reference: Storefront E-Invoice Request — Lifecycle and effects

Step 4 — Find the register that writes every request down

After this step you will know where to look first. In the admin applet, under Internal Submission, there is a screen called Portal Request. Despite its name, it lists every request from both doors, portal and web store alike, with its date and whether the processing succeeded or failed. Read the list as a register: it does not correct anything. Opening a row lets you export it, or raise a rejection request once its e-invoice is eligible, but the fix for a failed request happens where it always happens — on the pool row, or on the e-invoice record.

Screen: Internal Submission → Portal Request, showing document numbers, amount and user request status

Reference: My E-Invoice Admin Applet — Screens and menus

Step 5 — Check the failures on a schedule

After this step you will have a habit that closes the gap the missing alert leaves. Open Portal Request on a fixed rhythm — daily during the month, and certainly before the consolidation runs — and look for requests that failed. A failed request from the Batch Pool is the one that costs you most. Its receipt has already been switched to an individual submission, its pool row now reads processed and failed, and the monthly consolidation will pass it by. Nobody will report that sale unless you fix what the pool row’s validation error names and resubmit it.

Reference: My E-Invoice Admin Applet — Troubleshooting

How the steps fit together

    flowchart TD
  s1["Step 1 — Know what your buyer is actually asking for"]
  s2["Step 2 — Tell the two doors apart"]
  s3["Step 3 — Accept that both doors run without you"]
  s4["Step 4 — Find the register that writes every request down"]
  s5["Step 5 — Check the failures on a schedule"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5

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.

1. A shopper completes the e-invoice request form on GadgetSphere's web store. What reaches you? An e-mail to the finance mailbox with the request attached
A row in an approval queue that you accept or decline
No alert — the request is processed at once and written down as a row on Portal Request

2. A corporate buyer raises a request through the customer portal. When is it processed? At once, by the same processor the web store uses, with no approval step
When someone in finance approves it on the Portal Request screen
At the next monthly consolidation run

3. A corporate customer who buys from you monthly wants to raise requests themselves. Which door is theirs? The customer portal, signed in against the account they act for
The web store widget, which is the only supported route
Neither — a business customer must e-mail your finance team

4. A request for a Batch Pool receipt failed. What happens to that sale at month-end if nobody acts? It is swept into the consolidated e-invoice as before
It is passed over — the row now reads processed and failed, so it is not consolidated and not reported
It is retried automatically every night until it succeeds

Answer key

No alert — the request is processed at once and written down as a row on Portal Request — Storefront E-Invoice Request — Lifecycle and effects
At once, by the same processor the web store uses, with no approval step — Storefront E-Invoice Request — Lifecycle and effects
The customer portal, signed in against the account they act for — MY E-Invoice Portal Applet — Overview
It is passed over — the row now reads processed and failed, so it is not consolidated and not reported — My E-Invoice Admin Applet — Troubleshooting

This is a self-check. Your answers are marked in your browser and stay there — nothing is sent anywhere, nothing is recorded, and the marking is readable in the page source, so it is not a credential. Open the answer key at any time.

Next: What one buyer’s request does to your month · Back to the series · Play this as a presentation

Last updated on October 7, 2026

Two doors, one machine, and no bell What one buyer's request does to your month