Other Outbound Sync in Practice: From WMS to Kingdee
What This Strategy Solves
Every day, e-commerce warehouses generate a flood of inventory outflows that are neither sales nor purchases: samples leaving the building, promotional giveaways, internal requisitions, stocktaking losses. They never go through the sales order pipeline, yet they absolutely must reduce book inventory.
In one real project, a retail client logged sample requisitions in the warehouse management system while the finance team had to re-enter them manually in the ERP. Three days later the numbers no longer reconciled and inventory drift kept widening.
This strategy pushes Other Outbound documents (filtered by order_type=7) automatically from the warehouse side to the finance ERP — saved and immediately audited, inventory auto-deducted, books and stock aligned in real time.
Data Flow and Field Mapping
The data flow is straightforward and unidirectional: Other Outbound documents on the warehouse system travel through the Qeasy integration platform into the finance ERP's Other Outbound single. No business data is persisted in the middle — only format conversion and field transport.
| Dimension | Source (WMS) | → | Target (Finance ERP) | Note |
|---|---|---|---|---|
| Primary key | stockout_id | → | id | Internal unique ID |
| Business key | order_no (outbound order number) | → | bill_no (document code) | Business document number |
| Date | consign_time | → | bill_date | Document date |
| Business type | — | → | trans_type_id = "13" | Fixed value for Other Outbound |
| Operation type | — | → | operation_key = "audit" | Save and audit directly |
| Detail array | details_list | → | material_entity | One source row → one target row |
| Material code | details_list.goods_no | → | material_number | Passed through directly |
| Quantity | details_list.num | → | qty | Passed through directly |
| Unit price | details_list.price | → | price | Passed through directly |
| Amount | details_list.total_amount | → | amount | Passed through directly |
| Batch | details_list.batch_no | → | batch_no | Only when batch management is enabled |
| Valid date | details_list.expire_date | → | valid_date | Only when shelf-life is enabled |
Note that trans_type_id and operation_key are constants that do not exist on the source side — they must be filled in by the platform as fixed values. These two fields are the easiest ones to forget on first-time setup.
How to Configure on Qeasy
On customer sites we walk through four steps: build the source query, build the target writer, wire up field mapping, set the schedule.
Source side (WMS · Enterprise Qimen): pick API wdt.stockout.order.query, type QUERY, method POST, primary key stockout_id, business key order_no. Hard-code order_type as 7 in the request parameters — this is the key switch that filters Other Outbound documents. start_time uses {{LAST_SYNC_TIME}} and end_time uses {{CURRENT_TIME}}, which the platform fills automatically based on the last successful sync time.
Target side (Finance ERP V2): API is /jdy/v2/scm/inv_other_out, WebAPI type, method POST, primary key id, with IDCheck enabled to prevent duplicate pushes.
Field mapping: header fields are mostly DIRECT references. trans_type_id and operation_key use CONSTANT fixed values. details_list → material_entity is an entire array reference, and the target matches by material code automatically. No scripts are needed at the line level — all logic runs through configuration.
This is a typical "light scripts, heavy mapping" pattern we see across Qeasy customers: code mappings are managed centrally on the platform, headers and bodies are handled in stages, and material master data is kept consistent by other pipelines, so this strategy does not duplicate cross-lookups.
Implementation Steps
Stage 1 | Incremental starting point. First-time go-live requires a full historical backfill — on the source side, set start_time to the earliest historical timestamp and end_time to now, run once to populate all legacy Other Outbound documents. After that, the platform records LAST_SYNC_TIME and switches to incremental naturally.
Stage 2 | Full-volume run. Once historical data is backfilled, change start_time back to {{LAST_SYNC_TIME}} so that only new or changed records flow from this moment on. This incremental-and-full dual-rail handoff is the safe approach.
Stage 3 | Schedule frequency. Set the source cron to 3 2 * * *, which means run once daily at 02:03 — off-peak from payment settlement but before finance day-close. Set the target fallback cron to 23 2 * * * as a retry safety net.
Stage 4 | Joint verification. Walk through the verification checklist one item at a time: document number, date, trans_type_id=13, line quantity/amount, auto-audit pass, no duplicate documents.
Lessons from the Field
Pitfall 1 | Forgetting trans_type_id. The source system has no such field. Newcomers assume "whatever the source has, just pass it through" — the result is rejection on the ERP side or defaulting to sales outbound. Always assign "13" explicitly as a constant in the mapping.
Pitfall 2 | Material code mismatch. This strategy does not run _findCollection cross-lookups — it assumes the material codes are aligned on both sides. If the warehouse and ERP use different goods_no schemes, lookups will simply fail. The safe approach is to first establish a material master sync pipeline, then enable this strategy.
Pitfall 3 | Forgetting operation_key = audit. Without it, documents stay in "saved but unaudited" state, inventory is never deducted, and books drift from stock again.
Pitfall 4 | Incremental window too short. Setting the window to "past 1 hour" is common, but cross-night backfills get missed. Recommended window: at least 24 hours, with end_time pulled back a few minutes as a buffer.
Pitfall 5 | Misunderstanding the detail array reference. details_list → material_entity is an entire-array reference, not a per-field assembly. If you drop fields on the source side, the entire segment disappears on the target side. During joint testing, sample-test the empty-array and empty-field scenarios.
When It Fits and When It Does Not
Fits: e-commerce retail and wholesale businesses' sample/giveaway/internal requisition/stocktaking-loss outbound flows; warehouse and ERP material codes already aligned or maintained by another pipeline; scenarios where save-and-audit with auto inventory deduction is desired.
Does not fit: business that needs cross-lookups by warehouse, customer, or batch; large warehouse-vs-ERP code scheme gaps without a master data sync pipeline to back them up; sub-second real-time requirements — this strategy runs daily, so real-time needs call for an event-driven solution instead.