Stock Replenishment Applet

Turn each location’s minimum and maximum stock levels into purchase orders or stock transfers, on demand or on a calendar. The reorder quantity reads only those levels and the ledger quantity, and a run started by a scheduled event raises its documents without showing any errors, so check what each scheduled run produced.

Overview

The Stock Replenishment applet turns per-location minimum / maximum stock levels into documents. A Replenishment Template fixes the scope (items, locations, suppliers) and a Fulfillment Strategy (buy from a supplier, transfer from another location of the same company, or transfer from another company in the tenant). A Replenishment Event puts a template on a calendar — optionally recurring — and a Replenishment Run is one execution: BigLedger computes, for every item × location in scope, how far the location is below its minimum (or maximum) level and writes an order quantity line and an order fulfillment line. From those lines the applet — or, for scheduled events, the run itself — creates Purchase Orders (Internal) or Internal Outbound Stock Transfers, and optionally e-mails the outcome.

It is opened by purchasing and inventory planners. Upstream are the item master (min/max levels, supplier pricing) and the stock balance; downstream are the Purchase Order and Stock Transfer applets that carry the generated documents through GRN, invoice and stock movement. The applet itself moves no stock and posts no journal.

Where it fits

Screens and menus

Five menu items, plus Settings and Personalization:

Run view — eleven tabs, in this default order: Details, Locations, Items, Suppliers, Categories, Fulfillment Strategy, Min/Max Qty/Loc, Item List, Order Fulfillments, Export, Purchase Orders. Item List, Order Fulfillments and Purchase Orders load lazily. A Delete button sits under the tabs.

• Min/Max Qty/Loc — an editable grid of every item × location in the run (Item Code, Item Name, Loc. Code, Min, Max, Balance) with two buttons: Auto-Fill All (queues a fresh calculation for this run) and Reload.
• Order Fulfillments — the fulfillment lines (Item Code, Supplier Code / Name, Location Code, Quantity To FulFill, Quantity To Approve (editable), Price (editable), Min / Max Purchase Quantity, Location Balance, Fulfillment Type, Status, Blocked Reason) with four buttons: GENERATE PO, GENERATE STOCK TRANSFER, GENERATE INTER-COMPANY TRANSFER, GENERATE ORDER FULFILMENTS. Opening a line shows the underlying order-quantity line (Details tab — 30-day sales, balances, in-transit, open PO, reserved, sales-order-in-queue, reorder calculation, supplier, unit cost) and its fulfillment lines.
• Purchase Orders — the documents linked to the run (PO Number, Branch, Location, Txn Amount).
• Export — one enabled button, EXPORT AS PDF, which does nothing; CSV / DOCX / ZIP are disabled.

Template view — tabs Details, Items filter, Suppliers filter, Locations filter, Fulfillment Strategy, Category filter, Items List (a read-only expansion of the picked items and categories).

Event view — tabs Details (with the Recurring checkbox and recurrence editor), Items filter, Suppliers filter, Locations filter, Fulfillment Strategy.

Each filter tab carries a Rules Logic (AND / OR) and Negation Logic (Included / Excluded) control above its grid.

Settings — Field Settings, Default Selection, Printable Format Settings, Email Template, plus the shared Webhook, Feature Visibility and permission screens. Personalization — Sidebar and Default Selection.

No product screenshots exist for this applet; the two images previously on this page were a marketing infographic and a missing file, and have been removed.

Configuration

Before you can use it

Applet settings

Anyone with access to the Settings menu can change these; there is no finer-grained authority.

Field Settings is a stub: eight unbound toggles (Unit Discount, SST/VAT/GST, WHT, Blanket Order, Segment, G/L Dimension, Profit Center, Project) and a SAVE button that does nothing. Nothing on this screen is saved or read.

Default Selection:

Printable Format Settings — upload .jrxml formats; the star column marks the default, which the Printable Format and Email Template listings show. No screen prints anything — the Export tab’s PDF button does nothing — so the setting has no effect on output.

Email Template — applet-level notification templates with Template Code, Email Subject and Template body, plus clickable placeholder chips. The subject is stored in the template’s description field and is used as typed; left empty, BigLedger builds one from the outcome and the document number. Supported placeholders, substituted when the e-mail is sent in ${token} or {{token}} form (unknown tokens are left verbatim): docNumber, docTypeLabel, docServerType, supplier, location, items, itemsFulfilled, itemsBlocked, reason, outcome, fulfillmentType, documentCount, lineCount, and poNumber as an older name for docNumber (the chips do not offer it). A template is used only when a Fulfillment Strategy selects it.

Personalization → Default Selection is broken in this build: selecting a branch or location fails with an error and nothing is saved.

Document behaviour settings — the Fulfillment Strategy

The Fulfillment Strategy tab is the same tab on Template, Event and Run. Each level has its own strategy and SAVE STRATEGY writes only that level. Precedence is by copying, not by lookup: creating an event copies the template’s strategy (and filters) onto the event; creating a run copies the event’s strategy if the run came from an event, otherwise the template’s. A run is processed from the run’s own strategy only. Changing a template or event afterwards does not change existing runs; a run with no strategy saved is processed with the defaults below.

The two yellow banners on the tab (reorder formula; inter-company accounting impact) are informational text.

Filter logic per group (Items, Locations, Suppliers, Categories on template, event and run): Rules Logic AND / OR and Negation Logic Included / Excluded (defaults AND / Included). Effect on a run you start yourself (Auto-Fill All, or saving a run with a template): negation off → the picked set; negation on with picks → every active location / item except the picks; negation on with no picks → the whole universe. On a run a scheduled event creates, Negation Logic is not applied: the event’s picked locations and items are used as picked, whatever the switch says, so Excluded on an event orders the picks rather than everything else (read from the code, not tried). To exclude on a schedule, pick the locations and items you do want and leave negation off. AND / OR is stored and copied but does not change the result today. Event values that are left empty inherit the template’s at processing time. Category filters are copied template → event but never used to select items — only Items and Locations decide the item × location grid; Suppliers restrict which supplier is chosen first (see Troubleshooting — the filter is a preference, not a limit).

Settings in other applets that control this applet

Feature visibility / permissions

• Client-side permissions: none exist for this applet. Feature Visibility shows nothing for it; menu items cannot be hidden per role.
• Server permissions: API_TNT_DM_STOCK_REPLENISHMENT_RUN_{CREATE,READ,UPDATE,DELETE,ADMIN,OWNER,MEMBER}, and the same seven for TEMPLATE_HDR, EVENT_HDR, RUN_FILTER_ITEM, RUN_FILTER_LOCATION, RUN_ORDER_QTY_LINE, RUN_ORDER_FULFILLMENT_LINE, RUN_DOC_LINK. OWNER and ADMIN satisfy every check on their family.
• Auto-Fill All and GENERATE ORDER FULFILMENTS need only …_RUN_READ.
• All three generate buttons check the one permission API_TNT_DM_STOCK_REPLENISHMENT_RUN_ORDER_FULFILLMENT_LINE_GENERATE_PO — there is no separate transfer permission.
• Editing Min / Max on the Min/Max Qty/Loc tab is saved under the stock-take balance permission API_TNT_DM_ERP_STOCK_TAKE_BALANCE_UPDATE, not a replenishment one — a planner who can run everything else here still needs it to change a level.
• Event-created documents are created as the user who created the event.

Fields

Replenishment Template — Details

You give a template a Template Name (required) and an optional Description; Created By, Creation Date, Modified By and Modified Date are read-only. Nothing stops two templates sharing a name. The name matters more than it looks, because every run an event creates is named after it — Run for template: ‘…’ — and its description becomes the run’s description as Template description: …. Several events on one template therefore produce runs with identical names; tell them apart by the Replenishment Event Name and the run dates.

The filter tabs store the picked items (from the item grid: Item Code, Item Name, UOM, Status), locations, suppliers and categories (label code / name).

Replenishment Event — Details

Editing or deleting a recurring event asks This event / This and following events / All events. A malformed rule is rejected with Invalid Recurrence Rule : ….

Replenishment Run — Details

A run carries a Run Name (required, and not checked for uniqueness) and a free-text Description. The name is copied onto the link row of each document the run generates at the moment it is generated. Runs an event creates are named and described for you from the template, as above.

Min/Max Qty/Loc (run)

Editable Min and Max per item × location; each edit is saved straight to the location stock balance (not to the run), under the stock-take balance update permission named under Feature visibility. The grid refuses Max < Min when both are positive and restores the old value.

Order Fulfillments (run)

The generated document line takes Quantity To Approve as its quantity and Price as its unit price; a PO line left at 0 produces a zero-quantity PO line.

Lifecycle and effects

Templates, events and runs have only ACTIVE / INACTIVE statuses; there is no FINAL or VOID. The work happens in three stages after queueing: a calculation, a fulfillment pass and document creation.

1. Queueing. Saving a run with a template queues the calculation immediately. Saving an event queues one calculation per occurrence — immediately when the cycle start is already past, otherwise at the cycle start. Auto-Fill All and GENERATE ORDER FULFILMENTS queue the run again. A queued calculation that is not due yet waits for the platform’s background sweep, which reaches every tenant on its own clock and takes up to ten due replenishment jobs per pass; it needs no entry in the Scheduler applet, and the Scheduler applet can neither show nor stop it. If a scheduled run has not appeared a while after its start time, the sweep has not reached it yet or the job failed — see Troubleshooting.

2. Calculation. Three scenarios: an event (creates the run header, copies the event’s filters and strategy, records the previous run); a run with a template (copies template filters into the run’s Locations / Items / Suppliers tabs when the run’s own are empty); a run without a template (uses the run’s tabs only). It then resolves the effective location and item sets (negation), and for every item × location writes an order-quantity line with: location min / max / ledger quantity / open-PO; in-transit = outbound transfers to the location not yet received; company balance, reserved, sales-order-open, open-PO; last-30-days sales at location and company (sales invoices less sales returns); reorder quantity = max(0, level − ledger quantity); and the chosen supplier. Re-running does not delete earlier lines — each calculation appends a new set. Processing stops silently (logged, no error to the UI) when the effective location or item set is empty or a template has no location / item filters. An error inside the calculation is silent too: the job runs in a queue, and when it throws — most often PO cannot be initiated without a supplier present for an item with no supplier link and no past purchase invoice — the work is rolled back, the error is written to a table no screen shows, and the sweep tries the job again, up to five times. On an event-created run the run header is created before the item loop, so each attempt leaves another empty run named Run for template: ‘…’ in the Runs listing; on a manual run Auto-Fill All reports success the moment the job is queued, whatever happens to it afterwards (read from the code, not tried).

3. Fulfillment (one pass per line for manual runs, inline for event runs): reads the run’s strategy and writes one fulfillment line per order-quantity line — a PO line (status PENDING), an internal or inter-company transfer line (source location chosen by scope / priority), or a surplus redistribution line. A transfer line’s quantity is the lesser of the requested quantity and the source’s ledger quantity when the request is above zero; when the request is zero — every location already at or above its level, since the request starts as the reorder quantity — the line is given the source’s whole ledger quantity instead (read from the code, not tried). So in a transfer-type run every in-scope location gets a proposal, and the ones that needed nothing get the biggest; on an event-created run those become transfers automatically. Check the Quantity To Approve of every line whose Location Balance is already at its level before generating, and prefer manual runs for transfer strategies until you have seen one. A line with no item is skipped; a line with no usable source stays PENDING with a reason.

4. Document creation. GENERATE PO filters the selected lines to PO type with a supplier and not BLOCKED, applies the open-PO block, and merges lines with the same branch and supplier into one PO — and, inside that PO, merges lines for the same item into one line, summing the quantities. The merged line keeps the first location’s delivery store, and the run’s link to the document is written against the first matching fulfillment line only, so when two locations of one branch want the same item from the same supplier the PO shows one line addressed to the first location and the other location’s fulfillment line shows no document (read from the code, not tried). Split the PO line by hand in the Purchase Order applet, or run one location at a time. The POs are created with the same validation as the Purchase Order applet, linked to the run, the lines set to GENERATED and the notification sent. GENERATE STOCK TRANSFER does the same for internal and surplus lines; GENERATE INTER-COMPANY TRANSFER adds the branch inter-company checks (on the source location’s branch) and creates the inbound leg in the counterpart company. For event-created runs the POs and internal transfers are created automatically (errors are not surfaced); inter-company documents are never created automatically.

What Document Status: Active does and does not do. The generated document is written with posting status FINAL and the usual running number, and the webhook created event is queued — nothing else. The processing chain that moves stock for a transfer, or starts the purchase-order chain for a PO, is started only when a document is finalised through its own applet’s FINAL, and the run never calls that path. So a FINAL transfer from a run has moved nothing, Stock Balance does not change, and the Stock Transfer applet treats the document as already final and offers no FINAL to press (read from the code, not tried). Draft is the status that leads somewhere.

Posting proof block

Validation. Saving checks only structure (status, audit fields). The business rules are the errors listed under Troubleshooting.

Related applets

• Purchase Order (Internal) — receives the generated Purchase Orders (Internal); its own PO Replenishment menu is a separate, older screen family.
• Stock Transfer — receives generated outbound transfers (internal, inter-company and surplus).
• Inventory Item Maintenance — per-location minimum / maximum levels.
• Doc Item Maintenance — Entity Pricing supplier links, supplier priority, purchase price, order quantity bands, lead time.
• Supplier — the supplier entity on the generated PO.
• Organization — locations, branches, geolocation, Branch Intercompany Configuration.
• Chart of Account — inter-company GL mapping check.
• Stock Balance, Stock Availability, Stock Balance overview — the balance rows the run snapshots and whose min / max it edits.
• Stock Level Monitoring — the same template / event / run shape and the same Rules Logic and Negation Logic controls, but it only e-mails the breach instead of creating documents.

Troubleshooting

Related documentation

• Inventory module · Purchasing module
• Stock Balance overview — where the min / max levels live and how balances are maintained
• Purchase Order (Internal) — what happens to a generated PO
• Stock Transfer — what a FINAL outbound transfer does to stock