Production Planning and Monitoring Applet

The production planner’s desk: the sales-order lines Sales has flagged for production, the job order raised for a finished item against a job template, and the process instances the shop floor will run. Nothing here posts to the ledger and the job order itself moves no stock — stock moves only when a process instance is finalised in Manufacturing Operations, and no cost passes from the inputs to the finished goods, which keep the unit cost they already had at that location (zero if never costed there). Approving a production request creates no job order; the planner raises it in Master List and links the sales-order line by hand.

Your job, and the screen for it

Overview

The Production Planning and Monitoring applet is the production planner’s desk. It lists sales-order lines that Sales has flagged for production, lets the planner approve or reject each one, raise a job order for a finished item against a job template, expand that template into the process instances the shop floor will execute, and compare outstanding demand with stock on hand. It sits between the Sales Order (Internal) applet, where the request is flagged, and the Manufacturing Operations applet, where operators log work against the instances it generates.

The registry name of the applet is Production Planning and Monitoring Applet; its registry code is productionPanningAndMonitoringApplet (the typo is in the product). The source repository is named after the job order, and the sidebar title in the build reads “Production Planing & Monitoring Applet”. Nothing in this applet posts to the general ledger, and the job order itself moves no stock; stock moves only when a process instance is finalised (see Lifecycle and effects).

Where it fits

A second, industry-specific build of this applet exists with the same Master List, Processes and Sales Order screens but without Production Request and Outstanding Report. The Applet Store installs the general build only; the industry build is not offered there. This page documents the general build, which is the one you get.

Screens and menus

The sidebar has six entries plus Settings and Personalization. The applet opens on Master List.

Two further screens exist in the build but cannot be reached from any menu: a Requested Job Order listing (job orders in REQUESTED or REJECTED status, with approve-to-PLANNED and reject actions) and an Orders to Produce listing (unresolved sales orders by job). They are described here only so that the names are not mistaken for missing features.

Production Request is a sales-order line, not a document of its own. There is no production-request record anywhere in the product. The screen lists sales-order lines that carry one of the three MRP request statuses, and saving the view saves the whole sales order with the line’s (P) status, (S) status and MRP remarks changed. The status drop-downs in this applet offer –None–, APPROVED and REJECTED; REQUESTED is shown but disabled, because it is set on the other side — the MRP tab of the sales-order line in Sales Order (Internal) offers exactly the opposite set (REQUESTED enabled, APPROVED and REJECTED disabled). Nothing generates a request automatically when a sales order is confirmed, and approving a request does not create a job order: the planner raises the job order in Master List and links the sales-order line on its Sales Order Link tab.

The Stock Planning tab of a production request has two grids. The upper one lists job orders for the same item with their available (ad-hoc) quantity, reserved quantity, temporary reservations and estimated completion date; Reserve opens a dialog capped at min(available − reserved − temporarily reserved, sales-order line quantity) and creates a temporary job-order reservation against the line. The lower one lists bins with total, available, locked, reserved and packed quantity; Reserve there creates a stock reservation set to RESERVED with an expiry of the next calendar day, and a bin-reservation link expiring 24 hours later, through the same endpoints the Stock Reservation applet uses. The dialog’s text “this reservation will expire 24 hours after submission” is not true of the job-order temporary reservation — see Lifecycle and effects.

The Process Instance tab of a job order lists the instances generated for it (process, machine, output item, status, Active?). Generate Process Instance is enabled once and disabled after the instances exist; the + button adds a single instance by choosing a process template by hand; the Active? cell switches an instance off so a step can be skipped.

The Sales Order Link tab lists linked sales-order lines with order quantity and job-order quantity. Add lists sales orders for the item with Order Qty (line quantity minus quantity already on job orders) and an editable Qty To Add; the sum of the added quantities becomes the job order’s Sales Order Quantity.

The Stock Balance Summary (Sales Order menu → Item Details) shows system stock balance, total sales-order quantity, total reservation quantity, total quantity on incomplete job orders, and available stock with and without reservations, with Details drill-downs into the reservations and the job orders. It reads the same summary as the Stock Availability screens.

This page is illustrated in words only at present. The seventeen images the previous version of this page embedded all showed a live tenant’s code, branch codes, customer names, item codes or a user’s photograph, and were removed on 2026-09-15.

Configuration

Before you can use it

Applet settings

Settings are saved together, once per tenant for this applet. Anyone who can open Settings can change them; the applet has no client-side permission screen of its own. Each row below has a working control and is read by a screen.

Keys declared in the settings model but rendered by no control in this applet (ENABLE_DIMENSION, ENABLE_PROFIT_CENTER, ENABLE_PROJECT, ENABLE_SEGMENT, ENABLE_SST, ENABLE_WHT) are not documented as settings; the Department tab shows its four fields unconditionally.

Document behaviour settings

None. The job order has no posting-status or workflow settings; its process status is set directly on the form. There is no approval engine behind APPROVED / REJECTED on a production request — they are two strings on the sales-order line.

Settings in other applets that control this applet

Feature visibility / permissions

Server-side: the four TNT_API_DOC_INTERNAL_JOB_ORDER_* permissions on the job-order document type. Client-side: none — the applet defines no SHOW_* / HIDE_* client-side permissions and none are registered for it.

Fields

Job order — Main Details

Job order — Department Hdr

Segment, Profit Centre, Dimension, Project — the four accounting dimensions, all optional, shown unconditionally.

Job order — Process Instance (create tab)

Process Instance Group (the job template group for the item) — required by the server before Generate Process Instance can run (“THE TEMPLATE HDR GUID IS NOT POPULATED”).

Production request — Main

All fields are read-only copies of the sales-order line (doc short code, doc number, company, branch, item, base quantity, UOM, customer, sales agent, transaction date, (Ex) Existing Stock status) except (P) Production Status, (S) Schedule Status (–None– / APPROVED / REJECTED) and MRP Request Remarks.

Lifecycle and effects

Posting proof block. Server document type Job Order (Internal) · amount signum 0 · quantity signum 0 · Dr/Cr equation none — nothing is journalled for the type · GL precedence not applicable · stock processor none at document level · VOID not applicable (the job order has no posting status; it is deleted, and deleting it removes its sales-order links).

What moves stock is the finalisation of a process instance, not anything on this applet’s screens. When an instance reaches FINAL, the finalisation run writes one inventory transaction per INPUT line (quantity signum −1) and per OUTPUT line (+1) and the stock balance is updated from those. Every such line is written at an amount of 0, and the amount is ignored: each item is costed at its own unit cost at that location, so the inputs’ cost never reaches the finished goods, which come in at zero only if they have never been costed there. No journal is posted by any manufacturing run.

Job-order status is one of REQUESTED, REJECTED, PLANNED, READY, IN_PROGRESS, COMPLETED, ON_HOLD, CANCELLED, EXPORTED, FINAL, PENDING_APPROVAL; the form offers five of them. The server holds one transition rule, refusing COMPLETED while any of the job’s active process instances is not COMPLETED (“SORRY! NOT ALL PROCESSES ARE COMPLETE, THEREFORE THIS JOB IS NOT READY TO BE COMPLETED…”), but only on a separate status route that no screen calls. The Master List form saves the status through the ordinary update, which validates no transition, so a job order can be set to COMPLETED here with instances still open. The check is the planner’s: before completing a job order, open its Process Instance tab and confirm every row with Active? ticked shows COMPLETED.

Generate Process Instance reads the job template group’s process-template links, renumbers them by sequence, and creates one process instance per link with the template’s process, machine, output item, the job order’s branch and location, and the link’s parent and group. Changing the job order’s base quantity afterwards queues a background job that re-scales the planned inputs.

Sales-order link. Adding a line records the link with the added quantity; the client refuses a Qty To Add above the line’s remaining order quantity and, once instances exist, above the job’s total quantity. Both checks are screen-side toasts; the server checks only that the referenced records exist.

Job-order temporary reservation adds the reserved quantity to the job order’s temporary-reservation total. A temporary reservation can carry an expiry, and the expired-reservation clean-up job acts on any that have passed it — it sets the linked sales order’s posting status to DISCARDED and permanently deletes the reservation. Nothing on this screen or on the server sets an expiry, so reservations created here never expire and are never picked up — the “24 hours” hint in the dialog describes nothing that happens. If a reservation were ever created with an expiry, its expiry would discard the customer’s sales order.

Outstanding report and the figure called outstanding on the packing floor do not agree. The figure the Packing Order (Internal) applet’s Auto Coil Supervisor fetches when an output line is added is the ledger balance at that line’s location less the open quantity on posted (FINAL) sales orders across all locations. The exported report’s Balance Qty is the location’s ledger quantity, but its Outstanding Qty adds up only the quantity on sales orders still in draft at that location — an order drops out once it is finalised, even while it still owes stock — so its Net Outstanding is not a shortfall you can plan against. Use Balance Qty from the export and compare it with your open sales orders yourself (see Manufacturing reports). Either way it is a query, not a planning run: there is no materials-requirement explosion, no purchase suggestion and no scheduling engine behind it.

The four manufacturing applets together

A job order is planned here and carried out across the folder’s other three applets. This section, formerly the Manufacturing folder’s overview, follows a job through all four.

What each applet writes, and the one step that moves stock

The four applets share one set of production records and are used in this order.

Why the finished item does not carry the cost of its materials. Each line the finalisation run writes carries an amount of RM 0, which costing ignores: the materials leave at their running average, and the item made comes in at the unit cost it already carries at that location. If it has never been costed there, that is RM 0. Neither unit cost moves; the materials’ cost leaves inventory and reaches no finished item (what moves stock, and at what value). Until that changes, the accountant decides the finished item’s cost and sets it with Reset MA in Stock Adjustment before the item is sold (best practice 1).

Choosing a manufacturing tool for the job

The production figures, and what makes each

When manufacturing looks wrong

Checking that a job ran

Reopen the finalised instance on Supervisor PI. Its FINAL button is greyed because the finalisation run marks the instance POSTED, and the button stays off on a POSTED instance; if FINAL is still live after you pressed it, the run has not finished. Then open Stock Balance at the job order’s location: since the FINAL, each input item has fallen and each output item has risen by the instance’s actual quantities. Then read the finished item’s moving-average cost. If it reads RM 0 or an old figure, nobody has costed it yet. Last, open the job order’s Process Instance tab: every row with Active? ticked should read COMPLETED before the job order does. That is about a minute per job, and it catches the three silent gaps: a run that has not finished, a cost nobody set, and a job closed early. The module’s three checks worth doing carry the weekly, monthly and period-end versions.

What these applets leave to people, and who does it

• Cost the finished item. No step transfers the materials’ cost. The accountant decides the cost, sets it with Reset MA after each first run and before the sale, and checks it in Stock Balance.
• Post any production journal. Nothing in the module is journalled: nothing posts to a work-in-progress account, and there is no labour or machine absorption and no variance. The accountant works the month’s WIP value out from the open job orders and keys it on the WIP tab of the Closing Stock Balance in Chart of Account, which Month End Processing posts; absorption and variance, where the accounts need them, are a manual journal in Financial Accounting built from the quantities (what posts to the ledger).
• Plan materials. There is no requirements run, no purchase suggestion and no capacity scheduling behind “MRP”; it is the module’s name. The planner reads Stock Balance and the open sales orders and raises purchases by hand.
• Close a job order honestly. The status rule on the server is not applied by the form. The planner confirms every active instance reads COMPLETED first.
• Hold material. The Stock Planning tab’s job-order temporary reservation earmarks output and holds no material; a stock reservation does, and the planner makes it on the day the job runs.
• Write off scrap. The production supervisor and the stock owner total the Scrap & Short listing at each period end and raise the adjust-out.
• Approve anything through Approval Settings. The work log’s PENDING, APPROVED, REJECTED and REWORK and the packing supervisor’s Approve button are the module’s own approvals, and neither uses the approval engine; who holds SHOW_SUPERVISOR_VIEW is the control.

Prerequisites, blast radius and siblings

• Must exist first: every input, output and finished item in Inventory Item Maintenance; a process template whose output is the finished item, or the job template stops with “No BOM options found for this item”; a job template, or the job order form has no group to offer; machines typed Packing for the packing screens, which list no other; bins at the job’s location; the SHOW_SUPERVISOR_VIEW client-side permission for whoever presses FINAL, or Supervisor PI opens on 404; for packing against a sales order, a Doc Flow row from the sales order to the packing order in Organisation, or there is no KO For tab.
• Downstream: the FINAL is what lets you sell what was made; the stock it writes is what the Sales Invoice later takes out, at whatever cost the finished item carries by then; the sales order’s reservation is released by packing approval; the work logs and quantities are all a manual production journal has to go on.
• Siblings, and when to choose which: Stock Conversion for a one-step repack, a job order for a route; a stock reservation to hold material, never the job-order temporary one; a bundle when the item is never made at all, only sold as a set.
• Blast radius, or what breaks elsewhere: a finished item sold before anyone costs it goes out at the cost it carried before the job, RM 0 after a first run, so the margin on that sale is overstated by the materials’ cost; another item’s group on a job order runs the wrong steps and consumes the wrong materials; a packing approval empties a reservation other lines were relying on; an unwritten scrap lock overstates stock until period end.
• Used together: Sales Order (Internal), Production Planning and Monitoring, Manufacturing Operations and Packing Order in that order on a make-to-order job, alongside Stock Adjustment after each first run and a Stock Reservation on the day a job starts.

Related applets

• Process Maintenance — defines the machines, process types, process templates and job templates that a job order’s Process Instance Group drop-down lists.
• Manufacturing Operations — where supervisors prioritise and operators log work on the process instances generated here; finalising an instance there is what moves stock.
• Packing Order (Internal) — packs job-order output; its own Job Order and Production Request screens read the same tables.
• Sales Order (Internal) — the MRP tab of a sales-order line is where a production request starts; the Sales Order Link tab here points back at it.
• Stock Reservation — the bin reservations made from the Stock Planning tab are ordinary stock reservations and appear there.
• Stock Balance and Stock Availability — the Stock Balance Summary and the Outstanding Report read the current-location stock balance.
• Inventory Item Maintenance and Organization — the item, branch and location a job order is raised for.

Troubleshooting

Related documentation

• Manufacturing module
• Process Maintenance applet
• Manufacturing Operations applet
• Packing Order (Internal) applet