Integration Solution for OKKICRM and Jushuitan Sales Orders: Master Data, Order Sync, and Shipment Status Writeback

Scenario and Value

In a real project we worked on, a retail company's sales flow was stuck between CRM order entry and warehouse fulfillment. Sales reps entered orders in OKKICRM, but the warehouse team could not see them in Jushuitan. Once the warehouse shipped the goods, no one updated the order status in CRM, so the team relied on Excel reconciliation and finance only spotted the discrepancies three days after the holiday rush. The problem was not a faulty system on either side, but the absence of an automated closed loop between CRM and WMS.

This solution addresses exactly that link: it reliably delivers sales orders from OKKICRM to Jushuitan, then writes shipment status from Jushuitan back to OKKICRM, while aligning master data such as products and product groups. The two systems then run a complete order lifecycle around a single order document. After implementation, the business no longer relies on manual data shuttling, and sales and customer service can see shipment status in real time.

Integration Architecture and Data Flow

The architecture uses the Qeasy iPaaS platform as the integration hub between OKKICRM (CRM side) and Jushuitan (WMS/e-commerce side). The two endpoints are not directly coupled; all field mapping, code conversion, and schedule orchestration happen on the Qeasy side.

The data flow progresses in four phases:

• Phase 1 – Master Data: Jushuitan products are synced into OKKICRM as products, building the sku_id ↔ product_no material code mapping that serves as the prerequisite for subsequent order sync.
• Phase 2 – Query Support: Queries against OKKICRM product groups and products run in parallel with no dependencies. Results are written only into the platform-side cache for code mapping lookups, not back into OKKICRM.
• Phase 3 – Sales Order Dispatch: OKKICRM sales orders are dispatched to Jushuitan sales orders, depending on the material mapping from Phase 1. Order numbers are prefixed with M_ to establish the order_no ↔ so_id correspondence.
• Phase 4 – Status Writeback: Shipped orders in Jushuitan are written back to OKKICRM, with the order status set to "shipped". This phase depends on the order number mapping from Phase 3 for cross-strategy lookups.

In terms of dependencies, Phase 1 and Phase 2 can run in parallel. Phase 3 must wait for Phase 1 to produce the material mapping, and Phase 4 must wait for Phase 3 to produce the order number mapping. If any link in this chain breaks, the downstream write will fail.

Interface List

Implementation Notes

Phased scheduling: Product sync is recommended every 2 hours (0 */2 * * *), order dispatch every 10 minutes (*/10 8-22 * * *), shipment status writeback every 15 minutes (*/15 8-22 * * *), and the two query strategies run once per day each. Orders outside the business hours window can be picked up at 8 a.m. the next day to avoid frequent nighttime polling.

Incremental and full sync: Strategy 1 defaults to incremental sync by update_time, with a daily full sync at dawn for reconciliation. Strategy 2 and Strategy 3 filter increments by document status and time window.

Code mapping: Material codes, customer codes, and order numbers should all be centrally managed in Qeasy's Code Mapping module, distinguished by mapping_type as MATERIAL, CUSTOMER, and ORDER. In multi-store scenarios, the company.serial_id → shop_id mapping must be built as a customer-to-store table rather than hard-coded.

Exception retries: Use exponential backoff with 3 retries on interface timeouts, and 2 retries at 60s intervals on target write failures. Missing code mappings do not retry; the record goes directly into the failure queue for manual mapping. Jushuitan's time window must not exceed 7 days; overdue orders are handled separately.

Idempotency and privacy: Status writeback must be idempotent to avoid duplicate pushes. Recipient information from Jushuitan orders should be desensitized before being stored on the Qeasy side. Credentials should be placed uniformly in a key management service and never hard-coded in schedule configurations.

Best Practices and Pitfall Retrospectives

1. Dispatching orders before the material mapping is built – A typical mistake is opening Strategy 2 before Strategy 1 has finished, which causes the sku_id in the order line to fail the product_no lookup on the OKKICRM side and the entire order to be dropped into the failure queue. The safe approach is to make Strategy 1 a hard dependency of Strategy 2 in Qeasy orchestration so the platform forces the wait.
2. Passing order numbers through transparently – Writing the OKKICRM order_no directly as the Jushuitan so_id makes the return lookup impossible. A common remedy is to add an M_ prefix and use a COLLECTION cross-solution lookup in Strategy 3 to reverse so_id back to order_id before writing the status.
3. Non-idempotent status writeback – Jushuitan may fire shipment status callbacks multiple times, and without an idempotency key the writeback duplicates updates in CRM. The safe approach is to use a composite idempotency key of so_id + status + update_time.
4. Hard-coding shop_id across multiple stores – When one customer shares a single integration across multiple stores, hard-coding shop_id sends all orders to a single warehouse. Once the customer-to-store mapping is made configurable on the Qeasy side, the problem disappears.
5. Empty nighttime runs wasting quota – Continuing to poll every 10 minutes outside business hours wastes interface quota and adds log noise. Time-windowed scheduling (8-22) noticeably improves the situation after it is applied.

When to Use Qeasy

When CRM and WMS/e-commerce systems exchange multiple document types with several code systems and multi-phase dependencies, and you need a status-driven closed-loop writeback, Qeasy Data Integration Platform is a fit as the integration hub. Strategy orchestration, code mapping, phase dependencies, exception retries, and time-windowed scheduling can all be configured uniformly on the platform side, eliminating the need to build dedicated integration interfaces in each system or maintain a separate relay service.