MySQL to Kingdee Cloud Skylink: External Supplier Transfer Order Sync Strategy Tutorial
What This Strategy Solves
In one of our actual projects, a retail enterprise keeps inbound confirmation and plan-tracking data in MySQL on the MES/WMS side, while the ERP side runs on Kingdee Cloud Skylink. Both sides touch the "external supplier" line: MySQL holds the detail records of external supplier transfer orders, and these need to be created as corresponding transfer orders in Kingdee as the source for later inbound write-off and financial reconciliation.
The strategy itself is straightforward: pull the qualified external supplier transfer orders from MySQL and write them into Kingdee transfer orders. The hard part is the "external supplier" qualifier. If the filter is too loose, internal suppliers or unrelated business types will be mixed in, and within three months the books on both sides will not reconcile.
Data Flow and Field Mapping
The data flow is one-way: MySQL → Qeasy Data Integration Platform → Kingdee Cloud Skylink.
The source side (MySQL) uses a direct SQL query to fetch records that match external suppliers, specific task/output types, and the success flag conditions. The target side (Kingdee) uses batchSave to persist these records as transfer orders in bulk.
Key field mapping (compiled from the source material, desensitized):
| Business Meaning | MySQL Source Field (Example) | Kingdee Target Field | Notes |
|---|---|---|---|
| Document Number | CONCAT(d.confrim_no,'_',CAST(c.id AS CHAR)) | FBillNo | Concatenated on source side |
| Date | c.create_time processed | Business date field | Source uses config-table-based dynamic logic |
| Plan Tracking No. | b.mode_no | Plan tracking no. | For tracing |
| Material No. | b.part_no | Material code | |
| Quantity | c.confirm_numb | Quantity | |
| Purchase Order No. | b.business_no | Purchase order no. | |
| Barcode | b.ser_code | Barcode | |
| Supplier | b.supplier_uuid | Supplier | Key filter for external suppliers |
| Source ID | c.id | Custom field | Used for idempotency and write-back |
| Supply Org | m.delivery_org | Supply org | Aligned with target org codes |
| Document Type | Config item | FBillTypeID=ZJDB01_SYS | Transfer order type |
| Transfer Direction | Config item | FTransferDirect=GENERAL | |
| Transfer Type | Config item | FTransferBizType=OverOrgTransfer | Cross-org transfer |
| Business Type | Config item | FBizType=NORMAL |
Encoding mapping is typically centralized in Qeasy as "mapping tables + scripts": source supplier_uuid, org codes, and material numbers must be mapped in the middle layer, otherwise the target side will reject with "supplier/org not found".
How to Configure on Qeasy
Source-side configuration: choose API type select/SQL, method SQL, paste the main query into main_sql, and pass main_params with limit/offset for pagination. Keep the :created_at-style placeholders consistent with the main parameter field names. Parameterized pagination is the safe approach.
Target-side configuration: choose API type batchSave, method POST, and map Kingdee's standard transfer fields (FBillNo, FBillTypeID, FBizType, FTransferDirect, FTransferBizType, FSaleOrgId, etc.) one by one. idCheck=true enables idempotency by document number, avoiding duplicate creation.
For scheduling, the source uses */5 * * * * and the target uses */2 * * * *, which is the default in the material. The source runs every five minutes while the target runs every two minutes, forming a "read slow, write fast" rhythm so the target can drain its backlog within the window.
Implementation Steps
Step 1, configure the incremental starting point: on the MySQL side, use the watermark from sys_config (e.g., the field pointed to by config_id) as the start time to avoid replaying all historical external supplier transfer orders. For the first run, take only the most recent N days of data and verify the path.
Step 2, trigger the full sync: once the path is verified, widen the window or run a one-time full sync to backfill historical external supplier orders. Note: full sync should be scheduled during off-peak business hours.
Step 3, set scheduling frequency: source every 5 minutes, target every 2 minutes. In Qeasy the two schedules are configured independently, with data backlog bridging them automatically. If the target keeps falling behind, temporarily tighten the target to every 1 minute.
Step 4, write-back and idempotency: after the target creates a document, write the Kingdee document number back to the corresponding success flag on the source record. The is_success condition in the source SQL will then automatically exclude that record, achieving "process once, never again".
Field-Tested Lessons
Pitfall 1: missing the external supplier filter, e.g., is_inner=1. The source SQL in the material explicitly contains e.is_inner=1, meaning only external suppliers. Drop this and internal supplier transfer orders will also be pushed to Kingdee; the target will reject them on org/supplier validation, and once dirty data is in, cleanup is painful.
Pitfall 2: supply org mismatch. Hard-coded values like m.delivery_org='T01.01' in the source SQL will cause the target to reject the records if the org does not exist on the Kingdee side. The safer pattern is to manage the supply org through a config table instead of hard-coding it in the SQL.
Pitfall 3: success flag not written back, causing duplicate creation. A condition combo such as c.is_success5<>'1' and c.is_success4='1' is a natural idempotency switch, but only if the target updates is_success5 after success. If the write-back chain breaks, the 5-minute schedule will keep pushing the same record, and Kingdee will either error out or duplicate.
Pitfall 4: pagination parameters not passed. limit :limit offset :offset must be paired with the main parameters, otherwise the SQL pulls the entire table at once and OOMs on hundreds of thousands of rows. Keep the page size reasonable.
Pitfall 5: wrong FBillTypeID. The material uses ZJDB01_SYS, which is the specific document type code for transfer orders in Kingdee. Get this wrong (e.g., as a purchase order type) and the entire batch will be rejected by the target.
When It Fits and When It Does Not
Fits: MySQL is the front-end business system (MES/WMS/OMS), Kingdee Cloud Skylink is the ERP master. External supplier transfer orders need to be stably synced by org and time window, with a clear write-back condition providing idempotency.
Does not fit: scenarios with complex business rules requiring manual approval workflows (Qeasy sync strategies are best for system-to-system data movement); or cases where the source data is meant to be created manually in ERP, where hard sync only adds reconciliation cost.