Every manufacturing programme eventually answers the same question, usually without ever having asked it: which system owns the executable routing? Not the bill of material, not the order — the sequence people actually work to at the workstation. In most projects that answer falls out sideways, as a by-product of a module choice, and it still decides which licences are needed, what ends up being traceable, and what still reconciles at period end.
In JPS-iQ Manufacturing we draw that boundary deliberately, once, before anything is configured. This piece describes where we draw it and why — not what the product can do today. We come back to that distinction at the end.
The question no module list answers
Manufacturing conversations are almost always about functions: who does lot tracking, who does shop-floor confirmation, who does actual costing. But the question that decides the architecture is not a function question. It is an authority question. Which system holds the truth about what should happen at the workstation — and which holds the truth about what did?
The ERP is strong on the first half of a different question: what was ordered, what it may cost, what it is worth. The executable process is a different object altogether. It consists of operation sequence, steps, resources, setup data, parameters, instructions, checks, readiness conditions and consumption points. It changes with the product, not with the order. And it has to be versioned, because "which version was this order built to" gets asked at the first complaint at the latest.
Put both of those in the same field and nothing errors. You simply get a system in which a process change, looked at afterwards, appears to have always applied.
What the ERP should own — and what it should not
In the first cut we built, NetSuite is the ERP, and the split is stated explicitly. NetSuite stays authoritative for the work order, assembly item, bill of material and components, quantity, dates, locations, lot authority per attribute, valuation, ledger and posting. That is, for everything that counts commercially and on the balance sheet.
JPS-iQ owns the versioned executable process definition — the list from the previous section. An existing NetSuite routing definition is adopted or referenced where one exists. It is neither ignored nor maintained twice.
This boundary is a decision, not a technical necessity. You can draw it elsewhere. What matters is that it gets drawn at all, in writing, before the first operation is created — otherwise it draws itself, and it does so wherever the tool at hand happens to offer least resistance.
The licence question that rarely gets asked
One consequence of that split has more practical effect than the architecture itself: a NetSuite routing definition is not a prerequisite. A NetSuite account without Manufacturing WIP and without routings has to be able to run the flow. Additional NetSuite licences are not set as a general precondition.
That reads like a footnote and is in fact the entry question. In many manufacturing projects there is a module at the start that has to be bought before you are allowed to begin. That sequence is rarely recognised as an architecture decision, although it is one: it sets the price of the first auditable run — which is precisely the run that shows whether the model holds.
What going without costs you
Honesty requires the other side of it. Without WIP, actual times per operation stay facts on our side. They are not posted to NetSuite. Anyone who needs operation times in the general ledger — because actual costing builds on them, or because the auditor wants to see them there — needs WIP, and at that point the licence is not a luxury but part of the requirement.
The gain is not that WIP is never needed. The gain is that it becomes a decision instead of a default. Those who need operation times in the ledger get them deliberately. Those who do not are not paying to find out whether they do.
One run, from order to completion
The first cut takes a released NetSuite work order through to an auditable completion. The stations: intake, process resolution, readiness, execution, lot consumption, output, completion check, posting intent, delivery, read-back. Completion is recorded as an assembly build against the work order; lot and quantity are captured, and the document reference is read back.
That last station is the one most often missing. A completion that is not read back is a claim, not a fact. Between "we posted it" and "the system confirms the posting with a document reference" sits the entire difference between an interface that works and one everybody assumes works.
What we are building — and what we are not claiming
JPS-iQ Manufacturing is in development. Release 1 concentrates on exactly this one flow, with NetSuite as the first and only productive ERP connection. The core stays ERP-neutral; NetSuite coming first is the integration order of this cut, not a statement that the product logic is NetSuite-specific.
And the limitation we wrote down for ourselves before anyone else could phrase it: our own product documentation describes target capabilities. It does not evidence that every function is already implemented, deployed or formally accepted. This piece therefore claims no availability. It describes a design decision you can examine before there is anything to buy — and when there is delivery evidence per package, it will be stated here.
Where to take this from here
The boundary question can be answered before any product is involved, and it is worth answering even if you end up staying on plain NetSuite standard. Three questions are enough for a first read: is your routing versioned, and do you know, for every completed order, which version it was built to? Do you need actual times per operation in the general ledger, or only in reporting? And which module would you have to buy today purely to be able to demonstrate the first auditable run?
If the third question has an expensive answer, the conversation is worth having regardless of which system wins in the end.