Jushuitan Inventory Shrinkage → ERP Damage Report: Strategy Tutorial
What This Strategy Solves
In a retail business, after a warehouse stocktake, Jushuitan records the shrinkage quantity. If this data is not pushed to the ERP, the financial damage report lacks a basis, and reconciliation drifts.
This strategy syncs Jushuitan's stocktake-shrinkage documents to the ERP damage report, following a defined encoding rule, closing the loop between inventory and finance. We deliver this on the Qeasy data integration platform: source ingestion, transformation, and target write-back all run in a single orchestrated flow, and errors can be pinpointed directly in the logs.
Data Flow and Field Mapping
The flow is one-way: Jushuitan (source) → Qeasy middleware → ERP damage report (target).
Key field mapping (fields not present in the source material are intentionally omitted):
| Business Meaning | Jushuitan Side | ERP Damage Report Side | Mapping Notes |
|---|---|---|---|
| Document No. | Original stocktake No. | Damage report No. | Reference key from source; ERP generates a new No. by its own rule |
| Item Code | SKU | Inventory item code | Unified through a mapping table; one item, one code across systems |
| Shrinkage Qty | Stocktake variance (negative) | Damage qty (positive) | Take absolute value before writing to avoid negative intake |
| Document Date | Stocktake date | Business date | Direct sync; no timezone conversion (private network clocks are aligned) |
| Warehouse | Warehouse code | Warehouse code | Code lookup; missing values throw errors, no default fill |
| Memo | Stocktake memo | Summary | Truncate to target system's allowed length |
We keep the code mappings centralized in Qeasy's mapping table rather than scattered across strategies. When a new warehouse or SKU is added, only one place needs to be changed.
How to Configure in Qeasy
In the Qeasy platform, one strategy corresponds to one integration flow, composed of three segments: source ingestion, transformation, and target write-back.
Typical configuration points:
- Source ingestion: Subscribe to Jushuitan's stocktake-shrinkage events, or pull by time window. In private deployment, the source adapter uses an internal address; credentials are stored centrally in the platform's credential vault, never in plaintext within a strategy.
- Transformation: Use Qeasy's field-mapping node to handle quantity sign flipping, length truncation, and code replacement. Stocktake documents usually contain a header plus multiple line entries; we recommend phased processing: write the header first, then the lines, then write back the association IDs.
- Target write-back: Call the ERP damage report API (single submit-and-approve, or two-step depending on the customer site). On failure, Qeasy retries per configuration; once retries are exhausted, the record goes to the exception queue.
- Logging and alerts: Enable field-level logs for quantity, codes, and document numbers. Alerts are pushed to the enterprise IM, so the on-duty engineer receives a card in the group chat.
Implementation Steps
A phased rollout: incremental start-point + full-trigger + schedule frequency.
Phase 1 — define the incremental start-point. Use the project's go-live date at midnight as the cutoff for the first sync, so only post-cutoff stocktake shrinkage is synced. Avoid backfilling historical data.
Phase 2 — full trigger (optional). If the customer needs historical shrinkage backfilled into ERP, run a dedicated full-volume task once and then close that entry. Going forward, only incremental runs. Cap concurrency during the full run to avoid tripping ERP rate limits.
Phase 3 — schedule frequency. Stocktaking is a low-frequency event; once or twice per day is usually enough. Configure Qeasy's scheduler with cron in off-peak hours. After a stable run-in period, the frequency can be lowered further.
During the first batch after go-live, finance and warehouse typically reconcile quantities and amounts together, then sign off once both sides match.
Lessons from the Field
These are issues we have repeatedly encountered at customer sites. List them up front so you can avoid them.
- Forgetting to flip the quantity sign. Jushuitan expresses shrinkage as negative; the ERP damage report requires positive intake. The classic mistake is to write the source value through directly, which makes ERP reject the record or produce a wrong quantity. Apply an absolute-value step in the transformation node.
- Code mapping not centralized. When item or warehouse code mappings are embedded in strategies, any change requires editing multiple files. Centralize them in a mapping table; one change takes effect everywhere.
- Header and lines not phased. Stocktake documents have a header plus multiple lines; pushing them together can cause ERP validation order failures. Phase them: create the header first to obtain the primary key, then loop the lines, then write back the status.
- Retry policy too aggressive. If ERP-side approval fails after a damage report is written, Qeasy retry can re-write the same record and create duplicate damage entries. Use an idempotency key (source document number + warehouse + date); before retry, query the target to check whether the record already exists.
- Full and incremental not isolated. Running full and incremental in parallel during early go-live often leads to duplicate writes or order confusion. Isolate them: keep the full task on its own entry, close it once finished; start the incremental task from a clear cutoff, and ensure the two time windows never overlap.
When to Use and When Not to Use
Use when: stocktaking frequency is low, and the customer needs ERP and WMS reconciliation aligned; private deployment is available, and both systems expose stocktake/damage document APIs.
Do not use when: stocktake results are generated inside ERP and no external source is involved; sub-second real-time sync is required (this strategy runs on a schedule); encoding is wildly chaotic and master data (items and warehouses) has not yet been synchronized — master data must be aligned first.