Other Inbound Sync in Practice: A Single-Strategy Tutorial from WMS to Kingdee

What This Strategy Solves

In retail, "other inbound" orders (adjustments, initialization, inventory loss write-offs, and other non-purchase, non-production entries) live in a gray zone. The e-commerce OMS issues outbound orders while the ERP needs a matching inbound entry. If both systems are entered manually, three months later the inventory ledger stops reconciling and the year-end stocktake can show variances in the millions.

We use the Qeasy Data Integration Platform to take Wangdian Tong's other-inbound orders and push them automatically into Kingdee Cloud Xingchen V2, where the target-side document is audited immediately to remove a second round of manual entry. Two common patterns we see at customer sites: first, keep all material and warehouse code mappings centralized in Qeasy; second, go live with the header first and add line items in a later phase.

Data Flow and Field Mapping

Data flow: Wangdian Tong Qiemen → Qeasy middleware → Kingdee Cloud Xingchen V2. The source API is wdt.stockin.order.query and the target API is /jdy/v2/scm/inv_other_in.

Key field mapping:

Line mapping essentials: goods_no → material_number, num → qty, price → price, total_amount → amount. Batch and expiry are mapped only when batch management is enabled.

How to Configure It in Qeasy

In the Qeasy Data Integration Platform, a typical configuration has four parts:

1. Source connector: choose Wangdian Tong Qiemen, API wdt.stockin.order.query, Method POST, Type QUERY. Set start_time to {{LAST_SYNC_TIME|datetime}}, end_time to {{CURRENT_TIME|datetime}}, hard-code order_type to "6" and status to "80".
2. Target connector: choose Kingdee Cloud Xingchen V2, API /jdy/v2/scm/inv_other_in, Method POST, Type WebAPI/EXECUTE.
3. Field mapping: at the header, bill_date takes {{stockin_time}}, bill_no takes {{order_no}}, while trans_type_id and operation_key are constants. For lines, use a whole-array reference: set material_entity.value to "details_list". The platform auto-maps by field name into material_number, qty, price, and so on.
4. Scheduling: set the source Crontab to 3 2 * * * (02:03 pull) and the target to 23 2 * * * (02:23 write), leaving a 20-minute buffer between them.

Implementation Steps

We recommend a three-phase rollout to keep things safe:

Phase 1: Incremental cold start Before the first run, manually set LAST_SYNC_TIME in Qeasy to seven days earlier than today so only the last week is pulled. Avoid dumping years of history on day one.

Phase 2: Full-volume trigger (optional) If the business requires historical backfill, temporarily hard-code start_time to the historical start date, run once, then immediately revert it to {{LAST_SYNC_TIME}} to go back to incremental. Many teams forget this step on site. A safer approach is to create a separate "full backfill strategy" in Qeasy and archive it after it completes.

Phase 3: Steady-state scheduling The source pulls at 02:03 every day and the target writes at 02:23. Qeasy maintains LAST_SYNC_TIME automatically. Watch the count returned by the source versus the count successfully written to the target on the monitoring dashboard and alert if the delta exceeds the threshold.

Pitfalls and Lessons Learned

1. Mismatched material codes on both sides: this strategy does not use _findCollection cross-lookup; goods_no is passed straight into material_number. At one customer site, the two systems had codes differing by a prefix, and Kingdee threw "material does not exist". A safer approach is to build a separate master-data sync strategy in Qeasy to centralize the code mapping.
2. Line-item field names not aligned: setting material_entity.value="details_list" only gives you the array reference. If the source calls the field spec_no and the target expects material_number, you must pair them explicitly in the mapping table—the platform does not do semantic inference.
3. Duplicate inbound documents: because operation_key="audit" creates-and-audits in one shot, a network hiccup that makes Qeasy think the call failed can trigger a resend and produce duplicate documents. A classic mistake is forgetting to use bill_no (source order_no) as the idempotency key—Qeasy defaults to idCheck deduplication, so make sure the unique keys on both sides are aligned.
4. Time window too narrow, missing entries: for cross-day schedules, if the source end_time uses the current exact hour, any document modified right at the boundary will be missed. A safer approach is to extend end_time two minutes forward, or let Qeasy open a tolerance window.
5. Wrong trans_type_id: Kingdee's "other inbound" is a fixed value 12, which is different from purchase inbound or inventory surplus. If misconfigured, the document saves but lands in the wrong business type, and downstream reports fall apart. This is easy to get wrong—verify the value after configuration.

When This Strategy Applies and When It Does Not

Applies: e-commerce retail scenarios where the WMS/OMS generates large volumes of non-purchase inbound orders (adjustments, initialization, inventory loss) that need to be auto-posted to the financial ERP, and where material codes are already unified or governed by a master-data strategy.

Does not apply: projects where the two systems have completely different material coding schemes and no master-data sync is in place, or scenarios that require manual approval flows and do not want create-and-audit semantics (this strategy hard-codes audit and does not support a two-step submit).