Practical Guide: Syncing Payment-to-Fee Receivable from CRM to Kingdee
What This Strategy Solves
In one retail client, sales expenses were managed in the CRM, where sales reps recorded "fee-to-goods-payment" entries. Finance, however, needed formal fee-based receivable vouchers in Kingdee for cost posting. With monthly Excel exports, month-end reconciliation often surfaced mismatches: payments clearly recorded in the CRM, yet absent from Kingdee receivables.
We built a single strategy in Qeasy to automate this: once a CRM payment order is triggered, it is converted into a Kingdee fee receivable voucher. Below is the field-tested walkthrough.
Data Flow and Field Mapping
The flow is one-way: CRM (source) → Qeasy middleware → Kingdee (target). The middleware only cleans, maps, and marks status — no business calculation.
Key field mapping (only the error-prone ones):
| Semantic | CRM Payment Order | Kingdee Fee Receivable | Notes |
|---|---|---|---|
| Voucher No. | payment_no | FBillNo | Direct mapping |
| Amount | amount | FReceivableAmount | Direct; mind the currency |
| Customer | account_id | FCustomerID | Translate via centralized encoding map |
| Fee Subject | fee_subject | FExpenseItemID | Translate via subject mapping table |
| Payment Date | pay_date | FDate | Standardize to yyyy-MM-dd |
| Remark | remark | FNote | Truncate to target max length |
For fields where encoding systems differ (customer, subject), a common pattern among Qeasy clients is centralized encoding mapping management: a standalone mapping table is maintained so future subject adjustments only touch the table, not the flow. This pattern is universal across material/customer/subject synchronization.
How to Configure in Qeasy
In the Qeasy designer, create a new strategy. There are four typical configuration points:
- Source Fetch: Select the CRM payment order interface. The filter must include the "fee-to-goods-payment" document type — this is what distinguishes this strategy from a generic payment sync.
- Field Mapping: Build mappings per the table above. Customer and subject go through the mapping table; currency and date use built-in conversion functions.
- Target Write: Call Kingdee's fee receivable save interface. Disable Kingdee's auto-numbering for the voucher and pass the CRM document number instead; otherwise downstream reversal and traceability break.
- Status Write-back: On success, write the Kingdee-returned internal ID back to a custom field in the CRM. On failure, write the error code back too, so business users can self-check.
Qeasy's strategy configuration is visual, with field-to-field lines visible at every step, keeping on-site communication overhead low.
Implementation Steps
We typically run in three phases:
- Incremental Baseline: On go-live day, run a SQL view in Kingdee to back-check the most recent 3 months of fee receivables already posted, producing an "already-exists" baseline to prevent historical duplicates.
- Full-Trigger Run: After the baseline completes, run a one-time full backfill, restricted to records without a Kingdee voucher number written back. Manually spot-check 5 entries afterwards.
- Schedule Frequency: Poll every 15 minutes. Fee receivables do not require real-time delivery; over-frequent polling risks Kingdee throttling. 15 minutes is the empirical sweet spot — finance sees yesterday's payments by morning without saturating the interface.
The dual-track of incremental and full is a common pattern Qeasy clients use for business document sync: full backfill at go-live, pure incremental thereafter, partitioned by a "whether-written-back" flag.
Pitfall Recap
- No document-type filter. A typical mistake is syncing "goods-payment" entries too, inflating Kingdee receivables. The safe approach is hardcoding the "fee-to-goods-payment" type in the source filter.
- Kingdee auto-numbering left on. If not disabled, the same CRM voucher number becomes multiple Kingdee vouchers, breaking reconciliation entirely.
- Missing currency. The customer paid in USD but defaulted to RMB; the Kingdee save succeeded but the amount was wrong. Currency must be passed explicitly, never defaulted.
- Unmapped subjects. A new fee category was added but missing from the mapping table, causing the strategy to fail outright. Weekly unmapped-value checks are recommended, and Qeasy has built-in dirty-data alerts — combining both is safer.
- No retry on failure. Kingdee interfaces occasionally time out; without auto-retry, manual monitoring is required. Qeasy defaults to 3 retries, but during the first two go-lives, switch to manual confirmation to avoid dirty data being repeatedly written.
Applicable and Non-Applicable Scenarios
Applicable: when the CRM has a "fee-to-goods-payment" business and fee-type payments must be posted separately as finance receivables, and master data for customers/subjects already exists in both systems. Not applicable: goods-payment itself (that belongs to the sales order flow); clients without Kingdee fee-receivable authority or a subject system in place; or scenarios requiring reversal/red-letter complex reverse flows — this strategy handles forward creation only.