Integration Overview: Yonyou NCC and Fenxiangxiaoke CRM — 20 Strategies Bridging Sales and Finance

Scenario and Value

In one of our projects at a fast-moving consumer goods distributor, the business team only discovered on the third day after a promotion that the sales orders in the CRM did not match the payment records in the ERP. The CRM side had 30 signed orders, but only 18 had been posted in the ERP; the remaining ones were either stuck in the approval workflow or blocked by mismatched regional organization codes. The problem was not in any single system, but in the absence of an automatic closed loop between CRM and ERP — order creation, approval, writes-back, and reconciliation were scattered across systems and reconciled manually via Excel.

The goal of this integration is straightforward: write Fenxiangxiaoke sales orders, return orders, and rebate orders into Yonyou NCC according to predefined rules, then write approval results, ERP document numbers, and payment documents back into the CRM, and finally push anomaly alerts to the operations group via DingTalk. The whole chain is anchored on "order → approval → writes-back → reconciliation", with a second financial stream handling rebates and payments.

Integration Architecture and Data Flow

The overall architecture follows a typical "two endpoints + middle integration layer" pattern. The two endpoints are the CRM and the ERP, while the middle integration layer — in our projects, the Qeasy Data Integration Platform (轻易云) — handles extraction, transformation, loading, scheduling, and monitoring.

┌──────────────────────────────────────────────────────────────┐
│  Fenxiangxiaoke (CRM)                                         │
│  Sales Order / Return / Customer / Rebate / Cash Flow API     │
└──────────────────────────────────────────────────────────────┘
        │                                       ▲
        │ Sales, Returns, Customers, Rebates      │ Cash Flow, ERP Doc No.
        ▼                                       │
┌──────────────────────────────────────────────────────────────┐
│  Integration Platform (Qeasy)                                  │
│  Incremental/Full Pull | Mapping | Encoding | Retry | DLQ | Alert│
└──────────────────────────────────────────────────────────────┘
        │                                       ▲
        │ Sales, Customers, Payments, Approvals  │ Payments
        ▼                                       │
┌──────────────────────────────────────────────────────────────┐
│  Yonyou NCC (ERP)                                             │
│  Sales Order / Customer / Payment / Employee / Approval Flow  │
└──────────────────────────────────────────────────────────────┘

The data flow runs along two main lines. The first is the sales line: Fenxiangxiaoke sales orders enter Yonyou, and after approval, the ERP document number is written back to Fenxiangxiaoke. Return orders follow the same path but are written in a "return" status. The second is the financial line: Fenxiangxiaoke rebate orders are split by region (Beijing, Shanghai & Shaanxi) into Yonyou payment documents; after approval, the ERP document number is written back, while Yonyou payments flow into Fenxiangxiaoke cash flow records split by payment type and region. The master data line runs first to establish customer and employee code mappings.

Interface Inventory

Implementation Highlights

Phased Scheduling: Master data runs once at 01:00 with full pull plus daily incremental; sales orders run every 15 minutes in three strictly serial steps — incremental pull, approval, and writes-back; financial lines run every 30 minutes covering rebates, payments, writes-back, and cash flow; DingTalk alerts are triggered independently by events. Strict dependency orchestration is enforced between phases so that orders never arrive at the ERP before customer mappings.

Incremental with Full-Pull Fallback: Incremental progress is driven by both "modification time" and "document status". A lightweight consistency check runs before the first execution of the day; if the incremental field is empty or document numbers skip, a full reconciliation is triggered automatically. Initial deployment, version upgrades, and data repair force a full pull.

Centralized Code Mapping: Code mapping tables for customer, material, employee, organization, and currency are centrally maintained on the integration platform. Adding a new region or organization only requires updating the mapping, not the strategies. We have seen projects where mappings were scattered across strategies, causing the same customer to be mapped to different codes in different strategies — a typical pitfall.

Retry and Dead-Letter Handling: A single failure does not block subsequent records; it enters a retry queue. Once retries exceed the threshold, the record is moved to the dead-letter table and a DingTalk alert is triggered. Alert content is masked for privacy — no customer names or amounts — only document number, failing step, and error code.

Idempotency and Privacy: Every strategy is deduplicated by business primary key or document number to prevent duplicate writes. Connection credentials are stored in platform environment variables and never embedded in strategy scripts. Alert pushes and logs are uniformly masked.

Regional Routing: Beijing, Shanghai, and Shaanxi are split into independent strategies for rebate creation and payment writes-back. Each region runs, writes back, and reconciles independently to avoid mutual blocking.

Best Practices and Lessons Learned

First, master data must come first, business documents second. Once customer mapping is missing, every sales order write into the ERP fails. The common mistake we see on customer sites is "let the sales strategy go live first since it works smoothly" — only to find a week later that customer codes do not match and everything has to be redone.

Second, write headers and line items in separate phases. Headers and line items often come from different paginated APIs. Do not force them into one strategy. Create the header first to obtain the ERP document number, then append line items in batches using that number. This is much more resilient to network jitter.

Third, keep approval as a separate strategy. Do not embed approval logic into the sync strategy. Sync handles writes only; approval is a standalone strategy that depends on the write being completed. When approval fails, it can be retried independently without polluting sync state.

Fourth, idempotency checks on writes-back. When writing the ERP document number back to the CRM, always check both document status and document number to prevent duplicate writes-back from overwriting business fields.

Fifth, prefer region-split strategies over single multi-branch ones. We have seen projects pack Beijing, Shanghai, and Shaanxi into one strategy with conditional branches, only to fail to locate which region caused the error. The robust approach is to split into independent strategies, each with its own monitoring and alerting.

When to Use Qeasy

If you need a stable, observable, retry-capable data closed loop between CRM and ERP — especially in private deployments involving multiple organizations, regions, and approval flows — the Qeasy Data Integration Platform (轻易云) fits well as the middle layer. All 20 strategies can be orchestrated and go live within one working day, with code mapping, retry, DingTalk alerting, and privacy masking available out of the box, eliminating the need to build scheduling and monitoring from scratch.