Practical Tutorial: Sync Transfer-Out Orders from Jushuitan to Kingdee Cloud via Staged Transfer-Out Document

What This Strategy Solves

A retail client needs frequent inter-warehouse transfers: goods move from warehouse A to B, and inventory counts must match on both sides. When a transfer order is created in Jushuitan, the back-end ERP—Kingdee Cloud—must see this outbound movement; otherwise finance and cost accounting lag behind. The approach we built on the Qeasy data integration platform is: once a Jushuitan transfer order is generated, an incremental trigger syncs it into Kingdee Cloud as a "staged transfer-out document." This way the transfer chain is booked line-by-line on the ERP side, keeping inventory accounts and physical stock aligned.

Data Flow and Field Mapping

The overall flow is Jushuitan (Transfer Order) → Qeasy Middle Layer → Kingdee Cloud (Staged Transfer-Out Document). The middle layer handles code mapping, field transformation, and status filtering, so dirty data never reaches the ERP directly.

Key field mapping (source → target):

Note: Jushuitan warehouse IDs are auto-increment numbers, while Kingdee uses custom-defined warehouse codes. They cannot be aligned directly. Both must go through a centrally managed code-mapping table—a common pattern among Qeasy customers, where every code-mapping table lives in a single data model for traceable maintenance.

How to Configure on Qeasy

On the Qeasy data integration platform, this strategy exists as a standalone integration flow. Configuration essentials:

1. Source connection: Select the Jushuitan adapter and configure shop/account authorization (credentials must be stored in a secret manager by the enterprise IT team; never written in plaintext into engineering files).
2. Trigger mode: Transfer orders support incremental pull by io_id, configured with a last_modify_time cursor polled every 5 minutes; on the go-live day, run a one-time full sync to replay historical orders.
3. Middle-layer transformation: Use Qeasy's field-mapping canvas to handle warehouse/product code mapping, date formats, and batch number enablement. A common pattern here is "header and line items in stages"—process the document header first, then iterate through line items.
4. Target write: Select the Kingdee Cloud adapter and call the staged transfer-out document's save/audit interfaces. Save as draft first; only push the audit action after validation passes.
5. Exception handling: Configure retry (3 attempts, exponential backoff), write to error queue, and alert to the enterprise IM when thresholds are exceeded.
6. Observability: Enable run logs and field-level diff tracing on Qeasy for later audit.

Implementation Steps

For supply-chain synchronization, scheduling is generally divided into three phases:

• Incremental starting point: On go-live, record the last_modify_time starting timestamp (e.g., 2024-01-01 00:00:00); the cursor advances automatically afterward.
• Full sync trigger: Run a one-time historical full sync on the night of go-live, replaying the past N days of transfer orders by creation time. Add a mutex between full sync and incremental sync to prevent the same order from being pushed twice.
• Scheduling frequency: Normally every 5–10 minutes incrementally; during promotions or stock-taking days, shorten to 2 minutes and temporarily scale up target-side write concurrency.

The recommended go-live sequence is: first, sync material/product master data (sequence A) → then vendor/warehouse archives (sequence B) → finally turn on this transfer-order sync. Do not reverse the dependencies, or the codes won't align when documents arrive.

Lessons from the Field

1. Hard-coding warehouse codes: Early on, an engineer wrote from_warehouse_id=1 directly as FStockId='001warehouse'. Three months later the client added a new warehouse and the integration broke entirely. The safe approach is to route every archive-style code through a mapping table, maintained centrally on Qeasy as a data model.
2. Missing batch numbers: Jushuitan had batch management enabled, but the target-side line field FBatchNo wasn't populated, so the ERP rejected the document with a mandatory-field error. Solution: in the middle layer, check whether batch management is enabled; if not, fill a default placeholder.
3. Status-machine mismatch: "Shipped" in Jushuitan and "audited" in Kingdee are not the same semantics. Draft transfer orders were pushed too, causing negative inventory on the ERP. The safe approach is to add a filter on the source side and only sync orders where status='approved'.
4. Full and incremental sync clashes: Without a mutex, historical full sync and the cursor ran simultaneously, pushing the same order twice and causing Kingdee document-number conflicts. A typical mistake is to rehearse the full sync on production data—always rehearse mutex logic in a test environment first.
5. Silent credential expiry: Jushuitan's API token expires every three months, and the failure was silent. The safe approach is to configure credential expiry reminders on Qeasy, alerting enterprise IT at least 7 days in advance.

When to Use and When Not to Use

Suitable for: multi-warehouse e-commerce and retail enterprises where Jushuitan handles front-end fulfillment and Kingdee serves as the back-end ERP with finance—where inventory accounts must align with physical stock and every order must be traceable. Not suitable for: single-warehouse enterprises, businesses without batch or serial-number management, or scenarios where Kingdee is the primary operating system and Jushuitan is merely a supplement. In the latter case, the staged transfer-out document logic becomes overkill.