Process Maintenance

The manufacturing master data a job order needs before anyone can plan or run production: machines, process types, the process templates that say what one step consumes and produces and on which machine, and the job templates that tie a finished item to its chain of steps. Open it first: the job order form will not save without a process group, and a group exists only once a job template has been set up here. The form’s group drop-down lists every item’s groups, not only the item’s own, so an item with no job template of its own can still be given another item’s group — and its process instances then follow that other item’s chain. Set up the job template for each item you make, and pick the group named after it. Nothing here posts a journal or moves stock, and the MRP in its address is the module’s name, not a material requirements planning engine; there is none.

Overview

Process Maintenance is the manufacturing master-data applet. It holds the four things a job order needs before anyone can plan or run production: the machines on the floor, the process types that classify and sequence work (drawing, stranding, insulation, packing…), the process templates that say what one step consumes, what it produces, and on which machine, and the job templates that tie a finished item to the chain of process templates that makes it. A CSV import creates process templates in bulk.

It is opened by whoever owns the production recipe — a process engineer or a system administrator — and it is opened first: the Production Planning and Monitoring applet cannot raise a job order for an item that has no job template, and the Manufacturing Operations applet only ever runs process instances generated from these templates.

Nothing in this applet posts a journal or moves stock. Stock moves once, later, when a process instance is finalised (see Lifecycle and effects).

The MRP you will see in the applet’s address is the name the platform gave this module, not a material requirements planning engine — there is none.

Where it fits

    flowchart LR
  M[Machine] --> PT[Process Template]
  T[Process Type] --> PT
  I[Inventory item] -->|input / output BOM lines| PT
  PT -->|options derived from BOM| JT[Job Template]
  I -->|finished item| JT
  JT -.->|job order, process instances| PP[Production Planning<br/>and Monitoring]
  

Screens and menus

The sidebar has five entries. A sixth, QC Specifications, is not available in the current build.

Each listing opens a create form (+) or an edit form (row click). Edit forms are tabbed:

• Machine — Main, Parameters (ad-hoc Field Name / Field Type custom fields), Item Linking.
• Process Type — Main, Attributes (custom fields), Item Linking, Machine Linking, Attachments.
• Process Template — Main, Output Items, Input Items, Machine Used, Machine Spec (attachments), plus a QC tab on create (Custom Fields, Attachments). The tab order is configurable (below).
• Job Template — Main, Process Group. (The create form has one tab, Item Details.)

Settings (lands on Field Settings): System Configuration → Field Settings, Default Selection · Server Side Permissions → Permission Wizard, Permission Set, User Permission, Role Permission · Integration → Triggers (webhook) · Developer Tools → Release Notes, Audit Trail. Personalization has one item, Default Selection, and the sidebar editor.

Configuration

Before you can use it

Applet settings

Anyone with access to the Settings menu can change the settings below.

Field Settings

Default Selection

Personalization → Default Selection saves nothing. The screen opens blank, because the code that would load your current values is switched off, and it is never handed the applet’s settings, so a branch or location you pick is not recorded and SAVE has nothing to send. Since no form reads the applet-wide values either, nothing is lost — but do not rely on it as a per-user override.

Document behaviour settings

Not applicable — this applet creates no document. There is no status flow, posting, printable, approval or e-Invoice control anywhere in it.

Settings in other applets that control this applet

None found. The item pickers respect whatever the item masters hold, but no setting in Inventory Item Maintenance or Doc Item Maintenance changes how this applet behaves.

Feature visibility / permissions

• Server-side. Every save, read, update and delete in this applet is guarded by a server-side permission per record type; the Permission Wizard / Set / User / Role screens assign them. The wizard’s targets are Company, Entity, Location, Branch, Tenant, Applet, Team and Hostname — the standard set, nothing manufacturing-specific.
• Client-side. There is no client-side permission screen in this applet and no client-side permission definitions are registered for it. Whoever can open the applet can see and edit everything in it.

Fields

Machine (Main tab)

Description and Remarks are free text, both shown as listing columns. The code is turned to capitals as you type it. Name and code cannot be changed after the first save — both are read-only on the edit form (the lock is the screen’s: the server’s update would accept a new, unique code) — so a mistyped code means a new machine and deleting the old one.

Other tabs: Parameters — free Field Name / Field Type custom fields kept with the record; Item Linking — links the machine to financial items. The link does not protect the item: deleting a financial item is not checked against its machine links, and the delete clears those links away with the item.

Process Type (Main tab)

Description (also a listing column) and Remarks are free text.

Other tabs: Attributes (custom fields); Item Linking and Machine Linking (stored with the type; nothing outside this applet reads them today); Attachments (columns Title, File Name, Size, Uploaded Date, Uploaded By).

Process Template

Main

The Main tab also takes a free-text Description.

Output Items / Input Items — one row per line, added through the BOM form:

Each line also takes a free-text Description. With ENABLE_MULTI_OUTPUT_PROCESS_TEMPLATE off the Output Items tab takes one row.

Machine Used — the machines this step can run on (Machine Code, Name, Description, Default Machine? checkbox). Only one default is allowed — the checkbox is disabled once a default exists. The Main form has no machine field of its own; machines are assigned only here.

Machine Spec — file attachments, opened from the tab or shared through a public link.

Job Template

Main

The tab also offers an optional Process Type and a free-text Description (a listing column). The server checks that a chosen process type exists, and then nothing reads it: it does not narrow the options, and job orders do not use it. The form carries Job Template Name and Job Template Code inputs too, but they are hidden and never sent — a job template is always named and coded after its item.

Process Group is not typed in; it is derived. See Lifecycle and effects.

Import Process Template

One .csv per upload, processed row-by-row. Column order:

PROCESS_TEMPLATE_CODE, PROCESS_TYPE_CODE, TEMPLATE_TYPE, TEMPLATE_DESCRIPTION, MACHINE_1_CODE … MACHINE_4_CODE, OUTPUT_ITEM_CODE, OUTPUT_UOM, OUTPUT_RATIO, OUTPUT_DESCRIPTION, INPUT_1_ITEM_CODE, INPUT_1_UOM, INPUT_1_RATIO, INPUT_1_DESCRIPTION … INPUT_7_*

So one file row = one process template with up to four machines, one output and seven inputs. The edit view of an import shows All rows and Error rows (Short Error Message, Error Stack Trace, then the row’s columns). A Sample Format for Process Template link on the upload panel points at the template file.

Lifecycle and effects

This is master data: every screen saves directly and nothing posts. The one exception in behaviour is the job template, which generates data:

Job template creation is asynchronous and derives the options. Save on the create form starts a background task and the form polls until it finishes. Behind it, BigLedger:

1. creates the header;
2. finds every process template whose output line is the job template’s item, and for each one walks its input lines recursively — each input that is itself the output of some process template opens the next level — until it reaches items nothing produces (raw material). Every distinct path is one option; every link records its level so the Process Group tab can show a sequence;
3. stops with “No BOM options found for this item” if no process template outputs the item, and “Option group n has N BOMs (max 30) - possible data issue” above thirty links in one option;
4. saves one link per step, naming the group <item name>-OPT-<n>.

The Process Group tab lists the links grouped by name — <item name>-OPT-1, -OPT-2 and so on — with Process Template, Output, Input, Process Type (its code) and Sequence. That grouping is what a job order is raised against. The tab is read-only: there is no screen that renames a group or regroups its links, so the generated -OPT-n names stand as they are.

Delete guards. The server does not check whether a machine or process type is in use before deleting it. The guard is on the edit form: the Machine edit form looks for process templates that use the machine and the Process Type edit form looks for templates of the type; if either finds any, the DELETE button is disabled and the message Can’t Delete, The Machine/Process is being used is shown. A deletion issued outside the form is not stopped.

Where stock moves. Not here. A process template’s BOM lines are copied onto process-instance lines when a job order is planned; when the instance is finalised, the finalisation run turns INPUT lines into stock-out and OUTPUT lines into stock-in inventory transactions. Those transactions carry no cost from inputs to output, so the ratios you enter here drive quantities only — each item is costed at its own unit cost at that location, and a finished item never costed there comes in at zero. The job order and packing order documents themselves post nothing to the ledger.

Job order completion (downstream, but set up here): the server has a rule that refuses COMPLETED on a job order while any of its active process instances is not COMPLETED — “SORRY! NOT ALL PROCESSES ARE COMPLETE…” — but it sits on a status route no screen calls. The job order form in Production Planning and Monitoring saves through the ordinary update, which does not check, so the check is yours: confirm every active instance reads COMPLETED before completing the job order.

Related applets

• Production Planning and Monitoring — raises job orders against a job template’s process group and generates process instances from its process templates.
• Manufacturing Operations — supervisors and operators work the process instances; the default machine and the input/output lines come from here.
• Packing Order (Internal) — the packing line uses PACKING templates and Packing machines.
• Inventory Item Maintenance — every input, output and finished item.
• Doc Item Maintenance — the financial items a machine or process type can be linked to; deleting such an item clears its machine links rather than being stopped by them.

Troubleshooting

Related documentation

• Manufacturing module — how the four manufacturing applets fit together.
• Production Planning and Monitoring — the next applet in the flow.