Purchase Return Material to Other Outbound: Inventory Sync from Kingdee Cosmic to Wangdiantong
What This Strategy Solves
In a reverse supply chain flow, a retail client we worked with hit a common issue: purchase return material documents created in Kingdee Cosmic had to flow into Wangdiantong as other outbound orders, otherwise inventory on both sides would silently drift apart. It looks like a simple directional sync, but in return-material scenarios, any weak design around item codes, organizations, or batch rules will cause stock mismatches within three months.
On the customer site we used Qeasy (the Qingsong data integration platform) to own this link. The value is turning "Kingdee return → Wangdiantong outbound" into an observable, replayable, and traceable strategy, rather than hard-coded scripts.
Data Flow and Field Mapping
The flow is Kingdee Cosmic (source) → Qeasy middle layer → Wangdiantong (target), under the inventory sync business module and business document subdomain.
Key field mapping (source → target):
| Dimension | Kingdee Cosmic (Purchase Return) | Wangdiantong (Other Outbound) | Note |
|---|---|---|---|
| Header | Doc No FBILLNO | outer_no | 1:1, used as idempotency key |
| Doc type | Business type (return) | other_out | Fixed mapping |
| Organization | Inventory org | Warehouse code | Via org mapping table |
| Line – item | Item code + name | Goods code + name | Centralized in Qeasy |
| Line – qty | Actual return qty | Quantity | Pass-through |
| Line – batch | Batch no | Batch | Required for returns |
| Line – warehouse | Return warehouse | Target warehouse | Routing rule when N:1 |
How to Configure in Qeasy
- Source connector: Kingdee Cosmic, pulling purchase returns by "modified time + doc status".
- Target connector: Wangdiantong's "create other outbound order" API.
- Field mapping: Configure header and lines separately, so failures are easier to localize.
- Centralized encoding mapping: Maintain item and organization mappings in a single mapping table—this is one of the most common patterns among Qeasy customers.
- Write policy: Retry with backoff plus a dead-letter queue, so one bad record never blocks the batch.
- Idempotency key: Use the source document number as the outer_no; duplicates are auto-deduped on the target side.
Implementation Steps
We split the rollout into three phases to avoid big-bang issues.
Phase 1: Incremental start point Freeze both sides' stock at the cutover moment. From 00:00 on cutover day, the source side pulls by "modified time". The target side only writes new documents—no historical replay.
Phase 2: Full backfill trigger Run a one-off full sync for return documents from the 7 days before cutover, to cover the window. Stop the full job once done; afterwards, only the incremental runs—this is the typical incremental + full dual-track pattern Qeasy customers use.
Phase 3: Scheduling frequency Returns are low-frequency, so a 10–15 minute polling cycle is enough. During month-end closing, temporarily tighten it to 5 minutes, then restore.
Pitfalls We Have Seen
- Encoding mapping scattered in scripts: Early projects spread item-code mapping across many conversion scripts, and three months later the two sides no longer reconciled. The safe approach is to centralize mappings in Qeasy's mapping table, with clear ownership.
- Batch field dropped: Return documents almost always carry batch info. Missing it causes the target's batch-level stock to mismatch, and physical inventory checks will surface it.
- Idempotency key on doc number only: If the source system allows duplicate doc numbers, you must combine org + date; otherwise the same doc is treated as two.
- No alert on writeback failure: When the target system writes back status, configure exception alerts in Qeasy—otherwise the issue only surfaces during month-end reconciliation.
- Full and incremental running together: A classic mistake at go-live is forgetting to stop the full job, which then races the incremental job and produces duplicates. Lock the full window and only release the incremental after the full job is confirmed clean.
Where It Applies and Where It Does Not
Applies: Low-frequency internal reverse stock movements such as returns, issues, and transfers; mid-to-large enterprises that need dual-system reconciliation. Does not apply: High-frequency sales outbounds, cross-org real-time stock transfers (these need their own dedicated outbound sync strategy rather than reusing the return link), and scenarios that only need reporting archive without writing back to inventory.