Kingdee Real-Time Inventory to Jky Stocktake: A Practical Configuration Walkthrough

What This Strategy Solves

A retail enterprise runs its ERP on Kingdee Cloud and its warehousing/distribution on Jky, and the two systems have long struggled to keep inventory aligned. The business wants to aggregate Kingdee's daily inventory snapshots by warehouse into stocktake documents and push them to Jky for reconciliation. The core of this strategy is "one stocktake per warehouse," not one per item. The real difficulty lies in three areas: field mapping, batch dimension, and the starting point of incremental sync.

Data Flow and Field Mapping (Source → Middle Layer → Target)

Data flow: Kingdee Cloud STK_Inventory → Qeasy Data Integration Platform middle layer (grouped by warehouse) → Jky erp.stock.quantityadjust. Each source record is a snapshot of "material + warehouse + lot." The middle layer groups records by FStockId_FNumber; each group becomes one stocktake document, and all records in the group form the detail lines.

Main-form key field mapping:

Detail-line field mapping:

How to Configure on Qeasy

1. Source configuration: select executeBillQuery, form ID STK_Inventory, mode QUERY, incremental condition FUpdateTime >= '{{LAST_SYNC_TIME|datetime}}', pagination Limit=2000 with StartRow increment. For nested objects, use the dotted syntax: FStockId.FNumber, FLot.FNumber.
2. Target configuration: select erp.stock.quantityadjust, mode EXECUTE. Set warehouseCode value to {{FStockId_FNumber}}; matchType as constant 1; detail as an array referencing the source record collection.
3. Grouping logic: this strategy uses no custom scripts. All aggregation is done by the platform's built-in "group by field" capability, triggered on FStockId_FNumber. This is a common Qeasy customer pattern: prefer platform-native grouping over custom scripting to reduce maintenance cost.
4. Centralized code mapping: warehouse and material code mappings live in master data strategies (e.g., "Kingdee warehouse → Jky warehouse"). This strategy references those mappings directly. If codes differ across systems, use _findCollection to look up the master data strategy.

Implementation Steps

• Stage 1: Full initialization. For the first run, omit LAST_SYNC_TIME and pull historical inventory in one go, group by warehouse, and push to Jky as opening reconciliation. Run during off-peak hours to avoid dirty data.
• Stage 2: Switch to incremental. Once the full sync succeeds, change the filter to FUpdateTime >= '{{LAST_SYNC_TIME|datetime}}' and record the first successful time as the new LAST_SYNC_TIME.
• Stage 3: Scheduling. Source runs at 0 13,23 * * * (13:00 and 23:00); target runs 15 minutes later at 15 13,23 * * * to give the source pull and grouping enough window. In production, this can be tightened to hourly depending on volume.
• Stage 4: Validation and reconciliation. Each cycle, sample-verify that target stocktake quantities match source FBaseQty, check that lot numbers are intact, and confirm no warehouse is missed.

Lessons Learned

1. Confusing FStockId with FStockId_FNumber. FStockId is an object in Kingdee; directly using {{FStockId}} serializes to JSON instead of the code, producing garbage at the target. The safe practice is to always use {{FStockId_FNumber}} for the flat code.
2. Picking the wrong quantity field. FBaseQty is on-hand (book) qty, FBaseAVBQty is available qty. For stocktake, use FBaseQty; otherwise allocated-but-not-shipped qty gets counted in and the two systems drift apart.
3. Missing lot numbers. If materials with batch management are pushed without FLot.FNumber, Jky merges different batches into one line, breaking later batch traceability. Explicitly include FLot in the source request and mark the target field required.
4. Blowing up the target with one big full sync. In one engagement, a full sync was pushed to Jky without staging, triggering rate limits and dropping some stocktake documents. A safer pattern is header-then-detail staging: first push headers to confirm landing, then push details; or configure concurrency throttling inside Qeasy.
5. Incremental starting point not aligned. After a full sync, the team forgot to switch to incremental and re-ran a full sync next cycle, producing duplicate stocktake documents. The transition from full to incremental must be recorded in change logs during handover.

When This Applies and When It Doesn't

Applies: regular reconciliation between ERP and WMS, cross-warehouse stocktake aggregation, batch-strict retail and distribution scenarios. Does not apply: real-time second-level inventory (this strategy runs hourly), complex multi-status stock conversion (e.g., inspecting, frozen) that requires per-status push, and cases where the source has no reliable FUpdateTime field for incremental sync.