Yonyou NCC Receipt Voucher to Fenxi销售 Account Cash Flow Sync: A Private-Deployment Tutorial on Qeasy
What This Strategy Solves
A finance team typically faces this pain point: receipt vouchers recorded in Yonyou NCC need to be pushed, transaction by transaction, into Fenxi销售 account cash flow records on the expense side, so that front-office CRM users can reconcile incoming payments and expense claims in real time. Manual export is slow, balances frequently mismatch, and once cross-org payments or consolidated postings are involved, missing entries become the norm.
In the Qeasy data integration platform, this kind of "finance document → CRM cash flow" sync is a typical downstream document strategy: data flows from the back-office ERP to the front-office business system, with an intermediate layer handling code mapping, field enrichment, and status tagging. On customer sites we usually dedicate one standalone strategy to it, avoiding coupling with sales-order or customer-master strategies on the scheduling chain.
Data Flow and Field Mapping
The overall flow is Yonyou NCC (receipt voucher) → Qeasy intermediate layer → Fenxi销售 (account cash flow, tagged as expense).
Key fields (only the high-frequency, error-prone ones):
| Business Meaning | Yonyou NCC (Source) | Intermediate Layer | Fenxi销售 (Target) |
|---|---|---|---|
| Document No. | Receipt voucher No. | Pass-through | External document No. |
| Direction | Receipt (income side) | Invert to "expense" | Direction = Expense |
| Amount | Local-currency amount | No rounding, keep 2 decimals | Amount (original) |
| Counterparty | Customer/Vendor code | Centralized code mapping | Account/Object code |
| Memo | Memo text | Concatenate "NCC No.+memo" | Remarks |
| Business date | Voucher date | Normalize to UTC+8 | Occurrence date |
| Currency | Local currency | ISO-3 mapping | Currency |
A specific reminder: "direction inversion" is the most easily missed detail in this strategy. The source voucher is a receipt, but it lands on the expense-side flow, so the intermediate layer must explicitly mark the inversion—otherwise reconciliation will show "both sides are correct amounts but the directions are reversed," which is a classic silent failure.
How to Configure It on Qeasy
In the Qeasy data integration platform, this strategy is typically modeled as a three-stage pipeline: source reader → intermediate transformer → target writer.
- Source reader: configure the Yonyou NCC receipt voucher query view. The filter conditions should include
document status = approvedandlast modified time >= last sync time, so unapproved vouchers are blocked at the source. - Intermediate transformer: place the code-mapping table (customer/vendor → Fenxi销售 account), field enrichment, direction-inversion logic, and a "header-body staged" handling—per customer convention, this strategy only syncs the header-level flow, with body entries handled by a follow-up strategy, to keep each strategy simple.
- Target writer: call Fenxi销售's account cash flow write API, and perform idempotency checks (using the external document No. as the unique key) before writing, to prevent duplicate pushes.
Centralized code-mapping management is a very common pattern among Qeasy customers: all cross-system code mappings live in one maintainable mapping table owned by a dedicated steward, instead of being scattered across individual strategy scripts—three months in, no one remembers which rule lives where.
Implementation Steps
On customer sites we usually progress through four phases:
- Mapping-table preparation phase: spend roughly one week consolidating bidirectional code mappings for counterparties and importing them into the Qeasy mapping table; in parallel, confirm that currency, organization, and book basis data are aligned on both sides.
- Full-trigger phase: the first sync is typically a full backfill, usually covering the most recent six months of approved receipt vouchers; once the full run completes, freeze it and switch to incremental.
- Incremental starting point: take the full-run cutoff as the incremental starting point. Qeasy has a built-in watermark mechanism that automatically reads the last successful maximum timestamp on each scheduled run.
- Schedule frequency: finance scenarios do not benefit from high-frequency polling; 15-minute or 30-minute intervals are typical. A nightly compensation task is added to recover any data missed during the day due to network jitter.
This "incremental + full dual-track" is also a repeatedly validated pattern among Qeasy customers: the first full run establishes the baseline, normal operations run incrementally, and the two are carried by different scheduled tasks that never pollute each other.
Pitfalls and Lessons Learned
- Pitfall #1: pushing the receipt voucher straight through as "income". The strategy title already highlights that this is the expense-side flow. The source voucher is a receipt, so the intermediate layer must explicitly invert the direction—otherwise amounts match but directions are all wrong at reconciliation time.
- Pitfall #2: no idempotency check. Yonyou NCC receipt vouchers may be re-pushed after an unapprove–reapprove cycle. If the target side does not deduplicate using the external document No. as a unique key, duplicate entries will be written, and the front-office CRM will show two flows with the same document number.
- Pitfall #3: rounding the local-currency amount too early. The source amount field is often high-precision decimal. If the intermediate layer rounds too early, the target side will accumulate 0.01 tail differences during reconciliation; a few months in, the imbalance will surface in audit.
- Pitfall #4: code mapping scattered across scripts. Each strategy carries its own mapping logic; half a year later, when the customer reorganizes, every strategy must be edited individually, and omissions are almost guaranteed. The safer approach is to centralize the mapping in a single mapping table.
- Pitfall #5: ignoring time zones and date formats. The source date is a string, voucher time zones differ, and the target side uses yet another format. Without normalization, month-end reconciliation will throw batch failures. The safer approach is to perform date normalization in the intermediate layer.
When to Use and When Not to Use
This strategy applies when approved receipt vouchers need to land on the front-office CRM expense-side flow view, with master data (organization, currency, customer codes) already aligned and reconciliation required within roughly 30 minutes.
It does not apply to unapproved vouchers, when body-line details must also be synced, or when master data is not yet aligned on both sides—the latter should run a master-data strategy first, then the document strategy.