Scheduler

A job that exists in the product is not a job that runs on your tenant. A background job runs on a timetable only where your tenant holds an ACTIVE row for it in this listing, and a job BigLedger added to the product after your tenant was created has no row here unless BigLedger has since re-installed its defaults for you or somebody added it. Two more things before you trust the listing: Last Run Date means the clock fired, not that the job worked, and a schedule whose code is not a job the platform has is dropped silently, with no error and no run history.

Overview

The Scheduler is the tenant’s cron table. Each row pairs a background job processor with a cron expression and, optionally, a JSON payload of properties for that job. On every pacemaker tick the platform reads the tenant’s active rows, works out which are due, and puts the matching job on the tenant queue.

It is how recurring work gets scheduled without a deployment: e-invoice submission sweeps, replenishment runs, report generation, notification pushes and the rest. It runs nothing itself and knows nothing about what the jobs do.

Shipped, registered, scheduled, working: which of the four this screen shows

When BigLedger ships a new background job, four separate things have to be true before it does anything for you. This screen shows you one of them outright, one by inference, and the other two not at all.

1. The job exists in the product. This screen cannot tell you. The Select Processor picker is not the test: it is a list BigLedger refreshes from the product from time to time, and it disagrees with the clock in both directions (see Screens and menus).
2. The clock recognises its code. You see this only by inference. An ACTIVE row whose Last Run Date keeps moving is recognised; one whose date never moves while the other rows’ dates do is not.
3. Your tenant has an ACTIVE clock for it. This is the one the listing shows outright: a row, Status ACTIVE. No row means the job does not run on a timetable on your tenant, whatever the release note said. Jobs that start when you finalise a document are a different mechanism, subscriptions, and this applet does not list them.
4. It did its work. Never on this screen. Last Run Date moves when the clock fires; the work shows only where the job leaves it, in the job’s own applet.

The same four states, with the mechanism behind each, are in How work actually runs.

Where it fits

What must exist first. The job’s code has to be one the clock recognises, and BigLedger’s platform clock has to be running a round for your tenant; every minute that round reads this table before it does anything else. Neither shows on a screen. When either is missing, what you see is in Troubleshooting.

What it makes possible. Recurring work that nobody has to remember: the e-invoice submission and status passes, the monthly aging snapshot your historical debtor reports read, the half-hourly bank-reconciliation balance refresh, and any job you add yourself.

Its sibling: subscriptions. Two things start background jobs. A clock starts one on a timetable; a subscription starts one when a document is finalised (the journal, the stock movement, the cashbook line, the e-invoice queue). They are separate settings, and this applet shows only clocks. If your question is “why did finalising this invoice not post”, it is a subscription question, covered in How work actually runs. Other screens write clocks into the same table: Doc Item Maintenance has its own Scheduler window for its marketplace jobs, and what you create there appears in this listing too.

What breaks when a clock is wrong. A clock’s mistake rarely stays in its own module. A missing e-invoice clock leaves documents waiting in their pool; a missing bank-reconciliation refresh leaves every reconciliation with the cashbook balances it worked out when it was created; a missing aging clock leaves a month with no snapshot; and one ACTIVE row with an expression the clock cannot read stops every clock on the tenant (see Troubleshooting).

What it pairs with. The applet of whatever the job does, because that is the only place you can prove a clock worked; and Run Now, for the rehearsal in Trying it safely.

Screens and menus

Create has three tabs. Details holds Scheduler Code (read-only — clicking it opens a Select Processor picker, showing Code, Name, Type and Status), Scheduler Name, and Status (ACTIVE / INACTIVE). Cron Expression is a cron editor pre-set to 0 0 1/1 * *. Json holds the event properties, pre-filled from the chosen job’s registered default properties and able to load a .json file. CREATE is disabled until code, name and status are filled.

The Select Processor picker is BigLedger’s platform-wide list of job processors, the same whichever tenant you open it on — not a list of what runs on yours. It does not match what the clock can run in either direction: some codes in it are not ones the clock recognises, so a clock made from them never fires, and some jobs the clock does run are missing from it. Picking from it is the right way to get a code spelled correctly; it does not promise the job will run. Your tenant’s own clocks are the rows in the Scheduler listing.

Where the listing’s figures come from

• Scheduler Name is never read by the clock. A clock BigLedger installed as a default carries its code as its name, underscores and all; a clock made on this screen starts with whatever name the picker shows for the job.
• Last Run Date is the moment the clock last fired: it queued the job, or found an identical one already waiting. On a row that has never fired it is the moment the row was created. Run Now never moves it.
• Created Date is when the row was inserted. On a default, that is the day BigLedger installed the defaults on your tenant, at tenant creation or a later re-install, and it tells you which later defaults you are likely to be missing (see Configuration).
• Updated Date is the last time someone saved the row. The clock firing never changes it. A default whose Updated Date is later than its Created Date has been saved since it was installed; when a default is INACTIVE and nobody remembers why, that date is where to start.
• All three dates are shown in your browser’s time.

Edit shows the same Details, Cron Expression and Json tabs for the saved schedule. The Cron Expression tab shows the Current Expression and, below the editor, Update Expression to — the value SAVE writes. Edit also shows Created Date and Modified Date, and carries Run Now and Delete.

The Personalization menu lists a Field Settings item that leads to the applet’s 404 page.

Screenshots needed

This applet has not been captured yet. A capture session should take: the Scheduler listing with several rows and their Last Run Date; the Select Processor picker; the Cron Expression tab with the editor open; and the Edit screen’s Json tab with a payload and the Run Now button. Job processor codes are product-wide, not customer data, so a demo tenant is enough.

Configuration

Before you can use it

Applet settings

Settings are applet-local, and neither screen does anything for this applet.

• Settings → Field Settings is an eight-toggle placeholder (Unit Discount, SST/VAT/GST, WHT, Blanket Order, Segment, G/L Dimension, Profit Center, Project) — nothing is saved, SAVE does nothing, and the labels belong to a sales-document screen.
• Settings → Default Selection and Personalization → Default Selection offer Default Branch and Default Location. Nothing in the applet uses either.

Everything that matters is on the schedule row itself:

Times of day. Which time zone the hours in an expression are read in has not been confirmed by BigLedger, so this page gives no time of day as advice. Most default clocks run every few minutes, where it does not matter. For a clock you want at a particular hour, read its Last Run Date after the first firing: that is when it actually fired, in your browser’s time. Adjust the expression if it is off.

The clocks BigLedger installs, and why yours may be missing some

When BigLedger creates a tenant it inserts a set of default clocks, all ACTIVE, each named after its code and with empty properties. In mid-October 2026 the set is twenty clocks:

• E-invoice (twelve schedules): E_INVOICE_GENERIC_DOCUMENT_TO_IRB_PROCESSOR, E_INVOICE_TO_IRB_SUBMISSION_QUEUE_PROCESSOR, E_INVOICE_TO_IRB_SUBMISSION_PROCESSOR, E_INVOICE_TO_IRB_VALIDATION_STATUS_UPDATE_PROCESSOR, E_INVOICE_BATCH_PROCESSING_CYCLE_RUN_PROCESSOR, CONSOLIDATED_E_INVOICE_PROCESSOR, E_INVOICE_INTERMEDIARY_ACCESS_TOKEN_PROCESSOR, E_INVOICE_FROM_IRB_RUN_PROCESSOR, E_INVOICE_FROM_IRB_DOCUMENT_QUEUE_PROCESSOR, E_INVOICE_EMAIL_PRINTABLE_QUEUE_PROCESSOR, E_INVOICE_AUTO_CANCEL_PROCESSOR, E_INVOICE_ITEM_CLASSIFICATION_CODE_UPDATE_PROCESSOR.
• Stock (one schedule): INVENTORY_CURRENT_STOCK_BALANCE_QUEUE_PROCESSOR.
• Cash and bank (two schedules): BANK_RECON_BALANCE_QUEUE_PROCESSOR (every 30 minutes) and CASHBOOK_TXN_WATCHDOG_PROCESSOR (every 15), which re-queues the cashbook posting of a finalised or voided document whose cashbook lines did not come out right.
• Housekeeping (three schedules): GENERIC_DOC_DELETE_TEMP_QUEUE_PROCESSOR, EXPIRED_TASK_QUEUE_SCHEDULER_PROCESSOR, TASK_HANDLING_QUEUE_POLLING_PROCESSOR.
• The first of the month (two schedules): DEPOSIT_ROLLOVER_PROCESSOR and MONTHLY_GENERIC_DOC_HISTORICAL_AGING_PROCESSOR.

The insert happens once, and only for codes your tenant has no row for. A default added to the product after your tenant was created is therefore not on your tenant unless BigLedger has since re-installed the defaults for it. That is a platform operation, and nothing in your tenant’s applets starts it. The set has grown over time: the monthly aging snapshot and the e-invoice e-mail queue joined in August 2025, the item-classification refresh in January 2026, the e-invoice auto-cancel and the queue that fetches received e-invoice documents from LHDN in September 2026, and the bank-reconciliation refresh and the cashbook watchdog in October 2026. Compare those months with the Created Date on your default rows.

If you reconcile a bank, check this one first. A bank reconciliation stores its cashbook opening and closing balances. When a cashbook line in its period changes later (a back-dated payment, a void), the platform records a refresh request, and BANK_RECON_BALANCE_QUEUE_PROCESSOR is the only thing that acts on those requests. Take GadgetSphere, whose tenant was created in mid-2025 with 28 cashbooks to reconcile: with no row for that code, every reconciliation keeps the balances it worked out at Create, and a payment voucher you post and match in the period shows on Report 1 as a variance of its own amount. When this page was written that code was not in the Select Processor picker, so you could not add it from this screen. Ask BigLedger to add it. The Bank Reconciliation applet covers what the stored balances are.

A re-install fills gaps and nothing else. It adds a default only where your tenant has no row with that code at all, whatever that row’s status. A default you set INACTIVE stays inactive. A default you deleted stays deleted: Delete here only marks the row deleted and hides it from the listing, and the re-install still counts the hidden row. To stop a default, set it INACTIVE. If you deleted one and want it back, create it again yourself where the picker offers its code; a second row with the same code is allowed.

Deciding which jobs run on your tenant

The product does not decide this for you, and BigLedger has not published a recommended set of jobs for a business like yours. The decision belongs to whoever owns your month-end, usually the finance lead, and it is made with BigLedger job by job: at go-live, and again whenever BigLedger tells you about a new job. When a job you need has no clock, there are two ways to add one:

• Add the clock yourself, where the picker offers the code. It is quick, and you choose the timetable. The cost: you own its expression, its properties and its time of day. A clock made here also differs from BigLedger’s default in two ways you cannot see. Its Json tab is pre-filled from the job’s registered properties (a default has none), so read what it put there before you save. And it is put on the queue for the same round to pick up, where most defaults run the job inside the clock’s own pass. Either way the job runs.
• Ask BigLedger to re-install the defaults. You get exactly BigLedger’s timetable, and every missing default at once, including ones you had not noticed were missing. The cost: you wait for BigLedger, and it adds every default your tenant has never had, ACTIVE, including any you would rather not run.

You know you got it right when each job’s effect appears where it should. The monthly check under Trying it safely is how you look.

Feature visibility / permissions

The applet has no client-side permissions and checks no HIDE_* / SHOW_* keys, so the Feature Visibility screen has nothing to gate.

Server-side, schedules need API_TNT_DM_SCH_CRONTAB_READ, _CREATE, _UPDATE and _DELETE (with _OWNER and _ADMIN as the broad grants). Note that Run Now needs API_TNT_DM_SCH_CRONTAB_CREATE, not update — anyone who may add a schedule may also fire one immediately.

Fields

Create → Details

The other two Details fields are Scheduler Name and Status (ACTIVE or INACTIVE — see the settings table above). Picking a processor fills Scheduler Name with the job’s own name, and it is saved upper-cased and trimmed on both Create and Edit. The name is yours alone: the clock queues the job by its code and never reads the name, so if you keep two clocks on the same job — one daily, one month-end — the name is the only thing on the listing that tells them apart. Put the difference in it. Give them different properties too: the queue treats two firings with the same code and the same properties as one job, so while one is still waiting the other queues nothing — and still stamps its Last Run Date.

Cron Expression tab — a cron editor. Its value is copied onto the schedule on submit.

Json tab (Create and Edit) — a single event-properties field holding a JSON object, pre-filled and uploadable from a file.

Listing columns — Scheduler Code, Scheduler Name, Status, Last Run Date, Created Date, Updated Date. Last Run Date is set only by the platform and cannot be edited.

Lifecycle and effects

No document, no journal, no stock. The applet writes schedules; the platform writes the run history and queues the jobs.

What happens on each tick of the platform’s clock:

1. Read every ACTIVE schedule of the tenant. A tenant whose database the clock fails to reach is skipped for that tick, not failed.
2. Keep only schedules whose code is a job the platform has. A schedule naming a job the platform does not have is silently dropped: no error, no run history, no change to Last Run Date.
3. Keep only schedules that are due. The expression is read as a UNIX cron expression, measured from the Last Run Date (or, before the first run, the Created Date): the schedule fires when now is after the next occurrence after that point. Because the reference is the last run and not the wall clock, a tenant that was down catches up on exactly one missed occurrence per tick.
4. For each due schedule, check that the same job is not already waiting — an identical job already queued is not queued again.
5. Otherwise queue the job with the schedule’s event properties and execution strategy.
6. Set Last Run Date to now and add a run-history entry — both when the job was queued and when an identical job was already waiting and nothing new was queued. Only a failure to queue leaves Last Run Date alone, so the next tick retries.

So Last Run Date says the clock fired, not that the job worked. It is stamped when the job is put on the queue (or found already there). The job runs after that, and if it fails, the failure is recorded where no screen shows it and Last Run Date does not change. To know a job did its work, look for its effect in the job’s own applet — the queue that drained, the rows that appeared.

Switching an inactive clock on. Only ACTIVE rows are read, so an inactive clock’s Last Run Date stays where it was. When you set it to ACTIVE, the next occurrence is measured from that old date, so if an occurrence fell while it was off, the clock fires on the next tick — not at its next scheduled time.

What “Run Now” does instead. It queues the job to start now (expiring in five hours) with the schedule’s code and event properties, and runs it at once. It reports an error only when the job fails to start — a code that is not a usable job — and the message is the server’s error text. A job that starts and then fails inside is recorded as a failure where no screen shows it, and the applet still says The scheduler has been run successfully. So a success message means the job was started, not that it worked. It does not update Last Run Date, so a manual run does not shift the next scheduled occurrence.

What the platform fills in. On create it supplies status = ACTIVE and execution_strategy = INSERT_TO_QUEUE when they are missing, and it sets Last Run Date to now. That last default is the one to remember: a new schedule’s first firing is computed forward from the moment you created it, never from the past, so creating a daily job at 3 pm does not back-fill this morning’s run.

Validation on create rejects a row with no code, no name, no cron expression, no status, no revision, or an execution strategy that is not one of the queue’s own strategy values.

Trying it safely before you need it

BigLedger has no sandbox and no test mode, so most failures are met for the first time in production. Scheduled jobs are the exception, and this is the one place in the product where you can make the thing happen on purpose instead of waiting for it.

Run Now is safe in the sense that matters here: it does not move the schedule. It writes to a separate queue and deliberately leaves last_run_time alone, so pressing it does not skip, double-run or delay the next scheduled occurrence. What it is not is a dry run — the job does whatever the job does, and if that job posts, sweeps or sends, it really posts, sweeps or sends.

So the rehearsal that is genuinely safe is the narrow one, and it answers the question people actually open tickets about:

1. Create the schedule with Status INACTIVE, so nothing fires on a clock while you are looking.
2. Press Run Now.
3. Watch for the effect in the job’s own applet — a queue that drains, a row that appears, an e-mail that arrives. This is the only test that counts: the success message says only that the job started. If the job needs properties, this is where a missing one shows up, because several jobs read their properties with no fallback and abort the whole sweep when one is absent.
4. If Run Now itself errored, the job could not be started at all — usually the code is not one the clock recognises.
5. Only then set Status to ACTIVE and let the cron expression take over. If an occurrence fell while the clock was inactive, it fires on the next tick rather than waiting for the next one.

Not every job is safe to rehearse. The monthly aging snapshot (MONTHLY_GENERIC_DOC_HISTORICAL_AGING_PROCESSOR) stores last month-end’s balances whenever it runs, using the balances at that moment, and never replaces a month it has already stored. Run it mid-month, or switch its clock on after a missed 1st, and last month-end is stored from today’s balances, for good.

Before you press Run Now on a job that moves money or files a document, do it on a small, deliberately chosen scope — one company, one branch, one day — through the job’s own event properties. There is no undo, and the platform will not ask you twice.

The monthly look at the clocks

The product does not watch its own clocks. Nothing alerts anyone when one stops, and Last Run Date is the only trace it leaves. So make the check somebody’s job: whoever signs off month-end, on the first working day of the month. It takes about five minutes.

1. For every ACTIVE row, compare Last Run Date with its expression. A clock set for every ten minutes should read within the last few minutes; a first-of-the-month clock should read this month’s 1st. A date older than its expression allows is the first sign of trouble, and Troubleshooting has the causes.
2. Check that the defaults you rely on are there and ACTIVE. For a group shaped like GadgetSphere, that means the e-invoice passes, the monthly aging snapshot and, because it reconciles 28 cashbooks, the bank-reconciliation refresh.
3. For each job that matters, look at its effect, not its date. The Historical Debtor Report in the Debtor Report applet has last month-end. Documents have left the e-invoice pool. A reconciliation’s cashbook closing follows a back-dated payment within about half an hour.
4. Read Updated Date. Any row saved since last month that nobody remembers saving is worth one question.

You are done when every ACTIVE row’s date fits its expression and every job you depend on has left its effect.

Related applets

• Developer SysAdmin Applet — the applet registry: Applet, Vendor, Modules, Categories, Developers. It has no job-processor screen, no subscription screen and no failure screen, and it is a platform applet a customer would not hold in any case. The platform’s list of job processors is in this applet’s own Select Processor picker (it is not your tenant’s list); subscriptions are on no screen; a failed job is on no screen anywhere in the product.
• Bank Reconciliation: its stored cashbook balances are kept current by the BANK_RECON_BALANCE_QUEUE_PROCESSOR schedule, where your tenant has one.
• Debtor Report: the Historical Debtor Report reads the snapshot the monthly aging clock stores.

Troubleshooting

Related documentation

• How work actually runs: clocks, subscriptions and queues, and the four states a job can be in.
• Developer documentation