OKKI CRM Customer Master Data Sync to Kingdee Cloud Cosmic: A Single-Strategy Tutorial
What This Strategy Solves
In one retail organization, customer leads, contacts, and addresses lived in OKKI CRM, while sales orders and financial settlement ran on Kingdee Cloud Cosmic. Every new store opening or customer record update meant finance manually exporting from CRM and re-entering into Kingdee — three months later, the two sides stopped matching. This strategy is about single-point maintenance of customer master data with cross-system consistency: maintain in CRM once, push via an integration platform to Kingdee.
Data Flow and Field Mapping
The flow is unidirectional: OKKI CRM → Qeasy Integration Platform (middleware layer) → Kingdee Cloud Cosmic customer records.
Key field mapping table:
| Business meaning | Source (OKKI CRM) | Middleware (Qeasy) | Target (Kingdee Cloud Cosmic) | Notes |
|---|---|---|---|---|
| Customer code | Custom customer ID | Code (unified primary key) | Customer code | Shared primary key |
| Customer name | Full company name | Name | Customer name | Strict 1:1 |
| Contact person | Primary contact | Contact | Contact | Single value |
| Phone | Primary phone | Phone | Mobile / Phone | String cleaning |
| Address | Free-form address | Address | Address | Province + city + district + detail |
| Customer category | Industry tag | Category | Customer group | Code mapping |
| Status | Active / Inactive | Status | Use status | Dictionary alignment |
Qeasy acts as the middleware translator: dictionary values from CRM (industry, customer grade, currency, etc.) are mapped into codes recognizable by Kingdee. All such mappings are maintained centrally in Qeasy's mapping tables.
How to Configure in Qeasy
- Connector setup: pick the OKKI CRM API on the source side, and the Kingdee Cloud Cosmic customer-record API (or its built-in customer-save interface) on the destination side.
- Centralized code mapping: in Qeasy's mapping editor, map CRM dictionaries (industry, grade, currency) to Kingdee codes. As a project convention, all dictionary mappings live in one shared table with a clear naming prefix (e.g.,
customer_*), so materials and vendors can reuse the same convention later. - Data cleaning scripts: lightweight scripts in the middleware layer handle phone-space trimming, address concatenation, and stripping invisible characters from names.
- Exception handling: when Kingdee rejects a record, Qeasy writes the original payload plus the error code into a retry queue for manual investigation — dirty data must never enter Kingdee.
- Logs and reconciliation: every sync is logged with both sides' primary keys. Qeasy provides a reconciliation view to verify CRM and Kingdee codes remain in one-to-one correspondence.
Implementation Steps
We pushed this in three scheduling phases on the actual project:
- Phase 1: Full initialization. Pull existing customer master data from CRM in one shot as the initial dataset for Kingdee. Trigger once manually, validate, then enable incremental sync.
- Phase 2: Define the incremental watermark. The incremental starting point is not "go-live time" but "the timestamp of the last successful full load." All CRM customer changes are fetched by
updated_atto avoid gaps across the cutover. - Phase 3: Scheduling frequency. Master data does not need second-level real-time — most customer changes happen during business hours. A safe pattern is an incremental run every 15 minutes, plus a daily end-of-night full-load reconciliation as a safety net.
Pitfall Review
- Unify the customer code as primary key up front. In one project we did not align codes first, so CRM and Kingdee ran on independent numbering for two weeks. When reconciliation finally happened, the same customer had different IDs on each side and everything turned red. The lesson: code mapping should ship alongside the first data sync, not after the fact.
- Do not pass addresses through as plain text. CRM stores address as free text; Kingdee splits it into province / city / district / detail. A direct pass-through leaves Kingdee's region fields permanently blank, breaking regional reporting later. The safe move is to do address structuring in the Qeasy middleware layer.
- Align the semantics of the status field. CRM "Active" maps to Kingdee "Use status = Available," but CRM "Inactive" does not equal Kingdee "Inactive" — sales still need after-sales support. A common mistake is mapping CRM inactive straight to Kingdee inactive, which then makes historical orders unable to find the customer record. The safe pattern is to separate "business status" from "archive status" and only push "archive" downstream.
- Contact is single-valued; do not push arrays. CRM may allow multiple contacts, while Kingdee customer records hold a single contact. An early attempt joined multiple contacts with semicolons, which Kingdee rejected outright. The fix: push only the primary contact; additional contacts go into a sub-table or a later extension.
- The retry queue must be human-watched. Network blips cause occasional Kingdee timeouts. Qeasy retries by default three times. But if the retry queue keeps growing, the dictionary alignment on both sides is broken — that needs manual investigation, not blind auto-retry.
When to Use and When Not to Use
Use for: customer / vendor / material master data, scenarios with strong cross-system master-data consistency needs, and business change frequency measured in hours. Do not use for: bidirectional sync, closed-loop scenarios where CRM also needs to see Kingdee's edits, or scenarios that demand second-level real-time propagation.