Qeasy Cloud
Get Started

Practical Tutorial: Syncing Supplier Master Data from Kingdee QJB to Wangdiantong

· 陈洁琳· Integration Solutions· 17 views· 4 min read
WDT金蝶云·星空旗舰版供应商主数据Kingdee Cloud轻易云Incremental Sync供应链集成

What This Strategy Solves

In supply chain integration, supplier master data is the standard "single source of truth, referenced everywhere" artifact. In one real project, the customer used Kingdee QJB as the ERP master and Wangdiantong Flagship as the warehouse execution side. Every purchase receipt needs to be booked against a supplier code. Once the two sides drift on code or name, you get the awkward situation where "the document goes through, but finance can't find who to pay." This strategy does one thing: incrementally push supplier records from Kingdee into Wangdiantong, keeping the supplier pool consistent so the procurement chain doesn't break.

Data Flow and Field Mapping

The data flow is unidirectional: Kingdee QJB (B) → Qeasy middleware → Wangdiantong Flagship (A). The source calls Kingdee's paginated query endpoint /kapi/v2/dtog/basedata/bd_supplier/query_gys, and the target calls Wangdiantong's write endpoint setting.PurchaseProvider.push.

Business MeaningSource (Kingdee field)Middleware VariableTarget (Wangdiantong field)
Supplier codenumber{{number}}provider_no
Supplier namename{{name}}provider_name
Contact / payeelinkman{{linkman}}collect_name

The source pagination uses pageNo / pageSize, starting at 10 per page, with idCheck=true for idempotent deduplication by primary key.

How to Configure It on Qeasy

Open the Qeasy strategy canvas, create a new strategy with source platform "Kingdee QJB" and target platform "Wangdiantong Flagship." The source API, method, and pageSize are already preset in the metadata. In the field mapping node, simply drag number to provider_no, name to provider_name, and linkman to collect_name. Once the mapping stabilizes, export the mapping table from Qeasy as a version baseline so future system upgrades can be diffed.

For code mapping, we recommend maintaining a supplier code dictionary in Qeasy's "Centralized Code Mapping" module. When the two sides disagree on a code, the mapping layer handles it instead of forcing business users to manually fix codes on the target side.

Implementation Steps

1. Confirm the incremental starting point. In the strategy configuration on Qeasy, save the source's "start time" or "max id" as an incremental cursor into the platform's built-in KV store. Before the first go-live, manually run a full sync to backfill the cursor.

2. Trigger full sync. On customer site we typically click the "Full Sync" button on Qeasy first to dump all current suppliers into Wangdiantong. Make sure this runs during off-peak hours so it doesn't fight purchase receipts for writes.

3. Schedule frequency. The source crontab is 0-59/3 7-22 * * *—every 3 minutes, 7 AM to 10 PM, weekdays. The target offset is 2 minutes, written as 2-59/3 7-22 * * *, to stagger the two sides and avoid hammering the source. Qeasy supports per-strategy crontab, so just paste these in.

4. Retry and alerting. In Qeasy's strategy monitor, turn on "retry 3 times on failure" and DingTalk/WeCom alerts. Write failures usually mean the target API is rate-limited, and a retry almost always clears it.

5. Stage header and body separately. This strategy only syncs the header (supplier basics). If you later need to sync supplier-ship-to addresses, split that into a second strategy so one change doesn't trigger a full rewrite.

Lessons Learned

  • Pitfall 1: Code case drift. Kingdee's supplier codes are uppercase, Wangdiantong defaults to lowercase. A direct sync creates the situation where both sides have the record but neither can find the other. The safe move is to add an UPPER() or LOWER() transform in the Qeasy mapping layer and hardcode it in the centralized code mapping.
  • Pitfall 2: Empty linkman blocks the write. The contact field is optional in Kingdee, and some legacy suppliers don't have one, but Wangdiantong treats it as required. The classic mistake is letting it throw an error. The right approach is to default empty values in the mapping—e.g., "TBD."
  • Pitfall 3: Pagination cursor drift. The source paginates by id ascending. If new records are added in Kingdee during sync, the cursor drifts forward and new data gets missed. Lock orderBy to id asc in Qeasy's source config and freeze the page size.
  • Pitfall 4: Incremental cursor reset. An ops engineer accidentally clicked "Re-run Full Sync," the cursor was wiped, and the next run became a full sync again—dumping tens of thousands of duplicates into Wangdiantong. Qeasy has a "cursor protection" toggle; turn it on in production.
  • Pitfall 5: Schedule window too wide. Someone wrote the crontab as 0-59/3 * * * *—24/7. During the nightly day-end, Kingdee is half-frozen and returns inconsistent data. Align the sync window with the customer's ERP ops team, and confine it to business hours.

When This Fits and When It Doesn't

Fit: Single ERP → single WMS/OMS supplier master sync, daily volume under a thousand, stable fields, header-only.

Doesn't fit: Scenarios where supplier records need to fan out to multiple downstreams (CRM, TMS, SRM)—in that case build a "fan-out strategy" + multiple "landing strategies" on Qeasy instead of running full syncs per downstream. Also not suitable when the customer is in the middle of a code-system overhaul in Kingdee—settle code governance first, then talk sync.

Original content. Please credit the source when reposting: https://www.qeasy.cloud/insights/solutions/strat-wdt-p110c26-0304-ok-9b86a569

Comments