Practical Guide: Backfilling Outbound Time for Assembly Disassembly Orders

What This Strategy Solves

In manufacturing and retail supply chains, assembly/disassembly orders (also known as assembly orders or split conversion orders) are a typical "semi-finished reprocessing" form: the warehouse issues stock according to the order, and only then does the assembly workshop move to the next production step. Many ERPs create an assembly/disassembly order with only a planned outbound date, and the actual outbound moment needs to be written back as a timestamp to drive subsequent operation accounting, cost settlement, and shop-floor scheduling.

In one real project, we found that after assembly/disassembly orders were created in Kingdee Cosmic for a retail enterprise, the outbound time field remained empty until manual entry at month-end, severely lagging the cost module. Our solution was a dedicated strategy that backfills the outbound time from the source system (Jike Cloud) to the target system (Kingdee Cosmic) in real time, aligning the "moment of outbound" between the two systems. The strategy looks simple, but it tests scheduling precision, incremental start point, and write-back idempotency.

Data Flow and Field Mapping

The overall link is a one-way backfill: Source system (assembly/disassembly outbound document) → Qeasy Integration Platform (middle layer) → Target system (header outbound time field of assembly/disassembly order).

The most error-prone part is the match key. The source uses "outbound document number" while the target needs the "assembly/disassembly order number" as the WHERE condition, so Qeasy must ensure the two have already been linked by an upstream strategy. This strategy itself only handles "time backfill" and does not create the association.

How to Configure on Qeasy

In the Qeasy Data Integration Platform, the core of this strategy is a source pull + target backfill two-stage combination.

Source configuration. Use the query-type WebAPI erp.storage.goodsdocout.v2, POST request, with page size set to 50 (50 records per page is stable in practice; larger sizes occasionally miss records). The key query window uses the platform built-in placeholders {{LAST_SYNC_TIME|datetime}} and {{CURRENT_TIME|datetime}}, which Qeasy maintains automatically; the first sync uses a safe fallback date as the starting point. Leave goodsDocNo empty to pull all records within the time window.

Target configuration. The call is Qeasy's own UpdateStrategyData interface, which looks like an internal API but is actually the platform's externally exposed "update by strategy" channel—it allows updating only the specified fields in the target strategy without pushing the entire document. The request body has three fixed-structure fields: updateKeys with field name outDatetime, updateValues with {{inOutDate}} passing through the source time value, and updateTypes marked as string. Two other otherRequest parameters: strategy_id specifies the target strategy ID to be updated, and whereKeys is set to content.assNo meaning position by assembly/disassembly order number.

Encoding mapping. Outbound time formats (such as "2024-05-20 14:30:00" versus Unix timestamp) need to be unified once in Qeasy's field mapping. In our project we used direct string format pass-through, which is stable and easy to troubleshoot.

Implementation Steps

1. Confirm prerequisite dependencies: ensure upstream strategies already sync assembly/disassembly order master data from Jike Cloud to Kingdee Cosmic, and the content.assNo field is populated; otherwise backfill will land on nothing.
2. Configure incremental start point: set a fallback time for first sync in Qeasy (we generally use 7 days before project go-live) to avoid pulling historical data all at once and pressuring the target.
3. Small-volume verification: run with crontab */9 * * * * (a high-frequency small window) for one to two days, manually checking the backfill results of a dozen orders.
4. Full backfill trigger: after confirmation, change the fallback time to the desired full backfill starting point and run a full sync once.
5. Finalize scheduling frequency: backfill-type strategies demand high real-time performance; we usually schedule every 9 minutes; below 5 minutes the source API occasionally rate-limits, above 15 minutes loses the meaning of "backfill".
6. Monitoring and alerts: hang a run-log dashboard in Qeasy to watch two anomaly counts: "target update failure" and "no matching assNo".

Lessons Learned

Pitfall 1: Setting the first sync start time to the system current time. This causes all historical assembly/disassembly orders to be missed, leaving target outbound time forever empty. The safe approach is to clearly separate "incremental start point" and "full trigger" into two stages: first run a full sync with the fallback time, then switch to incremental.

Pitfall 2: Wrong match key choice. We initially mistakenly used the outbound document number (goodsDocNo) as the WHERE condition, resulting in almost no matching records in Kingdee Cosmic. The correct key is the assembly/disassembly order number (assNo), and this field must first be mapped by another sync strategy.

Pitfall 3: Source time field carries a timezone, target does not. Jike Cloud's inOutDate is local time with timezone, while Kingdee Cosmic's outDatetime defaults to server timezone parsing. For cross-timezone customers, this strategy "arrives on time but is 8 hours off", which is often noticed by business users immediately. The safe approach is to add an explicit formatting step in Qeasy's field mapping.

Pitfall 4: Treating an update strategy as a sync strategy. UpdateStrategyData is a "partial update"; it cannot automatically create documents or push line items like ordinary sync strategies. Customers often confuse this on-site, resulting in downstream data not being found.

Pitfall 5: Ignoring idempotency. It is completely normal for the same assembly/disassembly order to be backfilled multiple times (e.g., business re-review, supplementary order), but the combination of updateKeys + updateValues + whereKeys must be idempotent, so the target does not generate dirty data from duplicate requests.

Suitable and Unsuitable Scenarios

Suitable: the source has "actual outbound time", the target's assembly/disassembly order needs to be backfilled with the true outbound moment for cost settlement, operation accounting, and shop-floor scheduling; and the two ends already have stable document associations via other strategies.

Unsuitable: the source has no concept of outbound time (e.g., purely planning-type systems); the target requires full-document sync (header + line + inventory) rather than updating a single field; there is no stable document mapping between the two ends. In these three cases, prioritize completing the prerequisite assembly/disassembly order master-data sync strategy before considering time backfill.