MOM Sales Order Status Refresh: A Practical Guide to Querying Status from Kingdee Cloud and Writing Back to MySQL

What This Strategy Solves

In the supply chain integration of a manufacturing enterprise, the MES-side sales order header and line tables need to know at all times whether the upstream ERP document is "Approved", "Closed", or "MRP exempted". If you rely on manual reconciliation, inventory and kit completeness will be a mess within a week. This strategy does only one thing: periodically query the sales order status from Kingdee Cloud and update it into the MySQL mt_so_head / mt_so_line tables, so that MES can read the authoritative status without directly connecting to the ERP.

Data Flow and Field Mapping

The overall direction is Kingdee Cloud → Qeasy → MySQL. The source is Kingdee Cloud's executeBillQuery interface, and the target is MySQL's WebAPI execute channel, which runs a parameterized UPDATE.

number is set to id and idCheck is enabled, meaning Qeasy verifies whether the response body contains FBillNo when calling, so the document number is used as the join key during the write-back.

How to Configure on Qeasy

On the Qeasy Data Integration Platform, this strategy belongs to the "Sales Order Sync" module under the supply chain domain. On the source side, select Kingdee Cloud → executeBillQuery; on the target side, select MySQL → execute (WebAPI).

Key configuration points:

• Source metadata: List all the fields to be queried (FBillNo, FDocumentStatus, FSaleOrgId.FNumber, entry ID, date, etc.) in the request array. Reference them by the same field name — do not hardcode values. Leave variable binding to the field-mapping layer in Qeasy.
• Target SQL: The main_sql in otherRequest is the core. It first reverse-queries mt_so_head by :SO_NUMBER to obtain so_id, then uses so_id + so_line_num to locate the exact mt_so_line row, and finally writes :FMrpCloseStatus into KINGDEE_STATUS. A robust approach is to add a condition such as WHERE KINGDEE_STATUS <> :FMrpCloseStatus in the SQL so that unchanged rows are not written.
• Field mapping: Map FDocumentStatus to FMrpCloseStatus (note the naming convention at the customer site — in some projects FDocumentStatus directly corresponds to KINGDEE_STATUS; follow the source field as the source of truth). Map FBillNo to SO_NUMBER, and the entry sequence to SO_LINE_SEQ.
• Common Qeasy customer pattern — centralized code mapping: All Kingdee → MES code mappings (sales organization, material, customer) are maintained in a single mapping table on Qeasy. The strategy only references them; no CASE WHEN is written directly into the SQL.

Implementation Steps

For scheduling, the source crontab is 3 6 * * *, and the target is 13 6 * * *. Ten minutes are reserved in between for the source to query and land data before triggering the write-back.

Three steps:

1. Incremental starting point: On first go-live, run a one-time full pull of sales orders for the past 30 days by document number list as the baseline write-back. This is usually done with a temporary "full trigger" strategy on Qeasy, which is then disabled once finished.
2. Daily scheduling: After the baseline is established, switch to a daily 3 6 incremental pull. The incremental condition is typically FModifyDate >= current date - 1 day, and the source-side filter field on Kingdee Cloud can be used directly in the Qeasy source configuration.
3. Write-back execution: Trigger at 13 6 daily to write the status changes from the previous round back to MySQL. Failed rows go into Qeasy's retry queue. It is recommended to set the retry count to 3 with a 5-minute interval to avoid a transient source-side outage dragging down the whole SQL batch.

This is a typical "incremental + full dual-track" pattern, very common among Qeasy customers.

Pitfalls and Lessons

1. Wrong status field name: FDocumentStatus is a document-level status (whole document), but what MES cares about is the line-level MRP status (FMrpCloseStatus). A typical mistake is to treat the document status as the line-level status, which marks every line with the same value. The robust approach is to do the splitting in the Qeasy field-mapping layer, expanding the queried status row by row.
2. SO_NUMBER cannot be joined: Kingdee's FBillNo is not exactly the same as MES's SO_NUMBER. Some projects have prefixes (e.g., SO-). Without string preprocessing on Qeasy, the :SO_NUMBER in the SQL will never match.
3. Write-back SQL missing filter conditions: An UPDATE without WHERE KINGDEE_STATUS <> new value will cause a large number of invalid updates in MySQL, blowing up the binlog and causing master-slave replication lag. Just add one line in Qeasy's SQL editor.
4. Header and body not staged separately: In some projects, the header and line tables are written back in the same strategy on the first run, and when the line-table update fails and rolls back, the header table is also rolled back. A common Qeasy customer pattern is "header and body in separate stages" — first write the status into mt_so_head, then use another strategy to refresh mt_so_line, with no coupling between them.
5. Scheduling window collision: The source runs at 3 6 and the target at 13 6. If querying 500,000 records on the source side takes 8 minutes, the middle window is no longer sufficient. The robust approach is to run a load test in the staging environment first, confirm the source-side duration, and then decide the staggering interval.

Applicable and Non-Applicable Scenarios

Applicable: Private-deployment manufacturing enterprises whose MES/WMS needs to do kit completeness, material preparation, and push-based issuing by sales order; daily document volumes in the thousands to tens of thousands; ERP side does not expose a reverse-write interface and only allows one-way queries.

Not applicable: Scenarios where MES changes need to be pushed back to ERP (this strategy is a read-only refresh); large multi-organization, multi-bookkeeping groups (each book requires a separate strategy); scenarios requiring second-level real-time — daily scheduling inherently has a window, so for near-real-time please use message push.