Practical Guide: Syncing Wangdiantong Other Inbound Orders to Kingdee Xingchen Sales Returns (Linked to Return Requests)

What This Strategy Solves

In B2B retail scenarios, non-sale inbound events (such as transfer returns, rejected deliveries, and repair returns) are recorded in Wangdiantong as Other Inbound Orders, while the finance side needs them to appear in Kingdee Xingchen as Sales Returns linked to prior Sales Return Request Orders so that receivables can be reversed and inventory can be reduced. In one real engagement, the pain point on the customer site was clear: the request order was entered in Xingchen first, but the actual inbound happened in Wangdiantong, so the two sides never reconciled. This strategy uses Qeasy (Qingyi Cloud Data Integration Platform) to bridge the chain: Other Inbound Order → Sales Return → linked to the return request order.

Data Flow and Field Mapping

The flow is unidirectional: Wangdiantong (Other Inbound Order) → Qeasy Integration Platform (middle layer) → Kingdee Xingchen (Sales Return, linked to Sales Return Request). The middle layer only cleans, maps, and links records — it does not store business documents.

Key field mapping (only fields that matter for reconciliation and workflow):

The most critical step is backfilling the link field: src_apply_no is not a native field in Wangdiantong, so the Qeasy middle layer must look it up in Xingchen by "customer + SKU + original sales order no.". This lookup directly determines whether the return document can be tied to a request order.

How to Configure in Qeasy

Here is how we typically build this strategy on a customer site:

1. Data source registration: Use Wangdiantong's open API to pull Other Inbound Orders (incremental by modified_time > cursor), and Kingdee Xingchen's open API to write Sales Returns. Both accounts are maintained centrally in Qeasy's connector module.
2. Centralized code mapping: Customers, warehouses, and items are kept in a single mapping table (Qeasy's "Data Table" component). Inbound source codes are looked up against the table first; unmatched records go to an exception queue instead of being written dirty into Xingchen. Centralized mapping in the middle layer — rather than scattered across strategies — is a common pattern we see among Qeasy customers.
3. Header and body processed in stages: Headers go first (linking to the request order, warehouse, customer), then bodies line by line. If a line has an abnormal item code or quantity, only that line is affected — the whole document is not lost.
4. Request-order lookup strategy: Set a maximum lookback window (e.g., 90 days); beyond that, route to a manual queue. Avoid unbounded lookups — they can overload Xingchen's API.
5. Write acknowledgment handling: When Xingchen returns success, close the source record. Business errors such as "linked but quantity inconsistent" must go to manual review — do not auto-retry.

Implementation Steps

Three phases work better than going full-volume on day one:

• Phase 1 · Incremental start point: Freeze a timestamp (e.g., midnight today) and sync only Other Inbound Orders modified after it. In Qeasy, set crontab to every 5–10 minutes, run for 1–2 days, and confirm documents reliably land in Xingchen and link to request orders.
• Phase 2 · Full-volume trigger: Backfill historical data. Strongly recommend not running an overwrite-style full sync in production. Instead, batch by customer and time window; after each batch, sample 5–10 documents for reconciliation (quantity, amount, source document no.).
• Phase 3 · Lock in the schedule: Once stable, set the cadence to whatever the business can tolerate. For retail, every 10–30 minutes is usually enough; if return volume is low, hourly works fine and reduces API pressure.

Running incremental and full-volume on parallel tracks is a common pattern among Qeasy customers — incremental ensures timeliness, full-volume acts as a safety net.

Lessons Learned (Pitfalls)

1. Quantity direction confusion: Wangdiantong's Other Inbound Order uses positive quantities meaning "inbound"; Xingchen's Sales Return also uses positive quantities but means "returning to the customer". This is where things go wrong. The safe approach is to add a direction flag in the middle layer rather than flipping signs in field mapping.
2. Over-broad request-order matching: A typical mistake is matching on "customer + SKU" only, which can incorrectly link someone else's return document. At minimum, add the "original sales order no." as a strong constraint.
3. Warehouse code mismatch: Wangdiantong and Xingchen often use different warehouse code systems. We have seen "01" on the Wangdiantong side and "WH01" on the Xingchen side on customer sites. Always maintain this explicitly in the mapping table — never hard-code it in scripts.
4. Re-inbound triggering duplicate returns: Wangdiantong allows modifying and re-pushing Other Inbound Orders, which can create multiple returns in Xingchen. In Qeasy, use source_no + customer + SKU + inbound_date as an idempotency key; skip if it already exists.
5. Timezone and date boundaries: Cross-midnight inbound documents (e.g., a record near dawn) — which timezone's date to use directly affects reconciliation. Recommend both sides agree on one timezone and let the middle layer pass the date string through transparently, without timezone conversion.

When to Use and When Not to Use

Use when: B2B retail or wholesale return-inbound scenarios where Xingchen needs formal Sales Returns linked to request orders for receivables reversal and inventory reduction.

Do not use when: C2C e-commerce refunds (these go through refund documents, not Sales Returns), or scenarios where no Sales Return Request Order was previously created in Xingchen (in that case the lookup for src_apply_no will fail, and a pure create-new path should be used instead of this strategy).