Practical Tutorial: Syncing LingXing ERP Shipment Settlement Reports to Kingdee Cloud Sky Sales Outbound Orders (Japan Site)
What This Strategy Solves (Scenario and Value)
In cross-border e-commerce, one retail merchant runs fulfillment and settlement in LingXing ERP, while finance and warehouse teams prefer to book and review inside Kingdee Cloud Sky. Japan-site orders follow a separate settlement convention. If shipment settlement reports cannot be reliably written as sales outbound orders, the two systems drift apart and month-end closing becomes painful. This single strategy does one thing: take LingXing ERP shipment settlement reports tagged for the Japan site and write them into Kingdee Cloud Sky sales outbound orders, one shipment per outbound document, so both sides speak the same language.
Data Flow and Field Mapping (Source → Middle Layer → Target)
The overall flow is LingXing ERP → Qeasy Data Integration Platform (middle layer) → Kingdee Cloud Sky. The middle layer both transports and transforms: it reshapes LingXing conventions into what Kingdee can accept.
Key field mapping:
| Dimension | LingXing ERP (Shipment Settlement Report) | Middle Layer (Qeasy) | Kingdee Cloud Sky (Sales Outbound Order) |
|---|---|---|---|
| Document No. | Report ID / platform order No. | Passed through with site prefix | Document No. (unique within org) |
| Business Date | Settlement date | Use settlement date as-is | Business date |
| Customer / Channel | Store + platform order No. | Assembled as "Platform-Store" customer profile | Customer (matched by code) |
| Item Code | Platform SKU or MSKU | Centrally managed via code mapping | Material code |
| Quantity | Shipment quantity | Quantity + unit conversion handled together | Quantity (base UoM) |
| Warehouse | Fulfillment warehouse | Mapped against Kingdee warehouse | Issue/Receipt warehouse |
| Site Routing | Mixed sites | Filter: site = Japan | Japan only |
| Amount | Settlement currency and amount | FX converted to base currency | Total price including tax, base currency amount |
Site routing is the heart of this strategy: the Japan site must be sliced cleanly out of the global shipment settlement reports; nothing else should slip through.
How to Configure on Qeasy
We let the Qeasy Data Integration Platform host this strategy. In practice, four configuration lines matter most.
- Source retrieval: Connect to the LingXing ERP shipment settlement report endpoint, pull incrementally by settlement date, and keep a rerun window open.
- Filter and route: Add a hard filter
site = Japanat the Qeasy filter node. During testing, it is better to miss one than to let extras through. - Centralized code mapping: Master data such as items, customers, warehouses, and currencies is maintained in a single mapping table. When source SKUs are renamed, target codes stay stable. A common Qeasy customer pattern is to expose this mapping table as a dedicated configuration node so that future changes touch only one place.
- Write to Kingdee Cloud Sky: Call the sales outbound order API. The header and lines are submitted in two phases—write the header first to obtain the internal document ID, then post the line entries using that ID. This is a typical "header-then-lines" pattern that avoids oversized payloads timing out.
Implementation Steps
We usually split go-live into three phases and only move on once each one is stable.
- Validate the incremental starting point: Derive a starting date by looking back at historical data. Confirm that everything before this date has already been backfilled through the full-sync channel; only after that should incremental sync take over, otherwise duplicates or gaps appear.
- Full-sync trigger: One-shot backfill of historical Japan-site shipment settlement reports into Kingdee Cloud Sky, batch by batch. Once finished, switch to the incremental channel.
- Scheduling cadence: Japan-site shipments concentrate in daytime, so we recommend hourly schedules with an extra overnight rerun window to fix abnormal documents. Qeasy supports an "incremental plus full" dual-track pattern: incremental runs daily, and a monthly full reconciliation auto-triggers to keep both sides in sync.
Lessons Learned from Real Projects
- Never skip the site filter. A classic mistake is to sync all shipment settlement reports indiscriminately, turning the Japan-site strategy into a global strategy. The reliable approach is to place the filter at the most visible node and to maintain clear unit test cases.
- Do not assume currency and FX. The Japan-site settlement currency may not be CNY. The middle layer must define the FX source explicitly; otherwise outbound amounts will not match invoices.
- Do not scatter code mappings across scripts. Once scattered, the same SKU ends up encoded differently across three strategies, and data governance collapses. Centralized mapping tables are the standard Qeasy customer approach.
- Header/line submission order matters. Kingdee Cloud Sky is sensitive to the submission order of sales outbound orders. Submit the header first, then the lines, and capture the returned internal ID to wire the relationship; otherwise downstream references break.
- Incremental starting point drift. Inconsistent source-system time conventions cause the incremental window to drift. The safe approach is to record the last successful watermark explicitly; Qeasy supports advancing by business timestamp.
When to Use and When Not to Use
Use when: a single cross-border Japan-site settlement convention needs to be booked as sales outbound orders in Kingdee Cloud Sky; master data (items, customers, warehouses) already has mapping in place; daily volume ranges from thousands to tens of thousands of records; hourly sync windows are acceptable. Do not use when: multiple settlement conventions coexist, currencies switch frequently, reconciliation logic is complex, or strong-consistency real-time writeback is required—in those cases, use a real-time channel rather than scheduled sync.