Kingdee Cloud Supplier Master Query-Only Sync: A Single-Strategy Implementation Guide

What This Strategy Solves

In supply chain integration, supplier master data is the foundation for every downstream process—purchase orders, goods receipt, reconciliation. In one real project, the client distributed supplier master data to both an internal ERP and an external collaboration system; each side maintained its own copy and within three months the numbers no longer matched—coding conflicts, name mismatches, inconsistent enable/disable status, and a finance team left staring at unreconciled ledgers. We used the Qeasy data integration platform to host this "query-only" strategy: a one-way pull from Kingdee Cloud as the authoritative source, distributed downstream. This guarantees a single source of truth and eliminates dual-write conflicts.

Data Flow and Field Mapping

Flow: Kingdee Cloud → Qeasy integration hub (middle layer) → downstream consumers (e.g., Lingxing ERP).

In this strategy, Kingdee is the source. It pulls data through the executeBillQuery interface using three query fields: FSupplierId, FNumber, and FName. The data lands in the Qeasy middle layer—the target side is an "empty-write" execution node—so nothing is actually persisted; instead, the data hangs on the hub for other strategies to consume.

Key field mapping:

Two metadata flags matter: idCheck=true and number=FNumber. The first lets Qeasy decide insert vs. update by primary key; the second treats the business code as an external number, avoiding remapping downstream.

Configuring in Qeasy

Source (Kingdee Cloud) configuration points:

• Interface: executeBillQuery (POST), type QUERY, effect QUERY.
• Required request fields: FSupplierId, FNumber, FName; add filter conditions (e.g., FForbidStatus='A' for enabled only) as needed.
• Pagination: Limit=100, StartRow=0. Kingdee caps single-response rows; 100 is a battle-tested value—don't be greedy.
• Metadata flags: idCheck=true, autoFillResponse=true, buildModel=false. The first dedupes and decides upsert; the second lets Qeasy auto-parse the response so you skip manual modeling.

Target (Qeasy middle layer) configuration points:

• Interface is a WebAPI "empty-write" action, POST, idCheck=true. It does not actually persist; instead, it parks the data in the integration hub's data center for sibling strategies in the same tenant to subscribe to. This is a classic Qeasy pattern—centralized encoding mapping and field normalization on the platform, with each downstream subscribing independently so the source isn't queried repeatedly.

Implementation Steps

Phase 1: Define the incremental starting point For initial rollout, run a full sync first to establish a baseline. For the incremental anchor, use FSupplierId or FModifiedDate (if the material doesn't expose a modification time field, the cursor approach with the max internal ID is more reliable).

Phase 2: Full sync trigger Manually trigger a full sync in Qeasy and verify the returned row count and pagination loops match expectations. A typical failure: 5,000 suppliers with Limit=500 causes a single-request timeout—the safe practice is 100 with looping pagination.

Phase 3: Schedule frequency The crontab in the material is 10-59/15 7-22 * * *—every 15 minutes from 07:00 to 22:00 daily. This frequency suits business hours when supplier data needs to stay fresh; off-hours pausing reduces load on the source. Dual-track incremental + full sync is a common Qeasy customer pattern: high-frequency incremental for freshness, low-frequency full sync (recommended overnight) to catch anything the incremental missed.

Phase 4: Downstream subscription and validation Lingxing ERP subscribes to the middle layer and maps into its own coding system. During the first week post-launch, manually reconcile supplier counts and code differences between the two sides daily.

Pitfall Retrospective

1. Don't guess the pagination cap. executeBillQuery has a single-response cap; setting it to 500 or 1000 routinely triggers timeouts. 100 is the validated safe value.
2. Don't forget the FForbidStatus filter. Without an "enabled only" filter, disabled suppliers sync too, and downstream buyer files end up with "supplier not selectable" anomalies.
3. Understand idCheck semantics per side. On the source side it's for upsert decisions by internal ID; on the target side its meaning may differ—don't blindly copy the configuration.
4. Code uniqueness is non-negotiable. The source FNumber must be unique; if Kingdee allows duplicates, downstream will receive multiple rows with the same code, causing silent overwrites or outright corruption.
5. "Middle layer no-persist" ≠ "data lost". An empty-write target node is by design, but monitoring must look at Qeasy platform run logs—not just the target database's write count.

When to Use and When Not

Use when: supplier master authority lives in Kingdee Cloud, multiple downstream systems need to subscribe, freshness requirements are in minutes, and you don't want the source system bearing push pressure. Don't use when: bidirectional writes are needed, change-history audit is required, or field-level permission control is needed—those scenarios call for a full sync strategy with persistence and audit trails.