Authoritative Tutorial: Kingdee Cloud Production Order Query (PRD_MO) Field Handbook

What Problem Does This Interface Solve

In real-world MySQL ↔ Kingdee Cloud integration scenarios, the production order (also called manufacturing order / work order) is the critical bridge between sales orders and shop-floor execution. We often encounter this requirement: pulling production orders from Kingdee into MySQL for production planning, progress tracking, sales-to-production traceability, shop-floor task dispatch, and completion monitoring. This interface does exactly that—incrementally pulling by approval date into the MySQL table order_production, supporting downstream MES dashboards and BI analytics.

Interface Capability Overview

• Authentication: Uses Kingdee Cloud's WebAPI system, invoked via executeBillQuery. Authorization is carried in request headers (in Qeasy Cloud, this is encapsulated as connector credentials—no manual writing needed).
• Request Structure: Core parameters are FormId (fixed PRD_MO), FilterString (filter conditions), FieldKeys (field set), and Limit/StartRow (pagination).
• Response Structure: JSON containing Result (business status code), Message, and Data (paginated result set). Data is returned as a tree structure: one header + multiple line entries.
• Pagination Mode: Looping through pages using Limit + StartRow; TopRowCount is used to retrieve the total row count in advance.
• Incremental Mode: A typical FilterString is LEFT(FMaterialId.FNumber, 1) = '1' and FApproveDate >= '{{DAYS_AGO_1|datetime}}' and FSaleOrderNo <> '', i.e., material code starting with '1', approved within the last 1 day, and source order number is not empty.
• Execution Cadence: Across multiple customer projects, a common cron pattern is */15 7-22 * * *, running every 15 minutes from 7 AM to 10 PM daily.

Typical Field Mapping

FStatus Business Status Mapping: 1 Planned / 2 Plan Confirmed / 3 Released / 4 Started / 5 Completed / 6 Closed / 7 Settled.

How to Configure on Qeasy Cloud

In the Qeasy Cloud data integration platform, the production order query is typically handled in two steps using the "Kingdee Cloud Adapter + Field Mapper":

1. Adapter Selection: For the source, choose "Kingdee Cloud - Execute Query (executeBillQuery)", set FormId to PRD_MO, and pull credentials from the connector to avoid hardcoding.
2. Filter Conditions: In Qeasy Cloud's FilterString editor, use the visual builder to compose the filter expression above. The DAYS_AGO_1 variable is automatically populated by Qeasy Cloud's relative time operator—no manual date calculation needed.
3. Field Mapper: Qeasy Cloud's field mapper automatically recognizes Kingdee fields with hierarchical _ structures (e.g., FID/FBillNo/FTreeEntity_FEntryId) and flattens them on the target side (e.g., order_id, order_no, line_id). Extension fields like F_QOQG_* keep their original names; you can add custom conversion functions in the mapper, e.g., mapping F_QOQG_Base to custom_base_name.
4. Target Write: For the target MySQL table order_production, recommend using a composite unique key (fid, fentryid). Qeasy Cloud automatically applies upsert semantics to prevent duplicates.

Cross-Project Practical Points

1. The Filter Triple is Standard: Across multiple customer Kingdee integration projects, production order queries almost always use the combination LEFT(material_code,1)='1' AND approval_date >= last_1_day AND source_order_no<>'' to avoid pulling planning documents and drafts.
2. FID vs FBillNo as Primary Key: FID is the most stable Kingdee PK; FBillNo is the business number and may change (when modified, the number may stay the same but version changes). When writing to MySQL, recommend FID as PK and FBillNo as a unique index.
3. Line Entries are Tree-Structured: Returned data has a tree structure with one header and multiple entries. In Qeasy Cloud's field mapper, flatten them into rows—each entry corresponds to one MySQL row. Don't stuff entries into JSON columns; downstream BI tools can't aggregate over them.
4. FQty is String: Kingdee returns quantity fields as strings. Convert to decimal before writing to MySQL; otherwise aggregation will hit string concatenation pitfalls.
5. Incremental Cursor on Approval Date: Use FApproveDate instead of FCreateDate as the incremental cursor. This stably captures approved documents and avoids mid-state records.
6. Extension Fields Have Customer Prefixes: F_QOQG_* prefixed fields are customer-specific custom extensions. Preserve the prefix or apply semantic renaming in the mapper—don't drop them.

Pitfall Retrospective

• Pitfall 1: Confusing FApproveDate and FAPPROVEDATE. The metadata labels FAPPROVEDATE as "approver" but it's actually a duplicate field name. The real approval time is FApproveDate. Using the wrong field for filtering/increment causes data loss.
• Pitfall 2: FQty Type Trap. Kingdee returns string. Writing directly to a MySQL INT column can cause scientific notation or precision loss. The safe approach is CAST(FQty AS DECIMAL(18,4)) in the mapper.
• Pitfall 3: Writing Tree Structure Without Flattening. Some customers shortcut by stuffing entries into a MySQL JSON column. Later, production progress dashboards can't aggregate by material and require a rewrite.
• Pitfall 4: Incremental Window Too Small. A 1-day window can miss records during network jitter or Kingdee performance issues. The safe approach is to widen the window to 2-3 days + use FID for idempotent deduplication.
• Pitfall 5: Ignoring Extension Fields. F_QOQG_* carries key business meaning in some customer projects (e.g., custom priority). Qeasy Cloud preserves them by default, but manual configuration often misses the checkbox, leading to reconciliation failures.

When to Use

This interface applies to "MySQL ↔ Kingdee Cloud" integration scenarios requiring production order sync for scheduling, progress tracking, and sales-production linkage. If you only need operation-level or process-level data, use "Operation Plan Query" instead. If you only need material inventory, use "Instant Inventory Query". When production order volume is small (under ~100/day) with no custom extension fields, you can use Kingdee's native API directly without Qeasy Cloud.