Syncing Feishu Purchase Orders to Xingchen: A Single-Strategy Walkthrough

What this strategy solves

In a retail-plus-manufacturing engagement, the client uses Feishu for purchase requisitions and collaboration, and Kingdee Xingchen for formal purchase orders and financial books. The recurring pain point: a requisition is fully approved in Feishu, but no purchase order ever appears in Xingchen, so suppliers deliver against an order that does not exist on the books and reconciliation drifts.

This strategy closes the loop. Once a Feishu purchase order is confirmed, the integration writes the record into Xingchen, generates a formal purchase order, and triggers approval — keeping requisition, approval, and execution on a single document.

Data flow and field mapping

Data leaves the Feishu approval flow, is cleaned and mapped through the Qeasy integration platform, and lands in the Xingchen purchase order endpoint. The core mapping looks like this:

A common Qeasy customer pattern is to handle the header and the lines in two stages: write the header keys (document number, supplier, requester) first, then process the line items. This avoids a single bad material row rolling back an otherwise good order.

How to configure it in Qeasy

Inside the Qeasy platform, this strategy is typically built as a Feishu → Xingchen sync flow. There are four configuration points worth highlighting.

First, on the source side, pick the Feishu approval instance API, and trigger only on "approved + business type = purchase order." Do not pull all instances; otherwise drafts and rejected requests will also be synced.

Second, on the target side, use Xingchen's purchase order save endpoint and chain the approval actions in the same flow: save, then submit, then audit, in that order.

Third, keep field mappings — especially supplier, material, and user master data — in Qeasy's centralized mapping table. Treat the mapping table as a maintainable resource so that adding a new supplier later only requires editing one table, not every flow.

Fourth, use Feishu instance_id + business prefix as the idempotency key, and write it straight into BillNo on the Xingchen side, so a replay does not create duplicates.

Implementation steps

Stage one, fix the incremental starting point. Run a one-off backfill of pre-cutover records using Feishu historical data, with the lower bound explicitly set to "the day before go-live" so the incremental run never re-processes legacy data.

Stage two, set the schedule. Feishu approvals are discrete events, so a 5-minute polling interval is sufficient. Going shorter tends to trip Feishu rate limits. The approval action should be triggered inline within the sync flow, not as a separate scheduled job — otherwise there is a window where the order exists but is not yet approved.

Stage three, roll out gradually. Pilot with one business unit and one supplier type for two weeks, watch mapping hit rates and rollback counts, then expand.

Stage four, run full and incremental in parallel: full for monthly reconciliation catch-up, incremental for daily sync, and reconcile both sides at month-end.

Pitfalls from real projects

First, decentralized material code mapping is the most common failure mode. Every strategy maintaining its own mapping script means three months later, materials do not line up and nobody knows which script is authoritative. The safe approach is to centralize mappings in Qeasy's resource layer and share them across all purchasing strategies.

Second, suppliers are referenced by name in Feishu but by code in Xingchen, and relying on manual maintenance will miss new entries. A typical mistake is capturing 200 suppliers at go-live and then never updating them, which causes order writes to fail silently.

Third, changes to the Feishu approval schema are invisible to the sync strategy. In one project, the client split "quantity" into "base quantity + auxiliary quantity"; the strategy kept mapping the old field, which doubled the received quantity in Xingchen.

Fourth, turning approval into a separate scheduled job creates a backlog of unapproved orders and triggers frequent reconciliation errors on the finance side.

Fifth, time zones are easy to overlook. Feishu timestamps carry time zone information, while Xingchen's document date is a plain date. Explicit timezone normalization is required, otherwise cross-midnight orders land on the previous day.

When this applies, and when it does not

Applies when Feishu is used for purchase requisition and collaboration, Xingchen is used for ERP order entry, and approved requisitions need to be written back as formal orders with approval triggered automatically. Does not apply when Feishu itself is the system of record for finance, when Xingchen has to support multi-org multi-book complex scenarios, or when sub-second real-time write-back is required — in those cases, use event push rather than polling sync.