IFS Cloud and SPS Commerce integration

What moves between them

The main flow runs bidirectionally. Inbound purchase orders from SPS Commerce trading partners are polled on a regular schedule and imported into IFS Cloud as purchase orders with full line detail and ship-to addresses mapped to IFS Cloud customer dimensions. When those purchase orders are fulfilled in IFS Cloud, outbound invoices (810) and advance ship notices (856) are generated and pushed to SPS Commerce on an event-driven cadence so each retail trading partner receives them in their expected EDI format. PO acknowledgments flow from IFS Cloud back to SPS Commerce after purchase orders are confirmed.

How ml-connector handles it

ml-connector stores both credential sets encrypted and presents the OAuth 2.0 bearer token on every call to both systems. On the IFS Cloud side, it accepts the tenant-specific base URL per customer, reads inbound purchase orders via OData polling with a timestamp filter to capture only new and modified records, and maps trading partner identifiers from SPS Commerce to IFS Cloud customer master records. When writing purchase orders to IFS Cloud, ml-connector captures the OData ETag header on the initial read and includes it in the subsequent PATCH or POST request to satisfy IFS Cloud's optimistic concurrency model. On the SPS Commerce side, it wraps all outbound documents in the RSX 7.7.7 envelope before transmission, translates IFS Cloud GL account and cost center dimensions into SPS Commerce trading partner requirements, and deduplicates by checking for existing documents by purchaseOrderNumber or invoiceNumber before posting. Polling intervals are configurable per customer and are typically aligned with your purchase order receipt cycle and daily fulfillment batch schedule. Every record carries a full audit trail and can be replayed if a downstream write fails.

A real-world example

A mid-sized consumer goods supplier manufactures products for major retailers including Walmart and Target. Previously, purchase orders arrived at the supplier via EDI files that required manual mapping into their IFS Cloud ERP system, and outbound invoices had to be manually exported from IFS Cloud and reformatted for each retailer's specific EDI requirements before transmission. With IFS Cloud and SPS Commerce connected, inbound purchase orders from the SPS Commerce network flow directly into IFS Cloud during off-hours polling, automatically mapped to the correct customer accounts and ship-to addresses. When those orders are fulfilled and invoiced in IFS Cloud, the invoices are automatically formatted in each retailer's EDI standard and pushed to SPS Commerce, eliminating the manual mapping and reformatting step entirely.

What you can do

• •Import inbound purchase orders from SPS Commerce trading partners into IFS Cloud on a configurable polling schedule, with full line detail and ship-to addresses mapped to customer dimensions.
• •Export outbound invoices and advance ship notices from IFS Cloud to SPS Commerce in RSX 7.7.7 format on an event-driven basis, ready for transmission to each retail trading partner.
• •Handle IFS Cloud OData mutations by capturing ETag headers and including them in write requests to satisfy optimistic concurrency requirements.
• •Authenticate both systems with OAuth 2.0 client credentials, storing credentials encrypted, and refresh tokens when API calls return 401.
• •Maintain a full audit trail on every purchase order, invoice, and shipment, with configurable retry and replay on failed downstream writes.

Questions

How are trading partner identifiers from SPS Commerce mapped to IFS Cloud customers?

SPS Commerce trading partners are provisioned during onboarding with their retailer identifiers. ml-connector maps these identifiers to IFS Cloud customer master records by matching on the customer code or external reference field. The mapping is stored in the connector configuration and validated at sync time to ensure every inbound purchase order lands on the correct customer account.

What happens when IFS Cloud requires an ETag header for a purchase order write?

ml-connector reads the purchase order record first to capture the OData ETag header from the response, then includes that ETag value in the If-Match request header on the subsequent PATCH or POST. If the ETag is stale because another process modified the record in between, IFS Cloud returns a 412 Precondition Failed error, which ml-connector logs and retries on the next polling cycle after re-reading the record.

Does SPS Commerce require documents to be wrapped in RSX 7.7.7 envelopes before transmission?

Yes. All outbound documents from IFS Cloud to SPS Commerce (invoices, ASNs, PO acknowledgments) must be wrapped in the RSX 7.7.7 JSON envelope before posting. ml-connector automatically applies the envelope wrapper on every outbound write, including required metadata fields like document type, trading partner ID, and timestamp, so IFS Cloud teams do not need to manage the envelope format manually.