SQL Server and Wandiantong Supply Chain Integration Overview: Purchase Persistence, Step-wise Transfer Push, and Douyin Inventory Sync

Scenario and Value

In a multi-channel retailer's daily operations, purchase requisitions are aggregated from stores into the group's ERP and eventually need to become sellable inventory across e-commerce channels. In between sit three systems: the purchase requisition system, the ERP, and the e-commerce mid-platform. During a promotion, reconciliation across purchasing, transfer, and inventory typically surfaces only on the third day after the event. The bottleneck is not slow ERP polling — it is the absence of any automated closed loop across the full chain: requisition persistence, step-wise transfer order to purchase order, and Douyin-channel inventory sync.

In one real engagement we saw exactly this pattern: purchase requisitions in the upstream system had to be manually exported and loaded into SQL Server for BI; step-wise transfer orders from the group ERP had to be re-entered into the e-commerce mid-platform as purchase orders by operations; and whether Kingdee Cloud's real-time inventory matched Douyin store availability depended on next-day manual counts.

This integration plan is built around that chain. It binds three independent strategies into an observable, retryable, staggered data flow, shifting procurement-to-inventory coordination from manual fallback to automated fallback.

Integration Architecture and Data Flow

The architecture has three layers: upstream business systems, the integration middle layer, and target systems.

┌─────────────────────┐     ┌─────────────────────┐     ┌─────────────────────┐
│  Requisition System │     │  Group ERP          │     │  Kingdee Cloud      │
│  (Purchase Req.)    │     │  (Step-wise Transfer)│     │  (Real-time Inv.)   │
└──────────┬──────────┘     └──────────┬──────────┘     └──────────┬──────────┘
           │                           │                           │
           │ Strategy 1                │ Strategy 2                │ Strategy 3
           ▼                           ▼                           ▼
┌──────────────────────────────────────────────────────────────────────────────┐
│                     Qeasy Data Integration Platform                           │
│       Scheduling / Transform / Mapping / Retry / Full Resync                 │
└──────────────────────────────────────────────────────────────────────────────┘
           │                           │                           │
           ▼                           ▼                           ▼
┌─────────────────────┐     ┌─────────────────────┐     ┌─────────────────────┐
│  SQL Server         │     │  Wandiantong         │     │  Wandiantong         │
│  (Requisition DB)   │     │  Enterprise Qimen    │     │  [Douyin Channel]   │
└─────────────────────┘     └─────────────────────┘     └─────────────────────┘

The data flow proceeds in three independent segments:

• Strategy 1 (Requisition persistence): Requisition master + detail rows → SQL Server tables t_purchase_apply and t_purchase_apply_detail. Incremental filter on created_time/modified_time; full resync supported for initial load or repair.
• Strategy 2 (Transfer to purchase order): Group ERP step-wise transfer order → Wandiantong purchase_order_push interface. The transfer order number FBillNo is written as outer_no to ensure idempotency. Material, supplier, and warehouse code mappings are maintained centrally in the middle layer.
• Strategy 3 (Inventory sync to Douyin): Kingdee Cloud real-time inventory → Wandiantong Douyin-channel inventory sync interface. Only inventory hitting the configured Douyin shop/warehouse mapping is synced, preventing dirty data from polluting other channels.

Interface List

The three strategies have no strong execution-order dependency and can run in parallel. We still recommend staggering by 2–5 minutes to avoid API rate limits on the Wandiantong open platform.

Implementation Points

Staged scheduling: Strategy 1 every 5–10 minutes, Strategy 2 every 10–15 minutes, Strategy 3 every 15–30 minutes. They run concurrently but start at offset times, balancing freshness against peak QPS.

Incremental fields and full resync: Strategy 1 uses created_time/modified_time; Strategy 2 uses audit time/FModifyDate; Strategy 3 can use inventory change time or full-difference reconciliation, the latter being useful for initial load or repair.

Centralized code mapping: Material code → spec_no, supplier code → provider_no, warehouse code → warehouse_no, shop code → shop_no. These mappings are a prerequisite for the entire integration to function. On the customer site we used Qeasy's mapping component so mappings are maintained centrally and propagate to every strategy on change.

Exception retry: Wandiantong APIs occasionally time out or rate-limit. Tasks need automatic backoff retry rather than hard failure. Retry count, backoff curve, and timeout thresholds must be explicit in the scheduler configuration.

Privacy handling: Database connection strings, Wandiantong open platform authentication, API keys, and similar must live in the platform's environment variables / credential vault. The solution document only carries field mappings and process descriptions — never real credentials.

Best Practices and Pitfalls

1. Centralize code mappings; do not scatter them across strategies. In one real engagement we saw material mapping hard-coded inside one strategy's transform script. After a Wandiantong-side product cleanup changed spec_no, three strategies had to be patched separately, and one was easy to miss. Consolidate mappings into Qeasy's mapping center and ongoing maintenance cost drops sharply.

2. Persist header and detail in phases, not as one monolithic upsert. Strategy 1's requisition is a master-detail structure. A typical mistake is to assemble both tables and upsert them in one go: if one detail row fails validation, the whole batch rolls back, and on retry the master is rewritten. The robust pattern is to write the master first, then the details. A detail failure does not corrupt already-persisted master data, and retry only targets the details.

3. Distinguish Qimen and non-Qimen channels. Wandiantong Enterprise Qimen exposes interfaces such as purchase_order_push through the Qimen gateway; Wandiantong Flagship uses a different set of open interfaces. Authentication and field naming differ. We have seen the Qimen endpoint accidentally configured against the Flagship channel, producing persistent 401s. In this plan, Strategy 2 and Strategy 3 target different channels explicitly, avoiding mix-ups.

4. Filter inventory by channel; do not push everything. Kingdee Cloud inventory is shared across channels, but each Wandiantong channel (defined by shop_no/warehouse_no combinations) should only receive its own slice. Without filtering, a Douyin channel's inventory gets polluted by changes from other channels, leading to over-sell or stock-out.

5. Stagger scheduling rather than fully concurrent. Three strategies running concurrently is fine most of the time, but during promotions Wandiantong tightens rate limits and all three can return 429 simultaneously. A 2–5 minute stagger flattens instantaneous pressure and noticeably improves stability.

When to Use Qeasy

If your supply chain spans multiple ERPs and e-commerce mid-platforms and you need stable staggered scheduling with centralized mapping management, Qeasy Data Integration Platform turns scheduling, mapping, retry, and full resync into out-of-the-box capabilities, letting engineers focus on business rules instead of repeatedly rebuilding scheduling and retry primitives.

Supplementary Strategy Dependency Table