Overview of ECCANG and Kingdee Cloud Skylink Supply Chain Integration

Scenario and Value

A retail client kept hitting the same wall every sales season: after the warehouse shipped goods, it took two days for the inventory ledger on the financial side to reconcile. The problem was not that the ERP was slow to pull data, but that there was no automatic closed-loop between WMS outbound documents and ERP postings. With hundreds of sales outbound, purchase inbound, transfers, and miscellaneous in/out documents flowing daily, manual imports were slow and error-prone.

In most projects we have seen, ECCANG acts as the WMS handling physical movements, while Kingdee Cloud Skylink acts as the ERP for accounting and supply-chain planning. The document structures, encoding systems, and organizational models differ on both sides, so a point-to-point interface tends to break down during promotions. The goal of this design is to engineer three things: master data first, incremental document sync, and observable exception handling — so that inbound/outbound actions close back to the ERP within 20–30 minutes.

Integration Architecture and Data Flow

The architecture involves three parties: ECCANG (WMS), Kingdee Cloud Skylink (ERP), and an integration hub. In our projects the hub is Qeasy (轻易云数据集成平台), which handles strategy scheduling, code mapping, exception retries, and data relay.

Data flows are organized in three directions:

1. Kingdee → Hub: warehouse, customer, material, distribution-out query, purchase-inbound query. This mirrors ERP master data into the platform to serve as a dictionary for downstream transformation.
2. ECCANG → Hub: WMS warehouse query. Used to build the mapping between WMS warehouse codes and ERP warehouse codes.
3. Bidirectional document flows:
   • ECCANG → Kingdee: transfer-in, sales outbound, purchase inbound, miscellaneous inbound (exchange/return/assembly/abnormal return), miscellaneous outbound (inventory loss/assembly split/defective).
   • Kingdee → ECCANG: distribution-out → purchase order. This is split into two strategies based on whether the supplier field is empty; the empty-value branch requires a fallback to look up the upstream supplier.

Interface Inventory

The design contains 21 strategies organized by phase, as listed below.

Code-mapping dependencies: six mapping tables (warehouse, customer, material, WMS warehouse, distribution-out, supplier) are required by all business document strategies and must be initialized before business strategies start.

Implementation Notes

Phased scheduling. The 21 strategies are split into two phases: Phase 1 covers master data (strategies 1/2/3/5/9), Phase 2 covers business documents (strategies 4/6/7/8/10/11/13/14/15/16/17/18/20/21). Strategies within Phase 1 can run in parallel; Phase 2 starts in parallel once master data is ready. Strategy 9 must complete at least one sync before strategy 8, otherwise distributed transfer-in documents cannot find the upstream source document.

Incremental field selection. Incremental sync relies on timestamps: on the ECCANG side, fields like receiving_update_time and update_time; on the Kingdee side, fields like FApproveDate and FModifyDate. The choice of incremental key directly affects the probability of mis-sends and missed sends. Before going live, the team must confirm with the business whether approved documents can still be modified.

Full-load fallback. Weekly full reconciliation for materials, warehouses, and customers; full repair for business documents on demand. The first deployment must run a full load — do not start with incremental logic, otherwise historical dirty data will be bypassed by the incremental filter.

Centralized code mapping. Four mapping tables — warehouse (WMS warehouseId ↔ ERP FNumber), material (ERP FNumber/FOldNumber ↔ WMS productSku), customer (ERP FNumber/FName ↔ WMS platformUserName), and supplier (supplier_code ↔ suppiler_id) — must be maintained centrally on the hub. Do not scatter mappings inside individual strategy scripts. We have seen versions where mappings were hard-coded inside Python scripts; whenever a new warehouse was added, the scripts had to be hot-patched, leading to high incident rates.

Exception retry. Network timeout: exponential backoff, up to 3 retries (30s / 60s / 120s). Target system 5xx: 2 retries with 60s interval. Missing code mapping: no retry, skip and alert. Query returning no result: no retry, log and alert. Dead-letter queue accumulation above 100 messages requires manual intervention.

Data privacy. All real customer names, account sets, and organization codes in the design have been generalized as placeholders such as "a retail client". During implementation, the same masking must be applied on the hub's log redaction module for FNumber, supplier codes, and phone numbers.

Best Practices and Lessons Learned

1. Master data first is non-negotiable. Some projects skip Phase 1 to meet a promotion deadline, only to find that materials cannot be matched and the whole batch of sales outbound documents is rejected by the ERP. The safe approach is to wait until Phase 1 is fully green before opening Phase 2, and to enable alerting during the master data phase itself.

2. Dual channels for the empty-supplier branch. In the distribution-out → purchase order chain, whether the supplier is empty decides whether the order can be placed directly. In Qeasy we split this into strategy 10 (supplier non-empty) and strategy 14 (supplier empty, requires upstream lookup), with the empty-value branch using a separate fallback.

3. Header and body written in separate stages. Kingdee Cloud Skylink's document interface is strict about header-body consistency. A common pitfall is writing the body before the header; if it fails midway, you get orphan data. The safe approach is to create the header first to obtain the document number, then write the body in batches with retryable failure handling.

4. Set monitoring thresholds by business reality. Master data strategies should pause dependent strategies after 3 consecutive failures; business strategies should alert immediately when failure rate exceeds 10%; sync latency above 30 minutes must trigger investigation. A common configuration among Qeasy customers is to wire these thresholds directly into the platform's alerting channel so that incidents are surfaced the same day.

5. Build periodic cleanup into the design. If intermediate table data older than 90 days is not cleaned up, the platform slows down over time and audit traceability becomes difficult. Strategy 19 exists exactly for this — running once at 2 a.m. is enough.

When to Use Qeasy

For scenarios involving multi-document, multi-encoding, high-frequency sync between a WMS and an ERP, Qeasy (轻易云数据集成平台) provides ready-built strategy scheduling, a centralized code mapping center, exception retry, and a dead-letter queue, eliminating the cost of building an in-house ETL scheduling chain. For Chinese-vendor combinations such as ECCANG and Kingdee Cloud Skylink, the platform has accumulated common field-transformation templates, shortening implementation cycles from weeks to days.