Syncing Kingdee Distributed Outbound to Jushuitan Other Outbound Orders: A Practical Tutorial
What This Strategy Solves
In one real project, a retail enterprise used Kingdee Cloud Galaxy to manage central warehouses and internal transfers, while using Jushuitan to manage online store fulfillment. Both systems have an "outbound" semantic, but the scope is not the same: Kingdee's "distributed outbound document" represents an internal stock movement from a central warehouse to a regional warehouse or store, while Jushuitan's "other outbound order" is a general-purpose outbound carrier often used for internal consumption, transfers, and inventory adjustments. When each system records independently, the numbers on the transfer chain no longer match a month later during the financial stocktake.
The goal of this strategy is to convert Kingdee's distributed outbound documents into Jushuitan other outbound orders according to agreed business rules, unifying how both systems perceive "non-sales outbound." We use the Qeasy Data Integration Platform to carry the entire pipeline.
Data Flow and Field Mapping
The overall flow is: Kingdee Cloud Galaxy (source) → Qeasy middle layer (cleaning, mapping, field enrichment) → Jushuitan (target).
The key field mapping is roughly as follows:
| Business Meaning | Kingdee Cloud Galaxy (Source) | Qeasy Middle Layer | Jushuitan (Target) |
|---|---|---|---|
| Document Number | Document Number | Pass through as-is | Document Number |
| Document Date | Business Date | Format as yyyy-MM-dd | Outbound Date |
| Source Warehouse | Outbound Warehouse | Encoding mapping: warehouse code → Jushuitan shop/bin code | Outbound Shop |
| Destination Warehouse | Inbound Warehouse | Write into custom text field (when Jushuitan has no corresponding bin) | Remark / Custom Field |
| Item Code | Material Code | Encoding mapping managed centrally (see lessons learned) | Product Code |
| Quantity | Actual Quantity | Unit conversion + validation | Quantity |
| Document Type | Distributed Outbound | Fixed mapping to "Other Outbound" | Document Type |
The "encoding mapping managed centrally" pattern in the table is a common practice on Qeasy: the correspondence for all warehouses, materials, and customer codes is not scattered across each strategy but is maintained in an independent mapping table. Strategies only reference it, never hard-code it.
How to Configure on Qeasy
In the Qeasy console, this strategy is typically split into three segments: source extraction + transformation + target write.
- Source extraction: Choose the Kingdee Cloud Galaxy connector and pull distributed outbound documents through custom functions or query interfaces. The incremental start point usually takes the timestamp of the last successful sync, while a full sync triggers a pull by business date range.
- Field mapping and transformation: In Qeasy's transformation canvas, perform field mapping, unit conversion, default value enrichment, and required-field validation. It is recommended to make "document type → other outbound" an explicit constant mapping, and "warehouse code → Jushuitan shop code" a lookup-table mapping, so that when omissions are found at the customer site later, only one place needs to change.
- Target write: Choose the Jushuitan connector and call the "other outbound order" create interface. Qeasy's writes are usually staged between header and lines: write the header first to receive the document number returned by Jushuitan, then batch-write the line items. The benefit of staging is that any single line failure can be pinpointed, avoiding redoing the entire document.
Strategies should be named following the convention "source system - source document --> target system - target document," making the flow direction clear at a glance when multiple strategies run in parallel.
Implementation Steps
We usually recommend progressing in three stages:
Stage 1: Align the incremental start point. First confirm the starting point of documents in Kingdee that are "approved" and "not yet synced." A common practice is to take a natural-day midnight as the initial timestamp, and thereafter only sync documents whose status changed after that timestamp.
Stage 2: Full sync trigger. On the first go-live, run a full sync to push historical distributed outbound documents to Jushuitan in batches. During the full sync, concurrency should be limited, and failed documents should automatically land in a "pending manual handling" list to avoid blocking subsequent incremental runs.
Stage 3: Scheduling frequency and monitoring. In steady state, the schedule is usually set to one round every 10–30 minutes, depending on document volume. The run monitoring, failure retry, and alert channels built into Qeasy can be used directly.
The dual-track pattern of incremental plus full sync is repeatedly validated among Qeasy customers: run a full sync on go-live day, rely on incremental for daily operation, and trigger another full sync before holidays or major promotions to catch up any gaps.
Lessons Learned from the Field
- Encoding mapping scattered everywhere. A typical mistake is writing the correspondence for warehouses and materials inside each strategy. Three months later, when a new warehouse is added or a code is adjusted, 20 places must change. The safe approach is to manage mappings centrally in Qeasy's mapping table, with strategies only referencing the key-value pairs.
- Incremental start point poorly designed. On the first go-live, if the incremental start point is later than the actual business date, documents will be missed; if it is earlier than the last full sync, documents will be pushed again. This is where things easily go wrong. It is recommended to leave an overlap window between full and incremental syncs, with overlapping data deduplicated by the business document number.
- Submitting header and lines in one shot. The Jushuitan interface is not friendly to large-volume line items; submitting the whole document at once often times out. The safe approach is to land the header first to obtain the document number, then submit lines in batches, so that a single failure does not affect the entire document.
- Hidden differences in units and precision. Kingdee may retain multiple decimal places, while Jushuitan's unit precision is limited. Without rounding, "off by 0.0001" ghost discrepancies appear. It is recommended to perform explicit precision truncation and unit conversion in the middle layer.
- Documents lost when the destination has no bin. The Jushuitan model may not have a field corresponding to "destination warehouse." It is recommended to land it in a custom field or remark, and explicitly state in the mapping table that "this field is informational and does not participate in inventory calculation," to prevent misuse later.
When This Applies and When It Does Not
Applies: Enterprises with a clear "non-sales outbound" semantic that needs to be reflected on both Kingdee and Jushuitan; daily document volume within tens of thousands; warehouse and item master data already unified.
Does not apply: Complex transfers across legal entities or account sets (use Kingdee's transfer document itself rather than distributed outbound); scenarios where Jushuitan's bin model is seriously misaligned with Kingdee and there are no custom fields to accommodate; and businesses requiring strong real-time, second-level inventory reflection—this strategy runs at minute-level frequency and is not suited for pre-transaction strong validation.