Material Master Data Sync in Practice: A Query-and-Push Strategy from Kingdee Cloud to Jushuitan

What This Strategy Solves

Material master data is the bedrock of every downstream process. In a real project, a retail enterprise used Kingdee Cloud as its finance and supply chain back-end and Jushuitan for e-commerce front-end merchandising. Materials were scattered across both systems from day one: inconsistent coding rules, mismatched unit and brand fields, missing shelf-life values. The result was three different names for the same SKU across procurement, warehousing, and e-commerce, and after three months the inventory reconciliation had drifted completely out of alignment.

The core of this strategy is to treat Kingdee Cloud as the single source of truth for materials. Using the Qeasy data integration platform, materials are queried on a schedule, field-mapped, and then pushed into Jushuitan so the e-commerce product catalog always follows the back-end definition.

Data Flow and Field Mapping

The pipeline has three stages: Kingdee Cloud (source) → Qeasy integration platform (middleware) → Jushuitan (target). On the source side, the executeBillQuery API is used for material queries (QUERY type, read-only). On the target side, jushuitan.itemsku.upload pushes the product catalog (EXECUTE type).

Key field mapping table:

The middleware handles three jobs: code mapping, resolving unit and brand auxiliary data, and cleansing the shelf-life zero value.

How to Configure in Qeasy

In the Qeasy integration platform, this strategy is decomposed into a three-part structure: source connector + transformation + target connector.

1. Source connector: Choose Kingdee Cloud as the source platform, configure the executeBillQuery API. In the request body, only pick the fields needed for this push—avoid pulling the entire material master in one shot.
2. Middleware transformation: Qeasy's field mapping table centrally maintains the mappings between Kingdee codes and Jushuitan codes, and between Kingdee custom auxiliary data and Jushuitan text values. A common practice among Qeasy customers is to keep all custom field (F_XC_*) code-value mappings in a single dedicated mapping table managed centrally by the platform, rather than scattered across multiple strategies.
3. Target connector: Choose Jushuitan as the target platform and invoke jushuitan.itemsku.upload. We strongly recommend turning on idCheck so the platform uses the product code as an idempotency key, preventing duplicates caused by retries.

Qeasy's ability to push header and body data in phases is critical here. Material archives span multiple business modules (basic info, sales info, inventory info), so during configuration they should be split into multiple sub-steps that execute in dependency order. If one step fails, the entire archive will not be polluted.

Implementation Steps

Together with the customer, we broke the rollout into three scheduling phases:

1. Full initial load: On day one of strategy go-live, manually trigger a full load to push every active material from Kingdee to Jushuitan at once. This is the baseline alignment that brings both systems into sync.
2. Set the incremental starting point: Align the incremental start in Qeasy to the same timestamp as the full-load trigger. After that, poll every 5 minutes during business hours (*/5 7-23 * * *) to fetch newly created or changed materials.
3. Schedule frequency: High frequency (5-minute intervals) during the day keeps the e-commerce side current; low frequency or paused at night leaves Kingdee's back-end a window for batch processing.

The safe approach is to run an "incremental plus full-load dual track" during the first week after go-live. Each record goes through the incremental branch for individual push, while a full-load reconciliation runs every early morning to diff both sides. Any gaps found in the logs get re-pushed. Once the system is stable for one week, disable the full-load reconciliation and keep only incremental.

Lessons Learned from the Field

1. Code mappings not managed centrally. The first time we did this, every customer kept the Kingdee-to-Jushuitan code mapping table embedded inside the strategy, scattered across a dozen strategies. Changing a field name meant searching through a dozen places. The safe approach is to use Qeasy's mapping table for unified maintenance and let strategies only reference, never hard-code.
2. Shelf life of 0 pushed as a real value. Materials without shelf-life data in Kingdee default to 0, and pushing that straight into Jushuitan makes every product a "0-day shelf life" item. The middleware must include a case when '0' then '' else value end cleanse, otherwise the e-commerce side will be flooded with near-expiry products.
3. Auxiliary data fields not resolved to code values. Kingdee's "brand" field is auxiliary data; the raw return is an internal code, and you must call .FDATAVALUE to get the display name before pushing. Otherwise, Jushuitan will display a string of numbers.
4. idCheck turned off causes duplicate records. The first version did not have idempotency check enabled, so network-jitter retries created duplicate products. Strongly recommend turning on idCheck on the target connector so the platform uses sku_id as the dedup key.
5. Daytime scheduling collided with business peak. Initially we set the sync frequency to every minute, which happened to land right on Kingdee's month-end batch processing window and slowed the back-end down. Changing it to */5 7-23 * * * made the problem disappear.

Applicable and Non-applicable Scenarios

Applicable: Enterprises that use Kingdee Cloud as the back-end ERP and Jushuitan as the e-commerce front-end; material master data that requires a single source of truth and code-based idempotent push synchronization.

Not applicable: Scenarios where materials must be edited bidirectionally in both systems; businesses where material changes are frequent but real-time requirements are looser than 5 minutes (use a change-notification + message-queue approach instead); cross-organization, cross-account material distribution.