Purchase Order Cancel Sync in Practice: Dingtalk Approval Revoke → Kingdee Cloud CancelAssign

What This Strategy Solves

In the procurement workflow of a manufacturing enterprise, a purchase order is first created and audited in Kingdee Cloud, then routed through an approval flow into Dingtalk for downstream confirmation. As soon as the applicant withdraws the request or an approver revokes it on Dingtalk, the order on the Kingdee side must be synchronized into a cancelled state. Otherwise, you end up with orphan orders—already withdrawn in Dingtalk but still alive in Kingdee. This strategy pushes that single revoke action cleanly from Dingtalk into Kingdee.

Data Flow and Field Mapping

Data flow: Dingtalk approval instance → Qeasy (intermediate layer) → Kingdee Cloud CancelAssign. The source is not the order itself but an approval event; the target is not a write but an execution.

The two most critical columns are Numbers and Ids. Kingdee's cancel API accepts either a bill number or an FID, so the safe practice is to fill both—the number comes from the form, the FID from the lookup; whichever hits will land the operation.

How to Configure on Qeasy

In the Qeasy integration platform's strategy editor, configure the following key points:

1. Source side: pick "Dingtalk" as the platform, choose topapi/processinstance/get as the API, set effect to QUERY, with id as the primary key. In the response list, check "BillNo" and mark _autoFillResponse in the describe field so that the Dingtalk form control value is auto-filled into the variable.
2. Target side: pick "Kingdee Cloud" as the platform, choose CancelAssign as the API, set effect to EXECUTE. Set FormId to the constant PUR_PurchaseOrder; reference {{BillNo}} directly for Numbers; for Ids, use the COLLECTION type and the expression _findCollection find FID from {{queryPlanId}} where FBillNo={{BillNo}}.
3. Lookup dependency: ensure a "Query Kingdee Purchase Order" plan already exists on Qeasy. That is the data source for _findCollection. The audit and cancel strategies can share the same query plan—a common pattern we use when delivering to customers: centralize all "find FID by bill number" needs in a single query plan so other strategies only reference rather than duplicate it.
4. Scheduling: set both sides to */3 * * * *. The source polls every 3 minutes for new/changed approval instances, and the target executes in lockstep. Cancel is a low-frequency action; 3-minute granularity is enough, no need to drop to 1 minute.
5. Switch: explicitly set IgnoreInterationFlag to true. This is standard practice for cancel-type strategies—otherwise Kingdee may pop up interaction dialogs and the task will hang.

Implementation Steps

1. Pre-build the lookup plan: first create a "Query Kingdee Purchase Order" plan on Qeasy and confirm it can return FID by FBillNo. This is the shared foundation used by both the audit and cancel strategies.
2. Land the cancel strategy: create the strategy per the previous section. Manually trigger once to verify _findCollection returns an FID and CancelAssign succeeds.
3. Configure the incremental starting point: deduplicate on the source side using "approval instance id" and only process instances whose state has changed to "revoked/withdrawn" to avoid duplicate executions.
4. Full-trigger sweep: at first go-live, run a one-shot full scan to backfill historical orphans—orders already withdrawn in Dingtalk but still open in Kingdee. Then switch back to incremental.
5. Scheduling cadence: keep both sides polling every 3 minutes. If approval volume is high, the source can be tightened to 1 minute while the target stays at 3 minutes, forming an "upstream fast, downstream steady" rhythm.
6. Verification: within the first week after go-live, sample 3–5 orders daily and compare Dingtalk status against Kingdee status to confirm linkage is correct, then relax monitoring.

Pitfalls and Lessons Learned

1. BillNo cannot be obtained and cancel fails outright. Dingtalk's topapi/processinstance/get returns the approval structure, and BillNo hides in form_component_values or extend. Be sure to configure _autoFillResponse in the source response; otherwise the downstream {{BillNo}} will be an empty string and Kingdee will reject with "Numbers cannot be empty".
2. Passing only Numbers without Ids causes intermittent failures. In some Kingdee versions, when the bill number carries a prefix (e.g., PO-2024-xxx), pure number matching fails. The safe practice is to pass Numbers and Ids together and let Kingdee decide—this is the default in our customer projects.
3. _findCollection syntax errors cause empty results. A typical mistake is adding spaces in where FBillNo = {{BillNo}} or using the wrong plan ID. The syntax is space-sensitive—no spaces between field name and value—and the plan ID must be accessible within the current tenant.
4. IgnoreInterationFlag not set to true, task hangs forever. Cancel in some validation scenarios triggers interactive prompts; without ignoring them, async tasks get suspended. The symptom is "strategy keeps running but produces no result".
5. Audit and cancel share the lookup plan, but updates get forgotten. If fields in the query plan change, both audit and cancel break at the same time. Whenever you share a foundation, change one place and regression-test both—this is the discipline cost of centralized management.

When to Use and When Not to Use

Use when: Dingtalk is the approval entry point and Kingdee is the business system, and approval state must drive business documents in reverse (cancel, unaudit, close). Do not use when: Dingtalk lacks a "BillNo" form control, or the Kingdee order has already triggered downstream transactions (e.g., goods received, warehoused) that prevent direct cancellation. In those cases, downstream cleanup must run first before invoking cancel.