What runs on your tenant when nobody presses a button — 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 you if you keep the books and want to know what your tenant does on its own. In about eight minutes you will be able to say which clocks run for you and how to ask about the rest, how you would know a job ran, and which checks nobody will make unless you do.

Step 1 — Separate the button from the work it starts

After this step you will know why the screen comes back before the work is done. When you finalise a sales invoice at GS-KV-01, BigLedger writes one row into your tenant’s job queue and hands it to a background thread, and your screen returns at once. The journal, the stock movement, the queue that will pair the invoice with its payment, called knock-off, and the e-invoice row are separate jobs, each one your tenant has switched on, and they follow in the background, normally within seconds. Each is done by a job processor, a named routine the platform runs for you. Hold on to one consequence. When one of those jobs fails, the person who pressed Finalise has long moved on, so nothing appears at the till and nobody is e-mailed. The document simply looks normal.

Reference: How Work Actually Runs — Trace it once: what one Finalise actually starts

Step 2 — Tell a subscription from a clock

After this step you can say which of two kinds of automation you are looking at. The first kind is started by a document. When you finalise, the platform asks which follow-on jobs your tenant has switched on, and runs only those, so a group with no loyalty scheme never runs the points job. Those switches are called subscriptions, and no screen shows them. If you need to know whether yours posts journals or moves stock, that is a question for BigLedger. The second kind is started by the time. A clock is a row in the Scheduler applet: a job, a timetable written as a cron expression, and a status. This is the half you can see, and the half the rest of this series is about.

Reference: How Work Actually Runs — As publish-subscribe — and this one is literal, not a metaphor

Step 3 — Know which clocks came with your tenant

After this step you will know where your clocks came from. When a tenant is created, BigLedger inserts a set of default clocks, all active: the e-invoice submission and status passes every ten minutes, the consolidation pass every twenty, the stock-balance queue every fifteen, and the deposit rollover and the monthly aging snapshot on the first of the month. A default is inserted only where no clock with its code exists yet. So a default added to the list after your tenant was created is missing, unless BigLedger re-installs the defaults for you. GadgetSphere’s tenant is older than the monthly aging clock, and its listing has no row for it. A re-install adds only a default whose code has no row at all. Deleting a clock only hides it: its row stays, marked deleted, so a deleted default is never re-installed. To stop a default, set it to inactive; never delete it.

Reference: How Work Actually Runs — As a scheduler — cron, per tenant, with a run log

Step 4 — Read what the listing says, and what it does not

After this step you can read what each clock says about itself. Open the Scheduler applet. Each row shows the Scheduler Code, which names the job, a Scheduler Name, the Status and the Last Run Date. Only active rows are read. On every tick of the platform’s own clock, an active row with a code the scheduler recognises, whose next occurrence has passed, puts its job in the queue, or finds an identical one already waiting, and its Last Run Date moves to now. Read that date carefully. It says the clock fired. It does not say the job finished, or that it worked. A clock whose date is older than its timetable allows is worth opening. A clock whose date moves while its work never appears belongs to a job that is still waiting in the queue or failing, and only the job’s own output tells you which.

Reference: Scheduler — Lifecycle and effects

Step 5 — Check the four gates before you wait for a job

After this step you will stop waiting for jobs that cannot come. A job passes four gates before it does anything for you. Its code has to exist. The scheduler has to recognise that code. Your tenant has to hold an active clock or a subscription for it. And the job has to have done its work, which only its own output proves. The second gate is easy to miss, because the picker and the scheduler read different lists. The Select Processor picker, where you choose the job for a new clock, lists the platform’s own register of jobs, the same list whichever tenant you open it on. That register and the scheduler’s do not match. Some codes in the picker are names the scheduler does not recognise, and a clock for one is passed over on every tick without a word. Some jobs the scheduler can run are not in the picker at all.

Reference: How Work Actually Runs — Shipped, registered, scheduled, running — four different facts

Step 6 — Check that one document’s jobs happened

After this step you can prove, for one document, that the jobs behind it ran. Open a finalised purchase invoice from GS-PEN-01 and its Posting tab. It shows five statuses: Journal, Inventory, Membership Points, Cashbook and Tax. POSTED means that part is done. Blank on a final document means the job has not run or it failed, and the two look exactly the same. Where an applet carries a TraceDocument tab instead, an empty Journal Txn grid on a document that should have posted tells you the same thing. To find every document with a missing journal, open Ledger And Journal, then Error Checking, then Missing Journal, and choose a document type and a date range. To repair one, fix the cause first, then trace that document in the Financial Report applet and press Resolve.

Reference: How Work Actually Runs — How you know it worked

Step 7 — Make the checks nothing else will make

After this step you will know which checks are yours, because no screen will make them. A job that fails writes its error into a table that nothing in the product reads, so no alert, badge or e-mail ever arrives. On the queue your document postings go through, a job that failed is not tried again. One job does look back at your documents rather than at the queue: the inventory watchdog, which re-queues the stock posting of any final document still without one, and it runs only where somebody has added a clock for it. Nothing does the same for journals. So the month-end check is yours to own: Missing Journal for each document type you post, the Stock Flow Report’s inventory against accounting value, and a look down the Scheduler listing for dates that stopped moving.

Reference: How Work Actually Runs — What this will not do

How the steps fit together

    flowchart TD
  s1["Step 1 — Separate the button from the work it starts"]
  s2["Step 2 — Tell a subscription from a clock"]
  s3["Step 3 — Know which clocks came with your tenant"]
  s4["Step 4 — Read what the listing says, and what it does not"]
  s5["Step 5 — Check the four gates before you wait for a job"]
  s6["Step 6 — Check that one document's jobs happened"]
  s7["Step 7 — Make the checks nothing else will make"]
  s1 --> s2
  s2 --> s3
  s3 --> s4
  s4 --> s5
  s5 --> s6
  s6 --> s7
  

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: Add a clock, rehearse it, and prove it fired · Back to the series · Play this as a presentation