Syncing Kingdee Receipt Notices to MySQL: Field-Proven Configuration and Pitfalls

What This Strategy Solves

Receipt notices are basic supply-chain documents, yet they are among the most error-prone. Once upstream ERP approves them, downstream warehouses, MES, and BI all need the line details immediately. In one real engagement, a customer's Kingdee Cloud generated several hundred receipt notices a day with approval timestamps scattered throughout the day. Downstream MySQL reporting relied on manual export and re-import, leading to long delays and inconsistent definitions. This strategy pulls by document number incrementally, persists records as soon as approval happens, and keeps MySQL aligned with Kingdee at the same definition.

Data Flow and Field Mapping

The flow is Kingdee Cloud → Qeasy → MySQL. The middle layer only handles routing, mapping, and scheduling — it does not persist business data.

On the source side, call Kingdee's executeBillQuery and pull incrementally by FBillNo. Key fields include line entry ID FDetailEntity_FEntryID, document number FBillNo, document status FDocumentStatus, document type FBillTypeID, business date FDate, plus material code, received quantity, and warehouse.

On the target side, MySQL's batchexecute runs batch SQL with primary key id and idCheck enabled. Fields map one-to-one to the target table:

For code-style fields (document type, material code), maintain a mapping table on Qeasy instead of hard-coding inside scripts.

How to Configure on Qeasy

Open the Qeasy Data Integration Platform, create a new source connection selecting Kingdee Cloud and a target connection selecting MySQL. Create a new strategy of type "form query + write".

Source configuration: pick executeBillQuery, add FBillNo, FDate, FDocumentStatus and other fields to the request body, and restrict FDocumentStatus to "Approved" in the filter so drafts are not pulled in.

Target configuration: batchexecute runs batch SQL with primary key id set to idCheck=true. When the same record arrives again, the system performs an update instead of inserting dirty data.

For scheduling, the source crontab is */8 * * * * and the target is 3-59/8 * * * *. The two timestamps are offset by 3 minutes so the target does not start writing before the source finishes pulling.

Implementation Steps

1. Build the table and align fields: create the target table in MySQL first; keep all columns as strings initially, then tighten types after the pipeline is stable.
2. Set the incremental starting point: run one full sync with a starting FBillNo as the baseline. A common pattern on Qeasy is the dual-track approach — full sync runs once, then everything goes incremental.
3. Configure the strategy: wire source and target per the field mapping above, then trigger one record manually to verify it lands in the database.
4. Go live with scheduling: source pulls every 8 minutes, target writes with a 3-minute offset, observe for 24 hours.
5. Monitor anomalies: turn on "failure retry" and "primary key conflict" alerts on Qeasy and watch manually for the first three days.
6. Roll out header and body in phases: when extending to other documents, ship the header first, stabilize it, then add the body.

Pitfall Retrospective

1. Drafts get pulled in: without filtering on FDocumentStatus, the source returns a flood of unapproved documents and downstream reporting definitions immediately break.
2. idCheck not enabled on the target: when the same receipt is approved twice, MySQL ends up with two rows and the numbers no longer reconcile.
3. Source and target fire at the same time: with both set to */8, they collide and the target table gets a half-batch — only part of a batch inserted. The safe pattern is to offset by 3-5 minutes.
4. Code mapping hard-coded in scripts: in one project the material code changed once on the Kingdee side and it took editing more than a dozen SQL statements to catch up. After switching to a mapping table on Qeasy, one change takes effect everywhere.
5. Custom fields not identified by prefix: Kingdee custom fields start with F_xxx and get mixed up with standard fields. When designing the table, either put them in separate columns or annotate them clearly.

When to Use and When Not to Use

Use it when Kingdee Cloud receipt notices, delivery notes, or receiving documents need real-time or near-real-time persistence into MySQL for reporting or reconciliation. Do not use it when cross-organization or cross-set aggregation is required, or when document volume is very high (over one hundred thousand rows per day) — those scenarios are better served by a data warehouse or message queue.