Employee Master Data Sync in Practice: Field Mapping from Weaver User Table to Kingdee Cloud and Lessons Learned

What This Strategy Solves

In a real project, a manufacturing enterprise adopted Kingdee Cloud as its supply chain core system, but organizational and HR data had long lived in the source system's (Weaver) user table. New hires, transfers, and terminations were handled in the source system, yet downstream document creation (purchase orders, sales orders, expense claims) had to land in Kingdee Cloud. Both sides kept employee profiles, and after three months the audit numbers no longer matched — "WangXX – Technology Dept – Engineer" in one system versus another variant in the other — and workflows started to jam. We used the Qeasy data integration platform to take over this master data sync chain, with one single source of truth: wherever HR makes changes, downstream follows.

Data Flow and Field Mapping

The overall flow is unidirectional: source system employee table → Qeasy middle layer → Kingdee Cloud employee profile. The middle layer handles three things: code mapping, field cleansing, and change identification.

Business Semantics	Source Field	Middle Layer	Target Field	Notes
Employee code	USER_ID	Pass through as primary key	Code	Immutable once generated
Name	USER_NAME	Trim, full-width to half-width	Name	Manual intervention if needed
Department	DEPT_NAME	Lookup in Qeasy mapping table	Department code	Use code, not name
Position	POST_NAME	Same as above	Position code	Position dictionary must exist first
Mobile	MOBILE	Mask validation, format check	Mobile	Failures route to exception table
Entry date	ENTRY_DATE	Normalize date format	Entry date	yyyy-MM-dd
Status	STATUS	1→Active / 0→Terminated	Employee status	Terminate ≠ delete
Email	EMAIL	Format check	Email	Optional

How to Configure in Qeasy

Step 1, connect the source data source. Create a new SQL Server data source connection with sanitized credentials, select only the required employee user table, and grant read-only permission to the database account — never dbo.

Step 2, connect the target system. Kingdee Cloud uses API access via Qeasy's built-in Kingdee adapter. Credentials should be injected through configuration items, never hardcoded in scripts.

Step 3, build code mapping. Department and position are stored as Chinese names in the source system but as codes in Kingdee. Do not write the mapping inline in every strategy. Maintain a single mapping dictionary table in Qeasy, and let every strategy that references department/position look up that table. A common pattern we see on customer sites is "centralized code mapping" — keep it out of individual strategies.

Step 4, build the field mapping canvas. Drag source fields to target fields and apply Qeasy's transformation functions in between (trim, date formatting, status code translation, etc.). For validation-heavy fields like mobile and email, route failures through Qeasy's exception branch to a "data exception table" rather than aborting the whole batch.

Step 5, configure trigger and scheduling. This strategy is master data, so incremental trigger is sufficient. See the next section for details.

Implementation Steps

Phase 1: Full initialization. This is a cold-start phase, run only once. Schedule it during off-peak hours. In Qeasy, write the source table query to only fetch incrementally-needed fields (e.g., WHERE update_time > '2000-01-01'), and set the start time parameter to the actual historical starting point. Build all historical employee profiles in one go. Coordinate with Kingdee's "employee import" interface to ensure root nodes for organization, position, and department exist on the Kingdee side first.

Phase 2: Confirm the incremental starting watermark. After full initialization, the incremental starts from where full ended. Record the maximum update_time of the source as a "sync watermark" variable in Qeasy, and each run pulls only update_time > watermark. Once the watermark is set, do not rewind it casually — doing so causes duplicates or primary key conflicts.

Phase 3: Scheduling frequency. Master data does not need minute-level cadence; 5–15 minutes is usually enough. If HR workflows demand tighter latency, you can compress to 1 minute, but first evaluate the write pressure on Kingdee's side. In private deployments, Qeasy's scheduler itself is not the bottleneck — the bottleneck is usually Kingdee's API rate limiting. We recommend starting at 10 minutes and tuning after a week of observation.

Phase 4: Monitoring and alerting. Configure monitors for sync count, failure rate, and runtime in Qeasy. Push alerts to the IM group when failure rate exceeds a threshold. Distinguish "this sync returned 0 rows" (normal) from "this sync failed" (requires immediate attention).

Lessons Learned

Do not match codes by name. The classic mistake is matching DEPT_NAME='Technology Dept' directly. The day the source system renames a department, every downstream employee's department goes haywire. The safe approach is to maintain a DEPT_CODE on the source side and align by code.
Do not physically delete terminated employees. Once employee master data is referenced by downstream documents (who created the order, who approved it), physical deletion breaks the audit chain. Configure the mapping rule to translate source-side "terminated" into target-side "employee status = terminated", not delete.
Mobile/email validation failures must not block the whole batch. One bad mobile number should not jam 200 other records. Configure the exception branch: failed rows go to the exception table, the rest proceed.
Persist the incremental watermark. Do not store the watermark in memory. When Qeasy restarts or upgrades, the in-memory watermark is lost. Persist it in a database table or a Qeasy persistent variable.
Build organization/position/department root nodes on the Kingdee side first. Without department and position dictionaries in place, employee profiles cannot be written. During cold start, run the "organization/position/department" initialization strategy first, then the employee strategy.

Applicable and Non-Applicable Scenarios

Applicable: Unidirectional master data sync, relatively stable field structures, HR workflows centralized in the source system, the target system as the downstream document system. Private deployment, latency-tolerant (minute-level acceptable).

Not applicable: Bidirectional sync (HR edits on both sides), frequently changing field structures, sub-second real-time requirements, or when Kingdee itself is the HR system of record. In these cases the strategy direction must be reassessed and this configuration cannot be applied as-is.