Skip to content

Manufacturing Module

Manufacturing in BigLedger is one chain of four applets over one set of bl_mrp_* tables. 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.

This page is a map, not a manual. Each applet’s own reference page carries its screens, settings, fields and failure modes. This page says which applets are in the module, what each one records, and — the thing this module gets wrong most often when described from memory — what moves stock, at what value, and the fact that nothing here posts a journal.

Applets in this module

Membership is an editorial judgement — the product has no module↔applet relationship in its data — and it is written down in planning/specs/module-applet-membership.md. Manufacturing owns four registry applets, all with a reference page. They are used in this order.

AppletWhat it records
Process MaintenanceThe definition of production: machines (bl_mrp_prodsys_hdr, 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 writes bl_mrp_process_type_*, bl_mrp_process_template_*, bl_mrp_job_template_* and bl_mrp_prodsys_*, and never touches stock
Production Planning and Monitoring AppletThe plan: a job order (bl_mrp_job_order_hdr) 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 OperationsThe 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 (bl_mrp_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

AppletOwnerWhy manufacturing needs it
Stock BalanceInventoryThe “what do we have” screen; the Outstanding Report reads the same bl_inv_current_location_stock_balance.qty_ledger
Stock ConversionInventoryLight 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 AppletInventoryThe bin-level reservation the job order’s stock-planning screen writes (bl_mrp_job_order_bin_link), and the expiry processor that releases it
Sales Order (Internal)SalesWhere demand comes from: a sales-order line’s MRP tab links it to a job order, and MRP_MANDATORY_FOR_NON_FINISHED_GOODS can make that link compulsory
Inventory Item MaintenanceCoreThe item’s Process Template tab lists every template that uses it, with a Replace action

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 MRP_PROCESS_FINALIZATION_PROCESSOR. 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 the instance’s branch and location, writes them as ordinary bl_inv_txn_line rows, 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 COMPLETED (MrpProcessFinalizationProcessor.java L90–L138).

Every one of those transaction lines carries amount_txn = 0 (MrpProcessInstanceService.populateToMrpToTxnLine, L149). The finished item therefore enters the location’s moving average at zero value, and the consumed inputs leave at their running average with nothing to receive their cost. This is the same defect the inventory unit recorded for Stock Conversion (P-0255); it is recorded for the MRP path in the product register. Until it is fixed, treat the moving-average cost of any manufactured item as wrong after every finalisation and reset it deliberately with Reset MA in the Stock Adjustment applet — the remedy P-0255 names.

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 (ServerDocTypes.java L65, L68). 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. JournalPostingTypeHandler has no entry for any bl_mrp_* document 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 in the backend enum with short codes — INTERNAL_PRODUCTION_ORDER (quantity 1, amount 1) and INTERNAL_PLANNED_ORDER (quantity 0, amount 1) — but no handler, validator or applet 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 enum: REQUESTED, REJECTED, PLANNED, READY, IN_PROGRESS, COMPLETED, ON_HOLD, CANCELLED, EXPORTED, FINAL, PENDING_APPROVAL (ProcessStatus.java). The one hard rule the backend enforces between them: a job order cannot be set to COMPLETED while any of its process instances is not COMPLETED — the request is rejected with “SORRY! NOT ALL PROCESSES ARE COMPLETE …” (MrpJobOrderHdrService.java L163–L168). Changing a job order’s base quantity after its instances exist queues a patch processor that rescales the planned inputs (MrpJobOrderHdrService.java L150).

Each work log carries its own approval_status — PENDING, APPROVED, REJECTED or REWORK (WorkLogApprovalStatus.java) — set by the supervisor through the work-log applet’s own endpoint (ProcessInstanceWorkLogService.updateApprovalStatus, 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/ under core2/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. bl_mrp_process_template_bom holds 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 in source that are not in the registry

refs/blg-applet-wavelet-internal-kitting-applet and refs/blg-applet-wavelet-process-monitoring-applet are built applets with no row in the applet registry as of the 2026-09-05 export, so they cannot be installed from the Applet Store and are not documented here (the class ADR-0007 covers). A second build of the planning applet with an industry in its repository name also exists in source; which build the registry row installs is pending a registry check — see the planning applet’s page.

Where to go next