Purchase Inbound Sync in Practice: Field Notes from Pushing Marketing Cloud Documents into Kingdee YXC

What This Strategy Solves

A retail enterprise runs its dealer purchase orders in Marketing Cloud, while Kingdee YXC handles inventory and accounts payable on the back end. Purchase inbound documents need to flow from Marketing Cloud into Kingdee YXC as the entry point for receiving and accounting. The source documents are pulled incrementally within a time window so that during business peaks the integration does not flood the target system or generate duplicate receiving records.

Data Flow and Field Mapping

Data flow: Marketing Cloud (purchase inbound) → Qeasy middleware → Kingdee YXC (purchase inbound).

Key field mapping (desensitized):

Business meaning	Marketing Cloud source field	Middleware handling	Kingdee YXC target field	Notes
Document number	number	Pass-through	bill_no	Globally unique on source, used as idempotency key
Document date	auditTime	Format as date	bill_date	Use audit time, not creation time
Transaction type	transtype	Static mapping	transtype	Fixed value on target
Supplier code	supplierId	Dealer→supplier mapping table	supplier_id	Centralized code mapping
Remark	remark	Concatenate source number	remark	Append source number for traceability
Line items	items[]	Expand row by row	entries[]	Header and lines handled in stages

Centralized code mapping is a common pattern among Qeasy customers: master data such as suppliers and items is first landed by a foundation data sync strategy; the purchase inbound strategy then only references codes and never creates new master records on the target side, which reduces dirty data risk.

How to Configure It in Qeasy

In the Qeasy Data Integration Platform, this strategy sits under the "Purchase Order Sync" domain as the inbound sub-strategy. The typical configuration points are:

Source connector: WebAPI/POST, pointed at Marketing Cloud's purchase inbound query endpoint, with two core parameters — dealer id (tenantId) and status filter (status=1 audited).
Time window: beginTime uses the variable {{LAST_SYNC_TIME|datetime}}, endTime is the current time, so each run only pulls data after the last sync point.
Target connector: WebAPI/POST, calling Kingdee YXC's purchase inbound creation endpoint, with transtype written according to the target enum.
Field mapping: Supplier and item codes go through a "lookup mapping" node instead of being passed directly. When source codes change, only the mapping table needs refreshing.
Idempotency control: enable idCheck, using the source document number as the idempotency key, so duplicate pushes on the target side are skipped automatically.
Exception handling: retry up to 3 times on failure; persistent failures land in the exception queue for manual patching or reverse lookup.

Implementation Steps

Phase 1: incremental start point calibration. Run a one-time full pull of historical audited inbound documents before go-live and write them into the target system. At the same time, set the initial LAST_SYNC_TIME value so the incremental run starts exactly from that point. Schedule this during a business off-peak window to avoid conflict with daily jobs.
Phase 2: full trigger and reconciliation. After the full run completes, export the batch's inbound document numbers from the target system and compare against the source. Confirm there are no gaps and no duplicates before enabling scheduled jobs.
Phase 3: daily scheduling. Configure source pulls during working hours on weekday daytime (every 5 minutes from 8 to 21, as in the source material), and target writes in a slightly later window (every 5 minutes from 7 to 23) so the two sides' write pressure does not stack in the same minute.
Phase 4: monitoring and exception handling. Configure three monitoring thresholds in Qeasy — runtime, failed row count, and empty payload. When consecutive empty payloads appear, check whether the source API is being rate-limited or whether authorization has expired.

Incremental plus full is another common pattern among Qeasy customers: the first cutover uses a full load as a safety net, daily runs use incremental sync, and the two run as separate scheduled jobs. This guarantees historical data completeness while avoiding a full table scan every cycle.

Lessons from the Field

Wrong field used for the time window. A typical mistake is using "creation time" as the incremental window, which causes source documents created first and audited later to be missed. The safer practice is to use auditTime, which matches the target system's "audited inbound" semantics.
Supplier code passed through directly. The source system uses a string dealer id, while the target system uses a numeric supplier id. Passing the value through directly creates garbage supplier records on the target side. A mapping table conversion is mandatory.
Submitting header and lines at once. When source lines are large, submitting the whole document to the target at once easily triggers timeouts. Land the header first, then write lines row by row in a sub-process — this is the standard header-then-lines staged handling.
Wrong idempotency key chosen. Using the source id for repeat submission raises "duplicate creation" errors. The safer practice is to use the source business document number (number) as the idempotency key and enable idCheck.
Schedules on both sides overlap in the same minute. Source pulls and target writes collide in the same minute — the source has not yet returned data while the target side has already started writing, producing empty payloads. Staggering the schedules is basic hygiene.

When This Fits and When It Does Not

Fit: the source system has a clear "audited" status, the target system requires incremental sync over a time window, and both sides expose stable purchase inbound APIs. Does not fit: ambiguous source status semantics, hard real-time second-level sync requirements, or no stable API on either side — those cases need master data and interface foundations built first before any sync strategy can be considered.