Practical Tutorial: Master Data Sync from Kingdee Materials to JiJia Products

What this strategy addresses

Material master data is the foundation of any supply-chain integration. If codes and specifications drift between systems, every downstream document — purchase orders, stock movements, price lists — inherits the error. In one project, a retail customer used Kingdee Cloud as the finance and procurement backbone and JiJia ERP as the operations system of record. Both required the same material catalogue. When the team relied on manual exports, the two systems diverged within three months. This strategy pushes material records one-way, traceably, from the source system to the target, so master data has a single source of truth.

Data flow and field mapping

The flow is Kingdee Cloud (source) → Qeasy Data Integration Platform (middleware) → JiJia ERP (target). The middleware owns code mapping, field conversion, retry handling and audit logging.

The source uses executeBillQuery to fetch the material view, with FMasterId as the primary key and FNumber as the business code. The target uses POST /purchase/goods/product/create, accepting an object product plus an array productCartons (carton/box info).

Key field mapping:

How to configure on Qeasy

On customer sites, we typically structure this strategy as a three-stage pipeline: collect, map, write.

1. Collector (source): pick the Kingdee Cloud connector, choose executeBillQuery, and add FMasterId, FNumber, FName, FSpecification, FOldNumber to the request field list. For incremental runs, use FModifyDate >= ${lastSyncTime}; for full loads, omit the condition.
2. Mapper (middleware): use Qeasy's centralised code-mapping management so that FNumber → product.code lives in a maintainable mapping table rather than being hard-coded in scripts. This is a common pattern we see among Qeasy customers — it makes audits and root-cause analysis far easier. Header fields map one-to-one; array fields like carton info go through a sub-flow so grouping is preserved.
3. Executor (target): JiJia ERP target is POST /purchase/goods/product/create. Keep idCheck enabled so that on failure the platform re-queries by code and chooses UPDATE instead of blindly inserting duplicates.

Implementation steps

A phased rollout is the safest approach. We usually split it into three steps.

• Step 1 — verify the incremental baseline. Without enabling the scheduler, trigger one manual run to pull materials changed in the last N days and reconcile. A common issue on customer sites is that hundreds of disabled/frozen materials also get pulled, so add status filters here first.
• Step 2 — trigger a full load. After the stock is validated, run one full backfill and observe one to two full scheduling cycles. The source cron is 5 7-22 * * * and the target cron is 10 7-22 * * * — five minutes apart so the source finishes writing before the target re-queries.
• Step 3 — steady-state scheduling. Once stable, switch to incremental mode and tune the interval to every 15–60 minutes based on volume. Qeasy runs the strategy in a public-cloud environment, so no customer scheduler is required.

Pitfalls and lessons learned

• Pitfall 1 — passing carton info as a flat string inside product. productCartons is an array; flatten it and the target will reject the structure. Always send array fields through a sub-flow.
• Pitfall 2 — disabling idCheck causes duplicate inserts. If the source has no unique constraint, turning idCheck off leads to repeated INSERTs for the same code. The safer default is to keep idCheck on so the platform stays idempotent on code.
• Pitfall 3 — code mapping buried in scripts. Every change requires touching multiple scripts and debugging is painful. A common pattern among Qeasy customers is to centralise mappings into a config table that strategies only reference.
• Pitfall 4 — mixing full and incremental runs in the same scheduler. A misconfigured incremental filter can re-trigger a full load and overload the target. Run full loads once only; everything afterwards should be incremental.
• Pitfall 5 — ignoring status filters for disabled/frozen materials. Historical archives from the source will pollute the target's base-data library if not filtered.

When to use and when not to use

Use when: Kingdee is the single source of truth for material master and JiJia is the operations system receiving one-way upstream pushes; material changes are low-to-medium frequency and code consistency is critical — typical for retail and trading businesses. Do not use when: bidirectional sync is required, or JiJia also creates materials that must flow back to Kingdee. In those cases, a separate return-flow strategy with conflict-resolution rules is needed; this configuration alone is not sufficient.