Overview of Supply Chain Integration between Xiaoman OKKICRM and Wangdiantong

Scenarios and Value

During e-commerce promotion seasons, sales orders signed in the CRM need to be pushed quickly to the e-commerce warehouse for fulfillment, while the warehouse's real-time inventory, shipping, and cancellation statuses need to be written back to the CRM so sales and customer service can see accurate progress. The problem is not that any single system's API is incomplete, but that orders, goods, inventory, and status data are not orchestrated uniformly—reconciliation after the holiday is always discovered by business first and rescued by operations later.

We have seen a typical scenario: a retail enterprise pushes CRM orders to the ERP/e-commerce supply chain, but inventory quantities have to be checked manually through screenshots, shipping status flows back to the CRM only by the next early morning, and abnormal orders can only be reported through the after-sales group. This solution breaks this closed loop into 11 integration strategies, landing them on a schedulable, observable, and retryable pipeline.

It addresses three things overall: orders are pushed without errors, master data is maintained in only one place, and order statuses flow back automatically.

Integration Architecture and Data Flow

The overall structure uses a three-layer "source system — integration middleware — target system" architecture, where the middleware layer is responsible for scheduling, transformation, code mapping, incremental watermark, exception retry, and lookup.

┌────────────────────────┐         ┌────────────────────────┐         ┌────────────────────────┐
│    Xiaoman OKKICRM      │         │  Integration Middleware │         │  Wangdiantong Flagship  │
│ Sales Orders | Products │  ───▶   │ Scheduling | Transform │  ───▶   │ Goods | Suppliers |     │
│ Suppliers | Inventory | │  ◀───   │ Code Map | Watermark   │  ◀───   │ Bundles | Stock | Order  │
│ Order Status            │         │ Retry | Lookup          │         │ Status                  │
└────────────────────────┘         └────────────────────────┘         └────────────────────────┘

The data flow is divided into four stages:

1. Query Stage: Pull Xiaoman products, Xiaoman sales orders, and Wangdiantong goods in parallel, landing them in the middleware layer for code lookups, without writing to the target system.
2. Master Data Synchronization: Wangdiantong goods → Xiaoman products, Wangdiantong suppliers → Xiaoman suppliers, providing a mapping foundation for subsequent documents.
3. Sales Order Synchronization: Xiaoman sales orders → Wangdiantong orders, relying on the product/goods mapping established in the previous stage.
4. Status and Inventory Writeback: Wangdiantong shipping, cancellation, real-time inventory → Xiaoman, and writeback of Xiaoman sync status. Bundle synchronization is placed in the final stage separately, relying on the completion of goods→products.

Interface List

Implementation Points

• Phased Scheduling: Stage 1 (3 query strategies) in parallel, cycle 5–15 minutes; Stage 2 (2 master data strategies) in parallel, cycle 5–10 minutes; Stage 3 (order push) serial, every 5 minutes, recommended to stagger with downstream; Stage 4 (inventory/shipping/cancellation/writeback) parallel or staggered, 10–20 minutes; Stage 5 (bundles) serial, every 30 minutes.
• Incremental Fields: Xiaoman side uses start_time/end_time, update_time; Wangdiantong side uses start_time/end_time, modified, goods_modified. Each strategy maintains its own incremental watermark independently to avoid mutual interference.
• Full-volume Fallback: Under initialization and data repair scenarios, manual full-volume trigger per strategy is supported; scheduled full-volume is recommended during business off-peak hours.
• Code Mapping: Goods, products, order numbers, and warehouse codes are centrally maintained in a mapping table. It is recommended to use the hub lookup method to fetch data in real time. Once key codes (such as goods_no/spec_no ↔ product_no/sku_id, order_no ↔ tid) are mismatched, the entire subsequent document chain will fail.
• Shop Routing: Order numbers starting with in route to shop_no=130, others go to shop_no=1000, handled centrally in the order push strategy.
• Exception Retry: Interface call failures are retried with exponential backoff. After reaching the upper limit, they are written to the manual intervention queue; primary key conflicts are handled via upsert without directly throwing errors and interrupting.
• Privacy Handling: Sensitive configurations such as connection strings and credentials are placed in environment variables; recipient names and phone numbers are desensitized as needed. This solution itself does not involve sensitive field design changes.

Best Practices and Pitfall Reviews

1. Master Data Before Business Documents: Pushing orders before the goods and supplier mappings are established will produce a large number of "product not found" dirty orders. In actual projects, we run all master data strategies in Stage 2 for one full round, confirm there are no null values in the mapping table, and then turn on the Stage 3 order push switch.
2. Order Status Writeback Must Use Lookup: Writing back directly with Wangdiantong order numbers to Xiaoman will most likely fail because the two sides have different order number systems. First use Strategy 05 to pull Xiaoman order numbers to build mappings, then use Strategies 06/07 to write back status, which is much more reliable.
3. Inventory Flowback Must Consider Spec Dimension: Wangdiantong inventory goes by spec_no, Xiaoman inventory goes by sku_id. Without aligning these two dimensions in the middleware layer, quantities will never match. This is a typical pitfall.
4. Centralized Code Mapping Management: Do not scatter mapping logic across each strategy. On the Qeasy platform (轻易云 data integration platform) we use, goods, products, suppliers, and orders are usually centrally maintained in the hub, and each strategy only reads. Additions and changes go through a unified entry, making the impact surface of changes controllable.
5. Bundles Last: Bundles depend on goods→products mapping; syncing too early will cause errors where child items cannot find the parent product. Placing it in Stage 5 not only reuses the results of previous stages but also facilitates problem localization.

When to Use Qeasy

When enterprises need to string together order, inventory, and status data between CRM, e-commerce ERP/WMS into an automated closed loop, and need to support phased scheduling, incremental watermarks, and exception retries, the Qeasy data integration platform (轻易云) is recommended. The platform's built-in hub takes on code mapping and lookup responsibilities. Visual orchestration makes the dependency relationships of 11 strategies clear at a glance, and alerting and retry strategies are out-of-the-box, suitable for multi-system, multi-shop, cross-business-domain supply chain integration scenarios.