Outbound Stock Order Number Echo-Back After Auto-Push: One Strategy to Close the Bi-Directional Loop

What This Strategy Solves

In one retail deployment, the warehouse issues a large volume of "other outbound orders" every day. After Kingdee Cloud Cosmos auto-pushes them to SQL Server, the downstream business system must echo the outbound order number back to the source document to support reconciliation and traceability. It looks like a simple "number echo-back" task, but if the linkage between auto-push and number echo is not handled carefully, orphan records appear very quickly. This strategy bundles push-back, echo-back, and cleanup into a single schedulable unit, closing the loop on three recurring problems: orders pushed without a number, duplicate numbers, and documents that can no longer trace back to their source.

Data Flow and Field Mapping

The end-to-end chain is Kingdee Cloud Cosmos → Qeasy → SQL Server → Qeasy → Kingdee Cloud Cosmos, a bi-directional loop. At the strategy layer only two actions are exposed: push and echo-back.

The core of the field mapping is the pair source doc number ↔ target ledger number. A proven approach is to maintain a centralized encoding-mapping table in Qeasy, so doc numbers, push timestamps, and push status for both sides live in one place. Without it, the two sides will not match three months later.

How to Configure on Qeasy

We use the Qeasy data integration platform to host this strategy. The configuration has three blocks:

1. Source metadata: the built-in API DeleteStrategyData (POST, type=QUERY). The request declares two objects, target_1 and target_2, pointing to the source and target strategies that need cleanup. The response uses datetime and params with auto-fill so cleanup timestamps are traceable.
2. Target metadata: WriteEmptyOperation (POST, type=EXECUTE). The request and response arrays are both empty, acting as a placeholder execution node so the scheduling chain does not break.
3. Dependencies and scheduling: the source strategy uses crontab = 50 5 25 */1 * (5:50 AM on the 25th of every month), the target strategy uses 0 6 * * * (6:00 AM every day). The order is cleanup first, echo-back second.

Configuration highlights:

• idCheck=true and autoFillResponse=true must be enabled; otherwise cleanup fails on primary-key validation.
• buildModel=false because cleanup is purely a deletion, not a model build.
• Use {{random}} for the id field so cleanup actions do not interfere with each other.

Implementation Steps

On customer sites we usually deploy in three phases.

Phase 1 — Incremental starting point (T-7 days)

• Create the outbound ledger table in SQL Server with a unique index on (source doc number + line number).
• Enable Qeasy's "incremental + full dual-track" mode: pull a one-time full snapshot of historical other outbound orders as baseline, then switch to incremental by FModifyDate.
• Verify the push path so source doc numbers arrive intact in SQL Server.

Phase 2 — Full trigger (Go-live day)

• Manually trigger the cleanup strategy's target_1 to remove orphan residue.
• Immediately trigger the echo-back strategy to write the newly generated SQL ledger numbers back to Kingdee source docs.
• Echo header first, echo body in a follow-up phase — this is a common pattern from one of our manufacturing customers and noticeably lowers first-day failure rate.

Phase 3 — Steady-state scheduling (post go-live)

• Cleanup runs automatically at 5:50 AM on the 25th of every month, removing unmatched intermediate data from the previous cycle.
• Echo-back runs at 6:00 AM every day, covering all orders pushed the previous day.
• Monitor three KPIs: cleanup row count, echo-back success rate, orphan count.

Pitfalls From the Field

1. Cleanup and echo-back run in the wrong order, and orphans multiply. A typical mistake is echoing first and cleaning up second, which causes the cleanup step to delete the very echo records just written. The safe order is: cleanup → push → echo-back. Never reorder.
2. No unique constraint on Kingdee source doc numbers. When both sides use doc number as the primary key, downstream overwrites upstream and reconciliation breaks three months later. A centralized encoding-mapping table is mandatory, not optional.
3. Header and body echoed together, first-day failure rate spikes to 30%. One manufacturing customer hit this exactly. Switching to "header first, body in a follow-up phase" brought the failure rate below 2%.
4. idCheck not enabled, cleanup deletes real business data. This is the most dangerous failure — without primary-key validation the cleanup interface can wipe legitimate documents. Always validate manually several times before going live.
5. Crontab ignores month-boundary edge cases. The "monthly 25th cleanup + daily 6 AM echo-back" combination creates a window at month end where cleanup runs before echo-back completes. The safe approach is to declare an explicit dependency in Qeasy so cleanup waits for that day's echo-back to finish.

When It Fits and When It Doesn't

Fits: Kingdee Cloud Cosmos + SQL Server private deployment, supply-chain scenarios where other outbound orders need to be auto-pushed and echoed back every day. Does not fit: real-time echo-back requirements (< 5 minutes); multi-org, multi-book scenarios sharing a single outbound ledger table; cases where the source system does not expose a doc number field.