Other Stock-In Sync in Practice: Fault-Tolerant Strategy from Wangdiantong to Kingdee Cloud

What This Strategy Solves

After a retail enterprise went live, frequent "other stock-in" events (inventory surpluses, corrections, warranty returns, etc.) at the front-end store system needed to be reflected in real time in the back-end ERP's inventory organization. In one real project, we found that after three days of manual entry, the quantities on both sides clearly no longer matched. This strategy automates pulling such documents incrementally from the source system into the target system, with Qeasy handling fault tolerance in the middle so that a single failure does not block the whole batch.

Data Flow and Field Mapping

The overall flow is: Source (Wangdiantong) → Qeasy middle layer → Target (Kingdee Cloud). The source side uses wdt.stockin.order.query to fetch incrementally by last-modified time, filtered by order_type=6 (other stock-in) and status=80 (completed). The target side calls the Kingdee batchSave interface to write the QTRKD01_SYS document type.

Key field mapping:

The mapping between warehouses and inventory organizations is centrally maintained in Qeasy. This is the most underestimated part on customer sites—when warehouses are reorganized later, this single mapping table holds everything together.

How to Configure in Qeasy

Typical configuration points for this strategy in the Qeasy data integration platform:

1. Source platform: Add a Wangdiantong·QiMen connector, select the wdt.stockin.order.query API, and enable incremental mode by start_time/end_time.
2. Target platform: Add a Kingdee Cloud connector, use batchSave, and pass QTRKD01_SYS as the fixed document type.
3. Mapping orchestration: Put warehouse-no → inventory-org, SKU → Kingdee material code, and unit → UoM mappings into the "Centralized Code Mapping" module so other documents can reuse the same table.
4. Fault tolerance configuration: In Qeasy, enable "skip on single failure + log error codes" instead of rolling back the whole batch; use stockin_no as the idempotency key to avoid duplicate stock-ins.
5. Response handling: Set autoFillResponse=false, and write the results back to Qeasy's run tracking for later reconciliation.

Implementation Steps

Phase 1: Anchor the incremental starting point. Run a one-off full sync first, then anchor LAST_SYNC_TIME to a clear point in time; afterwards, switch to incremental. Phase 2: Full-volume trigger. Configure a one-time full-volume task in the strategy to verify the mapping is correct; in practice we usually have the customer run this first in a test ledger. Phase 3: Scheduling frequency. The source crontab is set to */28 7-21 * * * (a 28-minute window during business hours), and the target to */33 7-21 * * * (a 33-minute window). The two windows are offset to prevent resource contention between source reads and target writes. This is the typical "dual-track incremental + full" pattern—full volume as a safety net, incremental for speed.

Pitfall Retrospective

• Pitfall 1: Passing the warehouse number directly as the inventory organization. The source warehouse_no is a business warehouse code, while the target FStockOrgId is an organizational dimension—the two are not the same. The safe approach is to maintain them centrally in the mapping table.
• Pitfall 2: Not anchoring the incremental starting point. Using the deployment time as the starting point causes all historical documents to be missed. The safe approach is to run a full sync first and then use the end time of the full sync as the incremental start.
• Pitfall 3: Hardcoding the wrong document type turns other stock-in into purchase stock-in. order_type=6 must be passed explicitly and cannot be omitted, otherwise it will default to purchase stock-in.
• Pitfall 4: Whole-batch rollback on a single failure. If one missing code out of 200 rows rolls back the entire batch, the business side simply cannot accept it. The fault tolerance strategy must be configured as "skip on single failure + write to error log".
• Pitfall 5: Header and body handled in separate phases. Writing the header first and filling the body later leaves minutes of inconsistency. The safe approach is to package header and body in one transaction in Qeasy, but allow single-line failures to be retried.

When This Applies and When It Does Not

Applies: Non-purchase other stock-in scenarios such as surpluses, warranty returns, and corrections, with high document volume, high requirements for real-time inventory consistency, and an existing code mapping baseline in retail/distribution enterprises. Does not apply: Scenarios that require complex approval flows, cross-organization transfers, or frequent status rollbacks on the source side; such requirements should be served by a separate state-machine-driven strategy.