Jushuitan Other Outbound → Kingdee Cloud Other Outbound: An Incremental Sync Strategy Tutorial

What This Strategy Solves

A retail enterprise uses Jushuitan for front-end e-commerce fulfillment and Kingdee Cloud for back-end finance and inventory accounting. Warehouses generate a large number of "Other Outbound" documents every day (transfers, consumptions, scrapping, etc.). Asking warehouse staff to enter data in both systems is slow and leads to reconciliation drift. The goal is straightforward: pull Confirmed Other Outbound documents from Jushuitan by a modified-time window and auto-create Other Outbound documents in Kingdee Cloud. It sounds simple, but outbound documents have headers and lines full of master-data codes (warehouse, location, SKU, batch). If the mapping is wrong, inventory numbers will silently diverge within three months.

Data Flow and Field Mapping

The chain is one-way: Jushuitan (source) → middleware (Qeasy) → Kingdee Cloud (target).

The source calls Jushuitan's open API other.inout.query (POST), pulling documents within a modified_begin / modified_end window. The request hardcodes types=其它出库 and status=Confirmed, locking the scope to "effective Other Outbound". Each document uses io_id as the unique identifier (idCheck=true) for idempotent deduplication.

The target calls Kingdee Cloud's batchSave (POST) to write Other Outbound documents. Key field mapping:

For SKUs, warehouses and locations, we adopt centralized coding mapping management — maintain a dedicated mapping table in Qeasy so that adding a new store or SKU only requires editing one place, and all related strategies pick it up automatically. This is one of the most common patterns among Qeasy customers.

How to Configure in Qeasy

1. Connect source and target platforms. In the Qeasy Data Integration Platform, create connections for Jushuitan and Kingdee Cloud separately, binding the corresponding app credentials (test and production environments as separate connections).

2. Configure the source strategy. Select Jushuitan's other.inout.query. Set modified_begin to the variable {{LAST_SYNC_TIME|datetime}} and modified_end to {{CURRENT_TIME|datetime}}. Hardcode the filter types=其它出库 and status=Confirmed into the request parameters.

3. Configure the target strategy. Select Kingdee's batchSave. Map FBillNo to {{io_id}}. Resolve organization fields dynamically from the mapping table. Apply format conversion on date fields. The header and lines are written in a two-phase header-then-lines pattern — first generate an empty header to obtain Kingdee's internal document ID, then submit line items in batches, avoiding timeouts from oversized payloads.

4. Arrange strategy dependencies. This strategy (sequence=B) depends on related master data being in place first (materials, warehouses), so in Qeasy's orchestration it must run after its dependency strategies.

Implementation Steps

We split the sync into a three-phase schedule:

Phase 1: Full backfill trigger. On go-live day, manually trigger a one-time full backfill to write all historical Confirmed documents that were not synced into Kingdee. After the full backfill, anchor Qeasy's LAST_SYNC_TIME to that go-live moment.

Phase 2: Incremental polling. The source strategy polls every 3 minutes via cron 1-59/3 6-23 * * *; the target strategy writes every 3 minutes via cron 5-59/3 6-23 * * *. The two are offset to avoid thundering herds. Each round only processes additions and modifications within the modified-time window.

Phase 3: Reconciliation and archiving. During off-peak hours each day, run a reconciliation to compare document numbers and statuses on both sides, sending anomalies into a manual fallback queue. Documents pulled from the source with status Cancelled are handled by a corresponding reversal flow on Kingdee's side (out of scope for this strategy).

This is a typical dual-track incremental + full approach — full backfill at go-live for safety, incremental polling for daily operation, reconciliation for exception convergence.

Pitfall Review

Pitfall 1: Wrong timezone in modified_begin. Jushuitan timestamps carry timezone info, while Kingdee's FDate is a local date string. Cross-day data is easily missed. The safe approach is to explicitly normalize the timezone in Qeasy's field transformation.

Pitfall 2: Idempotency failure causes duplicates. If Kingdee's batchSave returns a timeout due to network jitter, Qeasy will retry, but Kingdee may have already written the record. Rely on the unique constraint of FBillNo (= source io_id) as the safety net — drop duplicates rather than re-write.

Pitfall 3: Organization codes hardcoded in the request body. The reference material shows FStockOrgId as 105, but in a multi-store tenant different stores map to different organizations. It must be resolved dynamically from the mapping table; otherwise switching stores will fail.

Pitfall 4: Oversized line-item payload. When a document has many line items, batchSave tends to truncate. The two-phase header-then-lines pattern exists exactly for this case.

Pitfall 5: Wrong status filter. Accidentally syncing WaitConfirm (pending review) documents will cause Kingdee to reject them. Always verify the status=Confirmed filter has not been overwritten.

When to Use and When Not to Use

Use when: the source provides a clear modified-time field and an idempotency key, sync is one-way, and both sides' document structures are relatively stable — typical for other-outbound / other-inbound style businesses.

Do not use when: bidirectional real-time sync is required, the source lacks timestamps or unique keys, or the document state machine is highly complex (strict review/approval flow). In those cases, an event-driven + real-time API push pattern is more appropriate than polling.