Supplier Un-Disable Status Sync: Kingdee Cloud → MySQL Status Writeback Strategy

What This Strategy Solves

In one retail company, suppliers are managed as master data in Kingdee Cloud. Finance or procurement may disable a supplier on the Kingdee side, but the downstream ordering system (MySQL) has no idea and keeps treating the supplier as active, causing chaos in reconciliation, settlement, and payments. This 'upstream changed, downstream blind' split is the classic reverse status sync scenario in supply chain integration. What we do in Qeasy (the data integration platform by QingYiYun) is configure an independent 'un-disable status update' strategy that only writes back the status field, never touching other master data columns—stable, lightweight, and rollback-friendly.

Data Flow and Field Mapping

The overall flow is Kingdee Cloud (source) → Qeasy middleware → MySQL (target). On the Kingdee side, executeBillQuery pulls supplier list fields (code, name, address, payment terms, document status FDocumentStatus). The middleware keeps only the two columns that really matter, then writes them back to MySQL by the mapping rules.

Note: the MySQL otherRequest is update … set yn_lock=:yn_lock where supplier_short_code=:supplier_short_code and company_code='TYZN'—the company/book code MUST be in the WHERE clause, otherwise cross-company records will be touched. This is the top pitfall.

How to Configure on Qeasy

In Qeasy, this strategy follows a 'source query → field mapping → target execute' three-stage pattern:

1. Source (Kingdee.Cloud): API executeBillQuery, method POST. Pass FSupplierId, FNumber, FDocumentStatus, FName, FAddress, FPayCondition_FNumber as request fields. Set autoFillResponse=true so the response is flattened by field name, skipping one parsing layer.
2. Middleware: use Qeasy's 'integration strategy' to trim and map fields, converting FDocumentStatus to 0/1 yn_lock. Best practice among Qeasy customers is to put code mappings in a unified 'code mapping table' on the platform—reused by other supplier strategies instead of hardcoded per strategy.
3. Target (MySQL): API execute (WebAPI). Put main_params in the main body, and put the actual SQL into otherRequest.main_sql using named parameters (:yn_lock, :supplier_short_code). Set idCheck=true so updates only fire on matched records—zero write risk.

Implementation Steps

1. Incremental starting point: first run a 'full' sync to align current status of all suppliers; schedule the initial run in business off-peak hours (e.g., 0:00–5:00).
2. Daily schedule: source 3 7-22 * * * (at minute 3 every hour) querying, target 5 7-22 * * * (at minute 5) writing back—a 2-minute gap gives the source query a window. Common Qeasy customer pattern is 'dual-track incremental + full': incremental by FSupplierId on weekdays, full verification early on weekends.
3. Header/body staged: this strategy touches only the 'header' status field, never the body. If you later need to extend to contacts or payment terms, create a separate strategy—don't overload.
4. Retry and alerting: enable retry in the strategy config (3 attempts, 30s interval) and alert on 'updated row count = 0' for an extended period—long-term zero usually means the code mapping is broken.

Pitfall Review

1. Typical mistake: forgetting the company_code condition. Without company dimension in the WHERE clause, the UPDATE will touch same-named suppliers in other companies. Safe practice: always include book/company fields in WHERE.
2. FDocumentStatus is not simply enabled/disabled. It's a document status (A = submitting, B = audited, etc.); disabling usually depends on specific business fields. Always write the conversion function on the platform side, not as case when in SQL.
3. Don't set writeback frequency too tight. Status changes are low-frequency events—hourly is enough. Minute-level will hammer the Kingdee query interface.
4. Centralize code mapping. Don't hardcode 'Kingdee code ↔ MySQL short code' mappings inside the strategy. Qeasy's 'code mapping' component is the right place—reusable later for materials, customers, bank accounts.
5. Don't also write back name/address. Touching master data fields will dirty downstream caches. Keep status fields in a separate strategy so the blast radius is minimal when something goes wrong.

Applicable and Non-Applicable Scenarios

Applicable: upstream is Kingdee Cloud/Yonyou or similar ERP, downstream is a business database, and you need to reverse-write enable/disable and audit status back to the business system; change frequency is low (hourly is fine). Not applicable: scenarios that need to sync upstream approval flows, attachments, change history—those should use a full master data sync strategy, not this status writeback strategy.