Inventory Overage Sync in Practice: A Single-Strategy Tutorial from Jushuitan to ERP

What This Strategy Solves

In retail and manufacturing scenarios, warehouse stock counts in Jushuitan frequently reveal situations where the physical quantity exceeds the system quantity—in other words, an overage. If this overage is only recorded in Jushuitan, the ERP inventory ledger will remain short, dragging down month-end closing and cost accounting. The "inventory-count increase sync" means: whenever Jushuitan generates an inventory increase document, an overage report (also called a surplus document) is automatically created on the ERP side, so that the books on both sides are aligned within the same day. On the Qeasy data integration platform, we typically use a dedicated single-strategy pipeline for this flow—neither mixed with normal purchase receipts nor dependent on manual re-entry.

Data Flow and Field Mapping

The data flow is straightforward: Jushuitan (the "overage" rows in the stock-count document detail) → Qeasy middleware layer (cleansing, transformation, default-value enrichment) → ERP overage document (header + lines). The key field mapping is roughly as follows:

The greatest value of the middleware layer is the centralized management of this code mapping. We model the warehouse mapping and SKU-to-material mapping as two maintainable mapping tables in Qeasy's mapping center, rather than hard-coding them in scripts. When the business side adds a warehouse or SKU, they only need to fill in one row of mapping—no change to the main sync flow is required.

How to Configure on Qeasy

On the Qeasy data integration platform, this strategy is organized as a single-strategy, document-level pipeline. There are four typical configuration points:

1. Source and target. The source uses Jushuitan open-platform's stock-count document interface (incremental pull of count-result documents); the target invokes the ERP overage-document save interface. Authentication is managed through Qeasy's connector management—no tokens are exposed inside the strategy itself.
2. Filter conditions. The source only fetches records where "Document Type = Inventory Increase" AND "Approval Status = Approved". This avoids mixing in count decreases (shrinkage) and prevents unapproved drafts from triggering downstream.
3. Field mapping. Header fields map one-to-one; the body is split by row, where each overage detail becomes one line of the overage document. SKU and warehouse code mappings reference the two tables in the mapping center rather than hard-coded values.
4. Error handling. Enable "document-level retry + row-level skip": the whole document auto-retries 3 times on failure, while missing row-level mappings (e.g., a SKU with no mapping yet) skip that row and write a log, so one unknown SKU never blocks the entire batch.

Implementation Steps

At the customer site, we typically proceed in four phases:

• Phase 1: Incremental Start Alignment. Before the first run, we work with the customer to define a clear starting point (e.g., 00:00 on go-live day). Incremental pulling begins from that moment, and prior overage documents are manually backfilled once, avoiding the pollution of historical data into the sync chain.
• Phase 2: Full Trigger and Reconciliation. Within the two weeks before go-live, we allow a one-time "full backflow" to push all overage documents after the starting point into the ERP at once, then disable the full mode and keep only incremental. After the backflow, business, warehouse, and finance teams reconcile once to confirm overage numbers match on both sides.
• Phase 3: Schedule Frequency Go-Live. Stock counts usually happen after the day's shift ends, so the schedule is set to twice daily—early morning plus late evening—covering late-shift counts without contending for resources during peak business hours.
• Phase 4: Steady-State Monitoring. The Qeasy console outputs daily sync row counts, failure counts, and skip details. Operations staff only need to look at one daily report; abnormal documents are handled manually as a fallback.

Lessons Learned from the Field

1. Mixing overage and shrinkage in one pull. A classic mistake is to filter on "count result" only, without specifying "Document Type = Inventory Increase", causing shrinkage to be pushed into ERP overage documents and disrupting the business. The safe approach is to explicitly specify the business type in the filter, rather than relying on non-empty field checks.
2. Unapproved documents pushed downstream. Some warehouses close the count before approval; if the approval status isn't checked, draft data will be pushed to the ERP. Always add an "Approved" condition or perform state validation in the middleware layer.
3. SKU mapping omissions. When a new store or new SKU goes live, Jushuitan SKUs often arrive before ERP material codes, resulting in skipped rows every day during the first week. The response pattern is to treat missing mappings as an alert event pushed to the item master data owner, rather than silently discarding them.
4. Many-to-many warehouse mapping hard-coded. The same warehouse may have different codes on the two sides. If this is written as if-else logic in scripts, changing one warehouse later requires edits in three places. Centralize it in the mapping center—one change takes effect everywhere.
5. Duplicate push of overage documents. If a Jushuitan stock-count document is un-approved and then re-approved, it triggers duplicate downstream push. The safe approach is to record already-pushed count document numbers in the middleware layer for idempotent control—the same document number is only pushed once.

Applicable and Non-Applicable Scenarios

Applicable: Multi-warehouse retail, e-commerce + offline hybrid businesses, where Jushuitan handles daily stock counts and the ERP handles inventory ledger and cost accounting, requiring same-day alignment of overage books. Not applicable: Scenarios where Jushuitan already syncs inventory to the ERP in real time without needing document-level business records; or scenarios where the ERP does not distinguish overage documents and merges them into other receipt documents for unified posting—the latter should follow a combined purchase/other-receipt strategy rather than a dedicated overage pipeline.