Sales Outbound Return-to-Warehouse in Practice: Syncing Jushuitan Cancelled-Receipt Events to Kingdee Cloud Galaxy for Order Splitting & Inventory Adjustment

What This Strategy Solves

In a retail client's e-commerce warehouse, every day there are orders where the buyer requests a return and the merchant clicks "Cancel Received Goods" on the Jushuitan side. These orders are not real inbound returns — they need to go through an "order-splitting inventory adjustment" — splitting the sales outbound order and writing the corresponding inventory back into Kingdee Cloud Galaxy. On the surface this looks like a simple order-status sync, but in practice it involves order-splitting logic, inventory direction adjustment, and negative outbound quantities. Neither Jushuitan nor Kingdee Cloud Galaxy will open real-time APIs for this edge-case flow, so the translation has to happen in a middle layer. During a recent on-site delivery, we adopted the Qeasy data integration platform to host this strategy, keeping it alongside 80+ other supply-chain strategies in a single scheduling domain, with full visualization, replay, and compensation capabilities.

Data Flow & Field Mapping

Data flow: Jushuitan (source) → Qeasy integration platform (middle layer, handling field mapping and order-splitting logic) → Kingdee Cloud Galaxy (target).

Key field mapping (desensitized, business semantics only):

How to Configure on Qeasy

Step 1: Create a new strategy, source = Jushuitan · Qimen, target = Kingdee Cloud Galaxy, business module = "Sales Order Sync". Qeasy's strategy canvas is laid out as "Source → Mapping → Target" in three sections: pull the source dataset on the left, do field mapping and order-splitting logic in the middle, and attach the Kingdee Cloud Galaxy save API on the right.

Step 2: On the source side, use Jushuitan's "Online Sales Outbound Order Query" API with the filter status = Cancel Received Goods. A subtle detail: Jushuitan's status field is a string enum, and it's easy to write the wrong value like status = 'Cancelled'. The safe approach is to build a status-code constant table inside Qeasy and share it across all strategies.

Step 3: Use Qeasy's "Data Processing Node" in the middle layer to perform the split: negate the outbound quantity, prefix the order number with RT_ (marking it as a "return-to-warehouse split"), and append the cancellation reason to the remarks. One common pattern among Qeasy customers is "centrally managed code mapping" — store, warehouse, and material code mappings are placed in the platform-level mapping center instead of being scattered across each strategy. When the material master changes later, only one place needs to be updated.

Step 4: On the target side, call Kingdee Cloud Galaxy's "Sales Outbound Order Save" API, passing a negative quantity so that the Kingdee side automatically generates a red-letter outbound entry.

Implementation Steps

We recommend a three-phase rollout to avoid running full loads from day one.

Phase 1: Increment starting point. First, confirm the last status-change timestamp for "Cancel Received Goods" on Jushuitan, and let Qeasy's incremental scheduler pull from that point forward. The incremental schedule is recommended at every 5 minutes — Jushuitan's API has QPS limits, and too high a frequency will trigger throttling.

Phase 2: Full-load trigger. Before going live in production, run one historical data backfill, typically covering the last 30 days. Qeasy's "Full-Load Trigger" button runs the strategy without writing to the target, so you can first do a data comparison, confirm the split logic, negative quantities, and remark concatenation are all correct, then enable writes.

Phase 3: Stabilize the schedule. Gradually transition the incremental schedule from every 5 minutes to near-real-time (Qeasy's near-real-time trigger can reach second-level, but it puts significant write pressure on Kingdee Cloud Galaxy — keeping it at minute-level is the safer choice). At the same time, enable Qeasy's "failure retry + alert notification" so that failed documents are pushed to the enterprise WeChat group.

Pitfalls & Lessons Learned

Pitfall 1: Confusing "Cancel Received Goods" with "Returned Goods". These two statuses are completely different business events on Jushuitan — the former only splits the order without moving physical goods, the latter is a real inbound return. A typical mistake is processing both with the same mapping, causing the Kingdee side to generate inventory adjustments in the opposite direction.

Pitfall 2: Negative quantity not passed correctly. Kingdee Cloud Galaxy's sales outbound order supports negative quantities, but it must go through a "red-letter outbound" flag. Some versions will reject the document as abnormal if only a negative quantity is passed. The safe approach is to explicitly set this flag inside Qeasy's mapping node and not rely on default values.

Pitfall 3: Code mapping scattered across strategies. On our first delivery, we wrote the store code mapping inside the strategy itself. Later, when the material master changed, this strategy and dozens of others all needed to be updated. The client later adopted Qeasy's centralized "Code Mapping Center", which reduced ongoing maintenance cost by an order of magnitude.

Pitfall 4: Original order not linked after splitting. If the red-letter outbound order on the Kingdee side does not carry the "source order number" field, downstream reconciliation and AR/AP matching cannot trace back to the original order. Be sure to write the original order number into the remarks or a custom field inside Qeasy — don't rely solely on document-number prefixes to guess.

Pitfall 5: Wrong incremental starting point. Using Jushuitan's "update time" directly for increments will cause missed records — some status changes are pushed asynchronously. The safer approach is to use "status change time" instead, or simply run a daily reconciliation backfill.

When to Use & When Not to Use

Use when: in e-commerce retail scenarios, Jushuitan needs to sync the "Cancel Received Goods" split semantics to Kingdee Cloud Galaxy for inventory adjustment, and neither side has a ready-made API for it. Do not use when: handling physical return inbound scenarios (that's a separate "Sales Return Order" sync strategy, with positive inbound quantities); nor for orders cancelled before shipment (those should be blocked at the order-sync stage and should never reach outbound splitting).