DingTalk Monthly Reimbursement to Kingdee Cloud Skylight Payment Order: A Single-Strategy Implementation Tutorial
What This Strategy Solves
A retail enterprise uses DingTalk for daily reimbursement approvals, and finance closes the month with a batch of "monthly loan" reimbursement orders. Once approved, finance needs these orders to land in Kingdee Cloud Skylight as payment orders for subsequent write-off and voucher generation. Previously, staff exported Excel files and entered them manually, consuming most of the first three days each month. We used the Qeasy data integration platform to standardize this process: as soon as an order is approved, it automatically lands in Kingdee, and finance only needs to verify.
Data Flow and Field Mapping
Overall flow: DingTalk approval flow → Qeasy middle layer → Kingdee Cloud Skylight payment order. The middle layer handles code mapping, field conversion, idempotent deduplication, and exception staging.
| Business meaning | DingTalk field | Middle-layer processing | Kingdee Cloud Skylight payment order field |
|---|---|---|---|
| Order number | Approval instance businessId | Take last 8 digits and pad | Document number (FBillNo) |
| Applicant | originatorUserName | Resolve userId via department query strategy | Applicant employee |
| Reimbursement amount | Form control amount | Convert to decimal, keep two places | Payment amount (FAmount) |
| Summary | Reason | Concatenate "monthly - department - name" | Explanation (FExplanation) |
| Applicant department | deptName | Look up Kingdee code via department mapping table | Department (FDeptId) |
| Payment type | Expense type | Enum mapping: monthly loan → other payable | Payment type (FPayType) |
| Approval completion time | finishTime | Convert to yyyy-MM-dd HH:mm:ss | Business date (FDate) |
For Qeasy code mapping, centralized management is recommended: keep applicant userId, department code, and expense type enum mappings in the platform's "mapping tables", so when new departments or expense types are added, only one place needs updating.
How to Configure on Qeasy
Source: select DingTalk's "Approval Instance Detail" API, pull approved reimbursement orders by businessId, using finishTime as the incremental time window.
Middle layer:
- Header and body processed in phases — first persist the header (amount, applicant, department, business date); after validation passes, then pull the body details.
- The idempotency key uses DingTalk businessId + approval node version number to avoid duplicate triggers for the same order.
- Abnormal orders go into the "manual handling" queue without blocking the main pipeline.
Target: Kingdee Cloud Skylight payment order save API (save), with FBillNo as the existence check: if not present, create; if present and unapproved, update; if approved, skip and log.
Implementation Steps
We typically roll out in three phases, each running on real business data.
Phase 1: Full backfill + reconciliation (one week before go-live) Pull the past 30 days of approved monthly loan orders into the middle layer in one batch, write them into Kingdee one by one, and finance verifies each amount and department against Kingdee. The goal is to establish a baseline for reconciliation.
Phase 2: Incremental start + shadow run (week 1 after go-live) Set the strategy schedule to run daily at 02:00, pulling orders with finishTime between yesterday 00:00 and today 00:00. During this week, Qeasy only writes to the middle database without actually pushing to Kingdee, and finance verifies the middle database results daily.
Phase 3: Formal push + monitoring (from week 2 onward) Enable the target-side save action, keeping the schedule at daily. Simultaneously enable three monitoring metrics: document count, success rate, and average latency, with automatic alerts to DingTalk groups when thresholds are exceeded.
Lessons Learned
-
Department codes inconsistent across systems. DingTalk departments are text; Kingdee departments are numeric codes. The easiest pitfall is hardcoding mappings directly in scripts; three months later when a new store is added, the correspondence cannot be found. The reliable approach is to maintain mappings in Qeasy mapping tables, with scripts only looking up the table.
-
Amount field type drift. DingTalk form controls return string numbers; Kingdee payment amounts are decimal. We once encountered floating-point accumulation errors like "0.1 + 0.2" causing reconciliation imbalance. The reliable approach is to consistently use decimal in the middle layer with rounding.
-
Inaccurate approval status determination. DingTalk approval instance statuses include "Approved", "Completed", etc. Mistaking "Approved" for "Completed" causes orders to be synchronized prematurely while approvers are still adjusting amounts. The reliable approach is to push status determination down to the middle layer scripts, clearly only fetching instances with finishTime already written.
-
Idempotency key designed too weak. Only using businessId caused duplicate orders to land when the same businessId was rolled back and resubmitted. Switching to businessId + operation timestamp version number resolved this.
-
Finance monthly close window not avoided. At the start of the month, Kingdee is closing the books, and Qeasy pushing orders in gets rejected with table locks. The reliable approach is to block the first to third day of each month in the schedule calendar and push back the business date by one day.
Applicable and Non-Applicable Scenarios
Applicable: standardized approval flows, stable order structures, and reimbursement-type businesses where fields can be retrieved on both sides. Non-applicable: frequently changing approval flows, orders requiring manual modification before synchronization, or scenarios where Kingdee-side requires multi-person collaborative review — these are better suited for an API middle platform rather than direct single-strategy push.