Purchase Inbound Sync in Practice: An End-to-End Guide from Marketing Cloud to Finance ERP
What This Strategy Solves
Purchase inbound orders are the last mile of the supply chain. Once goods arrive at the warehouse, the document must land in the finance ERP—otherwise books and reality drift apart, payables cannot be attached, and costing becomes guesswork. In one retail engagement, the marketing cloud handled ordering and approval, while a finance ERP handled accounting. We bridged the two with Qeasy (the 轻易云 data integration platform) so that approval triggers sync and every document stays traceable.
Data Flow and Field Mapping
The flow is unidirectional: marketing cloud (source) → Qeasy (middleware for cleansing, mapping, and defaulting) → finance ERP (target, writes the inbound document).
The source side queries audited inbound orders from the marketing cloud's purInWarehsOrder endpoint using an update-time window. The middleware handles code translation (supplier, SKU), header and line splitting, and default value injection (such as business type). The target side calls the ERP's pur_inbound endpoint.
Key field mapping:
| Business meaning | Source field | Target field | Notes |
|---|---|---|---|
| Document date | auditTime | bill_date | Use approval date, format as date |
| Document number | number | bill_no | Auto-generated by ERP or echoed back |
| Business type | — | transtype | Fixed value "2" (purchase inbound) |
| Supplier code | supplierNumber | supplier_id | Go through the code mapping table |
| Line items | items[] | material_entity[] | Expand per row |
| Remark | remark | remark | Concatenate source and original order number |
How to Configure in Qeasy
In Qeasy, this strategy is split into three segments: source reader, middleware transformation, and target writer.
The source reader is a WebAPI call, POST method. The request body sets status=1 to lock down audited documents, and beginTime uses the {{LAST_SYNC_TIME|datetime}} placeholder so the platform injects the last sync timestamp automatically—giving you an incremental window for free.
The middleware is where the real work happens. Qeasy's mapping panel supports three modes: constant assignment, variable reference, and conditional branch. A common pattern among Qeasy customers is to maintain code mappings as centralized lookup tables (suppliers, SKUs, warehouses). New partners are added by editing the table, not the flow.
The target writer is also a WebAPI call, POST to the ERP's pur_inbound. Leave bill_no empty so the ERP generates it. Use a template to build remark: {{remark}}-from marketing cloud-{{yxyNumber}}. Finance can later trace any document back to its origin.
Implementation Steps
We recommend a three-phase rollout.
Phase one, full initialization. Manually trigger a run in Qeasy with a wide time window (e.g., the past year) to backfill all audited inbound orders. Sample-verify counts, amounts, and suppliers on the ERP side before moving on.
Phase two, incremental start. Enable scheduling. Set the source crontab to */3 8-21 * * * (every three minutes during business hours) and the target to */4 7-23 * * * (one hour buffer on either side). The beginTime placeholder drives the incremental cursor automatically.
Phase three, steady state. Monitor for one week: document count deltas, retry behavior, and API latency. Qeasy's run monitor shows the full request and response payload for every call—no need to log into both systems to debug.
Pitfalls from the Field
Pitfall 1: Timestamp format mismatch. The marketing cloud expects 0000-00-00 00:00:00, while the ERP expects a date type. Add formatters in Qeasy's mapping layer rather than writing conversion logic in both systems.
Pitfall 2: Missing supplier mapping. A classic mistake is mapping SKUs but forgetting suppliers. The ERP's supplier_id is an internal code, not the source system's. The safe approach is to first build standalone QUERY strategies for all dependent master data (suppliers, SKUs, warehouses, currencies), run them to land in the ERP, and only then turn on transactional sync.
Pitfall 3: Header and lines sent as one block. Sending the whole payload with items[] often results in only the last line being kept. Explicitly expand items[] in the middleware with a for loop, and build material_entity row by row. This is the typical header-then-line staged pattern.
Pitfall 4: Resync creates duplicates. Mixing incremental and full backfill in the same flow produces duplicate inbound orders in the ERP. Build the full initialization as a separate strategy, mutually exclusive with the incremental one, and disable it after completion.
Pitfall 5: Schedules spin during off-hours. Restrict crontab to business hours to save quota and leave the rest of the day for maintenance.
When to Use and When Not To
Use it when: marketing cloud handles orders and the ERP handles books; inbound orders need to post right after approval; you want centralized code mapping. Do not use it when: you need true second-level real-time (Qeasy is near real-time, on the order of minutes); the source system has no approval flow and everything stays as draft; the target ERP is on-premises and cannot be exposed to the public network.