Querying Kingdee Employees in Practice: The Last Mile of Basic Data Sync Between Guanyi Cloud and Kingdee Cloud Cosmos

What This Strategy Solves

"Querying Kingdee employees" looks unremarkable—it merely pulls personnel records from Kingdee Cloud Cosmos into the middle layer, without writing back to Guanyi Cloud. But in a real retail integration project, we found that if this strategy is missing or delayed, the "salesperson" and "creator" fields on subsequent sales orders and outbound documents will all be empty, front-end users cannot see the responsible person, and customer service cannot trace orders. Therefore, it is the "last-mile prerequisite" for document sync and must run stably before any business document strategy.

Data Flow and Field Mapping

The strategy direction is Kingdee Cloud Cosmos → Qeasy Data Integration Platform. After landing in the middle layer, it is not written back to Guanyi Cloud, but is referenced by other dependent strategies (sales orders, transfer documents, etc.) by primary key.

The source side calls Kingdee's executeBillQuery interface. The target side is configured as a "write empty operation" in Qeasy, meaning it only lands in the middle database for other strategies to JOIN.

How to Configure on Qeasy

1. Source platform connection: Register the Kingdee Cloud Cosmos private deployment address and account set info. Authentication follows the customer's actual authorization (masked here, not detailed).
2. API selection: Choose executeBillQuery, form select "Employee", method POST. Set idCheck to true to ensure downstream FID is uniquely trusted.
3. Field mapping: Check all of FNumber / FID / FName / FMobile / FEmail / FPostDept. Do not be lazy and only take the name—subsequent orders need to look up personnel by code.
4. Target platform: Qeasy itself acts as the target. Select "Write Empty Operation" for the API—only land in the database, do not write back to Guanyi Cloud. Keep autoFillResponse on to facilitate troubleshooting.
5. Scheduling: Source side */10 7-23 * * * (every 10 minutes during business hours); target side 2-59/10 7-23 * * * (offset by 2 minutes to avoid simultaneous pulls on both ends).

Implementation Steps

• Incremental start point: Pull all Kingdee employees once before go-live as the baseline; thereafter, increment every 10 minutes by FModifyDate.
• Full trigger: Run a full reconciliation at dawn on the first business day of each month to compensate for daily misses (e.g., employee disable/enable status changes that do not trigger modification time).
• Scheduling frequency: Business hours 7:00–23:00, every 10 minutes; stop during non-business hours to reduce pressure on the Kingdee private server.
• Dependencies: Set this strategy's depends_on to empty (its upstream is Kingdee itself). However, other document sync strategies must check it in "prerequisite dependencies" to ensure the personnel primary key is in place first.

Pitfall Review

1. Only syncing name, losing code: A typical mistake is to only take FName. After downstream orders are pushed, the "salesperson" displays correctly, but reverse lookup fails. The reliable approach is to store both FNumber + FID in the middle layer.
2. Writing employees to Guanyi Cloud: This step does not need to write back to Guanyi. Business staff mistakenly configure "target platform as Guanyi Cloud", causing code inconsistency between the two sides, making later cleanup very troublesome.
3. Ignoring disabled employees: When an employee is disabled in Kingdee, FForbidStatus is not within the current mapping scope, but downstream orders still reference them. The safe approach is to add a filter on the Qeasy side and mark disabled personnel as "unavailable".
4. Overlapping schedule times: If the source and target trigger at the same moment, the middle database will experience short-term null values. A 2-minute offset is an empirical value.
5. No full reconciliation: Only doing incremental sync, after 3 months some employees' fields become stale due to organizational adjustments not triggering modification time. A monthly full reconciliation is mandatory.

Applicable and Non-Applicable Scenarios

Applicable: Mid-to-large retail and e-commerce enterprises where Kingdee serves as the ERP master data source and Guanyi serves as the e-commerce frontend, needing to bridge "personnel primary keys" between the two—particularly in scenarios where sales orders and transfer documents frequently reference salespeople/creators. Not applicable: Lightweight scenarios where Kingdee and Guanyi are homogeneously deployed and personnel do not need cross-system references; or scenarios where personnel are maintained entirely independently in the HR module with no intersection with the supply chain.