How you would know any of it happened — transcript

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 the one that decides whether the rest of them are worth doing. You can run every tax-number tool in BigLedger correctly and still have no idea afterwards whether anything happened, because most of what would tell you is either empty by design or empty by accident. Twelve minutes on exactly what the screens report, what they do not, and the check you build yourself instead.

Step 1 — Stop waiting for the two boxes that never fill

After this step an empty screen will stop being a mystery. Open the bulk tax-number file listing and you see a Process Status column and an Error Message column, and File Details repeats both as fields. Neither is ever written. Nothing in the tax-number path sets a process status — the price-list and purchase-invoice imports both do, which is why the columns look like they should work here — and there is no error-message column on the underlying table at all, so that one can only ever render blank. They are not waiting for a run to finish. They will be empty after every run you ever do.

Reference: My E-Invoice Admin Applet — Bulk TIN Validation: what the upload actually starts

Step 2 — Find the one tab that does carry evidence

After this step you will know where to look. Open the uploaded file, then the Line tab, which lists your file back to you — a name, an e-mail address, a telephone number and a customer code per row. Open a line and there is a Queue tab. That is the real report. It holds one row for each entity matched to that line whose check failed or whose identity was incomplete, with a count of reminders sent beside it. Every row there is a customer you still need something from. It is a worklist, and it is the only one you are given.

Reference: My E-Invoice Admin Applet — Bulk TIN Validation: what the upload actually starts

Step 3 — Read an empty Queue tab honestly

After this step you will not mistake silence for success. A line with no queue row under it means one of two things and the screen cannot tell you which. Either every entity it matched was already complete and correct, which is good news, or the line matched nobody at all — a customer code with a typographical error, a name that no record holds, a column you left blank. Those two outcomes look identical. So when you spot-check a run, check a line you know should have failed, not one you hope succeeded. A worklist you cannot distinguish from an empty search is not a worklist yet.

Reference: My E-Invoice Admin Applet — Bulk TIN Validation: what the upload actually starts

Step 4 — Check that the half which writes to customers is switched on

After this step you will not wait a month for e-mails that were never going to arrive. The campaign is in two halves. The upload runs the moment you submit it and needs no scheduling. The half that reads the queue, re-checks each entity and writes to your customers is a scheduled job — and across ninety tenant databases measured in September it was scheduled on none of them. So today an upload builds the queue rows and then nothing touches them. Ask support to schedule it, and to set its four properties at the same time, because a missing one stops the whole sweep.

Reference: My E-Invoice Admin Applet — Troubleshooting

Step 5 — Know when a request stops existing

After this step your follow-up will be timed properly. Once the sweep is running, each queue row is chased at most once every two days, up to ten times, and the row is then deleted — or deleted after thirty days, whichever comes first, answered or not. Nothing records that the customer never replied. A customer with no e-mail address on their record is never written to at all and nothing tells you so. The practical consequence is simple: a campaign has a life of one month, and whatever it did not achieve in that month is invisible afterwards unless you wrote it down.

Reference: My E-Invoice Admin Applet — Bulk TIN Validation: what the upload actually starts

Step 6 — Build the before-and-after check yourself

After this step you will have a real report. There is no approval step anywhere in e-invoicing and no ageing alert on any pool or queue, so a routine that waits to be told something will quietly stop working. Do this instead. Before you start, export the customers whose tax number is blank and keep the file with the date on it. Run whatever you are running. A month later, export the same list and compare. The difference is your result — and it counts the numbers that arrived silently from the automatic search as well as the ones your customers typed, which no screen in BigLedger reports at all.

Reference: Best Practices — 5. Do not design a process around an approval or an alert

How the steps fit together

    flowchart TD
  s1["Step 1 — Stop waiting for the two boxes that never fill"]
  s2["Step 2 — Find the one tab that does carry evidence"]
  s3["Step 3 — Read an empty Queue tab honestly"]
  s4["Step 4 — Check that the half which writes to customers is switched on"]
  s5["Step 5 — Know when a request stops existing"]
  s6["Step 6 — Build the before-and-after check yourself"]
  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.

Back to the series · Play this as a presentation