Incremental Update from DingTalk Approval Changes to Kingdee Payment Bill: A Practical Strategy on Qeasy

What This Strategy Solves

In the chain of "payment application → DingTalk approval → push-down to Kingdee payment bill," the push-down is only the beginning. Business users at approval nodes often go back and modify header information such as payment attribute, payee, and remarks after approval is complete, while the Kingdee payment bill has long been generated. If every modification triggers a full overwrite, it will erase originally correct data and cause the line items to be recalculated. This "modification write-back" scenario requires an incremental update strategy that only touches three header fields and keeps everything else intact. We use the Qeasy Data Integration Platform to handle this, with stable and controllable results.

Data Flow and Field Mapping

The overall flow is: DingTalk approval instance modification event → Qeasy middleware layer (fetch the latest form + lookup to locate the target FID) → Kingdee payment bill (AP_PAYBILL).

Key field mapping is as follows:

Line items do not participate in this strategy's mapping. They are generated by Kingdee during the initial push-down and are not touched this time.

How to Configure on Qeasy

Create a new strategy in Qeasy. Select DingTalk approval as the source and Kingdee payment bill AP_PAYBILL as the target, with operation type BatchSave. Four points need to be confirmed:

1. Source trigger: Use DingTalk topapi/processinstance/get to fetch the latest approval instance, filtered by processInstanceId, ensuring you get the snapshot after modification, not the old one at the time of approval.
2. Lookup positioning: Add an _findCollection node in the middleware layer, referencing the "Query Kingdee Payment Bills (Associated Modification Info) all" scheme, and fetch FID by FBillNo. This is the prerequisite for the modification operation; otherwise Kingdee doesn't know which record to modify.
3. Centralized enum mapping management: A common practice among Qeasy customers is to extract enum mappings like payment attribute → CP/FL into an independent mapping table for maintenance and reuse across multiple strategies, avoiding writing case when for each strategy separately.
4. Only update specified fields: In the target operation, explicitly configure NeedUpDateFields as F_VAOJ_HKSX,FREMARK,FBillNo, with other fields not included in the payload. Set IsAutoSubmitAndAudit to false, because header field adjustments usually still require financial review.

Implementation Steps

We generally advance in three phases at the customer site:

• Incremental starting point: First find an existing payment bill in Kingdee as an anchor, trigger this strategy with an approval record, and confirm that FID can be correctly looked up and the three fields can be overwritten.
• Full trigger: Batch backflow all approval records that have been modified over a past period, run a "full backfill" once, and verify that the mapping rules, remark concatenation format, and enum values are correct across all historical data. After the full phase is complete, switch back to incremental.
• Scheduling frequency: It is recommended to poll for approval modification events every 5–10 minutes, and the interval can be appropriately extended during non-working hours. The Qeasy platform supports both time-window triggering and Webhook callbacks; choose according to the actual rhythm of the enterprise.

Pitfall Review

1. business_id is not the same as the approval instance ID. The business_id returned by DingTalk is not the same as processInstanceId. Using processInstanceId directly as FBillNo will cause all payment bill numbers to be misplaced. The reliable approach is to extract business_id separately from the approval details before mapping.
2. Lookup scheme returns multiple records. If the same bill number has been pushed down multiple times in Kingdee, _findCollection will return multiple FIDs at once, and batchSave will fail directly. A uniqueness check or sorting to take the largest version number needs to be added after the lookup.
3. NeedUpDateFields is missing. A typical mistake is to only write target fields without configuring a whitelist, resulting in batchSave overwriting the entire bill and clearing the line items. When configuring, be sure to write the three fields F_VAOJ_HKSX,FREMARK,FBillNo into the whitelist, and keep the others untouched.
4. Order and delimiter of remark concatenation. {{title}}-{{payee}}-{{remark}} looks simple, but title itself may already contain hyphens, causing confusion when splitting by - later. It is recommended to fix the delimiter and perform a simple cleanup on title before concatenation.
5. IsAutoSubmitAndAudit=true causes review loss of control. After automatic submission and approval, finance cannot intercept abnormal modifications on the Kingdee side. It is recommended to keep it false, so that the modification write-back stays in the "saved" state, and it is up to humans or downstream strategies to decide whether to approve.

Applicable and Non-applicable Scenarios

Applicable: Scenarios where header information is occasionally modified after approval and line items are already stable; compliance requirements that need to retain the financial review process; enterprises that are already using DingTalk for approvals and Kingdee for financial accounting and hope that the data on both sides is ultimately consistent.

Not applicable: Scenarios where line item amounts, currencies, business units, or other fields that affect accounting results need to be modified; the approval has not yet been pushed down to generate a payment bill; the target system is not Kingdee or does not support batchSave updates by field whitelist.