Syncing Feishu Payment Requests to Kingdee Cloud Skylight: A Practical Guide Using the Daily Payment Request Form

What This Strategy Solves

At one retail client, expense reimbursement and daily payment approvals live in Feishu, while financial bookkeeping sits in Kingdee Cloud Skylight. After an approval finishes, business users want the result to automatically become a payment voucher in Kingdee, so finance no longer chases anyone for paperwork at month-end. This specific strategy takes the daily payment request form from Feishu, splits it by payment type (daily expense, procurement, payroll/tax), and writes the corresponding payment voucher into Kingdee. The value is closing the loop between approval and bookkeeping.

Data Flow and Field Mapping

Data flows from a Feishu approval instance into a Kingdee payment voucher, passing through Qeasy for field renaming, organization and bill-type code translation, and header/line-item splitting.

How to Configure in Qeasy

In the Qeasy data integration platform, this strategy belongs to the Feishu → Kingdee Cloud Skylight EXECUTE write-back chain. There are four key configuration points.

1. Source configuration: pick Feishu as the source platform, use the /open-apis/approval/v4/instances API, take serial_number as the primary key, and turn on autoFillResponse so response fields are parsed automatically without manual modeling.
2. Incremental window: pull by start_time / end_time on the source side. Bind to a relative variable such as {{CURRENT_TIME}}000 rather than hard-coded values.
3. Target configuration: pick Kingdee Cloud Skylight as the target, call batchSave, and route FBillNo through idCheck to avoid duplicate submissions.
4. Centralized code mapping: text-to-code conversions for bill type, organization, and currency should live in Qeasy's central code-mapping table rather than buried in individual field expressions. A common pattern we use with Qeasy clients is keeping all encoding lookups in one place so adding a new bill type later only touches one mapping.

Implementation Steps

We roll out this sync in three phases to keep the pace manageable.

• Phase 1: backfill the incremental starting point. In Qeasy, run a one-off 7-day retrospective to pull all approved Feishu requests that have not yet produced Kingdee vouchers. Run the backfill script separately from the regular schedule so dirty data never enters the daily flow.
• Phase 2: switch on full incremental flow. Once the backfill is reconciled, switch the strategy to the production schedule. The Feishu side polls near real-time (minutes-level) for completed approval events, and the Kingdee side writes through batchSave.
• Phase 3: schedule cadence and rerun mechanism. For daily payment request forms we recommend a 5–10 minute interval, plus a low-traffic full-pull at night as a safety net. Configure three retries on the Qeasy side and use FBillNo as the idempotency key so retries never produce duplicate vouchers.

Pitfalls We Have Seen

1. Timestamp units do not match. Feishu returns milliseconds while Kingdee FDATE expects a second-precision string. The fix is FROM_UNIXTIME(LEFT(...,10),'%Y-%m-%d %H:%i:%s'). Getting the unit wrong shifts dates by about 40 years.
2. Org fields carry suffixes. Feishu org fields look like xxx_code; you must SUBSTRING_INDEX(..., '_', 1) or Kingdee will reject with "organization does not exist."
3. No fallback in the bill-type branch. When business adds a new payment type that CASE WHEN does not cover, Kingdee falls back to a default type and books the wrong account. Give an explicit ELSE branch and wire up an exception alert.
4. Header and lines processed together. The Feishu detail widget is a single JSON blob; Kingdee needs it split into multiple entry rows. A pattern we often apply on Qeasy is two-phase processing: persist the header first, then loop and persist the lines, so each step has its own readable log.
5. idCheck left disabled in production. It is tempting to turn it off during debugging to retry freely, but if you forget to re-enable it, network jitter will produce duplicate vouchers—very painful during reconciliation.

When to Use and When Not to

Use when: approvals live in Feishu, bookkeeping lives in Kingdee Cloud Skylight, and approval results can map cleanly to voucher master data. Fits small-to-mid retail or service companies with stable field definitions and infrequent new bill types.

Do not use when: the approval flow needs complex budget reservation or contract settlement pre-processing; Kingdee is required to go through a workflow instead of direct EXECUTE; or the approval form structure changes too often and field semantics are unstable.