Syncing Kingdee Cloud Skylight Bills to Feishu Bitable: A Single-Strategy Tutorial on Qeasy

What This Strategy Solves

At one retail company, supply-chain bills lived in Kingdee Cloud Skylight while operations and procurement teams collaborated on Feishu. Reconciling, chasing materials, and triaging exceptions all happened in a Feishu Bitable. Previously, the numbers on each side were reconciled through manual spreadsheet exports — a missed or wrong export would only be noticed three days later. This strategy has one goal: push bills in "approved" status from Kingdee Cloud Skylight into a Feishu Bitable on an hourly incremental basis, so both sides always match and the business no longer depends on manual sync.

Data Flow and Field Mapping

The flow is unidirectional: Kingdee Cloud Skylight (source) → Qeasy integration platform (middle layer, handling query, transform, and batch assembly) → Feishu Bitable (target).

The source calls Kingdee's executeBillQuery API (POST). FBillNo is used as the bill number field, FDetailEntity_FEntryID is the entry-row ID, and idCheck is enabled so a row is written at most once. Key request fields:

In the middle layer, three things must happen on Qeasy: first, abstract the "base-data.code" access pattern (e.g. FMaterialId.fnumber) into a centralized code-mapping table; second, filter by status and only take C (approved); third, deduplicate by the composite key FBillNo + FDetailEntity_FEntryID to avoid duplicate writes during concurrent schedules.

The target calls Feishu Bitable's /open-apis/bitable/v1/apps/:app_token/tables/:table_id/records (RESTful POST), with fields as the body. There's a common trap here: Feishu does not have an "auto-overwrite" semantics — the default is insert. Idempotency requires the middle layer to query by bill number first, PATCH on hit, POST on miss.

How to Configure It on Qeasy

On the Qeasy integration platform, this strategy is built as a three-stage "Query → Transform → Execute" pipeline.

Source configuration: select the executeBillQuery API, method POST, turn on idCheck, set the primary-key field to FDetailEntity_FEntryID, and the bill-number field to FBillNo. For the incremental starting point, start with a 7-day cold start, then switch to FModifyDate-based increment after stabilization.

Transformer configuration: use Qeasy's field mapper to map source fields onto fields. We recommend centralized code-mapping management — material, organization, and supplier codes are maintained in a single mapping table and reused across strategies; do not hard-code fnumber access rules in each strategy.

Target configuration: select Feishu Bitable records write, method POST, body goes into fields. To avoid duplicate rows, add a "query by FBillNo first" precheck step at the end of the transformer — PATCH on hit, POST on miss.

Implementation Steps

We recommend a four-phase rollout, each with a clear "go/no-go" criterion.

Phase 1, Cold-start full load: pull the last 7 days of approved bills into Qeasy at once, then manually reconcile both sides. Use this to verify mapping rules, code access, and status filtering. Phase 2, Gradual cutover: enable the production schedule (30 */1 * * *), keep the target table in "append only, no notifications" mode for 24 hours, and confirm no duplicate rows or empty fields. Phase 3, Bidirectional reconciliation: add a reverse check strategy on Qeasy (pull back from Feishu → compare against the Kingdee FBillNo set), with automatic alerting on differences. Phase 4, Full + incremental dual track: keep a daily early-morning full reconciliation task (40 */1 * * *, offset 10 minutes from the source), run hourly increments normally, and switch back to full on exception.

On cadence, the source uses 30 */1 * * * and the target uses 40 */1 * * *, deliberately staggered to avoid peaks at both ends simultaneously.

Pitfalls and Lessons

Pitfall 1: pulling FMaterialId instead of the code. The typical mistake is pulling FMaterialId directly, which writes Kingdee's internal ID into Feishu — completely unreadable to the business. The safe approach is to uniformly take fnumber, and add a second-level "Kingdee code ↔ Feishu business code" mapping in the code-mapping table.

Pitfall 2: Feishu's default is insert; without idempotency, duplicates appear. Feishu's records API does not natively overwrite. This is where things go wrong. Always add "query first, then write" in the transformer, or maintain a dedup table on Qeasy.

Pitfall 3: status filter intended in the request body but FDocumentStatus='C' actually missing. If the status condition is dropped from the source request, "Draft Z" rows come through and the business sees a pile of unapproved drafts.

Pitfall 4: using FDetailEntity_FEntryID as a header-level primary key. Business bills have a header + entry structure; headers repeat (the same bill number can be revised multiple times), and only entry-row IDs are real idempotency keys.

Pitfall 5: full and incremental running at the same time and overwriting each other. The safe approach is dual-track: hourly increment rolls on FModifyDate, and a daily early-morning full run provides a backstop — but writes still go through idempotency keys to avoid overwriting.

When This Applies — and When It Doesn't

Suitable for: enterprises where Kingdee Cloud Skylight and Feishu collaborate deeply, the business relies on Bitable for operations reconciliation, and the hourly volume is manageable (a few thousand rows per hour per strategy). Not suitable for: financial posting scenarios requiring strict transactional consistency — Feishu Bitable is not an accounting system and should not carry financial closing duties; also not suitable when volume far exceeds Feishu's write throughput — in that case land the data in a data warehouse first and let Feishu serve as a lightweight view.