IFS Cloud and Orderful integration

What moves between them

Purchase orders and supplier invoices flow from IFS Cloud to Orderful. ml-connector polls IFS Cloud's PurchaseOrderSet and PostingProposalHeadSet on a configurable schedule, translates each order and invoice to EDI 850 and 810 format, and POSTs them to Orderful via the /v4 endpoints for delivery to trading partners. Inbound 855 purchase order acknowledgments and 856 ship notices are retrieved from Orderful via polling or webhook, matched to the original IFS purchase orders by order number and supplier ID, and written back into IFS Cloud as updates to the purchase order state and as new vouchers for received goods. Supplier master data is synced bidirectionally so partner changes in Orderful are reflected in IFS Cloud's SupplierSet.

How ml-connector handles it

ml-connector stores the IFS OAuth client credentials and tenant URL, and the Orderful API key. It polls IFS Cloud at a frequency you configure (e.g., every 10 minutes for orders, every 30 minutes for invoices) using OData $filter queries on the IFS CloudSystem LastChangeDateTime field to capture only new or modified records. For each purchase order, ml-connector maps the IFS PurchaseOrderSet fields (order number, supplier, items, quantities, dates) to EDI 850 segment format, includes the company code from configuration, and POSTs to Orderful. When writing back inbound EDI responses, ml-connector retrieves them from Orderful (via polling or webhook), validates the ISA identifiers, de-envelopes the 855 or 856 payload, and uses OData PATCH to update the IFS purchase order. Because IFS Cloud enforces the OData ETag header on mutations, ml-connector reads the target purchase order first to capture its @odata.etag, then includes that etag in the PATCH request. Orderful's API Key has no expiry and requires no refresh. IFS Cloud's OAuth token is cached and refreshed only on 401 response. Rate limit retries on both sides use exponential backoff. ml-connector tracks the IFS projection name (e.g., PurchaseOrder_v1) at connect time to ensure compatibility with your IFS Cloud version.

A real-world example

A mid-sized manufacturer runs IFS Cloud for ERP and procures components from 20+ suppliers globally. Before the integration, the procurement team manually translated purchase orders from IFS into EDI 850 format, uploaded them to Orderful, and then manually copied inbound 855 acknowledgments and 856 ship notices back into IFS to update order status. This process took 2-3 hours per day and introduced errors when orders or suppliers changed. With IFS Cloud connected to Orderful, each new purchase order is automatically translated to EDI and sent to suppliers within minutes. Inbound acknowledgments confirm the order was received at the supplier, and ship notices update goods receipt in IFS so the finance team sees accurate inventory and accruals. The manual translation step is gone, order-to-receipt cycle time drops, and the data stays in sync.

What you can do

• •Translate IFS Cloud purchase orders to EDI 850 documents and send them to Orderful for delivery to suppliers.
• •Translate IFS Cloud supplier invoices to EDI 810 documents and route them through Orderful to trading partners.
• •Receive EDI 855 acknowledgments and 856 ship notices from Orderful and write them back into IFS Cloud purchase order status and goods receipt vouchers.
• •Sync supplier master data bidirectionally between IFS Cloud and Orderful so partner information stays current.
• •Poll IFS Cloud on a configurable schedule with OAuth token refresh and ETag concurrency control, and retry failed calls with exponential backoff.

Questions

Which direction does data flow between IFS Cloud and Orderful?

The primary flow is IFS Cloud to Orderful. Purchase orders and invoices move from IFS Cloud to Orderful for EDI translation and delivery to suppliers. Inbound EDI responses (855 acknowledgments, 856 ship notices) flow from Orderful back into IFS Cloud to update order and goods receipt status. Supplier master data is aligned in both directions so changes in one system are reflected in the other.

How does the integration handle IFS Cloud's OData ETag concurrency requirement?

IFS Cloud requires the OData ETag header on PATCH and certain POST operations to enforce optimistic concurrency control. ml-connector reads the target record first to capture its @odata.etag value, then includes that etag in the mutation request. If the etag is stale (another process modified the record), IFS Cloud returns an error and ml-connector retries after re-reading the current version.

Can ml-connector handle changes to IFS Cloud projections across different IFS versions?

IFS Cloud projection names are version-specific (e.g., PurchaseOrder_v1, PurchaseOrder_v2 in different releases). ml-connector queries the AllProjections.svc endpoint at connect time to confirm the projection names available for your IFS Cloud instance and fails fast if a required projection is not found. If you upgrade IFS Cloud to a new major release with different projection names, the integration must be reconfigured with the new projection names.