BOM Master Sync in Practice: Incremental Pattern from Kingdee Cloud to MES

What This Strategy Solves

Pushing the Bill of Materials (BOM) from Kingdee Cloud to MES is almost always on the integration roadmap for any manufacturer. The hard part is not "can we push it," but rather: BOM is a parent-child structure with many lines that change frequently with process revisions; documents have draft/approved/closed states; and the field naming for quantity, scrap, and BOM version never matches between two systems. In one real project, the shop floor reported quantity mismatches three months after BOM went live; root cause was that document-status filtering was missing and the quantity numerator/denominator was not actually being passed through. So this strategy must solve: getting approved or closed BOMs into MES incrementally, safely, and at a controllable cadence.

Data Flow and Field Mapping

End-to-end flow: Kingdee Cloud (source) → Qeasy Data Integration Platform (middleware) → YSD MES (target). The source uses executeBillQuery to pull ENG_BOM; the target uses /api/bom/createBom (create) or /api/bom/editBom (update).

Key field mapping:

doseSon/doseMom are currently hard-coded to 1/1 — a classic "ship the wiring first, refine later" placeholder.

How to Configure on Qeasy

We used the Qeasy Data Integration Platform (轻易云) to host this strategy. Four configuration layers:

1. Source connector: Register Kingdee Cloud, configure executeBillQuery with form ID ENG_BOM, enable incremental time-window mode.
2. Target connector: Register the MES API connector with both /api/bom/createBom and /api/bom/editBom for create vs. update.
3. Field mapping: In the visual mapping panel, apply DIRECT / CONSTANT / TRANSFORM / COLLECTION per the table above; createTime uses _function REPLACE('{{FCreateDate}}','T',' ') to normalize the date format.
4. Centralized code mapping: Kingdee FITEMPPROPERTY and MES source are aligned today, so direct mapping works; if they diverge, promote the rule into a centralized code-mapping table rather than scattering it across strategies — one of the most common patterns we see on Qeasy projects.

Implementation Steps

• Phase 1 — Materials before BOM. BOM depends on parent materials existing in MES. Run the material strategy first and stabilize it, then start BOM. We follow an A→B→C sequence ordering.
• Phase 2 — Full trigger. First go-live uses full sync: remove the time filter and flush every approved/closed BOM as a baseline.
• Phase 3 — Switch to incremental. After baseline, change the filter to FDocumentStatus in ('C','D') AND (FModifyDate >= LAST_SYNC_TIME OR FApproveDate >= LAST_SYNC_TIME).
• Phase 4 — Scheduling. Run at the top of every hour (crontab: * 7-22 * * *), covering 7:00–22:00 working hours. If BOM changes are very frequent, tighten to every 15 minutes, but watch source API QPS.
• Phase 5 — Header and body staged go-live. Bring up header mapping first, then enable the items collection. This is another common Qeasy pattern — staging makes issues easier to localize.

Lessons from the Trenches

1. Status filter missing. Writing only the time window without status filtering pushed drafts and rejected BOMs as well, polluting MES. Safer rule: status condition first, time condition second.
2. Quantity hard-coded to 1. Using 1/1 as a placeholder works to get the wiring live, but forgetting to replace it later caused quantity mismatches. Mark the mapping with a "TODO: connect FNUMERATOR/FDENOMINATOR" note and review.
3. The T in ISO dates not replaced. Kingdee returns ISO timestamps with T; MES rejected them. One _function REPLACE('{{FCreateDate}}','T',' ') fixed it — a typical use of Qeasy expression functions.
4. Sub-item collection not configured. Header ran, but items was left unmapped — shop floor could not pick materials. Header and body must be staged and verified.
5. Wrong dependency order. Running BOM before materials made materialUuid unresolvable and writes failed. Qeasy's depends_on field exists precisely for this kind of prerequisite ordering.

When This Fits and When It Does Not

Fits: manufacturers running ERP and MES as decoupled systems, with BOM master data owned in ERP and consumed by MES; clear document state machines; moderate document volumes. Does not fit: scenarios where BOM is owned by MES, change frequency is extreme (per-second, requires a message queue), or ERP and MES share the same database.