Syncing Kingdee Production Orders to MES Work Orders: A Flat-Mapping Practice with Qeasy

What This Strategy Solves

On the shop floor of a discrete manufacturer, the ERP and MES have long been two separate worlds: planners release production orders in Kingdee Cloud, while the shop still re-keys work orders into the MES by hand. Late data, mismatched figures, and missed orders are routine. The strategy dissected here uses one single sync to push already-approved and already-released Kingdee production orders into MES work orders automatically, so the shop dispatches against one and only one source of truth.

Data Flow and Field Mapping

Data flow: Kingdee Cloud (PRD_MO) → Qeasy data integration platform → MES (creatOrder).

Kingdee production orders are flat in structure. Each line entry (FTreeEntity) maps directly to one MES work order, using FTreeEntity_FEntryId as the idempotency key.

Key field mapping table:

Business meaning	Source field (Kingdee)	Target field (MES)	Mapping type	Conversion
Production order number	FBillNo	orderNo	DIRECT	Direct pass-through; serves as the business trace ID
Material master key	FMaterialId	materialUuid	DIRECT	Depends on the material master sync that built the mapping
Production quantity	FQty	orderNum	DIRECT	Convert to int
Line entry ID	FTreeEntity_FEntryId	outerOrderBomId	DIRECT	Key field for idempotency and lookup
Company code	—	companyCode	CONSTANT	Fixed value; multi-tenant identifier on the MES side
Spare quantity	—	spareNum	CONSTANT	Currently empty
BOM version	—	bomVersion	EMPTY	Not mapped yet; reserved for extension
Routing version	—	flowchartVersion	EMPTY	Not mapped yet
Workshop UUID	—	workshopUuid	EMPTY	Source has FWorkShopID_FNumber, not wired up

FMaterialId is not the MES-side primary key. The production-order strategy should not invent its own material mapping. The pragmatic pattern, and a common Qeasy customer default, is centralised code-mapping management: let the material and workshop master sync strategies settle first, then have the production-order strategy use _findCollection to look up the MES material UUID.

Configuring It on Qeasy

Source connection: Create a Kingdee Cloud data source, pick executeBillQuery, business object PRD_MO, primary field FBillNo, line key FTreeEntity_FEntryId, page size Limit=500.
Target connection: Create a MES data source, endpoint /api/creatOrder, POST, EXECUTE type.
Field mapping: Configure per the table above; mark DIRECT / CONSTANT / EMPTY; tick the int conversion on FQty.
Filter conditions: In the source FilterString write FDocumentStatus in ('C','D') and FStatus in ('2','3','4','6') and (FApproveDate >= '{{LAST_SYNC_TIME|datetime}}' or FModifyDate >= '{{LAST_SYNC_TIME|datetime}}' or FConveyDate >= '{{LAST_SYNC_TIME|datetime}}' or FCancelDate >= '{{LAST_SYNC_TIME|datetime}}') and FWorkShopID.FNumber != 'BM000022'.
Lookup (optional): If you need workshopUuid, use _findCollection against the workshop master sync's result set.
Write policy: Header and body share the same flat source, no need to split header/body in stages; the MES side relies on outerOrderBomId for idempotency.
Logging and alerts: Enable Qeasy's retry and alerting; group logs by order number to make manual remediation easier.

Implementation Steps

The recommended rollout is a three-phase approach — incremental start point → full backfill → steady-state scheduling — which is a typical "incremental plus full dual-track" pattern seen across Qeasy deployments.

Phase 1: Pick the incremental start point. Pick a clear timestamp on the Kingdee side (e.g. the latest approval time in the last 7 days) as the initial LAST_SYNC_TIME so historical orders do not flood the MES.
Phase 2: Full backfill (when necessary). If the MES is going live on an empty database, temporarily drop the time filter and run a full sync; restore the filter immediately after, then manually reconcile order count vs work order count.
Phase 3: Steady-state scheduling. Configure cron * 7-22 * * * to cover the daytime release peak; pause at night to leave the database room for stats and backups.
Phase 4: Observation and extension. During the first week, monitor duplicate work orders, status drift and workshop exclusion; then extend BOM version, routing version, planned start/finish dates and so on as needed.

Pitfall Review

Running the production-order sync before the material mapping exists. materialUuid is a primary key on the MES side; without the mapping the MES will reject the call or generate dirty data. The Kingdee→MES material master sync must run first.
Forgetting the FDocumentStatus filter. Filtering only by business status will push "saved but unapproved" orders downstream, leaving the shop with work orders it cannot execute. Keep FDocumentStatus in ('C','D').
Dropping the FWorkShopID.FNumber != 'BM000022' exclusion. Outsourced or pilot workshops leaking into MES dispatch will break the scheduling rules. Putting it explicitly in FilterString is far safer than manual filtering.
Using FTreeEntity_FEntryId as if it were the order number. It is the line ID, not FBillNo; fine as an idempotency key, but the shop floor will not recognise it on a kanban.
Cron set to every minute, all day. Production orders peak during business hours; a high-frequency all-day schedule just stresses the database with no benefit. Once an hour from 7 to 22 is plenty.

When to Use and When Not to

Use it: When Kingdee Cloud is the ERP planning source, the MES owns shop-floor execution, and the MES uses outerOrderBomId for idempotency, in a discrete-manufacturing context where material and workshop masters already have their own sync strategies in place.

Do not use it: For complex scenarios that need to sync Kingdee's nested BOM structure, routing steps or process versions into the MES, or when the MES primary-key logic does not depend on the external line ID.