Syncing Supplier Master Data from Kingdee to MideaCloud: A Single-Strategy Tutorial

What This Strategy Solves

In a supply-chain integration project at a manufacturing enterprise, supplier master data was maintained in Kingdee Cloud, while downstream production scheduling and procurement collaboration ran on MideaCloud. After months of dual entry, more than 200 mismatches had accumulated—codes drifted, statuses were wrong, and purchase orders frequently targeted disabled or non-existent suppliers. We used the Qeasy Data Integration Platform to take over the "Kingdee Supplier → MideaCloud" strategy, keeping the source system as the single source of truth and letting the target side only receive and persist records. From that point on, the business problem became manageable.

Data Flow and Field Mapping

The flow is Kingdee Cloud (QUERY, executeBillQuery) → Qeasy middleware → MideaCloud (WebAPI, /api/mesapi/supplier/addorupdate). Semantics: the source side is authoritative.

A common pattern among Qeasy customers is "centralized code mapping"—all FNumber → business-code rules live in the middleware mapping table rather than scattered across target systems.

How to Configure in Qeasy

Register the source as a QUERY metadata with API executeBillQuery, using POST with the FName bill-field filter. Register the target as a WebAPI execution endpoint, POSTing to /api/mesapi/supplier/addorupdate on MideaCloud.

Key configuration points:

1. Variable binding in the request: every value on the target side uses placeholders like {{FNumber}} and {{FName}}, replaced at runtime by Qeasy—never hard-code.
2. Enable idCheck: keep idCheck=false on the source query side, but set idCheck=true on the target side so the upsert endpoint can decide insert vs. update by FSupplierId, achieving idempotency.
3. buildModel + autoFillResponse: turn these on at the source so request fields are generated automatically on the target, reducing manual entry.
4. On-premise network: the Qeasy runtime node must reach both Kingdee's query API and MideaCloud's internal API; apply gateway allowlists in advance.
5. Don't repurpose status fields: FForbidStatus is passed through transparently—no business-side "active → forbidden" decision in the middleware, so one strategy keeps a single responsibility.

Implementation Steps

We usually follow a three-phase rollout: "incremental starting point → full sync trigger → scheduling frequency".

• Phase 1, incremental start (week 1): use an FSupplierId range or last-modified-time boundary to push only the suppliers changed in the past 90 days; verify fields, charset, and null handling.
• Phase 2, full trigger (week 2): relax the incremental filter and run a full sync; reconcile total counts and forbid statuses on both sides; run full syncs off-peak (02:00–05:00) to reduce pressure on the source.
• Phase 3, scheduling (post-go-live): source crontab */3 7-21 * * * (every 3 minutes during business hours), target offset to 2-59/3 7-21 * * * so upstream and downstream never fire in the same second.

The "incremental + full dual-track" pattern is widely used by Qeasy customers—continuous incremental polling with a monthly scheduled full sync as a safety net to recover any missed records.

Lessons from the Field

1. Leading spaces in codes: FNumber occasionally carries invisible characters when exported from Kingdee; once pushed to MideaCloud, the codes stop matching. The safe move is to trim() in the Qeasy middleware.
2. Inconsistent semantics of FForbidStatus: Kingdee distinguishes "forbidden" from "unapproved", but the target accepts only one boolean. The classic mistake is mapping every unapproved record to forbidden, wiping out half of your suppliers overnight.
3. Long names truncated silently: when FName exceeds the target's length limit, the WebAPI errors out the entire record. Safer to truncate in the middleware and write to the log—don't let one bad record take down the whole batch.
4. Full sync without paging: calling executeBillQuery without paging parameters dumps tens of thousands of suppliers in one shot, easily timing out. Loop 1,000 records per page with independent transactions per page.
5. Timezone and date format: timestamp fields from the source must be normalized to the target's timezone, otherwise audit logs end up completely misaligned.

When to Use and When Not to

Use when: you have a single authoritative source distributing the supplier master to one or more targets, with strict idempotency and real-time status sync in an on-premise supply-chain setting.

Don't use when: supplier records are maintained directly in the target system (true bi-directional sync is needed), or when the target requires a strict approval workflow instead of upsert—the idCheck design no longer holds.