Cross-System Sales Outbound Sync in Practice: Kingdee Cloud Galaxy → Wonderstore Flagship

What This Strategy Solves (Scenario and Value)

Many retail enterprises use Kingdee Cloud Galaxy for finance and supply chain on the backend, and Wonderstore Flagship Edition for stores and e-commerce warehouses. When a sale completes its outbound process on the Kingdee side, the available inventory on the Wonderstore side does not automatically refresh, which easily leads to overselling or distorted availability at the store fulfillment stage.

This strategy writes Kingdee Cloud Galaxy's "Sales Outbound Document" into Wonderstore's "Other Inbound Document" according to mapping rules, keeping the inventory views on both sides consistent. In one actual project, we used the Qeasy data integration platform to take on the entire chain, encapsulating the one-way sync as a schedulable and observable strategy unit. After running for a period, the inventory differences between the two sides were basically eliminated.

Data Flow and Field Mapping (Source → Middle Layer → Target)

The data flow is unidirectional B_TO_A: Kingdee Cloud Galaxy (source B) → Qeasy middle layer → Wonderstore Flagship Edition (target A). The middle layer is responsible for fetching, cleaning, mapping, filling default values, and then pushing in batches to the target side.

Key field mapping:

How to Configure on Qeasy

Step 1, register two data sources in the Qeasy data integration platform: Kingdee Cloud Galaxy (private deployment) and Wonderstore Flagship Edition. The private environment is accessed via leased line or VPN, and accounts are managed through key escrow, not written directly in scripts.

Step 2, establish centralized "code mapping" management. We put the mapping relationships of master data such as products, warehouses, and customers into a mapping table, maintained by dedicated operations personnel. This way, when stores or SKUs are adjusted later, only one place needs to be changed and won't be scattered across multiple strategies. This is one of the very common practices among Qeasy customers.

Step 3, configure source system data fetching: call Kingdee Cloud Galaxy's sales outbound document query interface, incrementally fetch by "last modified time", and add the filter condition "audit status = audited" to avoid pushing draft documents.

Step 4, middle layer transformation: header and body are processed in phases. The header first does basic field filling and default value completion, then handles the body line items. The benefit of phased header and body processing is faster error localization — document-level validation is placed in the header phase, and line-item-level validation in the body phase.

Step 5, configure target system writing: call Wonderstore Flagship Edition's other inbound document creation interface. After successful writing, write back the external order number mapping of the source document for idempotency and reconciliation.

Step 6, configure exception handling: failed retries use exponential backoff, and after exceeding the threshold, enter the alarm channel. This is where the strategy's companion "DingTalk Error Alert" strategy comes into play.

Implementation Steps

We usually roll out in three phases:

Phase 1: Incremental Starting Point. First use historical data to initialize the mapping table and basic data, then switch the strategy to incremental mode with a scheduling frequency of every 15 minutes. The key to the incremental starting point is anchoring the starting timestamp at a specific moment to avoid duplicate or missed pushes.

Phase 2: Full Trigger. When switching stores or doing large-scale initialization, a full supplement push is needed. The safe approach is to run a separate full task, then return to incremental. Running full and incremental on dual tracks is one of the common response patterns of Qeasy customers, avoiding full tasks blocking daily business.

Phase 3: Stable Operation. The scheduling frequency gradually converges to a business-acceptable window (e.g., every 30 minutes), and a "dynamic adjustment by business time period" strategy is added, reducing frequency during non-business hours. At the same time, enable reconciliation reports to check quantity differences between both sides daily.

Pitfall Review

Pitfall 1: Directly using Kingdee's internal code as the Wonderstore goods number. It seems to save effort, but three months later the two sides don't match because the master data systems on both sides are completely different. The safe approach is to build a centralized mapping table, maintained by dedicated personnel.

Pitfall 2: Also pushing draft and unaudited documents. A typical mistake is not adding the audit status filter, resulting in a bunch of "phantom inbound" on the Wonderstore side. This is easy to crash; the filter condition must be written.

Pitfall 3: Handling header and body all at once. When there are many fields, it gets chaotic, and when there's an error, you don't know which row and which field has the problem. After phased processing, problem localization drops from hours to minutes.

Pitfall 4: Ignoring unit conversion. The Kingdee side may be in cases, while the Wonderstore side needs pieces. If there's no conversion, the quantity will double or shrink. Unit fields must be explicitly handled in the middle layer.

Pitfall 5: Not doing idempotent writeback. After network jitter retries, duplicate documents will be generated. Writing back the external order number mapping and doing deduplication on the source side is basic.

Applicable and Non-Applicable Scenarios

Applicable: After sales outbound, the front-end system (Wonderstore Flagship Edition) needs to sense inventory changes, avoid store overselling, and scenarios requiring consistent bidirectional visibility for retail and e-commerce warehouse fulfillment.

Not applicable: Scenarios requiring real-time second-level synchronization (should use message queues instead of timed sync), source documents frequently voided without audit, or scenarios where master data on both sides has not been aligned before forced sync.