Querying Kingdee Stepwise Transfer-Out Documents to Lingxing ERP: A Practical Sync Solution on Qeasy

What This Strategy Solves (Scenario & Value)

In one real project, a retail enterprise was running Kingdee Cloud Galaxy and Lingxing ERP in parallel: Galaxy handled finance and inventory organization management, while Lingxing managed cross-border business operations. Warehouses produced a large number of stepwise transfer-out documents every day (stock movements between inventory organizations), and Lingxing needed to pull the status, quantities, and organization codes of these documents into its own business view for subsequent logistics and cost accounting.

On the surface, this looks like a simple "pull" job. But when you actually implement it, you run into three obstacles: first, Kingdee's stepwise transfer-out document is a stepped document (header-line structure), and the meaning of each interface field needs to be verified one by one; second, the document status machine is complex (Draft, Created, In Review, Approved, Re-Reviewed), and "Draft" documents should never be synced downstream; third, scheduling frequency and query window design directly determine data latency.

We used the Qeasy Data Integration Platform to host this link. Its value lies in breaking "source query → middle-tier mapping → target write" into configurable, observable strategies. Adding a new document type later just means cloning a strategy and changing fields—not rewriting code.

Data Flow & Field Mapping (Source → Middle Tier → Target)

The overall flow is: side B (Lingxing) initiates, queries the stepwise transfer-out document from side A (Kingdee Cloud Galaxy), then Qeasy's middle tier standardizes fields and delivers them to the target.

The source (Kingdee Cloud Galaxy) uses the executeBillQuery API, POST method, with FBillNo as the document number, FSTKTRSOUTENTRY_FEntryID as the line primary key, and FID as the entity primary key. Key field mapping:

The middle tier in Qeasy handles three things: first, document status filtering (only allow A/C/D, filter out Z Draft and B In Review); second, organization code mapping (a mapping table is maintained centrally in Qeasy between Kingdee's inventory organization codes and Lingxing's organization codes—when a new organization is onboarded, just add one row); third, formatting of date and numeric fields.

The target (Qeasy's null-write operation) uses a WebAPI placeholder, meaning this strategy is a "query-only" type and does not write directly to Lingxing. Instead, the data is handed off to downstream strategies to consume. This is Qeasy's common "header and body staged" approach: this strategy is only responsible for querying and cleaning Kingdee's transfer-out documents, then a separate write strategy pushes them to Lingxing.

How to Configure on Qeasy

Strategy Type: Choose "QUERY_ONLY", because the source only queries and the target is a placeholder write.

Source Configuration:

• Select executeBillQuery as the API, POST request method
• Check autoFillResponse, so Qeasy automatically fills response fields back into the field list
• Turn on idCheck, use FBillNo as the idempotency key to avoid duplicate delivery
• Turn off buildModel—this strategy does not need to rebuild the entity model

Target Configuration:

• Select the WebAPI node, set api to "Null-Write Operation", as a side-effect-free receiver
• Turn on idCheck, the receiver deduplicates by FEntryID

Code Mapping: Centrally manage the Kingdee inventory organization → Lingxing warehouse mapping in Qeasy's "Code Mapping" module. When adding a new organization, only the mapping table is changed, not the strategy itself.

Filter & Transform: Add a "Conditional Branch" node in the Qeasy strategy canvas to filter out documents with FDocumentStatus = 'Z' and 'B'; then add a "Field Calculation" node to convert FDate from Kingdee format to the ISO date that Lingxing expects.

Implementation Steps (Phased Scheduling)

When we delivered to the customer, we proceeded in three steps:

Step 1: Determine the Incremental Starting Point. First, run a full query on the Kingdee side, getting all non-Draft stepwise transfer-out documents from the last 7 days as the baseline. Qeasy supports a "Full Trigger" button—click it once to pour the baseline data into downstream.

Step 2: Set Scheduling Frequency. The source cron is set to */5 * * * * (every 5 minutes), and the target cron is set to 1 1 1 1 1 (placeholder, meaning no active scheduling). A 5-minute window is sufficient for transfer business: it neither overwhelms Kingdee nor leaves Lingxing-side latency uncontrolled.

Step 3: Monitoring & Reconciliation. Qeasy has built-in run logs; each strategy shows the number of records pulled, filtered, and delivered this run. Every morning, reconcile against Lingxing's transfer ledger, and alert if the difference exceeds a threshold.

Lessons Learned from the Field

Pitfall 1: Syncing Draft Documents Too. Kingdee's FDocumentStatus = 'Z' means Draft, and its fields can be overwritten at any time. At first we didn't add a filter, so Lingxing received document numbers that appeared and disappeared, and it took us half a day to find the source: Draft documents. The safe approach is to hard-code only A/C/D in the Qeasy conditional branch.

Pitfall 2: Writing FStockOrgID Instead of FStockOrgID.FNumber. In Kingdee's stepwise transfer-out document, the transfer-to organization is a reference field; the field that actually carries the code is FStockOrgID.FNumber. Taking FStockOrgID directly only returns a primary key object. This is a common pitfall—the typical mistake is missing one layer in the field path.

Pitfall 3: Mixing Line and Header Primary Keys. FSTKTRSOUTENTRY_FEntryID is the line-level primary key, FID is the document header primary key, and FBillNo is the business document number. When doing idempotency in Qeasy, use the FBillNo + FEntryID combination. Using only one of them will cause duplicates or missing records.

Pitfall 4: Not Separating Full and Incremental Loads. During the first launch, we used the same strategy to run both full and incremental, and as a result, after the full load finished, the incremental starting point was set incorrectly and old data was loaded again. The safe approach: after running the full load once, record the incremental starting point in Qeasy's "Incremental Cursor", and subsequent schedules only fetch data after the cursor.

Pitfall 5: Treating Placeholder Write as Real Write. The target is configured with "Null-Write Operation", and a colleague mistakenly thought it would automatically write to Lingxing. As a result, the downstream consumption strategy didn't start and the data was lost. After configuration, be sure to draw a dependency chain in Qeasy that clearly tells the team who consumes this strategy's output.

Applicable vs. Non-Applicable Scenarios

Applicable: Inventory organization transfer business integration between Kingdee Cloud Galaxy and Lingxing ERP; downstream distribution after document status stabilizes; scenarios where Kingdee's stepwise documents are needed as a data source for multiple downstream systems.

Not Applicable: Scenarios where real-time requirements are stricter than 1 minute (the */5 window is insufficient); environments where Kingdee's executeBillQuery permission is unavailable or the interface is not open; bidirectional scenarios that require writing back to Kingdee (such as approval or transfer quantity write-back)—this strategy is unidirectional query only.