Purchase Order Sync in Practice: An End-to-End Implementation from Inbound Orders to the Target ERP

What This Strategy Solves (Scenario and Value)

A retail enterprise runs its front-line inbound scanning and on-site collaboration on one system, while finance and inventory accounting live on a separate ERP. When the two pipelines are disconnected, you end up with the awkward scenario where the warehouse says "100 pieces received" but the ERP shows zero.

We used the Qeasy data integration platform to host this sync pipeline, pushing inbound orders from the source side into the target ERP according to business rules. The result is that a scan at the front line immediately hits the books—inventory, payables, and cost close the loop in real time.

Data Flow and Field Mapping (Source → Middle Layer → Target)

The overall path is: Source System (B) → Qeasy middle layer → Target ERP (A). The middle layer does not store business facts; it only cleans, maps, and fills in missing fields.

Key field mapping (anonymized for illustration):

Business Meaning	Source Field	Target Field	Mapping Notes
Inbound order number	inbound_no	in_stock_no	Passed through verbatim; serves as the idempotency key
Warehouse code	warehouse_code	whs_code	Maintained centrally in a code-mapping table
Supplier code	supplier_code	vendor_code	Maintained centrally in a code-mapping table
Item code	sku_code	item_code	Depends on the item sync strategy as a prerequisite
Quantity	qty	in_qty	Numeric type conversion
Unit price	price	in_price	Keep 4 decimal places to avoid precision drift
Batch / production date	batch_no / prod_date	lot_no / mfd_date	Written in a separate phase for the line items
Inbound date	in_date	in_stock_date	Normalize time zone to UTC+8

Worth highlighting: item codes and supplier codes are typically centralized in a single mapping table on Qeasy. Every strategy that uses these two codes references the same table, so a change in one place takes effect everywhere. This is one of the common patterns we see among Qeasy customers.

How to Configure on Qeasy

Connect the source system: Register the source system's inbound-order API under "Data Sources" on Qeasy. Store credentials in the platform's secure vault rather than embedding them in scripts.
Connect the target system: Register the target ERP's inbound-order write API, and confirm that the response structure contains a document number usable as an idempotency key.
Orchestrate the strategy: Create a SYNC-type strategy, choose B_TO_A as the flow direction, and tag the business module as "Purchase Order Sync".
Configure field mapping: Header fields use one-to-one pass-through; line items use "detail row mapping". Pull time-sensitive fields such as batch and production date out into a second write phase, so they are not rolled back together with the header transaction.
Set dependencies: depends_on points to the "item sync" strategy to ensure item codes are in place before inbound orders flow. This is another common pattern among Qeasy customers—header and body written in phases, prerequisite strategies enforced.
Exception handling: Retry up to 3 times with exponential backoff; once a threshold is exceeded, push the record into a "manual compensation queue" that operators can re-trigger from Qeasy's operations view.

Implementation Steps (Phased Scheduling)

We generally take three steps on the customer site:

Step 1: Establish the incremental baseline. Use a slice of historical data to anchor a baseline timestamp—for example, run a full sync over the most recent 7 days of approved inbound orders to align inventory and payables on both sides. The goal is to nail down the baseline so that subsequent increments have a stable comparison point.

Step 2: Trigger a full sync. Configure a manually-triggered "full re-run" entry on Qeasy, used only in these scenarios: initial go-live, source-system schema changes, and recovery after extended downtime. Every full sync must generate a unique run batch ID for post-hoc reconciliation.

Step 3: Set the schedule. We recommend a routine schedule of every 5 minutes to cover peak scanning windows. If the volume is low, every 15 minutes is also acceptable—inbound orders do not demand the second-level responsiveness that sales orders do.

In addition, we recommend running a "reconciliation job" at a fixed time every day: pull the inbound-order number sets from both sides, compute the difference, and list documents that exist only on the source or only on the target. This is the most effective safety net for post-hoc traceability.

Pitfalls and Lessons Learned

Code mappings scattered across strategies. A manufacturing customer initially wrote supplier-code mappings into the script of every strategy. When they switched suppliers, they had to update six places before everything aligned. The safe approach: consolidate everything into Qeasy's central mapping table—maintain once, reference everywhere.
Overly broad idempotency key. If you use "inbound order number + line number" as the idempotency key, any modification to lines on the source side triggers repeated updates or missed updates. We recommend using "inbound order number" alone as the key, and handling line-level diffs via full delete-and-insert.
Time zone and date format. If the source side carries timestamps down to the second while the target inbound date is day-granularity, a naive pass-through causes two records on the same day to overwrite each other in bizarre ways. The safe approach: truncate to the day in the middle layer, and aggregate by the business calendar when needed.
Precision drift. Quantity, unit price, and amount fields must have explicit precision set in the middle layer—do not let the two databases decide independently. We have seen a 0.01 difference in unit price break month-end closing.
Over-reliance on real-time. Inbound orders do not need second-level sync; attempting it can actually hammer the source system's API with retry storms and take it down. A minute-level cadence is sufficient, and the precious real-time channel should be reserved for data with strong time-sensitivity, such as orders and payments.

Applicable and Non-Applicable Scenarios

Applicable: Multi-organization, multi-warehouse setups where the front end is an on-site scanning/collaboration system and the back end is an ERP for inventory accounting, requiring inbound data to be written back at a minute-level cadence.

Not applicable: Complex quality-inspection flows that require weighing, scanning, and photographic evidence before inbound posting, and scenarios that strongly depend on source-system business rules for inventory reservation—these are better handled as internal transactions within the source system rather than via cross-system synchronization.