Procurement Monthly Settlement Sync in Practice: A Single Strategy from Expense System to Kingdee Cloud
What this strategy solves
For a retail client whose monthly procurement reconciliation relied on manual export from the expense system into Kingdee Cloud, we used a single sync strategy to push monthly settlement instances by update time, keeping procurement and finance figures aligned.
Data flow and field mapping
Direction is one-way: expense system as source, Kingdee Cloud as target, with Qeasy data integration platform in between. Source side calls the business object instance query API and pulls monthly settlement records in pages by update time window; target side calls batchSave to write them into Kingdee Cloud.
Key field mapping:
| Meaning | Source | Target | Handling |
|---|---|---|---|
| Document No. | name | FNumber | Direct mapping |
| Document Name | name | FName | Direct mapping |
| Bank Info | source object | FBankInfo(array) | Pass-through |
| Create Org | platform default | FCreateOrgId | Constant 102 |
| Use Org | platform default | FUseOrgId | Constant 102 |
| Update Window | startDate/endDate | not stored | ${LAST_SYNC_TIME} to ${CURRENT_TIME} |
| Business Object | entityId | not stored | Fixed value |
| Paging | start/count | not stored | 0 / 100 |
In Qeasy, this two-piece metadata structure (source metadata + target metadata) is a common pattern: source cares about how to pull, target cares about how to write, and the middle mapping is owned by the platform's field mapper.
How to configure on Qeasy
On the source side, choose the business object instance query API, method GET, key field name, id field name. Paging parameters go in otherRequest: start fixed at 0, count fixed at 100. This pair determines page size, and we control volume through scheduling cadence rather than adjusting count.
On the target side, choose batchSave, method POST, with idCheck enabled. FCreateOrgId and FUseOrgId use the fixed constant 102 (in this client's setup); FNumber and FName use expressions ${_system.code} and ${_system.name} to pull from the source record. FBankInfo, as an array, is passed through as-is.
Code mappings belong in a centralized mapping table in Qeasy, not scattered across each strategy's field mapping. When new business objects come in later, you only change one place.
Implementation steps
Step 1: set the incremental start time as the initial value of ${LAST_SYNC_TIME}, typically back to the first second of the current month. This makes the first run pick up monthly increments instead of full history.
Step 2: if historical backfill is needed, temporarily widen the crontab and set startDate to go-live date, endDate to current time, run a one-shot full backfill, then switch back to incremental.
Step 3: lock the schedule. Source crontab is */20 7-22 * * *, meaning every 20 minutes between 7am and 10pm. At month start this cadence is dense enough to stay timely without overwhelming the source. Target crontab is left as a trigger placeholder (e.g. 1 1 1 1 1) so it only fires when triggered upstream.
Step 4: do an integration test. Run one real monthly settlement document end to end, verify FNumber uniqueness, FBankInfo integrity, and org IDs.
Lessons learned
-
Never hardcode startDate/endDate. A typical mistake is filling a literal date, so the next day's sync stops. Use
${LAST_SYNC_TIME|datetime}and${CURRENT_TIME|datetime}and let the platform compute the window each run. -
Don't blow up page size. Pulling 500 or 1000 per page looks efficient, but the source API has performance limits and will truncate. We keep it at 100 per page and let paging do the work.
-
Don't disable idCheck. With idCheck on, if FNumber already exists in Kingdee Cloud, the platform treats it as update instead of duplicate create, which avoids pushing the same monthly settlement twice.
-
Treat org IDs as constants with clear ownership, not hardcoded strings scattered across strategies.
-
Don't break array fields apart. FBankInfo is a complete array on the source side; if you split it field by field in the mapper, any change to source field order or structure forces full re-test of the chain. Pass-through is the safe choice.
Where this fits and where it doesn't
Suitable for monthly settlement documents synced by update time, with stable org structure and simple field mapping. Not suitable when source fields need heavy transformation, target needs line-item split or multi-org allocation, or cross-period reversals require reversal documents.