Manufacturing API notes
This page is for the developer connecting a shop-floor system: how a job order and its steps are created and finalised through the API, which endpoint families that touches, and what the stock lines it writes carry. It is the manufacturing part only. There is one API for the whole platform, with no separate Manufacturing API, no separate host for it and no shop-floor key, so the path grammar, access endpoints, authentication, paging, response envelopes and error codes are on the developer integration path.
Every tenant-scoped mapping is under core2/tnt/dm/ (Core2Config.TENANT_DOMAIN_URL_PREFIX), and
the manufacturing ones under core2/tnt/dm/mrp/ (Core2Config.MRP_MODULE_PREFIX = "mrp/").
The fast path for a shop-floor integration:
- Create the job order with
POST mrp/job-orders/backoffice-ep, and change its status withPUT mrp/job-orders/update-process-status/backoffice-ep. Only the COMPLETED rule is checked there, so send statuses in the order the applets would. - Finalise a step with
PUT mrp/mrp-process-instance-hdr/update-process-status/backoffice-epand the statusFINAL, then poll the instance until itsposting_statusisPOSTED. - The stock lines it writes carry amount zero: put the cost on the manufactured item afterwards.
The document types this module produces
| Server document type | Short code | Produced by | Quantity · amount signum | Meaning |
|---|---|---|---|---|
INTERNAL_JOB_ORDER | JOBODR | Production Planning and Monitoring | 0 · 0 | The plan. No journal, no stock. Generic-document path erp/gen-doc/internal-job-orders; permissions TNT_API_DOC_INTERNAL_JOB_ORDER_{CREATE,READ,UPDATE,DELETE} |
INTERNAL_PACKING_ORDER | — | Packing Order Applet (Internal) | 0 · 0 | The pack. No journal, no stock. Path erp/gen-doc/internal-packing-orders; the backend’s previous-document connector lists INTERNAL_SALES_ORDER only while the applet’s knock-off tabs are gated by the company’s Doc Flow rows; permissions TNT_API_DOC_INTERNAL_PACKING_ORDER_* |
Two more are in the enum and nowhere else: INTERNAL_PRODUCTION_ORDER (PRDODR, 1 · 1) and
INTERNAL_PLANNED_ORDER (PLNODR, 0 · 1). No handler in GenericDocumentTypeHandler, no
validator, no applet. An integration that creates one gets whatever the generic path does with an
unregistered type; do not.
The process instance is not a server document type. Its lines become stock through
MRP_PROCESS_FINALIZATION_PROCESSOR, which writes bl_inv_txn_line rows with quantity signum ±1
and amount zero. An integration that needs a cost
on a manufactured item has to put it there afterwards.
Endpoint families an integration touches
All paths under core2/tnt/dm/mrp/ unless stated. Most controllers expose the standard
/backoffice-ep create · update · delete · get · /query set; only the additions are listed.
| Family | Path | What it is |
|---|---|---|
| Job orders | job-orders | The bl_mrp_job_order_hdr record: create, update, process_status changes (the COMPLETED rule is enforced here) |
| Job order ↔ sales order | job-order-gen-doc-link | The link a sales-order line’s MRP tab shows |
| Temporary reservations | job-orders/temp-reservations | Bin reservations held by a job order; has /permanent/{guid} delete and /posting-status |
| Job-order bins | bl_mrp_job_order_bin_links, job-bin-listing | The bin links and the listing the planning screens read |
| Process instances | mrp-process-instances, mrp-process-instance-hdr, mrp-process-instance-lines | The per-step records. PUT mrp-process-instance-hdr/update-process-status/backoffice-ep is what the supervisor screen calls; when the status sent is FINAL the service enqueues the finalisation processor and checks nothing else about the instance. GET mrp-process-instances/backoffice-ep/update-inventory-from-process-instance/{guid} runs the same stock adjustment directly |
| Work logs | mrp-process-instance-work-log, mrp-process-instance-work-log-linked | Operator logs; PUT …/update-approval-status/{guid} with a body of PENDING, APPROVED, REJECTED or REWORK |
| Definitions | mrp-process-types, mrp-process-templates, mrp-process-template-item-line, mrp-process-template-boms, mrp-process-template-machine-link, mrp-process-template-machine-file, mrp-job-template, mrp-job-template-to-process-template-link, mrp-job-template-to-process-option, mrp-job-template-to-process-option-process-template-link, process-option, process-type-checklist-attachments | The Process Maintenance master data. POST mrp-job-template/create-with-process-groups is the call that derives a job template’s stages and option groups from the BOM chain (MrpJobTemplateOrchestrationService) |
| Machines and QC | mrp-prodsys, mrp-prodsys-link, item-to-mrp-prodsys-link, mrp-prodsys-qc-checklists, mrp-prodsys-process-type-file | Machines are bl_mrp_prodsys_* records; the QC-checklist endpoints have no screen in the current build. DELETE on a machine or a process type checks nothing about templates that use it |
| Imports | mrp-process-template/import-file-hdrs and …/import-file-helpers, mrp-template-process-type/…, mrp-process-template-machine/… | The spreadsheet imports; each has a header row and helper rows processed by a job processor |
| Pick-pack queue | mrp-pick-pack-queues, bl-mrp-container-sizes, and erp/mrp-pick-pack-queue-to-gen-docs | The packing floor’s queue and the container sizes the packing order uses |
| Reports | outstanding-reports/generate-csv/backoffice-ep (CSV), outstanding-reports/backoffice-ep/outstanding-qty (POST), production-master-schedule/generate-report/backoffice-ep (CSV) | The two reports that exist — see Reports |
| Availability | job-order-availabilities | GET by criteria. No applet in source calls it |
| PMC operators | pmc-operators, pmc-operator-instances | No applet in source calls them through the shared library service |
Two things an integration must respect
- Finalisation is asynchronous and idempotent per instance. The trigger enqueues a processor;
the stock lines appear when the tenant queue runs it, and the instance’s
posting_statusturnsPOSTED. Poll the instance, not the stock balance. - The job order’s COMPLETED rule is the only server-side status check. Every other status is accepted as sent. If your integration sets statuses, it is responsible for the order the applets would have enforced.