ERP Integration Check

Why does the sendMO WebDev resource pass the request body to trainingERP.sendMO(body) instead of containing the order logic itself?

The endpoint should handle only HTTP concerns: the request, the response, the status code, the content type, and basic exception handling. Keeping the business logic in a project script library makes it easier to test, reuse, maintain, and version, and lets other workflows call it too. See Create Web Service.

Which Ignition project should hold the ERP integration scripts and WebDev resources, and why?

KANOA_SCRIPTS. It is intended for client custom scripts such as the ERP interface, it is installed only once, and it is never overwritten on module updates, unlike kanoaAPP. See Kanoa Ignition projects.

The ERP simulator sends an order for an item that doesn't exist in Kanoa. What does sendMO do?

It creates the item, in the item class from itemClassPath, and then creates the production order. It also creates the unit of measure and the ERP order source if they're missing, so the same order can be sent again safely: an existing order is updated, not duplicated. See Create Web Service.

Why does sendMO look up the Released status and the Production mode by name instead of hardcoding their IDs?

Database IDs can differ between systems, so a hardcoded ID that works on one gateway may be wrong on another. Names are stable, so the script looks up IDs by name. See Create Web Service.

Why does sendMO save the received payload as apiBody metadata on the production order?

So you can see exactly what ERP sent for each order, which helps with troubleshooting. Production order metadata stores extra name/value data against an order, and you can view it by expanding the order on the Production Orders screen. See Order Management.

ERP calls the packing line AP01, but in Kanoa it is Manual Pack 1. How does the scheduling script know which asset to schedule the order on?

You add an erpName custom attribute to Manual Pack 1 with the value AP01. The script matches scheduleInfo.assetName in the payload to that attribute, so you can keep the names operations uses while still linking to ERP. See Get Orders from ERP.

When Kanoa sends order status back to ERP, why send only workOrderName, itemName, reqdQty, and actualQty instead of the whole production order?

ERP defined the payload it expects: those four fields wrapped in a parent order dictionary. The Kanoa production order contains many fields ERP doesn't need, so you send only the agreed fields. See Send Order Status to ERP.