Practical Guide: Syncing DingTalk Monthly Reimbursements to Kingdee Payment Vouchers
What This Strategy Solves
In many companies, expense approvals run on DingTalk while financial accounting and disbursements live in Kingdee Cloud Cosmic. Once an approval is done, finance staff re-key the same reimbursement bills into Kingdee every week to generate payment vouchers — a recipe for duplicate work, missed entries, and reconciliation gaps. The strategy we walk through here automatically pushes approved DingTalk "monthly settlement" reimbursements into Kingdee as payment vouchers, landing them directly in the pending-payment pool.
Data Flow and Field Mapping
Overall direction: DingTalk (reimbursement bill) → Qeasy middle layer → Kingdee Cloud Cosmic (payment voucher).
The source side only picks up DingTalk reimbursement bills that have passed approval and whose settlement method is "monthly settlement." The target side writes payment vouchers into Kingdee, routed by business entity to the corresponding financial books.
| Dimension | DingTalk Reimbursement | Qeasy Middle Layer | Kingdee Payment Voucher |
|---|---|---|---|
| Document No. | Reimbursement ID | Reimbursement ID (passed through) | Document No. (same source) |
| Applicant | Employee name | Applicant + employee code | Payee / applicant |
| Settlement Method | Monthly settlement | Monthly settlement (filter) | Payment method |
| Business Entity | Department | Department code mapped to book | Payment organization |
| Amount | Applied amount | Applied amount + currency | Payment amount |
| Summary | Reason | Reason + source-system tag | Summary |
Code mapping is the lifeblood of this strategy. Employee, department, and supplier codes must be maintained centrally in Qeasy; the source payload is converted once on the way through, otherwise numbers on both sides drift and business users show up about three months later.
Configuring It on Qeasy
The source uses DingTalk's approval-instance APIs filtered by approval status and settlement method; the target calls Kingdee's payment-voucher save API.
Key configuration points:
- Filter conditions: approval result = approved AND settlement method = monthly settlement; anything else is skipped.
- Mapper: keep employee, department, and supplier code mappings in a single Qeasy mapping table that the runtime only reads, so business owners can maintain it themselves.
- Idempotency control: use the DingTalk reimbursement ID as the external document number and enable duplicate checks on the target side; a second push with the same ID is rejected.
- Exception branches: route book-write failures, missing-code mappings, and amount anomalies to separate alert channels so on-call engineers can pinpoint the cause quickly.
Implementation Steps
We follow a "full backfill first, then incremental steady state" rhythm in three phases:
- Full trigger phase. One-shot backfill of the last 90 days of monthly-settlement reimbursements to initialize historical payment vouchers in Kingdee. Run this once and close it to prevent duplicates.
- Incremental anchor. Use the cut-off timestamp of the full backfill as the starting point for incremental pulls based on approval completion time.
- Schedule frequency. In production, run hourly to fetch new increments; run a separate daily reconciliation job to confirm every payment voucher generated during the day is accounted for.
Get code mappings, filter conditions, and idempotency keys right up front, and the long-term operational burden drops by an order of magnitude.
Lessons from the Trenches
- Mappings scattered across strategies. Early on we hard-coded mappings into strategy scripts; later, when business reorganized a department, we had to change dozens of places. The safe pattern — and one we see often on Qeasy projects — is to centralize them in the mapping table so a single edit takes effect everywhere.
- Forgetting the monthly-settlement filter. Without the filter, every reimbursement bill flows into Kingdee, leading to duplicate payments. This is a classic trap — put the filter on the very first gate at the source.
- Weak idempotency key. The DingTalk reimbursement ID is a natural idempotency key, but if the document can be edited, make sure the latest version wins; otherwise older versions overwrite newer ones.
- Implicit book routing. Different business entities must land in different books, and the routing must be explicit in the middle layer — relying on defaults guarantees reconciliation chaos at month-end.
- Ungraded alerts. Missing-code and amount-anomaly alerts sharing the same channel create noise that buries real issues. Configure dedicated alert channels per exception type in Qeasy.
When to Use and When Not to
Use when: expense approval lives in DingTalk, financial accounting lives in Kingdee Cloud Cosmic, and the business has monthly or batch settlement needs. Don't use when: reimbursements require manual one-by-one review, cash movements demand ultra-high reconciliation precision, or the DingTalk and Kingdee versions in use have known compatibility gaps.