Syncing New Payment Orders from DingTalk to Kingdee Cloud: A Practical Guide for Procurement Payments

What This Strategy Solves

A retail enterprise runs its procurement payment approval workflow on DingTalk. Once approved, the payment order needs to be written into Kingdee Cloud as a formal payment voucher so that finance can reconcile and post it to the general ledger. Approval lives on DingTalk; accounting lives on Kingdee. Without integration, the workflow finishes on one side but finance never sees the document on the other. This strategy pulls finished DingTalk payment workflow instances into Kingdee Cloud on a 20-minute cycle and produces reconcilable payment vouchers.

Data Flow and Field Mapping

The overall flow is DingTalk → Qeasy integration platform → Kingdee Cloud. No business database sits in the middle; Qeasy only performs field cleaning and assembly.

On the source side (DingTalk), the strategy calls the Yida process instance query API v1.0/yida/processes/instances, paginates with pageNumber / pageSize, uses the workflow title as the business number, and uses processInstanceId as the idempotency key with idCheck enabled for deduplication.

In the Qeasy middle layer, fields are cleaned and mapped. The core mappings are:

On the target side (Kingdee Cloud), the strategy calls batchSave. The returned id is used as the primary key, and idCheck is also enabled to prevent duplicate writes.

How to Configure It on Qeasy

There are four key points when configuring this strategy on Qeasy:

1. Register the data sources: Register both DingTalk and Kingdee Cloud platform instances. For private-cloud deployments, use the internal access endpoint rather than the public default.
2. Attach the metadata: The source metadata type is QUERY; the target metadata type is EXECUTE. The APIs are Yida's process-instance query and Kingdee's batchSave.
3. Compose the field mapping: Build the mapping in Qeasy's mapping canvas following the table above. Fields that require transformation—dates, timestamps, unit types—must be handled with function nodes or custom expressions, not hard-coded constants.
4. Centralize code mappings: Constants like currency PRE001, document type FKDLX01_SYS, business type 2 should be stored in Qeasy's global dictionary. If the customer later switches organization or currency, you change one place instead of hunting through multiple strategies.

In our projects, centralizing code mappings is the most easily overlooked item. Customers tend to scatter these values across strategies during the first rollout, and half a year later, when they want to add an organization or switch currency, they find dozens of inconsistent values buried in 26 different strategies.

Implementation Steps

1. First full sync: Trigger it manually with a starting page and a large page size to backfill all historically completed payment workflow instances as Kingdee payment vouchers. This step verifies whether the mapping is correct and whether document numbers will collide.
2. Set the incremental anchor: Set Qeasy's "last sync cursor" to the maximum processInstanceId from the full sync. Subsequent schedules only pick up newer instances.
3. Schedule frequency: Use */20 * * * * as in the source material—every 20 minutes. For procurement payments, which are moderate in volume but require same-day posting, 20 minutes is a good trade-off: timely enough for the business, yet not overwhelming for the target batchSave.
4. Retry and alerting: Configure separate alert channels in Qeasy for network timeouts, missing fields, and batchSave errors. The first two usually recover via automatic retry; the third requires manual intervention to check whether Kingdee already has a half-written voucher.

The safe approach is full sync first, then incremental, then steady-state scheduling. Do not reorder these steps. Many on-site issues come from teams that switch to scheduled runs before validating the full sync.

Lessons from the Field

1. Forgetting to divide the timestamp by 1000: DingTalk Yida returns millisecond timestamps. A direct FROM_UNIXTIME(ts) will land in 1970. Always do /1000 explicitly.
2. Duplicate document numbers: DingTalk title may itself be duplicated. Without a business suffix like (FKD), Kingdee's unique constraint will fail the entire batchSave.
3. idCheck not enabled: Without deduplication on processInstanceId, a retried schedule or a manual rerun will produce duplicate payment vouchers in Kingdee, breaking downstream reconciliation.
4. Hard-coded currency / document type scattered across strategies: This is the typical mistake. Maintenance cost grows fast. Always use Qeasy's global dictionary.
5. 20-minute cycle ignores Kingdee's batch size limits: If a single pull returns hundreds of records, the batchSave endpoint will be rate-limited. Keep each batch within 50 records in Qeasy and split larger batches automatically.

When This Applies and When It Doesn't

Applies when an enterprise uses DingTalk Yida for procurement payment approval and Kingdee Cloud for general-ledger accounting, and needs finished payment workflows to become formal vouchers; procurement volume is moderate, with same-day posting required.

Does not apply when approval and accounting already live in the same system (no integration needed), or when volume is extremely high (over a thousand per day) with sub-second latency requirements—in those cases, push directly through a message queue instead of polling every 20 minutes.