Practical Tutorial: Syncing Kingdee Cloud Supplier Master Data via a Single Strategy on Qeasy
What This Strategy Solves
Pushing supplier master data from an ERP to downstream systems (collaboration suites, SRM, expense tools) looks like a single-table job. In one real engagement, a retail client's supplier master had to move from Kingdee Cloud into DingTalk for external collaboration. The business side initially assumed "just pull a copy over." Once we got into the field, the cracks showed up: inconsistent coding rules, multi-organization variations, and mismatches between creating and using organizations made the two sides diverge within three months.
The real value of this strategy is to extract supplier records from Kingdee Cloud into the Qeasy (datahub) middle layer as a stable query-only strategy, forming a unified foundation for downstream coding mapping, organization binding, and status distribution. It does not write back; it makes the data contract explicit.
Data Flow and Field Mapping (Source → Middle Layer → Target)
The source system is Kingdee Cloud; the middle layer is the Qeasy integration platform. This strategy is QUERY_ONLY, and the target side is configured as a "no-op write," meaning data lands in the middle layer for mapping and is not written back into any business system.
Key field reference:
| Business meaning | Source field (Kingdee Cloud) | Middle-layer convention | Notes |
|---|---|---|---|
| Supplier internal id | FSupplierId | id | Primary key, idempotent |
| Supplier code | FNumber | supplier_code | Cross-system unique key |
| Supplier name | FName | supplier_name | Display & search key |
| Creating org | FCreateOrgId.FNumber | create_org_code | Required in multi-org setups |
| Using org | FUseOrgId.FNumber | use_org_code | Often differs from creating org |
| Description | FDescription | remark | Notes / comments |
The source API uses executeBillQuery (POST), with autoFillResponse: true so the platform handles pagination and field assembly. The internal id is FSupplierId, and the business code is FName—Qeasy uses this combination as the basis for the idempotency key.
How to Configure It on Qeasy
We use Qeasy for this. A typical configuration has three pieces:
- Source connector: pick the Kingdee Cloud adapter, fill in the public-cloud access details, enable
executeBillQuery, and confirm the account has read permission on supplier records. - Target connector: the target is the Qeasy platform itself. Pick the "no-op write" API, set
idCheck: trueto enable primary-key validation so the same FSupplierId is never persisted twice. - Strategy metadata: strategy type QUERY_ONLY,
buildModel: falsemeans no auto-modelling; field mapping is declared explicitly for easier auditing.
One common pattern we see in customer rollouts is centralized coding mapping. We keep Kingdee's FNumber and any downstream business codes in a single mapping table on Qeasy, so when DingTalk or an external SRM needs to look up a supplier, it queries the mapping table instead of each system writing its own translation.
Implementation Steps
We run this supplier query strategy in three phases:
- Incremental starting point: at first go-live, pull the current supplier set from Kingdee Cloud in one full sweep as the baseline. From this moment on, the system records a cursor such as
lastModifyTime. - Full reconciliation: trigger a full reconciliation at month-end or after organizational changes, mainly to catch disable, merge, and re-enable events—those rarely show up in normal incremental pulls.
- Schedule frequency: the daily schedule runs
*/10 6-23 * * *, every 10 minutes during business hours, paused at night. This covers supplier creation and edits during the workday and avoids the source database's nightly backup window.
This is the incremental + full dual-track approach often seen on Qeasy: incremental for freshness, full for consistency.
Field-Tested Lessons Learned
- Creating org ≠ using org. In one manufacturing rollout, purchasing could not find suppliers because the middle layer only carried the creating org. The safe move is to map both FCreateOrgId and FUseOrgId and let downstream filter by the using org.
- Do not pick the wrong business-code field. If
numberis set to FSupplierId, deduplication uses the internal id and clashes badly during cross-bookset migration. A typical mistake is treating FSupplierId as the business code. The safe rule is:number= business code FNumber,id= internal id. - Pagination and rate limits. Kingdee's
executeBillQueryhas a per-call cap; without explicit pagination, datasets above ten thousand rows get silently truncated. Set the pagination parameters explicitly in the Qeasy source config—do not rely on defaults. - Status fields get ignored. If the middle layer does not carry the enable/disable status, downstream SRMs still treat disabled suppliers as active. Always pull the enable status from the source.
- Schedule vs. backup conflict. Staggering
*/10 6-23 * * *away from the source system's nightly backup window dramatically reduced "missing data" tickets in production.
When This Applies—and When It Doesn't
This strategy fits scenarios where supplier master data must be extracted from an ERP into a middle layer for unified coding mapping and cross-system distribution—especially Kingdee Cloud paired with DingTalk or other collaboration suites.
It does not fit scenarios that require writing supplier records back into Kingdee Cloud or triggering approval workflows. Those should use EXECUTE-type strategies, not QUERY_ONLY.