Practical Tutorial: Syncing MES Semi-Finished Goods Receipts to Kingdee Cloud Skylink Other-Inbound Document (Virtual Warehouse)

What This Strategy Solves

In a real manufacturing site, MES owns shop-floor execution while Kingdee Cloud Skylink owns finance and inventory books. When a semi-finished product is completed on the line, the receipt is recorded in MES and must flow back into the ERP — but the ERP team prefers not to post real warehouse transactions. Instead, they use a "virtual warehouse" combined with an "Other Inbound" document as a lightweight, process-oriented bookkeeping mechanism.

This strategy pushes internal-production semi-finished receipts from MES into Kingdee as a standard Other Inbound document (bill type QTRKD01_SYS), writing the inventory org, picking org, and owner by rule, and closing the loop between shop floor and ERP books in a lightweight way.

Data Flow and Field Mapping

The data flow is straightforward: MES (source) → Qeasy Data Integration Platform (middleware) → Kingdee Cloud Skylink (target). The middleware does not own business logic — it only translates fields, manages code mappings, and routes exceptions.

Key field mapping (Source → Middleware → Target):

In practice, on Qeasy we maintain a single "centralized code-mapping table": MES material code → Kingdee virtual material code, and MES warehouse → virtual warehouse. Other strategies (e.g., finished-goods inbound, virtual material master) reference the same table — a "header / body phased" pattern common among Qeasy customers.

Configuring on Qeasy

Typical configuration points on the Qeasy Data Integration Platform:

1. Source platform: the MES Web system, using the common/search WebAPI (POST, paginated via pageNum / pageSize), with business_no as the document number field and id as the primary key. Enable idCheck and autoFillResponse so paginated rows merge automatically into the response.
2. Target platform: Kingdee Cloud Skylink, calling batchSave (POST, EXECUTE type, buildModel: true) to construct a full other-inbound model.
3. Request body: assemble the header (FBillTypeID, FStockOrgId, FPickOrgId, FOwnerTypeIdHead, FOwnerIdHead, FBillNo, etc.) and the line body (material, qty, warehouse, batch) separately. FBillNo references the source document number via {{business_no}}.
4. Code mapping: in Qeasy's data-processing / field-mapping node, route material and warehouse through the centralized mapping table so new mappings are added in one place.
5. Error handling: configure "header failure rolls back the whole document, line failure skips only that line". This is often forgotten on customer sites and leads to "half a document" landing in Kingdee — a pain to troubleshoot.

Implementation Steps

We recommend a three-phase rollout — the "incremental + full dual-track" pattern often used by Qeasy customers:

Phase 1 — Full initialization. With pageSize=100, pull all historical unreceived MES semi-finished receipts and trigger a one-shot full run on Qeasy to clear historical backlog. Always confirm the scope with business first; otherwise already-closed legacy docs will contaminate the period.

Phase 2 — Anchor the incremental cursor. Use the end of the full run as the incremental start. The MES call filters by lastModifiedTime > cursor. Persist the cursor in Qeasy's strategy state and advance it on each run.

Phase 3 — Steady scheduling. The source cron * 7-22 * * * runs every minute from 07:00 to 22:00, matching shop-floor cadence. Run for at least a week in production to observe success / failure / retry distribution, then tune frequency — if Kingdee's batchSave starts queuing, drop frequency from every minute to every 2–5 minutes.

Field-Tested Lessons

1. Header / body partial failure. In one project, the header succeeded while a single line's material was inactive in Kingdee; only the header landed, leaving an empty other-inbound. The safe pattern is buildModel: true inside one transactional node on Qeasy — any line failure rolls back the whole document for manual replay.
2. Virtual warehouse accidentally disabled. If the virtual warehouse is disabled across orgs, the strategy fails in bulk with a misleading "invalid warehouse" error. Add a pre-check on Qeasy for target warehouse + org status before posting.
3. Duplicate document numbers. MES allows the same business_no to be reused across multiple docs; Kingdee rejects duplicate FBillNo. The robust fix is concatenating business_no + sequence into a globally unique FBillNo.
4. Unowned mapping table. Once mapping is centralized, unmapped new data piles up in Qeasy's "unmapped" bucket if no one owns it. Assign a single owner and route changes through tickets.
5. Cron misses night shift. * 7-22 * * * covers 07:00–22:00; once night shift starts, receipts are missed. Confirm production windows with the shop floor before locking the schedule.

When It Fits and When It Doesn't

Fit: discrete manufacturing with MES on the shop floor and Kingdee as the inventory / finance ledger, where semi-finished goods need lightweight bookkeeping rather than a full production inbound. Not fit: scenarios where semi-finished goods participate in cost accounting or require real warehouse / bin management — those should use a standard production inbound document, not "Other inbound + virtual warehouse".