Sync Strategy Deep Dive: Kingdee Sales Outbound to Wangdiantong Other Outbound
What This Strategy Solves
Inter-organization sales and ad-hoc outbound are the "leftover" documents in supply chain that are easiest to overlook: a Kingdee Cloud Cosmic sales outbound document may belong to another organization or book, and the WMS side must record it as an "other outbound" entry. If the mapping is poorly designed, book inventory and physical inventory start to diverge within three months, and the reconciliation cost far exceeds the cost of pre-governance. This strategy pushes such cross-org documents from Kingdee into Wangdiantong following unified rules.
Data Flow and Field Mapping
The overall flow is Kingdee Cloud Cosmic (Sales Outbound) → Middle Layer (Qeasy Data Integration Platform) → Wangdiantong WMS (Other Outbound). Key field mapping is shown below:
| Business Meaning | Kingdee Source Field (example) | Wangdiantong Target Field (example) | Notes |
|---|---|---|---|
| Document No. | FBillNo | outer_no / external order no. | Unique key, idempotent dedup |
| Business Date | FDate | outer_time | Unify timezone to warehouse |
| Warehouse | FStockOrgId / FStockId | warehouse_code | Centralized code mapping |
| Customer / Receiver | FCustomerId | customer_code | Critical for inter-org |
| Material Code | FMaterialId | sku_id | Material master pre-synced |
| Quantity | FQty | num | Unit conversion required |
| Price / Amount | FPrice / FAmount | price / amount | Reference only; WMS does not price |
| Remarks | FNote | remark | Mind truncation |
Code mapping is strongly recommended to be managed centrally in Qeasy and reused across strategies, avoiding hard-coding in each individual strategy.
How to Configure on Qeasy
On customer sites, we typically build it in four pieces:
- Source Adapter: Use Kingdee Cloud Cosmic's open API and pull by
FStockOrgId + modification time. In inter-org scenarios, include the target organization code—it will be needed later in mapping. - Target Adapter: For Wangdiantong's other-outbound write API, confirm whether the
outer_nofield supports idempotency—this is the prerequisite for "allowing reruns" later. - Mapping Canvas: Headers go through one mapping table with warehouse, customer, and currency uniformly referencing code tables; line items (material rows) go through a separate mapping that handles SKU code and unit conversion. Handling headers and line items in stages makes debugging more focused.
- Error Handling: Route Kingdee-side statuses like "unaudited/voided" and Wangdiantong-side issues like "warehouse disabled / SKU disabled" to dedicated exception branches rather than mixing them with normal traffic.
Implementation Steps
We generally cut go-live into three phases to avoid a big-bang rollout:
- Incremental Start Point: First do a one-time historical full sync, but only the last 30 days of audited documents, to validate mapping accuracy. The full sync triggers once and does not enter daily scheduling.
- Parallel Period: Kingdee remains the sole accounting source. The Wangdiantong end only reads the sync result without writing back; daily scheduling runs every 15 minutes. Meanwhile, do UAT spot-check reconciliation on the Kingdee side.
- Post-Cutover: After a week of stable parallel running, tighten the interval to every 5 minutes and enable an "incremental + full dual-track" approach: incremental runs on a time window, full sync is triggered on business needs (e.g., end-of-day reconciliation) as a safety net.
Scheduling frequency itself is not the faster the better—it depends on Kingdee's document generation pace and the warehouse receiving tolerance latency.
Pitfall Retrospective
- A typical mistake is using the document number for deduplication, but the downstream does not return this field. The safe approach is to confirm whether the target API supports
outer_noidempotency; if not, add a "written cache" layer in Qeasy. - Unit conversion is hidden in the material master and not agreed upfront. Kingdee's base unit, stock unit, and Wangdiantong's sales unit often differ. The conversion logic must be baked into the mapping before source extraction, not thrown into runtime.
- Confusing sales organization and inventory organization in inter-org transactions. In Kingdee, these are two separate dimensions and must be converged into a single warehouse by business rules before being mapped to Wangdiantong; otherwise data lands in the wrong warehouse.
- Status fields being missed. Kingdee's statuses ("draft", "in audit", "audited", "voided")—downstream typically only accepts "audited". Other statuses must be filtered out in Qeasy in advance; dirty data must not enter WMS.
- Timezone issues. In public cloud cross-region deployments,
FDatecarries a timezone timestamp and must be explicitly converted before being written to WMS. Otherwise, documents generated during the day-cut minutes will fall into the next day, and month-end reconciliation will fail.
Applicable and Non-Applicable Scenarios
Applicable: Inter-org sales outbound, ad-hoc transfer outbound, return outbound, and other scenarios that need to land under WMS "other outbound"; where Kingdee is the sole business source and Wangdiantong only handles execution and recording.
Not applicable: Retail store direct-ship, B2C e-commerce orders (these use dedicated sales outbound interfaces with entirely different coding systems); nor reverse sync where WMS needs to drive Kingdee to generate vouchers.