Process Request: what one click sets off, and what comes back — 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 presses Process Request at GadgetSphere and wants to know what that click actually does before pressing it. In about eleven minutes you will follow one request from the moment it is approved to the moment the screen comes back, see what BigLedger checks, what it sends LHDN, what a success writes and what a failure leaves behind, and learn why the confirmation e-mail is not coming to you.

Step 1 — Know that a request is a record, and your click is the only thing that moves it

After this step you will stop expecting the system to do anything with a request you have raised. Request for Rejection on a Valid e-invoice writes one row: requested, in progress, with the reason you typed. Approving it writes an approval status and a processing logic onto that same row, and nothing else happens. There is no processor behind it, no scheduled run, no callback from LHDN; a request left alone stays exactly as you left it until the seventy-two hours are gone. That is not a gap, it is the design: a cancellation is a compliance action, and the platform will not take one on your behalf. Across the estate the commonest state a request is found in is raised and never approved, on more than a dozen tenants. Every one of those was somebody who thought the row would move by itself.

Reference: My E-Invoice Admin Applet — 6. Cancellation (Rejection Requests → Cancellation Queue)

Step 2 — Know that Process Request calls LHDN inside your own click

After this step you will understand why the screen pauses. Process Request does not queue anything for later. In the same request your browser sent, BigLedger takes every request that is approved, in progress and carries a logic, builds a Cancellation Queue row for each, and runs it there and then. For each row it checks three things before it goes anywhere near LHDN: the e-invoice record must read Valid, it must carry LHDN’s document identifier, and fewer than seventy-two whole hours must have passed since the validation time on the record. Pass all three and BigLedger sends LHDN a single instruction, put the document into the state cancelled, with the reason text from your request attached word for word. The answer is back before your screen is. Nothing waits for a scheduled run, which is why there is nothing to watch for afterwards.

Reference: My E-Invoice Admin Applet — 6. Cancellation (Rejection Requests → Cancellation Queue)

Step 3 — Read what a success writes

After this step you will recognise a successful cancellation by what has disappeared. When LHDN accepts, BigLedger does not simply mark your record; it asks LHDN for the document again and writes back what LHDN now says, Cancelled, together with the cancellation time, onto the e-invoice record and onto every submission history row that carries that identifier. Then it deletes the Cancellation Queue row outright, and marks the request completed with a cancellation status of Cancelled. So GadgetSphere’s laptop invoice, cancelled at ten past nine, shows three things by eleven past: the record reads Cancelled on To IRB E-Invoice, the queue is empty of it, and the request is closed. The bill’s own E-Invoice tab reads the same record, so it agrees without anyone refreshing anything.

Reference: My E-Invoice Admin Applet — 6. Cancellation (Rejection Requests → Cancellation Queue)

Step 4 — Read what a failure leaves behind

After this step you will read a failure from the row it leaves. A cancellation that did not go through leaves its Cancellation Queue row in place, at submission failed, and that row is the whole story: the address BigLedger called, the body it sent, the body that came back, and a Request Error. The error is one of BigLedger’s own three sentences if a pre-check stopped it, not validated, e-invoice is not generated yet, passed seventy-two hours from validation date time, or LHDN’s own response text, verbatim, if the call was made and refused. The request itself is marked completed either way, with a cancellation status of FAILED. That word completed matters in Step 6. A queue row you can still see is, by construction, a cancellation that did not happen.

Reference: My E-Invoice Admin Applet — 6. Cancellation (Rejection Requests → Cancellation Queue)

Step 5 — Know where the e-mail goes, and stop waiting for it

After this step you will not sit by your inbox. BigLedger does send an e-mail for every outcome, success, failure, not eligible, and every one of them is addressed to the buyer’s e-mail address on the e-invoice record, not to the person who pressed the button. It opens Dear User and says whether the cancellation request for that invoice number succeeded or failed, and on some failures adds a recommendation about your own next step. If the record has no buyer e-mail, as a walk-in receipt usually does not, the send fails and the failure is written to a log nobody at GadgetSphere reads, after the statuses have already been saved. So the e-mail is a courtesy to your customer at best and silence at worst. Your notification is the Cancellation Queue: a row that is gone succeeded, a row that stays carries the reason.

Reference: Cancelling and Correcting a Validated E-Invoice — Step 4: Send the cancellation to LHDN

Step 6 — Retry the right way

After this step you will know why pressing Process Request twice does nothing. Process Request only takes requests that are still in progress, and a request that has failed is already marked completed, so it is invisible to that button forever. The retry lives on the other screen. Correct whatever was wrong on the request first, most often the processing logic, then go to Cancellation Queue, select the failed row, and use Process. That re-runs the row and reads the request’s logic as it is now, not as it was. It is how a consolidated e-invoice refused with can not void the generic document gets cancelled after all: change the logic to cancel for edit and resubmit, then process the row. What you cannot do is process a row for a request whose seventy-two hours have meanwhile expired; the next presentation is about that clock.

Reference: My E-Invoice Admin Applet — Troubleshooting

How the steps fit together

    flowchart TD
  s1["Step 1 — Know that a request is a record, and your click is the only thing that moves it"]
  s2["Step 2 — Know that Process Request calls LHDN inside your own click"]
  s3["Step 3 — Read what a success writes"]
  s4["Step 4 — Read what a failure leaves behind"]
  s5["Step 5 — Know where the e-mail goes, and stop waiting for it"]
  s6["Step 6 — Retry the right way"]
  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: Four choices, and what each one tells LHDN · Back to the series · Play this as a presentation