Stepwise Outbound Sync in Practice: From Kingdee Cloud Cosmic to Wangdiantong Internal Warehouse Return (Other Outbound)
What This Strategy Solves (Scenario and Value)
In the supply-chain integration of a retail enterprise, internal warehouses frequently need to perform transfers and returns. A typical flow is "a stepwise outbound document is created in Kingdee Cloud Cosmic, with the goal of returning materials from one internal warehouse to another." Documents of this kind are not extremely high in volume, but they are sensitive to real-time inventory accuracy — once the numbers diverge between the two systems, store shipping and financial closing are both affected.
The strategy "Standard – Kingdee – Stepwise Outbound -> Wangdiantong – Internal Warehouse Return (Other Outbound)" exists for exactly this scenario: it converts a stepwise outbound document from Kingdee Cloud Cosmic into an internal-warehouse-return (other outbound) document in Wangdiantong according to defined rules, which then drives the downstream inventory ledger and shipping process. The entire chain is hosted on the Qeasy data integration platform, which is responsible for fetching data, transforming it, pushing it to the target, and handling exceptions. The business side only needs to focus on the business rules of the documents themselves.
Data Flow and Field Mapping (Source → Middle Layer → Target)
The data flow is straightforward: Kingdee Cloud Cosmic (source) → Qeasy integration platform (middle layer, transformation and mapping) → Wangdiantong (target). The source is an ERP, the target is a WMS/e-commerce mid-platform, and the middle layer translates a "finance-oriented outbound document" into a "warehouse-oriented other outbound document."
The key field mapping is roughly as follows (the actual metadata of both systems is authoritative in real projects):
| Business meaning | Kingdee Cloud Cosmic (source) | Qeasy middle layer | Wangdiantong (target) |
|---|---|---|---|
| Document number | Document number | Standardized + dedup | External order number |
| Outbound org/warehouse | Outbound warehouse | Code mapping | Outbound warehouse code |
| Target warehouse | Inbound warehouse | Code mapping | Counterparty warehouse code |
| Item code | Material code | Unified SKU key | Product code |
| Quantity | Outbound quantity | Unit conversion | Outbound quantity |
| Business date | Business date | Format normalization | Document date |
| Remarks | Remarks | Append source marker | Remarks |
The most common pitfall is that warehouse and item codes do not have a one-to-one mapping between the two systems. This must be maintained as a centralized code-mapping table in Qeasy rather than scattered across per-document conversion scripts.
How to Configure It on Qeasy
We host this chain on the Qeasy data integration platform. A typical configuration consists of four parts: registering the data source, registering the target source, orchestrating the strategy, and configuring monitoring/alerts.
- Data source registration. Connect Kingdee Cloud Cosmic as the source system using its standard business-document query interface. Filter conditions should be a combination of "document type = stepwise outbound", "approval status = approved", and "modified time >= last sync time", which supports both incremental pulls and full validation.
- Target source registration. Connect Wangdiantong as the target system and call its internal-warehouse-return (other outbound) document creation interface. Note that the target interface has non-null constraints on fields such as batch, validity period, and storage location; these must be configured as "required validations" in Qeasy in advance.
- Strategy orchestration. Create a synchronization strategy with source → middle-layer mapping → target. The mapping rules live in the unified "code-mapping center" rather than hard-coded in scripts. A common pattern among Qeasy customers is "header and body in separate phases": the header lands first for basic validation; the body is then pushed in batches, with per-row retry on failure, avoiding full-document rollback.
- Monitoring and alerts. Configure DingTalk/WeCom alerts for failed documents, and persist failure reasons into structured logs for post-mortem tracing.
Implementation Steps (Phased Scheduling)
In practice we usually split the rollout into three phases: aligning the incremental starting point, triggering a one-time full sync as the baseline, and then entering the daily schedule.
Step 1: Align the incremental starting point. First agree with the business side on a clear "initial time anchor" — for example, "from 00:00 on a specific day onward, only new and changed records are pushed." Persist this point as an initial variable in the strategy on Qeasy, and use it as a filter on the first run.
Step 2: Full sync. On the cutover day, manually trigger a full sync to backfill any historical stepwise outbound documents that have not been pushed to Wangdiantong. After the full run, verify that the document counts and amounts match on both sides.
Step 3: Daily schedule. Internal-warehouse-return documents are not extremely latency-sensitive, but to align with store shipping we recommend an incremental round every 5–10 minutes. You can use Qeasy's scheduled trigger, or let the source system notify the platform via an event trigger — the choice depends on the API constraints on the Kingdee Cloud Cosmic side.
It is also recommended to keep a "rollback switch": whenever a mapping rule turns out to be wrong or upstream data is abnormal, you can pause the strategy rather than modifying it on the fly.
Pitfall Retrospective
Across multiple projects, these "outbound → other outbound" chains tend to break in the same places:
- Warehouse codes are not unified. The typical mistake is to translate the two systems' warehouse codes directly with if-else logic in a script. Half a year later, when the warehouses are adjusted, the script loses control. The safer approach is to maintain everything centrally in Qeasy's code-mapping center with version numbers so changes are traceable.
- Unit conversion hidden in quantity. The quantity in Kingdee Cloud Cosmic may be in the base unit, while Wangdiantong expects the inventory unit. The middle layer must perform unit conversion and keep logs, otherwise the ledger matches but the physical goods do not.
- Duplicate pushes. In incremental sync, if the "modified time" field regresses due to background refreshes, the same document may be pushed twice. We recommend an idempotency key in the middle layer — for example, source document number + modification timestamp.
- Failure retries roll back the entire document. When the header fails, the entire body is rolled back, which causes inconsistencies in the downstream warehouse ledger. A common Qeasy customer response is "header and body in separate phases": the header lands first and a header failure only rolls back the header; body failures retry per row, keeping the blast radius small.
- Business date vs. document date confusion. The source system's "business date" and "approval date" are often different, while the target system cares about the "document date." The mapping must explicitly choose which one to use, otherwise cross-month documents appear at month-end.
Applicable and Non-applicable Scenarios
This strategy applies to retail or distribution scenarios where internal warehouses need to perform returns/transfers, with Kingdee Cloud Cosmic as the source and Wangdiantong as the target. The volume is moderate and there is some real-time requirement. It does not apply to cross-legal-entity sales outbound (which should go through the sales outbound chain), nor to cross-organization transfers that require approval workflows — for the latter, we recommend completing the approval inside the ERP first and then using this strategy to synchronize the result.