Practical Guide: Syncing Yonyou NCC Receipts to Fenxiaokao Account Cash Flow

What This Strategy Solves

In a private-deployment project for a retail-channel integration, the customer ran front-end business on Fenxiaokao and back-end finance on Yonyou NCC. Both sides recorded the same receipt independently: front-end as account cash flow entries, back-end as receipt vouchers. The finance team reconciled weekly by exporting Excel files from both systems, which cost about two person-days every week.

We used the Qeasy data integration platform to do something straightforward but effective—automatically push Yonyou NCC receipt vouchers into Fenxiaokao account cash flow entries in the outflow direction, so the numbers stay aligned on the same day. Below is the end-to-end breakdown of this single strategy.

Data Flow and Field Mapping

The overall pipeline has three layers: source system (Yonyou NCC) → middle layer (Qeasy) → target system (Fenxiaokao account cash flow).

Key field mapping:

Business meaning	Yonyou NCC receipt	Fenxiaokao cash flow	Handling notes
Document number	vbillno	outer_no	Source ID as idempotency key
Receipt date	billdate	biz_date	Format to yyyy-MM-dd
Customer code	custcode	customer_code	Lookup in mapping table
Direction	paydirection (receipt)	direction	Hard-code "支出" (outflow)
Amount	money	amount	Two decimal places
Account code	bankaccountcode	account_code	Lookup in mapping table
Memo	memo	remark	Truncate to 200 chars

Code mapping (customer, account) is the most easily overlooked piece. Our approach is to centralize it in Qeasy's built-in mapping table component, which supports one-to-many mappings as well.

Configuring in Qeasy

The entire strategy lives inside one integration flow, with four core configuration blocks:

Source adapter: pick the NCC OpenAPI adapter, calling the receipt query endpoint with pagination and timestamp parameters to avoid pulling everything at once.
Data extraction: use Qeasy's "DB/API pull" node in incremental mode, with billdate as the incremental field.
Field mapping and cleansing: complete field rename, code replacement, and date formatting in the "Mapping Transform" node. Suggest isolating strongly-typed fields like dates and amounts—it speeds up debugging later.
Target write-back: use the Fenxiaokao OpenAPI adapter to call the cash flow creation endpoint, using outer_no as the dedup key so repeated pushes do not create dirty data.

In Qeasy's strategy canvas, source, transform, and target layers are wired together visually, with field-level previews at every step. This matters a lot in finance—one wrong field and the ledger will not balance.

Implementation Steps

We split the rollout into three scheduling phases to avoid crushing the downstream with a full sync on day one.

Phase 1: Incremental starting point On first launch, do not pull everything. Pick an "incremental start date" (usually 00:00:00 of the go-live day) and only push data after that point. This is configured directly in the strategy's "initial pull time" property in Qeasy.

Phase 2: Historical backfill Reconciliation needs historical data, so we configured a separate "full backfill" strategy that runs month by month and stops once finished. This only runs during migration and is shut off afterward.

Phase 3: Schedule frequency Reconciliation is daily. Since source writes peak in the afternoon, we scheduled a daily trigger at 18:00 with a one-hour window. Qeasy supports cron expressions, or you can use the built-in "daily/hourly" simple picker.

Also, turn on failure retries. NCC API timeouts are routine—we set 3 retries with exponential backoff, and failed batches go to a dead-letter queue for manual handling.

Pitfalls and Lessons Learned

A few mistakes we made along the way worth highlighting:

Decentralized code mapping. In v1 we hard-coded customer mappings inside a script. When a new customer type was added later, it was painful to change. The stable approach is to centralize everything in Qeasy's mapping table component so business users can maintain it themselves.
Date and timezone issues. NCC stores dates as datetime with time component; Fenxiaokao expects pure date. We forgot to truncate initially, so same-day entries landed on the next day and reconciliation was always off by one row. The reliable approach is an explicit DATE_FORMAT in the mapping layer.
Weak idempotency key. We initially used vbillno + custcode as dedup key, but found that multiple receipts for the same customer on the same day would overwrite each other. Switching to source document number vbillno alone as the unique idempotency key cleaned things up.
Pushing header and lines together caused write-back confusion. Receipt vouchers have line entries; pushing the whole document meant a partial line update could fail while the header was already written. The safer approach is to push header and lines in separate stages, with full rollback on failure.
Full backfill and incremental racing. Running full backfill and daily incremental simultaneously produced duplicates. Basic rule: run full backfill first, then start incremental.

When This Applies and When It Doesn't

Applicable: source and target both expose standard OpenAPIs, code systems are stable, daily reconciliation is enough, and sub-minute real-time is not required. Not applicable: scenarios requiring minute-level real-time writes (use a message queue instead), overly complex business rules on the target side requiring custom development, or cases where codes are persistently misaligned with no one to maintain the mapping table.