CIP-to-Fixed-Asset Transfer: A Practical Sync Pattern into Kingdee Cloud Asset Cards

What This Strategy Solves

A manufacturing enterprise maintains Construction-in-Progress (CIP) records in its ERP. Once a project passes final acceptance, those CIP entries must be batch-converted into fixed-asset cards in Kingdee Cloud. On the surface it looks like a simple "batch insert", but the real headache is this: if the code mapping is not designed well, the asset codes on both sides drift out of sync within three months. Departments, custodians, and accumulated-dereciation accounts are scattered on the source side, and when pushed to the target they often arrive empty. We use the Qeasy data-integration platform to host this link. The "fixed-asset to Kingdee" job is treated as a single strategy: data converges at the platform first, then is pushed in batches, so the target system only handles persistence and the business side only cares whether the asset card is created successfully.

Data Flow and Field Mapping

The source is the fixed-asset view hosted on the Qeasy integration platform (essentially the data aggregated by the upstream strategy; here we treat it as our source). The target is the Kingdee Cloud asset-card persistence API batchSave. No redundant storage is introduced in the middle — the platform only handles field mapping, code translation, and batch control.

The platform uses a {{variable}} placeholder syntax in the request body, e.g. FAssetTypeID is set to {{typeCode}}. This placeholder mechanism is the most ergonomic part of doing such integrations on Qeasy — no glue code, just direct field references in the metadata.

Configuration Essentials on Qeasy

The source metadata is configured with effect=QUERY, api=OpenCallback, method=POST, because Kingdee Cloud's asset query endpoint is exposed as a WebAPI callback. The target is configured with effect=EXECUTE, api=batchSave, method=POST — the batch write entry point for Kingdee Cloud asset cards. The number and id fields on each side play the roles of "business document number" and "primary key": the source uses them for deduplication, the target uses them for idempotent write-back.

Code mappings should be maintained centrally in Qeasy's mapping tables, not hard-coded inside request scripts. We once got burned on a real project: different consultants maintained their own mapping tables, so three months later when the source added a new asset type, the target missed it and data was silently dropped. We later moved everything to a single "mapping center" where changes go through tickets, and only then did the problem converge.

For cron expressions, the source side can be 1 1 1 1 1 (monthly full reconciliation), and the target side can be * 7-22 * * * (poll every minute during business hours, leave buffer at peak). Staggering the two sides is the very common "dual-track of incremental and full" pattern on Qeasy.

Implementation Steps

Step 1, run full first. Manually trigger the source on Qeasy once to pull all CIP entries that have been completed but not yet capitalized. Do not introduce any incremental logic at this stage — only verify that field mapping and code translation can persist correctly on the Kingdee side.

Step 2, set the incremental watermark. Take the moment when the full run finishes as lastSyncTime, and afterwards push records where lastModified > lastSyncTime. This is the classic "incremental starting point" pattern that avoids re-pushing everything.

Step 3, attach target-side polling. The source queries changes every minute, the target aggregates and writes hourly. Two details matter. First, Kingdee's batchSave is a batch endpoint — keep each call under 200 records; the platform auto-splits anything larger. Second, when idCheck=true, the platform must first call the view endpoint to look up FNumber, confirm it already exists in the target or is left blank, otherwise Kingdee will reject the save outright.

Step 4, build the response callback. With autoFillResponse turned off, the platform must process the id list that Kingdee returns and write it back to the source as the anchor for the next incremental comparison. This step is easy to miss — without the write-back the system cannot tell whether an asset has already been successfully capitalized.

Lessons Learned

First, fill both org fields. Both FAssetOrgID and FOwnerOrgID must be supplied, and they are often the same value such as 102 (the asset-owning organization). Filling only one will trigger "using organization is empty" on the Kingdee side. The safe approach is to map the org number twice in the mapping table and bind it explicitly to both target fields.

Second, basic data such as unit/department/custodian must exist first. Kingdee Cloud has very strong dependencies on basic data; before an asset card can be saved, the unit, department, custodian, and asset category must already exist in Kingdee. Otherwise batchSave returns a failure but only with a single-line error code, and the investigation cost is huge.

Third, the semantics of idCheck. idCheck=true means "if the code already exists, update it; otherwise create". idCheck=false means "only create; if it exists, report an error". In the CIP-to-asset scenario we want "if it exists, update the card status", so idCheck=true is the correct choice. This is a common pitfall — many people choose false by intuition, and then the same asset gets pushed over and over, while the target keeps returning "code conflict".

Fourth, batch size. Kingdee's batchSave times out above 500 records per call. Keep it under 200 on the platform side — better to run several smaller batches than to push a single huge one.

Fifth, timezone and time window. Is the source's lastModified UTC or Beijing time? What timezone does the target compare against? The platform defaults to local time. When crossing timezones, early-morning records are easily missed or duplicated. Explicitly set "Asia/Shanghai" in Qeasy's timezone configuration, and add a 1-minute slack in the comparison logic.

When It Applies and When It Does Not

It applies to: batch CIP-to-fixed-asset conversion, fixed-asset card initialization, and historical asset backfill. It does not apply to: in-life depreciation calculation or single-asset changes (that is the scope of Kingdee's own modules — the integration platform does not replace them); nor does it apply to cross-book synchronization. Kingdee Cloud enforces strict book isolation; moving data across books requires a dedicated cross-org transfer process, not this integration link.