Syncing Other Outbound Orders from Jushuitan to Kingdee Cloud Galaxy: A Single-Strategy Tutorial
What This Strategy Solves (Scenario and Value)
In a real project at a retail company, the warehouse records a large number of "Other Outbound Orders" in Jushuitan every day—overages, write-offs, internal consumption, sample deliveries, and similar operations all flow through this single document type. On the accounting side, the company uses Kingdee Cloud Galaxy, and outbound orders must be posted according to Galaxy's coding rules and dimensions (warehouse, stock location, department, cost item); otherwise, monthly cost roll-up breaks.
On the surface, it looks like "pushing one document over." In practice, the two systems have entirely different coding schemes, document state machines, and mandatory dimensions. A common result: after the warehouse operator finishes a document, Galaxy either fails to create it, creates it but omits the cost item, or leaves it stuck in "Draft" and unable to enter the costing module. We use the Qeasy data integration platform to carry this strategy. The core value is to land Other Outbound Orders into Galaxy in a traceable, replayable, and observable way, so warehouse and finance are looking at the same numbers.
Data Flow and Field Mapping
The overall flow is a three-stage pipeline: Source System → Qeasy Middle Layer → Target System.
| Dimension | Jushuitan (Source) | Qeasy Middle Layer | Kingdee Cloud Galaxy (Target) |
|---|---|---|---|
| Document type | Other Outbound Order | Standardized document object | Other Outbound Order (business document) |
| Document number | Platform order no. | Original no. + sequence no. | Source no. / Document no. |
| Outbound date | io_date | ISO 8601 | Business date |
| Item code | sku_id | Item mapping table → item code | Item code |
| Quantity | qty | Numeric validation | Actual issue quantity |
| Warehouse | warehouse | Warehouse mapping table | Warehouse + stock location |
| Department / cost item | No explicit field | Default value + mapping rules | Department, cost item |
| Document status | io_status | State machine translation | Draft → Created → Approved |
How to Configure in Qeasy
We usually split the configuration into four blocks: source collection, transformation mapping, target write, and exception handling.
Source collection uses Jushuitan's "Other Outbound Order Query" interface. By default, data is pulled incrementally by modification time. All fields are kept in their original form in the middle layer—we avoid cleaning at the source.
Transformation mapping is where this strategy is most likely to go wrong. We typically centralize coding mappings in Qeasy's "Mapping Table" component—item codes, warehouse codes, and customer codes each get their own table, and all subsequent strategies (sales outbound, purchase inbound, transfer orders) share them. Headers and line items are processed in phases: the header first goes through mandatory-field validation, then line items are validated row by row for quantity and on-hand availability.
Target write calls Kingdee Cloud Galaxy's "Other Outbound Order—Save" and "Other Outbound Order—Approve" interfaces. The Qeasy connector is configured with Galaxy's organization and book environment (specific addresses are provided by the customer side and are not detailed here).
Exception handling must enable "retry on failure + dead-letter queue"—a single failed document must not bring down the entire batch task.
Implementation Steps
We recommend a three-phase rollout rather than jumping straight into full scheduling.
Phase 1: Incremental Start Point. First, pick a clean incremental start point—for example, "from a specific early morning." Pull only documents changed after that timestamp. The goal is to validate coding mappings and master data dependencies first, avoiding historical data interference.
Phase 2: Full Trigger. Once the coding mappings are stable, run a one-time full sync to backfill historical documents before the start point. This step should be batched by warehouse and date, with each batch kept at a reasonable size to avoid hitting the partner's API rate limits.
Phase 3: Steady-State Scheduling. After go-live, use a "dual track of incremental and full": incremental polling every 5-10 minutes handles real-time documents; a daily full sync runs during off-peak hours to re-process the previous day's window as a reconciliation safety net, catching missed documents and missed lines.
Each Qeasy scheduled task should have a clear crontab and corresponding alert channels (enterprise WeChat / DingTalk / email), so on-duty engineers see failure details immediately.
Pitfall Recap
Pitfall 1: Coding mappings are not centralized. Early on, we hard-coded mappings into each strategy. After 3 months, "Item Sync," "Other Outbound Sync," and "Sales Outbound Sync" each had their own copy, and the numbers no longer matched. The safe approach is to route item, warehouse, and customer coding through Qeasy mapping tables with unified maintenance.
Pitfall 2: Header validated, line items skipped. In Galaxy, the line-item "cost item" is mandatory, but Jushuitan does not carry this field. We initially validated only headers, leaving many documents stuck in "Draft." Now line items are validated row by row, with default values applied via Qeasy's "auto-fill by warehouse" rule.
Pitfall 3: Wrong incremental start point. Picking "system go-live day" as the start point seems safe, but all historical documents are lost, and Galaxy's inventory opening balance doesn't match. The safe approach is to perform a "dual-system reconciliation" before go-live and set the start point based on that.
Pitfall 4: Ignoring partner rate limits. A one-time full sync can easily knock out Galaxy's API. We later parameterized batch size and interval, adjusting dynamically based on the partner's API behavior.
Pitfall 5: Retries causing duplicate postings. Without an idempotency key, network-jitter retries produced duplicate documents in Galaxy. We then use "source document number" as the idempotency key in Qeasy, querying before writing to avoid duplicate posting.
Applicable and Non-Applicable Scenarios
Applicable: Retail or trading companies with multiple organizations and warehouses that need stable posting of Jushuitan's daily outbound documents into Kingdee Cloud Galaxy for cost accounting by document dimension.
Not applicable: Pure manufacturing companies' shop-floor issue operations (Kingdee's production issue document is more appropriate), and scenarios requiring true real-time sub-second sync where latency is extremely sensitive (Qeasy's standard scheduling is minute-level; second-level sync requires a dedicated streaming approach).