Skip to content

Core Concepts

Six records, one chain. Everything the four manufacturing applets do is a screen over one of these, and the vocabulary on those screens is the vocabulary below.

1. The definition — process type, process template, job template

A process type is a kind of step: cutting, coiling, assembly, testing. It is a name, a code, a position in a sequence and an active flag (checklist attachments hang off it; the QC Specifications menu that would show them is commented out in the current build).

A process template is one step, fully specified: which process type it is, which input items it consumes and which output items it produces (BOM rows, each with a direction and a ratio), which machines can run it (one flagged default) and its attachments. It is the closest thing the module has to a bill of materials — one level deep. The item’s Process Template tab in Inventory Item Maintenance reads those BOM rows back.

A job template is one per finished item. When it is created the backend walks the chain for you — from the templates that output the item down through their input items — and writes the resulting stages and process options (alternative templates for the same stage) as link rows (groups named <item>-OPT-n). Those links are what finalisation walks to find the next stage. A machine is a production-system record typed Production or Packing. All of this is master data maintained in Process Maintenance, and none of it touches stock.

2. The plan — job order and process instance

A job order (server document type INTERNAL_JOB_ORDER, short code JOBODR) is “make this quantity of this item, from this job template, by this date, at this priority”. Raising it in Production Planning and Monitoring generates one process instance per template in the route, each carrying the planned input and output lines scaled to the job quantity, a branch and a location, a machine, and a process status. The job order links to the sales-order lines it satisfies; the sales-order line shows that link on its MRP tab. A job order carries quantity and amount signum 0: it is a plan, not a stock or accounting document.

Changing the job’s base quantity after the instances exist does not silently leave them stale — the backend queues a job to rescale the planned inputs.

3. The execution — work log

A work log is one operator’s record against one process instance: shift date and type, machine, start and end time, quantity produced against quantity required, the input bins consumed and the output bins produced, remarks. Operators write them on the Operator PMC screen of Manufacturing Operations; the supervisor sees them on Supervisor PI. A work log does not move stock. It carries an an approval status — PENDING, APPROVED, REJECTED, REWORK — and every status change writes a historical copy so the log can be audited after the fact.

4. The one stock event — finalising a process instance

When the supervisor finalises an instance, the backend queues the process-finalisation job, which does four things in order:

    flowchart LR
  A[Instance set FINAL] --> B["INPUT lines → stock out (qty −1)<br/>OUTPUT lines → stock in (qty +1)<br/>at the instance's branch and location"]
  B --> C["Next stage's instances<br/>become READY once every<br/>instance in this stage is FINAL"]
  C --> D[Instance marked POSTED]
  D --> E[Input bin locks released]

The stock lines are ordinary inventory transaction lines fed to the same current-stock-balance processor every stock document uses — with one difference that matters: the amount on every line is zero, and it is never read. A process-instance line carries none of the document types whose amount enters the moving average, so each item is costed at its own unit cost at that location: the inputs leave at their running average, and 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, because the inputs’ cost leaves inventory and the finished item never receives it. Read Best practices before you rely on the cost of a manufactured item.

The packing order (INTERNAL_PACKING_ORDER, signums 0 and 0) sits after this. Setting it FINAL pushes its lines onto the pick-pack queue; the packing operator records the packed quantity and bins against a queue row, and the supervisor’s approval records the packed bins, releases the sales order’s stock reservation and settles the queue balance. The backend registers INTERNAL_SALES_ORDER as its only previous document; the UI also offers jobsheet, delivery order and sales invoice as knock-off sources where the Organisation Doc Flow row for that pair is enabled. The document moves nothing; the stock it packs was already put in by finalisation.

5. Nothing posts

Journal posting has no rule for any manufacturing record. Nothing in the module posts to a WIP account, and there is no absorption, no standard cost, no variance and no cost-of-goods-manufactured journal. What the ledger sees of production is what the ordinary stock documents around it post — the purchase invoice that brought the raw material in, the sales invoice that sends the finished item out. A work-in-progress figure has a place outside the module: the accountant works it out at month end and keys it on the WIP tab of the Closing Stock Balance in Chart of Account, and Month End Processing posts it (where a work-in-progress figure goes).

6. Statuses, and the one rule between them

The process status on a job order and on a process instance takes one of: REQUESTED, REJECTED, PLANNED, READY, IN_PROGRESS, COMPLETED, ON_HOLD, CANCELLED, EXPORTED, FINAL, PENDING_APPROVAL. The server holds one transition rule — a job order set to COMPLETED while any active instance is not COMPLETED is refused — but only on a status route that no screen calls; the job order form saves through the ordinary update, which checks nothing, so even that rule is the planner’s to keep. Every other transition is the applet’s choice; the applet pages say which buttons set which status.

The work-log approval is the module’s only approval, and it is the work-log screen’s own. The generic approval engine covers Purchase Order, Purchase Requisition and Stock Requisition and nothing in this module.

7. Demand, availability and reservation

Demand reaches the planner from the sales order, and a production request is not a record — it is a pair of status fields on the sales-order line (a production request status and a schedule request status). Sales sets a line to REQUESTED from the line’s MRP tab in Sales Order (Internal); the job-order applet’s Production Request screen lists those lines and lets the planner set them APPROVED or REJECTED, which saves the sales order with the two fields changed and creates nothing — the planner still raises the job order. Nothing is generated when a sales order is confirmed.

From the request’s stock-planning screen the planner can reserve bins for the job: it writes a stock reservation with a 24-hour expiry (the record the Stock Reservation Applet manages and its expiry processor releases) and a job-order temporary reservation whose expiry is never populated by the current build — the planning applet’s page records both. The Outstanding Report nets, per item and location, the ledger balance against the outstanding quantity; it is the module’s whole answer to “do we have enough”, and a person reads it — nothing acts on it.

8. What the module has no engine for

  • No material-requirements planning run, no BOM explosion into requisitions, no netting, no capacity scheduling — “MRP” is the backend package name and the sales-order tab name.
  • No WIP calculation, absorption, standard cost or variance. The accountant keys the month’s WIP value on the Closing Stock Balance WIP tab (§5).
  • No machine capacity, downtime or utilisation record beyond the machine and duration on a work log.
  • No approval on any document; the work-log approval only.
  • INTERNAL_PRODUCTION_ORDER and INTERNAL_PLANNED_ORDER are declared in the document-type enum with short codes and are used by no handler, validator or applet.

Where this leads

Configuration lists what has to exist before a job order finalises cleanly; Use cases traces the three shapes the module is used in to the records above.