Syncing Pending Asset Data: From Fixed Assets to Kingdee Asset Cards

What This Strategy Solves

In a group enterprise's fixed asset management scenario, the front-end business system retains a batch of asset data in a 'pending confirmation' state before formal asset cards are generated. This data must be pushed to Kingdee Cloud Cosmic to create asset cards, which serve as the master data source for subsequent depreciation, changes, and disposals. If this link breaks, asset cards have to be manually entered one by one in Kingdee, which is slow and prone to missing fields. This article focuses on the single strategy 'Sync pending asset data from fixed assets to Kingdee asset cards', walking through the complete closed loop from source query to target write.

Data Flow and Field Mapping

The entire link has three layers: source (fixed asset pending confirmation repository), middle layer (Qeasy Data Integration Platform), and target (Kingdee Cloud Cosmic asset cards).

The source is the platform-side OpenCallback interface (POST /QUERY), returning pending asset records. Key return fields include deviceCode (asset barcode), budgetAccount (budget account), accCode (asset code), etc. These fields are only in 'pending confirmation' state at the source and need to go through code translation and field concatenation at the middle layer before being written to the target.

The target is Kingdee Cloud Cosmic's batchSave interface (POST /EXECUTE), used for batch saving asset cards by document. The key parameter mapping is as follows:

Note a few details: the target has idCheck=true, meaning the write must first check whether the primary key exists; the source has idCheck=false, meaning OpenCallback does not perform idempotent checks. This difference determines that idempotent logic must be handled at the middle layer.

How to Configure on Qeasy

On the Qeasy Data Integration Platform, this strategy is typically configured with the following key points:

1. Source action: Select OpenCallback, POST method, effect set to QUERY, declare return fields like deviceCode / budgetAccount / accCode. The source does not set number or ID checks; it only handles 'fetching data'.
2. Target action: Select Kingdee Cloud Cosmic's batchSave, POST method, effect as EXECUTE, number field bound to document number FBillNo, id field bound to primary key id, enable idCheck. On the Kingdee side, FAssetOrgID / FOwnerOrgID are hardcoded with constant 102, while FNumber / FName / FAssetTypeID use variables bound to source fields.
3. Code mapping: 'Asset type' is a typical code translation scenario. The source business code and Kingdee's FAssetTypeID are not always one-to-one mapped. It is recommended to centrally maintain them in Qeasy's mapping table rather than scattered in scripts—this is the 'centralized code mapping management' pattern commonly used by Qeasy customers.
4. Header and body: This strategy mainly writes header fields (organization, ownership, type, code, name, unit). If you later need to extend to the body (such as depreciation policy, attachments), it is recommended to stabilize the header for a period first, then add the body in phases.

Implementation Steps

1. Incremental starting point: For initial launch, first take 'pending confirmation' assets after a fixed point in time as the incremental starting point, run a batch to validate mappings and codes; do not start with a full reload, otherwise historical dirty data will be poured into Kingdee all at once.
2. Full trigger: Once incremental is stable, use a one-time script or the platform's full trigger task to fill historical 'pending confirmation' assets into Kingdee asset cards.
3. Scheduling frequency: The source crontab is set to 1 1 1 1 1 (run only once, for initial fetch), and the target crontab is set to * 7-22 * * * (every hour during working hours). This way, the source is 'on-demand triggered', and the target is 'high-frequency landing'—a typical dual-track pattern of incremental and full.
4. Go-live sequence: First run 3-5 sample records in a test account set, confirm FNumber is not duplicated, FAssetTypeID can be queried, and idCheck passes, then switch to the formal account set.

Pitfall Review

1. idCheck=true is easy to overlook. Kingdee's batchSave checks the primary key by default. If the same accCode is pushed repeatedly, it will report an error directly. The safe approach is to use accCode as an idempotent key at the middle layer: check first, then write.
2. Code mapping scattered in scripts. A typical mistake is 'write this field once in this flow, and again in a different strategy', and three months later the numbers on both sides don't match. Centralizing in a mapping table is a repeatedly verified practice among Qeasy customers.
3. Organization and ownership mismatch. The source organization may correspond to multiple accounting organizations in Kingdee. FAssetOrgID and FOwnerOrgID cannot simply copy-paste the constant 102; they need to follow the actual organization to which the asset belongs.
4. Insufficient target response parsing. batchSave does not return simple success/failure, but an object with FBillNo. If FBillNo is not taken back for write-back in the response, subsequent change strategies will not be able to find this card.
5. Scheduling window mismatch. The source 1 1 1 1 1 only triggers once, and someone mistakenly thinks it means 'once per second'—this is a cron expression, and five 1s in Qeasy's semantics means 'one-time initialization'. When changing the frequency, be sure to check the platform documentation and not rely on intuition.

Applicable and Non-Applicable Scenarios

Applicable: batch generation of asset cards from fixed asset 'pending confirmation' assets, with fixed organization/ownership and aligned asset type codes. Not applicable: scenarios requiring complex bodies (such as multi-line depreciation, attachment flows), cross-organizational allocation, or scenarios where source data quality is extremely poor and must be cleaned before sync—these are better suited for a 'clean first, then sync' two-stage strategy.