Wangdiantong Transfer Orders to Kingdee Cosmic Star Direct Transfer Orders: Inventory Transfer Sync Tutorial
What This Strategy Solves
In multi-warehouse retail operations, transfer orders are among the highest-frequency inventory movement documents. Inter-store and store-to-central-warehouse transfers are typically generated first in Wangdiantong as transfer orders (non-back-stock), while financial accounting and real-time inventory sit in Kingdee Cosmic Star. Without integration, the financial inventory view lags behind reality by half a day to a full day, and stock discrepancies accumulate. The core goal of this strategy is to push Wangdiantong transfer orders as-is into Kingdee Cosmic Star to generate direct transfer orders, achieving minute-level ledger-to-physical synchronization.
Data Flow and Field Mapping
The data flow is unidirectional A→B: the source system is Wangdiantong, and the target system is Kingdee Cosmic Star. The middleware does not store business data; it only performs format conversion and field enrichment.
Key field mapping (typical, not exhaustive):
| Business Meaning | Wangdiantong Source Field | Kingdee Cosmic Star Target Field | Mapping Notes |
|---|---|---|---|
| Document Number | order_no | FBillNo | Pass-through, add prefix if needed to avoid duplicates |
| Transfer Direction | type | FTransferDirection | Code mapping, centrally maintained |
| Source Warehouse | src_warehouse_id | FOutStockId | Resolved via warehouse mapping table |
| Destination Warehouse | dst_warehouse_id | FInStockId | Resolved via warehouse mapping table |
| Item Code | spec_code | FItemNumber | Consistent with item sync strategy |
| Quantity | num | FQty | Unit conversion required |
| Business Date | created | FDate | Uses document creation time |
One point to emphasize: master data such as item codes, warehouse codes, and units must rely on prerequisite strategies like "item sync" and "warehouse sync" to be in place first. Otherwise, transfer orders will be rejected by Cosmic Star due to missing master data.
How to Configure in Qeasy
In actual projects, we use the Qeasy Data Integration Platform to handle this link. The configuration has three parts:
- Source Collector: Select the Wangdiantong adapter and subscribe to the "Transfer Order (type≠back-stock)" event. The filter condition must be set; otherwise, back-stock orders will mix in and reverse inventory.
- Middleware Transformer: Use Qeasy's field mapping canvas to split header and body processing. The header handles document-level fields (number, date, direction), while the body handles line items (item, quantity, unit, batch). Separating header and body into stages is a common pattern among Qeasy customers, helping avoid the difficulty of troubleshooting failures when large batches of documents are submitted at once.
- Target Writer: Call Kingdee Cosmic Star's "Direct Transfer Order" save interface. It is recommended to keep the "save-and-audit" switch off initially and turn it on after data stabilizes, to allow easier rollback.
Centralized encoding mapping is another common practice: the three mapping tables for warehouses, items, and units are maintained in Qeasy's "Data Dictionary" and referenced by all downstream strategies, preventing the situation where a change in one place causes desynchronization elsewhere.
Implementation Steps
Proceed in three phases:
- Incremental Starting Point: Run incremental sync at the beginning of go-live, continuing from the historical breakpoint. Use Wangdiantong's
updated_atas the incremental field, fetching only changed documents each time. The purpose is to quickly verify the link works, not to pursue historical completeness. - Full Volume Trigger: After incremental sync has run stably for 3-5 days, manually trigger a one-time full volume catch-up to fill in any historical documents missed before go-live. Full volume must run as an asynchronous task to avoid blocking the real-time link.
- Scheduling Frequency: Regular scheduling is recommended as polling every 5-10 minutes. Transfer orders are time-sensitive, but too-frequent polling puts pressure on the source system. If the source supports webhook push, switching to event-driven is recommended, with Qeasy handling the data immediately upon receiving the callback.
The safe approach is to run incremental and full volume in parallel: incremental handles daily operations, while full volume serves as a fallback compensation.
Lessons Learned
Several real project pitfalls:
- Back-stock mixing in: Wangdiantong transfer orders include a "back-stock" type, which is logically a reverse reversal. If not filtered out at the source, Cosmic Star will show repeated inventory increase and decrease, causing stock discrepancies.
- Item code inconsistency: If the item sync strategy and transfer strategy each maintain their own encoding mappings, the item records on both sides will drift apart within three months. Centralized management is essential.
- Source and destination warehouses swapped: Transfer direction plus source/destination warehouses are two independent fields that look correct individually but are only validated in combination. There have been incidents where the direction was correct but the warehouses were swapped.
- Unit conversion overlooked: Wangdiantong may use "pieces" while Cosmic Star requires "base units". Submitting without conversion causes inflated quantities.
- No idempotency guarantee: During network jitter retries, the same transfer order may be created twice in Cosmic Star. The typical mistake is relying on the source side for deduplication; the safe approach is to use "source document number + business date" as the idempotency key in the Qeasy middleware layer.
Applicable and Non-Applicable Scenarios
Applicable: Multi-warehouse operations, frequent inter-store transfers, enterprises where finance requires real-time inventory alignment with business systems. Not applicable: Single-warehouse operations, or scenarios with very low transfer volumes where T+1 reconciliation is acceptable.