Syncing Kingdee Receipt Notices to WangdianTong Purchase Orders: A Single-Strategy Field Guide

What This Strategy Solves

In a real retail or manufacturing deployment, once the warehouse posts a receipt in Kingdee Cloud, the buyers and suppliers on the store side are still tracking the deal through purchase orders in WangdianTong Flagship. When the two sides drift apart, chasing missing orders, re-issuing documents, and reconciling settlements all grind to a halt. This strategy pushes Kingdee's receipt notices over to WangdianTong as purchase orders on a defined cadence, so upstream receiving and downstream procurement sit on the same chain.

Data Flow and Field Mapping

The data flow is straightforward. Kingdee Cloud is the source, pulling receipt notices incrementally via executeBillQuery by document number. The Qeasy data-integration platform acts as the transformation layer, doing cleansing and mapping. Finally, the WangdianTong Flagship purchase.PurchaseOrder.createOrder API writes the purchase order in.

The source uses FDetailEntity_FEntryID for line-level uniqueness. The target relies on idCheck=true plus the API's idempotency to guarantee "no duplicate push for the same number."

Configuring It on Qeasy

In the Qeasy data-integration platform, this strategy sits inside one integration task. There are four configuration essentials.

First, the source query. Pick Kingdee Cloud's executeBillQuery and tick the fields you need: document number, status, material number, receiving org, material name, business date. Lock the filter to "Approved" status so drafts never flow downstream.

Second, centralize code mapping. The most common failure we have seen onsite is mismatched supplier and warehouse codes between the two systems. The safe pattern is to maintain a dedicated mapping table for org / warehouse / supplier inside Qeasy, reconciled by the business team periodically, instead of hardcoding the mapping inside every sync.

Third, split header and body phases. Phase one only writes the header (purchase order number, supplier, warehouse, purchaser, expected arrival time). Once the hit rate is stable, layer the material detail lines on top. When something breaks, this makes it trivial to tell whether the header is being rejected or the line items are.

Fourth, write back to the target. Call purchase.PurchaseOrder.createOrder with idCheck enabled so re-running the same receipt notice will not create duplicate purchase orders.

Implementation Steps

Phased scheduling is what keeps this strategy stable.

Step 1: Incremental anchor. Use the time the document status flips to "Approved" as the incremental cursor. For the first full backfill, set a business starting point (e.g., month start or go-live date), and from then on only pull new and modified records.

Step 2: Full trigger. On go-live night, run a one-off full backfill to cover the historical receipts so the business side can reconcile in a single pass.

Step 3: Schedule frequency. Configure the source crontab as 5-59/10 7-22 * * *, running every 10 minutes during business hours. The target write runs at 10-59/10 7-22 * * *, offset by 5 minutes, so the source has time to finish pulling before the same batch is submitted twice. A 5-minute offset between source and target is one of the patterns we see most often in real customer rollouts.

Step 4: Catch-up and rerun. Provide a manual rerun entry by document number. When the upstream re-approves or a field changes, you rerun the single document, not the whole batch.

Lessons from the Trenches

Pitfall 1: Status filter missing. The classic mistake is pulling by FDate alone, so drafts and voided documents also get pushed to WangdianTong, producing a flood of meaningless purchase orders. Force FDocumentStatus='Approved' in the source query.

Pitfall 2: One-to-many warehouses. Kingdee's receiving org and WangdianTong's warehouse are not a clean 1:1, especially in multi-org businesses where one receiving org owns multiple physical warehouses. The mapping table must support many-to-many, never a hardcoded constant.

Pitfall 3: Inconsistent date formats. Kingdee may return dates with or without a time component. Normalize the format in the middle layer; otherwise WangdianTong parsing fails and the whole order is dropped.

Pitfall 4: Idempotency on number alone is not enough. FDetailEntity_FEntryID is the real line-level key. Deduplicating only by FBillNo will silently skip line changes after re-approval.

Pitfall 5: No source/target offset. Running source and target on the same minute means the target is writing before the source has finished pulling. A 5-minute offset is a tiny investment with a big payoff in production stability.

When to Use It and When Not To

Use it when Kingdee Cloud is the ERP master, WangdianTong Flagship carries store-side procurement execution, and receipts must match purchases one-for-one; daily volume is in the low thousands. Do not use it when purchase orders are generated entirely on the WangdianTong side and Kingdee only does financial posting, or when the business needs true real-time latency (in that case, prefer a message queue over scheduled polling).