QAD and Cin7 integration

What moves between them

The main flow runs from Cin7 Core into QAD. ml-connector reads Cin7 Core suppliers and Purchase records and creates the matching suppliers, purchase orders, and supplier invoices in QAD, mapping the Cin7 Core Approach value so an ORDER lands as a QAD purchase order and an INVOICE lands as a QAD supplier invoice. Because QAD enforces a three-way match, invoices are only posted after the related goods receipt exists, which Cin7 Core tracks through its RECEIVE approach. Chart of accounts codes and item codes are aligned in both directions so every purchase line references a GL account and item that already exists in QAD. The QAD chart of accounts is the system of record for finance, and the Cin7 Core chart of accounts is read-only over the API, so ml-connector never writes accounts back to Cin7 Core.

How ml-connector handles it

ml-connector stores both credential sets encrypted and sends the Cin7 Core api-auth-accountid and api-auth-applicationkey headers on every request, while on the QAD side it accepts the full tenant URL per customer since QAD publishes no shared base address and refreshes the QAD bearer token when a call returns 401. Because both QAD cloud and Cin7 Omni are pull-only, and Cin7 Core webhook events carry no verifiable signature, it polls Cin7 Core Purchase and Supplier endpoints on a schedule using page and limit parameters rather than relying on a push. Chart of accounts and item codes are mapped first, so every purchase line posted into QAD references an account and item that already exists there. Supplier invoices are held until the matching goods receipt is present, to respect the QAD three-way match. Cin7 Core has no idempotency header, so ml-connector uses the Purchase Reference field as a natural key to avoid duplicates, and when Cin7 Core returns HTTP 429 it reads the Retry-After header and backs off. Every record carries a full audit trail and can be replayed if a downstream call fails.

A real-world example

A mid-sized contract manufacturer runs QAD Adaptive ERP for production planning, costing, and finance, and uses Cin7 Core to manage inventory, supplier purchase orders, and receiving in the warehouse. Before the integration, the buying team raised purchase orders and recorded supplier invoices in Cin7 Core, then the finance team re-keyed those same suppliers and bills into QAD by hand, which slowed month-end close and produced mismatches between received goods and posted invoices. With QAD and Cin7 Core connected, suppliers and purchase activity flow into QAD automatically, invoices post only after the goods receipt is in place, and each line lands on the right GL account. The duplicate data entry is gone and the accounts payable figures reconcile against receipts from the first day of close.

What you can do

• •Create QAD suppliers, purchase orders, and supplier invoices from Cin7 Core suppliers and Purchase records.
• •Map the Cin7 Core Approach value so orders, receipts, and invoices land in the correct QAD record type.
• •Hold supplier invoices until the matching goods receipt exists, to respect the QAD three-way match.
• •Authenticate Cin7 Core with its account-id and application-key headers and QAD with its tenant-specific token.
• •Poll Cin7 Core on a schedule with Reference-based dedup, Retry-After backoff, and a full audit trail on every record.

Questions

Which direction does data move between QAD and Cin7?

The main flow is Cin7 Core into QAD. Suppliers and purchase records move from Cin7 Core into QAD as suppliers, purchase orders, and supplier invoices, while chart of accounts and item codes are aligned in both directions. The Cin7 Core chart of accounts is read-only over the API, so ml-connector does not write accounts back into Cin7 Core.

How does the three-way match affect supplier invoices?

QAD matches a supplier invoice against the purchase order and the goods receipt before it can post. ml-connector holds each invoice read from Cin7 Core until the matching goods receipt is present, which Cin7 Core records through the RECEIVE approach on the same Purchase. This keeps accounts payable in QAD reconciled against what was actually received.

Why does the integration poll Cin7 instead of using webhooks?

Cin7 Core can send outbound events through its Automation module, but those events carry no documented signature header, so they cannot be verified reliably. QAD cloud is also pull-only and has no webhook system for connectors. For these reasons ml-connector polls the Cin7 Core endpoints on a schedule using page and limit parameters and backs off on HTTP 429 using the Retry-After header.