WMS Other-Outbound to Kingdee Other-Outbound: A Practical Inventory Sync Strategy Built on Qeasy
What this strategy solves
In a retail warehouse-and-distribution scenario, the warehouse side (referred to here as the source system) generates a large number of Other-Outbound documents every day — transfers, material issues, scrapping, and sample shipments all flow through this document type. These documents must land in the Other-Outbound document on the Kingdee side so that finance and inventory accounting share a consistent basis. We use the Qeasy Data Integration Platform to handle this strategy. The core goals are only three: aligned document types, consistent inventory direction, and traceable coding and organization mappings.
Data flow and field mapping
The overall flow is one-way: source system → Qeasy middleware → target system. The middleware is responsible for cleaning, mapping, backlogging, and retries.
| Business field | Source (Other-Outbound) | Middleware processing | Target (Other-Outbound) |
|---|---|---|---|
| Document No. | Source doc no. | Pass-through with prefix to avoid duplicates | Target doc no. |
| Document type | Business type code | Dictionary mapping | Target business type code |
| Business org | Warehouse's organization | Organization mapping table | Target business org code |
| Inventory org | Warehouse code | Warehouse → inventory org mapping | Target inventory org code |
| Owner type | Owner category | Dictionary mapping | Target owner type |
| Item code | Source SKU | Coding mapping table (centrally managed) | Target material code |
| Quantity | Outbound qty. | Unit conversion | Base-unit qty. |
| Remarks | Source remarks | Truncate/merge | Target remarks |
Note: the document header and document body must be processed in phases in the middleware. The header lands first, the body is pushed line by line, and failed lines are written to a separate exception table to prevent one failed row from breaking the whole document.
How to configure it on Qeasy
We configure this strategy as a separate integration flow on the Qeasy Data Integration Platform. The typical configuration points are:
- Source connector: Use the built-in source adapter to pull Other-Outbound documents by document type, with the increment field being the document's last-modified timestamp.
- Target connector: Connect to the target system, write to the standard Other-Outbound interface, and configure save and approval actions.
- Code mappings: Manage the four mapping types — item, organization, warehouse, and type — in Qeasy's Mapping Management module so they are centrally maintained. The most common approach on customer sites is to centralize code mappings so that SKU or organization changes only need to be made in one place.
- Header and body in phases: Write the header first, then write the body line by line. Failed lines go to an exception queue and are re-driven after manual or scripted compensation.
- Notifications: Send alerts via enterprise IM or email when the backlog exceeds a threshold or there are consecutive failures.
- On-premise note: Adapters, the middleware database, and scheduling services all run on the intranet. The network egress must be whitelisted to the source and target system interface addresses.
Implementation steps
We recommend a three-step rollout to production for this strategy.
Step 1: Trigger a full sync to align the baseline Before the first go-live, manually trigger a full sync in Qeasy so that both sides align on a historical baseline. Do not run incremental sync in parallel during the full sync to avoid duplicate documents.
Step 2: Enable incremental sync and set the schedule After the baseline is aligned, switch on incremental mode. A common practice at customer sites is the "incremental plus full dual-track" approach: run an incremental every 5–10 minutes as the safety net, and run a small-window full sync once a day in the early morning to verify nothing is missing.
Step 3: Stabilize and move into operations Observe for 1–2 weeks. Track success rate, backlog size, and exception rate. Categorize high-frequency exceptions into a knowledge base and periodically audit the code mapping tables.
Pitfalls recap
- Code mappings are not centrally managed: A typical mistake is that each business line maintains its own mapping table, and three months later the numbers on both sides no longer match. The safe approach is to maintain a single mapping table in Qeasy's mapping center, shared by all related strategies.
- Unit conversion is ignored: The source uses "box" while the target needs "base unit". This is where things often go wrong. Always perform explicit unit conversion in the middleware; never assume both ends agree.
- Header failure causes the entire document to be lost: Do not put the header and body in a single transaction. If the header fails, only roll back the header. The body should be committed line by line, with failed lines going to an exception table.
- Wrong field chosen as the incremental start point: Using last-modified time as the increment field is common, but for some documents the field no longer changes after approval, which causes missed documents. It is recommended to also pull a small window of "recent N days" as a safety net.
- Inventory direction is reversed: Other-Outbound on the source side decreases inventory. The direction must be made explicit when pushing to the target — choosing the wrong type can turn it into an inbound document, and the books become more and more inconsistent.
When this applies and when it does not
Applicable: non-sales outbound documents such as transfers, scrapping, material issues, and sample shipments in single- or multi-warehouse setups that require daily inventory reconciliation. Not applicable: cross-entity or cross-accounting-period complex carry-forwards, or scenarios requiring manual approval workflow — those should be handled by a workflow, not a pure document sync strategy.