BOM Sync in Practice: Kingdee Cloud → Sihua MES Modify Scenario Deep Dive
What This Strategy Solves
In a manufacturing ERP + MES dual-system architecture, the BOM (Bill of Materials) is the source for workshop picking, kitting analysis, and cost accounting. Once the ERP-side BOM changes (usage adjustments, new substitutes, scrap rate revisions) at a manufacturing company, if the MES side cannot reflect these in time, the workshop will produce against an outdated version, leading to work order scrapping and inflated inventory. This strategy specifically handles BOM modification sync: it pushes approved or closed BOMs from Kingdee Cloud to the Sihua MES editBom endpoint incrementally based on modification/approval time, ensuring the workshop always uses the latest routing.
Data Flow and Field Mapping
Data flow: Kingdee Cloud (BOM) → Qeasy Data Integration Platform → Sihua MES (BOM editBom).
The platform acts as the middle layer, responsible for fetching, cleansing, transforming, and dispatching, without persisting business master data. Key field mapping is as follows:
| Target Field (MES) | Source Field/Rule (Kingdee) | Mapping Type | Description |
|---|---|---|---|
| companyCode | Fixed constant | CONSTANT | Company code |
| erpId | FID | DIRECT | Kingdee BOM primary key |
| erpParentId | "0" | CONSTANT | Root node fixed at 0 |
| materialUuid | FMATERIALID | DIRECT | Parent material primary key |
| outerPartNo | FMATERIALID_FNumber | DIRECT | Parent material number |
| doseSon | "1" | CONSTANT | Usage numerator (can be changed to FNUMERATOR) |
| doseMom | "1" | CONSTANT | Usage denominator (can be changed to FDENOMINATOR) |
| lossRate | FSCRAPRATE | DIRECT | Variable scrap rate |
| source | FITEMPPROPERTY | DIRECT | 1 purchased / 2 self-made / 3 outsourced |
| property | "1" | CONSTANT | Fixed as physical |
| bomVersion | FNumber | DIRECT | BOM version number |
| createName | FCreatorId | DIRECT | Creator |
| createTime | REPLACE(FCreateDate,'T',' ') | TRANSFORM | ISO time → YYYY-MM-DD HH:mm:ss |
| updateName | FCreatorId | DIRECT | Modifier (can be changed to FModifierId) |
| updateTime | "" | CONSTANT | Can be changed to REPLACE(FModifyDate,'T',' ') |
| items | refund_order_list | COLLECTION | Child item collection, requires separate config |
How to Configure on Qeasy
In the Qeasy Data Integration Platform, this strategy corresponds to an independent "sync solution" with three configuration blocks:
- Source:
executeBillQuery(ENG_BOM) POST query, filter conditionFDocumentStatus in ('C','D')andFModifyDate|FApproveDate >= LAST_SYNC_TIME.LAST_SYNC_TIMEis automatically maintained by the platform, no manual intervention required. - Target: WebAPI
POST /api/bom/editBom,idCheck=true, meaning the platform will verify existence against MES usingerpIdbefore writing, avoiding accidental creation. - Field Mapping: Header goes through "Field Mapping" config, body (items) goes through "Child Item Collection" config. The platform supports nested array structures.
_function REPLACEcan be written directly in the expression box. The platform also provides_findCollection(cross-solution lookup) and_mongoQuery(complex conditions) as advanced tools.
Implementation Steps
- T0 Incremental Starting Point: At first launch, set
LAST_SYNC_TIMEto 00:00:00 of the project start date, run a "full backfill" once to push all approved BOMs in one go, ensuring baseline consistency on both sides. - T1 Full Trigger: Click the "Full Execution" button on the Qeasy solution. The platform will ignore timestamp filters and push all BOMs matching the current filter conditions to MES. Recommended during off-peak hours at dawn.
- T2 Scheduling Frequency: crontab set to
* 7-22 * * *, i.e., every hour from 7:00–22:00 daily. Covers daytime shift operations, avoids invalid calls during nighttime maintenance periods. - T3 Gray Release and Rollback: First validate header and body fields with 1–2 BOM documents, then release full volume. Every sync in Qeasy has execution logs; failures can be retried individually without affecting subsequent increments.
- T4 Monitoring and Alerting: The platform comes with a success rate dashboard. Recommend building a dedicated dashboard for "BOM Modification Sync" with enterprise WeChat alerts when failure rate exceeds 1%.
Pitfall Review
- Pitfall 1: createTime Format Inconsistency. Kingdee returns ISO 8601 (
2025-12-12T11:21:50), but the MES endpoint requiresYYYY-MM-DD HH:mm:ss. The safe approach is to use_function REPLACE('{{FCreateDate}}','T',' ')directly. The platform's expression box supports nesting—do not modify in pre-scripts, or it will be lost when switching environments. - Pitfall 2: Usage Numerator/Denominator Defaulted to 1. In the template,
doseSonanddoseMomare hardcoded as 1. After launch, we discovered Kingdee's FNUMERATOR/FDENOMINATOR were not transmitted, causing work order kitting errors. Recommendation: check the "unmapped field list" during solution review and map all business-critical fields like usage and scrap. - Pitfall 3: updateName Mistakenly Takes Creator. In the modification scenario,
updateNametakesFCreatorId, meaning it always displays the original creator. Kingdee has aFModifierIdfield. The correct approach is to change it to{{FModifierId.FName}}so audit traceability is accurate. - Pitfall 4: Dependent Materials Not Synced First. BOM's
materialUuidandouterPartNodepend on parent materials already existing in MES. A common pattern among Qeasy customers is to make this dependency into "Sequence A→B": first run material master data (Strategy A), then run BOM (Strategy B), declaring dependencies via thedepends_onfield. The platform will automatically wait. - Pitfall 5: Header and Body Phased Rollout. BOM is a parent-child structure; items contain child materials, usage, scrap, line numbers, etc. Pushing header and body together from the start makes troubleshooting very difficult. The safe approach is header first, body later: phase one only pushes the header to validate erpId/materialUuid; phase two enables items and compares field by field.
Applicable and Non-Applicable Scenarios
Applicable: ERP (approved/closed status) → MES BOM modification sync, with data volume within tens of thousands and relatively stable field mapping. Not Applicable: BOM creation (should use createBom strategy); MES → ERP reverse sync; multi-level BOM hierarchy (FParentRowId not mapped); scenarios requiring real-time (second-level) triggering (hourly scheduling has up to 1-hour latency).