Jushuitan Transfer Orders to Kingdee Other Outbound: Inventory Transfer Sync Tutorial
What This Strategy Solves
In multi-warehouse retail operations, a typical scenario keeps coming up: stock moves between warehouses are recorded as transfer orders in the source e-commerce ERP, while the target financial ERP needs the outbound side posted as an Other Outbound document so cost and book inventory stay correct. When reconciliation is done manually in Excel, month-end almost never matches — transfer statuses are stale, quantities are missing, and warehouse mappings drift. The gap shows up directly as inventory variance between the books and the floor.
The goal of this strategy is to land the source transfer order into the target outbound document under a defined mapping rule, so the inventory transfer loop closes automatically between the two systems. On-site, we use the Qeasy Data Integration Platform to orchestrate the four moves — fetch, transform, write, and reconcile — in a single flow.
Data Flow and Field Mapping
The overall direction is "Source → Qeasy Middle Layer → Target". Headers carry document identity and business context, while lines carry items and quantities. The target's field set does not line up one-to-one with the source, so alignment has to happen in the middle layer.
Key field mapping:
| Dimension | Source (Transfer Order) | Middle Layer (Qeasy) | Target (Other Outbound) |
|---|---|---|---|
| Document No. | io_order_no | Preserve original | bill_no (mapped) |
| Source warehouse | src_warehouse_name | Warehouse code lookup | Issue warehouse (outbound direction) |
| Destination warehouse | dst_warehouse_name | Warehouse code lookup | Reference warehouse (record only, no stock effect) |
| Document date | io_date | Format yyyy-MM-dd | Business date |
| Item code | sku_id | Item code lookup | Material code |
| Quantity | qty | Numeric validation | Quantity |
| Remarks | remark | Pass-through | Remarks |
One critical engineering decision here: warehouse codes and item codes must be managed centrally. A common pattern we see on Qeasy is to lift the mapping tables out of an individual strategy and into the platform's unified mapping management, so adding a new warehouse or SKU means changing one place, not the flow itself.
Configuration on Qeasy
On the Qeasy Data Integration Platform, this strategy typically sits in one flow node inside an integration flow. Key configuration points:
- Source fetch: Use the source transfer order API and pull incrementally by "last modified time". An initial full sync is triggered manually to backfill.
- Middle-layer transform: Field mapping and value conversion run in the Qeasy transformer, including date formatting, numeric validation, and warehouse/item code lookup.
- Target write: Call the target Other Outbound save API. Headers and lines are submitted in two phases — write the header first to receive the returned document number, then submit lines together with that header number. This is a typical requirement of target-style financial systems.
- Exception handling: Configure retries and alerts in Qeasy. The two most common failure causes are missing mappings (warehouse or item not in the lookup table) and target-side validation errors (quantity or date format).
- Logging: Every transfer order's outcome (success / failure / reason) is written back to the platform log for on-site review.
Implementation Steps
We usually push this through in three phases to keep the rollout stable.
Phase 1: Prepare the incremental starting point. Run a one-off full sync of historical transfer orders to establish the initial document and stock baseline on the target side. In Qeasy this is started manually via a scheduler trigger.
Phase 2: Run full and incremental in parallel. As soon as the full sync finishes, switch to incremental mode with the starting timestamp set to the full sync's completion time. Another common pattern on Qeasy is to let full and incremental coexist for a while, verify both sides agree, then close the full entry.
Phase 3: Schedule frequency and steady-state operation. Transfer orders do not demand extreme real-time latency, so an incremental schedule every 5–10 minutes is usually enough. During low-traffic overnight windows, a small full catch-up can be added as a safety net. The schedule is set in Qeasy's crontab.
In the first week after go-live, we recommend pulling a daily reconciliation report that compares the source's daily transfer order count with the target's generated Other Outbound count, and alerting on any delta beyond the threshold.
Lessons Learned
1. Submitting header and lines together causes "document number is empty" errors on the target. Target-style Other Outbound documents usually require the header to land first, return a document number, and only then accept lines. The safe pattern in Qeasy is to write the header first, capture the returned bill_no, then submit the lines with bill_no attached.
2. Warehouse names differ between the two sides, and passing raw Chinese names fails the lookup. The source carries Chinese names while the target expects codes. A typical mistake is hardcoding names inside the transformer, which silently drops orders whenever the customer renames a warehouse. This is where it tends to blow up, so a lookup table is required, and the table itself must be maintainable from Qeasy's unified management view.
3. Source SKUs and target material codes do not line up across systems. The source "item" and the target "material" often differ in granularity — one material may map to several SKUs, or several SKUs may collapse into one material. Build the SKU-to-material mapping in Qeasy up front, instead of assembling it inside the flow at runtime.
4. Incremental start timestamp drifts, causing duplicates or gaps. At the exact moment of switching from full to incremental, a slight clock skew between source and platform can cause boundary orders to be missed or duplicated. On-site we usually roll the start point back a few minutes as a buffer, then tighten it once the line has been stable for a week.
5. Source transfer orders get voided, but the target has no corresponding handling. When a source transfer order moves from "approved" to "cancelled", the target needs a reversal or write-off, otherwise inventory drifts further out of balance over time. The safe pattern is to add a status branch in the Qeasy flow so voided orders trigger a reversal on the target side, instead of being silently ignored.
When This Applies, and When It Does Not
This strategy fits multi-warehouse retail or distribution scenarios where both the source e-commerce ERP and the target financial ERP need to record transfers, the warehouse structure on both sides is reasonably stable, and item mappings can be clarified in advance.
It does not apply when the warehouse naming schemes on the two sides diverge widely and keep changing, when item granularity is fundamentally incompatible and cannot be mapped, when transfer volume is so low that manual handling is more cost-effective, or when the source lacks a reliable last-modified timestamp and incremental sync is therefore impossible.