Kingdee Cloud Galaxy x Feishu Supply Chain Integration: 16 Strategies to Close the Loop on Procurement, Sales, and Finance Approvals

Scenario and Value

In mid-to-large enterprises, daily operations such as procurement, sales, and expense reimbursement typically span both the ERP system and the mobile approval platform. Kingdee Cloud Galaxy is responsible for persisting business documents and financial vouchers, while Feishu carries approval flows plus personnel and department data. When these two systems remain isolated, several common problems arise: after a business user initiates a purchase order in ERP, they must switch to Feishu and manually fill out the approval form; once the approval is complete, the result has to be returned manually to ERP to perform the audit operation; and master data such as suppliers, employees, and expense items are maintained inconsistently across the two systems, leading to code conflicts or failed postings.

This solution uses the Qeasy iPaaS integration platform as the hub, building 16 synchronization strategies between Kingdee Cloud Galaxy and Feishu, covering five business domains: master data, purchase orders, sales orders, financial documents, and other expenditures. The value is reflected in three points. First, after a business document is initiated, it flows automatically into Feishu for approval, and once approved, it is written back to ERP to complete the audit, eliminating manual handoffs. Second, codes for personnel, departments, suppliers, and expense items are uniformly cached and mapped in the platform hub, avoiding master-data drift across systems. Third, all strategies support retry, idempotency, compensation, and alerting, enabling stable operation in a public-cloud environment.

Integration Architecture and Data Flow

The overall architecture consists of Kingdee Cloud Galaxy, Feishu, and the Qeasy iPaaS integration platform. Data flow is divided into three directions.

First, Galaxy → Feishu (4 strategies). Galaxy purchase orders, sales orders, prepayment bills, and payment bills are synced to Feishu via strategies 3, 6, 10, and 11, generating corresponding approval instances. During sync, the platform looks up user_id from the "Fetch Feishu Personnel" hub by creator_name via collection, and writes the Galaxy document number bill_no / billno back to the form6 field of the Feishu approval form, where downstream audit strategies can read it.

Second, Feishu → Galaxy (10 strategies). Once Feishu approval is passed, strategies 4, 5, and 12 call the Galaxy audit interface /jdy/v2/sys/common_operate to complete the audit of purchase orders, sales orders, prepayment bills, and payment bills. Strategies 7, 8, 9, 13, 14, 15, and 16 sync prepayment applications, payment applications, travel reimbursements, routine expense reimbursements, loan applications, loan write-offs, and prepayment write-offs to Galaxy as prepayment bills or other expenditure bills. These strategies generally depend on hubs such as "Query Galaxy Supplier," "Query Galaxy Employee," and "Query Galaxy Expense Item" to look up master-data IDs by name.

Third, Feishu → integration platform hub (2 strategies). Strategies 1 and 2 call Feishu open APIs every morning at low traffic, caching personnel and department data into the platform hub for all strategies that depend on user_id and department affiliation.

There are clear execution dependencies among strategies: strategies 1 and 2 must run before purchase-order, sales-order, and payment-related strategies; strategies 3, 6, 10, and 11 must run before their corresponding audit strategies; and financial strategies depend on the supplier, employee, and expense-item hubs.

Interface List

Implementation Points

Field mapping and encoding rules. Header fields for purchase-order, sales-order, and audit strategies are mostly direct mappings. The critical fields are the initiator user_id (COLLECTION lookup against the Feishu personnel hub) and the document number bill_no (DIRECT, written back to Feishu form6 for downstream audit positioning). Financial strategies such as prepayment applications, payment applications, and travel reimbursements use TRANSFORM: dates are normalized via a datetime filter, document numbers are concatenated with business prefixes (YFSQ-, FKSQ-, CLFBX-, RCFB-, JKSQ-, JKHX-, YFCX-), and supplier IDs are looked up by name. Strategy 12 (payment audit) determines entity_number by the form6 prefix (YFKD% → ap_prepaybill, otherwise ap_paybill), then calls common_operate to complete the audit. Line items generally use ARRAY mapping, passing the entire Feishu detail control into Galaxy pay_entry_list or the material detail table.

Master data prerequisites. All strategies depending on user_id and department affiliation must be enabled only after strategies 1 and 2 have completed their first run; otherwise, initiators cannot be matched and documents will hang under the default approver. Master data such as suppliers, employees, and expense items must be maintained on the Galaxy side first; the platform only looks up IDs by name and does not maintain new master data.

Exception handling. Network timeouts use exponential backoff (5s/15s/45s, up to 3 retries); rate limiting (HTTP 429) waits 60s and retries up to 2 times. A single failure does not block the whole batch; failed records are written to the failure table. The primary key (serial_number, bill_no, billno) enforces idempotency, so re-sent data is updated rather than duplicated. Lookup misses are logged with the missing values and trigger alerts, but do not abort the flow.

Scheduling. Master-data strategies (1, 2) run once daily at 3 2 * * *. The 4 Galaxy→Feishu business strategies run on a 1-59/2 cadence between hours 7 and 21. Feishu→Galaxy audit strategies run on 0-59/2 between hours 7 and 22. Feishu→Galaxy financial strategies extend coverage to hour 23. After initial deployment or data repair, perform staged full reconciliation; daily operation switches to incremental sync based on start_time and modify_time.

Best Practices

First, treat the master-data sync strategies as the "faucet" of the entire integration chain. Whenever strategies 1 and 2 experience anomalies, every downstream strategy that depends on user_id and department data will trigger alerts or even fail, so they should be at the top of the monitoring dashboard.

Second, the document-number prefix must be agreed with the business side during the design phase. The form6 field on Feishu is not merely a display field—it is the sole basis on which strategy 12 distinguishes prepayment bills from payment bills. Once the prefix definition is changed mid-flight, the handling of historical unaudited documents must be re-evaluated.

Third, master data such as suppliers, employees, and expense items should have Galaxy as the single source of truth; Feishu only passes names. The platform hub only caches the name-to-ID lookup and does not perform bidirectional maintenance, avoiding master-data drift between the two ends that could lead to failed postings.

Fourth, set alert thresholds according to the business rhythm: a single-run failure rate above 10% should trigger a warning; three consecutive total failures should trigger a severe alert (prioritize checking credentials and interface changes); a strategy with no successful record for 24 consecutive hours should trigger an informational alert (verify whether the business has new data or whether the incremental conditions are appropriate).

Fifth, all credentials, keys, and organization IDs are stored in the Qeasy platform connectors with tenant-level isolation, strictly following the principle of least privilege. Real customer names, company names, credentials, keys, and other sensitive information must never appear in solution documents or strategy configurations.