From LingXing Adjustment Order (Good Product Out) to Kingdee Other Outbound Order: A Single-Strategy Sync Tutorial
What This Strategy Solves
In one retail engagement, the warehouse team used LingXing ERP for bin and batch management while Kingdee Cosmic handled finance and the general ledger. When a "good product out" adjustment happened in the warehouse, the adjustment was logged in LingXing, but no corresponding voucher existed in Kingdee—finance had to key entries by hand. Within a month, dozens of mismatches piled up and month-end reconciliation turned into manual labor. This strategy pushes LingXing's "Adjustment Order (Good Product Out)" into Kingdee's "Other Outbound Order" automatically, so warehouse actions and finance vouchers stay in lockstep.
Data Flow and Field Mapping
The flow is LingXing ERP → Qeasy middleware layer → Kingdee Cosmic. The middleware does more than copy—it transforms codes, trims fields, and runs light validation.
| Business Meaning | LingXing Source (typical) | Middleware Handling | Kingdee Target (typical) |
|---|---|---|---|
| Document number | Adjustment order no. | Passed through, prefixed to avoid collisions | BillNo |
| Document date | Business date | Converted to Kingdee's date format | Date |
| Warehouse | Warehouse code | Translated via warehouse mapping table | Issue/receipt warehouse |
| Item code | SKU | Translated via item mapping table | Material code |
| Quantity | Adjustment qty | Sign normalized (good product out is always positive) | Actual issue qty |
| Batch | Batch no. | Passed through; empty if missing | Batch |
| Remark | Adjustment reason | Concatenated with "LingXing adjustment:xxx" | Remark |
Note: field names above describe business semantics; the actual interface fields depend on system metadata.
How to Configure It in Qeasy
In the Qeasy data integration platform, this strategy is a single integration flow. We typically build it in four steps:
- Source node: Choose LingXing ERP, configure authentication, and locate the query interface for the adjustment order (good product out). The incremental condition is
last_modified >= last_success_time, with a 5-minute overlap window to absorb clock drift. - Transformation node: Write a lightweight script that handles three things—code mapping (warehouse, item, reason code), sign normalization, and default values for missing fields. This is where the "centralized code mapping" pattern pays off: keep mapping tables in Qeasy's auxiliary data tables, not buried in scripts, or no one will find them three months later.
- Target write node: Choose Kingdee Cosmic and call the save interface for other outbound orders. Enable Kingdee's "deduplicate by BillNo + skip/overwrite" behavior to guarantee idempotency—otherwise repeated pushes will corrupt inventory.
- Exception branch: Network errors, field-length overflows, and unmapped codes should all route to alerts. Never let failed documents silently retry—the risk is that Kingdee's inventory goes negative.
Implementation Steps
We usually split the rollout into three phases:
- Phase 1: Align the incremental start point. Pick a frozen T0 in both systems and skip historical data—only run increments from T0 forward. Let business run for 1–2 weeks to confirm document cadence matches.
- Phase 2: Full backfill (optional). If history already has gaps, trigger a one-shot full backfill. Force this run through the "new document" channel and never overwrite already-approved Kingdee documents.
- Phase 3: Lock the schedule. Inventory documents need near-real-time freshness, so use a 5–10 minute polling cadence; tighten to 3 minutes during peaks and relax to 15 minutes off-peak. Qeasy's scheduler supports cron directly on the strategy, so no external scheduler is needed.
Once this stabilizes, the "incremental + full backfill" dual-track becomes the standard pattern: increments for day-to-day, full backfills for retrospectives and corrections.
Pitfalls and Lessons Learned
- Code mapping scattered across scripts. Our first version hard-coded
if-elsemappings inside transformation scripts; two weeks later, adding a warehouse meant code changes and a redeploy. The reliable approach is to maintain mappings in Qeasy's auxiliary data tables and hot-reload them. - Sign not normalized. LingXing's "good product out" can be positive or negative depending on the bin, while Kingdee only accepts positive values. The middleware must explicitly normalize the sign, or inventory will be subtracted in the wrong direction.
- Duplicate pushes drain inventory. The classic trap: Kingdee's deduplication by BillNo is either missing or disabled, so the same adjustment is pushed twice and inventory drops by double. Idempotency checks on the target are non-negotiable.
- Time window too narrow. Source-system clocks and integration-server clocks drift by a few minutes; using
strictly greater thanfor the incremental filter will lose boundary data. Use a multi-minute overlap and rely on document-number deduplication downstream. - Silent retry on failure. A warehouse code is suddenly disabled in Kingdee, the push fails, and the system retries 10 times—every retry fails—and meanwhile LingXing has already recorded the movement. The safer behavior is to alert immediately and pause the strategy, not to keep retrying in the background.
When It Applies (and When It Doesn't)
Applies: Dual-system setups where LingXing handles warehouse operations and Kingdee handles finance; enterprises with high adjustment-order volume and high manual-entry cost; finance-shared-service scenarios that need warehouse and finance to reconcile in real time.
Does not apply: Single-system operations (LingXing-only or Kingdee-only); inter-organization transfers (which should use a dedicated transfer strategy, not "other outbound order"); Kingdee deployments where the other outbound order document is disabled or replaced by a custom one.