Practical Guide: Syncing Inventory Count Inbound Orders from WMS to Kingdee

What this strategy solves

In a retail company's warehouse, a stock count runs every night after closing. The count results land in the WMS as "inventory count inbound orders," and the warehouse supervisor expects these differences to be posted into the ERP's inventory module and reflected in the general ledger before opening the next morning. But WMS count inbound orders and ERP standard other inbound bills are not a one-to-one mapping — document type, business type, and inventory transaction type all need translation. If you push raw data, you pollute ERP master data.

This strategy addresses exactly that: reliably and traceably posting WMS count inbound orders into ERP other inbound bills without affecting other inbound flows.

Data flow and field mapping

The source side is the WMS count inbound order (API wms.StockPd.queryStockPdInDetail), and the target side is the ERP standard other inbound bill (API /kapi/v2/dtog/im/im_otherinbill/batchAdd). The middle layer, handled by the Qeasy data integration platform, performs transformation, mapping, idempotency, and retries.

Key field mapping table:

Centralized mapping management is a common pattern among Qeasy customers: environment-related mappings (warehouse, org, document type) live in mapping tables on Qeasy, while business fields pass through directly. Switching environments only requires updating the mapping tables, not the main flow.

How to configure on Qeasy

Step 1, source integration. The source API is wms.StockPd.queryStockPdInDetail, a POST request. Use order_no + stockin_id as the idempotency key. Make the pagination pager configurable to avoid pulling everything at once and overwhelming the interface.

Step 2, target assembly. The target API batchAdd supports batching, so we process header and body in two phases: on Qeasy, use an aggregation component to group line items under the same document number into a single header, then perform batch writes. A subtle detail here: another common Qeasy customer pattern is "header/body phased" — confirm the header lands first, then fill the body. On failure, only the body rolls back, keeping the ERP document pool clean.

Step 3, mapping and functions. biztime uses FROM_UNIXTIME({{stockin_time}}/1000,'%Y-%m-%d %H:%i:%s') to convert the date, billno takes {{order_no}} directly, and org_number and billtype_number use constants or mapping tables.

Step 4, idempotency and retries. Enable idCheck to dedupe on order_no at the target side. HTTP 5xx and timeouts retry automatically; business errors go to a manual investigation queue.

Implementation steps

Phased scheduling is the key to a safe rollout.

1. Incremental starting point: first run a one-time full backfill of the last 7 days of count inbound orders as the baseline. Trigger the full pull with the "full pull" button on Qeasy for a single execution, then turn it off.
2. Incremental polling: source crontab is 12-59/20 7-23 * * * — starting at 7:12, every 20 minutes, ending at 23:59. The target side starts 5 minutes later (17-59/20 7-23 * * *), offsetting source fetch and target write windows to avoid same-minute contention.
3. Schedule frequency: every 20 minutes covers business hours well. Night counts typically finish in the early morning, so the first round at 7 AM naturally picks them up — no extra scheduling needed.
4. Monitoring and alerts: configure two rules on Qeasy — alert when the source pulls zero records for two consecutive rounds, and alert when target write failure rate exceeds 1%. The first prevents silent field changes at the source.

Lessons learned

1. A typical mistake is passing stockin_time as a raw string. The source is a millisecond UNIX timestamp; the target requires YYYY-MM-DD HH:mm:ss. Without FROM_UNIXTIME on Qeasy, ERP will reject it or post it as 1970.
2. Setting billtype_number to "other inbound return". Count differences rarely produce negatives, but if even one negative slips through with the wrong document type, the entire batch gets rejected by ERP. The safe approach is to fix it as im_OtherInBill_STD_BT_S and route negatives through a separate manual channel.
3. Warehouse codes are not mapped. WMS warehouse_no and ERP stock_number follow different naming conventions. Without mapping, you'll get "warehouse not found." The mapping table must be aligned with both the warehouse and ERP teams in advance.
4. Full and incremental are not separated. Turning on full pull in the same scheduled job will blow up the interface. The dual-track pattern (full pull run once, incremental running on crontab continuously) is a common Qeasy customer approach: the two chains don't interfere with each other.
5. Idempotency key only uses order_no. WMS occasionally repushes different line items under the same document number. Use the order_no + stockin_id combination for idempotency to avoid missing or duplicate lines.

Applicable and non-applicable scenarios

Applicable: single or multi-organization sharing one ERP set, only count differences between WMS and ERP need to be posted, and you don't want count orders polluting other inbound flows.

Not applicable: multiple ERPs with multiple account sets, separate books per warehouse, or when the WMS-side count document already contains adjusted stock rather than the difference.