Customer-Material Mapping Sync to Kingdee with Write-Back: A Field Guide from MySQL to Kingdee Cloud Cosmos

What This Strategy Solves

In supply chain integration projects we keep hearing the same question, not "can we sync it" but "after it lands, how does the source know the result." Pushing a customer-material mapping table from a CRM-side MySQL into Kingdee Cloud Cosmos to create a bill is only half the loop; the other half is writing the bill number, success flag, and error message back to MySQL so the business team can drive downstream actions off that mapping table. This strategy turns push + write-back into one closed loop, so you never end up with orphan rows where Kingdee has the document but CRM does not.

Data Flow and Field Mapping

The end-to-end direction is MySQL (source business table) -> Qeasy integration platform -> Kingdee Cloud Cosmos (bill creation) -> Qeasy integration platform -> MySQL (status write-back). The source is a customer-material mapping table; the platform assembles it into the payload Kingdee's WebAPI expects. After Kingdee creates the bill successfully, the platform writes the bill number and success flag back to designated columns on the source row.

Worth flagging: these are platform-internal logical names; the mapping to actual database columns happens at the persistence layer. On customer sites this is the most common source of confusion, because logical names look like column names.

How to Configure It on Qeasy

On the Qeasy data integration platform we split this strategy into two halves: source -> Kingdee push, and Kingdee response -> MySQL write-back.

In the first half, the source API is configured as WebAPI / POST / QUERY with an empty request body (empty operation), and a script pulls pending rows from MySQL. The response declares four fields: 单据编号, sourceid, is_sucess, result_message, which become the inputs for write-back.

In the second half, the target API is configured as WebAPI / SQL / EXECUTE. otherRequest holds the main_sql, e.g. update wk_wodtop_customer_material_ref set sync_1=:is_success, sync_2=:is_success1 where data_id=:sourceid. The main_params parameter is an object type, mapping the four response fields from the first half into the SQL bindings.

We recommend keeping code mappings in a single platform mapping table rather than scattered across strategies — this is one of the most common patterns we see across Qeasy customers, so future encoding changes happen in one place.

Implementation Steps

Step one: confirm on source MySQL that the mapping table has a data_id primary key plus two flag columns; without data_id, write-back cannot locate the row. Step two: on Qeasy, create one source API and one target API each, then validate with a single record to confirm Kingdee creates the bill and MySQL gets updated. Step three: once the single-record path works, configure scheduling — source side */2 * * * *, target side */7 * * * *. Write-back should run slightly slower than push to avoid the "bill not yet created, write-back already ran" race.

For the incremental start point we recommend "now minus N minutes" and first drain any pending historical rows. Full-volume trigger is a one-shot script used only at initialization; once it finishes, stop it and rely on incremental from then on.

Pitfalls We Have Hit

Pitfall 1: treating write-back as an independent strategy rather than part of the loop. The classic mistake is to stop after configuring source -> Kingdee, so the bill number never comes back and business users still reconcile both sides manually. The safe approach is to make write-back a downstream of the push strategy, not a parallel one.

Pitfall 2: blurring the meaning of sync_1 and sync_2. On customer sites we have seen sync_1 used for "platform push success" and sync_2 for "Kingdee bill success"; the two get mixed up and reporting numbers disagree. The safe approach is to fix the naming up front — e.g. sync_push vs sync_kd — and document it in the mapping table description.

Pitfall 3: the write-back SQL's where clause uses a business field instead of data_id. Once the business field changes on the source side, write-back misses the row. The safe approach is to always use an immutable primary key such as data_id as the locator.

Pitfall 4: inverted scheduling cadence. Pushing every 2 minutes and writing back every 7 minutes looks fine, but Kingdee bill creation takes time, so write-back can race ahead and capture empty values. The safe approach is write-back cadence ≥ push cadence, with a guard that only writes back when the response is non-empty.

When to Use It and When Not To

Use it when CRM and ERP exchange data in a "business mapping table + bill write-back" shape, the source is a relational database, and there is a stable primary key. Do not use it when Kingdee ingest is bulk import instead of bill creation, when the source table has no stable primary key for write-back, or when you need hard real-time (sub-second) write-back — in that last case, prefer a message queue over polling.