Kingdee Cloud Purchase Order Delivery Reply Backwrite to MES: A Single-Strategy Deep Dive Tutorial

What This Strategy Solves

In a manufacturing setting, once a buyer places a purchase order in Kingdee Cloud and the supplier fills in the reply date, the MES side must see it almost immediately—otherwise scheduling, kit checks, and inbound planning stall. This strategy does only one thing: query Kingdee Cloud by bill number, pull the lines, and back-write the "sales reply delivery date" and the "second sales reply delivery date" into the MES purchase order line table. It sounds trivial, but delivery-date back-writes are often the "last mile" of supply chain digitization.

Data Flow and Field Mapping

Direction: Kingdee Cloud (source) → Qeasy Integration Platform (orchestration and mapping layer) → MySQL MES database (target).

Source fields (Kingdee Cloud executeBillQuery):

Target SQL (MySQL WebAPI execute):

update ty_mes.mt_po_line
set REPLY_DELIVERY_DATE=:REPLY_DELIVERY_DATE,
    REPLY_DELIVERY_DATE2=:REPLY_DELIVERY_DATE2
where KINGDEE_ENTRYID=:KINGDEE_ENTRYID

Mapping table:

How to Configure It in Qeasy

In the Qeasy platform, this strategy takes the form of a "source Query + target Execute" combo. These are the configuration points I usually lock down:

• Source API: Kingdee Cloud executeBillQuery, POST, with FBillNo as the request filter and FPOOrderEntry_FEntryID as the row locator. Set Limit to 5000 so the server does not silently truncate a large bill.
• Target API: MySQL WebAPI execute, using the main_sql template. Pass :REPLY_DELIVERY_DATE, :REPLY_DELIVERY_DATE2, and :KINGDEE_ENTRYID as bound parameters from the source payload.
• Code mapping: The line ID on the Kingdee side is an internal key. I typically maintain a central "Kingdee EntryID ↔ MES row" mapping in Qeasy, so every strategy does not have to rewrite the SQL.
• Response handling: Keep autoFillResponse on for the source; the target is an UPDATE, so an empty response is expected.

Implementation Steps

A staged schedule, recommended rollout:

1. Initial full backfill: Drive it with a historical bill-number list and pull the last three months of purchase order delivery dates in one pass, so MES has a baseline before scheduling goes live.
2. Incremental start: From the current system time forward, process only newly created or changed lines. Constrain by FBillNo on the source Query for each scan.
3. Schedule cadence: Source runs at 8,18,28,38,48,58 * * * * (every 10 minutes, offset at minute 8); target runs at 9,19,29,39,49,59 * * * * (1 minute after source). The offset on the minute is intentional—it lets the source land first and the target catch up, removing transient contention.
4. Monitoring and reconciliation: Watch failed rows in the Qeasy run log. Rows where the UPDATE affects 0 records almost always mean KINGDEE_ENTRYID did not match—which leads us straight into the next section.

Lessons Learned from the Field

1. EntryID drift is the most common failure. A typical mistake is treating FEntryID as a business key and writing it directly into the target. It does not align on the MES side. The safe pattern: maintain a dedicated ID mapping table in Qeasy; use the source FPOOrderEntry_FEntryID only as a lookup, never as a business key.
2. Empty values wipe out existing dates. If the source returns an empty string rather than NULL for an unfilled date, the UPDATE clears whatever was already there. Add a guard like WHERE (:REPLY_DELIVERY_DATE IS NOT NULL AND :REPLY_DELIVERY_DATE <> '') to the target SQL, or fall back in the mapping layer.
3. Schedule collisions at the minute mark. When both source and target run on a wildcard minute, large documents make them race on the same rows, and the target UPDATE is overwritten by the source's prior read. Shifting the target one minute later eliminated the issue in our case.
4. Silent truncation by Limit. Kingdee silently cuts off responses above 5000 rows. The job looks healthy while missing data. The safe move is to enable the pager in Qeasy explicitly, or slice by FBillNo across multiple pulls.
5. Second reply date gets ignored. Many projects go live only to discover that F_ReplyDeliveryDate2BySale was never mapped, because test data only filled in the first reply. Include both fields in the test plan from day one.

Where It Applies and Where It Does Not

Applies: Manufacturing projects where both Kingdee Cloud and MES need line-level delivery dates on purchase orders, where supplier replies must be back-written quickly, and where a stable KINGDEE_ENTRYID mapping already exists. Does not apply: Source delivery-date fields renamed after an upgrade, target tables without a KINGDEE_ENTRYID-style stable locator, or any scenario that needs the entire purchase order synchronized—including header approval flow and payment terms. That is a different level of integration entirely.