Kingdee Inventory Overwrites OKKICRM: A Hands-On Tutorial for Real-Time Inventory Sync

What This Strategy Solves

In many retail and distribution setups, Kingdee Cloud acts as the system of record for inventory, while OKKICRM handles front-end sales and customer operations. When a customer places an order, the stock shown must match the ERP—otherwise overselling, missed orders, and complaints pile up. The "Kingdee inventory overwrites OKKICRM" strategy has one clear goal: use ERP real-time stock to overwrite CRM-side inventory values, locking the source of truth in Kingdee while OKKICRM only displays and takes orders. This tutorial walks through end-to-end implementation of that single strategy.

Data Flow and Field Mapping

The flow is a single-direction overwrite: Kingdee Cloud → Qeasy Integration Platform (intermediate layer) → OKKICRM.

On the source side, the Kingdee inventory query API is invoked to pull current real-time stock and available quantity by material ID and warehouse ID. The intermediate layer converts Kingdee's internal material ID into OKKICRM's SKU code—this relies on centralized code mapping management: material codes are first pulled and stored by an independent "query Kingdee materials" strategy, then resolved into sku_id through a lookup collection inside the inventory sync. The target side calls OKKICRM's inventory update API to write back both real and available quantities.

Key field mapping:

How to Configure on Qeasy

On the Qeasy data integration platform, this strategy is configured as a paired source/target setup.

Source configuration: Use Kingdee Cloud's inventory query API. Declare return fields FID, FStockId, FMaterialId, FBaseQty, FBaseAVBQty in the request body. Use FMaterialId_FNumber as the primary key for idempotency. Adjust pagination to stay within Kingdee's page size limit and avoid truncated responses.

Target configuration: Use OKKICRM's inventory update API. Bind sku_id to a lookup expression—"find sku_id where sku_code equals {{FMaterialId_FNumber}}"—which embodies the centralized code mapping management pattern: instead of maintaining mappings inside every strategy, rely on a single material master result set. Bind real_count and enable_count to {{FBaseQty}}, and hard-code inventory_type=1 to indicate absolute overwrite semantics.

Orchestration: In Qeasy's strategy canvas, place "Kingdee inventory overwrites OKKICRM" at the tail of the dependency chain, explicitly declaring it depends on the upstream "Kingdee material → OKKICRM product" master data sync. The lookup collection only has data after the master data lands—if the dependency is skipped, sku_id resolution returns empty.

Implementation Steps

1. Land master data first: Run the "Kingdee material → OKKICRM product" strategy end-to-end and confirm the lookup collection is populated. This is a non-negotiable prerequisite for inventory sync.
2. Initial full trigger: Once materials are ready, manually trigger a full run of "Kingdee inventory overwrites OKKICRM" and verify every SKU's stock matches Kingdee. Run this during off-peak hours and notify business owners in advance.
3. Switch to incremental schedule: After full verification, set the source crontab to */30 7-23 * * * and the target to 1-59/30 7-23 * * *. Offsetting source and target by half a minute yields a stable near-real-time sync window covering the main business day.
4. Monitoring and alerting: Attach Qeasy's strategy dashboard; watch for three classes of anomalies—source-side empty runs, target-side 4xx/5xx, and empty field mappings. Alert when any threshold is exceeded.
5. Periodic reconciliation: Weekly, pick 10 SKUs and manually reconcile stock between Kingdee and OKKICRM to confirm the sync pipeline truly has zero drift.

Pitfalls and Lessons Learned

• Pitfall 1: Syncing inventory before master data. The lookup collection is empty, sku_id resolves to nothing, and the run reports success while every stock is zero. The safe path is to verify the master data strategy's output before triggering inventory sync.
• Pitfall 2: Using delta semantics instead of absolute overwrite. If the target side interprets writes as deltas rather than absolute values, negative adjustments from Kingdee cycle counts will accumulate and drift further away from the truth. The inventory_type=1 (overwrite) constant is mandatory—don't remove it for convenience.
• Pitfall 3: Ignoring the warehouse dimension. Kingdee tracks stock per warehouse; OKKICRM aggregates per SKU. Without filtering out virtual and in-transit warehouses on the source side, those stocks get written into the CRM, producing beautiful but business-incorrect numbers.
• Pitfall 4: Wrong idempotency key. Using FID instead of FMaterialId_FNumber as the primary key causes multi-warehouse rows for the same material to trigger redundant overwrites, leading to API rate-limiting. The safe pattern is "material code + warehouse" as a composite idempotency key.
• Pitfall 5: Schedule colliding with business peak. Half-hour syncs that land on promotion hours can pile up and overwhelm the OKKICRM side. Running source on the hour and target offset by 30 minutes is a common source-target offset pattern that mitigates this.

When It Fits and When It Doesn't

Fits: Retail and distribution scenarios where the ERP is the inventory source of truth and the CRM/frontend only displays and orders; businesses sensitive to overselling that need near-real-time (half-hour) inventory alignment.
Doesn't fit: Scenarios where the CRM must preserve independent inventory semantics (warehouse reservations, channel quotas); edge stores with poor connectivity where both systems are frequently offline—those call for offline batch processing, not real-time overwrite.