Practical Tutorial: Syncing Sales Outbound Orders from Jushuitan to Kingdee Cloud Cosmic
What This Strategy Solves
In a real retail project, the front-end e-commerce platform (Jushuitan) generates hundreds of sales outbound orders daily, while the back-end ERP (Kingdee Cloud Cosmic) needs this outbound data to flow into the financial and inventory accounting chain. The "sales outbound sync" looks simple, but Jushuitan's online SKU codes do not naturally align with Kingdee's material codes. If you do not centralize code mapping, warehouse mapping, and customer mapping in the middleware layer, the inventory balances between the two systems will diverge within three months. We use the Qeasy data integration platform to take on this strategy, concentrating the messy work in the middleware so that the target system only receives standardized data it can recognize.
Data Flow and Field Mapping
The data flow is unidirectional: Jushuitan (source) → Qeasy middleware → Kingdee Cloud Cosmic (target). The core responsibilities of the middleware layer are code conversion, field completion, and unit conversion.
Key field mapping table:
| Business meaning | Jushuitan (source) | Qeasy middleware | Kingdee Cloud Cosmic (target) |
|---|---|---|---|
| Document number | io_id / so_id | Kept as-is, used as external bill number | FBillNo + FSrcBillNo |
| Outbound time | io_date | Convert to yyyy-MM-dd HH:mm:ss | FDate |
| Warehouse | warehouse | Warehouse mapping table → Kingdee warehouse code | FStockId |
| Customer | shop_id | Customer mapping table → Kingdee customer code | FCustomerId |
| Material code | sku_id | SKU master data mapping table → Kingdee material code | FMaterialId |
| Quantity | qty | Unchanged | FQty |
| Price | price | Unchanged | FPrice |
| Remarks | remark | Passed through as-is | FNote |
In Qeasy, three types of mapping tables are typically built: warehouse mapping, customer mapping, and SKU mapping. These are placed in a unified mapping center rather than scattered across each strategy.
How to Configure on Qeasy
On the Qeasy data integration platform, the configuration of this strategy revolves around three stages: source extraction → transformation → target write.
Source side: Select Jushuitan's sales outbound interface (or the sales outbound query interface), pull data incrementally by modification time, set request parameters modified_begin and modified_end, and a page size of 50-100 is recommended.
Transformation layer: Configure field mappings, expressions, and conditional branches in Qeasy's transformation panel. Common processing includes:
- Warehouse codes are replaced through a mapping function lookup;
- Customer codes use if-else fallback; unmatched records route to a default customer and emit a log alert;
- Rows that fail SKU code mapping are written to an exception queue separately, blocking subsequent rows from entering the target to avoid dirty data contaminating Kingdee.
Target side: On the Kingdee Cloud Cosmic side, the standard sales outbound document save interface is used (not via the Qimen channel). After the document is saved successfully, the FBillNo is returned and needs to be written back to the middleware for reconciliation. It is recommended to land the header and the body as two separate data flows: write the header first to obtain the FBillNo, then write the body carrying the FBillNo. If submitted in one shot, a compensation queue must be in place for failure rollback.
Implementation Steps
On customer sites, we usually split the go-live into three phases to avoid crushing both systems with full-load stress testing from day one.
Step one: Confirm the incremental starting point. Pick a low business peak day (for example Sunday 02:00) as the modified_begin starting point, backfill data from that day onwards in one shot, and verify that code mapping and field semantics are correct.
Step two: Trigger a full reconciliation. Full load does not mean reloading all historical documents; instead, compare Jushuitan's current outbound details with Kingdee's existing outbound documents and reconcile the differences manually or via scripts. The purpose of this step is not synchronization but confirming that the baselines on both sides are consistent.
Step three: Configure formal scheduling. A common practice is the "incremental + full-load dual-track" approach: incremental runs every 5-15 minutes, pulling by the modified_end - modified_begin window; full-load runs once a day in the early morning as a reconciliation safety net. Configure these two schedules separately on Qeasy so that they do not depend on each other; an incremental failure does not affect the full-load reconciliation.
During the first week after go-live, it is recommended to keep a manual rerun switch enabled for catch-up data.
Lessons Learned from the Field
Pitfall one: Jushuitan's modified_time and Kingdee's FDate have inconsistent time zones. The source field carries timezone information and needs to be converted (typically to UTC+8) before landing in Kingdee; otherwise, the financial closing date will be off by one day.
Pitfall two: SKU mappings are centrally managed, but a batch of historical SKUs was missed during the initial setup. As a result, a large number of rows went to the exception queue after go-live. The safe approach is to perform a full SKU comparison before go-live and backfill missing entries in the mapping table in one shot.
Pitfall three: Header and body submitted in one shot, network jitter caused a half-success state. A typical mistake is not having a compensation queue, leaving an orphaned header on the Kingdee side after failure. It is recommended to submit the header and body in stages, with independent compensation for each stage's failure.
Pitfall four: The incremental window is set too large (24 hours at a time), causing timeouts as data volume grows. A safe approach is to shrink the window to 5-15 minutes and trade stability for higher scheduling frequency.
Pitfall five: The "void document" logic of Jushuitan is not considered. The source pushes already-voided outbound documents, and the target has no corresponding "void" action; only a red-letter or delete can be performed on the Kingdee side. This needs to be confirmed with the business: is it a physical delete or a red-letter reversal? Status judgment must be added in the middleware layer accordingly.
Applicable and Non-Applicable Scenarios
Applicable: The front-end e-commerce (Jushuitan) serves as the outbound execution side, while the back-end ERP (Kingdee Cloud Cosmic) serves as the financial and inventory accounting center, and the two sides have inconsistent SKU, customer, and warehouse codes that require middleware mapping.
Not applicable: Pure homogeneous system direct connections, scenarios where codes are already unified, or scenarios where outbound data does not need to flow into the financial accounting chain. In these cases, the middleware layer adds unnecessary complexity.