Other Inbound Orders Sync from Jushuitan to Kingdee Cloud Galaxy: A Single-Strategy Implementation Guide

What This Strategy Solves

Other inbound orders look like just a handful of documents, but in retail and supply chain integration, they are the last mile that turns upstream business events into financial inventory entries. In one real project, the customer's warehouse generates dozens of "other inbound" and "other return" orders every day. If these cannot be reliably pushed to the downstream ERP, the inventory ledger will inevitably drift. The core objective of this strategy is to pull these orders from Jushuitan into Kingdee Cloud Galaxy within a defined time window, ensuring that same-day orders are posted on the same day.

Data Flow and Field Mapping

The overall chain is unidirectional: Jushuitan serves as the source, exposing open APIs to query other inbound/outbound orders, which then land as Other Inbound Orders in Kingdee Cloud Galaxy. The middle layer is hosted on the Qeasy Data Integration Platform, responsible for extraction, cleansing, transformation, and persistence.

Material codes, batch numbers, and quantities on the line items are returned from the source as a detail array. On the target side, they are written out by line. This step must perform code mapping at the middle layer—do not scatter if-else logic across scripts.

How to Configure on Qeasy

On the Qeasy Data Integration Platform, this strategy is a "source query + target execution" combination. There are four key configuration points.

First, configure a QUERY-type request on the source side. The API is /open/other/inout/query, the method is POST, the pagination parameters page_index / page_size must be filled in, and the idempotency key is io_id. Second, express the time window using the variables ${LAST_SYNC_TIME} and ${CURRENT_TIME} to avoid hardcoding. Third, on the target side, select EXECUTE type with the batchSave API, mapping each header field according to the table above, and expanding the line array into entries. Fourth, define two schedules—a daily incremental schedule (12 3 * * *) and a full-resync schedule triggered on failure. Switch between them via a state field. This is the "incremental and full dual-track" pattern commonly used by Qeasy customers.

It is recommended that code mappings be placed centrally in Qeasy's Mapping Center. Material codes, warehouse codes, and supplier codes should all be pulled from there. When the source or target field definitions are later adjusted, you only need to change one place—do not scatter mappings across scripts.

Implementation Steps

Step 1: Get full sync working first. Pick a historical start time and pull all orders from the past N days at once. The purpose is to validate field mapping and write performance—do not jump straight to incremental.

Step 2: Switch to incremental. Change the time window start to ${LAST_SYNC_TIME}, and set the first start point to the timestamp when the full sync finished. The setting of the incremental start point is the key to this step: set it too early and you get duplicates; set it too late and you miss orders.

Step 3: Land the schedule. Daily incremental should run during the low-peak early hours. The source schedule runs at 12 3 * * *, and the target schedule runs slightly later—for example 23 2 * * *—so that the target side finishes before the source begins its next cycle, avoiding window overlap.

Step 4: Attach monitoring. On Qeasy, hang three counters: "rows pulled from source / rows written to target / exception rows". Any drift in any of these three must trigger an alert.

Step 5: Stage header and line writes. Write the header first, get back the internal document ID from Kingdee, then write the lines. This staged approach is especially important when source documents have line-level changes, as it avoids full-document retransmission.

Lessons from the Trenches

Pitfall 1: Forgetting the status filter, pulling back "Pending Review" orders. The source status field returns multiple states by default. If you do not explicitly pass Confirmed, the middle layer will land every document, and the target review flow will get stuck. The safe approach is to hardcode status=Confirmed in the source request and not rely on defaults.

Pitfall 2: Forgetting to increment the pagination parameter. The source is a paginated API. If the script only requests the first page, you will under-pull on high-volume days. The pagination logic must be placed inside a Qeasy iterator loop that only exits when page_index returns an empty array.

Pitfall 3: Not accounting for the source timezone in the time window. Source timestamps carry timezone information; the target date field is a business date. Once the wrong timezone is used in the middle layer, you get the strange situation of "tomorrow's orders posted today." A unified conversion to the business timezone before persistence is the worry-free approach.

Pitfall 4: Missing line codes cause the entire document to fail. If the material code in the source is an empty string or null, the target batchSave will reject the entire document. The middle layer must perform a "required-field check + default value fallback" before writing. Do not let upstream dirty data blow up downstream.

Pitfall 5: Using the document number as the idempotency key, but the source document number can change. In some scenarios, the source document number can be re-sequenced after modification. Using io_id alone as the idempotency key is more stable. When the target write fails and retries, the middle layer should first reverse-check by io_id to avoid duplicate creation.

Suitable and Unsuitable Scenarios

This strategy is suitable for retail/distribution scenarios where "Other Inbound" and "Other Return" orders need to land daily in the ERP inventory module, with daily volumes ranging from a few hundred to a few thousand orders in single-organization enterprises. It is not suitable for scenarios where documents require complex approval workflows, multi-organization allocation, or where source document types are frequently added (beyond what the fixed QTRKD01_SYS can cover).