Syncing Kingdee Material Master Data to Jushuitan Products: A Single-Strategy Tutorial

What This Strategy Solves

In one real retail project, the client ran Kingdee Cloud Galaxy as the back-end ERP and Jushuitan as the front-end e-commerce fulfillment system, while operations staff had to maintain material master data manually on both sides. Whenever a new SKU was created or revised, the numbers would drift apart within one or two weeks—stock figures diverged, order fulfillment mis-matches appeared, and consolidated reporting became unreliable. This strategy takes a simple approach: Kingdee material data becomes the single source of truth, synced one-way to the Jushuitan product library, so that front-end SKUs have a unique origin and every change is traceable.

Data Flow and Field Mapping

The data flow is unidirectional: Kingdee Cloud Galaxy material records serve as the source, and Jushuitan product records serve as the target. The middle layer is hosted on the Qeasy data integration platform, responsible for extraction, transformation, and loading.

Key field mapping (the most error-prone items in real projects):

Code mappings (enumerations like units, warehouses, statuses) should never be scattered across scripts. Centralize them in a mapping table within Qeasy—this is the lowest-cost approach for ongoing operations.

How to Configure on Qeasy

On the Qeasy data integration platform, this strategy is typically implemented as a source-document → target-document sync flow. Configuration highlights:

1. Source connection: Use the Kingdee Cloud Galaxy adapter, configure the tenant and API authorization; for Jushuitan, use the open-platform adapter and complete shop and product API authorization.
2. Pull strategy: Pull incrementally from the source by last-modified timestamp (FModifyDate); perform an initial full load first, then switch to incremental.
3. Field mapping: Complete the mapping in Qeasy's visual canvas using the table above; reference the unified dictionary through "code mapping" nodes for enumerations like units, warehouses, and statuses.
4. Write strategy: The Jushuitan product API supports upsert by code; using material code as the idempotency key is recommended to avoid duplicates.
5. Exception handling: Configure retry on failure, alerts on field-length truncation, and—instead of deleting disabled materials—map them to an off-shelf status. This point is expanded in the pitfalls section.

Implementation Steps

Roll out in phases; staged go-live is far safer than a single cutover.

• Phase 1: Full-load baseline. Trigger a one-off full load in Qeasy to push all currently used materials over. Run this first on a Jushuitan test shop; do not touch production data directly.
• Phase 2: Align the incremental start point. Before switching to incremental, freeze the source data and capture a clear FModifyDate timestamp as the new starting point. Persist the synced code list on the target side, and use code as the existence key going forward.
• Phase 3: Scheduling frequency. Material changes are not frequent; a 15-minute polling cycle is common. If SKU changes are sparser, an hourly cycle is also acceptable. A single scheduled task on Qeasy is sufficient.
• Phase 4: Validation and reconciliation. During early go-live, perform a daily reconciliation of code counts on both sides and sample 5–10 records for field-level comparison. After stabilization, switch to weekly reconciliation.

Pitfalls and Lessons Learned

1. Scattered code mappings. Early on we wrote unit, warehouse, and status mappings directly into the script of each sync flow. After three strategies, the same unit mapping had been edited three times. The safer approach is to centralize mappings in a Qeasy mapping table, and have flows only reference, not redefine.
2. Deleting disabled materials directly. In one earlier script, materials disabled on the source side were deleted on the target side via an API call, which triggered anomalies in Jushuitan's historical order product snapshots. The safer approach is to map disabled to "off-shelf" status, never perform a physical delete.
3. Truncation on multi-barcode fields. The FBarCode field on Kingdee supports multiple barcodes joined by semicolons, while Jushuitan's single-barcode field has a limited length—oversized values are silently truncated. The safer approach is to configure oversize alerts in Qeasy and split multiple barcodes per the business rule.
4. Drifting incremental start point. If the source is not frozen when switching to incremental, materials modified during the switch may fall outside the new time window and be lost. The safer approach is to take a full snapshot before switching and record the highest timestamp as the new starting point.
5. Currency and tax in price fields. Kingdee prices are typically stored as a mix of tax-inclusive/tax-exclusive and base/foreign currency; passing them through directly leads to 0.01-level discrepancies. The safer approach is to clearly mark the convention in Qeasy and perform a unified currency and tax-flag conversion.

Applicable and Non-Applicable Scenarios

Applicable: enterprises that treat the ERP as the single source of truth for materials and use front-end e-commerce/fulfillment systems in read-only mode; SKU volumes in the tens of thousands with low-to-medium change frequency. Not applicable: scenarios that require bidirectional material maintenance on both sides, scenarios where new SKUs must go live extremely fast (hourly) with the front-end leading, or scenarios where the target must create derivative product combinations. Such scenarios need more complex bidirectional sync or front-end-leading strategies and cannot be addressed by this approach.