QAD and IBM Sterling integration

What moves between them

Outbound, ml-connector reads QAD purchase orders, translates them to X12 850 or EDIFACT ORDERS documents, and posts them into the IBM Sterling mailbox that routes to each trading partner. Inbound, it polls the receiving mailboxes for 810 invoices and 820 remittance advice, extracts the EDI payload, and creates supplier invoices and payment references in QAD against the matching supplier and purchase order. Ship notices and acknowledgements are tracked the same way. Trading partner identifiers map to QAD supplier records so each document lands on the right account. Polling cadence is set per mailbox, typically every one to five minutes.

How ml-connector handles it

ml-connector stores both credential sets encrypted. On the QAD side it accepts the full tenant URL per customer, since QAD publishes no shared base address, and reads records over the business document API. On the IBM Sterling side it accepts the customer host and Liberty HTTPS port and authenticates with Basic auth or OAuth2 client credentials, using a dedicated non-super-user account because IBM rejects super-user accounts on the REST API. To send a QAD document it first creates a Sterling document to get a documentId, then posts a mailbox message that references it, because the EDI content cannot be inlined. To receive, it polls mailbox messages by path, filters new items by created date or cursor, and extracts the payload. Because neither system pushes events, both directions run on a schedule rather than a webhook. Trading partner identifiers are mapped to QAD suppliers first so every invoice resolves to a real account. The REST API has no idempotency key, so ml-connector checks the returned mailbox message id and workflow id before retrying a create, backs off on transient errors, and keeps a full audit trail with replay on every record.

A real-world example

A mid-sized industrial parts manufacturer runs QAD Adaptive ERP for procurement and finance and already operates IBM Sterling B2B Integrator to trade EDI with its large retail and distributor customers. Before the integration, staff exported purchase orders from QAD, hand-built EDI files, and dropped them into Sterling mailboxes, then watched inbound mailboxes for supplier invoices and typed the totals back into QAD. With QAD and IBM Sterling connected, each QAD purchase order is translated and delivered automatically, and inbound 810 invoices flow back into QAD against the right supplier and purchase order. The manual file handling disappears and document errors fall.

What you can do

• •Translate QAD purchase orders into X12 850 or EDIFACT ORDERS and deliver them through IBM Sterling mailboxes.
• •Poll IBM Sterling mailboxes for inbound 810 invoices and 820 remittance and post supplier invoices into QAD.
• •Map IBM Sterling trading partner identifiers to QAD suppliers so each document resolves to the right account.
• •Authenticate IBM Sterling with HTTP Basic or OAuth2 client credentials against the customer host and Liberty port.
• •Run both directions on a per-mailbox schedule, with retry handling and a full audit trail on every record.

Questions

Which records move between QAD and IBM Sterling?

Outbound, QAD purchase orders become X12 850 or EDIFACT ORDERS documents delivered through IBM Sterling mailboxes. Inbound, 810 invoices and 820 remittance are polled from mailboxes and posted into QAD as supplier invoices and payment references. Ship notices and acknowledgements are tracked alongside them.

How does ml-connector send and read EDI through IBM Sterling?

To send, ml-connector first creates a Sterling document to obtain a documentId, then posts a mailbox message that references it, because the IBM Sterling REST API does not allow inline EDI content. To read, it polls mailbox messages by path, filters new items by created date or cursor, and extracts the payload. The actual EDI bytes are the mailbox message content, not a queryable REST resource.

Why does this integration poll instead of using webhooks?

Neither system pushes events to an external endpoint. QAD cloud has no webhook system, and the IBM Sterling B2B REST API does not support outbound webhooks. ml-connector therefore polls QAD over its business document API and polls IBM Sterling mailboxes on a schedule, typically every one to five minutes per mailbox.