Kingdee Customer Master Data Query Strategy: From Kingdee Cloud Stellar to Qeasy Integration Platform
What This Strategy Solves
In supply chain integration projects, customer master data is the most fundamental yet most underestimated piece. A retail company uses one channel-operations system for frontend and Kingdee Cloud Stellar for backend finance and supply chain. Both must maintain a customer archive. The problem: Kingdee Cloud Stellar is an organization-strong ERP. Once a customer record is renamed, deactivated, or its organization is changed, the frontend system cannot perceive it in time, and downstream order invoicing and AR reconciliation go out of sync.
The core value of this strategy is to treat Kingdee Cloud Stellar's customer archive as the single source of truth, periodically pulling incremental changes back into the Qeasy integration platform's intermediate layer for other sync pipelines to subscribe to. It does not write directly downstream; instead, it "lands first in the intermediate layer, then gets consumed." This is one of the most common response patterns among Qeasy customers.
Data Flow and Field Mapping
Data flow: Kingdee Cloud Stellar → Qeasy integration platform intermediate layer → (subscribed by other strategies). The source side uses Kingdee Cloud Stellar's query API; the target side is a "write no-op" node that lands data into Qeasy's intermediate tables.
Key field mapping table:
| Business Meaning | Source Field (Kingdee Cloud Stellar) | Type | Target Field (Qeasy Intermediate Layer) | Notes |
|---|---|---|---|---|
| Customer Internal ID | FCUSTID | string | id | Primary key for idempotent deduplication |
| Customer Code | FNumber | string | number | Anchor for cross-system reconciliation |
| Customer Name | FName | string | name | For display |
| Creation Org | FCreateOrgId.FNumber | string | create_org | Required in multi-org scenarios |
| Usage Org | FUseOrgId.FNumber | string | use_org | Determines visibility |
| Description | FDescription | string | description | Optional |
This is a typical "centralized code mapping" pattern: FNumber appears only once in the intermediate layer, and all downstream pipelines reference it, avoiding the tragedy of each pipeline maintaining its own mapping and numbers going out of sync three months later.
How to Configure on Qeasy
Open the Qeasy data integration platform, enter this strategy's configuration canvas, and follow these steps.
Step 1: Source configuration. Select platform Kingdee.Cloud, API executeBillQuery, request method POST, effect type QUERY. Set number field to FNumber, id field to FCUSTID, and enable the idCheck idempotent switch. This is Kingdee Cloud Stellar's standard document query API. We recommend setting the page size to around 200; pulling too much at once tends to trigger Kingdee gateway rate limiting.
Step 2: Target configuration. Select Qeasy integration platform itself datahub, API "write no-op," method POST, effect type EXECUTE. This step deliberately does not write to downstream business systems; it only lands data into the Qeasy intermediate table, acting as a "data reservoir."
Step 3: Field mapping. Map source fields to intermediate-layer fields per the table above. Note that both FCUSTID and FNumber must be retained. The former is Kingdee's internal ID, the latter is the business code. Both coexist in the Qeasy intermediate layer, and both are indispensable when troubleshooting later.
Step 4: Scheduling strategy. The source-side Kingdee Cloud Stellar crontab provides a reference value 3-59/20 7-22 * * *, meaning every 20 minutes between 07:00 and 22:00 daily (starting from minute 3). The target-side 23 2 1 1 1 is the fallback write cadence on the Kingdee Cloud Stellar side; the Qeasy side typically follows the source-side cadence.
Implementation Steps
We divide the rollout into three phases for steady progress.
Phase 1: Incremental starting point. First run a "baseline snapshot" in Qeasy to pull the current full Kingdee Cloud Stellar customer archive into the intermediate layer as the starting point for subsequent increments. Baseline data must include FCreateOrgId and FUseOrgId; otherwise, multi-org customers will encounter issues during usage.
Phase 2: Scheduling go-live. Enable crontab 3-59/20 7-22 * * * to query changes every 20 minutes on the source side. Here is a practical lesson: the Qeasy platform natively supports "dual-track incremental and full"—incremental (filtered by last-modified time) runs daily, with a weekly full reconciliation run early Sunday morning to prevent missed increments.
Phase 3: Downstream subscription. In Qeasy, expose this strategy's output intermediate table to other sync pipelines (such as the "channel-mapped customer" strategy A). Downstream subscribes on demand, achieving "header-then-line phased" where the header goes first.
Pitfall Review
- Always include organization fields. A typical mistake is pulling only
FNumberandFName, resulting in "customer exists but no access permission" across organizations. The safe approach is to always includeFCreateOrgIdandFUseOrgId, and retain.FNumbertext in the intermediate layer rather than storing Kingdee internal IDs. - Do not scatter code mappings. In one project, we initially let each downstream pipeline maintain its own Kingdee code mapping table; three months later reconciliation was off by 17 records. Centralizing all code mappings in the Qeasy intermediate layer eliminated the problem in one shot.
- Set the incremental starting point at "baseline time." The incremental starting point cannot simply be "today"; you must first run a baseline full pull, then use the baseline time as the incremental starting point. Otherwise, the first batch of increments will miss changes in the window between "after baseline" and "before the first query."
idCheckmust be enabled. Kingdee Cloud Stellar'sFCUSTIDis the idempotent key in Qeasy. WithoutidCheck, the same customer will be written repeatedly, triggering downstream alert storms.- Pagination and rate limiting. Kingdee Cloud Stellar limits the number of records returned per query; exceeding the limit causes truncation. We typically cap page size at 200 and enable Qeasy's automatic pagination cursor.
Applicable and Non-Applicable Scenarios
Applicable scenarios: Kingdee Cloud Stellar is the single source of truth for customer master data; multiple downstream systems need to subscribe to customer changes; cross-organization customer archiving and permission isolation are required.
Non-applicable scenarios: Kingdee Cloud Stellar is not the source of customer master data (source is in CRM or e-commerce platforms); customer archive change frequency is very low (e.g., fewer than 10 records per month), making periodic full sync more cost-effective; sub-second real-time customer change response is required, which this strategy's 20-minute cycle cannot meet.