# ERP Integration Check

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

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](../03-erp-connectivity/1-create-endpoint.md).

</details>

<details>
<summary>Which Ignition project should hold the ERP integration scripts and WebDev resources, and why?</summary>

`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](../../1-kanoames-overview/1-projects.md).

</details>

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

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](../03-erp-connectivity/1-create-endpoint.md).

</details>

<details>
<summary>Why does sendMO look up the Released status and the Production mode by name instead of hardcoding their IDs?</summary>

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](../03-erp-connectivity/1-create-endpoint.md).

</details>

<details>
<summary>Why does sendMO save the received payload as apiBody metadata on the production order?</summary>

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](../../../kanoa-ops/order-management.md).

</details>

<details>
<summary>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?</summary>

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](../03-erp-connectivity/2-scheduling-orders-from-erp.md).

</details>

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

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](../03-erp-connectivity/3-send-order-status-to-erp.md).

</details>