Sales Outbound Drop-Ship Sync in Practice: One Strategy from Jike Cloud to Kingdee Cosmos

What This Strategy Solves

In a drop-ship scenario, e-commerce orders are placed in Jike Cloud, but finance and inventory must be settled in Kingdee Cosmos. If the sales outbound document is not pushed across, Kingdee has no shipping record—and inventory and receivables drift out of sync. We use the Qeasy data integration platform to host this strategy so that drop-ship outbound documents land in Kingdee every 15 minutes, keeping both sides reconciled.

Data Flow and Field Mapping

The chain is: Jike Cloud (source) → Qeasy (middleware) → Kingdee Cosmos (target).

The source side calls jackyun.tradenotsensitiveinfos.list.get to fetch drop-ship orders, with modified_begin / modified_end defining the time window, tradeNo for precise fetching, and pageSize controlling pagination.

The target side uses Kingdee's batchSave to write the sales outbound document.

Key field mapping:

shopCode is the critical bridge field here—both org and customer are resolved through it.

How to Configure in Qeasy

When configuring this strategy in the Qeasy platform, keep these points in mind:

1. Source pull interface. Use Jike Cloud's tradenotsensitiveinfos.list.get. Set pageSize to the maximum allowed to minimize requests; drive the incremental cursor with startModified / endModified.

2. Centralized code mapping. The _findCollection lookups from shopCode to FSaleOrgID and FCustomerID should be maintained centrally in Qeasy's data-mapping module. A common Qeasy customer pattern is to put all shop-to-org-to-customer mappings into a single mapping table, updated only when a shop is added or changed—not scattered across strategies.

3. Target write. Use batchSave on the Kingdee side. Set FBillTypeID to XSCKD07_SYS; bind FBillNo with {{tradeNo}}; bind FDate with {{consignTime}}; resolve org and customer through the lookup table.

4. Idempotency and validation. Enable idCheck on both sides, using tradeId / id as the idempotency key to prevent duplicate documents on retries.

Implementation Steps

We recommend three phases:

Phase 1: Define the incremental starting point. Pick a starting timestamp in Jike Cloud (e.g., 00:00 of that day), backfill pre-start documents into Kingdee via a one-off full-import script, then switch to incremental mode using startModified / endModified rolling windows.

Phase 2: Full-import trigger. Run the full import with time slices, each no more than seven days apart (a hard limit of the source API). After it completes, reconcile document count and amount between the two systems before enabling scheduled runs.

Phase 3: Scheduling cadence. Set source crontab to */15 * * * * and target to */16 * * * *, offset by one minute to avoid simultaneous connection contention. A common Qeasy customer pattern is dual-track: incremental runs during the week, plus a daily full-range validation at 02:00 on Sundays as a safety net.

Pitfalls and Lessons

1. Window over seven days fails outright. The source API enforces a 7-day max gap between modified_begin and modified_end—slice the full import accordingly.

2. shopCode not found in Kingdee. If the shop is not set up in Kingdee's master data, or codes are inconsistent, the entire document gets rejected. Pre-validate with a shop list before going live.

3. Duplicate document numbers. In drop-ship scenarios, Jike Cloud trade numbers may be reused or re-pushed—without an idempotency key on the target side, Kingdee will reject with "document number already exists."

4. Header passes but body is dropped. A typical mistake is mapping only header fields and ignoring the line items. A common Qeasy customer approach is staged validation: validate header only first, then add body after the header path is stable.

5. Time zone and date format. Jike Cloud's default time zone differs from what Kingdee's FDate expects—unconverted values get rejected.

When This Applies and When It Doesn't

Applies: e-commerce drop-ship, store-front fulfillment, and outbound document sync between heterogeneous systems.

Does not apply: sub-second real-time core trading pipelines (use message queues instead), and multi-level outbound flows with complex approval routing (drive those through Kingdee's state machine rather than batch sync).