Other Outbound Order Sync Strategy in Practice: From WMS to Kingdee Cloud

What This Strategy Solves

In a real retail supply-chain integration, besides normal sales shipments, a business issues many non-sales outbound documents: internal consumption, transfers, scrapping, and stock-loss write-offs. On the source e-commerce WMS, these are recorded as "other outbound orders", while on the target ERP's inventory module they must be posted as formal stock documents so that finance can book them, inter-org settlements can be reconciled, and real-time inventory can be decremented. With mismatched codes, organizations, and state machines, manual re-entry is slow and error-prone. The goal of this strategy is to automatically push WMS other-outbound orders that have reached "pending settlement" or "completed" status into ERP inventory documents according to predefined rules, achieving one-time configuration and long-term stable operation. On the customer site, we use the Qeasy data integration platform to host this pipeline.

Data Flow and Field Mapping

The overall flow is Source (WMS other outbound order) → Middle layer (Qeasy) → Target (ERP inventory document). The source pulls incrementally by status 65 (pending settlement), 70 (completed); the middle layer performs code mapping, field cleansing, and batch merging; the target is written via batchSave.

Key field mapping (source → target):

How to Configure on Qeasy

Step 1: Source connection. In Qeasy, create a source platform connection, choose the corresponding WMS adapter, fill in authentication, select API wdt.wms.stockother.outquery.querywithdetail (POST), and set the incremental field to modified so changes can be pulled within a time window.

Step 2: Target connection. Choose ERP as the target platform, select batchSave as the API, and assemble the request body according to the ERP document header + line structure. Qeasy's write operation automatically handles batching and retries.

Step 3: Centralized code mapping. This is one of the most common patterns Qeasy customers adopt: put all cross-system codes (warehouse, organization, material, document type) into a single mapping table, and reference it directly from field mapping. When new warehouses or SKUs are added later, only the mapping table needs to be updated, not the strategy.

Step 4: Header and body phased delivery. Another common Qeasy pattern: phase one runs only the header to confirm the document can be created; phase two attaches the body (detail lines). This avoids opening every field at once and makes problem localization much easier.

Step 5: Response handling. The source's idCheck=true means the business document number is used as the idempotency key. The target's batchSave returns a success identifier, and Qeasy marks the document as "synced" accordingly to prevent duplicate writes.

Implementation Steps

We break the rollout of this strategy into a three-stage schedule:

1. Incremental start (cold start). Trigger one full pull, fetching the last 30 days in descending modified order to backfill history; record the start timestamp afterwards.
2. Steady-state scheduling. The source cron is set to */10 7-22 * * * (every 10 minutes during business hours); the target write is offset by 5 minutes as 7-59/10 7-22 * * * to avoid both sides contending for resources at the same instant.
3. Full reconciliation. Run a full-volume check once a week during the early Sunday off-peak, comparing documents on both sides using other_out_no as the primary key and re-pushing the differences. This is the "dual-track of incremental and full" pattern adopted by many Qeasy customers, used to catch any missing entries.

The recommended rollout path is: pass the test environment → run for a week in pre-production → canary in production with gradual ramp-up.

Lessons Learned

1. Wrong status filter, half of the documents were pushed. At first we only filtered 70 (completed), but users wanted to see inventory decrement immediately on the same day of consumption, and complained that "inventory didn't move". Switching to both 65 and 70 immediately improved the user experience.
2. Missing warehouse-org mapping, documents stuck at audit. Source warehouse codes are in WMS's own encoding system, while the target requires ERP organization codes. On first launch, a new warehouse wasn't in the mapping table, and the target returned "organization does not exist". The safe approach is to run a mapping table validation before going live.
3. Unit mismatch, doubled outbound quantity. WMS uses "piece", while ERP's primary unit is "box" (1 box = 12 pieces). Mapping must carry the unit conversion relationship; otherwise finance reconciliation numbers will not match. This is a classic trap.
4. Idempotency key conflict, rerun caused duplicates. The target's idCheck=true must align strictly with FBillNo; otherwise rerunning full sync will create duplicate documents. We recommend writing a dedicated unit test for idempotency in Qeasy strategies.
5. Wrong field used as business date. Early on, created was used as the ERP business date, resulting in document dates earlier than the actual outbound date and affecting financial closing. The typical mistake is picking the wrong time field; the safe approach is to use audit time (check_time) as the business date.

Applicable and Inapplicable Scenarios

Applicable: Non-sales outbound documents (internal consumption, transfers, scrapping, stock-loss write-offs) that need to land in the ERP inventory module for financial booking and real-time inventory decrement, where both source WMS and target ERP have standard APIs.

Inapplicable: Sales shipments (use the sales-outbound strategy); cross-org transfers requiring in-transit tracking (use the transfer-order strategy); scenarios where source or target lacks standard APIs and requires custom development.