Procurement Refund Sync in Practice: From DingTalk Approval Flow to Kingdee Cloud Payment Voucher

What This Strategy Solves

After procurement operations are up and running, the real pain point is often not "placing a purchase order" but handling refunds afterward. When suppliers deliver goods with quality issues, wrong shipments, or contract changes, money that has already been paid out needs to be recovered. In one real project, a retail enterprise's procurement refund process went through a DingTalk approval flow. After approval, the business clerk manually entered the payment voucher into Kingdee Cloud, which led to two problems: the refund amount did not match the approval form, and at month-end reconciliation, finance staff could not locate the corresponding payment voucher number.

What this strategy does is simple: it pushes approved "procurement refund" process instances from DingTalk, following defined rules, into Kingdee Cloud to generate a corresponding payment voucher (FKTK), so the approval flow and the financial ledger speak the same language. We use the Qeasy Data Integration Platform to handle the entire link, treating DingTalk as the business entry point and Kingdee as the financial exit point.

Data Flow and Field Mapping

The data flow is unidirectional: DingTalk (source) → Qeasy middle layer → Kingdee Cloud (target). On the DingTalk side, completed process instances are queried via YiDa (v1.0/yida/processes/instances); on the Kingdee side, batchSave is called to write the payment voucher.

The middle layer has three responsibilities: first, translating DingTalk field identifiers (such as tableField_lgm25d9j.textField_lgm25d9w) into business fields Kingdee can recognize; second, normalizing base data such as dates, exchange rates, and currencies; third, maintaining a centralized mapping management location — we have seen too many teams scatter this part across scripts, with the result that no one dares to modify them later.

Key field mapping reference:

How to Configure in Qeasy

In Qeasy, this strategy is modeled as a three-part structure: "source integration + target integration + scheduling", deployed in the customer's private environment.

Source (DingTalk) configuration points:

• Select DingTalk as the platform type, with API v1.0/yida/processes/instances (POST, QUERY).
• appType, systemToken, and userId in the request body are mandatory and obtained from the DingTalk YiDa backend. In Qeasy, we recommend configuring them as integration connection credentials rather than writing them directly into request fields.
• Pagination parameters use built-in platform variables {{PAGINATION_START_PAGE}} and {{PAGINATION_PAGE_SIZE}}; Qeasy iterates automatically by page.
• number points to the process instance title, and id points to processInstanceId — these serve as anchors for deduplication and checkpoint resumption.

Target (Kingdee Cloud) configuration points:

• Select Kingdee Cloud as the platform type, with API batchSave (POST, EXECUTE).
• For fields like FBillNo that need concatenation, use platform-provided expression variables (such as {{serialNumberField_lgm25d8r}}) for combination.
• Date fields use function expressions like _function FROM_UNIXTIME(...) for conversion in the Qeasy mapping layer; do not modify fields on the source side.
• Keep idCheck enabled to avoid pushing the same refund twice.

Scheduling and orchestration: Both strategies (crontab = */30 * * * *) run every 30 minutes. We recommend separating "procurement payment" and "procurement refund" into two independent strategies rather than mixing them into one flow — when issues arise, this makes it faster to locate whether the problem lies in the payment direction or the refund direction.

Implementation Steps

When landing this strategy at the customer site, we typically follow three steps:

Step 1: Align the incremental starting point. First confirm the "completion time" field of DingTalk process instances, and use this time as the incremental starting point. In Qeasy, set data filter conditions to processInstanceStatus = COMPLETED and completion time ≥ last sync checkpoint, so that approved refund forms are picked up.

Step 2: Full-volume trigger and reconciliation. On launch day, run a one-time full backfill to bring historical refund vouchers up to date in Kingdee. After the full backfill, perform a reconciliation on both sides using the document number prefix ((FKTK)) to confirm that the count and amounts match.

Step 3: Normal scheduling and monitoring. After entering */30 * * * * normal operation, configure run-log alerts in Qeasy, focusing on two types of anomalies: first, failure rows returned by batchSave (usually due to incorrect organization or currency codes); second, processInstanceIds on the DingTalk side that cannot find corresponding vouchers in Kingdee (indicating a write failure without an error thrown).

Lessons Learned

1. Wrong field used for the business date. DingTalk forms usually contain two timestamps: applicant submission time and process completion time. A typical mistake is pushing "submission time" as the business date to Kingdee, which causes the financial period and approval period to misalign. The safe approach is to use the process completion time, and explicitly convert it via FROM_UNIXTIME in Qeasy.
2. Settlement org mixed with applicant org. The applicant's department in DingTalk and the settlement organization on Kingdee's payment voucher are different things. Directly using the applicant's department will cause Kingdee to reject the voucher on "organization authority/dimension" grounds. Always perform a secondary translation of the org code in the mapping layer — the source is the applicant's department, the target is the settlement org code.
3. Refunds and payments mixed in one strategy. It looks like a single payment voucher, but the document type, direction, and refund reason fields are completely different from payment. Many Qeasy customers have fallen into this trap — before going live, be sure to split them into two independent strategies so that adding fields later does not affect each other.
4. Idempotency not done rigorously. After a DingTalk approval form is rejected and resubmitted, a new processInstanceId is generated but the business number may repeat. If deduplication in Qeasy relies only on the document number, pushes will be missed. The safe approach is to deduplicate using processInstanceId + document number jointly.
5. Mapping tables scattered. During the customer's first launch, org, currency, and document type code mappings were written into scripts; six months later, no one knew where to modify them. We later centralized these mappings into Qeasy's "Mapping Management" module for unified maintenance — change in one place, effective in one place.

Applicable and Non-Applicable Scenarios

Applicable scenarios: The procurement refund process has gone through DingTalk (or another low-code platform) as an approval flow, and a formal payment voucher needs to be generated in Kingdee Cloud, with the requirement that approval and ledger be consistent and traceable transaction by transaction.

Non-applicable scenarios: The refund business has no online approval and still relies on offline paper documents; or the Kingdee side is not Cloud but another version of Kingdee with significant field naming differences; or the refund amount needs to be reconciled item by item against the original payment voucher (this strategy only lands the voucher and does not handle reconciliation linkage).