Sales Delivery Sync from Guanyi Cloud to Kingdee Cloud Sky: End-to-End Path of a Single Strategy
What this strategy solves
In a multi-system landscape, a retail merchant consolidates front-end store and e-commerce orders in Guanyi Cloud while finance and supply-chain accounting live in Kingdee Cloud Sky. For offline delivery, the delivery notes created on the Guanyi side must land in Kingdee as sales outbound documents, which serve as the source vouchers for downstream inventory, costing, and receivables. It looks like moving a single document, but it is tricky: high volume, frequent status changes, inconsistent code systems across the two sides, and any misalignment directly distorts the inventory ledger. We use the Qeasy data integration platform to host this line as one strategy, making it easy to trace and replay.
Data flow and field mapping
The end-to-end path: Guanyi Cloud (source) → Qeasy middleware → Kingdee Cloud Sky (target).
The source side pulls header and line data from Guanyi sales delivery notes; the target is the Kingdee sales outbound document. The key field mapping is shown below. We recommend centralizing these mappings in Qeasy so they can be reused by other strategies.
| Business meaning | Guanyi Cloud (source) | Qeasy middleware | Kingdee Cloud Sky (target) |
|---|---|---|---|
| Document number | Delivery note no. | delivery_no | Document number |
| Document date | Delivery date | delivery_date | Business date |
| Customer code | Customer code | customer_code | Customer code (mapped) |
| Warehouse code | Warehouse code | warehouse_code | Warehouse code (mapped) |
| Item code | Item code | sku_code | Material code (mapped) |
| Quantity | Delivery quantity | qty | Actual issue quantity |
| Unit price | Unit price | price | Tax-inclusive or exclusive unit price |
| Remark | Remark | memo | Remark |
Code mapping is the linchpin of this implementation: customer, warehouse, and item master data must be reconciled in Qeasy mapping tables ahead of time; otherwise, a Guanyi code will not resolve on the Kingdee side—the classic failure pattern.
How to configure on Qeasy
Four configuration blocks get this running stably.
Step 1: Register the two system sources (Guanyi Cloud, Kingdee Cloud Sky). Credentials are managed centrally in Qeasy credential storage; secrets never live in local files.
Step 2: Build the source pull. Given the volume of Guanyi delivery notes, use pagination plus a time window and filter by document status so draft notes are excluded.
Step 3: Build the target write. Kingdee Cloud Sky is strict about required fields on sales outbound documents. A common pattern is to split header and body into two phases: write the header first, capture the Kingdee-returned document inner ID, then post the body. This is the typical "header-body phased" pattern on Qeasy, and it significantly reduces the half-success half-failure scenario.
Step 4: Build mappings and conversions. Customer, warehouse, and item codes go through the mapping tables; other fields only need lightweight name and type conversions.
Implementation steps
We recommend splitting implementation into three phases with appropriate scheduling.
Phase 1: Incremental anchor preparation. Run master-data syncs first so customer, warehouse, and item mappings land in the Qeasy mapping tables. The order sync strategy depends on these three strongly; the order cannot be reversed.
Phase 2: Full trigger. When historical delivery notes are numerous, run a one-off full sync to backfill the recent history. Run the full phase during off-peak hours with large batch intervals to avoid downstream spikes.
Phase 3: Incremental schedule. The incremental anchor is the last successful execution timestamp. Frequency depends on volume: a few hundred orders per day works at 15–30 minute intervals; higher volumes can go down to 5–10 minutes. Qeasy supports both crontab expressions and manual replay; on replay, typically reset the incremental anchor.
After going live, keep a one-week observation window focused on document status, inventory counts, and reconciliation differences before shortening the interval.
Pitfalls and lessons learned
1. Distributed mapping management. Early on we wrote customer, warehouse, and item mappings into each strategy separately, then updated materials but forgot customers, and the two ledgers drifted within a month. The safe pattern is to centralize in Qeasy mapping tables and share across strategies.
2. Header and body submitted in one shot. Kingdee Cloud Sky often rejects the whole document when body fields are missing, causing full rollback while the source is already marked. This is a common pitfall; we recommend phased handling so failures only retry the body.
3. Improper incremental anchor reset. A typical mistake is promoting a strategy that ran in test directly to production, which floods Kingdee with test documents. The safe approach is to explicitly reset the incremental anchor when switching environments and add a status filter.
4. State machine not enforced. Guanyi delivery notes have draft, approved, shipped, and other states; the target should only consume approved and later states, otherwise you get "Kingdee issued, then Guanyi recalled" scenarios.
5. No fallback for abnormal documents. Any sync link will produce failures. Configure an exception branch in Qeasy: failed documents flow into a manual handling queue, with source document number and target response captured for debugging.
Suitable and unsuitable scenarios
Suitable: Guanyi Cloud as the front-end transaction system paired with Kingdee Cloud Sky as the back-end finance and supply-chain system; offline-dominant delivery with strict inventory and finance consistency needs, typical of retail and distribution merchants. Unsuitable: pure online delivery that demands real-time, second-level inventory, or pure Guanyi single-system scenarios without a Kingdee Cloud Sky accounting backbone.