Overview of KIS Private Cloud and OKKICRM Supply Chain Integration
Scenario and Value
In a supply chain collaboration project at one manufacturing enterprise, the sales team enters orders in OKKICRM while production and inventory are tracked in Kingdee KIS Private Cloud. Orders used to be exported manually each day and re-entered into the ERP, which meant order status lagged behind and inventory numbers never aligned. During peak promotional periods, business teams only noticed afterwards that some orders had never reached the production plan.
The integration has a single objective: build a closed loop across three layers — master data, business documents, and inventory — between OKKICRM and KIS. CRM is the order entry point, ERP is the system of record for production and inventory, and the integration layer has to align codes on both sides, separate incremental from full syncs, and surface exceptions in a chat group rather than burying them in logs.
The overall design covers eight integration strategies around master data, sales orders, and real-time inventory, supporting bidirectional sync and query-only flows for supply chain collaboration and CRM-ERP unification.
Integration Architecture and Data Flow
The architecture follows a typical "two systems + central integration layer" pattern. Kingdee KIS Private Cloud holds materials, customers, sales orders, and real-time inventory as the authoritative store (note: sales orders flow the other way, from OKKICRM into KIS). OKKICRM owns CRM-side customers, products, and sales order entry. The central integration layer handles code translation, incremental detection, retry, and DingTalk alerting.
┌─────────────────┐ ┌─────────────────┐
│ KIS Private Cloud │ │ OKKICRM │
│ (Materials/Cust/ │ │ (Products/Cust/ │
│ Employees/Orders/│ │ Sales Orders) │
│ Inventory) │ │ │
└────────┬─────────┘ └────────┬─────────┘
│ │
│ Material→Product Customer←Customer │
│ Inventory→ Query-only │
│ Sales Order← │
└───────────────┬───────────────────────┘
┌───────▼───────┐
│ Integration / │
│ ETL Middleware │
│ Mapping/Retry │
│ DingTalk Alert │
└───────────────┘
The data flow is split into four dependency-driven stages:
- Stage 1 (parallel, 7:00–22:00): Three query-only strategies — KIS customer, OKKICRM material, KIS employee — serving as lookup sources for subsequent code mapping.
- Stage 2 (parallel): KIS material → OKKICRM product; OKKICRM customer → KIS customer. Bidirectional master data sync landing in each side's master table.
- Stage 3 (serial): OKKICRM sales orders (header + product_list) → KIS sales orders (header + detail lines), depending on Stage 2.
- Stage 4 (serial, recommended daily at 06:00): KIS real-time inventory → OKKICRM inventory view, pulled by FMaterialNumber + FStockNumber and mapped to product_no + warehouse code.
Event-driven: when any strategy fails, the integration layer pushes an alert to DingTalk without carrying sensitive fields.
Interface List
| Strategy ID | Data Object | Sync Direction | Notes |
|---|---|---|---|
| S1 | Material → Product | KIS → OKKICRM | Master data, FNumber/product_no mapping |
| S2 | Customer | OKKICRM → KIS | Master data, serial_id/company_id ↔ FNumber |
| S3 | KIS Customer | KIS → Hub | Query-only, for code mapping lookups |
| S4 | OKKICRM Material | OKKICRM → Hub | Query-only, for code mapping lookups |
| S5 | Sales Order (header + detail) | OKKICRM → KIS | Business data, depends on S1/S2/S7 |
| S6 | Real-time Inventory | KIS → OKKICRM | Business data, depends on S1 |
| S7 | KIS Employee | KIS → Hub | Query-only, for sales order employee mapping |
| S8 | DingTalk Alert | Integration → DingTalk | Event-triggered, on failure |
Implementation Essentials
Phased scheduling. Master data must run before business documents, and business documents before inventory display. This rule was learned the hard way: in one project the team pushed sales order strategies fully in parallel, and the material codes in those orders had not yet landed in the OKKICRM product table, so the whole batch failed. The safe approach is to place master data and query-only strategies in Stages 1–2, business documents in Stage 3, and inventory in Stage 4 — a serial structure that prevents misalignment.
Incremental fields and full-sync fallback. Incremental fields are not symmetric across the two systems: KIS relies mainly on FModifyTime plus StartDate/EndDate windows, while OKKICRM uses start_time/end_time, with sales orders additionally using order_time. Recommended scheduling: incremental polling every 5–15 minutes, full-sync fallback weekly (e.g. early Sunday morning), triggered manually or on schedule, to cover any window miss.
Centralized code mapping. Materials, customers, employees, currencies, units — all depend on a unified mapping. We use the Qeasy (轻易云) Data Integration platform's Hub for centralized code management: master data sync writes mappings back, business documents read mappings before write-in, and any unmapped code is intercepted and routed to manual handling or an exception queue.
Retry and alerting. The integration layer records run logs and failure details for every strategy, retries with exponential backoff, and pushes a DingTalk notification on terminal failure. Alerts carry only strategy name, error code, and document number — no phone numbers or recipients.
Privacy handling. Before writing sales orders into the ERP, recipients and phone numbers are masked or hashed according to customer rules; raw values stay on the CRM side, and the integration layer does not persist sensitive plaintext.
Best Practices and Pitfalls
- Two-phase header/detail write. A sales order has a header plus a product_list. The classic mistake is pushing the entire order to KIS at once, then failing the whole order when any single detail row has a missing code. We use a two-step commit — header first, then details — so failure granularity drops from whole order to single line, with rollback on detail failure.
- Split routing between Qimen and non-Qimen channels. KIS Private Cloud sometimes exposes both Qimen and non-Qimen interfaces to upstream systems. The integration layer routes by warehouse or document type so that a failure on one channel does not take down the other.
- Do not force-merge when inventory definitions differ. KIS real-time inventory is pulled by FMaterialNumber + FStockNumber, OKKICRM uses product_no + warehouse code. Map first, then compare, and send any difference to a reconciliation report instead of overwriting on either side.
- Query-only strategies are not decorative. The three query-only strategies — KIS customer, KIS employee, OKKICRM material — were once questioned on site as "nobody reads them anyway." In reality, sales orders and inventory both rely on them for code lookup. Turning them off is equivalent to turning off the translator for every downstream strategy.
When to Use Qeasy
When your supply chain collaboration requires a closed loop across master data, business documents, and inventory between ERP and CRM — with centralized code mapping, dual-track incremental and full scheduling, automatic retry with DingTalk alerting, and sensitive field masking on landing — the Qeasy Data Integration platform can package these eight strategies into reusable integration templates running reliably in a private deployment.