Syncing Supplier Master Data from LingXing ERP to Kingdee Cloud: A Single-Strategy Walkthrough

What This Strategy Solves

During supply-chain rollouts, teams often live with two systems: a LingXing ERP on the cross-border commerce side that captures supplier records first, and Kingdee Cloud as the single entry point for finance settlement and purchase orders. When vendors are keyed into both systems independently, codes drift, short names diverge, and disable flags stop matching — and payments, reconciliation, and tax filings all start to break. This strategy does exactly one thing: push LingXing-side supplier master data into Kingdee every day, keyed by supplier code, so Kingdee becomes the only settlement record of truth.

Data Flow and Field Mapping

The flow is LingXing ERP → Qeasy Data Integration Platform → Kingdee Cloud. No persistent intermediate store — the platform only reshapes fields and validates codes.

The source uses is_delete=0 to filter out voided records and avoid pushing archived vendors. The target calls batchSave, where Kingdee decides insert vs update based on the code.

Configuring This in Qeasy

On the source side, pick a WebAPI adapter of type QUERY. Declare the pagination parameters offset and length explicitly, with a default page size of 1000 to avoid hitting upstream rate limits. Only pick the fields you actually use; let Qeasy's autoFillResponse handle the rest.

On the target side, pick an EXECUTE adapter of type batchSave. Map organization and group to constants; map code, name, and short name to fields. Use {{supplier_name}} template syntax for FName, and a conditional expression for FShortName to fall back when the short name is empty.

Two patterns we see a lot among Qeasy customers: first, centralized code mapping — every code transformation and group constant lives in one place, and strategies only reference it, so a single edit propagates everywhere. Second, header-then-line staged rollout — this strategy only syncs the header, leaving contact info, bank accounts, and other line fields for phase two, which lowers first-version risk.

Implementation Steps

Step 1, fix the starting point. Full snapshot trigger: pull every valid supplier with is_delete=0 as the Kingdee initialization baseline. Incremental start: persist the set of supplier_id values that ran successfully the first time, then pull deltas by updated_at or cursor pagination daily.

Step 2, schedule frequency. The source crontab is set to 15 0 * * *, and the target to 29 0 * * *. The 14-minute offset between source and target gives the middleware a processing window and prevents the classic race where the target starts writing before the source has finished pulling.

Step 3, verify and write back. Qeasy automatically compares FNumber in the response, dispatching updates when the code exists and inserts otherwise. After the first full run, manually spot-check 5–10 vendors in Kingdee for name, short name, organization, and group, then switch to steady-state scheduling.

Step 4, monitoring and alerts. Daily, compare "rows pulled from source" against "rows written to target". A persistent deviation above 1% is a red flag — usually a missed page on the source side or a code conflict rejection on the target side.

Lessons Learned

1. Treat the code as the primary key. If you let Kingdee auto-generate codes, every later round-trip and rename breaks. Push supplier_code to FNumber verbatim, and keep idCheck on.
2. Long names get truncated. Kingdee's FName has a length limit, and some overseas vendor names from LingXing exceed it — this is where projects trip. The safe approach is a truncation-plus-alert layer in Qeasy's field mapping.
3. Don't hard-delete on "is_delete=1". Instead of physically deleting in Kingdee, flip FForbidStatus to disabled and keep the audit trail.
4. Hard-coding orgs and groups in the strategy blocks multi-org expansion. A classic mistake is writing 100 and CG straight into the request body; adding a new org then means editing N strategies. Lift them into a constants table once and you're done.
5. Same-minute crontabs cause write queues. On a real project, both strategies at 0 0 * * * produced sporadic Kingdee write timeouts. A 10–15 minute stagger is the steady-state pattern.

Where This Fits and Where It Doesn't

Use it when: a single group on a single org, vendors are maintained only in LingXing, and Kingdee is purely a consumer. Don't use it when: multiple subsidiaries share one Kingdee book and need org-isolated vendors; vendors are edited in both sides and require bidirectional sync; or contact info and bank accounts must be written together — these scenarios either need a different strategy or split into parallel strategies. Don't squeeze them into this one.