Purchase Order Sync: A Practical Tutorial for the MySQL to Kingdee Cloud Skyward Single Strategy

What This Strategy Solves

In manufacturing supply chains, purchase orders often need to land in two places at once: the MES-side MySQL business database and the financial/inventory side of Kingdee Cloud Skyward. The two systems care about different things. MES cares about executability, Skyward cares about finance and inventory booking. It looks like syncing a single document, but if any one of the code conventions, document status, or write-back timing drifts apart, three months later reconciliation will show mismatched quantities, prices, and suppliers.

The goal of this strategy is straightforward: push approved purchase orders from MySQL into Kingdee Cloud Skyward incrementally, and once the target side completes audit and returns the result, write back the document number, status, and message to the MySQL interface table to form a closed loop. Let us walk through it.

Data Flow and Field Mapping

The whole strategy is a bidirectional closed loop of MySQL → 轻易云 → Kingdee Cloud Skyward → 轻易云 → MySQL. Everything passes through 轻易云 as the carrier.

One note worth making explicitly: cross-system mapping for material codes, supplier codes, and departments follows a common pattern on 轻易云 that we call centralized code mapping. Keep the mapping table in one place and reference it everywhere, instead of scattering copies across many strategies that nobody can refactor three months later.

How to Configure It on 轻易云 (Qeasy)

In one real project we used 轻易云 for this, and there are four configuration points to get right:

1. Source datasource: register the MySQL connection (private deployment internal addresses are anonymized to host and port placeholders), and extract by interface table plus an incremental field.

2. Target API: call the Kingdee Cloud Skyward Save and Audit Purchase Order WebAPI. The materials split the flow into phases — save first, then audit, then return. On 轻易云 the strategy is therefore organized as a three-stage orchestration: push, audit trigger, and result write-back. It is not one big monolithic script.

3. Field mapping and code conversion: in the 轻易云 mapper, perform FSupplierId → Skyward supplier and FMaterialId → Skyward material lookup conversions, and normalize the format of amount, tax rate, and unit according to the Skyward field types.

4. Write-back strategy: once Skyward returns FBillNo, audit result, and error message, 轻易云 writes them back into the MySQL interface table's status and message columns. The materials include the condition UPDATE ... status not in ('S','A') — this avoids overwriting records that have already succeeded or been manually adjusted, which is the safe approach.

Implementation Steps

Phase 1: align the incremental starting point Before going live, align the starting timestamp with the business team. We usually take "approved but not yet pushed in the last 30 days" as the first full load to clear the historical backlog, then switch to incremental sync by modified_time.

Phase 2: trigger the full load Configure a "full sync task" on 轻易云, run one round to reconcile document numbers and amount totals on both sides, then switch to incremental scheduling.

Phase 3: scheduling frequency The purchase order sync frequency should follow the business rhythm, not the principle of "the faster the better." Workshop entry peaks are typically 8:00–10:00 and 14:00–16:00. We generally compress the schedule to every 1–3 minutes during those windows, and relax it to every 5–10 minutes during valleys. For write-back-style strategies like the one in the materials, */1 * * * * (every minute) is common, because the volume is small. The main push strategy does not need to be that dense.

Phase 4: monitoring and alerting Every strategy on 轻易云 has run logs and failure alerts. We typically set up three independent alert points — push failure, Skyward audit failure, and write-back failure — so that the on-call engineer can immediately see which link broke.

Lessons Learned

1. Do not write code mappings inside the strategy. Earlier we wrote supplier mappings directly inside a single 轻易云 strategy's script. Half a year later another sales order strategy needed the same mapping and nobody could find the source. After that we standardized on centralized code mapping, maintained per business domain.

2. Push header and lines in phases, do not all-or-nothing. A purchase order has a header plus multiple lines, and the Skyward save interface is sensitive to line count and field length. Pushing more than 200 lines at once easily hits interface timeouts. The safe approach is header first, lines in batches.

3. Always carry a status condition in the write-back. The status not in ('S','A') clause in the materials looks unremarkable, but without it the write-back will overwrite statuses that users have manually modified after Skyward audit. The classic mistake is a plain UPDATE with no condition.

4. The incremental field must be indexed. If the modified_time field on the MySQL interface table is not indexed, the scheduler does a full table scan on every run, and after two hours nobody can stand it. This is something to align with the DBA in advance.

5. Private deployment network jitter requires retries. Kingdee Cloud Skyward private deployments sit on the intranet, and cross-segment calls occasionally time out. Enable strategy-level retry with backoff on 轻易云, and do not rely solely on manual intervention.

Suitable and Unsuitable Scenarios

Suitable: purchase orders pushed from the business-side MySQL into the financial/inventory-side Kingdee Cloud Skyward, where the document structure is stable, supplier and material master mappings already exist on both sides, and the daily volume is in the range of hundreds to thousands of orders.

Unsuitable: scenarios where multiple legal entities or multiple Kingdee booksets need to receive the same purchase order simultaneously, and the early phase where supplier code mapping has not been agreed across both sides. Forcing synchronization in those cases only magnifies the chaos.