IFS Cloud and Stedi integration

What moves between them

Purchase orders and supplier invoices flow from IFS Cloud into Stedi. ml-connector polls IFS Cloud's PurchaseOrderSet and PostingProposalHeadSet on a configurable schedule (typically daily or after procurement events), transforms them to X12 850 and 810 formats, and writes them to Stedi via REST calls with Idempotency-Keys to prevent duplicates. Inbound EDI from trading partners arrives at Stedi as transaction.processed.v2 webhooks; ml-connector receives the parsed JSON, maps 855 Purchase Order Acknowledgments and 865 Change Acknowledgments back to IFS Cloud VoucherSet entries and PurchaseOrderSet state updates, and uses OData If-Match headers to handle concurrent edits. Acknowledgments are written with the ETag captured on the most recent read to prevent optimistic concurrency conflicts.

How ml-connector handles it

ml-connector stores both credential sets encrypted: IFS Cloud OAuth client_id and client_secret (refreshing the bearer token before it expires at 60 minutes), and Stedi API key. On each outbound sync, ml-connector polls IFS Cloud filtered on modified timestamps to reduce payload, reads the OData ETag from each record, transforms the entity to X12 format mapping IFS purchase order line items and invoice details to X12 segments, and POST to Stedi with a unique Idempotency-Key per record to enforce deduplication across retries. On inbound, Stedi webhooks deliver parsed JSON; ml-connector decodes the transaction type (855 vs 865), maps the EDI data to IFS Cloud entity fields, reads the current VoucherSet or PurchaseOrderSet record to capture its ETag, and PATCH with that ETag in the If-Match header to ensure concurrent edits do not silently overwrite. IFS Cloud enforces company code on financial entities, so ml-connector maps Stedi transaction headers to the correct company code per customer configuration. Rate limits on both sides are respected: IFS Cloud 1000 requests per minute returns HTTP 429, and Stedi webhooks timeout at 5 seconds, so ml-connector uses exponential backoff with jitter on 429 responses and processes webhook payloads asynchronously to reply within the 5-second window.

A real-world example

A discrete manufacturer with multiple plants uses IFS Cloud for procurement and GL accounting, and ships to a network of 15 distribution partners via EDI. Before the integration, the procurement team exported purchase orders from IFS Cloud daily, manually converted them to X12 format in a spreadsheet tool, and uploaded them to Stedi via the portal. Inbound 855 acknowledgments from partners were downloaded from Stedi as X12 files, re-keyed into IFS Cloud by hand, and reconciled against the original orders. With IFS Cloud and Stedi connected through ml-connector, each new purchase order in IFS Cloud automatically flows to Stedi, is translated to X12, and routed to the correct partner without manual intervention. Partner acknowledgments arrive as Stedi webhooks, are parsed back into JSON, and update the purchase order status in IFS Cloud in near real-time. Month-end reconciliation is streamlined because inbound and outbound EDI is already synchronized with IFS Cloud records.

What you can do

• •Poll IFS Cloud purchase orders and supplier invoices on a schedule and publish them to Stedi, translated to X12 850 and 810 formats, without manual export or re-keying.
• •Map inbound Stedi EDI transactions (855 acknowledgments, 865 change notices) back to IFS Cloud purchase order and voucher records with OData ETag-based optimistic concurrency handling.
• •Authenticate IFS Cloud with OAuth 2.0 Client Credentials and manage 60-minute token refresh, and store Stedi API keys encrypted.
• •Use Idempotency-Keys on Stedi writes and OData If-Match headers on IFS Cloud PATCH operations to prevent duplicate records and handle concurrent edits safely.
• •Handle IFS Cloud's 1000-request-per-minute rate limit with exponential backoff, Stedi's 5-second webhook timeout with asynchronous processing, and capture full audit trails of every transaction and acknowledgment.

Questions

How does ml-connector handle IFS Cloud's OData ETag requirement for updates?

ml-connector reads the current record from IFS Cloud (e.g., PurchaseOrderSet or VoucherSet), captures the @odata.etag value returned in the response, and includes that etag in the If-Match header on the PATCH request to update the record. If the record was edited by another process between the read and the update, IFS Cloud returns a 412 Precondition Failed; ml-connector logs the conflict, re-reads the current record, and retries with the fresh etag.

What X12 transaction types does ml-connector translate between IFS Cloud and Stedi?

IFS Cloud purchase orders map to X12 850 (Purchase Order), and supplier invoices map to X12 810 (Invoice). Inbound from partners, X12 855 (Purchase Order Acknowledgment) updates the PurchaseOrderSet confirmation status, and X12 865 (Change Acknowledgment) records order change requests in IFS Cloud VoucherSet entries. Other X12 types (856 Advance Shipment Notice, etc.) can be extended per customer configuration.

Does ml-connector retry failed Stedi writes, and how does it prevent duplicates?

Yes. ml-connector retries failed Stedi API calls with exponential backoff if the response is 429 (rate limit) or a transient error. Every outbound write to Stedi includes a unique Idempotency-Key header based on the IFS Cloud record ID and transaction type; Stedi deduplicates within a 24-hour window, so a retry with the same key will not create a duplicate transaction even if the first call partially succeeded.