Empty-Operation Triggered Approval: A Practical Tutorial for Purchase Receipt Synchronization

What This Strategy Solves

In supply chain integration, when a Purchase Receipt comes from an upstream document (such as an OA approval flow or an upstream ERP document), it is often in an "unapproved" state. Relying on manual approval in Kingdee Cloud Cosmos is both slow and error-prone. The strategy we discuss here uses an "empty operation -> approval" approach to trigger Kingdee Cloud Cosmos to execute the approval action on the Purchase Receipt, so that the document takes effect immediately upon arrival, and the subsequent inventory and financial accounting chain will not be broken.

Data Flow and Field Mapping

The essence of this strategy is a "trigger," not data movement. The source system is Weaver OA-E9Http, and the target system is Kingdee Cloud Cosmos. When the OA-side receipt process reaches a designated node, a status event is pushed to the Qeasy Data Integration Platform; the platform identifies the event and initiates an "approval" operation against Kingdee Cloud Cosmos.

Key field mapping:

Note: the middle layer does not write business fields; it only transmits the document number and the trigger signal. What actually writes to the database is Kingdee Cloud Cosmos's own approval interface.

How to Configure on Qeasy

When configuring this strategy on the Qeasy Data Integration Platform, we usually do it in three steps.

Step 1: Select the strategy type. In the strategy editor, select "Empty-Operation Trigger Type," choose Weaver OA-E9Http as the source, Kingdee Cloud Cosmos as the target, and fill in "Purchase Receipt" for the business module.

Step 2: Configure the trigger condition. Bind the trigger to a specific process node on the OA side, such as "Purchase Receipt Process — Finance Confirmation Complete." A reliable approach here is to use the callback event of the process node instead of polling, which ensures real-time performance and avoids putting pressure on the OA interface.

Step 3: Configure the target action. Select Kingdee Cloud Cosmos's "Approval" operation on the target side, and just pass in the document number. Qeasy will automatically call Kingdee's approval interface to complete the chained submit-and-approve actions. A common approach at customer sites is to centrally maintain the document number mapping rules in Qeasy's code mapping table, avoiding scattering across multiple strategies, so that later when the process changes, only one place needs to be modified.

Implementation Steps

When we deploy on customer sites, we usually advance in three phases.

Phase 1: Joint debugging. First, run a complete OA receipt process in the test environment and observe whether the Qeasy platform receives the event and whether Kingdee successfully approves it. In this phase, no scheduling is enabled, and everything relies on manual triggers, focusing on log observation.

Phase 2: Trial operation. Configure Qeasy's scheduling policy. There are two modes to choose from. One is to leave the triggering entirely to OA-side event callbacks, with Qeasy only responding; the other is to have Qeasy periodically poll the OA process status to catch events that were missed. We recommend using "event trigger + scheduled polling dual-track" during the trial operation phase, and turning off polling after stability is achieved.

Phase 3: Steady state. Switch to the production environment, close debug logs, and keep only error alerts. The scheduling frequency is recommended to be set as "real-time trigger + daily reconciliation," where reconciliation is used to catch documents that were missed the previous day.

Lessons Learned

Here are the most common pitfalls at customer sites.

Pitfall 1: Missing approver mapping. Kingdee's approval interface requires a specific approver account. If Qeasy does not pass it or passes it incorrectly, the approval will fail. A reliable approach is to maintain the mapping from OA handlers to Kingdee users in the code mapping table.

Pitfall 2: Duplicate triggers. If the OA process node is rolled back and then advanced, it will push the event repeatedly, causing duplicate approvals on the Kingdee side. The tricky point is that Kingdee will report an error if the approval interface is called again on an "already approved" document, so Qeasy needs to implement idempotency control: the same document number can only be triggered once within a window period.

Pitfall 3: Incorrect time field format. Kingdee's approval date has strict format requirements, and the request will be rejected if the string is wrong. A typical mistake is that OA provides "yyyy-MM-dd HH:mm:ss" while Kingdee requires "yyyy-MM-dd". Be sure to confirm the format conventions on both ends during configuration.

Pitfall 4: Insufficient permissions. The approval operation in Kingdee Cloud Cosmos requires a user with specific permissions to execute; insufficient permissions for the integration account will cause approval failure. Confirm the role and permission list of the integration account at the start of the project.

Pitfall 5: Missing reconciliation mechanism. Many teams discover after launch that some documents are occasionally missed, but there is no remediation means. It is recommended to configure a daily reconciliation task in Qeasy to periodically pull Kingdee's unapproved receipts, compare them with the completed OA-side processes, and manually re-push the differences.

Applicable and Inapplicable Scenarios

Applicable scenarios: the upstream is a process-driven system (OA, approval flow), and the process-end event needs to be translated into a document-effective action in the downstream ERP, such as purchase receipts and payment requests. Inapplicable scenarios: scenarios where both upstream and downstream are structured business systems requiring bidirectional field synchronization; as well as continuous business flows without a clear "process end" node. In such cases, the design idea of empty-operation triggered approval should be replaced with a field-level synchronization strategy.