The button that strands a row, and the guard that is only on its neighbour — 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 is about to tidy up the Batch Pool. There are two buttons above that grid that look like housekeeping and are not, and in about eleven minutes you will know exactly what they write, when to use them, and why a batch of rows that was perfectly healthy this morning can be stuck by lunchtime.

Step 1 — Learn what the two buttons actually write

After this step you will treat these buttons as writes, not as checks. Process and Save and Resubmit do the same thing to a Batch Pool row. They run the individual e-invoice check on the underlying document, write the result into the row’s queue status — success or failed — and then set the row’s process status to processed. That last write happens either way. It is not conditional on the check passing; there is no branch in which the row is left alone. Whatever you selected, however it turned out, every row you pressed the button on comes back processed, and processed is the only state the monthly consolidation refuses to collect.

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

Step 2 — Watch a healthy row become a stuck one

After this step you will recognise the moment it happens. A cash bill from a walk-in customer sits in the Batch Pool, unprocessed and red, waiting for next month’s consolidation. Somebody who has been told that red is bad selects a page of these and presses Process. The check runs again, and fails again — of course it does, the customer’s tax number is no more available today than it was last week. The row is written failed, and then it is written processed. Nothing is broken, nothing is reported, no message says what has changed, and the row that was going to be consolidated automatically has just been taken out of the run by the person trying to help it.

Reference: The Month-End E-Invoice Cycle (1st to 7th) — Step 2: Check the Batch Pool for rows that will not be swept

Step 3 — Notice the guard that is on the neighbour and not here

After this step you will know how confident to be. The button next door behaves differently. Consolidate re-reads your selection, keeps only the rows still unprocessed, and refuses outright if none of them is. Somebody clearly thought about the state of a row before acting on it. Process has no such filter: every row you selected goes through, whatever state it is in. The grid used to help — the rule that only allowed an unprocessed row to be ticked is still in the code, commented out — so today nothing on the screen stops you selecting a row that has already been dealt with. The care exists; it is just not on this button.

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

Step 4 — Know when pressing it is exactly the right thing

After this step you will not be afraid of the button, which would be the wrong lesson. Process and Save and Resubmit exist for a real job: you have obtained the buyer’s details, you have corrected the customer record, and you want this receipt to go out as its own e-invoice in that customer’s name rather than disappear into the monthly batch. Open the row, complete the fields the validation error names, and press Save and Resubmit. The check passes, an e-invoice record is created, a submission queue row goes with it, and the sale is reported individually. That is the button working. The harm only comes from pressing it on rows you have not changed.

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

Step 5 — Avoid the second way it bites

After this step you will leave finished rows alone. There is a worse version of the same mistake. A row that reads processed and successful has already been dealt with — its receipt is inside a consolidated e-invoice, or already has one of its own. Press Process on that row and the check runs from scratch, with no memory of what came before; if the buyer details have since been completed on the customer record, it passes, and a second e-invoice record is created for a sale that is already reported. That is one of the named causes of the same sale appearing in two valid e-invoices at LHDN, and unpicking it means a cancellation inside seventy-two hours or a credit note after.

Reference: My E-Invoice Admin Applet — Troubleshooting

Step 6 — Adopt the rule that makes all of this easy

After this step you have one sentence to work by. Only press Process or Save and Resubmit on a row you have just changed. If you have not opened the customer record and completed something, there is nothing new for the check to find, and the only thing the press can achieve is to take the row out of the automatic run. Work the pool the other way round: start from the validation errors, fix the master data that matters, and press the button on those rows alone. Everything you did not touch stays unprocessed, stays collectable, and is somebody else’s month-end — the software’s.

Reference: The Month-End E-Invoice Cycle (1st to 7th) — Step 2: Check the Batch Pool for rows that will not be swept

How the steps fit together

    flowchart TD
  s1["Step 1 — Learn what the two buttons actually write"]
  s2["Step 2 — Watch a healthy row become a stuck one"]
  s3["Step 3 — Notice the guard that is on the neighbour and not here"]
  s4["Step 4 — Know when pressing it is exactly the right thing"]
  s5["Step 5 — Avoid the second way it bites"]
  s6["Step 6 — Adopt the rule that makes all of this easy"]
  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: Getting a stranded Batch Pool row back, and the four things that will not do it · Back to the series · Play this as a presentation