Rebate Order ERP Number Write-Back Strategy: A Closed-Loop Implementation from Yonyou NCC to Fenxiang CRM

What This Strategy Solves

Once a rebate order is approved in the ERP (Yonyou NCC), business users still need to follow up on invoicing, reconciliation, and customer communication in the CRM (Fenxiang). If the ERP document number cannot flow back, manual entry is required on the CRM side, and cross-system reconciliation loses accuracy. A common requirement we see on customer sites is to write back the effective rebate document number and approval status from the ERP to the corresponding CRM record, so that the business side uses the ERP as the final reference. This strategy does not transmit line items; it only performs a lightweight write-back of the document number and status fields.

Data Flow and Field Mapping

The overall flow is: Yonyou NCC (source, polled) → Qeasy Data Integration Platform (intermediate, filtering and mapping) → Fenxiang CRM (target, invoking the data update interface).

The key points are: status=2 is used as a filter to fetch only completed records, number is passed directly as the write-back field value, and id on the source side serves as the idempotency key.

How to Configure in Qeasy

The source is a query interface and the target is a write interface, which is a typical "query → update" two-stage pattern. When configuring on the Qeasy platform, the strategy is split into source registration, target registration, and mapping orchestration:

1. Source registration: API = QueryStrategyData, method = POST, effect = QUERY. The request body always carries strategy_id, status=2, created_at_begin={{LAST_SYNC_TIME}}, and created_at_end={{CURRENT_TIME}}. Mark number as the business number, and enable idCheck on id for downstream deduplication.
2. Target registration: API = /cgi/crm/v2/data/update, method = POST, effect = EXECUTE. The request body consists of data (header object), triggerWorkFlow=true, and triggerApprovalFlow=false.
3. Mapping orchestration: Write the source number into the ERP-number field inside the target data; associate source id with target data.object_id. Triggering the workflow but not the approval flow is the safe choice for this kind of lightweight write-back — it prevents secondary approvals on the CRM side that would cause status ping-pong.

Implementation Steps

1. Incremental starting point: Initialize LAST_SYNC_TIME to midnight on the official ERP rebate go-live date. The first batch is a full pull; subsequent runs are 15-minute increments.
2. Full-volume trigger: Backfill historical data once, typically via a temporary schedule running overnight; after it completes, switch LAST_SYNC_TIME to the current time.
3. Scheduling frequency: Per the source material's crontab (*/15 6-23 * * *), run every 15 minutes during business hours and stop at night to reduce ERP pressure.
4. Exception handling: When the source returns a failure or the target data is empty, the strategy enters the retry queue; after three consecutive failures, it is escalated to a human.

Lessons Learned

1. Do not skip the status filter: An earlier version omitted status=2 and wrote back records that were still "waiting," which incorrectly triggered CRM workflows and triggered business complaints. The safe approach is to hard-filter on the source query.
2. Do not use response time for the window: The material leaves response_at_begin/end empty and uses only the created_at window, to avoid reprocessing already written-back records.
3. Centralize code mapping: At one retail customer, the ERP document number and CRM field names did not match. We maintained the mapping table centrally in Qeasy, so adding new regions later only requires new rules — no flow changes.
4. Workflow vs. approval trigger: Only trigger the workflow on the CRM side, not the approval flow (triggerApprovalFlow=false), otherwise already-closed records would be pushed into approval again.
5. Idempotency key must be enabled: With idCheck enabled, duplicate data is deduplicated, preventing repeated writes to the same CRM record.

Applicable and Non-Applicable Scenarios

Applicable: ERP is the single source of truth for rebate/expense settlement, CRM is only for follow-up and display, and the ERP document number must serve as the reconciliation anchor. Not applicable: Scenarios with many line items (this strategy only writes back header fields), or bidirectional real-time scenarios that require event-driven rather than scheduled polling.