Yonyou NCC and Fenxiangxiaoke Integration: Bidirectional CRM-ERP Master Data and Document Synchronization Design

Scenario and Value

In sales-driven businesses, data silos between CRM and ERP are a common pain point. Sales orders, return orders and customer master data are maintained in the CRM, while financial bookkeeping, receipt reconciliation and approval workflows live in the ERP. Manual re-entry between the two not only reduces efficiency but also leads to inconsistent codes and reconciliation risks.

This solution is designed for a retail/consumer goods enterprise and provides a private-deployment integration design that connects Fenxiangxiaoke CRM with Yonyou NCC ERP through an integration platform. The scope covers five core objects: master data, sales orders, return orders, rebate documents and payment receipts, together with approval result write-back and exception alerting. The solution defines 20 strategies in total, including 17 SYNC, 2 QUERY_ONLY and 1 NOTIFY, and can serve as a reference for similar enterprises pursuing CRM-ERP unified integration.

Integration Architecture and Data Flow

The overall architecture follows a three-layer structure. The source side consists of Fenxiangxiaoke CRM and Yonyou NCC, while the target side includes the same two systems plus DingTalk as the exception notification channel. The integration platform sits in the middle and is responsible for extraction, mapping transformation, write-back and alerting.

┌────────────────────────────────────────────┐
│  Fenxiangxiaoke (CRM)                       │
│  Sales Order / Return / Customer / Rebate / │
│  Account Flows                              │
└────────────────────────────────────────────┘
       │                          ▲
       │ Orders, Returns,         │ Flows, ERP No. write-back
       │ Customers, Rebates       │
       ▼                          │
┌────────────────────────────────────────────┐
│  Integration Platform                       │
│  Incremental/Full | Field Mapping |         │
│  Code Conversion | Retry | Dead Letter      │
└────────────────────────────────────────────┘
       │                          ▲
       │ Orders, Customers,       │ Receipts
       │ Receipts, Approvals      │
       ▼                          │
┌────────────────────────────────────────────┐
│  Yonyou NCC (ERP)                           │
│  Sales Order / Customer / Receipt /         │
│  Personnel / Approval                       │
└────────────────────────────────────────────┘

Scheduling is divided into four phases. Phase 1 (daily at 01:00) runs master data synchronization and lookups. Phase 2 (every 15 minutes) handles sales order synchronization, approval and write-back. Phase 3 (every 30 minutes) handles financial synchronization. Phase 4 is event-driven DingTalk alerting.

Interface List

Implementation Highlights

1. Dependency Order and Initialization. Customer code mapping is the prerequisite for all subsequent order and rebate strategies, so Strategy 1 (Fenxiangxiaoke customer → Yonyou customer) must run before Strategies 4, 5, 10 and 11. Order strategies (4, 5) must successfully write into the ERP before the approval strategies (6, 7) can be triggered. Approvals must complete before ERP numbers are written back (8, 9). Rebate write-back strategies (18, 19) depend on the receipt primary keys generated by Strategies 10 and 11.

2. Code Mapping Table. Cross-system code mappings for five types of master data need to be maintained: customer, material, personnel, organization and currency. It is recommended to host a manageable mapping table inside the integration platform, initialized during implementation and automatically matched by business primary key at runtime.

3. Regional Splitting. Since rebate documents and receipts are settled separately for Beijing, Shanghai and Shaanxi organizations, Strategy 10 and 11 handle the conversion separately. Strategies 12 through 17 further split the receipt-to-flow synchronization into six flows by region and income/expense type. This split avoids synchronization delays caused by oversized batches and makes regional troubleshooting easier.

4. Idempotency and Retry. Each strategy should perform deduplication by business primary key or document number. Strategies that write into the ERP need to catch duplicate-document exceptions and skip them. Network or transient failures should support automatic retry; only persistent failures should enter the dead-letter queue.

5. Privacy Masking. DingTalk alert messages must not include sensitive fields such as customer names and amount details. Only error codes, source strategy identifiers and brief descriptions should be exposed to prevent operational data leakage in group messages.

6. Credential Management. Authentication information for Fenxiangxiaoke, Yonyou NCC and DingTalk should be stored uniformly in the integration platform's environment variables or secret management module, and must not be written directly into strategy configurations.

Best Practices

• Master data before business documents: During go-live, prioritize customer and personnel master data mapping. Only after stabilization should order and financial synchronization be enabled to reduce the issue surface during joint debugging.
• Off-peak scheduling: Place master data runs in the early morning, business documents on short incremental intervals, and financial jobs at intervals matching business density to avoid resource contention at peak hours.
• Observability: Each strategy should record processed count, success rate, latency and failure details. Alerts should be classified by severity and routed to different DingTalk groups.
• Phased rollout: Run the full chain first for a single organization (e.g., Beijing), then expand to Shanghai and Shaanxi. This allows gradual validation of the regional splitting logic in Strategies 10 through 19.
• Bidirectional write-back verification: After ERP numbers are written back, perform a lookup verification on the CRM side to ensure the written value matches the actual ERP document.