Manufacturing Module
Manufacturing in BigLedger is one chain of four applets over one set of production records. You describe how something is made once — machines, process types, process templates with their input and output items, and a job template that strings templates together — then raise a job order for a quantity, which generates one process instance per template step. Operators log work against each instance, a supervisor approves the logs, and when an instance is finalised the backend consumes its input items from stock and puts its output items in. A packing order then records how the finished quantity was packed against the sales order that asked for it.
Applets in this module
Membership is an editorial judgement — the product has no module↔applet relationship in its data. Manufacturing owns four applets, all with a reference page. They are used in this order.
| Applet | What it records |
|---|---|
| Process Maintenance | The definition of production: machines (typed Production or Packing), process types (the kinds of step), process templates (one step — its input and output items as BOM rows with a ratio, the machines that can run it, attachments), and job templates (one per finished item; the backend derives its option groups by walking from the templates that output the item down through their inputs), plus a CSV import for templates. QC-checklist tables exist but the menu is commented out. Master data; it never touches stock |
| Production Planning and Monitoring Applet | The plan: a job order for a quantity of one item, built from a job template, linked to the sales-order lines it will satisfy, with its generated process instances, stock reservations, priority and status; a Production Request screen that lists the sales-order lines Sales has marked REQUESTED on their MRP tab and lets the planner mark them APPROVED or REJECTED (a status pair on the sales-order line — approving creates nothing); the Outstanding Report and Production Master Schedule CSVs |
| Manufacturing Operations | The execution: two screens — Operator PMC, where an operator records work logs (shift, machine, start and end time, quantity produced, input bins consumed, output bins produced) against a process instance, and Supervisor PI, where a supervisor sets instance priority, approves or rejects each work log, and finalises the instance. Finalisation is the one thing in the module that moves stock |
| Packing Order Applet (Internal) | The pack: an INTERNAL_PACKING_ORDER document knocked off from a sales order (the UI also offers jobsheet, delivery order and sales invoice as sources where the Organisation Doc Flow row is enabled; the backend’s own previous-document list holds the sales order only). Its FINAL pushes the lines onto the pick-pack queue; an operator records what was packed into which bins and containers, and a supervisor’s approval writes the packed-bins rows and releases the sales order’s stock reservation. Also carries the coiling variant of the process-instance screens, the drum / reel container register and a Scrap & Short listing. Quantity and amount signum 0 — the document neither moves stock nor posts |
Supporting applets, owned by other modules and used here
| Applet | Owner | Why manufacturing needs it |
|---|---|---|
| Stock Balance | Inventory | The “what do we have” screen; the Outstanding Report reads the same ledger balance |
| Stock Conversion | Inventory | Light kitting without a job order — input lines and output lines on one header at one location; its edit form can link a conversion to job orders |
| Stock Reservation Applet | Inventory | The bin-level reservation the job order’s stock-planning screen writes, and the expiry processor that releases it |
| Sales Order (Internal) | Sales | Where demand comes from: a sales-order line’s MRP tab requests production, scheduling or stock for it and can link it to a job order; MRP_MANDATORY_FOR_NON_FINISHED_GOODS (with ENABLE_MRP_JOB_ORDER_LINK) makes the screen require a Requested status — not a job order — on lines without the Fast Moving Goods label |
| Inventory Item Maintenance | Core | The item’s Process Template tab lists every template that uses it, with a Replace action |
| Bundles and grouped items | Inventory | The other way an item is made of other items, and the one most businesses meet first: a bundle has no stock of its own, and its availability is the smallest of (each child’s balance at this location ÷ how many the bundle needs). Read it before you reach for a process template — and it is the page that explains “there’s not enough stock for bundle item”, an error that names the parent and never the child that ran out |
What moves stock, and at what value
Only one event in the module changes a stock balance: finalising a process instance. The
Supervisor PI screen sets the instance to FINAL, which queues the finalisation job.
That processor takes every process-instance line marked INPUT out of stock (quantity signum −1)
and every line marked OUTPUT into stock (quantity signum +1) at that line’s branch and location,
writes them as ordinary inventory transaction lines dated at the moment of finalisation (not the
work-log dates), marks the instance POSTED, releases the
bin locks the input bins held, and sets the next instances in the job to READY once every
instance in the current stage is FINAL.
Each of those transaction lines is written with an amount of zero, but the amount is never read: a process-instance line carries none of the document types whose amount enters the moving average, so every item is costed at its own unit cost at that location. The inputs leave at their running average; the finished item comes in at the unit cost it last carried there — zero only if it has never been costed at that location. Neither unit cost moves. What is lost is the transfer: the inputs’ cost leaves inventory and the finished item never receives it. So the cost of a manufactured item is whatever it carried before the job, and if you want it to carry the cost of what went into it, set it deliberately with Reset MA in the Stock Adjustment applet.
No other document in the module touches stock. The job order (INTERNAL_JOB_ORDER) and the
packing order (INTERNAL_PACKING_ORDER) both carry quantity and amount signum 0.
A work log records quantities but writes no transaction line;
only the totals on the instance lines at finalisation count.
What posts to the ledger
Nothing. Journal posting has no rule for any manufacturing record or for the job order or packing order; there is no Work-in-Progress account, no absorption of labour or machine time, no standard cost and no variance. If your accounts need a WIP or cost-of-goods-manufactured figure, it is a manual journal in Financial Accounting built from the Outstanding Report and the work logs — the module gives you the quantities, not the values.
Two further document types exist by name — INTERNAL_PRODUCTION_ORDER and INTERNAL_PLANNED_ORDER —
but no applet or posting uses them. They are declared, not implemented; do not plan around them.
Statuses and approvals
A job order and each of its process instances carry a process status from one list: REQUESTED, REJECTED, PLANNED, READY, IN_PROGRESS, COMPLETED, ON_HOLD, CANCELLED, EXPORTED, FINAL, PENDING_APPROVAL. The server holds one rule between them — a job order is refused COMPLETED while any of its active process instances is not COMPLETED (“SORRY! NOT ALL PROCESSES ARE COMPLETE …”) — but the rule sits on a separate status route that no screen calls. The job order form in Production Planning and Monitoring saves through the ordinary update, which validates no transition, so a job order can be set to COMPLETED there with instances still open. The check is the planner’s: before completing a job order, open its Process Instance tab and confirm that every row with Active? ticked reads COMPLETED. The word is literal — an instance already finalised reads FINAL, which is not COMPLETED, so the supervisor still has to move each finalised instance on to COMPLETED first. Changing a job order’s base quantity after its instances exist queues a patch processor that rescales the planned inputs.
Each work log carries its own approval status — PENDING, APPROVED, REJECTED or REWORK — set by the supervisor through the work-log applet’s own screen (which also writes a historical copy of the log). This is the module’s only approval. The generic approval engine covers Purchase Order, Purchase Requisition and Stock Requisition only; no manufacturing document has an approval setting, and the packing order’s Workflow Settings screen is the ordinary Workflow Design custom-status mechanism, not an approval.
What the module has no engine for
Written down because the previous version of this page, and most descriptions of an “MRP module”, assume them:
- No material-requirements planning run. “MRP” in BigLedger is the name of the backend package
(
mrp/undercore2/tnt/dm/) and of the job-order link on a sales-order line. Nothing explodes a bill of materials into purchase requisitions, nets demand against stock, or schedules by capacity. The Outstanding Report shows balance, outstanding and net per item and location; the planner reads it. - No multi-level BOM explosion. A process template’s input items are one level; a job template chains templates. The BOM rows hold the item-to-template links the Inventory Item Maintenance tab reads.
- No WIP, absorption, standard cost or variance — see What posts.
- No machine capacity, downtime or utilisation tracking. A machine is a master record and a field on a work log; the module records which machine and how long, not what the machine could have done.
- No approval other than the work log — see above.
Two applets that cannot be installed
An internal kitting applet and a process-monitoring applet exist but cannot be installed from the Applet Store, and are not documented here. A second build of the planning applet also exists; which build your tenant is served is a question for your BigLedger contact — see the planning applet’s page.