Configuration

The order below is the dependency order: each step’s records are picked from a list in the next. The previous version of this page had five “phases” including WIP and overhead GL mapping, labour cost rates and a smoke test that “confirms WIP assets increase”; nothing in the module posts, so those phases had nothing to configure. Each applet page’s Before you can use it table is the authority for its own step; this page only puts them in order.

1. Items and the location that makes them

Every input and output on a process template is an inventory item picked from Inventory Item Maintenance, so raw materials, intermediates (a cut length, a coiled length) and finished items all exist first, each with the UOM the floor will log in. The item’s Process Template tab stays empty until step 3. The workshop is a location under a branch in the Organisation Applet; finalisation moves stock at the branch and location on the process instance, so a job at a location that does not hold the inputs stalls at bin selection.

2. Machines and process types

In Process Maintenance: one Machine record per physical machine (typed Production or Packing; the code is unique on the backend), and one Process Type per kind of step, in the sequence they occur (its code is checked for uniqueness only in the browser). Neither can be picked on a template until it exists. Deleting either is guarded only in the browser — the API deletes a machine that templates still link to.

3. A process template per step, a job template per product

Still in Process Maintenance: a Process Template for each step — its process type, input and output items with their ratios, the machines that can run it and a default among them — and then a Job Template per finished item. You name the item; the backend derives the stages and their process options by walking from the templates that output the item down through their inputs, so the templates must exist, with the right outputs, before the job template is created. The CSV import (Import Process Template) loads templates in bulk; the applet page lists the columns. Once templates exist, the item’s Process Template tab in Inventory Item Maintenance shows them.

Do not expect a template change to reach a running job, with one exception. A job order’s process instances, and their input and output lines, are copied from the templates when Generate Process Instance is pressed on the job order, and editing a template afterwards changes none of them. The exception is the input ratio: changing the job order’s base quantity queues a background job that re-plans the existing input lines at each template’s current ratio, so a ratio edited since the instances were generated takes effect on that job at that moment.

4. The planning applet’s defaults and the sales-order link

Production Planning and Monitoring needs its Default Selection — company, branch and location — set for each planner, or every job order form starts empty. Its Custom Status and Email Template screens are optional. To make whoever keys a sales order decide, line by line, how each line will be met, turn on ENABLE_MRP_JOB_ORDER_LINK and MRP_MANDATORY_FOR_NON_FINISHED_GOODS in the Sales Order (Internal) applet’s line settings: a line whose item does not carry the Fast Moving Goods label then cannot be added or saved until one of the three statuses on its MRP tab — Production, Schedule or Existing Stock — is set to Requested. The screen enforces this; the API does not. A status is a request, not a link: the requirement is met whether or not any job order is reserved for the line.

5. The floor applet’s defaults, and the settings screen that saves nothing

Manufacturing Operations needs DEFAULT_BRANCH, DEFAULT_LOCATION and DEFAULT_COMPANY under Default Selection; the tab order of the work-log form is a personal setting. Its Application Settings screen renders toggles and a SAVE button that are bound to nothing — the applet page documents it as inert; do not spend time there. Supervisor access is the SHOW_SUPERVISOR_VIEW client-side permission, checked by the route guard; the operator view is declared with a bypass and is effectively open to anyone who can install the applet.

6. The packing applet’s document settings

Packing Order Applet (Internal) is a document applet and has the document settings the others do not: Field Settings, Printable Format Settings, Return Reasons Settings, Email Template and Workflow Settings — the last being the ordinary Workflow Design custom-status mechanism, not an approval. Container sizes and the WOOD / STEEL drum types are picked on the packing screens; the applet page lists what each setting does and which knock-off the UI offers.

7. Permissions — your only control

The backend gates the two documents with the ordinary create / read / update / delete permissions — TNT_API_DOC_INTERNAL_JOB_ORDER_* and TNT_API_DOC_INTERNAL_PACKING_ORDER_* — and gates nothing about status transitions, finalisation or work-log approval beyond that. Client-side permissions exist for two of the four applets — SHOW_OPERATOR_VIEW and SHOW_SUPERVISOR_VIEW, for both Manufacturing Operations and Packing Order Applet (Internal) — and for neither Process Maintenance nor Production Planning and Monitoring (0 rows each). SHOW_SUPERVISOR_VIEW is the one that matters: it opens the supervisor screens in both applets. The packing-order applet also checks some two dozen SHOW_* column and button codes that have no definition row, so they can be granted to nobody; each applet page says what its own code checks.

What success looks like

Raise one job order for one unit from one job template, log one work log, approve it, set the instance FINAL, and then open Stock Balance at the workshop location: the input quantity is down, the output quantity is up, the job’s next instance is READY, and the output item’s moving-average cost is unchanged — or 0.00 if the item had never been costed at that location. That last one is not a misconfiguration — finalisation costs each item at its own unit cost and carries nothing from the inputs across — and the first thing to decide before going live is who sets the finished item’s cost, and when (Best practices item 1).

Common mistakes