Practical Guide to Pushdown Sync of Purchase Receipts from WDT to Kingdee Cloud Galaxy

What This Strategy Solves

In a typical retail business, store-level receiving happens in a frontline OMS, while financial and supply-chain ledgers live in an ERP. Once the two diverge, month-end reconciliation becomes painful. The goal of this strategy is to push down purchase receipts from the OMS into the ERP, achieving one-to-one document alignment and consistent inventory and payable numbers. We deliver this on the Qeasy data integration platform. The real challenge is not "can it transmit," but "will both sides recognize the result."

Data Flow and Field Mapping

The flow is unidirectional: OMS source → Qeasy middle layer → ERP target. Qeasy does not perform business logic, but it handles field remapping, code translation, and exception routing.

Key field mapping (source to target, only the risky ones shown):

Code mapping (supplier, warehouse, material) is the backbone of this strategy. On Qeasy we keep it as centralized mapping tables—no hard-coding inside scripts.

Configuration on Qeasy

First, source and target connections. The source uses the OMS open API; the target uses the ERP save/submit API. Qeasy has built-in connectors for both, and credentials are managed by the platform's secret store rather than embedded in scripts.

Second, field mapping. In Qeasy's mapping canvas, map the fields above one by one. Mapping tables are decoupled and live in the "Code Management" module. A common pattern we see is splitting supplier, warehouse, and material into three independent tables so each domain owner only edits their own.

Third, pushdown mode. A purchase receipt typically has a header and multiple lines. Use "whole-document pushdown," not line-by-line—line-by-line breaks document linkage and breaks subsequent settlement.

Fourth, exception handling. Qeasy routes every failed record into an exception queue with the original payload and the target system's error message. On-call engineers classify failures by error code: missing code, blank required field, or price anomaly—three completely different handling paths.

Fifth, header and body phased rollout. In the early stage, only push the header plus a few fields to confirm the two systems can match documents, then layer in all line fields. Rolling out every field at once is the most common way this strategy fails.

Implementation Steps

We recommend three steps, not a single full-volume run.

Step 1: Full-volume baseline. Pull the last 30 days of historical documents from the source for a one-time full sync, used only to validate the chain. Qeasy's "Full Trigger" can run manually in the background. After it finishes, reconcile both sides and clear all differences before proceeding.

Step 2: Incremental starting point. Define a clear time boundary (for example, a specific early morning). From that moment on, only push new and changed records. Qeasy uses a timestamp plus document status as the incremental cursor to avoid duplicates and gaps.

Step 3: Scheduling frequency. Purchase receipts do not need real-time sync, but waiting until month-end is too late. We suggest every 15 minutes, relaxed to 30 minutes during off-peak. Qeasy's scheduler supports cron expressions, retries three times on failure, and routes to the exception queue after that.

One reminder: the source's "approved" status is a hard condition for the incremental cursor. Draft documents do not participate, to avoid orphan records in the target.

Pitfalls from the Field

Pitfall 1: Hard-coded code mapping. Three months after go-live, numbers diverged. A new store opened, its warehouse code did not propagate, and because the mapping was duplicated across multiple scripts, three places got updated and one was missed. The reliable way: externalize all code mapping to Qeasy's "Code Management" and edit only one place.

Pitfall 2: Tax-included vs. exclusive mismatch. The source defaults to tax-inclusive price; the ERP may expect tax-exclusive. Two paths: convert in the source before pushing, or configure the target to accept tax-inclusive receipts. Decide during PoC, not at month-end close.

Pitfall 3: Timezone issues. The source stores local time, the target parses as UTC, so cross-day documents fall into the next day. Normalize timezone in Qeasy's field mapping rather than relying on either system's default.

Pitfall 4: Rolling out all fields at once. Thirty-plus fields across header and body launched simultaneously leads to debugging nightmares. We promote "header and body in phases": main chain first, then line fields, then custom fields.

Pitfall 5: Incremental start point not frozen. After the full run, no clear boundary was defined, so full and incremental overlapped, generating many duplicates in the target. The reliable approach: after full completion, set a "checkpoint mark" and have incremental only push records after the mark.

When to Use and When Not

Use when: the OMS is the business front end, the ERP is the supply-chain/finance back end, purchase receipts need unidirectional aggregation, the organization is stable, and the code system is established. Do not use when: bidirectional sync is required, frequent reversals or red-letter documents exist, or reconciliation needs second-level real-time. Those scenarios need a separate strategy discussion.