Reading the Email Dashboard and the e-mail thread — what a row is evidence of, and the rows that never move — 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 gets the call that says “we never received the e-invoice”, and has the My E-Invoice Admin applet open. In about nine minutes you will know which three screens hold the evidence, how to read a queue row without being misled by a blank error column, why a queue can be full and moving nowhere, and how to send the customer their copy and prove it went.

Step 1 — Know the three screens

After this step you will not search the submission screens for an e-mail. Three places show it. The Email Dashboard, in the menu under that name, has two tabs: Email Printable Queue, the live queue with the process status, e-mail status, retry count, error code and message, the receiver’s address and the buyer’s name; and Email Printable Queue History, every attempt that was sent or failed. The second place is the To IRB record itself, where an Email tab lists the e-mail threads for that one e-invoice, each with its recipient, subject, body and the PDF as it was attached. The third is the Resend Email tab beside it, shown only once the header is Valid. The dashboard answers “is anything stuck”; the record answers “what did this customer get”; the resend tab is the only action.

Reference: My E-Invoice Admin Applet — The three screens

Step 2 — Read a queue row for what it is evidence of

After this step a queue row will tell you which of three situations you are in. The processor takes rows that are in queue with fewer than six failed attempts, oldest first, ten at a time. A send that succeeds writes a history row and deletes the queue row, so the healthy state of this queue is empty. A send that fails writes the error onto the row and adds one to the retry count, and after six the row drops out of the selection with its error still visible. That is a delivery problem and the error names it. The third situation is the one that misleads: a row in queue, retry zero, error blank, older than several runs. That row was not attempted and did not fail. It was selected and skipped, either because its company’s switch is off, or because the company has no e-mail identity, and the skip writes nothing.

Reference: My E-Invoice Admin Applet — How the queue moves, and how it stops

Step 3 — Understand why a full queue can be moving nowhere

After this step you will recognise a frozen queue from the dashboard alone. Because a skipped row keeps retry zero, it is selected again on the next run, and the run after. It is always among the oldest, so it is always in the ten. Once ten skipped rows are older than everything else, they are the ten, every run, and no row behind them is ever reached, for any company on the tenant. A group with several companies feels this hardest: one company that never wanted e-mails, or one that was never set up, silently stops the e-mails of every company that did. Measured across the estate on the day this was written, eighteen of ninety tenants were in exactly that state, with about ten thousand documents at switched-on companies waiting behind. The sign is simple: the oldest rows on the dashboard are days old, retry zero, error blank, and the newest never change status.

Reference: My E-Invoice Admin Applet — How the queue moves, and how it stops

Step 4 — Download exactly what the customer received

After this step you will settle a dispute with the file rather than a description. Open the To IRB record and its Email tab. Each thread is one conversation about that e-invoice; each content row inside it is one message, with the address it went to, the subject, the body as sent, and the PDF attached to it stored as a file you can download. That attachment is the customer’s copy, rendered at the moment of sending with the template and the header as they were then. If a customer says the PDF they have shows an old address, this is where you confirm it in thirty seconds. A content row marked draft with no send time is a different story: it was created when the row was queued and the e-mail never went, which is the thread-level view of the skipped row from the previous step.

Reference: My E-Invoice Admin Applet — The three screens

Step 5 — Resend, and read the thread rather than the toast

After this step you will resend correctly and know when it worked. On a Valid header, the Resend Email tab sends the PDF again to the buyer e-mail on the header, or to any additional recipient addresses you add, which is how you send a copy to yourself or to a customer’s accounts inbox without editing the header. The backend answers for each address, sent success or sent failed. The screen does not show that answer. It shows a green Email Sent for any reply at all, including the reply that says every address failed, and including a company that has no e-mail identity, where nothing was attempted. So after resending, open the Email tab and look for a new content row with a send time. That row is the proof. Its absence, after a green toast, is the diagnosis: nothing was sent, and the cause is one of the three things from the previous presentation.

Reference: My E-Invoice Admin Applet — The three screens

How the steps fit together

    flowchart TD
  s1["Step 1 — Know the three screens"]
  s2["Step 2 — Read a queue row for what it is evidence of"]
  s3["Step 3 — Understand why a full queue can be moving nowhere"]
  s4["Step 4 — Download exactly what the customer received"]
  s5["Step 5 — Resend, and read the thread rather than the toast"]
  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.

Next: Your customer’s PDF does not look like yours: the diagnosis, in the order that costs least · Back to the series · Play this as a presentation