Sync Inventory Loss Outbound from Jike Cloud to Yonyou NCC Other Outbound: Non-Factory Warehouse in Practice

What this strategy solves

In retail or manufacturing companies running multiple systems, when a stock loss occurs at a store or non-factory warehouse, the business side expects a corresponding outbound document to be generated in the ERP for accounting and cost settlement. Jike Cloud records the front-end inventory loss outbound, while Yonyou NCC acts as the back-end financial inventory system and needs to consume this document to produce a matching other outbound (non-factory warehouse). This strategy is the bridge between the two ends, keeping the back-end financial inventory consistent within a controllable latency after the front-end business event fires.

Data flow and field mapping

The flow direction is A → B (Jike Cloud → Yonyou NCC). In Qeasy (QingYiYun Data Integration Platform), we usually split it into three layers: source raw document → middle layer (Qeasy performs lightweight standardization and code mapping) → target document. The key fields that typically need to be mapped for this inventory loss outbound are:

The typical pitfall is the warehouse type field: the inventory loss outbound contains both factory and non-factory entries, but the target side only accepts non-factory ones. The safe approach is to let the Qeasy middle layer perform a routing decision; documents with mismatched warehouse type should go to an exception branch rather than being written through directly.

How to configure it in Qeasy

In Qeasy we usually configure this strategy around four key points:

First, register the source and target connections. The source uses Jike Cloud open APIs (inventory document query), the target uses Yonyou NCC's supply chain WebAPI or an intermediate table write interface, with account set details filled in according to the actual enterprise environment (specific values are not shown here).

Second, build the code mapping. Map Jike Cloud SKUs to Yonyou NCC inventory archive codes – this is the lifeline of sync correctness. A common pattern we see in customer projects is "centralized code mapping management": the mapping table is maintained as a master data strategy rather than scattered across individual sync flows.

Third, configure field conversion and constants. Including unit conversion, date formatting, and summary template concatenation. A typical mistake here is passing the source remark field straight through to the target, which results in dirty data such as "test" or "abc" appearing in the summary, making troubleshooting extremely painful later.

Fourth, configure exception handling. Network jitter, field overflow, and missing codes must each go to explicit failure branches and notify the ops group.

Implementation steps

We recommend a three-phase rollout to customers:

Phase 1 – incremental start. Set the incremental start time to 00:00 on the go-live day and sync only newly created or changed inventory loss outbounds. This minimizes the risk surface and gets the link running first.

Phase 2 – full-volume trigger. Once the link is stable, manually trigger a one-time full backfill to push all historical loss documents into Yonyou NCC. The cadence is usually temporarily tightened to every 5–10 minutes during this phase, then restored to the normal frequency afterwards.

Phase 3 – scheduling cadence. Evaluate by business volume: for companies with daily documents in the two-digit range, every 15–30 minutes is enough; for higher volumes, it can be tightened to 5 minutes, or switched to front-end event callbacks for better timeliness. A common pattern we see on customer sites is "incremental plus full-volume dual-track" – one scheduled job runs the incremental, while a separate channel retains the full-volume capability for backfill and exception recovery.

Pitfall review

First, no warehouse-type filtering before write. The non-factory strategy wrote factory-warehouse loss documents into Yonyou NCC too, and the issue was only found during month-end reconciliation. The fix is to add the routing decision at the middle layer up front.

Second, missing code mapping causes batch failure. One SKU was not yet archived in Yonyou NCC's inventory master, and Qeasy pulled an entire batch over that all failed. The recommendation is to route missing codes to a side branch instead of failing and aborting the batch.

Third, the batch field is empty on the source but required on the target. The middle layer needs to fill a default batch or explicitly skip such documents.

Fourth, no time window design. In the early rollout we used a "calendar day" window, which caused a number of cross-day documents to be missed. Switching to a sliding window plus a fallback compensation made it stable.

Fifth, weak idempotency on the target side. Yonyou NCC will create a new document for the same number, which collides when the business user manually supplements a same-named document on the Yonyou side. The recommendation is to keep a "successfully written" set in the middle layer for idempotency.

Applicable and non-applicable scenarios

Applicable: retail or distribution enterprises with multiple front-end business systems coexisting with a back-end ERP, where front-end loss events need near-real-time backflow into financial inventory, with non-factory warehouses under independent accounting, clear organizational boundaries, and standardized inventory archives. Not applicable: factory-warehouse losses (which should go through the dedicated factory strategy), early stages before inventory archives are built, and scenarios demanding strict real-time consistency (< 1 second).