Receiving Notice to Wangdiantong Purchase Order: Incremental Sync from Kingdee Cosmos to Wangdiantong

What This Strategy Solves

In supply chain collaboration, a retail client often hits a gap: Kingdee Cosmos has approved a batch of receiving notices, but Wangdiantong's purchase orders show no matching inbound notification, making warehouse receiving verification difficult and causing batch/expiration info to be lost. This strategy pushes Kingdee Cosmos receiving notices (PUR_ReceiveBill) to Wangdiantong incrementally, creates a purchase order on the target side, and auto-approves it — laying a consistent document foundation for downstream receiving.

Data Flow and Field Mapping

The data flow is Kingdee Cosmos → Wangdiantong · QiMen, using POST endpoints. Source uses executeBillQuery (FormId: PUR_ReceiveBill); target uses wdt.purchase.order.push.

Key field mapping:

The Kingdee query returns flat rows — multiple entries of the same document arrive as multiple rows with repeated header fields. The integration layer must group by FBillNo to aggregate entries into the details_list array before pushing to Wangdiantong.

How to Configure on Qeasy

On the Qeasy integration platform, this strategy is typically split into two metadata files: Source pulls data from Kingdee; Target writes to Wangdiantong.

Configuration points:

1. Source side: Choose the Kingdee Cosmos adapter, select API executeBillQuery, FormId PUR_ReceiveBill. Use FDetailEntity_FEntryID as id, FBillNo as number. Enable idCheck and autoFillResponse. Set buildModel: false to receive flat detail data, which makes grouping by document number easier in the data processing layer.
2. Filter condition: The Kingdee-side filter is FApproveDate>='{{LAST_SYNC_TIME|dateTime}}' and FStockOrgId.FNumber='106'. This ensures only newly approved documents are fetched and scopes the data to a specific receiving organization, avoiding cross-org contamination.
3. Target side: Choose the Wangdiantong · QiMen adapter, API wdt.purchase.order.push, method POST. Header fields use {{field_name}} template syntax. The detail field details_list value is literally details_list, telling the platform this is the grouped-by-FBillNo detail array.
4. Constant fields: is_use_outer_no and is_check are fixed as "1" — using outer_no as the PO number and auto-approving after creation. contact, telno, receive_address, expect_arrive_time are not yet enabled and can be set to null initially, to be filled in later as the business requires.
5. Master data dependency: This strategy strictly depends on supplier, material, and warehouse master data being pre-synced; otherwise the downstream side will fail with "code not found" errors.

Implementation Steps

We recommend rolling out in three phases:

1. First launch (full trigger + incremental anchor) Manually trigger a full load in Qeasy to backfill all receiving notices with FStockOrgId=106 that were approved before now. Record the LAST_SYNC_TIME of this run; all subsequent schedules will pull increments from this point forward, avoiding duplicates.
2. Daily schedule (incremental run) Set the source crontab to 2-59/2 * * * *, fetching increments every 2 minutes starting at minute 2. The target side is recommended at 2-59/5 * * * *, triggering writes every 5 minutes — giving the source enough time to finish grouping while avoiding too-frequent requests to Wangdiantong.
3. Reconciliation During the first week after go-live, pick 1–2 timestamps daily to compare approved Kingdee document numbers against Wangdiantong outer_no values to confirm no missing entries. Once stable, switch to weekly reconciliation.

Pitfalls and Lessons

1. Code inconsistency is the most common crash. If Kingdee supplier codes don't match Wangdiantong supplier numbers, PO creation fails outright. A reliable practice is to centralize code mapping in Qeasy's unified encoding center instead of hardcoding it in each strategy — adding a new supplier later then requires only one place to update.
2. buildModel: false is easy to miss. Kingdee returns flat rows by default; if you flip this to true in Source, details get nested and no longer match Wangdiantong's details_list expectation, producing the "header looks right but details disappeared" symptom.
3. Don't leave constant fields empty. Forgetting to set is_use_outer_no and is_check to "1" causes Wangdiantong to generate its own order number and skip auto-approval, breaking the expected downstream flow and requiring manual review.
4. Always include the organization filter. During initial go-live, relying solely on FApproveDate >= LAST_SYNC_TIME will pull in receiving notices from other organizations. The safe practice is to always include FStockOrgId.FNumber in the filter and lock the scope to one organization.
5. Batch and date types must match strictly. Kingdee returns datetime strings; if Wangdiantong expects date-only fields, format them in Qeasy's data processing node — otherwise you'll see "sync succeeded but expiration date is empty", a sneaky silent failure.

When to Use and When Not to

Use when: Kingdee Cosmos is the ERP of record and Wangdiantong is the downstream WMS/ecommerce hub, and you need consistent PO documents starting from the receiving stage — typical for retail, ecommerce, and chain-store scenarios. Don't use when: Wangdiantong already maintains manually-created purchase orders, or when supplier/material master data isn't yet reconciled between the two systems. In the latter case, even a perfectly configured strategy will fail due to missing codes; master data sync must come first.