Transfer Return Negative Mapping to Other Outbound: A Practical Guide to Inventory Sync from Jky to Kingdee Cloud

What This Strategy Solves

In multi-organization retail and distribution environments, transfer returns create an awkward data situation: the source warehouse has already received the goods back, so the document must carry a negative quantity, but the downstream finance and inventory system does not understand negative transfer entries—it only accepts standard "other outbound" documents. In one real engagement with a retail enterprise, the warehouse clearly had the returns in stock, yet the inventory on the target side never matched. The root cause was not the data itself, but how a negative entry should be translated into a positive document. This single strategy rewrites negative transfer-return records from the source system into outbound stock documents that the target system can recognize, keeping both sides consistent for the same business event.

Data Flow and Field Mapping

Data flows from the source system (Jky) through the strategy orchestration in the Qeasy data integration platform, and lands in the target system (Kingdee Cloud) as an outbound stock document.

The two decisive transformations are "take the absolute value of quantity" and "replace the document type." Together they convert a negative transfer return into a positive outbound document.

How to Configure on Qeasy

On the Qeasy data integration platform, this strategy is typically configured around the following points:

1. Source API: Use Jky's erp.storage.goodsdocin.v2 (WebAPI, POST). Control the incremental window with startDate and endDate. Default page size is 50.
2. Filter: Add an inouttype = transfer return filter in the middle layer so that positive transfer entries are not pulled in.
3. Field rewriting: Use Qeasy's field-assignment node to take the absolute value of quantity and fix the document type to QTCKD94_SYS. This is the soul of the strategy.
4. Code mapping: Material codes and warehouse codes go through a centrally managed mapping table, which is a common pattern among Qeasy customers—one source-side set, one target-side set, aligned through the platform. When a new SKU is added later, only one place needs to change.
5. Target API: Kingdee Cloud batchSave (WebAPI, POST, EXECUTE). The header and the lines are assembled in two phases—header first, then lines—to avoid total failure caused by missing references.
6. Idempotency: Use FJKYNo as the idempotency key. The source document number is unique, so retries do not create duplicate records.

Implementation Steps

We usually split the rollout into three phases to keep things stable:

• T0 Incremental start point: Confirm the creation time of the most recent complete transfer-return record on the source side and use it as the LAST_SYNC_TIME start point to avoid missing data.
• T1 Full backfill: On the cutover night, run a full backfill to push the historical negative transfer returns within the last N days at once. Once it completes, disable full mode and keep only incremental sync.
• T2 Incremental schedule: The source side runs at 14 6-23 * * * (every hour during the day, at minute 14). The target side runs at 47 * * * * (every hour, at minute 47). The two sides are staggered, with the target running roughly half an hour later to leave a processing window.

Pitfalls and Lessons Learned

1. The typical mistake is forgetting to take the absolute value—when a negative number is passed through directly, the target system rejects the batch. The safe approach is to explicitly add an ABS step in the middle layer rather than rely on the target system's implicit conversion.
2. Without the inouttype filter, positive transfer entries get pushed as returns too, and the quantities on both sides drift apart—only discovered during finance reconciliation. This is a common trap; the filter must be added up front.
3. Scattered code mappings—when mapping logic lives inside ad-hoc scripts, changing an encoding rule later means touching many places. A common Qeasy customer pattern is to centralize mappings on the platform so a single change applies to all strategies.
4. Sending header and lines together—if any line fails, the entire document rolls back and retry cost is high. Two-phase assembly (header first, then lines) significantly reduces the failure rate.
5. Clashing schedules—when source and target run at the same minute, queues pile up during peak hours. Staggering the two sides by 30 minutes or more leaves enough buffer.

Where It Applies and Where It Does Not

This strategy applies to multi-organization retail or distribution scenarios where the source records transfer returns as negatives and the target system only accepts positive outbound documents. It does not apply to: (1) positive transfer entries, which follow a normal transfer strategy and are out of scope here; (2) scenarios that require writing status back to the source system; (3) cross-currency or cross-valuation stock conversions—this strategy only carries quantity and basic fields.