Kingdee Real-time Inventory → Lingxing ERP Adjustment Order: Full Implementation of a Single Strategy
What This Strategy Solves
In a multi-organization, multi-warehouse retail business, one enterprise uses Kingdee Cloud Skylight as the financial and inventory source of truth, while Lingxing ERP holds the inventory view for e-commerce fulfillment. Whenever the two sides diverge, financial reconciliation, platform inventory alerts, and sellable quantities all break down. We used the Qeasy (Qingyiyun) Data Integration Platform to turn Kingdee's real-time inventory into inventory adjustment documents in Lingxing, making every adjustment traceable, replayable, and auditable.
Data Flow and Field Mapping
The overall flow is Kingdee Cloud Skylight (real-time inventory) → Qeasy middleware → Lingxing ERP (inventory adjustment document). The source does not write directly to the target; differences and field normalization happen in Qeasy first.
| Domain | Source: Kingdee real-time inventory | Middleware: Qeasy processing | Target: Lingxing adjustment document |
|---|---|---|---|
| Organization | Inventory org code | Code mapping table (centrally maintained) | Lingxing shop/warehouse code |
| Material | Material code + name | Material code mapping (SKU ↔ platform SKU) | Platform product code |
| Quantity | Real-time quantity | Compare with Lingxing current stock, diff goes to adjustment | Adjustment qty (positive/negative) |
| Unit price | Inventory unit cost | Apply business rule (moving average / standard) | Adjustment unit price |
| Reason | — | Trigger reason flag (stocktake / variance / opening) | Adjustment reason field |
| Document date | Business date | Take source business date or processing date | Document date |
Qeasy's centralized code mapping shines here: when a source code changes, all downstream strategies follow automatically — no more "Kingdee changed the material, Lingxing still reconciles by old code."
How to Configure in Qeasy
In an actual project, we usually deliver this in five steps:
- Source extraction: Configure the Kingdee real-time inventory interface, pull incrementally by org + warehouse + material, and identify the incremental anchor (typically the last successful update timestamp).
- Middleware processing: Add a data processing node in Qeasy to do code mapping, difference calculation (source real-time stock − Lingxing current stock = adjustment qty), field normalization, and null-value fallbacks.
- Target write: Call Lingxing ERP's inventory adjustment write interface. We recommend a phased approach — header first, then line items — to reduce first-time integration complexity.
- Exception handling: Failed writes enter the retry queue automatically; records with no mapping go to a "pending manual maintenance" branch to prevent dirty data in the target.
- Monitoring and alerts: Enable Qeasy's run logs, success-rate dashboard, and failure alerts. Watch the first 3 days on an hourly window.
Implementation Steps
We recommend a three-phase rollout at customer sites: Incremental anchor → Full baseline trigger → Schedule frequency.
- Phase 1: Incremental anchor confirmation. In a test environment, get single-org, single-warehouse incremental pull working first. Lock in the incremental field (usually last-modified timestamp or inventory update serial) and persist it as Qeasy's sync state for all subsequent runs.
- Phase 2: Full baseline trigger. Before going live, run a full baseline: pull real-time inventory across all orgs and warehouses in Kingdee, take a diff snapshot against Lingxing, and settle historical differences through adjustment documents. After the baseline settles, switch to incremental. The dual-track (full + incremental) pattern is one of the most common practices among Qeasy customers.
- Phase 3: Schedule frequency. Real-time inventory is latency-sensitive but does not need per-second polling. We suggest every 15–30 minutes, tightened to 5 minutes during peak hours, and relaxed to 1 hour overnight to ease source-system load. Qeasy's scheduler supports time-window differentiated configuration.
Lessons Learned
A few real pitfalls from customer sites, written for engineers who come after us:
- No centralized code mapping. In one early build, mappings were hardcoded in scripts. When Kingdee added new materials, Lingxing didn't follow, producing dozens of dirty adjustment records over two weeks. The safe approach is to put everything into Qeasy's code mapping table — source changes auto-refresh downstream.
- Ignoring deleted/invalidated inventory records. Some org-warehouse-material combinations in Kingdee become inactive when warehouses close. Without a "do not generate" judgment, Lingxing keeps producing meaningless zero-difference documents. Add an active org/warehouse whitelist in the middleware.
- Random adjustment reasons. Writing "system difference" as the reason makes financial tracing impossible. Ask the business side for a finite, enumerable reason set and pin it in configuration.
- Switching to incremental before baseline settles. Going incremental first and then running full causes duplicates and doubled amounts. Always run the full baseline, confirm zero difference, then switch to incremental.
- Timezone and date field traps. Kingdee and Lingxing interpret document dates with different timezones, so cross-day scheduling can mix yesterday's and today's differences. Explicitly lock timezone and date-truncation rules inside Qeasy.
When It Applies and When It Doesn't
Applies: Kingdee is the inventory source of truth and Lingxing is the fulfillment view; multi-org and multi-warehouse setups that need traceable adjustments; enterprises wanting automated variance handling to reduce manual reconciliation cost.
Does not apply: When the source inventory itself is estimated and cannot provide accurate increments; when the target has no adjustment-document interface and can only overwrite current-stock fields; or for low-frequency scenarios where monthly close is enough.