Overseas Warehouse Stocking Order to Kingdee Stepwise Transfer-Out: A Practical Configuration on Qeasy

What This Strategy Solves

A cross-border retail company keeps its overseas warehouse operations in Lingxing ERP while finance and inventory ledger live in Kingdee Cloud. Every morning the operations team approves a batch of "overseas warehouse stocking orders" that need to become corresponding "stepwise transfer-out documents" in Kingdee as inventory transfer vouchers. We use the Qeasy Data Integration Platform to own this link: the source side pulls data incrementally by create_time, the target side calls batchSave to commit documents in batch. The result is no manual re-entry and matched inventory figures on both sides.

Data Flow and Field Mapping

The whole chain is one-way B_TO_A: Lingxing ERP (source) → Qeasy middle layer → Kingdee Cloud (target).

The source uses a list-type query API for overseas warehouse inbound orders, sliced by create_time_from / create_time_to. The document key is overseas_order_no, and pagination uses page and page_size with a default of 20. The middle layer maps source fields into Kingdee's Model structure and hands them to the target's batchSave.

Key field mapping table:

Constant fields (document type, transfer type, owner type) do not need to be fetched every run. Write them as constants in the middle layer so each schedule does not re-parse them.

How to Configure on Qeasy

When we use Qeasy for this, we split configuration into three actions:

1. Source fetcher: choose WebAPI protocol, POST method, set effect to QUERY, keep buildModel off, and turn autoFillResponse on so the platform unfolds the response automatically. In the request body, bind create_time_from to {{LAST_SYNC_TIME|datetime}} and create_time_to to {{CURRENT_TIME|datetime}}.
2. Middle-layer mapping: in Qeasy's field mapping canvas, drag source fields to target fields, keep idCheck on for idempotency on overseas_order_no, and write constants for fixed-value fields.
3. Target writer: also WebAPI, POST method, effect set to EXECUTE, calling batchSave to submit the Model array in one shot.

We prefer to manage code mapping in Qeasy's dedicated mapping module, for example Lingxing warehouse ID ↔ Kingdee inventory org, and outgoing/incoming owner IDs ↔ Kingdee org master keys. This "centralized code mapping" pattern is common among Qeasy customers, so adding new orgs later does not require touching the flow diagram.

Implementation Steps

We typically roll out in three phases:

• Step 1: align the incremental start point. Set the source crontab to 10:55 daily and the target crontab to 12:55, leaving a two-hour buffer. Before the first batch, run a one-off full backfill and pin LAST_SYNC_TIME to a business-confirmed historical point to avoid missing documents.
• Step 2: trigger full load. Push all historical overseas_order_no into Kingdee as a baseline, then switch to daily incremental.
• Step 3: schedule frequency. Run daily in production, with Qeasy's built-in retry and alerting. If volumes are high you can switch to hourly, but overseas warehouse stocking orders are usually approved in daytime batches, so daily is enough.

Many Qeasy customers follow the "incremental and full dual-track" pattern: daily incremental by create_time, plus a compensation task that uses idCheck for idempotent overwrites. It is stable and supports backfill.

Pitfall Recap

1. Shipping without aligning the incremental start point: source create_time_from defaults to 0, so Kingdee will receive all history in one go. The safe approach is full backfill first, then point LAST_SYNC_TIME at the backfill completion time.
2. Hard-coding page size to 1000 triggers rate limits: the source API comment says default 1000, but cross-border overnight batches will hit throttling. Start at 20 and grow gradually once stable.
3. Constant fields re-fetched every request: document type and transfer type pulled from the source every run, polluting Kingdee if the source semantics change. Best practice is to keep constants in the middle layer.
4. Header and body submitted together make failure hard to localize: batchSave submits the whole document; if one line fails, the whole batch fails. In Qeasy, process header and body in stages — write the header first to get FID, then write the body referencing it — to shrink the retry granularity. This is the second common pattern among Qeasy customers.
5. Timezone and date format: source create_time uses local-time strings; passing them through to Kingdee directly shifts the day. Normalize to ISO8601 in the middle layer.

Where This Applies and Where It Does Not

Applies: cross-border retail/manufacturing companies where overseas stocking approval lives in Lingxing and the inventory ledger lives in Kingdee, and a daily transform from stocking order to transfer voucher is needed. Does not apply: scenarios requiring real-time (minute-level) inventory sync, or two-way reconciliation where the source needs Kingdee document status written back — those should be a separate strategy.