Supplier Master Data Sync from Retail System to ERP: A Single-Strategy Implementation Guide

What This Strategy Solves

In one retail operation, the front-end retail system accumulated a large amount of supplier master data, including account holder names, bank account numbers, groups, and owning organizations. When the business side required this supplier data to be unified into the cloud ERP for accounting and payment processing, the most naive approach was to "enter it twice on both sides." One mid-sized chain customer we worked with was in exactly this situation: procurement maintained 3,000+ suppliers in the retail system, while finance had to re-enter them in the cloud ERP. After three months, names mismatched, accounts shifted, and organizations were misassigned — the week before monthly closing, finance was basically "reconciling suppliers."

This strategy solves one thing: using the retail-side supplier master data as the single source of truth, one-way syncing it into the cloud ERP, so that one entry serves everywhere. We used the Qeasy Data Integration Platform at the customer site. The key is not "whether sync is possible," but "how to manage code mapping, how to assign organizations, and how to schedule incremental vs. full loads."

Data Flow and Field Mapping

The pipeline is one-way: retail system → Qeasy middle layer → cloud ERP. The source only "provides data," the target only "receives and stores," and all transformations happen inside Qeasy. This is one of the most common patterns among Qeasy customers: centralizing the dirty work in the middle layer.

Key field mapping (from actual configuration):

The source is a GET-type query interface, fetching by supplier_num as the business key. The target is a POST-type batchSave execution interface; the primary key field does not participate in target-side dedup check (idCheck is off, to avoid batch being misjudged as updates).

How to Configure on Qeasy

Step one: register two platform adapters. The source is WebAPI query-type (QUERY); the target is EXECUTE write-type. Platform identifiers are filled according to the actual tenant.

Step two, when creating the strategy, bind source body.supplier_num to both number and id — this has been repeatedly validated at customer sites: the source primary key must be bound to both number and id, otherwise the incremental starting point will be miscalculated.

Step three, enable autoFillResponse on the source so that common response fields like trace_id, sign, merchant_id, body, and app_id are auto-filled, saving manual mapping.

Step four, the target uses batchSave for bulk write. For organization info FBankInfo, apply Qeasy's "header-body phased" pattern: write the header first, then expand account, bank, and other details as a sub-array. This is another typical Qeasy customer pattern: header-body separation, avoiding three writes per supplier record.

Step five, centralize code mapping. Fixed values like FGroup, FCreateOrgId, and FUseOrgId should not be scattered across individual fields — place them all in Qeasy's "constant mapping table." When organizations or groups need to change, only one place needs editing.

Implementation Steps

We recommend a three-stage approach: incremental start point → full-load trigger → scheduling frequency.

Incremental start point: First, set the incremental start time in Qeasy to a reasonable historical point (for example, the day before business go-live) and run an incremental pass to capture newly added and modified suppliers. We set the source crontab to 1 1 1 1 1 (one-shot trigger), with the purpose of anchoring the start point.

Full-load trigger: Once incremental is stable, manually trigger a full load to push historical suppliers in one go. This must be done during off-peak hours, with finance notified in advance to avoid simultaneous entry on both sides.

Scheduling frequency: We configured the target crontab as */3 * * * *, polling the execution queue every 3 minutes. This way, new records on the source side land in the ERP nearly in real time. The key here is the "dual-track incremental and full-load" pattern: incremental relies on source timestamps, full-load relies on manual triggers, and the two tracks run in parallel without conflict.

Pitfall Review

1. Binding source primary key only to number, not to id: The incremental start point will be calculated as "the first row of the full table," re-running the entire history immediately. The safe approach is to bind supplier_num to both number and id.
2. Keeping idCheck on while doing batch: batchSave is bulk insert by nature; if idCheck is on, the target will query by primary key, find nothing, and error out. The typical mistake is "it says primary key conflict when it should be a new insert."
3. Passing FBankInfo as a string: It is an array type and must be assembled as a sub-array in Qeasy, otherwise the cloud ERP will throw "invalid structure."
4. Cron set too dense: The source does not need to be queried every minute; a one-shot start like 1 1 1 1 1 is sufficient for the source. The target can poll the execution queue at high frequency.
5. Hard-coded groups and organizations scattered everywhere: When organizations need to change, you'll be editing a dozen places. Centralized mapping management is the most comfortable practice on Qeasy.

Applicable and Non-Applicable Scenarios

Applicable: Single source of truth, clear field mapping, fixed organization dimensions, no bidirectional conflict resolution needed — supplier master data sync. Non-applicable: scenarios where both source and target need maintenance, scenarios with large field differences requiring manual intervention, and complex scenarios requiring per-store organization splits. For these, we recommend splitting into multiple strategies rather than forcing them into one.