Hotel Settlement Sync in Practice: A Single Strategy from Ctrip Business Travel to Kingdee Cloud Galaxy
What This Strategy Solves
After a retail group moved all employee hotel bookings to Ctrip Business Travel, monthly settlements became the finance team's pain point: documents had to flow from Ctrip into Kingdee Cloud Galaxy to generate vouchers, with a manual reconciliation sheet in between—and month-end variances routinely ran into dozens of line items. The first strategy we built on the Qeasy data integration platform was "Ctrip hotel settlement → Qeasy middleware → Kingdee Cloud Galaxy." It does not answer "can we move the data," but rather "can the incoming fields directly produce a voucher."
Data Flow and Field Mapping
The pipeline is one-way: Ctrip Business Travel as the source, the Qeasy integration platform as the middleware layer, and Kingdee Cloud Galaxy pulling from the middleware. The middleware layer is critical here—it is the single convergence point for field mapping and the reusable "template backbone" for later strategies such as air ticket and rail ticket settlements.
Key field mapping (sanitized):
| Business Meaning | Ctrip Source Field | Qeasy Middleware | Kingdee Target Field |
|---|---|---|---|
| Settlement No. | settlement_id | doc_no | FBillNo |
| Traveller | employee_name | traveller_name | FTraveler |
| Stay Range | check_in / check_out | stay_range (concatenated) | FCheckInDate / FCheckOutDate |
| Hotel Name | hotel_name | hotel_name | FHotel |
| Order Amount | order_amount | amount (2-decimal precision) | FAmount |
| Currency | currency | currency | FCurrency |
| Cost Center | cost_center_code | dept_code | FDeptCode |
| Traveller Department | dept_path | dept_path | FDeptPath |
A common action: the source provides path-style departments (e.g., "Group/East China/Shanghai Store"), while Kingdee needs codes—the middleware must perform a "path → code" lookup. A typical Qeasy customer pattern is to centralize this mapping table in the platform's data dictionary rather than scatter it across scripts.
How to Configure on Qeasy
On the Qeasy data integration platform, this strategy has four configuration blocks:
- Data source connections: configure the Ctrip open API credentials (access key and secret managed in the platform's credential vault, never embedded in the strategy); configure the Kingdee organization code and book authorization on the target side.
- Table registration: register Ctrip's "hotel settlement" as the source table, register Kingdee's "T&E expense document" as the target table, and use the platform's built-in "settlement middleware table" as the middle layer.
- Field mapping: beyond the one-to-one mappings above, apply two rules—all amount fields run
round(amount, 2)in the middleware, and all date fields normalize toyyyy-MM-dd. Date formats are the classic pitfall in cross-system integration; normalizing them once benefits every subsequent settlement strategy. - Write mode: on the Kingdee side, use a two-step "save + submit" pattern—write to draft state first, then trigger submit via the platform's audit node, to avoid the scenario where data is saved but never audited and finance cannot find it.
Two lightweight but critical toggles: the idempotency key is a composite of "settlement no. + traveller + check-in date" so that retries do not duplicate documents; failure retry uses three rounds of exponential backoff, after which failed items fall into a manual work queue.
Implementation Steps
When implementing for customers, we usually break this strategy into three phases:
- Phase 1 — Incremental baseline alignment. First run a full historical pull (typically the 3 months preceding go-live) as the baseline. From day two onward, switch to incremental mode using the settlement's last-modified timestamp as the cursor.
- Phase 2 — Scheduling frequency. Hotel settlements do not need second-level latency—typically scheduled at 02:00 and 14:00 daily, covering Ctrip's two billing windows. A common dual-track approach among Qeasy customers is incremental scheduled runs plus a weekly full-volume reconciliation that only audits and never writes.
- Phase 3 — Reconciliation loop. After each run, diff the day's source-side document ID set against the target-side document ID set, and push discrepancies into a reconciliation report for finance. This is what kills most disputes before they escalate.
Field-Tested Pitfalls
- Inconsistent date formats. Ctrip returns
2024/01/05 12:00while Kingdee expects2024-01-05—without normalization, an entire batch of date fields is unusable. The safe approach is to canonicalize all dates/times once in the middleware. - Department code mapping drift. When the org structure changes, path-style departments shift and old mappings break. Keep the mapping table centralized in the platform's data dictionary and re-resolve it before each run—do not cache it inside the strategy.
- Currency precision loss. Cross-border travel produces multi-currency cases: the source sends string codes like "CNY" or "USD", but Kingdee needs the currency code together with the exchange rate date. Sending only the code is insufficient.
- Over-simplified idempotency key. Using only the settlement no. as the key causes duplicates when Ctrip resends the same record. A composite of "settlement no. + traveller + check-in date" essentially eliminates duplication.
- Skipped audit step. An early version only configured "save" without "submit for audit," so documents remained in draft state and finance never saw them. When using header/body staged submission, always wire up both actions.
When to Use and When Not to Use
Use it when: employee travel is concentrated on Ctrip Business Travel, monthly reconciliation is the norm, and Kingdee Cloud Galaxy is the sole finance system—typical for mid-sized and above enterprises.
Do not use it when: travel is spread across multiple OTA platforms, reconciliation cycles are shorter than a day, or per-document real-time audit is required—those cases favor event-driven push plus manual triggers over scheduled sync.