Sync Sales Outbound Orders from Jushuitan to Kingdee Cloud x星辰: Field Implementation Guide
What This Strategy Solves
In a real project with a retail enterprise, sales outbound orders generated by e-commerce channels live in Jushuitan, while finance and inventory accounting require them to be consolidated in Kingdee Cloud x星辰. When the two sides are not connected, the most direct consequence is that shipping data enters the e-commerce backend but is not reflected in time in the ERP's outbound and receivables, and the inventory ledger and financial ledger become increasingly inconsistent.
What we need to do is to synchronize the sales outbound orders generated by Jushuitan Qimen to the sales outbound orders in Kingdee Cloud x星辰 according to established rules. This is a typical scenario of "business documents being posted across systems," and its value lies in providing a reliable basis for inventory, receivables, and cost accounting on the ERP side, eliminating the need for manual secondary entry.
Data Flow and Field Mapping
The overall path is: Jushuitan Qimen → Qeasy Integration Platform (middleware layer) → Kingdee Cloud x星辰. The middleware layer is responsible for data fetching, light cleaning, field mapping, and write packaging.
Key field comparison (core part):
| Business Meaning | Jushuitan Qimen (Source) | Kingdee Cloud x星辰 (Target) | Notes |
|---|---|---|---|
| Document Number | io_id / io_no | BillNo | Deduplication and length truncation required |
| Outbound Time | io_time | BizDate / BusinessDate | Timezone and format unification |
| Customer Code | shop_id / receiver | CustomerCode | Usually needs mapping at the middleware layer |
| Product Code | sku_id | MaterialCode | Align with material master data |
| Quantity | qty | Qty | Numeric type, pay attention to units |
| Unit Price | price | Price | Clarify tax-inclusive or not |
| Warehouse | warehouse | StockCode | Source from warehouse dictionary table |
The problematic areas are the encoding of customers, products, and warehouses. For customers, Jushuitan uses store or member conventions while Kingdee uses customer master conventions; for products, sku in Jushuitan is a product-level ID while Kingdee uses material codes; warehouses are even more different. These three types of mappings must be centrally maintained at the middleware layer; otherwise, downstream data will become increasingly messy.
How to Configure on the Qeasy Platform
We use the Qeasy Data Integration Platform to implement this strategy. The configuration is divided into three parts:
- Source Data Source: Select the Jushuitan Qimen interface, pull outbound orders by incremental time window, and remember to add status filter conditions to only fetch approved/shipped orders.
- Target Data Source: Configure the sales outbound order save interface for Kingdee Cloud x星辰 V2. It is recommended to prioritize standard open interfaces for easier upgrades.
- Integration Solution: Connect source and target, and add three components in the middle: "Field Mapping," "Data Cleaning," and "Encoding Conversion." Encoding mappings should be centrally placed in an independent mapping component for easier subsequent maintenance.
Typical configuration points:
- Headers and line items should be processed in phases: stabilize the header first, then handle the detail lines.
- Incremental and full-volume dual tracks: use incremental for daily operations, and trigger full-volume replenishment with one click when issues arise.
- Encoding mappings (customers, products, warehouses) are centrally maintained in "Basic Data" type strategies, and the sales outbound order strategy only references them without redefining.
- Abnormal data should first enter a "staging table" and then be pushed again after manual confirmation to avoid dirty data polluting downstream.
Implementation Steps
We generally take four steps on the customer site:
Step 1: Define the incremental starting point. Select a historical date as the "water level" for the first synchronization. It is recommended to look back 1–3 days for the first run to avoid missing documents.
Step 2: Full-volume trigger and reconciliation. After the first full run, immediately perform a round of reconciliation: extract Jushuitan's outbound orders of the day and Kingdee's inbound sales outbound orders of the day, and compare document number, amount, and quantity order by order. This is the key window to verify the correctness of mappings.
Step 3: Switch to incremental and execute according to the scheduling cycle. A common scheduling frequency is once every 15 minutes; for customers with large business volumes, it can be compressed to once every 5 minutes. The incremental field uses Jushuitan's "last update time" combined with status filtering to ensure neither missing nor duplicate orders.
Step 4: Monitoring and alerts. Turn on runtime monitoring, failure retry, and DingTalk/WeCom alerts on Qeasy. Three consecutive failures will automatically notify the on-duty person, which is the standard fallback.
Lessons Learned from Pitfalls
-
The first full-volume run did not look back far enough. A typical mistake is to directly take the current day as the starting point, resulting in missing orders that were shipped in previous days but not pushed. The safe approach is to look back 1–3 days for the first run and reconcile immediately after.
-
Customer codes "seem to match" but actually do not. Jushuitan's store ID and Kingdee's customer code are often not the same thing. Relying on manual Excel maintenance for a month or two starts to go wrong. This is easy to fail. It is recommended to centrally manage mappings in Qeasy's encoding mapping component and verify them regularly.
-
Detail line count is truncated. A promotional order's detail lines exceeded the single-interface limit, causing the entire batch to fail with only one line of error, which is hard to spot with the naked eye. The safe approach is to pre-batch by line count at the middleware layer and split orders when exceeding the threshold.
-
Inconsistent time zones and date formats. Jushuitan uses default timestamps while Kingdee requires string dates. Cross-timezone customers often experience "yesterday's orders arriving today." Be sure to unify formats and time zones at the middleware layer.
-
Missing status filter causes duplicate order pushes. Without properly filtering "shipped/approved" statuses, increments are repeatedly pushed, and Kingdee generates duplicate orders. This is easy to fail. It is recommended to place filter conditions at the very front of the source component.
Applicable and Non-Applicable Scenarios
Applicable: E-commerce retail enterprises where Jushuitan serves as the front-end transaction/fulfillment system and Kingdee Cloud x星辰 serves as the back-end ERP, requiring outbound orders to be posted to the ERP for inventory and receivables accounting.
Not applicable: Pure ERP scenarios where business is fully closed-loop within Kingdee; as well as in-warehouse operation synchronization that requires real-time second-level responses (for such cases, direct push via message queues is more advisable).