Transfer-Inbound Sync in Practice: Integrating Jushuitan Transfer Orders into Kingdee Cloud Xingchen Other-Inbound Documents

What This Strategy Solves

A retail enterprise frequently transfers stock between warehouses. Every time Jushuitan produces a transfer order, finance and the Kingdee Cloud Xingchen inventory ledger want to see a matching "Other-Inbound" document as soon as possible—otherwise the two ledgers drift apart and month-end stock-taking runs into the night. This strategy hands that seemingly simple but easy-to-mess-up task—converting Jushuitan transfer orders into Kingdee Cloud Xingchen Other-Inbound documents—to the Qeasy data integration platform.

Data Flow and Field Mapping

The flow is one-way: Jushuitan (transfer order) → Qeasy middle layer → Kingdee Cloud Xingchen (Other-Inbound document). The middle layer does not run business logic; it only handles code conversion, field alignment, and idempotency.

Key field mapping (only the fields most prone to issues are listed; the rest follow the Kingdee standard template):

Business Meaning	Jushuitan Source	Kingdee Target	Notes
Document number	Transfer order number	FBillNo	Add a business prefix in the middle layer to avoid clashing with purchase inbound numbers
Warehouse	Inbound warehouse	FStockId	Warehouse master-data mapping must be ready first, otherwise the document stalls during review
SKU	SKU	FMaterialId	Depends on the material-sync strategy running successfully first
Quantity	Transfer quantity	FQty	Jushuitan may contain un-shipped lines; filter them in the middle layer
Transfer date	io_date	FDate	Time zone and date format are common pitfalls—see below
Remark	remark	FBillHead.FNote	Carry the transfer reason for easier finance tracing

On Qeasy, we usually manage this mapping table as "centralized code mapping"—warehouse, customer, and material codes all come from the same master-data configuration, so a later change only needs to be made once instead of being scattered across many strategies.

How to Configure on Qeasy

On the Qeasy data integration platform's strategy configuration page, follow these key points and you will not go far wrong:

Source: select the Jushuitan "Transfer Order" interface, with the incremental fields io_date and io_id, sorted stably.
Target: select the Kingdee Cloud Xingchen V2 "Other-Inbound - Save" interface, which follows the standard header + body structure.
Field mapping: configure each item per the table above; use explicit converters for quantity and date—do not rely on platform defaults.
Filter conditions: on the source side only pick records where io_type belongs to the transfer-inbound scenario and status is approved, to reduce dirty data.
Idempotency key: use source document number + warehouse code + SKU as the unique key, so retries will not create duplicates.
Error handling: enable "row-level isolation" so that one row failing to find its SKU in Kingdee does not block the other rows from being submitted.

Implementation Steps

We recommend a three-phase rollout—do not start by running a full sync immediately.

Phase 1: Materials first. Confirm that the upstream "Jushuitan product information → Kingdee material" strategy has been running stably for at least one week, and that material codes can be matched 100% on both sides. Without this, every later document will fail.

Phase 2: Incremental start + scoped full sync.

Incremental start: pull transfer orders from the past 7 days as the first batch to validate fields and review flow.
Full sync trigger: run a historical full sync manually on Qeasy to backfill existing data.
Scheduling frequency: after business stabilizes, schedule the incremental pull every 15–30 minutes, and denser during daytime peaks.

Phase 3: Steady-state operation. Observe for one week to confirm both ledgers reconcile and the failure-retry mechanism works, then add monitoring, alerting, and on-call coverage.

Lessons from the Field

Running documents before warehouse codes are mapped. A typical mistake: Kingdee cannot resolve FStockId, so the entire document is rejected. The safe approach is to centralize the mapping of warehouse, customer, and material master data and treat them as the prerequisite for all document strategies.
Date format carries time zone. Jushuitan sometimes returns a timestamp string with a time zone, but Kingdee only accepts yyyy-MM-dd. Use an explicit to_date(..., 'yyyy-MM-dd') converter on Qeasy—do not cut corners.
Header passes but the body contains un-shipped lines. Jushuitan transfer orders allow partial shipment; un-shipped lines should not be synced into the Kingdee inbound document. The middle layer must filter these lines by status or qty, otherwise the Kingdee ledger will be inflated.
Idempotency key is too coarse. Using only the document number as the idempotency key makes it easy to duplicate inbound records when the source is re-pushed or manually supplemented. Include warehouse and SKU as well to achieve row-level idempotency.
A common Qeasy customer pattern: phase header and body separately. First get the header running, then progressively open up the body. This way, when something fails, you can locate it faster and one bad row will not block the whole document.

When to Use and When Not

Suitable for: multi-warehouse retail, frequent transfers, enterprises wanting real-time consistency between the two ledgers, and projects where material master-data sync is already running.

Not suitable for: scenarios where Jushuitan's transfer process is not yet standardized or the source is often manually edited; Kingdee has not yet enabled the Other-Inbound business; or complex two-way sync—this strategy is one-way only.