MES Production Replenishment Sync to Kingdee Cloud: Single-Strategy Tutorial
What This Strategy Solves
In discrete manufacturing, MES is the source of truth on the shop floor, while ERP is the authoritative ledger for finance and supply chain. Once a production replenishment document is generated in MES—for example, a shortage discovered mid-process, a work-order backflush, or an abnormal material issue—it must flow into ERP quickly; otherwise, inventory and cost rollups drift. The strategy we delivered is: incrementally syncing internal production replenishment documents from a manufacturing MES (web) into Kingdee Cloud as production replenishment documents, linked to the ERP-side production order.
The classic pitfall we have seen in real projects: everything looks synced, but three months later the numbers do not match. The root cause is almost always a poorly designed code mapping, a document number collision, or a header/line write split that fails silently. We used the Qeasy data integration platform to wrap the source-side API, paginated query, and target-side batchSave into an observable, replayable strategy.
Data Flow and Field Mapping
The flow is unidirectional: Source MES (WebAPI / common/search) → Qeasy middle layer (clean, map, dedupe) → Target Kingdee Cloud (batchSave).
Key field mapping:
| Business Meaning | Source MES Field | Middle Layer | Target Kingdee Field |
|---|---|---|---|
| Document number | orderNo | Pass-through, used as idempotency key | FBillNo ({{pickNo}}) |
| Date | createTime | Format to yyyy-MM-dd | FDate ({{createTime}}) |
| Document type | (none on source) | Constant | FBillType = SCBLD01_SYS |
| Issue organization | wsId / org code | Code mapping table | FStockOrgId = 100 |
| Production org | Org code | Code mapping table | FPrdOrgId = 100 |
| Material code | Material number | Material mapping table | FMaterialId |
| Quantity, lot | Child rows | Header/line staged write | FQty, FLot |
| Linked production order | MO number | Reference key mapping | FMoBillNo |
The two most critical jobs in the middle layer: centralized management of code mappings (material, org, owner type, warehouse all live in one mapping table), and staged header/line writes (batchSave the header first to obtain FID, then loop the line entries with FEntryId). These are the two patterns we see most often across Qeasy deployments.
How to Configure on Qeasy
Configuring a strategy on Qeasy comes down to a source connector + a target connector + a transformation flow + a schedule.
Source connector: pick the WebAPI adapter and register the common/search endpoint with a request body containing params, pageNum=1, pageSize=100, wsId, and queryKey=2. Note that wsId is the work station identifier and decides which workshop's replenishment data is pulled; whenever you switch workshops, update it accordingly.
Target connector: pick Kingdee Cloud's batchSave API and hard-code the document type as SCBLD01_SYS, which is the standard document type for production replenishment.
Transformation flow (the core):
- Field mapping: use the Qeasy expression editor to map MES
orderNotoFBillNoand formatcreateTimeintoFDate. - Code mapping: for material, org, and owner type, strongly recommend centralizing them in Qeasy's Mapping Table instead of embedding them in transformation scripts. The reason is explained in the pitfalls section.
- Line handling: enable "staged write" so the header is saved first, then the body rows are written in a loop.
- Idempotency: use
FBillNoas the dedupe key and skip already-existing documents.
Scheduling: start with a one-shot full backfill, then switch to incremental.
Implementation Steps
We split the rollout into three phases to avoid missing historical data when switching straight to incremental.
Step 1: Align the incremental cursor. Pull a full load from the source MES once and set the incremental starting timestamp, normally the last successful sync time. Store this timestamp in the strategy's cursor variable on Qeasy; every subsequent run filters by createTime > last_sync_time.
Step 2: One-shot full load. Manually trigger a full backfill to push the backlog of replenishment documents created before the strategy went live. The standard approach is to run it first against a test tenant, verify that code mappings, document type, and org IDs are correct, then switch to the production tenant.
Step 3: Schedule frequency. Replenishment activity is concentrated during day shift from 07:00 to 22:00, so we set the crontab to * 7-22 * * * (every 5–10 minutes depending on volume) and stop at night to reduce load on MES. Running incremental and full in parallel is a common pattern among Qeasy customers: incremental day-to-day, full once a month to detect cursor drift.
During the first week after go-live, we recommend a daily manual reconciliation between the replenishment document count in Kingdee and the MES daily report.
Lessons Learned from the Field
Pitfall 1: code mappings embedded in scripts are unmaintainable. On our first project we wrote material mappings directly into a Python script, and an org change took three days to roll out. The safe pattern is to maintain mappings centrally in Qeasy's mapping tables, one table per dimension (material, org, warehouse, owner type), and reuse them across strategies.
Pitfall 2: header written successfully, lines failed silently. When Kingdee's batchSave passes header validation but fails on a line item, the API can return a partial success. The classic mistake is treating HTTP 200 as full success. The safe pattern is to enable Qeasy's row-level response parsing, compare the success flag per row, and retry the failed rows separately.
Pitfall 3: wsId not updated when switching workshops. MES is multi-workshop and multi-workstation; wsId defines the data scope. We once had an incident where wsId was hard-coded and a new workshop came online but no replenishment documents flowed in. The safe pattern is to expose wsId as a configurable mapping variable that switches by organization.
Pitfall 4: document number collisions. MES orderNo rules and Kingdee FBillNo rules differ, and a direct pass-through can collide. The safe pattern is to add a pickNo transformation in the middle layer that prefixes the MES number (e.g., BL_), which preserves traceability and avoids collisions.
Pitfall 5: cursor drift causing missed records. MES createTime is server time; if it is across time zones or skewed, incremental filtering will miss boundary records. The safe pattern is to enable idCheck=true on the id field and use the primary key as a secondary check, automatically triggering compensation when IDs are non-contiguous.
When This Applies and When It Does Not
Applies: MES is the executor for replenishment/issue and ERP needs inventory and cost rollups; the production order already exists in ERP and MES only feeds back execution; the number of workshops is manageable (tens, not hundreds) and the code mapping table can be maintained.
Does not apply: both MES and ERP are allowed to create replenishment independently and bidirectional sync is required; the workshop count is huge and material codes are chaotic; the business requires sub-second latency (this strategy runs at minute-level; for sub-second, go through a direct message queue).