Production Requisition Receipt Echo-Back: A Closed-Loop Sync Pattern from MES to MySQL

What This Strategy Solves (Scenario & Value)

After a production requisition is pushed from MES to ERP, the shop-floor execution result (success flag, message text, requisition number) must flow back to the business side to close the loop. If we only push one way, the WMS or dispatch console never knows whether the requisition actually went through, how much was issued, or what went wrong. This article focuses on the "receipt echo-back" step — writing MES execution results back onto the detail rows of the business database so the task table becomes self-consistent.

Data Flow & Field Mapping

This strategy is the write-back leg of a "bidirectional integration": the source is the MES return interface carried by the Qeasy integration platform (QUERY/POST no-op, trigger-style polling), and the target is a business MySQL detail table (EXECUTE/SQL).

Key field mapping:

Target SQL (simplified): update wms_instock_confirm_task_detail set is_success1=:is_success where uuid=:sourceid.

Configuring It on Qeasy

When delivering this kind of strategy on a customer site, we usually land it in three steps:

1. Source as "request no-op" + QUERY: the platform acts as a "polling puller", grabbing newly generated receipts from MES on a schedule. Setting autoFillResponse=true lets the response structure come out automatically, so field mappings do not need to be hand-copied.
2. Target as a direct SQL against MySQL: skip the document API and use a plain update, with the condition uuid=:sourceid. This "short-link write-back" is far more stable than going through another API layer.
3. Map only the four critical values: sourceid is the locator key, is_sucess lands the status bit, and result_message and 领料单号 are optional — write them to a log table or a redundant column, not all into the main table at once.

Implementation Steps

We recommend a three-phase rollout:

• Phase 1 — Incremental baseline: run the historical receipts once, writing back the backlog of execution results as the baseline.
• Phase 2 — Scheduled polling: set the source crontab to a denser rhythm like */7 * * * *, since receipts are event-driven and can tolerate higher frequency; the target side is just an update and can run even denser (*/2 * * * * is fine).
• Phase 3 — Exception fallback: tag receipts where is_sucess indicates failure and trigger retries or a manual dashboard. A common pattern on Qeasy is to split "success" and "failure" into two branches, with failures routed to a DingTalk or WeCom alert.

Lessons from the Field

1. is_sucess is misspelled and underscored on the source side, and if you carry it over verbatim the downstream SQL has to live with is_sucess too — which is painful to fix later. The safe approach is to do a "field normalization" step inside Qeasy, renaming everything to a consistent is_success. One typo left in place will break every downstream consumer.
2. Do not use the business document number as the locator key — use the UUID or the source-system primary key. MES may reuse a requisition number across different processes, so updating by business number leads to mistaken writes.
3. Do not write the "production order number" from the receipt straight into the main table. It is context-only; landing it there will collide with the later production-order sync strategy. Send it to a log or redundant column instead.
4. Do not set the same crontab frequency on both ends. The source pulls, the target writes — running both at high concurrency simultaneously can deadlock MySQL row locks. Our experience is to keep them asymmetric (source sparse / target dense, or vice versa) so they never march in step.
5. Failure receipts must be observable. If you just update without logging, three months later when the customer asks "why was this requisition never issued", nobody can answer.

When to Use It (and When Not To)

Use it for: closing the task-status loop between MES and ERP when execution results need to land back in the business database, with detail-row write-backs in the sub-million-row range. Avoid it for: scenarios requiring strong transactional consistency and cross-system reconciliation, and complex document echo-backs with very rich fields and heavy business validation — those are a better fit for an API rather than a bare SQL.