Sales Order Sync in Practice: A Step-by-Step Guide for the WDT (Jingcai) → Kingdee Cloud Skylight Strategy

What This Strategy Solves (Scenario & Value)

A retail enterprise uses WDT (Jingcai) as the front end for e-commerce orders and Kingdee Cloud Skylight as the back end for supply chain accounting. Front-end orders arrive in small batches at high frequency, while the ERP must update inventory, generate receivables, and dispatch to WMS on a per-order basis. Manual exports and Excel copy-paste don't survive a month — wrong orders, missed orders, and timeouts become routine.

The goal of this single strategy — "WDT Sales Order Management (Jingcai) → Kingdee Cloud Skylight Sales Order" — is straightforward: push front-end orders to the back end in a stable, rule-defined way, so that finance, inventory, and fulfillment are anchored to the same order record.

Data Flow & Field Mapping (Source → Middle Layer → Target)

The data path is clear: WDT (Jingcai) is the source, Kingdee Cloud Skylight is the target, and the Qeasy Data Integration Platform handles scheduling, mapping, transformation, and retries in between.

Key field mapping (typical convention — actual mappings depend on each customer's master data):

Business Meaning	WDT (Jingcai) Source Field	Middle-Layer Mapping/Rule	Kingdee Cloud Skylight Target Field
Order number	Platform order no + shop code concatenation	Dedup + idempotency key	Document No. (FBillNo)
Shop / Customer	shop_no	Code mapping table (centrally maintained)	Customer Code (FCustomerID)
Product code	sku_id	Aligned with material master strategy, pre-mapped	Material Code (FMaterialID)
Quantity	num	No unit conversion (left to material sync strategy)	Quantity (FQty)
Unit price	price	Tax-included / tax-excluded converted per target convention	Tax-included unit price / Tax-excluded unit price
Shipping address	receiver_addr	Split into province / city / district	Shipping address
Order time	created_at	Unified to UTC+8, second-level precision	Business date / Approval date

Centralized code mapping is one of the most common patterns among Qeasy customers — keep shop, product, and customer mappings in a maintainable table instead of hard-coding them in scripts.

How to Configure It on Qeasy (Key Configuration Points)

We configure this strategy on the Qeasy Data Integration Platform in four core steps:

Connect source & target. Pick WDT (Jingcai) as the source and configure the app_key to read order lists per its official spec. For the target, pick Kingdee Cloud Skylight and use its standard sales-order save API. Qeasy manages the login session so secrets don't scatter across multiple scripts.
Extraction strategy. Incremental mode pulls records where modified >= {last_sync_time}, and we set an explicit "incremental start time". A separate full-compensation channel is also configured for initialization or breakpoint repair.
Field mapping. Use the visual mapper to complete the field alignment above. For high-change fields like shop code and customer code, route through a mapping table so a single edit propagates across the whole chain.
Write & write-back. When the target save succeeds, write back the document number returned by Kingdee Cloud Skylight into Qeasy's run logs, and use it as the linking key for downstream finance/inventory actions. Failed orders enter a retry queue; once the threshold is exceeded, an alert is pushed to the enterprise WeChat group.

Implementation Steps (Phased Scheduling: Incremental Start / Full Trigger / Frequency)

In one real project we typically proceed in four phases:

Phase 1 · Baseline alignment. Run a full sync once to pull historical orders from the source as the baseline. Pause business writes during this phase to avoid overwriting risk.
Phase 2 · Gray rollout. After the full sync completes, switch to incremental mode. The schedule frequency is set according to the customer's order peak; retail customers often settle on a 5-minute cycle to balance latency and API pressure.
Phase 3 · Steady state. Once incremental is stable, the full-sync channel switches to weekly or on-demand manual triggers, mainly for exception repair.
Phase 4 · Continuous monitoring. Watch Qeasy's run logs, failure rate, and missing-field rate. Review daily for the first two weeks, then move to weekly inspections.

Running incremental and full sync as two parallel tracks is a common safe pattern among Qeasy customers — one for daily latency, one for initialization and breakpoint repair.

Pitfalls & Lessons Learned (5 Field-Tested Tips)

No idempotency key = duplicate orders. Using the platform order number directly as the ERP document number causes duplicates whenever the source re-pushes. The safe approach is to build a composite idempotency key in Qeasy — "platform + shop + platform order number".
Don't push header and body in one shot. Sending the entire order at once makes failure localization hard. Splitting header and body into two stages gives cleaner rollback when something fails.
Hard-coded code mappings = painful late changes. Keep shop, product, and customer code mappings in a Qeasy mapping table so business-side changes don't require a new release.
Time zone and precision mismatches shift the date. If the source timestamp carries a time zone or only minute-level precision, normalize it in the middle layer — otherwise the finance date can be off by one day.
Unbounded retries can hang the task. Failure retries must have a threshold and an alert. Qeasy's failure queue can cover you, but humans must still watch.

Applicable & Non-Applicable Scenarios

Applicable: e-commerce front end (WDT Jingcai) integrating with back-end ERP (Kingdee Cloud Skylight) for unified order, inventory, and finance processing — daily order volumes in the thousands to tens of thousands.
Not applicable: cross-organization complex approval flows or orders requiring manual intervention. These should be handled inside Kingdee Cloud Skylight's own workflow rather than relying on the sync channel to carry business decisions.