Sync Kingdee Payment Applications to DingTalk Supplier Monthly Settlement Approval: A Hands-On Configuration Tutorial

What This Strategy Solves

In supplier monthly settlement scenarios, the finance team at one manufacturing enterprise had to re-key payment applications into DingTalk OA after they were approved in Kingdee Cloud. Two systems, double entry, frequent amount typos. This strategy automates that bridge: once a payment application is approved in Kingdee, a matching monthly settlement approval instance is created in DingTalk. In customer projects we typically place it right after the supplier master-data sync inside the broader Kingdee × DingTalk integration pack on Qeasy.

Data Flow and Field Mapping

The flow is one-way: Kingdee Cloud (CN_PAYAPPLY) → Qeasy transformation layer → DingTalk OA (topapi/processinstance/create). Kingdee is pulled incrementally via executeBillQuery, filtered by approval date FApproveDate. The platform then unwinds the base-data fields and assembles the request body expected by DingTalk.

For top-level parameters, process_code is the static identifier of the supplier monthly settlement template, written as a CONSTANT. originator_user_id and dept_id are dynamic: the source only carries the employee name (F_VAOJ_FQR), so an _findCollection lookup against the "DingTalk Directory → Kingdee Employee" hub is required to resolve user_id and primary department.

form_component_values is the form-component array expected by DingTalk. The typical mapping is:

All four common mapping types are in play here: DIRECT pass-through, CONSTANT, COLLECTION hub lookup, and TRANSFORM expressions when a fallback is needed.

How to Configure on Qeasy

When building the strategy in Qeasy, the source connector is Kingdee Cloud executeBillQuery with FormId = CN_PAYAPPLY and FilterString = FApproveDate>='{{LAST_SYNC_TIME|dateTime}}' so the platform maintains the incremental cursor automatically. The target connector is DingTalk topapi/processinstance/create, authenticated via DingTalk Open Platform access tokens.

For field mapping, we recommend the "centralised code-mapping" pattern that Qeasy customers often adopt: every _findCollection call points at the same "DingTalk Directory → Kingdee Employee" hub. When an employee leaves or moves departments, only one place changes. For form_component_values, two patterns work. Pattern one: bind each form control to a source field through the Qeasy UI. Pattern two: build a details array from one source record in a post-mapping script and assign it to form_component_values. Pattern two is more comfortable when there are many controls or you need to normalise formats (bank names, contact details, and so on).

Implementation Steps

We usually split this into three stages; doing them out of order leads to rework.

1. Master data first, transactional sync second. The "DingTalk Directory → Kingdee Employee" hub must be stable before this strategy runs, otherwise _findCollection cannot resolve user_id. Run a full load first, then turn on incremental.
2. Align the incremental starting point. Set LAST_SYNC_TIME to a clear anchor (for example, 23:59:59 of the day before go-live). Avoid pushing historical bills in one burst and overwhelming the DingTalk approval workflow.
3. Phased scheduling. Source crontab */7 9-22 * * * (every 7 minutes during business hours), target crontab */5 9-22 * * * (every 5 minutes). The two tiers are intentionally offset. Before going live, run a shadow mode for two to three days — Kingdee bills are created, but DingTalk uses a test template so you can verify document number, amounts and receiver info without sending real approvals to the leadership chain.

Pitfalls and Lessons Learned

A few things we have hit on real projects:

• FApproveDate is not the creation date. Filtering on creation date misses bills that are created first and approved later. Approval date is the right anchor if you want "sync the moment it is approved."
• Base-data fields used as plain strings. FCONTACTUNIT, FSETTLEORGID and similar are objects. Without .fname or .fnumber you end up pushing [object Object] into DingTalk, where it shows up as garbage. This is the single most common rookie mistake.
• leader_in_dept is an array. Primary department is leader_in_dept.0.dept_id. If the employee has no primary department or sits at the root, fall back to -1 in the transform layer, otherwise DingTalk rejects the request with "invalid originator department."
• Truncated process_code. The process_code is a hyphenated UUID. A single missing character during copy-paste produces a silent 404. Always copy it from the template detail page.
• Wrong control names in form_component_values. Control names are identifiers defined in the DingTalk template, not the visible Chinese labels. If the name is wrong, the value goes through but the field is blank in the form. When debugging, cross-check against the DingTalk template designer.

When to Use and When Not to

Use when: the enterprise already has a stable payment-application approval flow in Kingdee, needs monthly settlement approvals in DingTalk OA, and has completed two-way supplier master-data sync.

Avoid when: line-level (entry-level) approval is required (this strategy only carries header fields); Kingdee and DingTalk belong to different governance domains and the link is ad hoc; or Kingdee approval flow itself is unstable and source data is being reverted frequently.