QAD and SPS Commerce integration

What moves between them

Documents move in both directions, with SPS Commerce always the intermediary and the retailer as the true endpoint. Inbound, ml-connector polls SPS Commerce for retailer purchase orders (EDI 850) and product activity (852) and creates the matching orders in QAD. Outbound, when QAD records a shipment or a customer invoice, ml-connector builds the advance ship notice (856) and invoice (810) and pushes them to SPS Commerce for delivery to the retailer. Inventory advice (846) can flow either way to keep stock positions aligned. SPS Commerce holds no GL accounts, payments, or supplier master, so financial postings stay in QAD and are never written to the network.

How ml-connector handles it

ml-connector stores both credential sets encrypted. For SPS Commerce it exchanges the client ID and client secret for an OAuth2 bearer token at the SPS token endpoint, which sits on a different domain than the API base, and refreshes the token when a call returns 401. For QAD it accepts the full tenant URL per customer, since QAD publishes no shared base address, and authenticates with the tenant token. Inbound documents arrive inside the RSX 7.7.7 envelope, so ml-connector unwraps the transaction sets and maps the retailer purchase order header and line items, including item identifiers, onto QAD orders; outbound, it wraps QAD ship and invoice data back into RSX before posting. Because SPS Commerce is polling-primary, it reads new documents on a schedule using cursor-based paging and tracks a last-seen cursor so nothing is fetched twice. Trading partner IDs are provisioned during retailer onboarding and are mapped to the right QAD customer, since they are not discoverable through the API. Rate limits are not published, so ml-connector backs off with jitter on HTTP 429, and document numbers such as purchaseOrderNumber and invoiceNumber serve as natural deduplication keys. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized consumer goods manufacturer runs QAD Adaptive ERP for production and order management and sells to several large retailers that mandate EDI through SPS Commerce. Before the integration, a coordinator logged into the SPS portal each morning, printed inbound retailer purchase orders, and keyed them into QAD by hand, then manually assembled ship notices and invoices to send back, which delayed shipments and triggered retailer chargebacks for late or malformed documents. With QAD and SPS Commerce connected, retailer purchase orders flow into QAD automatically, and ship notices and invoices are returned through SPS as soon as QAD records the shipment. The coordinator stops re-keying EDI, orders are entered the same day they arrive, and compliance documents go out on time.

What you can do

• •Pull retailer purchase orders (EDI 850) from SPS Commerce and create them in QAD automatically.
• •Push QAD ship notices (EDI 856) and invoices (EDI 810) back to SPS Commerce for delivery to the retailer.
• •Wrap and unwrap the RSX 7.7.7 document envelope and map trading partner and item identifiers to QAD records.
• •Authenticate SPS Commerce with OAuth2 client credentials and QAD with its tenant-specific token.
• •Poll SPS Commerce on a schedule with cursor paging, 429 backoff, retries, and a full audit trail on every document.

Questions

Which direction does data move between QAD and SPS Commerce?

Both directions, with SPS Commerce as the intermediary. Retailer purchase orders and product activity are pulled from SPS Commerce into QAD, while ship notices and invoices are pushed from QAD back to SPS Commerce for delivery to the retailer. SPS Commerce holds no GL or payment data, so financial postings stay in QAD.

Does SPS Commerce send push notifications when a new order arrives?

Not reliably yet. The SPS Commerce API standards define a webhook framework, but it is still under development and there is no confirmed production event catalog. ml-connector therefore polls SPS Commerce on a schedule using cursor-based paging and a last-seen cursor, and pushes outbound documents as soon as QAD records the matching event.

How does ml-connector handle the RSX format and trading partner IDs?

Every SPS Commerce payload is wrapped in the RSX 7.7.7 JSON envelope, so ml-connector unwraps inbound transaction sets before mapping them to QAD and re-wraps QAD data on the way out. Trading partner IDs are provisioned during retailer onboarding and are not discoverable through the API, so each one is mapped to the correct QAD customer during setup.