Practical Sync Solution: From WDT Purchase Inbound Orders to Kingdee Other Inbound Orders (Production Inbound)

What This Strategy Solves

A retail enterprise uses WDT for front-end purchase inbound management, while Kingdee Cloud Cosmic handles back-end finance and cost accounting. The purchase inbound orders contain production returns, transfer inbound, and other businesses — mapping them directly causes errors. So the strategy separately syncs the "production inbound" type of WDT purchase inbound orders into Kingdee's other inbound orders. This article explains how to implement this single strategy on Qeasy.

Data Flow and Field Mapping

The data flow is unidirectional: WDT (source) → Qeasy (middleware) → Kingdee Cloud Cosmic (target). Qeasy acts as the data hub, responsible for extraction, filtering, transformation, and push.

Key field mapping:

• Document number: WDT order number → Kingdee document number (kept identical for traceability)
• Business type: WDT "Purchase Inbound - Production Inbound" → Kingdee document type "Other Inbound"
• Warehouse: WDT warehouse code → Kingdee warehouse code (mapping table required)
• Vendor: WDT vendor code → Kingdee vendor code
• Item code: WDT SKU → Kingdee material code (centrally maintained)
• Quantity, unit price, amount: direct mapping
• Remarks: extension fields passed through

Code mapping is the core. A common approach among Qeasy clients is centralized management — maintain one master data table in Qeasy, shared across all strategies, so one change applies everywhere.

How to Configure on Qeasy

1. Register two system connections: Select the WDT adapter for the source and fill in API credentials; select the Kingdee Cloud Cosmic adapter for the target and do the same. Keep connection info secure.
2. Create a new sync strategy: Name it following the convention "WDT-Purchase Inbound (Production Inbound)-->Kingdee-Other Inbound". Set strategy type to SYNC, flow direction A_TO_B.
3. Configure source extraction: Select the WDT purchase inbound API, set the filter — business type = production inbound, to avoid mixing in regular purchase inbound orders. This is the key filter step.
4. Configure field mapping: Map field by field according to the table above, attach code-type fields to the mapping table.
5. Configure target writing: Select the Kingdee other inbound API, set parameters like organization and review status.
6. Configure scheduling: See the next section.
7. Enable logging and alerting: Qeasy provides end-to-end logging for quick troubleshooting.

Implementation Steps

Three phases of scheduling:

• Incremental starting point: Before first go-live, perform a one-time full historical data backfill. Qeasy supports manual full-sync triggers to push all historical production inbound orders at once.
• Switch to incremental after first sync: After full sync, record the timestamp of the last document; subsequent strategies pull incrementally based on "modified time > last sync time".
• Scheduling frequency: In private deployment, poll every 5–10 minutes. Too frequent overloads the source system, too sparse causes delay. A common client practice is dual-track of incremental and full sync — daily incremental, plus a weekly or monthly full-sync validation to catch missed records.

Lessons from Pitfalls

1. Business type not filtered properly: At first go-live, the filter "business type = production inbound" was forgotten, so regular purchase inbound orders got synced too, creating massive duplicates in Kingdee. Safe approach: apply filters at the source extraction stage — don't rely on middleware cleanup.

2. Distributed code mapping maintenance: Early on, warehouse and material code mapping tables were embedded in individual strategies. When adding new strategies, one change was made while another was forgotten, causing data mismatch. Safe approach: centralized mapping management — all strategies reference the same mapping table.

3. Kingdee organization and document type mismatch: In Kingdee's multi-organization environment, different organizations have different inbound document type numbers. Common pitfall: only one organization was configured in the strategy, so orders from other organizations couldn't be pushed. Safe approach: parameterize organization and document type as fields, dynamically matching based on source orders within the strategy.

4. Review status triggering chain reactions: When WDT inbound order status changes, if Qeasy doesn't perform status checks, cancelled orders get synced too. Safe approach: add status filter at source extraction — only sync reviewed, non-voided orders.

5. Time zone and date format: WDT and Kingdee use different date formats, and cross-time-zone issues often arise. Safe approach: do unified formatting at the Qeasy middleware layer to prevent dirty data writes.

Applicable and Non-applicable Scenarios

Applicable: In WDT and Kingdee Cloud Cosmic supply chain integration scenarios where production inbound business in purchase inbound orders needs to be separated into Kingdee other inbound orders; multi-organization, cross-code-system, private deployment environments requiring centralized master data maintenance.

Not applicable: Scenarios where WDT front-end no longer has production inbound business, or where Kingdee can directly use purchase inbound orders without splitting document types; and scenarios requiring real-time second-level sync with extremely low latency (this strategy is near real-time, not real-time).