Syncing DingTalk Administrative Reimbursements to Kingdee Payment Vouchers: A Practical Qeasy Integration
What This Strategy Solves
In many enterprises, administrative reimbursements are approved through DingTalk, while financial payments are still recorded in Kingdee Cloud Galaxy. The common dilemma is that approvals happen in one system but the accounting entries live in another. We use the Qeasy data integration platform to convert DingTalk administrative reimbursement forms into Kingdee payment vouchers through a middle layer, so approvers and accountants stay aligned without double entry.
Data Flow and Field Mapping
The chain: DingTalk approval instance → Qeasy middle layer → Kingdee Cloud Galaxy payment voucher.
Key field mapping (based on typical structures for reimbursement and payment voucher):
| Business meaning | DingTalk reimbursement | Qeasy middle layer | Kingdee payment voucher |
|---|---|---|---|
| Document number | Approval instance ID | voucher_no | BILLNO |
| Applicant | Employee userid | applicant | Applicant (mapped in Kingdee personnel file) |
| Reimburse amount | Total amount | amount | PAYAMOUNT |
| Expense subject | Reason category | exp_subject | EXPID (mapped) |
| Payee | Payee name/account | payee | PAYEE |
| Apply date | Approval completion time | apply_date | Business date |
| Memo | Reason text | memo | MEMO |
DingTalk fields are usually scattered—expense subjects hide inside reason text, payees sit in line-item controls. Kingdee depends on a strict code system. The middle layer, which is exactly where Qeasy sits, takes on the gap.
How to Configure It in Qeasy
In customer projects we typically split configuration into three parts: source collection, target write-back, and mapping/transformation.
Source collection: use DingTalk approval instances as the data source, filter by approval result (only "completed" and matching the administrative template), and use approval completion time as the incremental cursor to avoid duplicates.
Target write-back: Kingdee payment vouchers are written through its standard API. Qeasy's built-in connector can establish target connections by organization, account set, and user. We recommend writing header and body in separate stages—header first, then body—so that a failed retry only replays the body.
Mapping and transformation: centralizing code mapping is one of the common Qeasy customer patterns. Put "DingTalk reason category → Kingdee expense subject code" and "DingTalk userid → Kingdee personnel code" into a maintainable mapping table, so later adjustments only happen in one place. Amount, date, and memo go through simple field converters.
Implementation Steps
We recommend a phased approach: get the basics running first, then move to near real-time.
Step 1: Run a full load. Pull historical completed reimbursements in batches and write them to Kingdee payment vouchers. This step is mainly about validating code mapping and field semantics—issues often surface here, such as non-standard reason text in DingTalk or applicant userids that do not exist in Kingdee's personnel file.
Step 2: Decide the incremental starting point. Use the end time of the full load as the cutoff; only sync increments afterwards. Use approval completion time as the cursor, and let the Qeasy scheduler poll at minute-level intervals.
Step 3: Set the scheduling frequency. Administrative reimbursements have moderate real-time requirements, so we suggest polling every 5–10 minutes. If finance only needs entries by the next day, narrow the window to a few fixed slots on business days.
Step 4: Exception compensation. In addition to automatic retries, Qeasy can configure a failure queue for manual fallback—a common pattern is to allow up to three retries per document; if it still fails, send it to a pending list for finance to verify and manually trigger a re-push.
Pitfall Recap
Pitfall 1: Hardcoding subject mapping. We have seen customers write subject mappings directly in scripts; three months later the business changes and finance finds the numbers no longer match. The safe approach is to maintain mappings centrally in Qeasy's mapping center.
Pitfall 2: Passing DingTalk userid directly as Kingdee personnel code. DingTalk and Kingdee maintain two independent personnel systems; without a mapping table, Kingdee will reject the entry or create "orphan" records.
Pitfall 3: Mixing amount and tax on a single line. Administrative reimbursements often include both "amount including tax" and "amount excluding tax" fields. Explicitly split them in the middle layer to avoid target-side defaulting to tax-inclusive treatment and causing differences.
Pitfall 4: Choosing the wrong incremental start point. Some customers use the approval start time and end up missing approvals that complete across day boundaries. The safe approach is to use approval completion time as the cursor and leave 1–2 minutes of clock redundancy.
Pitfall 5: Rolling back the whole batch on failure. Kingdee payment vouchers are financial evidence; a full rollback invalidates already-issued document numbers. We recommend Qeasy writing header and body in separate stages—the header commits and reserves the document number, and the body can be re-pushed independently on failure.
When It Fits and When It Doesn't
It fits enterprises whose approval and accounting live in separate systems and want to reduce double entry, especially for standardized scenarios such as administrative or travel reimbursements. It does not fit businesses with unstructured approval flows where reasons and subjects cannot be cleanly mapped, nor scenarios that demand strict real-time posting with no tolerance for any intermediate state.