Practical Guide: Syncing Jushuitan Sales Outbound Orders to Kingdee Cloud Skylight Sales Orders

What This Strategy Solves

Once a retailer completes shipping audit and generates sales outbound orders in Jushuitan, finance and supply chain need the matching sales orders in Kingdee Cloud Skylight to drive receivables, inventory, and costing. The challenge is that the two systems use different document models, different coding schemes, and different trigger points. This strategy specifically handles "Jushuitan sales outbound → Kingdee sales order" with delta triggering, pushing only newly created outbound orders and avoiding duplicates on the Kingdee side.

Data Flow and Field Mapping

The overall chain is Jushuitan (source) → Qeasy Integration Platform (middleware) → Kingdee Cloud Skylight (target). On the Jushuitan side, the outbound document carries e-commerce semantics: platform order ID, recipient, warehouse code. On the Kingdee side, the order carries ERP semantics: document type, customer, currency, settlement organization. Direct field-to-field push is not feasible; semantic translation must happen in the middleware.

Key field mapping (only critical items shown):

Business Meaning	Jushuitan Source	Middleware Handling	Kingdee Target
Document No.	io_id / io_no	Prefix added to avoid clash	FBillNo
Document Type	type (sales outbound)	Mapping: outbound → standard sales order	FBillTypeID
Customer Code	receiver / platform_buyer_id	Lookup via customer master mapping	FCustomerID
Material Code	sku	Lookup via material master mapping	FMaterialID
Quantity	qty	Unit conversion (pack → base UOM)	FQty
Warehouse	warehouse	Warehouse master mapping	FStockID
Amount	amount	Validated and recomputed; front-end tax-inclusive price used	FAmount / FTaxPrice
Date	io_date	Convert to yyyy-MM-dd	FDate
Remark	remark	Truncated, source identifier kept	FNote

When building the middleware in Qeasy, we centralize code mappings in the platform's master mapping tables — one table each for customers, materials, and warehouses. The Jushuitan code is the key; the Kingdee internal ID is the value. When new stores or SKUs come online, only the mapping table is updated; the main flow is untouched.

How to Configure in Qeasy

In the Qeasy integration platform, this strategy corresponds to a "Jushuitan → Kingdee Cloud Skylight" data integration task. Typical configuration has four parts:

Data source: the Jushuitan sales.out interface (sales outbound query), pulled incrementally by modification time. The increment start point is set to 30 days before the strategy enable time for cold-start compensation.
Target: the Kingdee Cloud Skylight salebill/save interface, standard sales order save. Document type is set via a mapping constant, never hard-coded in scripts.
Field mapping: configured through Qeasy's visual field mapping. Key transformations (UOM, currency, tax-inclusive/exclusive) use built-in functions. Customer/material/warehouse use lookup mappings; failures go into an exception queue.
Write control: enable "document number idempotency" — the same io_id produces only one Kingdee order regardless of reruns. Enable "failure retry" — Kingdee validation failures fall back to Qeasy's pending list, where they can be reviewed and manually re-pushed.

Implementation Steps

We typically break go-live into three phases — close it down first, then scale up.

Phase 1: Increment start point and cold start. Set the strategy to "manual trigger" in Qeasy and run a script that pulls the full data for the past 30 days. The goal is to backfill any shipped historical orders missing in Kingdee. After backfill, anchor the increment start at "cold start completion time". Getting this wrong causes duplicate backfill or missing orders downstream.

Phase 2: Delta trigger go-live. Switch the strategy to scheduled execution — typically every 15 minutes — with a window covering only "last successful end time ~ current time" for new and changed records. Because Jushuitan pushes outbound orders only after shipping audit, the faster the front-end audit, the faster the Kingdee order appears. Qeasy's "increment + full double-track" mode fits well here: scheduled delta for timeliness, a small nightly full pull for reconciliation.

Phase 3: Schedule frequency and monitoring. Once stable, the delta frequency can be tightened to every 5–10 minutes. On the Qeasy monitoring dashboard, watch three metric families: Jushuitan-side pull failure rate, Kingdee-side save failure rate, and document number conflict count. Any metric crossing the threshold triggers an alert into the enterprise WeChat group.

Pitfalls Revisited

Customer/material codes not centrally mapped, written directly into transformation scripts. Adding a new store or SKU requires script changes and a release cycle, which is too heavy. The safe approach is to push everything down into Qeasy's master mapping tables.
Header and detail pushed in one shot. Jushuitan outbound documents have a single header with multiple detail lines; the Kingdee save interface expects the header to be created first, its internal ID returned, then details are written. Pushing everything at once can cause the entire document to roll back when a detail line is too long or a SKU mapping fails. We typically switch to header-detail phased push: write the header first to get the FID, then batch-write details; only the details are retried on failure.
Ignoring post-shipment modifications. In e-commerce, Jushuitan allows address, remark, and even SKU changes after shipment. Once a Kingdee order is saved and has triggered receivables, subsequent changes must go through a change document rather than another save. We add an extra "modification flag" field to identify which records are changes versus new records, and route them through different downstream paths.
Amount fields copied directly. Jushuitan amounts are front-end tax-inclusive prices; Kingdee requires back-calculation of tax-exclusive prices based on price lists and tax rates. Direct copying creates amount discrepancies at month-end cost settlement. The safe approach is to recompute in the Qeasy transformation layer using the material+customer price list, never do straight field copy.
No idempotency protection. Qeasy retries or manual re-pushes without idempotency create duplicate orders in Kingdee. The strategy layer must enable "document number idempotency" and "source document number deduplication".

Applicable and Non-applicable Scenarios

Applicable: the e-commerce front end is Jushuitan, the back-end ERP is Kingdee Cloud Skylight, and there is a need to push sales outbound into sales orders in real time or near-real time for receivables and inventory accounting.

Not applicable: when Jushuitan and Kingdee belong to the same organization and offline reconciliation is preferred, or when the front end is not Jushuitan or the target is not Kingdee Cloud Skylight — this strategy does not apply directly, and mappings plus interface adaptation must be redone.