Profit Report Standard Fees to Kingdee Receivable Bill: One Strategy for Cross-System Financial Sync

What This Strategy Solves

The hardest part of cross-system financial sync is not data transport — it's inconsistent semantics. In one engagement with a retail enterprise, monthly profit report data from LingXing ERP was pushed into Kingdee Cloud as receivable bills, but mismatched bill types and missing customer/settlement-organization mappings left the month-end reconciliation off by a wide margin.

This strategy converts "Profit Report – Standard Fees" query results into Kingdee "Expense Receivable Bills" under a fixed set of rules, so both sides line up automatically before month-end close. We use the Qeasy Data Integration Platform to host the whole pipeline: query, transform, and execute are split into three segments, and any misconfiguration surfaces immediately in the logs instead of waiting for the finance team to discover it on the last day of the month.

Data Flow and Field Mapping

The pipeline is one-way: LingXing ERP (source) → Qeasy middleware → Kingdee Cloud (target).

The source calls the profit report endpoint /bd/profit/report/open/report/seller/list, scoped to a calendar month — first day to last day of the previous month — with a page size of 200. The target calls Kingdee's batchSave API to write receivable bills.

Key field mapping (excerpt):

The trickiest field is sid: on the LingXing side it is a single ID, but on the Kingdee side it maps to two completely different entities — settlement organization and customer. A common pattern among Qeasy customers is to centralize code mappings in one lookup table, so the source only fetches and the middleware translates uniformly; nothing is hard-coded on either side.

How to Configure on Qeasy

In the Qeasy console, this strategy is split into two data sources plus one integration flow.

Source data source LingXing: pick the QUERY action type, POST method, and enable autoFillResponse so request fields are rendered into the response and you can reference {{postedDateLocale}}, {{storeName}}, {{sid}} directly downstream. Turn on idCheck so Qeasy uses the composed key {{postedDateLocale}}-{{storeName}}-{{sid}} as the idempotency key and avoids duplicate writes.

Target data source Kingdee.Cloud: pick EXECUTE action, also POST method. batchSave is Kingdee's standard batch save API.

In the integration flow you do three things: first, frame startDate and endDate to a calendar month using _function expressions; second, look up sid against the mapping table to resolve both FSETTLEORGID and FCUSTOMERID; third, set FBillTypeID to the fixed value YSD02_SYS (expense receivable bill) — don't try to infer it from the source; the source semantics already dictate it.

Implementation Steps

We recommend a three-phase rollout.

Phase 1: Full-volume dry run. Set crontab to manual trigger, fetch the most recent complete calendar month, generate the receivable bills in a test ledger, and let finance verify four elements: amount, settlement organization, customer, and bill type. Don't move to scheduling until this is signed off.

Phase 2: Incremental schedule. Configure the source crontab as 0 0 6 * * and the target as 1 3 6 * * — source runs 3 hours and 1 minute earlier than the target. This buffer ensures the source side has finished writing the previous month's data before the target side starts pulling; if both fire in the same minute, the target gets an empty payload and the run is wasted.

Phase 3: Monitoring and reconciliation. Configure failure retry and alerts in Qeasy. On the finance side, maintain a reconciliation table that compares the profit report's monthly fee total against the YSD02_SYS bill total on the Kingdee side. A common pattern among Qeasy customers is "incremental plus full-volume dual track": incremental for daily runs, plus an additional full-volume overwrite for the previous month on the 1st of each month as a final safety net.

Lessons Learned

Pitfall 1: Bill type guessed, not chosen. On first configuration, it's tempting to set FBillTypeID to YSD01_SYS (standard receivable bill), but this strategy's semantic is "standard fees", which must land in YSD02_SYS (expense receivable bill). The safe practice is to put the semantics in the strategy name itself and copy them straight into the configuration — don't change on gut feeling.

Pitfall 2: One-to-many mapping for sid overlooked. A single sid from LingXing may map to settlement organization, customer, or even department in Kingdee — three different dimensions. During phased rollout, verify every mapping path; don't assume one-to-one only happens once.

Pitfall 3: Idempotency key left off, duplicates pile up. If idCheck is not enabled, every rerun generates new FBillNo values, and month-end reconciliation reveals a stack of extras. A classic mistake is enabling idCheck in test but forgetting to enable it in production.

Pitfall 4: Crontab time skew. Source 0 0 6 * * versus target 1 3 6 * * looks like a few minutes' gap, but the semantic is "source finishes before target starts". If reversed or fired simultaneously, the target fetches empty data — looks successful, but is actually missing rows.

Pitfall 5: length=200 too small. When profit report volume is high, a single store in a single month may exceed 200 rows. You need to page through offset in a loop; otherwise the last batch at month-end is truncated and reconciliation breaks again.

When to Use and When Not to Use

Use when: the source has a clear report-query API, the target is a standard financial document (receivable / payable / expense bill), and monthly close is the primary driver. Don't use when: real-time per-record writeback is needed (e.g., generating a receivable per order immediately), the source data is streaming rather than batch-queryable, or the target is a custom (non-standard YSD-series) bill type — those scenarios call for a higher-frequency schedule or a custom-bill strategy.