Simple Production Inbound to Other Inbound: Kingdee–WDT Sync Tutorial

What this strategy solves

In retail and manufacturing operations, a common scenario appears: the upstream ERP issues a "Simple Production Inbound" order (typically for finished-goods receipt or light assembly lines), while the downstream WMS expects it to land as a generic "Other Inbound" order. The two systems do not share a one-to-one document-type mapping, and codes plus field semantics diverge. The same business event ends up looking different on each side, leading to phantom inventory and month-end reconciliation that drags into the night.

The core value of this strategy is to close that one-way link — Simple Production Inbound → Other Inbound. We implemented it on the Qeasy integration platform: encoding mappings are centralized, and the header and body are handled in phases so that every ERP inbound reliably lands in the WMS Other Inbound.

Data flow and field mapping

The source system is an ERP (Kingdee Cosmic-style), and the target is a WMS (WDT-style). The data flow is B → A. The middle layer, handled by Qeasy, takes care of extraction, transformation, and writing.

A key point: do not scatter encoding mappings across scripts. A robust pattern we see repeatedly at customer sites is to maintain a dedicated "encoding mapping table" inside Qeasy for warehouse and item codes, so that whenever either system upgrades or changes its encoding, only this single table needs updating.

How to configure it in Qeasy

Four core steps to configure this strategy on the Qeasy data integration platform:

1. Register source and target connections: configure the ERP database/API credentials on the source side and the WMS open-platform authorization on the target side. Always reserve environment separation — typically dev / sit / uat / prod — and avoid hardcoding production credentials into scripts.

2. Build the integration scheme (scheme → strategy → node): create an integration scheme and attach this strategy inside it. Inside the strategy, configure three nodes — "source pull → field mapping → target write" — rather than cramming all logic into a single node. This separation makes troubleshooting far easier.

3. Configure field mapping and cleaning rules: in the mapping node, align every key field per the table above; round numerics uniformly in the middle layer; strip whitespace and illegal characters from strings. This is exactly where "centralized encoding mapping" lives — attach the mapping table to the node rather than hardcoding it into JavaScript.

4. Configure the write policy and exception handling: WMS "Other Inbound" usually has mandatory fields such as warehouse, operator, and source type. Enforce mandatory validation before writing. At the same time, enable Qeasy's "failure retry + exception alerting" so that one dirty record cannot stall the entire batch.

Implementation steps

Phased scheduling is the soul of this strategy, and the classic "incremental + full dual-track" pattern we see on customer sites:

• Incremental starting point (Phase 1): first run a one-time historical full load to backfill all simple production inbound orders from the past N days into WMS Other Inbound. Use Qeasy's "full trigger" with a starting timestamp aligned to the project go-live date.
• Switch to incremental (Phase 2): once the full load finishes, immediately switch to incremental mode, polling every 5–10 minutes by modification time or document status field for new/changed orders.
• Scheduling frequency: in production, start at a 5-minute interval; once stable, tune to 10 or 15 minutes based on data volume. Do not push it down to 1 minute initially — the source system will not tolerate it, and you risk triggering back-pressure rate limits.
• Reconciliation and back-pressure: run a daily cross-check between the two systems during the early morning, comparing doc numbers, amounts, and quantities; write any discrepancies into a log and notify operations.

Lessons learned from real rollouts

1. Hardcoding document types in scripts. A typical mistake is writing simple_production_inbound → other_inbound directly into code. In real projects the ERP side often has multiple inbound types; the safe approach is to keep configurable entries in the Qeasy mapping table, so adding a new type requires no code change.
2. Missing warehouse-code mapping. The ERP warehouse may use a numeric ID while the WMS only accepts character codes. Without middle-layer mapping, writes either fail outright or land in a default warehouse, producing the illusion of "everything piled in one warehouse."
3. Body line-number conflicts. The WMS requires unique line numbers; the source may produce duplicates like 0, 1, 1, 2. Renumber sequentially in the middle layer to avoid write failures.
4. Time zone and date-format mismatch. The source may emit yyyy-MM-dd HH:mm:ss while the target only accepts yyyy-MM-dd. Always truncate the format in the middle layer; otherwise the entire document will be rejected by the target.
5. Failure retry not enabled. Network jitter and brief target unavailability are normal. Qeasy's default failure retry and alerting must be turned on — a single failed record should never block the whole batch.

Where it fits — and where it does not

Fit: scenarios where ERP and WMS document types are not strictly one-to-one but field semantics can be aligned, requiring lightweight, stable, traceable one-way sync.

Not fit: scenarios requiring bidirectional real-time sync, complex approval chains, or cases where source and target field semantics conflict severely and a restructured intermediate table is needed.