Writeback from DingTalk Approval Edits to Kingdee Payment Bill: A Single-Strategy Tutorial

What This Strategy Solves

In the "Kingdee payment request → DingTalk approval → push-down payment bill" chain, a common headache is this: a business user modifies the approval form on DingTalk (e.g., changing the payment attribute from "finished product" to "auxiliary material", or adding a remark), but the payment bill that has already been pushed down on the Kingdee side still holds the old value. The two sides don't match, and the finance team is confused during reconciliation. The "modify pushed-down payment bill" strategy we're delivering here is designed to incrementally write back field changes from the DingTalk approval back to the Kingdee payment bill's header, updating only the three fields we care about while leaving the rest untouched.

Data Flow and Field Mapping

The data flow is clean: DingTalk approval process instance → Qeasy middle layer → Kingdee Cloud payment bill (AP_PAYBILL).

The source fields come from the approval instance returned by topapi/processinstance/get, and the target is the Kingdee payment bill's header. The key field mapping is as follows:

There is a key design point here: FID is not obtained directly from the source side but is reverse-looked-up via the cross-query scheme "Query Kingdee Payment Bill (associated modified document info) all" using FBillNo. This is because the Kingdee batchSave modification API requires FID to locate the record to update.

How to Configure on Qeasy

We use Qeasy to host this strategy. The typical configuration is split into four parts:

1. Source collector: A DingTalk approval trigger that listens for approval modification events and then calls topapi/processinstance/get to pull the complete form data back. Note that the response metadata usually only explicitly declares business_id; in actual execution, other fields are retrieved from extend or form components.
2. Middle-layer processing: Use Qeasy's "cross-query" node to configure _findCollection, using Number as FBillNo to fetch FID from another query scheme. This is the most error-prone part of the entire strategy and will be expanded in the pitfall section below.
3. Field mapping: Configure the three target field mappings according to the table above. Enum conversion uses _function expressions, and string concatenation uses template syntax directly. Qeasy's encoding mapping supports centralized management—if the payment attribute enum is later expanded (e.g., adding "packaging material"), changing one mapping location will take effect across the board.
4. Target write: Select BatchSave in the Kingdee write node, set FormId=AP_PAYBILL, and be sure to fill NeedUpDateFields with F_VAOJ_HKSX,FREMARK,FBillNo—this is the switch on the Kingdee side that controls "update only specified fields". Leaving it empty will be interpreted as a full update and will clear the detail lines.

Implementation Steps

Implementation usually proceeds in three phases:

• Phase 1: Align the incremental starting point. First, run a full pull of the "Query Kingdee Payment Bill (associated modified document info) all" scheme on Qeasy, caching the FBillNo → FID mapping of existing payment bills on the target side, ensuring the cross-query node hits on its first execution. This step is especially important for payment bills that have already been pushed down historically but have never run the modification writeback.
• Phase 2: Trigger a one-time full writeback. On the go-live day, manually trigger a full writeback for approvals that have been modified on the DingTalk side within the recent period, and verify that F_VAOJ_HKSX and FREMARK on the Kingdee side match DingTalk. This step serves as both data validation and a regression test of the mapping rules.
• Phase 3: Scheduling frequency and triggers. During daily operation, we recommend a dual-track mode: incrementals are triggered in real time by DingTalk approval modification events (seconds-level), while a fallback scheduled task is configured at the same time (e.g., running every 15 minutes, filtering by the approval's last modification time), preventing data drift caused by missed event triggers.

Pitfall Review

1. NeedUpDateFields left empty, detail lines cleared. The most typical crash: the engineer, trying to save effort during initial configuration, leaves this parameter blank. As a result, BatchSave is interpreted as "update by full model", the original detail lines of the payment bill are cleared, and the finance team blows up on the spot. The safe practice is to always explicitly list the fields to be updated this time, even if only one field is being updated.
2. FID cross-query returns multiple records. If the same FBillNo has historical versions on the Kingdee side (e.g., voided and reopened), the cross-query may return multiple FIDs, and the subsequent BatchSave will report "target record is not unique". The solution is to add deduplication and "take the latest" logic after the cross-query node, or to ensure global uniqueness of FBillNo on the Kingdee side.
3. business_id and Number misalignment. The source-side metadata only explicitly declares business_id. Engineers habitually use business_id as both FBillNo and the cross-query condition Number. This works in most scenarios, but in edge cases where the DingTalk approval is copied or resent, the two may diverge, causing cross-query failures. It is recommended to fetch the two fields separately—use Number as the cross-query condition and business_id for writing.
4. Enum additions not synchronized. After the payment attribute expands from "finished product/auxiliary material" to "finished product/auxiliary material/packaging material", if the mapping rule only writes case without a default else, new values will be rejected when written to Kingdee. Qeasy's encoding mapping supports centralized management, but the prerequisite is to keep an else branch as a fallback in the conversion rule—for instance, map all new enums to FL first, then manually review.
5. Trade-offs of IsAutoSubmitAndAudit=false. This strategy is configured to not auto-submit and audit—this is intentional: in modification scenarios, finance personnel need to manually review to prevent the approval process from being bypassed. However, if the customer's business allows it and immediate effect after modification is desired, it can be changed to true, but be sure to align with the business side first.

Applicable and Non-Applicable Scenarios

Applicable: Scenarios where DingTalk approval field changes need to be written back to Kingdee, involving only incremental updates to header fields, with detail lines maintained independently by the Kingdee system—specifically "approval → push-down document" writeback scenarios. Not applicable: Scenarios where detail lines need to be modified synchronously, cross-organization/cross-account-set transfers, or where the Kingdee side needs to run the full approval flow again—these require more complex strategy combinations and cannot reuse this solution.