Warehouse Transfer Order Sync in Practice: From Marketing Cloud Transfer-Out to Kingdee Cloud

What This Strategy Solves

A typical retail/distribution enterprise works like this: dealers raise transfer-out orders in the marketing cloud, and once approved the goods physically move. At the same time, the financial and inventory books must be reflected in Kingdee Cloud. With no direct connection between the two, you end up with the awkward situation where "the marketing cloud has the order, but Kingdee has no book entry." We use the Qeasy data integration platform to take over this strategy. The goal is to pull approved transfer-out orders from the marketing cloud by update-time window and write them as transfer orders in Kingdee Cloud, treating the business type as same-price transfer and directly setting the final status to "fully received" to minimize manual entry.

Data Flow and Field Mapping

The data flow is one-way: Marketing Cloud (QUERY) → Qeasy middle layer → Kingdee Cloud (EXECUTE). The source side calls the borrow/transfer-out query API, while the target side calls Kingdee's transfer-order write API. The table below shows the key field mapping:

A few notes worth highlighting: tenantId is a required dealer identifier on the source side and must be sent as a fixed parameter in Qeasy. The source's number is both a query condition and the "traceability ID" written into the remark—lose it and you can no longer trace back to the original document.

How to Configure on Qeasy

In the Qeasy data integration strategy editor, warehouse master-data and transfer-order strategies like this are typically configured in three sections:

1. Source platform: Select the marketing cloud, choose API /erp/api/order/query/borrowOrder, method POST, type QUERY. Fix tenantId as a constant, and build the time window using the built-in platform variables DAYS_AGO_1 and CURRENT_TIME.
2. Middle-layer mapping: In Qeasy's field mapping area, drag source fields such as number, created, and itemList to their corresponding target fields. For enums like trans_type and trans_fer_status, use "constant mapping" rather than pulling from the source—this prevents changes in source semantics from corrupting the target ledger.
3. Target platform: Select Kingdee Cloud V2, choose API /jdy/v2/scm/inv_tfmove, method POST, type EXECUTE. material_entity is an array entry—you must check "entry expansion" in Qeasy, otherwise the item lines will not be written.

At customer sites, we have two patterns we often see clients adopt. First is centralized code mapping management—keep the source product code to Kingdee product code mapping table as a public mapping table in Qeasy. This strategy references it directly, so when the material strategy changes later, the transfer strategy does not need to change. Second is phased header-then-line—get the header working first, then attach the lines. When something breaks, you can quickly tell whether the issue is in the header or the line.

Implementation Steps

Take it in three steps for stability:

• Step 1: Pin down the incremental start point. Before the first full run, pick a clear time point on the marketing cloud side (for example, system go-live date), pin beginTime to it, run a historical full sync, and confirm the document counts and amounts match on both sides.
• Step 2: Configure the schedule. Source crontab is set to */3 8-21 * * * (every 3 minutes during working hours); target EXECUTE is set to */4 8-21 * * *. The target runs one beat slower than the source to give the source buffer time to write. Once the incremental start point is fixed, subsequent beginTime advances with CURRENT_TIME, becoming a rolling 3-minute window.
• Step 3: Full sync and regression. At the start of each month, do a full reconciliation: pull a day's documents from the marketing cloud and compare against Kingdee transfer orders with the same document number to confirm trans_fer_status is correctly set to 3. If you find discrepancies, first stop the target EXECUTE, then investigate whether the source time window is missing orders.

Pitfall Review

• Pitfall 1: Mixing up number and id. The source returns both number (system document number) and id (internal id). Some engineers casually use id as the traceability remark, and later cannot trace back to the original document. The safe approach is to always use number for document traceability.
• Pitfall 2: Entry array not expanded. material_entity is an array. If you forget to check "entry expansion" in Qeasy, the entire transfer order's body is either empty or contains only the first line, and the month-end inventory books will not balance.
• Pitfall 3: Pulling enums from the source. Binding trans_type and trans_fer_status directly to source fields means that one day the source adds a new business-type value, the target will fail in bulk with errors that show up only in production.
• Pitfall 4: Time window drift. If endTime uses CURRENT_TIME but the server time zone is inconsistent, the boundary orders of those few minutes will be missed. The safe approach is to leave 1-2 minutes of slack on endTime.
• Pitfall 5: Dependencies not declared. This transfer order depends on materials, customers, and other master data. If the material strategy is not yet live when the transfer strategy runs, product code parsing will fail. It is recommended to explicitly declare upstream strategies in Qeasy's depends_on.

Applicable and Non-Applicable Scenarios

Applicable: Front-end business systems like the marketing cloud produce transfer/outbound orders that need to land in back-end ERPs like Kingdee Cloud to form inventory books and financial vouchers, and product/customer codes are already mapped across the two sides.

Not applicable: Source transfer-status semantics change frequently, complex transfer chains spanning multiple organizations/books, and scenarios that require strict step-by-step writeback by document state machine (approved → outbound → received) rather than a one-shot "set as fully received."