Authoritative Tutorial: Order Sync Interface Field Handbook for Xiaoman OKKI CRM and Digiwin T100
What This Interface Solves
In CRM-ERP integrated scenarios for retail/manufacturing enterprises, sales orders must flow seamlessly between the CRM (Xiaoman OKKI CRM) and ERP (Digiwin T100): the CRM serves as the order entry and customer operation hub, while the ERP handles materials, inventory, and financial fulfillment. Integrating the three core documents—orders, customers, and products—eliminates duplicate entry, code misalignment, and fulfillment delays, enabling business-finance alignment.
Interface Capability Overview
- Authentication: Digiwin T100 uses ERP account set + user credential session authentication; Xiaoman OKKI CRM uses the open platform AppID/Secret OAuth model. Both are unified as connector credentials on the integration platform side.
- Request/Response Structure: Digiwin T100 sales orders use a nested JSON structure with master + detail rows (
so_masteras an array); Xiaoman OKKI CRM orders use aproduct_listdetail row array. Both return paginated JSON. - Pagination: Both endpoints support
pageNo/pageSizepagination, recommended 100-200 records per page. Incremental sync pulls bymodifyDate(products) orstart_time~end_timewindow (customers/orders). - Idempotency Keys:
product_no,customerNo, andorder_no/numberserve as business keys for idempotent writes.
Typical Field Mapping
Product Sync (Strategy 2: Digiwin → Xiaoman)
| Source Field | Target Field | Type | Field-Tested Notes |
|---|---|---|---|
| itemNo | product_no | DIRECT | Cross-system material reference key, must be unique |
| itemName / itemSpec | name | DIRECT | Prefer itemName, fall back to itemSpec |
| itemNo | product_id | COLLECTION | Update scenario needs hub lookup of product_id |
| itemSpec | model | DIRECT | Specification/model |
| unitNo | unit | DIRECT | Unit of measure, watch dictionary consistency |
Customer Sync (Strategy 6: Xiaoman → Digiwin)
| Source Field | Target Field | Type | Field-Tested Notes |
|---|---|---|---|
| serial_id | customerNo / number | DIRECT | Customer number primary key, cross-system reference |
| 基本信息公司名称 / name | customerName | DIRECT | Prefer formal company name, fall back to name |
| 基本信息税号 | taxNo | DIRECT | Tax ID, affects invoicing |
| serial_id | id | COLLECTION | Update scenario needs Digiwin customer id lookup |
| — | status | CONSTANT | New records default to 1 (enabled) |
Order Sync (Strategy 3: Xiaoman → Digiwin)
| Source Field | Target Field | Type | Field-Tested Notes |
|---|---|---|---|
| order_no | number | DIRECT | Order number idempotency key |
| account_date | order_date | DIRECT | Date format conversion |
| company.serial_id | customerNo | COLLECTION | Requires prior customer mapping |
| currency | currency | DIRECT | Currency |
| exchange_rate | exchange_rate | TRANSFORM | If percentage, divide by 100 |
| amount | amount | DIRECT | Order total amount |
| product_list | so_detail (detail rows) | ARRAY | Encapsulate per Digiwin API spec |
| product_list.sku_no/goods_no/product_no | itemNo | DIRECT | Requires aligned material codes |
| product_list.quantity | qty | DIRECT | Quantity |
| product_list.price | price | DIRECT | Unit price |
How to Configure on Qeasy
On the Qeasy Data Integration Platform, official adapters are pre-built for both Xiaoman and Digiwin. Order sync typically uses a "Strategy Orchestrator + Field Mapper" combination: QUERY_ONLY strategies first establish product/customer hubs, then SYNC strategies drive order writes; the platform maintains the LAST_SYNC_TIME window and auto-retries. The Qeasy field mapper supports five rule types—DIRECT, COLLECTION, TRANSFORM, CONSTANT, ARRAY—directly reusable from the tables above. Detail rows are mapped 1:1 via the array expander from product_list to so_detail, and idCheck plus idempotency keys are automatically injected by the platform.
Cross-Strategy Field Insights
- Build Hubs Before Syncing: Across multiple customer projects, we always run the "Query Xiaoman Products" and "Query Digiwin Customers" QUERY_ONLY strategies first to land the code mapping table in the hub, which is essential for stable lookups in subsequent sync strategies.
- Align Material Codes First: Xiaoman orders → Digiwin orders heavily depend on consistent material codes; ensure the Digiwin → Xiaoman product sync runs first, or maintain a unified encoding rule across both systems.
- Dual-Field Customer Primary Key: Digiwin's customer primary key consists of both
customerNoandid; always enable idCheck—usecustomerNofor inserts, and write backidfor updates. - Filter Approved Orders: For Xiaoman orders, apply
approval=1to avoid pushing drafts or voided orders to the ERP, which would cause phantom inventory holds. - Stagger Window Timings: Simultaneous pulls across strategies trigger API throttling; offset Crons by 1-2 minutes, e.g.,
1-59/5,3-59/5,5-59/10. - Decouple Notifications & Cleanup: WeChat/Lark push and 30-day log cleanup should be scheduled independently, offset from business strategies to prevent mutual blocking.
Pitfall Retrospective
- Common Pitfall: Digiwin
itemNameanditemSpecoverlap semantically; direct concatenation results in over-long product names in Xiaoman. The safe approach is to apply priority-based selection. - Exchange Rate Unit Trap: Xiaoman's
exchange_ratemay be a percentage (e.g., 685 means 6.85); direct passthrough inflates the amount by 100x. Always apply ÷100 in the TRANSFORM rule. - Detail Row Array Wrapping: Digiwin's
so_mastermust be an array structure; some engineers mistakenly pass an object and get the whole order rejected. Always use the platform's array expander. - Don't Retry on Lookup Failure: Retrying on missing code mappings just wastes quota. Correct approach: write to the failure table, trigger an alert, manually complete the code, then rerun.
- Cleanup Misconfig Risk: A misconfigured 30-day cleanup window could wipe live data. Safe approach: dry-run statistics first, then execute deletion.
When to Use
Suitable for mid-to-large enterprises requiring CRM-ERP integration with unified order/customer/product data centers. For single-direction (e.g., CRM→ERP only) or minimal document scenarios, the hub strategies can be trimmed. For deeper scenarios involving financial general ledger or invoicing, layer dedicated financial module design.