Replenishment Order Number Write-Back to CRM: A Single-Strategy Integration Tutorial

What This Strategy Solves

A common pain point in many retail operations is this: a replenishment request created in the CRM is fulfilled in the ERP and gets a formal ERP document number, but the line items in the CRM still show no reference back. Salespeople quote the CRM request number, supply-chain teams talk about an FBillNo, and the two sides spend unnecessary time reconciling.

The goal of this strategy is to push the ERP-generated replenishment document number (FBillNo) back to the corresponding CRM row, so that the CRM request and the ERP replenishment document share an automatic cross-reference. It looks like "writing back one number," but to do it correctly you have to align document status, posting date, organization, and the head-vs-line relationship — otherwise business teams will chase you three months later.

Data Flow and Field Mapping

The direction is clear: the source is the ERP (treated as system B), the target is the CRM (system A), flowing B_TO_A.

Centralized mapping management is the key. The ERP-side FBillNo is a string document number, while the CRM side stores it in a text control — the two may differ in length and character set. On the Qeasy platform we keep the "ERP number → CRM control" mapping in one place so business changes only require a single update. A staged head-then-line approach also applies here: write back the document head first, then perform line-level write-back keyed by FSaleOrderEntry_FEntryID, to avoid oversized single payloads that are hard to roll back.

How to Configure It on Qeasy

Configuring this strategy on the Qeasy data integration platform takes three steps.

Step 1 — register the source fetch action. The ERP query API is executeBillQuery (POST, QUERY semantics). The fields that drive the strategy are FBillNo (serves as both document number and ID), FID, FSaleOrderEntry_FEntryID, FDocumentStatus, FSaleOrgId.FNumber, and FDate. Keep idCheck on, but turn autoFillResponse off so the mapper explicitly controls each field.

Step 2 — register the target write-back action. On the CRM side the endpoint is /v2/open/worksheet/editRow (POST, EXECUTE semantics). The three input parameters are worksheetId, rowId, and controls. Notably, rowId is not hard-coded — it is resolved by _findCollection, which searches the CRM row collection for a row matching {{F_dps_Bhdid}}. This is a common pattern: locate the target row by a business key rather than by an internal ID.

Step 3 — configure scheduling and dependencies. The source crontab is 3-59/5 * * * *, and the target crontab is 5-59/5 * * * *. Offsetting the two sides by two minutes prevents simultaneous writes. The strategy has no dependencies, meaning it runs independently.

Implementation Steps

We recommend a three-phase rollout: incremental anchor → full backfill → scheduling cadence.

1. Incremental anchor: use FDocumentStatus on the ERP side (e.g., audited/A) as the boundary, so only audited replenishment documents are written back. This avoids pushing draft FBillNo values into the CRM and then having them invalidated later.
2. Full backfill: the night before go-live, run a one-shot full scan to backfill the references for historical documents. Validate everything in a test environment first to avoid dirty data in production.
3. Scheduling cadence: combine a 5-minute poll with status filtering. The source side pulls audited documents every 5 minutes, and the target side writes back 2 minutes later. On Qeasy, keep incremental and full scans as two separate scheduled tasks — incremental runs continuously, full scan is triggered manually. This dual-track pattern is the most common one we see on customer sites.

Lessons Learned From Real Projects

• Easy to get wrong: the CRM row has no unique business key, so rowId comes back as null. The safe approach is to first build a unique index in the CRM using a business field like {{F_dps_Bhdid}}, then let _findCollection resolve the row.
• Typical mistake: writing FSaleOrderEntry_FEntryID back as if it were FBillNo. They are not the same — the former is an ERP line internal code, the latter is the document number. Mixing them up exposes wrong numbers to the business.
• Skipping a proper staged head-vs-line approach and writing everything in one shot. If one field has an incompatible control type (e.g., a number control receiving a string), the entire update fails and the previously written fields do not roll back. It is safer to first write back just the document number and status, validate, then expand.
• Picking the wrong incremental anchor. Using "created time" instead of "audit time" causes draft documents to be pushed into the CRM, and once a draft is voided, the reference on the CRM side is broken.
• Mapping rules scattered across multiple strategies with no centralized governance. After the dust settled, the customer consolidated all ERP-number-to-CRM-control mappings into a single mapping table maintained by one team.

When to Use This Strategy — and When Not To

Use it when the CRM initiates and the ERP executes, and you need the ERP's formal document number on the CRM line items as a cross-reference. Do not use it when you also need to bring back attachments or full approval flows — that is a separate strategy. It is also not suitable when neither side has a unique business key and humans have to match records manually.