Skip to content

Best Practices

Every item below is a consequence of something on an applet page or in the backend; none is general manufacturing advice.

1. Decide the cost of a manufactured item yourself, because finalisation carries none

Finalising a process instance takes its inputs out at their running average and brings the output in at the unit cost the output item already carries at that location. The zero amount on the line is ignored, so nothing is diluted — but nothing is transferred either: the inputs’ cost leaves inventory and the finished item never receives it. An item made for the first time at a location has no cost there, so it comes in at zero. The remedy today: decide the cost you want the finished item to carry, and set it deliberately after the finalisation with Reset MA in the Stock Adjustment applet — and do it before the item is sold, or the sales invoice’s cost of goods will be whatever the item carried before the job, zero for a first run. Check the result in Stock Balance.

2. Approve work logs before the instance is finalised, not after

The work-log approval (PENDING → APPROVED / REJECTED / REWORK) is the module’s only approval, and the backend’s finalisation checks nothing about it: update-process-status with FINAL enqueues the stock movement regardless of what the logs say. Once the instance is FINAL the quantities on its lines are what moved. Make the supervisor’s rule “no FINAL with a PENDING log”, because the system will not.

3. Finalise from the screen, and do not let an integration send FINAL

The Supervisor PI screen only enables FINAL when every line has a bin and an actual quantity; the endpoint enforces none of that. A FINAL sent through the API with empty lines finalises an instance that moved nothing. Keep FINAL a human action on the supervisor screen until the backend checks it.

4. Set the job order COMPLETED last

The server has one status rule — a job order may not go COMPLETED while any of its active process instances is not COMPLETED — but it sits on a status route that no screen calls, and the job order form saves through the ordinary update, which checks nothing. So the rule is yours to keep, and it means the word literally: a finalised instance reads FINAL, so the supervisor moves each finalised instance on to COMPLETED, and only then does the planner complete the job order, after reading the Process Instance tab. Everything else — an instance going IN_PROGRESS before the previous stage is READY, a job order CANCELLED with FINAL instances under it — is accepted as sent. Agree the order of status changes with the floor and write it on the wall; the applet will not stop a wrong one, this one included.

5. Change the job quantity on the job order, not on the instances

Editing the base quantity on the job order queues a patch that rescales every instance’s planned inputs. Editing an instance’s lines by hand leaves the other instances and the Outstanding Report describing a different job. If the quantity changes, change it once, at the top.

6. Do not edit a process template under a running job

A process instance is generated from the template at the moment the job order is raised; later changes to the template do not flow into existing instances, and the Inventory Item Maintenance Replace action on the template changes what the next job will consume, not what this one is consuming. Finish or cancel the running jobs first, or raise the changed product as a new template.

7. Expect the stock reservation to expire, and do not trust the temporary one

The stock-planning screen on a production request writes two records. The stock reservation is the record the Stock Reservation Applet manages; the screen sets its expiry to 24 hours after submission and the expiry processor releases it then. A job that waits a week for a machine has lost that reservation by the time it runs; re-reserve on the day. The job-order temporary reservation (job-orders/temp-reservations) is a second record whose expiry the current build never populates, and whose expiry processor — if it ever fires — discards the linked sales order; the planning applet’s page carries the evidence. Treat it as a note, not a hold.

8. Make Sales decide how each line is met, where a job must trace to an order

Turn on ENABLE_MRP_JOB_ORDER_LINK and MRP_MANDATORY_FOR_NON_FINISHED_GOODS on the Sales Order (Internal) applet: a line whose item does not carry the Fast Moving Goods label is held on the screen until one of its MRP-tab statuses — Production, Schedule or Existing Stock — is set to Requested, with or without a job order reserved. A Requested line is what reaches the planner’s Production Request queue; without the setting that queue holds only the lines somebody remembered to flag. The rule is the screen’s — an order created through the API is not checked — and it asks for a request, not a link: the job order is still the planner’s to raise and reserve.

9. Use Stock Conversion for a repack, a job order for a route

If the “manufacturing” is one step at one location with no machine and no operator — bundle ten units into a kit, relabel a carton — the Stock Conversion applet does it in one document. On 2026-10-06 its posting chain is not connected, so check Stock Balance after the first FINAL; and once it is, it carries no cost from the components to the kit either. Raise a job order when there is a route, a machine, a shift and a supervisor.

10. Take the scrap out of stock yourself, because scrapping does not

When the packing floor scraps a line from the Operator Queue, BigLedger writes a bin lock — a bin lock of type SCRAP, which is what the Scrap & Short menu lists. A lock is not a write-off. The scrapped material stays in stock, at its full cost, until somebody adjusts it out. The lock does two things only: while it is active, its quantity is held back from the bin’s available quantity on the bin pickers, so nobody picks the scrap again; and it appears on the Scrap & Short listing, one row per lock with the date it was made. It changes no stock balance, no cost and no account, so the only way to find out that scrap has piled up is to open that listing and look. A business that scraps three per cent of what it runs and leaves the locks alone overstates its stock and understates its cost of sales by that three per cent, every month, compounding.

So somebody has to do it, and this is the part of the job the software does not do:

  • Who. The production supervisor together with whoever is responsible for the stock at that location — the two of them, because one of them knows what was thrown away and the other has to live with the valuation.
  • When. At each period end, before the stock figures go to the accounts. Not when the scrap happens: the locks are the running record and the write-off is a periodic act.
  • What. Open Scrap & Short, take the period’s rows by their created date, total the locked quantity per item and location, and raise a matching adjust-out in the Stock Adjustment applet against an expense account you have agreed for scrap — so the loss lands in the profit and loss where it belongs rather than sitting in inventory pretending to be an asset.
  • How you know you got it right. The quantity you adjusted out and the scrap total for that period agree. The adjustment does not remove the locks, so the listing does not clear when you write the scrap off; keep the adjustment’s reference beside the period’s total so next month’s reader can tell written-off rows from new ones. If the two disagree, the difference is either scrap somebody recorded twice or material somebody threw away without recording — and both are worth the five minutes it takes to find out which.

Agree the scrap expense account before the first job runs, not at the first month end.

11. Three checks worth doing

  • Weekly: the bins and quantities the next jobs need, against Stock Balance at the location. Do not use the Outstanding Report’s Net Outstanding for this: its Outstanding Qty is not the open-order figure it appears to be — see Reports.
  • After every finalisation: the finished item’s moving-average cost in Stock Balance — item 1.
  • Monthly: the work-log historical table for logs that went APPROVED → REJECTED after the instance was FINAL; those quantities moved anyway.
  • Every period end: the Scrap & Short total against the scrap adjustment you raised — item 10.