Real-Time Inventory Status Conversion Sync: From MySQL to Kingdee Cloud Cosmos — In-Warehouse Inspection Strategy

What This Strategy Solves

On the shop floor of a manufacturing enterprise, MES produces a large volume of inventory status conversion events every day — for example, transferring items from the "inspection" location to the "qualified" location, or moving defectives into the "quarantine" location. In Kingdee Cloud Cosmos, these actions correspond to an Inventory Status Conversion document.

If operators create these documents manually in Kingdee, a few hundred entries per day is slow and error-prone. If MES connects directly to Kingdee's API, the two systems become tightly coupled and tend to blame each other when things break. We use the Qeasy data integration platform as the middle layer: whatever the MySQL interface table produces, the platform pushes through, and Kingdee only needs to receive the documents. This article dissects that single strategy end to end.

Data Flow and Field Mapping

Overall flow: MySQL interface table → Qeasy middle layer → Kingdee Cloud Cosmos batchSave. The source is a typical interface staging table; the target is Kingdee's inventory status conversion document.

Key field mapping (source → target):

Business meaning	MySQL source field	Kingdee target field	Notes
Source primary key	iface_id	—	Used only for idempotent dedup
Document number	Concatenated `MKCZHD+date+batch_id`	FBillNo	Generated at source; idCheck=true at target
Document date	aft_quiet_time after period comparison	FDate	Watch the period close point
Document type	instruction_doc_type	FBillTypeID	Code mapping required
Business type	Fixed '0'	FBizType	Dictionary item
Inventory org	inventory_org	FStockOrgId	Code mapping
Owner type	consignor_type	FOwnerTypeIdHead	Dictionary item
Owner	consignor_org	FOwnerIdHead	Code mapping
Line number	line_num	FEntity_FEntryId	Row number
Convert type	convert_type	FConvertType	Dictionary item
Material code	material_code	FMaterialId	Code mapping
UoM	uom_code	FUnitId	Code mapping
Convert qty	convert_qty	FQty	Numeric
Warehouse	warehouse_code	FStockId	Code mapping
Inventory status	inventory_status	FInventoryStatus	Code mapping

The header and line items come from the same table at the source, distinguished by line_num. On the Kingdee side, the header and body must be split into separate fields — this is the canonical "header/body staged processing" scenario for Qeasy.

How to Configure on Qeasy

The source uses the WebAPI select type, with a dynamic paginated SQL that contains :limit and :offset. The platform fetches page by page and stops automatically once paging is exhausted. main_params binds limit and offset to avoid string-concatenation injection.

The target uses Kingdee's batchSave with idCheck=true, meaning Kingdee will dedup by FBillNo — which lines up with the source's MKCZHD+date+batch_id, so resumable sync will not create duplicates.

Centralized code mapping management is the most common pattern we recommend: keep all codes for inventory org, material, UoM, warehouse, and inventory status in a single mapping table. When source codes change, you only update one place instead of touching every strategy. This is the least error-prone approach.

Implementation Steps

Set the incremental starting point. Before the first go-live, pull a batch of historical data from the MySQL interface table with status in ('N','E') and mark a creation_date baseline. After go-live, the platform advances incrementally by primary key iface_id; successfully pushed rows are flipped to 'S'; failed rows stay 'E' for the next retry.
Trigger a full sync. Run a one-time full sync on the initialization day to clear the backlog of N and E rows.
Scheduling frequency. The source cron is 3,13,23,33,43,50 * * * * — every 10 minutes plus extra runs near the top of each hour — balancing timeliness and avoiding the on-the-hour spike. The Kingdee target side uses */1 * * * *, polling the platform's transit queue every minute, achieving "batched at the source, second-level intake at the target."
Failure retry. The platform retries 5xx and network timeouts with backoff by default. Business validation failures (such as missing codes) go to the dead-letter queue for manual handling.
Period close handling. The document date is guarded by aft_quiet_time to avoid pushing documents into a closed accounting period.

Pitfalls and Lessons Learned

Don't let Kingdee generate the document number. The source already concatenates MKCZHD+date+batch_id. If Kingdee generates its own, the two sides drift apart and reconciliation breaks. The safe pattern is: source generates, target dedups via idCheck.
Never hardcode inventory status codes. Codes for "qualified", "inspection", "quarantine" can differ across orgs. Maintain them in a centralized mapping table — do not scatter them across individual strategies.
Line numbers must be passed. Kingdee's conversion document body requires the line number as an idempotency key. Omitting it causes the whole document to be treated as new and inserted again.
Do not ignore the period close point. Using creation_date directly as the document date can push entries into a closed period at month end, and Kingdee rejects them. aft_quiet_time is the key safeguard.
Paging overflow must be handled gracefully. With :limit :offset paging, an empty result on the last page is normal — do not treat it as a failure and retry, or you will flood the queue.

When It Fits and When It Doesn't

Fits: high-frequency sync of inventory status conversion, transfer, and adjustment documents from MES/ERP into Kingdee Cloud Cosmos, with daily volumes from a few hundred to tens of thousands.

Doesn't fit: complex conversions across orgs with multiple owners and approval workflows; or scenarios where the source interface table itself has poor data quality with frequently missing fields. In the latter case, fix the source first — otherwise the platform just moves dirty data into Kingdee faster.