Inventory Transfer Receipt Sync in Practice: Closing the Loop from Kingdee Cloud Cosmos to MySQL

What this strategy solves (scenario and value)

In one of our real projects, the customer rolled out a transfer link between MES and ERP: an interface table in MySQL initiates a direct transfer order and pushes it to the ERP for execution. But after the ERP finishes, the processing result—success or failure, the document number, and the error message—has to flow back into that MySQL interface table; otherwise the MES side will never know whether the transfer actually landed, and the inventory ledger will gradually drift out of sync.

This "receipt sync" strategy does exactly that. It is not a standalone business flow but the "closing segment" of the entire transfer link, dedicated to writing the ERP-side execution result back to the MySQL interface table. In the private-deployment environment of a manufacturing customer we worked with, it was precisely this strategy that turned the transfer link from one-way push into a fully traceable, end-to-end process.

Data flow and field mapping (source → middleware → target)

The data flow is: Kingdee Cloud Cosmos (queried through the Qeasy data integration platform as the middleware layer) → MySQL interface table.

The middleware (轻易云集成平台 / Qeasy) acts as a "request no-op" query trigger—it does not itself query the ERP, but serves as a scheduling container, periodically pulling the most recent batch of processed transfer receipts from Kingdee Cloud Cosmos. The response fields are as follows:

The UPDATE SQL on the MySQL target side is a single statement that writes the above fields back to the interface table:

How to configure it on Qeasy (轻易云)

Step 1: register two platform connections in Qeasy—one pointing to the Kingdee Cloud Cosmos private environment, the other pointing to the MySQL interface database. Connection strings and credentials are centrally maintained in Qeasy's connection management, not scattered across scripts.

Step 2: create a new strategy. Pick "Qeasy integration platform + WebAPI (QUERY)" as the source and "MySQL + SQL (EXECUTE)" as the target, under the business module "Inventory Sync". The source API's effect is set to QUERY (read-only); the target's effect is set to EXECUTE (run the UPDATE).

Step 3: configure field mapping. The middleware response fields map one-to-one to the SQL bound variables. The critical point is that :sourceid must be used as the unique match key in the where clause; otherwise you will run into "batched-update collision" incidents.

Step 4: handle the response. Set autoFillResponse to true on the source side so the request body can be empty and Qeasy automatically fills it with the context passed from the upstream strategy—saving you from writing the input for every record.

Step 5: error tolerance. The is_sucess field name is a legacy spelling issue. Do not try to "correct" it inside the strategy—just map it through. Renaming the field would break alignment with historical logs.

Implementation steps

Incremental starting point: start from records in the MySQL interface table whose status is empty or marked "pending receipt". When Qeasy pulls data, it goes in ascending order of sourceid so that receipts within the same batch are written back in their original initiation order, avoiding the chaos caused by later-initiated records receiving receipts earlier.

Full-volume trigger: during initial go-live or after a link failure recovery, a one-time full compensation run is needed. Temporarily change the crontab to */1 * * * * to pull every minute, then restore it to */7 * * * * after completion—this is the "emergency cadence" we often agree on with customers on site.

Scheduling frequency: in normal operation, the source strategy crontab is */7 * * * *, and the target strategy crontab is */1 * * * *. The source polls every 7 minutes because transfer execution on the ERP side has its own latency, and polling too often only returns large numbers of "processing" states; the target polls every minute to write accumulated receipts back as quickly as possible and shorten the perception delay on the MES side.

Phased scheduling: in the first week after go-live, both source and target strategies run at */1 for monitoring; from the second week the source switches to */7 while the target stays at */1; once stable, both run at their designated frequencies. This "tight-then-loose" cadence is very common among Qeasy (轻易云) customers in supply-chain integration projects.

Pitfalls recap

Pitfall 1: configuring the receipt strategy like a forward sync. This is the easiest place to crash. The receipt strategy is essentially "pull ERP results and write back to MySQL"—not "push MySQL to ERP". If the effect direction is wrong, both sides end up waiting for the other to write data, resulting in a deadlock.

Pitfall 2: ignoring the is_sucess spelling. The source field name is a legacy artifact. Renaming it forces historical logs and reconciliation scripts to follow. The safe approach is to leave the field name alone in the strategy layer and only document it.

Pitfall 3: omitting sourceid from the where clause. If the SQL is missing :sourceid, the entire interface table gets bulk-updated and every record ends up with "the same receipt". Once this kind of incident happens, recovery cost is extremely high and you can only fish the data back from a backup.

Pitfall 4: one-size-fits-all scheduling frequency. Using the same crontab for both source and target causes receipt backlogs or a flood of useless polls. The source can be slow, but the target must be fast—this is the standard pattern for closed-loop strategies like this.

Pitfall 5: autoFillResponse used in the wrong scenario. autoFillResponse only applies when "this strategy does not query on its own and is driven by upstream context". If this strategy needs to query the ERP independently, this switch must be turned off; otherwise the empty request body will keep pulling empty result sets.

Applicable and non-applicable scenarios

Applicable: when there is a three-stage "initiate → execute → receipt" document link (transfer / production / sales) between ERP and MES / WMS, and the receipt information must be written back to the initiator's interface table to form a business closed loop.

Not applicable: when the receipt only needs to be notified but not persisted; or when the ERP side already has an active push mechanism (callback interface), in which case additional polling would cause duplicate receipts; and when the receipt fields differ significantly from the initiator's interface table structure and require complex transformations—in such cases an event-streaming approach is more suitable than a single receipt strategy.