Ctrip Business Travel Monthly Settlement Payment Request Flow: A Practical Guide to Syncing Financial Documents from Weaver OA to Kingdee Cloud

What This Strategy Solves

Monthly travel settlement is a recurring cost for corporate-travel-heavy businesses. Employees book trips through a travel platform, finance raises a monthly settlement payment request in Weaver OA, and once approved, the payable must be written into the Kingdee Cloud payable ledger. It may look like a simple document copy, but the pipeline goes: trip statement aggregation → OA approval nodes → payable generation → voucher posting. Any misalignment in between means finance has to reconcile manually. In a recent private-deployment project, we used Qeasy (Qingyiyun Data Integration Platform) to host this end-to-end flow as a single strategy: the moment OA approval completes, Kingdee generates the payable automatically.

Data Flow and Field Mapping

Data flows from Weaver OA (source) to Kingdee Cloud (target). Qeasy streams it directly with no staging database. The key field mapping is shown below:

Business meaning	Weaver OA field (source)	Qeasy middle layer	Kingdee Cloud field (target)	Note
Request number	request_no	request_no	FBillNo	Bill no., used as idempotency key
Applicant	applicant	applicant	FApplicant	Job-based mapping
Requesting department	dept	dept	FDept	Centralized department code mapping
Settlement month	settle_month	settle_month	FPeriod	yyyy-MM format
Travel supplier	supplier_cpt	supplier_cpt	FSupplierId	Travel platform mapped to Kingdee supplier
Payable amount	amount	amount	FAmount	Two decimal places
Currency	currency	currency	FCurrency	Default CNY
Description	summary	summary	FDescription	dept + month + supplier
Approval time	approve_time	approve_time	FApproveDate	Used as voucher date

All source fields are passed as plain strings. Type conversion happens only inside the mapping layer of Qeasy.

How to Configure It in Qeasy

The strategy is built in Qeasy's standard flow editor with four core nodes:

Trigger: Listens to Weaver OA's "approval completed" event (flow status = Approved), polled every 5 minutes to avoid missing instant documents.
Data Reader: Calls the Weaver OA flow instance API, fetching the header and entry rows by request_no. The phased header-then-entry pattern is the most common Qeasy customer pattern—we write the header first, and only after a successful receipt do we add entry rows, avoiding half-written bills.
Mapping and Cleansing: All codes (department, person, currency, supplier) go through Qeasy's centralized code-mapping module. New codes are added in one place—no hard-coding inside scripts.
Writing to Kingdee Cloud: Calls Kingdee's payable SaveAndCommit API, and writes the Kingdee bill number back to an extension field on Weaver OA for traceability.

Implementation Steps

We recommend rolling this out in three phases:

Phase 1: Reconciliation from the incremental starting point. First, run a full historical backfill covering the last three months of approved requests to populate missing payables in Kingdee. Then switch to incremental mode using approve_time > last sync time as the starting window. A common pitfall: using approve_time alone as the unique key causes merged requests approved on the same day to be dropped. The safe pattern is to use request_no as the idempotency key and approve_time as the incremental window.
Phase 2: Manual full-volume trigger. Switch to manual triggering to align with finance's monthly close cadence. Run a full volume once in the first week of each month as a safety net.
Phase 3: Scheduled execution. Once stable, configure a crontab with incremental and full-volume running in parallel: incremental at dawn every day, and full-volume validation on the 3rd and 4th of each month. Any missed bill is caught within 48 hours.

Lessons from the Field

Approval status write-back delay. The Weaver OA flow API carries a 1–3 minute latency, so listening only to "Approved" misses some instant documents. We set the Qeasy polling window to 5 minutes and rely on request_no deduplication on the Kingdee side, so the occasional "read Not-Approved first, then Approved" pattern never produces duplicates.
Currency and exchange-rate rules. Most travel bills settle in CNY, but some overseas trips are billed in foreign currency. The source field is a string, so Qeasy's mapping layer must apply business conversion rules—otherwise Kingdee rejects the bill because of invalid FCurrency values.
Missing supplier records. If the travel platform's supplier code is not pre-created in Kingdee, the write returns 404. We attach a "supplier pre-check node" in Qeasy: before writing, query Kingdee's supplier list, log an alarm, and let the master-data team backfill and rerun.
Approval rejection and resubmission. When an employee is rejected and resubmits, a new request_no is generated, but Weaver retains the old flow instance. Do not correlate by flow instance ID—always correlate by the business request number.
Large-entry row truncation. A few monthly statements exceed 200 lines, which trips API pagination limits. Qeasy's reader must page explicitly and the entry entity must be committed in batches to keep payloads manageable.

Where This Applies and Where It Does Not

Applies to: corporate-travel-heavy businesses with a standardized OA form, stable approval nodes, and complete Kingdee-side supplier and department records. Does not apply to: real-time reimbursement (approve-and-pay per expense), scenarios needing complex cost allocation rules (e.g. allocating travel by project), or environments where the source form fields change frequently.