Integration Solution: OKKICRM and Jushuitan Master Data Synchronization

Scenario and Value

In one of our retail client projects, sales orders are created in the CRM, while warehouse fulfillment and e-commerce operations run on a separate ERP. Once the two systems are disconnected, products, inventory, and orders become three independent ledgers: the available quantity shown in the CRM no longer matches the warehouse reality, and the business only notices this after a promotion campaign ends. The problem is not that any single system wrote the wrong number — it is the absence of an automated closed loop.

What we need to do is bridge the gap between the CRM (OKKICRM) and the e-commerce ERP (Jushuitan), and synchronize the backbone: master data, inventory, and sales orders. Product codes are maintained in one place, inventory is visible in one place, and orders are pushed down from one place. The overall solution is split into 6 integration strategies executed in two phases — master data first, sales orders second.

Integration Architecture and Data Flow

The architecture uses the Qeasy iPaaS data integration platform as the integration hub, with OKKICRM on one side and Jushuitan (including Jushuitan·Qimen and Jushuitan Open Platform) on the other.

Architecture diagram (text description):

┌─────────────────────┐                  ┌─────────────────────
│   OKKICRM (CRM)     │                  │  Jushuitan (ERP/WMS)│
└──────────┬──────────┘                  └──────────┬──────────┘
           │                                        │
           │  Jushuitan product/inventory → OKKICRM │
           │  OKKICRM sales order → Jushuitan order │
           │  Jushuitan·Qimen order → Hub (query)   │
           │  OKKICRM product → Hub (query)         │
           ▼                                        ▼
   ┌────────────────────────────────────────────────────┐
   │   Qeasy Data Integration Platform (iPaaS)         │
   │   Code mapping / field transform / orchestration /│
   │   retry handling                                  │
   └────────────────────────────────────────────────────

Data flow by phase:

• Phase 1 — Master data: Jushuitan products → OKKICRM products; Jushuitan inventory → OKKICRM product custom fields or OKKICRM inventory; plus queries against OKKICRM products for reconciliation. The four strategies in this phase can run in parallel or staggered.
• Phase 2 — Sales orders: OKKICRM sales orders → Jushuitan sales orders, strongly depending on the product, customer, and warehouse code mappings established in Phase 1.
• Query strategies: Jushuitan·Qimen sales order queries and OKKICRM product queries have no business dependencies and can be scheduled independently, typically used for post-event reconciliation and lookup.

Interface List

Implementation Highlights

Phased orchestration. In Phase 1 (master data), strategy S3 must run first as the prerequisite for downstream inventory and order sync; S4, S5, S6 can run in parallel or staggered within the phase. In Phase 2 (sales orders), once the code mappings are in place, the strategy runs sequentially — recommended every 10 minutes during business hours. Jushuitan·Qimen order queries should run every 15 minutes for post-event lookup.

Incremental fields with full sync fallback. Use modified_begin / modified_end for Jushuitan products with a time window no longer than 7 days; use modified (inventory change time) for Jushuitan inventory; use start_time / end_time plus update_time for OKKICRM sales orders with order_no as the dedup key; use update_time for OKKICRM products. Run full sync during initial go-live or data repair, ideally between 02:00 and 04:00 during off-peak hours.

Centralized code mapping. Maintain all mappings in Qeasy's mapping center rather than scattering them across strategy scripts: material code (Jushuitan sku_id ↔ OKKICRM product_no, mapping_type=MATERIAL); customer code (OKKICRM company.serial_id ↔ Jushuitan shop_id, CUSTOMER); warehouse code (Jushuitan wms_co_id OKKICRM warehouse_code, WAREHOUSE); unit of measure (unit ↔ unit, UNIT).

Retry and alerting. Network/API timeouts use exponential backoff with up to 3 retries (30s, 60s, 120s); Jushuitan 429 throttling waits 60s before retry. Single-record failures are isolated to a sync_failed_records sink and support manual replay. Immediate alert fires when consecutive failures reach 3; a daily summary alert fires when daily failure rate exceeds 5%.

Privacy handling. Credentials and connection strings live in environment variables or a key management service. Jushuitan order recipient information (name, phone, address) is masked before persistence. The design itself does not pass through plaintext sensitive fields.

Best Practices and Lessons Learned

Lesson 1: Inventory field mismatch silently drops dimensions. Jushuitan inventory tracks four states — available, order-locked, purchase-in-transit, and transfer-in-transit — while the OKKICRM inventory module may not natively cover all of them. The typical mistake is cramming every number into a single real_count field, which makes dimensional reconciliation impossible later. The safer pattern is to first evaluate whether the OKKICRM inventory module fields are sufficient, and if not, land the inventory data into product custom fields (available stock, order-locked count, purchase-in-transit count, transfer-in-transit count) to preserve multi-dimensional breakdown.

Lesson 2: Sales order sync depends on product mapping — wrong order creates dirty data. We have seen this fail on customer sites: the sales order strategy went live before the product mapping was built, so the SKUs inside the orders were written into OKKICRM as new products, producing large amounts of duplicates. The safer pattern is to strictly serialize Phase 2 after Phase 1 — Qeasy's strategy dependency configuration can enforce this.

Lesson 3: Mixing Qimen and non-Qimen interfaces trips on authentication differences. Jushuitan exposes both the Open Platform and Jushuitan·Qimen channels, which differ in authentication, field naming, and throttling. The common pattern we apply in Qeasy is dual-channel routing: queries go through Qimen, while writes are matched to the appropriate Open Platform endpoint based on business fields — one auth scheme does not rule them all.

Lesson 4: Incremental windows that are too wide get rejected upstream. Jushuitan's incremental API enforces constraints on time window size, and oversized windows return errors. We generally cap the window within 7 days and configure automatic slicing inside Qeasy so that cross-window tasks backtrack day by day.

When to Use Qeasy

When an enterprise runs both a CRM and an e-commerce ERP and needs bidirectional synchronization of products, inventory, and orders — especially when multiple authentication channels like Qimen and the Open Platform are involved — Qeasy Data Integration Platform fits well. The platform turns code mapping, field transformation, scheduling, and retry handling into visual configurations, and with the 6 strategies executed in phases, the master data and sales order backbone can be live in roughly a week.