From LingXing Return Inbound Orders to Kingdee Other Inbound: A Practical Tutorial on Inventory Sync Strategy

What this strategy solves

Return-inbound document reconciliation is the most overlooked yet error-prone segment in supply chain integration. In one real customer project, the e-commerce operations team recorded return inbound orders in LingXing ERP, while finance and supply chain analytics relied on Kingdee Cloud for inventory book data. Without timely reconciliation, return costs, stock quantities, and batch ledgers would drift day by day. The goal of this strategy is to pull return-type inbound orders from LingXing on a daily schedule and write them into Kingdee's "Other Inbound" document, ensuring traceability of return-side inventory actions on both sides.

Data flow and field mapping

The whole pipeline can be abstracted into three stages: LingXing ERP (source) → Qeasy Data Integration Platform (middle layer, responsible for fetching, transforming, reconciling, retrying) → Kingdee Cloud (target).

Key field mapping is shown below:

Encoding mappings are recommended to be managed centrally in Qeasy, so that future organization changes can be updated in one place, avoiding hard-coding inside every strategy.

How to configure in Qeasy

The source side uses LingXing's open API /erp/sc/routing/storage/inbound/getOrders, with method POST and effect QUERY. The request body limits the time window through start_date and end_date (note: not allowed to cross month boundaries), and filters return inbound orders via the type parameter. offset and length control pagination, defaulting to 200 records per page.

The target side invokes Kingdee's batchSave API, with method POST and effect EXECUTE. The request body needs to map LingXing's header and line fields to Kingdee's FBillNo, FBillTypeID, FStockOrgId, FStockDirect, FDate, and other key fields. In the return scenario, FBillTypeID is fixed at QTRKD01_SYS, strictly distinguished from sales outbound, other outbound, and other document types.

The middle layer in Qeasy needs to do four things: line splitting, field type conversion, null and exception filtering, and idempotency control (deduplicate by order_sn to avoid duplicate postings).

Implementation steps

We recommend proceeding in three stages.

The first stage is establishing the incremental baseline. Initialize a full-history window in Qeasy to backfill the past several days of return inbound orders into Kingdee as the baseline for subsequent increments. Record the initial timestamp as the starting point for the next scheduling window.

The second stage is configuring scheduling and full triggers. The source crontab is suggested at 45 10 * * * (10:45 AM), and the target at 45 12 * * * (12:45 PM). The two time points are staggered to give the source enough time for fetching and transformation, and to avoid colliding with Kingdee's stock closing window. When going live for the first time, manually trigger a full run, and switch to incremental only after verification.

The third stage is daily scheduling and monitoring. Every day the source pulls by window, and the target writes on schedule. Qeasy's run logs, failure retries, and exception alerts should be closely watched during the first week. Once confirmed there are no duplicate documents, missing data, or field omissions, the monitoring frequency can be reduced.

Lessons from the trenches

First, LingXing's query constraint of "no cross-month". If the window accidentally crosses a month boundary, the API will directly error out or return an empty set, looking like a scheduling failure but actually a parameter issue. The stable approach is to encapsulate the window calculation logic in Qeasy, automatically splitting by month around the month-end.

Second, Wrong Kingdee document type. If FBillTypeID is mistakenly written as a sales outbound or other outbound type, the document may appear to be posted, but the stock direction, accounts, and process nodes are all wrong. In the return scenario, it must strictly be QTRKD01_SYS.

Third, Duplicate posting. The source API occasionally returns historical data. If the target side does not perform idempotency on order_sn, the same return order will be posted multiple times. The stable approach is to add a unique key constraint based on order_sn in Qeasy, drop duplicates, and log them.

Fourth, Line items being merged. A single LingXing document may contain multiple SKU lines. If the middle layer only takes the first line or merges quantities, Kingdee's inventory details will not match the physical stock. It is recommended to explicitly split by line in the middle layer and write line by line.

Fifth, Time zone and date format inconsistency. The source opt_time is a timestamp with time zone, while the target FDate usually only takes the date. It is recommended to uniformly format as Y-m-d in Qeasy, to avoid the return date being shifted by one day.

Suitable and unsuitable scenarios

Suitable: E-commerce or retail enterprises where the return process uses LingXing ERP as the business front-end and Kingdee Cloud as the finance and inventory back-end, and where return inbound data needs to be aligned daily. Unsuitable: Cross-entity inter-company transfer returns, industries with extremely high batch traceability requirements such as pharmaceuticals or food, or scenarios where the source system is not LingXing ERP.