Syncing Warehouse Master Data from Jky to Kingdee Cloud: A Practical Walkthrough of One Strategy

What This Strategy Solves

Warehouse master data is the foundation of supply chain integration: the shipping warehouse on sales orders, the receiving warehouse on purchase orders, and the organizational dimension of instant inventory all depend on warehouse records being in place first. A retail company running both Jky as the front-end business system and Kingdee Cloud as the back-end financial and supply chain system in a private deployment environment will see downstream document flows fail the moment warehouses diverge between the two sides. This strategy addresses exactly that: pushing warehouse records from Jky to Kingdee Cloud in a stable, incremental way while keeping codes, names, and attribute fields aligned.

Data Flow and Field Mapping

The entire chain is one-way sync: Jky (source) → Qeasy Data Integration Platform (middle layer) → Kingdee Cloud (target). The source pulls warehouse lists through the erp.warehouse.get WebAPI; the target writes them via batchSave. Below is the key field mapping:

We centralize the code mapping in Qeasy's mapping table, so that later adjustments to source or target fields only require changes in one place.

How to Configure on Qeasy

Source configuration: Select WebAPI type, choose the erp.warehouse.get interface with POST as the request method. Pagination parameters pageIndex and pageSize are fixed at 0 and 50. The incremental cursor uses gmtModifiedStart and gmtModifiedEnd, where the former references the system variable {{LAST_SYNC_TIME|datetime}} and the latter references {{CURRENT_TIME|datetime}}—this is the standard Qeasy approach for incremental sync, with the platform automatically maintaining the timestamp.

Target configuration: Choose the batchSave interface with POST. In the request body, FNumber directly references the source warehouseCode; FName references warehouseName; fields like FCreateOrgId and FUseOrgId are configured as fixed constants rather than mapped from the source, since organizational boundaries are typically determined by the target system's permissions.

Scheduling strategy: The source crontab is set to 3,23,43 * * * *, running every 20 minutes; the target write is set to 10,30,50 * * * *, offset by 7 minutes to leave a window for the middle layer to parse and transform.

Implementation Steps

1. First-round full-volume trigger: Set LAST_SYNC_TIME to a very early historical time so that all historical warehouse records are pulled in one go, ensuring no omissions on the target side.
2. Switch to incremental mode: Once the full volume completes, Qeasy advances LAST_SYNC_TIME to the current CURRENT_TIME, after which only records with modification time later than the last sync point are pulled every 20 minutes.
3. Phased validation: In the first phase, sync only code and name; once alignment is confirmed, enable attribute and organization mapping. This is the most commonly used "header phased" approach at customer sites, reducing initial go-live risk.
4. Monitoring and alerts: Configure failure retry and exception alerts on Qeasy. When the target batchSave returns an error, retry automatically 3 times; after 3 failures, route to a manual queue.
5. Periodic reconciliation: Run a code-consistency comparison script weekly to confirm that warehouse record counts and codes match between source and target.

Pitfall Review

• Pitfall 1: Overlooking idCheck. The source interface's idCheck defaults to enabled. If not explicitly confirmed, the platform treats certain response fields as primary key checks, causing some warehouses to be mistakenly judged as "already exists" and skipped from writing. The safe approach is to confirm that the business primary key is warehouseCode, not some hidden field in the response.
• Pitfall 2: Time zone drift. gmtModifiedStart uses the source time zone. If Qeasy is deployed in a different time zone, the incremental cursor drifts by a few hours, causing missed or duplicate records. Our fix at the time was to convert the source time to UTC before passing it.
• Pitfall 3: Hardcoded batch size. pageSize=50 is the initial value; once data volume grows, pulling too many at once causes the target batchSave to time out. The recommendation is to make batch limits configurable parameters in Qeasy and tune them based on actual data volume.
• Pitfall 4: Hardcoded organization codes. The source has no concept of organization, but the target requires FCreateOrgId. This is the easiest place to fail. Our experience is that such fields should always use constant configuration, never attempt to "derive" them from the source.
• Pitfall 5: Incremental start point not archived. After the initial full-volume run, if LAST_SYNC_TIME is not properly advanced, the next schedule repeats the history pull, causing massive duplicate writes on the target. Qeasy's incremental-and-full dual-track mechanism is critical here: only switch after the full volume completes.

Applicable and Non-Applicable Scenarios

Applicable: Source system is Jky, target system is Kingdee Cloud, and the enterprise has a clear warehouse master data governance standard; warehouse record changes are infrequent (within tens per day); deployment in a private environment that cannot rely on external SaaS. Not applicable: The source lacks a unified modification time field and cannot support incremental sync; the target's organizations change frequently and require more complex permission mapping; and scenarios demanding extremely high real-time performance—this strategy runs at 20-minute granularity and cannot achieve second-level latency.