DingTalk Project Reimbursement to Kingdee Payment Order: A Single-Strategy Sync Tutorial

What This Strategy Solves

A retail enterprise relied on DingTalk for project expense approvals, but finance had to record payments in Kingdee Cloud Galaxy. Because the approval flow and the ledger lived in different systems, project reimbursements piled up and reconciliation became painful — finance staff manually shuttled documents between the two systems, and errors were common.

On the customer site, our goal was simple: take DingTalk-approved project reimbursement forms and land them on Kingdee Cloud Galaxy payment orders under a stable encoding scheme — one approval, one ledger entry. This strategy is the tail end of the broader integration; it depends on department and project master data being aligned between the two systems first.

Data Flow and Field Mapping

The overall flow is: DingTalk (approval flow) → Qeasy Data Integration Platform (middleware) → Kingdee Cloud Galaxy (payment order). The middleware does not persistently store business data; it only handles field mapping, code translation, and document state bridging.

Key field mapping (abbreviated):

Centralizing the encoding mapping is a common pattern we see on Qeasy customer sites — keep DingTalk-side project codes, expense accounts, and payee info in a single mapping table, so future adjustments touch the table, not the flow.

How to Configure in Qeasy

Configuration highlights, in order:

1. Strategy identifier and dependencies: Create a new strategy in Qeasy with DingTalk as the source and Kingdee Cloud Galaxy as the target, business module labeled financial sync. Make sure prerequisite strategies (department query, project master sync) run first, otherwise codes will be missing.

2. Source data fetch: Use the completed approval instances in DingTalk as the filter — only pull instances whose status is "Finished" and result is "Approved". Filter out in-progress, rejected, and withdrawn instances to avoid noise.

3. Middleware processing: Use Qeasy transformers to perform code mapping, amount validation, date formatting, and payee matching. A common practice is to process header and body in stages — settle the header first, then back-fill the body via foreign key. This way a large-field failure won't break the whole document.

4. Target write: Call the Kingdee Cloud Galaxy payment order save interface. Use separate calls for "Save" and "Submit" depending on document state. On failure, drop the record into a middleware todo for manual investigation.

5. Exceptions and retries: Configure retry policies for three exception categories — network blips, missing codes, and amount overruns. Network errors retry immediately, missing codes go to the todo queue, amount overruns trigger an alert directly.

Implementation Steps

We typically break the rollout into four phases:

• Week 1, align the incremental start point: Manually export DingTalk reimbursements completed in the past 7 days and reconcile them one by one with Kingdee's historical payment orders. Once encoding, amount, and payee all match, lock that date as the incremental start point.
• Week 2, run a one-shot full sync: Trace back historical documents from the start point and manually trigger a full sync in Qeasy. During the batch run, finance pauses manual entries; afterwards, verify totals and counts.
• Week 3, enable scheduled runs: Configure a 15-minute incremental schedule in Qeasy. At 0:00 each night, run a difference check between new DingTalk approvals and new Kingdee payment orders; discrepancies go into an alert group.
• Week 4, observe and prepare rollback: Keep a manual channel open for two weeks. Only after verifying automation has no misses do we formally switch over. Meanwhile, prepare a rollback script so the strategy can be shut down quickly if it misbehaves.

The incremental-and-full dual-track is a pattern we have seen across Qeasy customers running cross-system financial document sync — no historical loss, no real-time pressure.

Pitfalls and Lessons Learned

• Classic mistake: incomplete approval-status filtering. Pushing in-progress reimbursements into Kingdee generated invalid payment orders. The safer approach is to filter at the source for "Finished + Approved" only, and add a status check again in the middleware.
• Payee matching misaligned. DingTalk's payee is an account name, but Kingdee needs the legal entity from the vendor master. You must match on both name and account; matching by name alone frequently collides with similarly named companies.
• Amount precision lost. DingTalk form amounts are stored as text; concatenating strings loses precision. Force conversion to decimal in the Qeasy transformer, with two explicit decimal places.
• Project code not aligned first. Starting payment order sync before prerequisite strategies complete leaves the related project empty. Project master data must finish syncing before payment orders.
• Retry amplifying exceptions. Unlimited retries on missing-code documents spam the alert channel with repeated failures. The safer approach is to categorize retries — business exceptions go to the todo queue and do not auto-retry.

Applicable and Non-Applicable Scenarios

This strategy fits: approval flow running on DingTalk, financial ledger on Kingdee Cloud Galaxy, relatively fixed document structure (project reimbursements), and mid-sized enterprises with daily volumes from tens to a few hundred documents. It does not fit: approval flows with frequently changing form fields, document structures not yet stable, or scenarios where daily volume exceeds several thousand and warrants a dedicated treasury system.