Kingdee KIS Private Cloud and Xiaoman OKKICRM Supply Chain Integration: 8-Strategy Bidirectional Architecture and Implementation
Scenario and Value
In supply chain collaboration and CRM-ERP unification scenarios, business teams typically require that master data such as customers, products, and inventory remain consistent between ERP and CRM, and that key documents such as sales orders can flow across systems. Kingdee KIS Private Cloud serves as the back-end ERP, managing materials, inventory, sales orders, and business partners, while Xiaoman OKKICRM owns customer profiles, sales processes, and product data. This solution targets that typical scenario by deploying 8 integration strategies to achieve bidirectional synchronization of master data and business documents between the two systems, reducing inconsistencies and inventory reconciliation gaps caused by manual duplicate entry.
Integration Architecture and Data Flows
The overall architecture adopts a three-layer "source – middleware – target" model. The sources are KIS Private Cloud (materials, customers, employees, sales orders, instant inventory) and Xiaoman OKKICRM (products, customers, sales orders). The middleware layer handles code mapping, field transformation, exception retry, and DingTalk alert push.
Data flows are organized by object type:
- Master data flow: KIS materials → Xiaoman products, mapped via FNumber/product_no; Xiaoman customers → KIS customers, mapped via serial_id/company_id and FNumber; KIS customers, KIS employees, and Xiaoman materials serve as query-only data sources for downstream business document code mapping.
- Business document flow: Xiaoman sales orders (header + product_list) → KIS sales orders (header + line items); customer, material, and employee codes are resolved via hub lookup or mapping tables.
- Inventory flow: KIS instant inventory is queried by FMaterialNumber + FStockNumber and mapped to Xiaoman product_no + warehouse code, supporting inventory reconciliation and inventory display.
In terms of strategy dependencies, the 3 query-only strategies run in parallel as the lookup foundation; master data sync (materials → products, customers → customers) starts in parallel once query-only is ready; sales order sync depends on master data completion; instant inventory sync runs at 06:00 daily or on a periodic schedule; DingTalk alert push is triggered by exception events.
Interface List
| Integration Strategy | Source Platform | Target Platform | Data Object | Sync Direction |
|---|---|---|---|---|
| [Query Only] KIS Customers | Kingdee KIS Private Cloud | Middleware | Customer | Query |
| [Query Only] KIS Employees | Kingdee KIS Private Cloud | Middleware | Employee | Query |
| [Query Only] Xiaoman Materials | Xiaoman OKKICRM | Middleware | Product/Material | Query |
| KIS Material → Xiaoman Product | Kingdee KIS Private Cloud | Xiaoman OKKICRM | Material/Product | KIS → Xiaoman |
| Xiaoman Customer → KIS Customer | Xiaoman OKKICRM | Kingdee KIS Private Cloud | Customer | Xiaoman → KIS |
| Xiaoman Sales Order → KIS Sales Order | Xiaoman OKKICRM | Kingdee KIS Private Cloud | Sales Order | Xiaoman → KIS |
| KIS Instant Inventory → Xiaoman Inventory Query | Kingdee KIS Private Cloud | Xiaoman OKKICRM | Instant Inventory | KIS → Xiaoman |
| DingTalk Alert Push | Middleware | DingTalk | Exception Notification | Event-triggered |
Implementation Points
Execution Stages and Order
Stage 1 starts the 3 query-only strategies in parallel, recommended to schedule within 7:00–22:00 at their respective frequencies. Stage 2 starts material → product and customer → customer in parallel after query-only stabilizes. Stage 3 runs sales order sync serially. Stage 4 runs instant inventory sync at 06:00 daily or on a periodic schedule. DingTalk push is event-triggered passively.
Key Configuration Items
- Incremental fields: KIS uses FModifyTime and StartDate/EndDate as incremental conditions; Xiaoman uses start_time/end_time and order_time.
- Full sync trigger: Manual triggering per strategy or scheduled full sync is supported, e.g., weekly full sync on Sundays.
- Code mapping: Materials, customers, employees, currencies, and units must be maintained in mapping tables or resolved via hub lookup in the integration layer.
- DingTalk push: Exceptions are pushed to DingTalk groups; push content excludes sensitive fields.
- Privacy desensitization: Receiver names, phone numbers, and similar fields are desensitized before being written to downstream systems as needed.
Field Examples
Core fields of instant inventory include FMaterialID, FMaterialNumber, FStockID, FStockNumber, FBUQty, FBUUnitName, FCUUQty, FCUUnitName, FAuxPropID, FBatchNo, FMaturityDate, etc. Core fields of KIS customers include FItemID, FNumber, FName, FFullName, FModifyTime, etc. The core field structure of KIS employees mirrors that of customers. Core fields of Xiaoman materials include product_id, product_no, name, group_id, group_name, etc.
Best Practices
- Lay the foundation with query-only strategies: Run KIS customers, KIS employees, and Xiaoman materials as upstream lookup sources before business document sync, avoiding downstream document failures caused by missing master data.
- Phased rollout: Strictly follow the order of query-only → master data → business documents → inventory. Validate each phase independently before moving to the next, simplifying fault localization.
- Incremental + periodic full sync dual track: Pull by incremental fields in daily operations, and trigger a periodic full reconciliation (e.g., weekly) to compensate for the risk of missed incremental records.
- Centralized code mapping maintenance: Manage mappings for materials, customers, employees, currencies, and units centrally in the middleware layer to prevent inconsistency caused by scattering across strategies.
- Desensitize exception push: DingTalk alert content carries only strategy name, error summary, and timestamp. Sensitive fields are excluded from notifications to reduce the risk of information leakage.