Sales Outbound Sync in Practice: Query Strategy from WMS to Kingdee Cloud

What This Strategy Solves (Scenario and Value)

Sales outbound orders are the kind of document that "look simple, fail in practice" in supply chain integration. The source system (order/WMS side) keeps producing outbound flows, and the target system (Kingdee Cloud) needs these flows as the source documents for supply chain accounting and receivables. Once the query filter is wrong, fields are mapped incompletely, or the incremental start point is off, the numbers between finance and warehouse diverge over time. This tutorial focuses on one specific "sales outbound order query" strategy and explains how to make it run reliably.

Data Flow and Field Mapping (Source → Middle Layer → Target)

The overall flow is: source system (order/WMS front end, here represented by WMS) → Qeasy Data Integration Platform (middle layer) → target system (Kingdee Cloud). The source side pulls outbound orders via a query interface using a time window and document status, and Qeasy handles ingestion, transformation, and writing.

Key field mapping (only the most error-prone ones, full fields are defined in the Qeasy metadata):

A few points worth emphasizing:

1. Document type on Kingdee is not a single value but a set of code constants (standard sales outbound XSCKD01_SYS, consignment XSCKD02_SYS, retail XSCKD03_SYS, VMI XSCKD05_SYS, B2C XSCKD07_SYS, etc.). These constants should be maintained centrally in Qeasy rather than scattered across strategies.
2. FEntity_FENTRYID (entry ID) and FBillNo (document number) are two semantically different fields. The former is for idempotent deduplication, the latter for business tracing. Do not mix them.
3. Organization/master-data fields like sales org, inventory org, customer, and item on Kingdee are reference fields with _FNumber suffix; the values are codes, not names.

How to Configure It in Qeasy

This strategy has a typical shape in Qeasy: the source side is a QUERY-type source strategy (the target side is a "write no-op" placeholder because the actual write is handled by a companion write strategy—this is the common pattern of separating query and write strategies on Qeasy).

Configuration points:

• Source metadata: choose api executeBillQuery, method POST, effect set to QUERY, enable buildModel so the platform builds the response structure automatically, and enable autoFillResponse so response fields are automatically filled back into metadata, reducing modeling effort.
• Dedup key: bind id to FEntity_FENTRYID and enable idCheck, so the platform performs idempotency based on the entry ID.
• Time window field: declare FDate explicitly as a date field, which will be used for subsequent incremental scheduling.
• Document number field: bind number to FBillNo for logs and business tracing.
• Target metadata: use the write no-op WebAPI placeholder here (POST, EXECUTE), which does not perform actual writing but only carries the query result flow.

In real projects, when we do this with Qeasy, we usually name such "query-only" strategies with a *-query-* prefix, paired with the actual write strategy, so during troubleshooting it is easy to tell whether the issue is in the query side or the write side.

Implementation Steps (Phased Scheduling)

We usually schedule sales outbound sync in three phases rather than starting with a full sync:

Step 1: Decide the incremental start point. On first go-live, do not directly use the current time as the incremental start. The safe approach is to pick a clear historical date (e.g., the start of the month) as the start of FDate, pull all data for that day in full, confirm field mapping is correct, and then switch to incremental.

Step 2: Switch to incremental trigger. The source strategy cron here is */10 * * * *, meaning every 10 minutes. For sales outbound documents that are "shipped and final, cannot be changed back", 10 minutes is a stable window—neither missing documents nor pressuring the source system too much. If the source system is under pressure, extend it to 30 minutes.

Step 3: Full-volume backstop. The Qeasy platform-side cron is 1 1 1 1 1 (placeholder). In actual production, we let the companion write strategy trigger a full-volume verification during business off-peak (e.g., 3 AM) to recover data missed by the incremental run. This is the typical "incremental + full dual-track" approach, and it is a very common response pattern among Qeasy customers.

In terms of rollout order, first get the "standard sales outbound" type working, then sequentially release VMI, B2C, consignment, and other types; stabilize the header first before opening the body. This is the "header and body phased" pattern.

Pitfall Review

1. Document type codes scattered across strategies. A typical mistake is hard-coding constants like XSCKD01_SYS in every strategy. The safe approach is to maintain a document type mapping table in Qeasy, referenced by all sales outbound strategies, so that when Kingdee upgrades and renames anything, only one place needs to change.
2. Using FBillNo as the idempotency key. FBillNo can be modified via unapprove in some business scenarios; using the document number as the idempotency key leads to "same number, two different contents" dirty records. The entry ID FEntity_FENTRYID is the stable idempotency key.
3. Setting the incremental start point to "current time minus N minutes". This will miss outbound documents that have not been fully generated at the moment of go-live. The safe approach is to back the start point up by 15~30 minutes—better to pull a bit more and then deduplicate via idempotency than to miss data.
4. Multi-org without sales organization/inventory organization. Kingdee Cloud is a typical multi-org architecture; missing the organization field will directly trigger "organization is empty" errors. Whichever organization the source belongs to, write it explicitly to the target—do not rely on defaults.
5. Coupling query and write strategies together. Once query and write are merged into one strategy, when something goes wrong it is impossible to tell whether the issue is in data pulling or data writing. The mature approach on Qeasy is to keep query and write separate, and locate the issue quickly by strategy name during troubleshooting.

When to Use and When Not to Use

Use when: the source side has a standard query interface and can pull outbound orders by FDate, the target side is Kingdee Cloud, and document type codes are confirmed in a multi-org project. Do not use when: the source side can only push but not be queried (in that case, switch to a push/subscription pattern), or documents need to be unapproved and modified frequently on both sides (query-type sync is naturally not suitable for such bidirectional modification scenarios).