Practical Guide: Syncing DingTalk Monthly Reimbursements to Kingdee Payment Vouchers
What This Strategy Solves
In a retail enterprise's monthly reimbursement scenario, employees submit travel, entertainment, and office reimbursement forms in DingTalk throughout the month. After financial approval, these need to be aggregated into a single payment voucher per month and pushed to Kingdee Cloud for payment settlement. The difficulty is threefold: reimbursement forms are granular (one per person), but payments must be merged monthly; DingTalk's "expense type" carries business semantics while Kingdee's "payment purpose / account" carries accounting semantics, and a single mapping error will break the books; approval pace rarely aligns with the financial closing window, and missing it means manual reconciliation. We use the Qeasy data integration platform to host this strategy as a schedulable, traceable, and rerunnable monthly link.
Data Flow and Field Mapping
Overall flow: DingTalk reimbursement forms (source) → Qeasy middle layer (aggregation, mapping, enrichment) → Kingdee Cloud payment voucher (target).
Key field mapping reference (desensitized):
| Business Meaning | DingTalk Reimbursement (Source) | Qeasy Middle Layer | Kingdee Payment Voucher (Target) |
|---|---|---|---|
| Document No. | biz_no | biz_no | FBillNo |
| Applicant | userid / name | applicant | FApplicant |
| Reimbursement Month | Month of submit date | period (YYYY-MM) | FDate |
| Expense Type | expense_type | expense_type_code | FUseType |
| Account | Expense category | subject_code (mapped) | FAccount |
| Amount | Total reimbursement | amount | FAmount |
| Payee | Payee + bank card | payee + bank | FPayee |
| Approval Status | approved | filter | Trigger condition |
| Remarks | Summary | remark | FExplanation |
The middle layer does three things only: aggregate by period, translate expense_type into Kingdee-recognized payment purpose and account, and resolve DingTalk userid into name and bank account.
Configuring on Qeasy
The configuration entry is the "Integration Strategy" section of the Qeasy platform. Given this strategy's characteristics, we recommend the following organization:
- Datasource registration: Source side uses the DingTalk approval instance (process code pointing to the monthly reimbursement template); target side uses Kingdee Cloud's "Payment Voucher" document. Connection info goes through standard public cloud onboarding; no tokens are hardcoded in the configuration.
- Fetch strategy: Use "approval completion time + status = approved" as the incremental filter to avoid pulling drafts and rejected forms. Run a full backfill before the first execution as baseline.
- Middle layer processing: Maintain a centralized "expense type → payment purpose + account" mapping table inside the Qeasy transformer. Centralized code mapping is one of the common patterns among Qeasy customers — when a new expense category is added, only one row needs to be inserted; the strategy backbone does not need to change.
- Writeback strategy: Kingdee side uses a two-step "query-then-save" approach: query by period + applicant first to check whether a payment voucher for the same month already exists; update details if it does, create if it does not. This way, even if Qeasy reruns, no duplicate documents are produced.
- Exception handling: Three common exception types — missing DingTalk fields, Kingdee account validation failure, payment voucher number conflict — each take a different fault-tolerance branch, are written to the run log, and trigger an enterprise WeChat alert.
Implementation Steps
We break this strategy into three phased scheduling stages, rolling out gradually:
Step 1: Build the incremental starting point (T+1 early morning) Pull all reimbursement forms approved the previous day in the early hours and load them into a staging table. This step only "fetches + loads to staging"; it does not write to Kingdee directly. Its purpose is to decouple DingTalk's rhythm from Kingdee's.
Step 2: Full-volume trigger (1st of each month, 06:00)
Trigger aggregation by period: merge all approved reimbursement forms from the previous month into one payment voucher and push to Kingdee. In the Qeasy scheduler, set this strategy's crontab to 0 6 1 * *, and attach a dependency — this strategy only runs after DingTalk's full backfill strategy completes, preventing aggregation before month-start data is fully loaded.
Step 3: Scheduling frequency and rerun
- Incremental: once daily;
- Monthly aggregation: once per month;
- Failure rerun: manual trigger, rerun only a specified period;
- Full backfill: only on initial go-live or after major mapping changes; disabled otherwise.
The dual-track approach of incremental + full-volume is a common pattern among Qeasy customers: incremental guarantees timeliness day-to-day, full-volume provides month-end fallback.
Pitfall Retrospective
1. Mapping scattered across multiple strategies becomes unmaintainable. The typical mistake is writing an if-else for "expense type → account" inside every strategy. Three months later, adding one expense category means editing a dozen strategies. The safe practice is to centralize all mappings in a Qeasy mapping table and have strategies reference rather than hardcode.
2. Pushing header and body together — one row failure rolls back the entire document. Kingdee payment voucher header (FBillNo, date, applicant) and body (detail lines) must be written in two phases: create the header first to obtain FBillNo, then write the body. In one customer engagement we saw a header validation failure roll back the entire voucher, requiring manual cleanup of garbage data in Kingdee. Phasing eliminates this.
3. Using "submit time" as the incremental window causes severe data loss. Forms submitted Friday and approved Monday will never be captured by submit-time filtering. The incremental window must use "approval completion time", and the month-start full backfill should backstop by period.
4. Month-end forms still under approval get dropped. Forms still being approved at 23:50 on the last day of the month are not picked up when aggregating by period = current month. The safe approach is to set the aggregation window as "1st of last month to 02:00 on the 1st of next month", giving the approval flow a 2-hour buffer.
5. Rerunning the strategy produces duplicate payment vouchers. When Kingdee does not enforce a unique key, every rerun creates another voucher. We insist on the two-step "query-then-save" approach and use period + applicant as the business unique key — repeated execution updates rather than creates.
Applicable and Non-Applicable Scenarios
Applicable: monthly reimbursements, expense-based payments, documents that need periodic aggregation; hybrid architectures where approval lives in DingTalk and accounting lives in Kingdee. Non-applicable: urgent reimbursements requiring real-time per-document payment (use a real-time payment voucher sync strategy instead); scenarios where the reimbursement document structure differs so radically from Kingdee payment vouchers that middle-layer mapping cannot reconcile them; and businesses where DingTalk approval nodes change too frequently to stably capture approval completion time.