Purchase Request Sync from WDT to Kingdee Cloud Galaxy: A Single-Strategy Integration Playbook

What This Strategy Solves (Scenario & Value)

A retail client runs its e-commerce operations on WDT (Wangdiantong), where purchasing needs originate as "Purchase Apply" documents. However, finance and supply-chain master data live in Kingdee Cloud Galaxy. If purchase requests stay only in WDT, buyers end up double-entering on both sides, and monthly reconciliation turns into a blame game.

We used the Qeasy Data Integration Platform to take ownership of the single strategy "Purchase Request Sync [WDT → Kingdee]": incrementally pulling WDT purchase requests into Kingdee, where they become the starting point for downstream purchase orders. In one real project, this single strategy alone eliminated about 1.5 hours of daily double-entry work for the purchasing assistant.

Data Flow & Field Mapping

The data flow has three layers: WDT Enterprise Edition (source) → Qeasy middleware → Kingdee Cloud Galaxy V2 (target). The middleware is responsible for fetching, transforming, and persisting data; the target side handles the write API.

Header Field Mapping Reference

Line Item Field Mapping Reference

Note: source fields such as purchase_apply_no, warehouse_no, and status are not currently mapped to the target. If the business requires document number, warehouse, or status, you need to extend the request configuration on the target side — a point we expand on in the pitfalls section.

How to Configure on Qeasy

On the Qeasy Data Integration Platform, this strategy is typically configured in four blocks:

1. Source dataset: choose WDT Enterprise Edition's purchase_apply_query — QUERY type, POST request, incremental query by start_time/end_time.
2. Target write API: Kingdee Cloud Galaxy V2's /jdy/v2/scm/pur_request — EXECUTE type, POST.
3. Field mapping layer: the four header mappings (table above) plus line-item array mapping material_entity.value = "details_list". Use the {{created\|date}} template for date conversion.
4. No script block: this strategy does not use _function, _findCollection, or CASE...END — everything is field-level pass-through or constants, so configuration is light.

Implementation Steps

When we delivered this for a client, we followed a strict three-phase rollout to avoid "trigger full sync and watch it blow up."

Phase 1: Align the Incremental Starting Point First, confirm with the business the start time for the initial sync. We recommend setting start_time to "23:59 last night" so only that day's new requests are pulled in. Qeasy's incremental cursor saves progress automatically and resumes from the last end time on the next run.

Phase 2: Trigger Full Sync (Optional) If historical data needs to be backfilled, run a full sync in the test environment first to confirm that every material_number exists on the Kingdee side — this directly depends on whether the "Material Sync [WDT → Kingdee]" strategy has been running successfully. Centralized code mapping management is a common pattern among Qeasy clients: keep SKU code mapping in a separate material master-data strategy, and have this strategy only reference it rather than hard-coding mappings inline.

Phase 3: Bring the Schedule Online Production schedule is set to */30 * * * *, running every 30 minutes. Qeasy's scheduler supports retry on failure and breakpoint resumption, so network hiccups won't drop documents. Dual-track incremental and full sync is another common practice: incremental during normal operations, plus a full reconciliation trigger at the start of each month.

Pitfalls & Lessons Learned

Pitfall 1: Material Codes Not Aligned in Advance A typical mistake is rushing the purchase request sync before the material sync strategy has stabilized. The result: material_number does not exist on the Kingdee side, the API returns "material not found," and the whole batch fails. The safe approach is to observe the material strategy succeeding continuously for 24 hours before starting this strategy.

Pitfall 2: Hard-Coding the Applicant The current emp_id is a hard-coded constant, so every request is attributed to the same person. During an audit, the business side asked, "Why is everything submitted by Zhang San?" This is where things can go wrong. If the business needs to map real applicants from createtor_name, configure _findCollection on Qeasy to look up the employee/department strategy and retrieve the corresponding emp_id. A common mitigation pattern is staged header-then-line iteration: stabilize the header mapping first, then iterate applicant logic separately — don't change every field at once.

Pitfall 3: Date Format Overlooked The source created field is a timestamp or yyyy-MM-dd HH:mm:ss, but Kingdee only accepts yyyy-MM-dd. Forgetting to apply the {{created\|date}} template causes the target API to immediately report a date format error.

Pitfall 4: Line Item Fields Not Expanded in the Target Config The current target configuration only declares the array mapping for material_entity but does not expand line-item fields. In real projects, we recommend explicitly declaring material_number, qty, and comment in Qeasy's field mapping section; otherwise, certain Kingdee versions will fall back to default field names, causing quantity or remark loss.

Pitfall 5: Original Purchase Request Number Not Written Back WDT's purchase_apply_no is not mapped to Kingdee, so downstream reconciliation can only rely on fuzzy matching by bill_date + emp_id, which is inefficient. We suggest extending a custom field on the target side to store the original document number, or using remark as a fallback to carry it over.

Applicable and Non-Applicable Scenarios

Applicable: Small-to-mid retail/e-commerce businesses that use WDT as the purchasing entry point and Kingdee Cloud Galaxy as the ERP master-data system, and need to automatically deposit e-commerce-side purchase requests into the ERP as the starting point for purchase orders and goods receipt.

Not applicable: When WDT and Kingdee belong to different legal entities with no unified material master data foundation; when applicant/department org structures differ drastically and cannot be looked up; when the business requires real-time second-level sync (this strategy recommends a 30-minute interval).