Query-Only Strategy in Practice: Scheduled Pull of Receipt Notices from Kingdee Cloud

What This Strategy Solves

In supply chain integration, a "query-only" strategy may seem minor, but it is actually a key tool for troubleshooting and reconciliation. In one real project, a retail enterprise's warehouse reported that the receiving quantities in the WMS differed from the actual arrivals by dozens of records. The business side required a daily check of receipt notices on the Kingdee side, but did not want any immediate write-back—they just wanted the data pulled out for comparison. This is where the typical "Query-Only - Kingdee Receipt Notice" strategy comes in: it periodically pulls receipt notices from Kingdee Cloud into the middle layer, without persisting or writing back, acting purely as a "data probe." This strategy is commonly used for pre-launch data discovery, early-stage alignment checks, and investigating upstream/downstream document inconsistencies.

Data Flow and Field Mapping

The data flow is a one-way pull: Kingdee Cloud → middle layer (Qeasy data integration platform) → target empty operation. The source API is Kingdee's /kapi/v2/dtog/im/im_purreceivebill/getList_01, RESTful type, POST method, with effect QUERY. The target is configured as a "write empty operation" (WebAPI, EXECUTE), so that the strategy completes a full chain on the platform without side effects on external systems.

Key field mapping table (desensitized):

Centralized management of encoding mappings is a common practice among Qeasy customers: all Kingdee-to-WMS encodings are placed in a single independent mapping table. Even though this strategy only queries data, when actual write-back is added later, the same mapping table is reused, avoiding scattered hard-coded mappings inside individual strategies.

How to Configure on Qeasy

On the Qeasy data integration platform, create a new strategy with the source system pointing to Kingdee Cloud and the target system pointing to the Qeasy integration platform (empty operation). For the source, select API /kapi/v2/dtog/im/im_purreceivebill/getList_01, effect QUERY, method POST. Set idCheck to true—the platform will use billno for idempotent deduplication, ensuring the same document is not pulled repeatedly even with an empty operation target. Keep autoFillResponse enabled so the platform automatically fills billno and id from the response back into the strategy metadata, making log troubleshooting crystal clear.

Keep the target configuration minimal: set the API to "write empty operation" with empty request/response arrays. This makes the strategy a complete chain on Qeasy. When switching to a real target later, only the target metadata needs to be replaced—the source and middle layer remain untouched.

For scheduling, the source crontab is 0-59/5 7-22 * * *, meaning every 5 minutes from 7:00 to 22:00 daily. The target crontab is 1 1 1 1 1, which looks like it never fires but is actually the platform's placeholder for empty operations—meaning "not actively triggered."

Implementation Steps

Step 1, determine the incremental starting point. Receipt notices are usually pulled incrementally by document number (FBillNo) or document creation time. In the project we use billno as the watermark: after the initial full pull, subsequent runs advance based on the maximum billno.

Step 2, trigger full verification. Adjust pageSize to 10 and manually run once on Qeasy to confirm the response structure matches expectations. After the full run completes, switch back to incremental mode.

Step 3, enable the schedule. Run every 5 minutes from 7:00 to 22:00, no nighttime execution—the business does not receive goods at night, and running then is just idle waste. On Qeasy, the source schedule window can be bound to business hours. A common pattern on customer sites: full runs on weekdays, a single full run on weekends.

Step 4, logs and alerts. Qeasy automatically records the total record count, duration, and exception document numbers for each pull. Customers typically set alerts on "3 consecutive zero-result rounds" and "response time > 10 seconds."

Step 5, follow-up linkage. Once the data stabilizes, replace the target from "empty operation" with a real write-back strategy—the source requires zero changes. The dual-track pattern of incremental plus full loads is especially suitable here: incremental during the day, a full load added in the early morning as a safety net.

Lessons Learned from the Field

First, do not misconfigure the empty operation metadata. Some engineers leave the target API as "please select." The platform will not error, but no acknowledgment appears in the logs, making troubleshooting confusing. The safe approach is to explicitly select "write empty operation."

Second, do not be greedy with pageSize. Under large data volumes, setting pageSize above 100 on the Kingdee API noticeably slows the response. On-site measurements: pageSize=10 averages 1.2 seconds per round; pageSize=50 averages 3.8 seconds.

Third, billno must be idempotent. idCheck=true cannot be omitted—otherwise rerunning the strategy pulls the same document multiple times, and the "probe" becomes a "repeated probe."

Fourth, do not ignore permissions and tenant differences. The Kingdee side is highly sensitive to tenant isolation. The platform instance and tenant code on Qeasy must match Kingdee's authorization scope, or the API will simply return empty data.

Fifth, be cautious with nighttime scheduling windows. If Kingdee has nighttime batch jobs (month-end closing, inventory closing), avoid that window—otherwise the API may suddenly slow down or return 500 mid-pull, causing the entire strategy to fail.

Applicable and Non-Applicable Scenarios

Applicable: pre-launch data discovery, early-stage alignment checks, upstream/downstream document reconciliation, data latency investigation, and interface performance baseline testing. Not applicable: real-time persisting inventory sync, bidirectional write-back business document sync, or scenarios where daily business operations still depend on this strategy after reconciliation completes—those should be upgraded to full data synchronization strategies.