Three status columns on a Batch Pool row, and only one of them decides anything — 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 opens the Batch Pool on the second of the month, sees thousands of red rows going back weeks, and needs to know whether any of last month’s takings reached LHDN. In about ten minutes you will be able to read those rows the way the software reads them, and say which ones are your problem.

Step 1 — Read the row the way the run reads it

After this step you will stop trusting the colour. A Batch Pool row carries three separate status columns, not one. There is a process status, which says whether anything has finished with this row. There is a queue status, which says how the last attempt on it went. And there is the ordinary record status, active or deleted, which the screen never shows you. The listing paints a row red from the middle one — the queue status. The monthly consolidation run reads the first one, the process status, and nothing else. Those are two different questions, asked of two different columns, and the answer to one tells you nothing about the answer to the other.

Reference: My E-Invoice Admin Applet — 3. Pools — what the buttons do

Step 2 — Understand why the row was born failed

After this step the red will look ordinary. Before a sale can go to LHDN as an individual e-invoice, BigLedger checks a long list of fields on the buyer — a name, a tax number, an identity type and value, an address with a first line, a city and a state, a contact number of the right length. A walk-in customer who bought a phone charger gave you none of that. The check fails, the sale is routed to the Batch Pool, and the reason it failed is written onto the row as its queue status and its validation error. So the red is not a report that something went wrong. It is the record of why this receipt belongs in the monthly batch in the first place.

Reference: My E-Invoice Admin Applet — 2 posting queue to irb or a pool cron e_invoice_generic_document_to_irb_processor

Step 3 — Hear what the consolidation run actually asks for

After this step you will know the whole selection. When the automatic run wakes up it asks the Batch Pool four things: give me rows whose process status is unprocessed, of a sales document type, dated in a particular month, a hundred of them. That is the entire request. It does not ask about the queue status. It is not that the software cannot — the query it uses supports filtering on queue status, and other screens do exactly that. The run simply never fills it in. An unprocessed row that is red and an unprocessed row that is clean are, to the run, the same row, and both are collected on the same tick.

Reference: My E-Invoice Admin Applet — 3. Pools — what the buttons do

Step 4 — See why a consolidated e-invoice does not need what the red is missing

After this step the design will make sense rather than look like an oversight. The fields the validation error is complaining about are the buyer’s. A consolidated e-invoice does not have that buyer. It is issued to the General Public tax number, with a fixed classification and a monthly billing period, and it lists your receipts by their document numbers. None of the missing buyer details would appear on it even if you had them. That is why the run is right to ignore the queue status: the check that failed was the check for a document the software is no longer trying to build. Reading the red as a blocker is reading a note about the road not taken.

Reference: Pools and queues — How it behaves in BigLedger

Step 5 — Know which state really is stuck, and how rare it is

After this step you will know what you are hunting for. There is one Batch Pool state that genuinely goes nowhere, and it is processed and failed. Processed means something has finished with the row; the run only ever collects unprocessed ones, so a processed row is past it, whatever the queue status says. Across BigLedger’s whole customer base, measured this month, rows sitting unprocessed and failed number in the hundreds of thousands, and rows sitting processed and failed number about a hundred in total, a handful per company. The state you have been taught to fear is the rarest one on the screen, and the wall of red in front of you is almost certainly not it.

Reference: My E-Invoice Admin Applet — 3. Pools — what the buttons do

Step 6 — Run the thirty-second check

After this step you have a habit that fits in a coffee break. Open the Batch Pool and do two things. Filter on process status, not on the red: everything unprocessed is in the queue for collection and needs nothing from you, however alarming the validation errors look. Then sort what is left by transaction date, oldest first, and look at the top of that list. Anything processed, and anything dated before last month, is work. Everything else is the system doing its job. If both of those come back empty you are finished, and you did not have to open a single row.

Reference: E-Invoice Pools & Submission Routing — What success looks like

How the steps fit together

    flowchart TD
  s1["Step 1 — Read the row the way the run reads it"]
  s2["Step 2 — Understand why the row was born failed"]
  s3["Step 3 — Hear what the consolidation run actually asks for"]
  s4["Step 4 — See why a consolidated e-invoice does not need what the red is missing"]
  s5["Step 5 — Know which state really is stuck, and how rare it is"]
  s6["Step 6 — Run the thirty-second check"]
  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: The one month the consolidation run can see, and the months it cannot · Back to the series · Play this as a presentation