Transfer-In Sync in Practice: A Step-by-Step Implementation from Wangdiantong to Kingdee Cosmic
What This Strategy Solves
A retail enterprise uses Wangdiantong for store and transfer operations while Kingdee Cosmic handles finance and inventory accounting. The two systems each maintain their own transfer-in records, and the numbers rarely reconcile at month-end. This article focuses on the most critical piece: syncing transfer-in records from Wangdiantong into Kingdee Cosmic as a stepped transfer-in document.
The strategy looks like a simple "push one document over," but it hides three issues. First, the transfer document must be split into header and lines written in sequence; one out-of-order line fails the whole batch. Second, master data such as warehouses, customers, and items must already be in place, otherwise the save fails immediately. Third, the write-back status needs a closed loop, or warehouse staff cannot tell whether the document was actually pushed.
Data Flow and Field Mapping
The overall flow is: Wangdiantong (source) → Qeasy data integration platform (middle layer, responsible for cleansing, mapping, and scheduling) → Kingdee Cosmic (target). The middle layer is not a simple forwarder; it acts as a translator handling code mapping, unit conversion, and null-value fallback.
Key field mapping example (desensitized):
| Business meaning | Wangdiantong (source) | Kingdee Cosmic (target) | Notes |
|---|---|---|---|
| Document number | transfer_no | FBillNo | Source is unique, passed through |
| Out-warehouse | out_warehouse_code | FOutStockOrgId.FNumber | Use a centralized code mapping table |
| In-warehouse | in_warehouse_code | FInStockOrgId.FNumber | Source and target codes typically differ |
| Item code | sku_code | FMaterialId.FNumber | Depends on item master sync strategy |
| Quantity | qty | FQty | Watch for unit conversion between base and stock units |
| Business date | transfer_date | FDate | Unify time zones to avoid cross-day issues |
| Remarks | remark | FNote | Target field has a length limit |
How to Configure It in Qeasy
In the Qeasy platform, this strategy is usually built as a three-stage flow: data source → integration flow → target write.
- Data source: Configure the Wangdiantong adapter, pick the transfer-in document type, and set the filter to "approved and not yet pushed." This filter is the foundation for incremental logic.
- Integration flow orchestration: This is the core. The common pattern is to split the header and lines into two stages. Stage one writes the header and captures the internal document ID returned by Kingdee. Stage two then writes the lines in batch. Qeasy's integration flow can use a "branch" node to handle this directly, which is clearer than hard-coded scripts.
- Field mapping and scripts: A pattern we frequently see on customer sites is centralized code mapping—extracting warehouse, customer, supplier, and item code correspondences into a single mapping table that all strategies share. Updating one place updates everywhere, instead of scattered across a dozen flows.
- Target write: On the Kingdee Cosmic side, use the standard stepped transfer-in save interface. Call the header save first, then the line batch save, then write back the document status.
- Exception handling: Categorize business errors returned by Kingdee (such as "warehouse not approved," "item not enabled," "insufficient inventory") and write them into a failure table for manual repush, rather than blocking the whole batch.
Implementation Steps
The rollout is best done in four phases, "skeleton first, then flesh":
- Phase 1: Master data first. Stabilize the sync of warehouses, customers, items, and units. Confirm the mapping is correct before touching transfer documents. This is a dependency—do not skip it.
- Phase 2: Full trigger, reconcile history. Manually trigger a full sync in Qeasy to cover the last three months of historical transfers and verify each one on the target side. The focus of this phase is to surface mapping issues; do not rush into scheduling.
- Phase 3: Enable incremental start point. Use the timestamp of the last successful sync as the incremental start point and enable scheduled tasks. For transfer-in scenarios with many stores, a 15-minute interval is usually safe and avoids backlog.
- Phase 4: Closed loop and monitoring. Write back the push status to the Wangdiantong side (a lightweight status flag is enough) and watch the failure rate on the Qeasy monitoring dashboard.
Lessons Learned
- Pushing documents before master data is stable. The classic mistake is skipping the prerequisite and pulling transfer documents directly, only to have Kingdee return "item does not exist" and fail the entire batch. The safe approach is to make the master data sync strategy's completion status a precondition for this strategy.
- Header and lines written together. Kingdee's stepped interface requires the header to be written first to obtain the internal ID, then the lines. Out-of-order writes often fail with "no details" on certain versions.
- Code mapping scattered across scripts. The most common anti-pattern we see on customer sites is putting warehouse code mapping directly into each strategy's script, so a single change requires editing a dozen places. Centralized mapping means a new store requires only one row to maintain.
- Unit conversion overlooked. The base unit might be "piece" while the stock unit is "box," and 1 box = 12 pieces. If the source sends pieces without conversion, the inventory quantity is off by 12 times. These issues only surface at month-end, and the troubleshooting cost is high.
- Wrong incremental start point. Using system time as the start point can miss documents when scheduling is delayed or when failed batches need repushing. The safe approach is to use the source's "last modified time" field as the incremental cursor.
Applicable and Non-Applicable Scenarios
Applicable: Enterprises with multi-store, multi-warehouse transfer operations whose financial accounting depends on Kingdee Cosmic, especially those with high transfer document volume that requires consistency across systems. Not applicable: Single-warehouse setups, or scenarios with very low transfer volume (under a hundred per month), where manual entry is cheaper; also not applicable to complex cross-legal-entity transfers, which typically require a three-stage flow of transfer order + transfer-out + transfer-in rather than a single stepped transfer-in document.