Supply Chain Integration Design: OKKICRM to Kingdee Cloud Cosmic

Scenario and Value

In order-driven supply chain operations, the coordination efficiency between CRM and ERP directly determines the timeliness of order fulfillment and financial reconciliation. A certain outdoor goods enterprise needs to maintain customers, products, and sales orders in its CRM, while the ERP handles material master data, outbound execution, real-time inventory, and receipt accounting.

The two systems naturally suffer from scattered master data, unsynchronized document status, and disconnected inventory and payment information. After orders are created in the CRM, they have to be manually re-entered in the ERP. Once outbound is completed in the ERP, the order status in the CRM cannot be updated automatically. After receipt bills are entered in the ERP, the CRM lacks corresponding payment records.

This article presents a bidirectional integration design covering master data, sales orders, inventory, and financial collection. It contains 8 integration strategies: 6 data synchronization strategies and 2 query-only strategies. Through standardized field mappings, explicit execution dependencies, and configurable scheduling, the design connects the key documents of CRM and ERP, keeping order fulfillment status, inventory, and payment information consistent on both sides.

Integration Architecture and Data Flow

The overall architecture follows a three-stage execution model: master data first, then sales orders as the core, and finally status writeback and financials. The master data stage executes material, customer, and product synchronization and queries in parallel; the order stage delivers CRM sales orders to the ERP; the status writeback stage delivers the ERP outbound quantities and receipt bills back to the CRM, and synchronizes real-time inventory.

┌─────────────────────┐                    ┌─────────────────────┐
│   OKKICRM           │                    │  Kingdee Cosmic     │
├─────────────────────┤                    ├─────────────────────┤
│ Product ←───────────│ Material           │ BD_MATERIAL         │
│ Customer ──────────→│ Customer           │ BD_Customer         │
│ Sales Order ───────→│ Sales Order        │ SAL_SaleOrder       │
│ Sales Order ←───────│ Outbound Status    │ SAL_SaleOrder(FQty) │
│ Inventory ←─────────│ Inventory          │ STK_Inventory       │
│ Receipt ←───────────│ Receipt Bill       │ AR_RECEIVEBILL      │
└─────────────────────┘                    └─────────────────────┘
         ↑                                           ↑
         └─────────── Query-only (for joins) ─────────┘

Execution dependencies are as follows:

• Master data first: material→product and customer→customer must execute before orders, inventory, and finance, providing master data for subsequent documents.
• Sales order core: after CRM→ERP sales order delivery, the order_no / order_id mapping can be established for outbound status updates and receipt bill lookups.
• Lookup dependency: real-time inventory, outbound status, and receipt bills all depend on cross-system lookups through business keys, ensuring that code mappings are already established during synchronization.

Interface List

Implementation Notes

Field mapping principles. All strategies use business keys as the primary join: material/product use FNumber ↔ product_no, customer uses serial_id ↔ FNumber, sales order uses order_no ↔ FBillNo, and receipt bill uses the sales order extension field to associate order_id and company_id. Constant fields (organization, group, warehouse, document type) are uniformly managed through "configured per business" placeholders, replaced at implementation time according to the tenant's actual situation.

Sales order delivery. The header maps order_no / account_date / company.serial_id / remark / company_address / customer_name / customer_phone directly to Kingdee's FBillNo / FDate / FCustId / FNote / FReceiveAddress / FLinkMan / FLinkPhone, with the document type fixed as XSDD13_SYS. Detail lines are mapped through the product_list[] array, mapping product_no → FMaterialId, quantity → FQty, price → FPrice, amount → FAmount. IsAutoSubmitAndAudit=true triggers Kingdee's auto-submit and audit.

Outbound status update. Read FQty and FStockOutQty from the Kingdee sales order and write back according to the status enum: FStockOutQty=0 → not shipped, 0 < FStockOutQty < FQty → partially shipped, FStockOutQty ≥ FQty → fully shipped. The filter conditions are FApproveDate within the last 5 hours, FBillTypeID=XSDD13_SYS, and excluding FBillNo LIKE '%XSDD%' embedded documents. This strategy depends on the query-only Kingdee outbound order providing FSoorDerno as the sales order number lookup entry.

Real-time inventory. Through the FMaterialId_FNumber → product_id lookup, the Kingdee material is converted to the CRM product ID, and FBaseQty is written to real_count / enable_count. Filtering relies on FStockId.FNumber and FUpdateTime>=LAST_SYNC_TIME.

Receipt bill → payment record. The key point lies in the amount fields: amount = FRECAMOUNTFOR + FHANDLINGCHARGEFOR + FSETTLEDISTAMOUNTFOR, real_amount = FREALRECAMOUNTFOR + FHANDLINGCHARGEFOR + FSETTLEDISTAMOUNTFOR, which must perform numeric addition rather than string concatenation. The sales order number is extracted through the extension field F_UJOP_Text_re5, and _findCollection looks up the CRM's order_id and company_id. The prerequisite is that the sales order already exists in the CRM→ERP synchronization.

Code mapping maintenance. Material codes are automatically established during synchronization; customer group, currency, salesperson, sales mode, business mode, and sales channel mappings need to be pre-maintained before customer synchronization. If missing, do not retry and maintain manually.

Best Practices

Exception handling. Network timeouts use exponential backoff (30s/60s/120s, up to 3 times); target system 5xx retries 2–3 times with 60s intervals; 4xx business validation does not retry, logs the failure and raises an alert; code mapping missing also does not retry. After retries are exhausted, write to a dead-letter queue and retain the source primary key, target primary key, error code, and timestamp in a failure record table. Idempotency control is based on business keys such as order_no / FBillNo / product_no to avoid duplicate writes.

Alert thresholds. Synchronization failure rate exceeding 5%, single strategy consecutive failures ≥3 times, critical field lookup returning empty, and incremental delay exceeding 2 scheduling cycles, all trigger immediate notifications.

Scheduling frequency. Master data (material, customer, product query) is recommended every 5 minutes, business documents (sales order, receipt bill) every 5–10 minutes, outbound status every 10 minutes, real-time inventory every 30 minutes. All scheduling is concentrated during business hours (7:00–22:00) to reduce pressure on the source system.

Execution order. Stage 1 executes material→product, customer→customer, and product query in parallel; Stage 2 executes sales order delivery; Stage 3 serially executes outbound status update, outbound order query, receipt bill→payment record, and real-time inventory.

Full and incremental. The production environment defaults to incremental, controlled by time fields such as LAST_SYNC_TIME / FApproveDate / FUpdateTime; material, customer, and product support full synchronization (remove the time filter or use a sufficiently early start time), recommended to run during non-business hours.

Privacy and security. The design document does not contain real customer names, API keys, organization codes, warehouse IDs, or other sensitive information. All configurable items are provided as placeholders, replaced by the project team according to the tenant's actual values at implementation time.