One press, and a fan-out you did not configure — 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 for the person at GadgetSphere who has to explain why the same invoice posts a journal in one company and not in another. In about fourteen minutes you will know what the primary processor does, the three filters that decide what actually runs, how deep the chain goes, and the one failure that can silence the whole thing.
Step 1 — Meet the processor whose only job is to start others
After this step you will have the shape. The queue row that Finalise leaves behind names one processor, and that processor does no posting of its own. It looks up every processor registered as a subscriber to it, checks each against the document, and puts a fresh queue row on the tenant queue for each one that matches. The journal, the stock ledger line, the cashbook line, the e-invoice matching queues, membership points, coupons, finance charges, budget lines, intercompany, the knock-off queue, sales commission — all of them are subscribers, and none of them is mentioned anywhere in the finalise code.
Reference: How Work Actually Runs — Trace it once: what one Finalise actually starts
Step 2 — Learn the first filter, because it is the one that matters
After this step you will know why two tenants behave differently. A subscriber link only counts if your own database holds an active trigger-configuration row for the template that link belongs to. That row is the switch. It is why one tenant’s finalised invoice writes a journal and another’s does not, and it is not visible from the document screen, from the applet settings or from anything a user can open. Across the estate the journal template, the cashbook template and the inventory template are each enabled on a clearly different number of tenants, so this is not a theoretical difference.
Reference: How Work Actually Runs — Trace it once: what one Finalise actually starts
Step 3 — Learn the two filters that come after it
After this step you will stop mistaking the override for the switch. Second, your company record may carry an include list and an exclude list of processor codes. An excluded code is skipped; if the include list has anything in it, everything not on it is skipped. It is an override on top of the subscription, not the thing that enables anything, and measured across every tenant it is unset on every company but a handful. Third, a link may be restricted to particular document types, so a processor that exists for sales orders is not queued for your invoice. Most links carry no restriction at all.
Reference: How Work Actually Runs — Trace it once: what one Finalise actually starts
Step 4 — Follow the chain down, because it does not stop at one hop
After this step you will understand where costing comes from. A subscriber can itself be a publisher. The inventory processor writes the stock ledger line, then looks up its own subscribers and queues the stock-balance processor; that one updates the balances and the moving average, then queues the FIFO processor. Three levels below the button, and all three hang off one template, so for stock it is on or off as a unit. Nothing in the code names the next step: each level asks the registry the same question about itself, which is why the depth is configuration rather than code.
Reference: How Work Actually Runs — Trace it once: what one Finalise actually starts
Step 5 — Accept that you cannot add a link, and ask for the list
After this step you will know the boundary and the workaround. The half that decides which job follows which lives in the platform registry. Your tenant can turn an existing link on or off; it cannot create one, and neither can an integrator. There is no screen anywhere that shows you the list of what is enabled on your tenant, which means the honest answer to “what happens when I press Finalise here” is a question for your BigLedger contact. Ask for it in writing and keep it, because every explanation in this series depends on it.
Reference: How Work Actually Runs — Trace it once: what one Finalise actually starts
Step 6 — Know the one failure that silences everything
After this step you will recognise a symptom that looks impossible. The fan-out resolves each subscriber by name, and it does not guard that lookup — the scheduler, doing the identical lookup, does guard it. One subscriber link in the platform registry today names a code that matches no processor, so on a tenant that enables that template the lookup throws, the loop stops, and every subscriber it had not reached yet is never queued. The symptom is a document that is FINAL with nothing posted at all and no error against it. If you enable trigger templates, enable them one at a time.
Reference: Sales Invoice (Internal) — Troubleshooting
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.
Answer key
- Whether your database holds an active trigger-configuration row for the journal template — How Work Actually Runs — Trace it once: what one Finalise actually starts
- Everything your tenant subscribes to and the document type matches — How Work Actually Runs — Trace it once: what one Finalise actually starts
- The stock-balance processor queues it, and that one was queued by the inventory processor — How Work Actually Runs — Trace it once: what one Finalise actually starts
- Which trigger templates the tenant has enabled, because the fan-out itself can throw — Sales Invoice (Internal) — Troubleshooting
Next: What the line remembers, and when it was remembered · Back to the series · Play this as a presentation