Inventory Transfer Sync in Practice: Pushing Standard Goods-Doc-In from Jky to Distributed Transfer-In on Kingdee Cloud

What This Strategy Solves

A retail group running a privately deployed hybrid of Jky and Kingdee Cloud ran into a familiar drift: store-level transfer instructions were created as standard goods-doc-in records on the Jky side, while corporate inventory and financial accounting lived on Kingdee Cloud. Without bridging the two, the warehouses assumed goods had arrived while the accounting system still showed them in transit.

We used the Qeasy Data Integration Platform to take ownership of the problem: pull standard goods-doc-in records from Jky incrementally by creation time, transform them into distributed transfer-in documents on Kingdee Cloud, and keep both ends of the transfer chain aligned.

Data Flow and Field Mapping

The pipeline is one-way: Jky → Qeasy middleware → Kingdee Cloud. The source side is a query-style WebAPI; the target side is an execute-style WebAPI.

Source (Jky) key fields: goodsDocNo (inbound document number), recId (unique identifier), startDate/endDate (creation-time window), inouttype (in/out type), ownerName (owner / inventory organization). Incrementality is driven by the time-window variables {{LAST_SYNC_TIME|datetime}} and {{CURRENT_TIME|datetime}}.

Target (Kingdee Cloud) key fields: FStockOrgID (transfer-in inventory org), FOwnerTypelnldHead fixed to BD_OwnerOrg (transfer-in owner type), FOwnerlnldHead (transfer-in owner), FDate (document date), FBillTypeID fixed to FBDR01_SYS (document type), FTransferMode (transfer mode), and the body line items.

Typical mapping reference:

How to Configure on Qeasy

Treat the strategy as a single dedicated integration flow on Qeasy. A few points are worth expanding—name configuration items by business semantics so future maintainers can read them.

1. Source query API: WebAPI / POST, effect=QUERY. Pagination starts at pageIndex=0, with pageSize=50 as a balance between payload and call frequency. Enable autoFillResponse so the platform merges paginated results automatically.
2. Incremental time window: bind startDate to {{LAST_SYNC_TIME|datetime}} and endDate to {{CURRENT_TIME|datetime}}. Do not hard-code—this is the soul of incremental sync.
3. Idempotency key: use goodsDocNo or recId as the primary key; pass it as the external bill number on the Kingdee Cloud side to prevent duplicate creation.
4. Code mapping: cross-system strong-validation fields like inventory org and owner should be maintained centrally in Qeasy's mapping table. We have seen customers hard-code them in conversion scripts, only to spend two weeks debugging when the org structure changed three months later.
5. Target execute API: WebAPI / POST, effect=EXECUTE, api=batchSave. Keep FBillTypeID fixed to FBDR01_SYS and FOwnerTypelnldHead fixed to BD_OwnerOrg—do not let them participate in variable computation.
6. Error handling: enable the platform's built-in retry and failure queue; preserve the original payload when the target returns non-success, and use the idempotency key for re-run deduplication.

Implementation Steps

This is what really decides whether things are stable after go-live. We usually walk through four phases.

• Step 1, full initialization: run a one-off full task to push all historical transfer documents accumulated on Jky before go-live to Kingdee Cloud, then disable it.
• Step 2, set the increment anchor: once full sync is complete, anchor LAST_SYNC_TIME to the creation time of the last successfully synced document. This is the zero point for incremental sync.
• Step 3, formal scheduling: source crontab set to 9 6-23/2 * * * (an offset every 2 hours during business hours), target crontab set to 55 */2 * * * (closing 5 minutes before the hour). The two sides are staggered to avoid contending for the same window.
• Step 4, monitoring and reconciliation: for the first 7 days, reconcile document counts and amounts between the two systems daily; once stable, switch to weekly checks, and route abnormal documents through the failure queue for manual recovery.

Lessons Learned

1. Incomplete time window, lost records: if startDate uses "last schedule end time" instead of "creation time of the last successfully synced record", cross-time-zone or scheduling delays easily cause data loss. The safe pattern is to anchor on the maximum recId or createTime from the source.
2. Hard-coded owner fields: stuffing ownerName directly as a string into FStockOrgID works fine before go-live, but breaks once the org structure changes. A centralized mapping table is the only sustainable approach.
3. Misaligned body pagination: source documents may contain hundreds of line items; if the transform only takes the first page, the target ends up with partial lines and mismatched quantities. Always confirm the entire body is delivered, or loop per-line and submit in batches.
4. Constants overridden by upstream fields: control fields like FBillTypeID and FOwnerTypelnldHead placed inside a generic transform script can be accidentally overwritten by upstream fields, scrambling the document type. The safe pattern is to keep them as isolated rows that do not participate in any variable mapping.
5. Same-window scheduling conflict: source finishes pulling just as target is still processing, and the next round starts—causing the same document to be pushed twice. Staggered scheduling plus an idempotency key is the double insurance.

When This Applies—and When It Doesn't

Applies: one-way Jky → Kingdee Cloud transfer sync in a privately deployed environment, near-real-time (2-hour level) reconciliation during business hours, cross-org / cross-owner standard goods-doc-in documents. Does not apply: reverse sync (Kingdee Cloud → Jky), status callbacks for the transfer instruction itself, or non-standard custom documents that require dedicated modeling.