Practical Configuration for Syncing Sales Outbound Orders from Kingdee Cloud to WMS

What This Strategy Solves

Sales outbound orders need to flow from Kingdee Cloud (post-audit) back to WMS as offline outbound orders for shipping confirmation and inventory deduction. Common pain points include mismatched semantics between header and line fields, an undefined incremental start point causing missed or duplicate transmissions, and scheduling collisions between the two systems that trigger concurrency conflicts. We use the Qeasy data integration platform to host this and turn it into a reusable strategy template.

Data Flow and Field Mapping

Data flow: Kingdee Cloud (source) → Qeasy middleware layer → SWMS (target).

The source side uses the executeBillQuery API, queried by FBillTypeID_FNumber + FBillNo; the target side writes through /outOrders/v4_1. Key fields are mapped as follows:

The warehouse code → name mapping is a classic encoding mapping case. A common Qeasy customer pattern is to centralize this in a dictionary table rather than hard-coding case branches inside the strategy.

Configuring on Qeasy

1. Source connector: Select the Kingdee Cloud adapter and configure the application URL and authentication.
2. Target connector: Select the SWMS adapter and configure the API prefix /outOrders/v4_1.
3. Request assembly: Build the target structure; warehouse name uses a case function; owner code uses a configured constant.
4. Response parsing: Enable autoFillResponse so the platform fills query/write results back, which is helpful for troubleshooting.
5. Idempotency: Enable idCheck, using document number + line ID as the unique key to avoid duplicate pushes.

Implementation Steps

• Stage 1: Full trigger. On first go-live, run a full sync to backfill historical outbound orders, then switch to incremental.
• Stage 2: Incremental start point. Use source FDate + document status as the incremental cursor. A safe approach is to look back a window so edge-case documents are not missed.
• Stage 3: Scheduling frequency. Source runs at 0-59/5 * * * * (every 5 minutes on the hour); target runs at 3-59/5 * * * * (staggered by 3 minutes) to avoid backpressure from simultaneous triggers.
• Stage 4: Header and line staged processing. Stabilize the header first, then run the line separately. During early go-live, validate the two in parallel, and merge into one schedule chain once confirmed.

Pitfall Review

1. Encoding mapping scattered in case statements. Hard-coding warehouse names in case when inside the request template means new warehouses require strategy changes. The safer approach is to extract them into a centralized dictionary table.
2. Wrong field for the incremental start point. We once used FDate without considering cross-day documents, causing orders around midnight to be missed. A dual condition of FDate + document status is recommended.
3. Scheduling collisions on both sides. Both source and target running at 0-59/5 caused the middleware queue to saturate at trigger time. A 3-minute stagger noticeably improved stability.
4. Missing idempotency key design. Without idCheck, a rerun produces duplicate outbound orders. Always use document number + line ID as the idempotency key.
5. Header and line bundled together. When line fields change frequently, header reruns add unnecessary cost. Staged processing reduces rollback cost significantly.

Applicable and Non-applicable Scenarios

Applicable: scenarios where sales outbound results need to flow back to WMS in near real time for shipping confirmation and inventory deduction verification. Not applicable: scenarios where WMS actively creates outbound orders and writes back to Kingdee Cloud—that is a different push-style sync strategy.