Supplier Master Data Query-Only Sync: A Practical Guide Between Jushuitan and Kingdee Cloud

What This Strategy Solves

A retail enterprise uses Kingdee Cloud as the back-office ERP and Jushuitan as the store and e-commerce front end. Supplier master data has long been maintained exclusively in Kingdee, while Jushuitan only reverse-looks-up suppliers by code at purchase-order time. To keep fields like supplier name, creating organization, using organization, and description consistent across both systems, they need a read-only query channel: pull the latest supplier list from Kingdee on a schedule into the middle layer, ready for downstream strategies to consume — without writing anything back to Jushuitan. This is exactly what the "Query-Only Kingdee Supplier Info" strategy is for: it is the most fundamental and stable baseline in the supply-chain integration solution.

Data Flow and Field Mapping

The entire pipeline is one-directional read: source Kingdee Cloud → middle layer Qeasy Data Integration Platform → target "Write Null Operation". The so-called "Write Null Operation" is not a bug but an intentional design: Qeasy attaches a no-op write endpoint on the target side so that the scheduler can complete its loop normally while keeping the data in the middle layer for downstream strategies to consume.

Key field mapping (source system → middle layer):

On the Kingdee side, the executeBillQuery WebAPI is used for form-based queries, taking the organization and filter conditions as parameters and returning a structured supplier list. Qeasy passes these fields through transparently without rewriting them.

How to Configure in Qeasy

In the Qeasy Data Integration Platform, this strategy is very lightweight to configure. Three core steps:

1. Source system connection: Choose Kingdee Cloud as the source system and fill in the API gateway address and authentication information (sensitive fields such as accounts and keys are redacted here). Select executeBillQuery as the api, POST as the method, and mark effect as QUERY.
2. Field selection: Tick FSupplierId, FNumber, FName, FCreateOrgId_FNumber, FUseOrgId_FNumber, and FDescription as return fields. Point both number and id to FNumber and enable idCheck to avoid duplicate pulls.
3. Target configuration: Choose the built-in "Write Null Operation" in Qeasy as the target palatom, mark effect as EXECUTE, and leave request and response empty. This way the scheduler completes each round with a clean "success" signal, which is friendly to dashboard statistics.

We have seen many customers directly write the query result back into Jushuitan at this step, only to discover later that supplier code naming conventions are inconsistent and downstream purchase orders fail to match. The safer approach is to query only, keep the middle layer, manage code mapping centrally, and then decide whether to write back.

Implementation Steps

Break the rollout into three phases for a steady rhythm:

• Phase 1: Incremental starting point. Before the first run, confirm a "supplier last-modified-time" baseline table in Kingdee. Qeasy pulls the first full snapshot sorted ascending by FSupplierId as the starting point for subsequent increments.
• Phase 2: Full-volume trigger. Temporarily set the crontab to 0 0 1 1 1 (1st of each month, midnight) to run one full reconciliation, confirming that row counts and key fields are consistent between the middle layer and Kingdee.
• Phase 3: Scheduling frequency. After go-live, change it to 5-59/30 7-23 * * *, i.e., every 30 minutes from 7:00 to 23:00 daily — near-real-time during business peaks, no database disturbance during off-hours.

The 1 1 1 1 1 crontab on the target side is effectively inert because the endpoint is a no-op write; it only acts as a placeholder.

Lessons Learned

1. "Query-only" accidentally changed to write. The most common pitfall on the customer site: when a second-line developer sees "target is null operation", they assume it is misconfigured and manually switch it to push suppliers into Jushuitan. Duplicate records then appear in Jushuitan, and after three months the two sides no longer reconcile. The typical mistake is underestimating the value of the middle-layer cache.
2. Required fields missed in the request. FCreateOrgId_FNumber and FUseOrgId_FNumber are required by Kingdee. If the query condition does not include an organization, Kingdee returns an empty set. It is recommended to hard-code a default organization code into the Qeasy request parameters.
3. Numbering scheme confusion. Kingdee's FNumber does not match Jushuitan's supplier short code. When doing staged header-and-line synchronization, the code mapping must be maintained centrally rather than scattered across multiple strategies.
4. Database pressure during peak hours. A query every 30 minutes works fine below 50,000 records. Above that, add pagination or split by organization, otherwise the Kingdee front end will be slowed down.
5. Misleading logs from the no-op endpoint. After the target "Write Null Operation" succeeds, the log shows "success", but nothing is actually written. Operations engineers seeing this for the first time will be confused. It is recommended to label the strategy description clearly with "QUERY ONLY".

Applicable and Non-Applicable Scenarios

Applicable: Kingdee is the single source of truth for supplier master data, and Jushuitan or other front-end systems need to reverse-look-up by code, or downstream strategies need to consume this snapshot. Not applicable: scenarios requiring real-time write-back of supplier information to the front end, or dual-master mode where both sides independently maintain supplier archives — those scenarios should use a "Bidirectional Supplier Master Sync" strategy, not "Query-Only".