Sync Feishu Loan Requests to Kingdee Other Expense Vouchers: A Qeasy Single-Strategy Tutorial
What This Strategy Solves
The business story is straightforward. Employees file loan requests through a Feishu approval flow. Once approved, the voucher needs to land in Kingdee for financial verification and payment. If both sides rely on screenshots and manual reconciliation, by month-end you will see "approved but not booked" or "paid but no approval record." We use the Qeasy Data Integration Platform to sync approved Feishu loan requests into Kingdee Other Expense Vouchers, so the approval flow and the finance flow speak the same data language.
Data Flow and Field Mapping
The overall flow is Feishu (Loan Request) → Qeasy Middle Layer → Kingdee (Other Expense Voucher). The middle layer does more than transport. We handle encoding mapping, field normalization, and deduplication there.
A typical field mapping looks like this (only key fields; real projects follow both sides' metadata):
| Business Meaning | Feishu Side | Middle Layer | Kingdee Side |
|---|---|---|---|
| Document Number | Request ID | biz_no (unified numbering) | Voucher Number |
| Applicant | Submitter user_id | Applicant Name/Employee ID | Applicant |
| Loan Amount | Requested Amount (yuan) | amount (2 decimals) | Amount |
| Purpose | Reason | remark | Summary |
| Department | Department ID | Department Code | Department |
| Approval Status | approve_status | Status: Pending/Approved/Rejected | Only "Approved" |
| Request Date | create_time | biz_date | Business Date |
Watch-outs: Feishu amounts are in yuan, while Kingdee sometimes stores in fen. Normalize decimal places in the middle layer. Applicant and department rely on different primary keys on both sides. Maintain a centralized mapping table instead of hardcoding in scripts.
How to Configure in Qeasy
In the Qeasy Data Integration Platform, this strategy is typically configured around these points:
- Source Pull: Trigger on the Feishu approval "Approved" event. Do not pull drafts or in-progress items. Use
approve_timeas the incremental field. Start with a full backfill, then switch to incremental. - Target Write: Use the standard Kingdee Other Expense Voucher API. Expense lines should be split according to the loan purpose.
- Encoding Mapping: In Qeasy's mapping module, centralize master data such as applicant, department, and expense item into one mapping table so future maintenance touches one place.
- Header-Body Phased Rollout: Stabilize the header first (applicant, amount, date, summary), then add the body (expense item, payment method, attachments). Phased rollout surfaces issues faster.
- Error Handling: Three common error types — missing source fields, unmapped target codes, and amount limits — should be routed to retry, manual queue, and alerting respectively, so one bad row does not stall the whole batch.
Implementation Steps
We usually split a go-live into three phases:
- Incremental Start Point: Choose the first day of a natural month as the
approve_timestarting point. Run a full backfill once, then switch to incremental. Always rehearse full runs in a test environment twice first. - Full Trigger: Full loads in Qeasy can be triggered manually. Add a second confirmation switch to prevent dirty data from being written into Kingdee by mistake.
- Schedule Frequency: Approval sync does not require real-time latency. A 5–10 minute cycle is sufficient. If the customer wants immediate visibility after approval, switch the trigger to "approval callback + fallback polling" — the polling acts as the safety net when callbacks are lost.
Lessons Learned
- Incomplete State Machine Handling: Feishu approvals include Approved, Rejected, Withdrawn, and Transferred. Filtering only Approved is not enough. You also need to decide whether Withdrawn should reverse the voucher already written. A safe pattern is to maintain a state transition table in Qeasy and disallow overwriting once written.
- Scattered Encoding Mapping: The most common first-project mistake is scattering applicant/department mapping inside scripts. Three months later, a staff change breaks it silently. We now require all master data mappings to be centralized in Qeasy's mapping center.
- Mixed Amount Units: Converting yuan to fen must happen in the middle layer, not at the target side. Otherwise you get 0.01 rounding gaps.
- Lost Attachments: Loan requests often include invoice or contract screenshots. Download or relocate the attachments inside the middle layer. Do not pass raw URLs through to Kingdee.
- Re-runs Causing Duplicates: If the incremental start point is chosen wrong, a full rerun creates duplicates. A safe pattern is to generate an idempotency key per record — we recommend
Feishu document number + approval time— and deduplicate on the Kingdee side by that key.
Applicable and Non-Applicable Scenarios
Applicable: Organizations that use Feishu as the unified approval entry and Kingdee as the financial book of record, and want a single approval flow to drive both systems.
Not applicable: Cases where loan approvals originate entirely inside Kingdee, or where Kingdee requires complex expense budget controls that Feishu cannot provide enough context for. In those situations, forced synchronization leads to heavy manual cleanup.