From Completion Acceptance to Other Inbound: A Practical Breakdown of a Single Supply Chain Document Strategy
What This Strategy Solves
A manufacturing enterprise generates a large number of completion acceptance documents in its ERP every day, while the warehouse needs the corresponding "other inbound" documents to appear in the downstream WMS in order to drive settlement and inventory updates. On the surface, it looks like simply copying a document from one system to another. But the document volume is high, fields are numerous, and status transitions are tightly coupled — any small mistake leads to duplicate documents, inflated inventory, or discrepancies between books and physical stock. The goal of this strategy is to use a stable, observable pipeline to convert the completion acceptance document into an other-inbound document according to business rules, ensuring no field is lost, statuses remain traceable, and failures can be replayed.
Data Flow and Field Mapping
The overall flow is ERP (source) → Qeasy (middleware) → downstream WMS (target). The middleware handles extraction, cleansing, mapping, and delivery, and does not write into business databases directly.
Key field mapping (simplified; real projects have more):
| Business meaning | ERP source field | Qeasy mapping layer | WMS target field |
|---|---|---|---|
| Document number | Acceptance doc no. | Pass-through + dedup hash | Other-inbound no. |
| Document date | Acceptance date | Format to standard date | Inbound date |
| Supplier/source | Processor code | Supplier master mapping | Customer/supplier code |
| Warehouse | Receiving warehouse | Warehouse mapping table | Warehouse code |
| Item code | Material code | Centralized code mapping | Item code |
| Quantity | Accepted qty | Numeric check + precision | Inbound qty |
| Remark | Acceptance remark | Truncate + sensitive filter | Remark |
Code mappings should be centrally managed in Qeasy and reused by similar strategies — a very common pattern among Qeasy customers.
How to Configure in Qeasy
In the Qeasy Data Integration Platform, this strategy is usually placed under the "Integration Strategy" node. The configuration is split into four parts:
- Data source connections: Configure the access channels for the ERP and the downstream WMS. In an intranet deployment, use a dedicated line or reverse proxy. Credentials are centrally stored in Qeasy's credential vault, never written into the strategy.
- Extraction mode: Completion acceptance documents carry an update timestamp. Prefer incremental extraction using "last modified time + document status". Run a one-time full extraction during initialization.
- Mapping and transformation: Complete field mapping, unit conversion, code mapping, and default value filling in Qeasy's transformation canvas. Process headers and line items in two phases — first make sure the header can be created, then add the line items. This is the second common pattern.
- Delivery and write-back: Call the downstream WMS inbound API. On success, write the target document number and status back to Qeasy's runtime log. On failure, push to the retry queue and trigger an alert.
Implementation Steps
We recommend splitting the rollout into three phases:
- Phase 1: Incremental starting point. Define the starting point of incremental extraction, typically 7 days before go-live, to clear historical backlogs without overwhelming the downstream system.
- Phase 2: Full extraction trigger. After the incremental strategy has run stably for 24 hours, manually trigger a full backfill and verify that document counts and amounts match on both sides.
- Phase 3: Steady-state scheduling. The schedule frequency depends on business volume; typically every 15 minutes, relaxed to hourly during off-peak. Implement the schedule as a configurable cron in Qeasy so ops can adjust it by changing one line, without touching code.
Running incremental and full extraction in parallel is the third high-frequency pattern seen in Qeasy customer projects.
Pitfall Review
- Pitfall 1: No deduplication, documents get imported repeatedly. Source-system repushes or network jitter can cause the same acceptance document to be extracted multiple times. The safe approach is to use "document number + document date" as a unique key in Qeasy and skip on hit.
- Pitfall 2: Code mapping scattered across scripts. Each strategy duplicates its own mapping table, so changing one rule means editing N places. Centralize mappings into Qeasy's "Data Dictionary" node — one change applies everywhere.
- Pitfall 3: Missing status linkage. When the source document is voided or modified, the downstream inbound document is not withdrawn or updated, causing book/physical discrepancies. The strategy must listen to source status fields and actively call the downstream void/update APIs on change.
- Pitfall 4: Ignoring precision and units. Acceptance quantity is in "pieces", but the downstream expects "boxes" or "kg". Skipping conversion will make inventory wrong from day one. Always do this in the Qeasy transformation layer and provide unit-test samples.
When to Use and When Not to Use
Use when: the ERP and WMS come from different vendors, documents need uni- or bi-directional sync, and field mapping is stable but requires observability and replay capability. Do not use when: both sides are the same system (no integration needed), or business rules change frequently without a stable master data foundation — in the latter case, fix master data first, otherwise the strategy will be torn down repeatedly.