Syncing Item Master Data from Kingdee to Jushuitan: A Single-Strategy Deep Dive
What This Strategy Solves
In a typical retail business, the ERP of record is Kingdee Cloud Cosmic while the e-commerce fulfillment side runs on Jushuitan. Item master data is created first in Kingdee, then consumed by Jushuitan — sounds like a simple one-way push, but in practice, mismatched codes, inconsistent units of measure, and diverging category names pile up fast. Within three months, the two systems drift apart by hundreds of records.
The strategy we are implementing here is the single one-way sync: Kingdee Item → Jushuitan Product Archive. It does not deal with transactional data; it focuses on aligning master data across the source–middle–target layers so that downstream sales outbound orders and transfer orders have clean reference data to work with.
Data Flow and Field Mapping
The pipeline is strictly unidirectional: Kingdee Cloud Cosmic is the source of record, the data flows through the standardization layer inside the Qeasy Data Integration Platform, and lands in Jushuitan's product archive.
| Business Meaning | Kingdee Cloud Cosmic (Source) | Qeasy Mapping Layer | Jushuitan (Target) |
|---|---|---|---|
| Item Code | FNumber | item_code (unified) | Product Code |
| Item Name | FName | item_name | Product Name |
| Specification | FSpecification | spec | Specification |
| Unit of Measure | FBaseUnit | uom_code | Unit |
| Category | FCategoryId | category_path | Category |
| Barcode | FBarcode | barcode | Barcode |
| Active Status | FUsed | is_active | Is Enabled |
| Remark | FDescription | remark | Remark |
The mapping layer holds no business logic — it only renames fields, converts types, and unifies encoding rules. Qeasy's "centralized code mapping management" is critical here: every FNumber ↔ product code and FBaseUnit ↔ uom_code mapping is maintained centrally on the platform, so nobody is left guessing the rationale three months later.
How to Configure in Qeasy
We use the Qeasy Data Integration Platform to host this strategy. The configuration splits into three parts:
Source connection: Pull item records from Kingdee Cloud Cosmic incrementally by last-modified timestamp (specific interface depends on the on-site version). Using the last-modified timestamp as the incremental cursor avoids full-table scans on every run.
Mapping and transformation: Create a new strategy in Qeasy's Data Integration module, target Jushuitan. Field mapping is done via a visual drag-and-drop UI; the code mapping table is maintained separately. Unit of measure is the most common trouble spot — Kingdee may use "piece" while Jushuitan uses "unit," but the same item must not be mapped to both. The rule must be hardened in the transformation layer.
Target write: Write to Jushuitan's product archive interface. Enable "idempotent write by code" so repeated pushes of the same item do not create duplicates.
The platform also offers a "header-body phased" pattern — the main strategy syncs only header fields (code, name, unit, category), while extensions like images, prices, and batch rules are pushed by separate sub-strategies. This avoids a single failure rolling back the entire batch.
Implementation Steps
We split the rollout into three phases:
Phase 1: Full initial load. Push all existing items from Kingdee to Jushuitan in one shot to establish the baseline. After it finishes, manually sample 50–100 records to verify codes, units, and categories.
Phase 2: Switch to incremental. Once the full load passes validation, switch to incremental mode. Daily cadence is usually sufficient because item create/modify frequency is far lower than transactional documents. Schedule it during off-peak hours (e.g., 2–4 AM).
Phase 3: Dual-track safety net. After incremental runs stably, run a small weekly full reconciliation. This is purely a safety net to catch stragglers (e.g., manual upstream edits, interface retransmissions).
All three phases are different run modes of the same strategy in Qeasy, toggled via schedule parameters — no need to rebuild.
Lessons from the Field
Pitfall 1: Code mapping not centralized. On the first run, code mappings lived inside scripts. Three months later, after a personnel change, the original rationale was lost. The safe approach: put all cross-system code mappings into Qeasy's mapping table with version history.
Pitfall 2: Wrong incremental starting point. Setting the first full-load completion time as the incremental start causes the two runs to overlap and overwrite each other. The safe approach: the incremental start must strictly exceed the full-load completion timestamp, and the first incremental run must be manually reconciled by record count.
Pitfall 3: One-to-many unit-of-measure. The same item uses different units across business organizations in Kingdee, but Jushuitan accepts only one. A typical mistake is to write whichever value came back first. The safe approach: in the transformation layer, always pick the "primary unit of measure" and record the original value in the remark field for traceability.
Pitfall 4: Disabled items not filtered. Inactive items from Kingdee got pushed over, producing a pile of grey records in Jushuitan. The safe approach: filter on FUsed=1 at the source; disabled items go through a separate archival strategy.
Pitfall 5: Idempotency not enabled. Repeated pushes created duplicate products in Jushuitan. The safe approach: target writes must be idempotent by code; enable "upsert" on the Qeasy side.
When to Use and When Not to Use
Use when: single organization, clear encoding rules, ERP is the source of record, retail or distribution business, low item-change frequency, hour-level latency acceptable. Do not use when: multi-org / multi-book setups, frequently changing encoding rules, or scenarios requiring real-time reverse lookup of item status — the latter should use a bi-directional sync strategy rather than a single one-way push.