Master Data Sync from Lingxing Auxiliary Materials to Kingdee Cloud Materials: A Qeasy Hands-On Tutorial

What This Strategy Solves

Pushing auxiliary-material master data from Lingxing ERP to Kingdee Cloud looks like a trivial table copy. In practice, a poorly designed code mapping or description convention will cause reconciliation drift within three months. Using the Qeasy Data Integration Platform, we deliver this strategy as a stable, low-latency foundation for downstream procurement, sales, and inventory flows.

Data Flow and Field Mapping

End-to-end flow: Lingxing ERP (source, incremental pull of auxiliary-material list by create_time) → Qeasy middleware (mapping, code completion, cleansing) → Kingdee Cloud material (target, batchSave).

Representative field mapping:

Semantic	Source (Lingxing aux API)	Middleware Handling	Target (Kingdee batchSave)
Unique code	sku	Pass-through, used as the dedup key	FNumber
Material name	product_name	Pass-through	FName
Description / spec	declaration.customs_declaration_spec	Pass-through, fallback to empty string	FDescription
Create org	—	Constant 100	FCreateOrgId
Use org	—	Constant 100	FUseOrgId
Source internal id	id	Idempotency hint only	—
Pull window	create_time_start/end	Variables {{LAST_SYNC_TIME}} / {{CURRENT_TIME}}	—

Note: setting both id to 0 and idCheck=true lets the target system dedupe by code, which is the reliable pattern for Kingdee material.

How to Configure in Qeasy

On the Qeasy platform, configure the strategy in three parts: source connector, target connector, and the integration flow.

Source connector (Lingxing ERP): API /erp/sc/routing/data/local_inventory/productAuxList, POST, WebAPI type, QUERY effect. Hard-code offset=0, length=100, and bind create_time_start/create_time_end to {{LAST_SYNC_TIME}} and {{CURRENT_TIME}}. Enable autoFillResponse so the response schema is auto-discovered.
Target connector (Kingdee Cloud): API batchSave, POST, EXECUTE effect. Set FCreateOrgId and FUseOrgId to constant 100; bind FNumber, FName, FDescription to source fields via variables.
Flow orchestration: pull → map → batch submit → log. A common pattern among Qeasy customers is to keep code mapping in a centralized node that handles special characters, empty-value fallback, and length truncation. This node becomes reusable for sibling strategies such as "Lingxing Product → Kingdee Material".
Idempotency: rely on the target system's code-based dedup (idCheck=true); keep the middleware light, avoiding hard deduplication that could block legitimate writes.

Implementation Steps

We recommend a three-phase rollout.

Phase 1: Incremental baseline. Run an initial full backfill by create_time, then switch to the incremental window using {{LAST_SYNC_TIME}} and {{CURRENT_TIME}}. Source cron 58 0 * * *, target cron 59 0 * * * — source first, target second, naturally serializing pull-then-write.

Phase 2: Full reconciliation trigger. Schedule a weekly full reconciliation (e.g., Sunday 02:00) to catch anything missed during incremental runs. Configure it as a separate timer in Qeasy, running alongside the daily incremental.

Phase 3: Stabilize the cadence. Daily incremental is sufficient for auxiliary materials; over-frequent pulls only stress upstream APIs. Once Lingxing batches move to hourly granularity, then revisit and tighten the cron.

Lessons Learned

Empty descriptions break batchSave. declaration.customs_declaration_spec is sometimes empty while FDescription is required. A typical failure is letting batchSave fail the whole batch; the safer move is to fall back to an empty string in the middleware.
Case-sensitive SKU mismatches. Lingxing usually sends uppercase SKUs while legacy Kingdee codes mix cases, producing "same item, different code". The wrong move is direct pass-through; the right move is to uppercase and trim in the mapping layer.
Hidden 100-row page cap. The source defaults to length=100. Many teams forget pagination and silently get only the first 100 rows. Enable auto-pagination in Qeasy and detect the next-page indicator.
Hard-coded org constants. Hard-coding FCreateOrgId/FUseOrgId to 100 forces a full reconfiguration when multi-org customers switch organizations. Bind orgs via a lookup dictionary and pass them dynamically per material.
Missing baseline timestamp. If you don't persist the initial LAST_SYNC_TIME, the second run silently drops data. Persist CURRENT_TIME after every run as the next baseline.

Applicable and Non-Applicable Scenarios

Applicable: auxiliary/finished SKU sets at the ten-thousands scale, daily-level change frequency, target systems that dedupe by code in supply-chain integration. Not applicable: real-time sub-second material status sync, multi-language/multi-currency complex specifications, or private deployments where batchSave is not exposed.