Sync Other Outbound Stock from Jushuitan to Kingdee Cosmic Star: Field Mapping and Scheduling Pitfalls
What This Strategy Solves
In one retail project we kept hearing the same complaint: warehouse and finance couldn't reconcile. Other outbound stock events (transfers, material issues, write-offs) recorded in the ERP-side system often didn't appear in the finance-side inventory ledger until half a day later, and the gaps only surfaced at month-end. This strategy pushes those non-sales outbound documents, incrementally by business time, so both sides share one traceable stock flow.
Data Flow and Field Mapping
The overall flow is ERP-side → Middle Layer → Finance-side. The middle layer's job is to translate "e-commerce language" into "finance language."
| Business meaning | Source field (example) | Middle layer handling | Target field (example) |
|---|---|---|---|
| Document No. | io_num | Pass-through | Document No. |
| Outbound type | io_type_code | Dictionary mapping | Business type |
| Warehouse | warehouse | Code mapping table | Warehouse code |
| Item code | sku | SKU ↔ material mapping | Material code |
| Quantity | qty | UoM conversion | Quantity |
| Price / Amount | price, amount | Recalculated per target rules | Price, Amount |
| Business date | io_date | Pass-through | Business date |
| Remarks | remark | Pass-through | Remarks |
Centralized mapping management is a common pattern among Qeasy customers: all SKU ↔ material, warehouse ↔ warehouse code, and shop ↔ customer mappings live in one mapping table, so adding a new warehouse or SKU means changing the table, not the strategy.
How to Configure in Qeasy
Within the Qeasy data integration platform, this strategy lives under the business-document category. Key configuration points:
- Source registration: pull "other outbound stock" from the ERP-side open API; write to the finance-side document API.
- Trigger: use the document's last-update timestamp as the incremental cursor; perform an initial full pull to establish a baseline, then push only deltas.
- Field mapping: configure the table above in Qeasy's mapping canvas, where type conversion and null-value fallbacks are handled.
- Pre-write validation: check whether the target warehouse is enabled and whether the material exists and is enabled; otherwise the write fails and Qeasy auto-retries and tags the record.
- Exception branch: a single failed document does not fail the whole batch—Qeasy lands failed documents in an error table for manual remediation.
Implementation Steps
A staged rollout is the safe path:
- Stage 1 — Baseline full sync: manually trigger a full sync in Qeasy to push all historical other-outbound documents, validating field mapping and the code-mapping table. This stage typically surfaces many "source-has, target-doesn't" materials that must be created in the finance system first.
- Stage 2 — Incremental cursor: once the full sync is confirmed, set the incremental cursor to the full sync's cutoff timestamp to avoid duplicate pushes.
- Stage 3 — Scheduled polling: recommend polling every 15–30 minutes. Too frequent stresses the source API; too sparse amplifies inventory lag. A common Qeasy customer pattern is "high-frequency polling + batch submission," accumulating documents and committing them in batches.
- Stage 4 — Monitoring and reconciliation: watch daily success/failure/retry counts on the Qeasy dashboard, and run an end-of-day reconciliation against the finance-side inventory ledger with auto-alerts when the gap exceeds a threshold.
Pitfall Post-mortem
- Mapping scattered across strategies. A typical mistake: SKU mapping lives in strategy A, warehouse mapping in strategy B, and the two eventually drift apart, sending stock in the wrong direction. The safe practice is centralized mapping management—one table covering all relevant strategies.
- Wrong incremental cursor. Using the full sync's cutoff as the cursor means the last hour of the full sync gets dropped. The safe practice is to use "cutoff − 1 minute" as the incremental cursor and watch the first few polling cycles.
- UoM and precision mismatch. Pieces vs. grams, two-decimal vs. three-decimal amounts—numbers just won't reconcile. The safe practice is to perform UoM conversion and precision normalization in Qeasy's mapping layer and add a validation rule.
- Business date vs. system time. The source writes by business time; the finance system defaults to server time, so cross-month documents land in the wrong month. The safe practice is to explicitly map the "business date" field and never let system time overwrite it.
- Header and body pushed together. Some teams pack header and body into one JSON and watch the parse failure rate climb. A staged push—send the header first to confirm the main document succeeded, then send the body—is the more stable pattern among Qeasy customers.
When It Fits and When It Doesn't
Fits: retail/distribution scenarios where the e-commerce warehouse and finance warehouse share one ledger and non-sales outbound events (transfers, issues, write-offs) must flow into finance in near real time. Doesn't fit: sales outbound (use the sales-order sync strategy instead), and inventory that requires strict batch or expiry-date tracking such as pharma or food.