Mapping Jushuitan Other Inbound Orders to Kingdee Cloud: A Single-Strategy Stock Document Sync Tutorial

What This Strategy Solves

When a retail or e-commerce business runs multiple systems in parallel, one deceptively simple document often causes endless reconciliation pain: the "Other Inbound Order." Used for stock adjustments, transfer-ins, and discrepancy corrections, these orders are typically created in Jushuitan by frontline staff, but the financial and inventory accounting must land in Kingdee Cloud. Once the two sides drift apart, the inventory balance and the general ledger will never agree, and the stock-taking season turns into a fire drill. This strategy aims to push Jushuitan Other Inbound Orders into Kingdee Cloud Other Inbound Orders in a stable, traceable way, so the same business event looks the same on both sides.

Data Flow and Field Mapping

The flow is unidirectional. Jushuitan acts as the source system, exposing data through the other.inout.query API. The Qeasy integration platform acts as the middle layer for field mapping and cleansing, then writes into the Kingdee Cloud target via the batchSave interface.

Key field mapping (Source → Middle Layer → Target):

Worth highlighting: header fields (FBillNo/FDate/FStockOrgId) and body fields (FMaterialId/FQty) are processed in separate stages inside Qeasy—header first, body after—so that failures can be located quickly. This is the "header-then-body phased" approach we often recommend to customers on-site.

How to Configure It in Qeasy

Configuring this strategy in the Qeasy integration platform is essentially wiring the source's "modified-time window pull" and the target's "batch save" into a single strategy flow.

1. Source Connector: Select the Jushuitan platform, choose API other.inout.query, set HTTP method to POST. Bind the incremental fields modified_begin and modified_end using placeholders {{LAST_SYNC_TIME|datetime}} and {{CURRENT_TIME|datetime}}—this is the lifeblood of incremental sync.
2. Filter Conditions: Hard-code status to Confirmed so that only posted documents are pushed. Draft or pending documents would otherwise pollute downstream inventory. Limit types to "Other Inbound" to match the target document type.
3. Middle-Layer Mapping: In the Qeasy field-mapping canvas, build a central mapping table for organizations, warehouses, owners, and SKU codes. A common pattern with Qeasy customers is to centralize code mapping in one place—an Excel fed into Qeasy's mapping center, fully auditable.
4. Target Connector: For Kingdee Cloud, select batchSave. Fix FBillTypeID to QTRKD01_SYS and turn on idCheck to prevent duplicate pushes.
5. Scheduling: The source pull cron is 1-59/25 7-23 * * * (every 25 minutes, staggered), and the target write is */8 7-23 * * * (every 8 minutes per batch). Staggering avoids collisions on both sides.
6. Runtime Safeguards: Enable Qeasy's "breakpoint resume" and "failure retry" so transient network glitches are handled automatically.

Implementation Steps

We typically follow a "skeleton first, incremental next, full-load last" rollout.

Stage 1: Materials and master data first. This strategy depends heavily on material master data. Confirm that the material sync strategy is already stable; otherwise FMaterialId will fail for every line.

Stage 2: Confirm the incremental start point. In Qeasy, manually specify an incremental start time, such as seven days ago, and run a few rounds to observe data volume and failure rate. Once stable, gradually move the start point earlier to match the real business need.

Stage 3: Full-load backfill. During a business off-peak window (e.g., late night), trigger a historical full backfill in Qeasy to close the historical gap. After the full load finishes, switch back to daily incremental.

Stage 4: Tune the schedule frequency. After one to two weeks of operation, tighten the cron from 25 minutes down to 15 or even 10 minutes based on document volume—but always watch the target write latency. Many customers initially overlook how easy it is to overwhelm Kingdee Cloud's batchSave queue.

Lessons Learned

• Pitfall 1: Pushing drafts. Without filtering on status, drafts and pending documents flood downstream and inflate inventory. The safe move is to hard-code Confirmed in the Qeasy source connector.
• Pitfall 2: Time zone mismatch. Jushuitan timestamps use UTC+8, but Qeasy's default variables may use UTC, causing dates to be off by one day. Always pin the time zone explicitly after {{LAST_SYNC_TIME|datetime}}.
• Pitfall 3: Missing SKU codes. Products exist in Jushuitan but not in Kingdee Cloud, so FMaterialId errors out everywhere. The right pattern is to add a "fail-to-manual" branch in Qeasy so materials can be backfilled before retry.
• Pitfall 4: Full load colliding with incremental. Running a full backfill and the incremental pull at the same time creates duplicate documents. The safe approach is to temporarily pause the incremental cron during the full-load window and resume it afterwards.
• Pitfall 5: Non-unique FBillNo. In rare cases Jushuitan's io_id can be reused, which would overwrite existing target documents. Always turn on idCheck and add an existence-check step in Qeasy.

When to Use and When Not to

Use it when: a retail or e-commerce business runs multiple systems and needs to consolidate inventory in Kingdee Cloud—the classic pattern where other inbound orders live in Jushuitan while financial and inventory accounting lives in Kingdee Cloud. Do not use it when: bidirectional sync is required, when reconciliation must be near real-time, or when material master sync has not yet stabilized—without SKU codes, this strategy will simply fail.