Practical Tutorial: Syncing DingTalk Reimbursement Orders to Kingdee Payment Vouchers
What This Strategy Solves
In one real project, a retail enterprise's procurement team used DingTalk to run the spot-purchase reimbursement workflow. Once approval went through, finance had to create a payment voucher in Kingdee Cosmic to complete payment reconciliation. The problem: doing it twice on each side made duplicate payments and missed payments equally likely. Our approach was to take DingTalk's approved reimbursement orders, shape them into Kingdee payment vouchers, and fully decouple the approval flow from the posting flow. Finance only has to look at Kingdee.
Data Flow and Field Mapping
The pipeline has three segments: DingTalk reimbursement order (source) → Qeasy Data Integration Platform (middleware) → Kingdee Cosmic payment voucher (target).
The middleware's job is not to "pass data along" but to "translate business." The table below lists the fields that need alignment most often:
| Business meaning | DingTalk reimbursement field | Middleware handling | Kingdee payment voucher field |
|---|---|---|---|
| Document number | Reimbursement number | Pass-through | Document number (source ref) |
| Payment amount | Applied amount | Pass-through | Payment amount |
| Payee supplier | Payee | Match against supplier master | Supplier code |
| Applying department | Applicant's department | Department mapping table lookup | Department code |
| Summary | Reason | Concatenate "Spot purchase + number" | Summary |
| Payment date | Approval timestamp | Take date portion | Business date |
| Payment method | Receipt method | Enum mapping | Settlement method |
| Expense account | Expense type | Centrally managed code mapping | Account code |
Note: suppliers and departments must already exist in Kingdee. The middleware only translates codes; it does not create master data.
How to Configure It in Qeasy
At the customer site we used Qeasy (轻易云数据集成平台). There are four configuration points for this scenario:
- Source retrieval. Use Qeasy's DingTalk connector to pull reimbursement orders incrementally by approval time, filtered to "Approval status = Approved AND Document type = Spot purchase."
- Data cleansing and mapping. Centralize code mappings in Qeasy's transformer: the four lookup tables for supplier, department, account, and settlement method live in one mapping set, so any future change happens in one place.
- Target write. Use the Kingdee Cosmic connector to call the payment voucher's save API and write the header and lines row by row. A safe practice is staged header-then-line writing: write the header first (capture Kingdee's returned FID), then use the FID to write the lines. This avoids half-success, half-failure records.
- Exception routing. Any order that fails to match a supplier code or account code goes automatically into Qeasy's exception queue for manual handling before being re-pushed, so dirty data never pollutes Kingdee.
Implementation Steps
We typically roll this out in three phases:
Phase 1: Anchor the incremental start point. On the very first run, do not insist on pushing from the very first record. Pick a clear business date as the anchor (for example, the first day of the current month) and pull incrementally from the approval time onward. This validates the pipeline quickly without historical reconciliation noise.
Phase 2: Full-trigger reconciliation. After incremental has run stably for a week, run a full backfill to reconcile against Kingdee's existing payment vouchers and confirm both amount and count match exactly. Only then switch the strategy to formal scheduling.
Phase 3: Stabilize scheduling frequency. A typical setup is an incremental run every 15 minutes, with a daily full backfill in the early morning as a safety net. Qeasy's scheduling policy supports an incremental + full dual track, where incremental handles real time and full provides a safety net for correction.
Pitfall Retrospective
Pitfall 1: Pushing supplier codes without mapping. Early in one engagement we wrote DingTalk's "Payee name" straight into Kingdee as if it were a code. Kingdee rejected the whole batch because the suppliers did not exist. The safe approach: suppliers must be set up in Kingdee first; the middleware maps name → code, and anything that cannot be mapped goes into the exception queue.
Pitfall 2: Mixing approval timestamp with payment date. DingTalk's approval time carries hour and minute. Pushing it raw makes Kingdee's business date fall late at night and disrupts the financial close. The safe approach: take only the date portion, and add a "next business day" rule if needed.
Pitfall 3: Writing header and lines through one call. We once saw a header write succeed while the line write failed, leaving Kingdee with empty payment vouchers. The safe approach: stage the writes, link them through the FID, and make failures replayable.
Pitfall 4: No one owns the exception queue. The queue existed but had no assigned owner, so dirty data piled up for a week. The safe approach: in Qeasy's alert configuration, attach an on-call owner so any exception gets a response within 30 minutes.
Pitfall 5: Incremental start point gets casually reset. During maintenance, someone accidentally moved the start point to an earlier date and a flood of historical records got re-pushed. The safe approach: treat the incremental start point as a controlled parameter and require approval with an audit trail for any change.
When to Use and When Not to Use
Use when: approvals live in DingTalk, bookkeeping lives in Kingdee, and reimbursement types are relatively stable (in this case, spot purchase). Typical for small and mid-sized retail, trading, and services businesses.
Do not use when: reimbursement types are many and the account structure changes frequently (mapping-table maintenance becomes too costly), or Kingdee itself must run workflow-based approval (which would mean two parallel approval flows and is not worth the cost).