QAD and Orderful integration

What moves between them

The flow runs in both directions across the procure-to-pay cycle. Outbound, ml-connector reads new and changed purchase orders from QAD and creates Orderful 850 and 860 change transactions addressed to the supplier ISA ID. Inbound, it reads partner 855 acknowledgments, 856 advance ship notices, and 810 invoices from the Orderful inbox and writes them back into QAD as PO acknowledgments, expected receipts, and supplier invoices. Outbound documents are sent as QAD changes are detected, while the inbox is polled every few minutes so inbound partner traffic lands quickly. Each inbound invoice is matched to its QAD purchase order and goods receipt before it is posted.

How ml-connector handles it

ml-connector stores both credentials encrypted and presents the Orderful API key in the orderful-api-key header on every call, while accepting the full QAD tenant URL per customer since QAD publishes no shared base address. It selects the US or EU Orderful base URL from the region field, because the two regions are isolated and credentials do not cross over. Outbound, QAD purchase order fields map to the Orderful Mosaic transaction body, and the configured sender and receiver ISA IDs are stamped on each envelope so routing succeeds. Inbound, transactions are pulled from the inbox or polling bucket, each batch is approved to dequeue it, and the EDI fields are mapped onto QAD business documents. Because QAD cloud has no webhooks, the inbox is polled rather than pushed, and because three-way match requires the goods receipt first, an 810 invoice is held against its purchase order and receipt before posting. The stream flag stays on test until partner scenarios pass, then flips to live. Orderful rate limits return 429 with a Retry-After header, so ml-connector backs off and retries, and since Orderful has no idempotency header, it records the assigned transaction ID after the first successful create to avoid duplicate sends. Transaction IDs are 64-bit integers and are handled as strings so they do not overflow.

A real-world example

A mid-sized contract manufacturer of consumer goods runs QAD Adaptive ERP and sells to several large retailers that mandate EDI. Before the integration, buyers exported purchase orders from QAD and re-keyed them into a separate EDI tool, and clerks typed supplier acknowledgments and inbound invoices back into QAD by hand, which delayed shipments and caused match errors at month-end. With QAD and Orderful connected, purchase orders flow out as 850 documents automatically, acknowledgments and ship notices update the open orders, and inbound invoices arrive already matched to the purchase order and goods receipt. The EDI re-keying step is gone and the AP team starts close with invoices already reconciled.

What you can do

• •Send QAD purchase orders and change requests to trading partners as Orderful 850 and 860 EDI transactions.
• •Ingest partner 855 acknowledgments and 856 ship notices from the Orderful inbox to update open QAD purchase orders.
• •Pull inbound 810 invoices from Orderful and post them into QAD as supplier invoices.
• •Match each inbound EDI invoice to its QAD purchase order and goods receipt so three-way match holds.
• •Bridge the QAD tenant token and the Orderful API key, with retries and a full audit trail on every transaction.

Questions

Which records move between QAD and Orderful?

Outbound, purchase orders and change requests leave QAD as Orderful 850 and 860 transactions. Inbound, partner 855 acknowledgments, 856 ship notices, and 810 invoices come from the Orderful inbox into QAD as PO acknowledgments, expected receipts, and supplier invoices. Orderful is an EDI network rather than an ERP, so the data that moves is trading-partner transactions, not master records.

How does the integration receive inbound documents when QAD has no webhooks?

Orderful can push inbound transactions to a registered HTTP endpoint, but QAD cloud has no native webhook system of its own. So ml-connector polls the Orderful inbox or polling bucket every few minutes, approves each batch to dequeue it, and writes the mapped documents into QAD. The polling cadence is configurable to match your partner volume.

Does the integration keep three-way match intact in QAD?

Yes. QAD posts a supplier invoice only after the matching goods receipt exists. ml-connector holds each inbound 810 invoice against its originating QAD purchase order and goods receipt, and posts it once the receipt is in place, so the three-way match between order, receipt, and invoice is preserved.