Querying Kingdee Bank Accounts: A Single-Strategy Walkthrough for Vendor Master Data Retrieval

What This Strategy Solves

In supply-chain integration, bank accounts are a classic example of lightweight yet highly sensitive master data. They do not participate in transactional flow, but they are a hard prerequisite for payment vouchers, expense reimbursements, and bank acceptance drafts. A retail customer uses Kingdee Cloud as the financial and supply-chain backbone and OKKI CRM as the sales front end. The sales side needs a clean bank-account list to assist customer reconciliation and payment matching, but does not want to read or write Kingdee's physical tables directly. The purpose of this single strategy can be stated in one sentence: use a lightweight query to pull Kingdee Cloud's bank accounts in read-only mode into the Qeasy data integration platform, so that downstream consumers can fetch them on demand.

Data Flow and Field Mapping

The data flow is unidirectional and read-only: Kingdee Cloud → Qeasy data integration platform. The source side invokes Kingdee's executeBillQuery (POST) to query bank-account records, and the result lands in the Qeasy intermediate database. Downstream systems then read from this intermediate store. Nothing is written back to Kingdee, and nothing is pushed directly to CRM.

Key field mapping:

A common trap here: in the source JSON, the value of FBANKID is written as FCURRENCYID. This is a Kingdee query-API field-alias habit. During configuration, you must split the actual Kingdee response rather than copying the string verbatim.

How to Configure on Qeasy

On the Qeasy data integration platform, this strategy is configured as a two-stage "source strategy + empty-write target". Since the target is the platform itself, target.metadata.api is set to 写入空操作 (write no-op), with type=WebAPI, effect=EXECUTE, and idCheck=true. This effectively sinks the Kingdee query result into a platform intermediate table.

Key configuration of the source strategy:

• API: executeBillQuery, type=QUERY, effect=QUERY, method=POST. Both primary key and ID use FNumber.
• Request fields: select FName, FNumber, and FBANKID to be returned; set is_required to false for all, so a single missing field will not block the entire batch.
• Pagination parameters: use the placeholders {{PAGINATION_PAGE_SIZE}} and {{PAGINATION_START_ROW}} in otherRequest. Qeasy's paginator injects them automatically — this is the standard pattern for Kingdee query APIs.
• Toggles: idCheck=false, buildModel=false, autoFillResponse=false. Keep the raw response for later reconciliation.

The target side does not need a request body; leave the arrays empty.

Implementation Steps

We split this into three phases — the cadence that worked on the retail customer's site:

1. Initial full load: Configure the source crontab as 3 2 * * * to trigger the first full pull during the early-morning low peak, dumping all existing Kingdee bank accounts into the Qeasy intermediate database.
2. Target-side landing: Configure the target crontab as 23 2 * * *, about 20 minutes after the source. This ensures the full-load result is already in the database before the platform-side write runs, avoiding empty executions.
3. Steady-state incremental: After the full load completes, switch to incremental mode — the source side deduplicates by FNumber and only pulls new or changed accounts. The target side keeps running on schedule, overlaying the incremental results onto the intermediate table.

This follows the "incremental and full-load dual track" pattern commonly seen in Qeasy customer projects: the full load handles initialization, the incremental handles steady state, both share the same table and are distinguished by a timestamp field.

Pitfall Retrospective

1. Mixed field aliases: In the source JSON, FBANKID.value is actually FCURRENCYID. Copying it verbatim will mix up the opening bank and the currency. The safe approach is to manually specify the source field name in Qeasy's field mapping rather than trusting the value string.
2. Missing pagination parameters: Kingdee's Limit and StartRow are mandatory; missing either will error out the whole page. It is easy to forget otherRequest on the first go-live. Explicitly add both placeholders to Qeasy's request-body template.
3. All is_required set to true on the source side: Some engineers mark every field as required by habit, so one record missing a currency blocks the entire batch. For basic data such as bank accounts, we recommend false for all non-key fields and let the target side handle tolerance.
4. Scheduling clashes: Source at 02:03 and target at 02:23 look staggered, but during the first full load Kingdee itself may still have other batch jobs running. We recommend at least a 30-minute gap and setting separate alerts for both strategies in Qeasy monitoring.
5. Downstream mistaking the intermediate for the source: The "bank account table" in the intermediate database holds data only — there is no write API. If CRM tries to call it as if it were writable, it will fail. Clearly mark the strategy as "read-only transit" in Qeasy's strategy description and keep CRM-side documentation in sync.

When to Use and When Not to Use

Use when: Kingdee Cloud is the master-data source and multiple downstream systems need to share bank accounts but cannot access Kingdee directly — typical of on-premise deployments. Also suitable as a prerequisite for later "payment voucher sync" and "bank acceptance draft sync".

Do not use when: Real-time (sub-second) lookups are needed. This strategy runs on a batch schedule, with daily granularity at best. If the sales front end requires "open the customer profile and immediately see the account", the CRM side should cache locally rather than rely on this strategy.