Write-back of Stepwise Transfer-Out Document: A Practical Guide from Kingdee Cloud Cosmos to SQL Server

What This Strategy Solves

In the supply chain integration of one retail customer, Kingdee Cloud Cosmos is responsible for generating transfer documents, while the business-side SQL Server carries store receiving, reporting, and reconciliation. Once a transfer-out document is created in Kingdee, if the store systems do not know the Kingdee-side document number, subsequent inbound reconciliation and difference investigation all break. The core of the 'write-back of stepwise transfer-out document' strategy is to write the audited Kingdee document number (F_CDPS_INTEGRATIONNO) back to an intermediate table on SQL Server, so that both sides align on the same 'document-number identity'. It usually appears as the sibling step of 'stepwise transfer-in document write-back', tagged as sequence B, running after the transfer-in number is returned.

Data Flow and Field Mapping

The data flow is a one-way write-back: Qeasy integration platform → SQL Server. The source side is the strategy execution result inside Qeasy (the outcome of the stepwise transfer-out document), and the target side is an intermediate status table.

The SQL template means: update T_STK_STKTRANSFEROUT set F_CDPS_INTEGRATIONNO = :number where FID = :sId. Here :sId comes from the source side sid, and :number comes from BillNo. This is a typical 'point write-back by primary key' pattern that does not scan the whole table.

How to Configure It on Qeasy

We usually build a 'source platform → target platform' synchronization task for this strategy in the Qeasy data integration platform. The source metadata type is QUERY, and the target is EXECUTE.

Source configuration key points: set api to 'request no-op (请求空操作)', method to POST, enable autoFillResponse, and enable idCheck. Bind the number field to BillNo and the id field to sid — these two fields are the source of the WHERE condition and SET value for the target side and must not be missing.

Target configuration key points: set api to update, method to POST, and enable idCheck. In request, attach a main_params object to receive field values; in otherRequest, attach main_sql, paste the UPDATE statement above into it, and use :sId and :number placeholders to bind source fields. This is actually a common 'direct SQL write' pattern among Qeasy customers, suitable for scenarios with few fields and a stable target table structure, and more controllable than going through an ORM.

If multiple similar strategies exist in the same project, we recommend centralizing field mapping into one comparison table (strategy id, source field, target field, is primary key) instead of maintaining them separately for each strategy. This can save roughly half the troubleshooting time later.

Implementation Steps

In one real project, we usually split this write-back into three phases:

1. Incremental starting point: on the first day of going live, run a full backfill to write back all Kingdee transfer-out documents audited in the last 30 days as a baseline.
2. Full-volume trigger: run once during the early-morning business low peak every day to fill in abnormal documents missed yesterday, with checkpoint resume support.
3. Schedule frequency: the normal schedule runs every 15 minutes (*/15 * * * *), staggered by 5 minutes from the source-side */10 * * * * rhythm to avoid concurrent UPDATEs hammering the target database. We recommend the 'dual track of incremental and full volume' approach: incremental for timeliness, full volume for consistency.

In the first week after going live, we manually compare 10 documents per day between the Kingdee document number and F_CDPS_INTEGRATIONNO on SQL Server, and only hand it over to the business side once everything matches.

Pitfall Review

1. A typical mistake is treating sid as the Kingdee document number. sid is the instance id inside the Qeasy platform; BillNo is the Kingdee document number. Once the two are mixed up, all downstream store systems fail to reconcile.
2. The target table has no primary key or has duplicate primary keys. If FID of T_STK_STKTRANSFEROUT is not unique, the UPDATE becomes 'randomly hit one row', causing dirty writes. The safe approach is to SELECT-verify FID uniqueness before going live.
3. The write-back happens before Kingdee auditing completes. This strategy depends on the audited state on the Kingdee side. If the upstream auditing strategy has not finished, a draft-state document number may be written here, causing stores to receive goods prematurely. The safe approach is to schedule the write-back after the audit-complete event, with a clear sequence ordering.
4. The schedule frequency is exactly the same as the source side. If the source runs every 10 minutes and the target also runs every 10 minutes, the target side will run empty UPDATEs while the source side has not yet generated new documents. Staggering by 5 minutes both reduces database pressure and makes logs easier to read.

Applicable and Non-applicable Scenarios

Applicable: scenarios where documents are generated on the Kingdee side and need to be referenced or reconciled on the business-side SQL Server, especially in multi-step processes such as 'transfer out first, then transfer in' in stepwise stock transfers. Not applicable: scenarios where the write-back target is a Kingdee Cloud Cosmos view field, or where the intermediate table structure changes frequently — those cases are better handled with an interface table plus trigger approach rather than a direct UPDATE.