Financial Sync in Practice: Receipt & Refund Vouchers to Account Expense Flow from Kingdee to Fenxiaoke
What This Strategy Solves
In supply-chain and finance integration projects, receipt vouchers and refund vouchers are the key documents linking front-end business and back-end finance. One fast-moving consumer goods company generates large volumes of such vouchers daily in Kingdee Cosmic, and they need to flow back into Fenxiaoke to reconcile advance payments by customer or distributor, offset open order amounts, and form account expense flow records. Once the two sides drift, sales reconciliation becomes a manual Excel exercise, and month-end closing turns into overtime work.
We use the Qeasy data-integration platform (Qeasy) to carry this pair of syncs. Kingdee Cosmic is the source of vouchers, Fenxiaoke is the destination of expense flow, and we use an incremental approach to write each entry. The goal is simple: as soon as a voucher is posted, it appears in the flow.
Data Flow and Field Mapping
Data flow: Kingdee Cosmic (System B) → Qeasy middle layer → Fenxiaoke (System A).
The middle layer is not just a transport cart, but the place where three things happen: code mapping, time-window filtering, and field reshaping.
| Business meaning | Kingdee Cosmic source field | Middle-layer handling | Fenxiaoke target field |
|---|---|---|---|
| Document number | FBillNo | Pass through | external_no |
| Document type | FDocumentType | Enum mapping: receipt→RECEIPT, refund→REFUND | flow_type |
| Amount | FReceiptAmount / FRefundAmount | Split by type into a unified field | amount |
| Customer / distributor | FCustId | Lookup by code-mapping table | account_id |
| Business date | FBusinessDate | Convert 8-digit date to ISO8601 | occurred_at |
| Remarks | FNote | Concatenate source identifier | remark |
| Status | FDocumentStatus | Only "Approved" flows through | flow_status |
Centralised code mapping is a common pattern among Qeasy customers: source IDs to target IDs for customers, products, and departments are all kept in a single mapping table, looked up at write time, avoiding scattered maintenance across many strategies.
How to Configure It in Qeasy
- Register data sources: register both Kingdee Cosmic (via the Cosmic open platform) and Fenxiaoke (REST API) connectors inside Qeasy, with credentials stored by the platform's secret manager, never on an engineer's local machine.
- Source query strategy: on the Kingdee side, use incremental query by document date. Pull voucher sets daily where "business date >= last successful sync date + 1" and "document status = Approved".
- Target write approach: adopt staged validation — first write the header (with unique constraint on external_no + flow_type), update on hit, insert on miss, avoiding duplicate postings.
- Field mapping and transformers: configure conversion rules in Qeasy's field-mapping canvas, including enum mapping, date formatting, and null fallback (record 0 when amount is empty).
- Error handling: the platform's header-then-body staged pattern fits this scenario well — first verify the header trio (number, type, date), and only then fill in detail amounts and notes; any failure triggers automatic retry and alerting.
Implementation Steps
Week 1 | Full initialisation
Manually pick a historical cut-off (for example, the 1st of the current month), run a full backfill of all "Approved" documents on that day, and establish the Fenxiaoke expense flow baseline. After full completion, record the baseline timestamp T0.
Week 2 onwards | Incremental sync live
Scheduling frequency is recommended at every 15 minutes. The incremental start point is fixed at T0 + 1; each subsequent pull fetches vouchers where "business date > last maximum business date synced". Three details matter:
- Use business date instead of created time as the cursor to block dirty data from backdated or modified orders;
- Vouchers in the same batch must be written in ascending order by document number to preserve downstream dependencies;
- On a target-side write failure, Qeasy automatically retries 3 times; persistent failures go to a dead-letter queue for manual review.
Month end | Reconciliation and boundary fixes At month end, run a reconciliation pass. If vouchers for a given day are missing, append their source document numbers to the incremental whitelist and trigger a one-off backfill. Incremental and full volumes run on two tracks: the daily incremental is the heartbeat, the monthly full is the health check.
Lessons from the Field
- Using "created time" as the incremental cursor — a classic mistake. In backdated scenarios, the created time is earlier than already-synced vouchers, causing the same-numbered voucher to be overwritten. The reliable approach is business date or last modified time.
- Code mapping scattered inside conversion scripts — in one project the customer-code mapping table was written into script constants, and three months later new customers came in and engineers had to patch every script. A centralised mapping table with regular refresh is the correct path.
- Refund direction reversed — whether a refund in Fenxiaoke's expense flow is negative or positive must be aligned with business from day one. We handle it as "signed value by direction, downstream displays absolute value with a sign bit for direction" to avoid later reversals.
- Full-volume vs incremental collisions — when full backfill runs concurrently with incremental, target-side write conflicts surge. During implementation, stop the incremental schedule during the full-volume window and release it only after full backfill is verified.
- Idempotency keyed only by document number — same number but different business (for example, a reversal) will collide. Recommend external_no + flow_type as the composite unique constraint.
Suitable and Unsuitable Scenarios
Suitable: Kingdee Cosmic as the voucher source, Fenxiaoke needs account-level flow analysis, high voucher volume with daily or hourly write-back required.
Unsuitable: scenarios demanding real-time sub-second sync, or where vouchers must first be approved inside Fenxiaoke and then flow back into finance — the latter is "bidirectional sync" territory and should be handled by a separate approval-node strategy rather than this sync pattern.