Logistics Sign-off → Kingdee Cloud Confirmation: One Strategy for the Supply Chain Sign-off Loop
What This Strategy Solves
In many retail and distribution enterprises, logistics sign-off happens on the WMS or TMS side, but sales outbound orders in Kingdee Cloud stay at "shipped" status, blocking financial reconciliation and AR confirmation. In one real project, a retail enterprise had 200–600 outbound orders per day; sign-off data never made it back, and staff had to manually click "confirm receipt" one by one — slow and error-prone. This strategy has a single purpose: driven by logistics sign-off facts, batch-write the receipt confirmation date back to Kingdee Cloud for all eligible outbound orders, closing the sign-off loop.
Data Flow and Field Mapping
Data starts at the source SQL Server, goes through the Qeasy data integration platform for cleansing and mapping, then is batch-written into Kingdee Cloud.
Key field mapping table:
| Field | Meaning | Source (SQL Server) | Middle Layer (Qeasy) | Target (Kingdee Cloud) |
|---|---|---|---|---|
| FBillNos | Outbound order number | T_SAL_OUTSTOCK.FBILLNO | Primary key, idempotency anchor | FBillNos (batch order id) |
| FSHDate | Receipt confirmation date | DATEADD(DAY,3,t.FRECEIPTTIME), MAX | String, formatted for target | FSHDate |
| FCZUser | Operator/marker | Fixed "物流签收" | Constant | FCZUser |
The source SQL filter is the heart of this strategy: only sign-off time exists + customer type excluded + not confirmed within 3 days after sign-off + certain special customer numbers excluded + same-day shipments excluded. The SQL itself selects "orders that should be confirmed but are not"; the target API simply writes the result back.
Configuring This on Qeasy
- Source modeling: Use the SQL Server data source in Qeasy with a custom SQL (main table query SQL). Push all filtering into the source to avoid full-table scans. Enable autoFillResponse so field names map directly to response keys.
- Target modeling: Choose Kingdee Cloud's batchUpdateSHDate custom API, method=POST, idCheck=true, ensuring writes only happen when the order number matches.
- Field binding: All three fields use
{{variable}}to reference the source response. FCZUser is set as the constant "物流签收". The request body stays a simple three-field structure — no header/body split, consistent with the "single-purpose strategy" principle. - Error handling: Enable retry on failure and alert notifications. On batch submission failures, the specific FBillNos must be locatable so staff can manually patch.
Implementation Steps
A phased scheduling approach to avoid one-shot full loads:
- Phase 1 — Incremental start point First run is manual; trigger only one day (yesterday) and reconcile the FBillNos count against the business system daily report. Only enable scheduled runs after parity is confirmed.
- Phase 2 — Full-volume trigger (optional) For projects with significant historical backlog, run a one-time "last 7 days" patch and observe whether Kingdee Cloud absorbs the load. A single full historical backfill is usually not recommended — it can trigger Kingdee Cloud batch API throttling.
- Phase 3 — Steady scheduling
Source crontab
0 2 * * *(02:00), target crontab offset by 5 minutes5 2 * * *, so both ends never strike the database at the same second. Once daily volume stabilizes, manual intervention is rarely needed. - Phase 4 — Verification Use Qeasy's reconciliation node or an independent query to spot-check daily that FSHDate matches sign-off time + 3 days; any drift over 1 day goes into a triage queue.
Pitfalls and Lessons
- Filter conditions in the wrong layer Typical mistake: putting customer exclusions in the target, causing Kingdee Cloud to receive pointless requests. The safe practice is to push all filtering into the source SQL — the platform should only move data.
- DATEADD MAX semantics unclear A single outbound order can have multiple sign-off records; taking the earliest vs. latest changes the business meaning. Decide explicitly in the source SQL and document in the strategy description that MAX = final sign-off time.
- Time zone and date format GETDATE() returns the database server's local time; FSHDate in Kingdee Cloud is a string. Unify the format (commonly yyyy-MM-dd HH:mm:ss) or the target will reject it as invalid.
- No idempotency guarantee Repeated scheduling will resubmit the same order numbers. Although batchUpdateSHDate is an overwrite, still enable idCheck in Qeasy to prevent dirty data from accidental manual triggers.
- Special customer list scattered everywhere In one retail project, special customer numbers were initially hard-coded into SQL; when business later needed to add a few, SQL had to be republished. A common Qeasy customer pattern is to centralize these exclusion conditions in a constant mapping table; the platform reads the table and filters — change once, applies everywhere.
When to Use and When Not to Use
Use when: sign-off semantics are unified (last sign-off wins), customer rules are relatively stable, and a batch write-back API is available. Do not use when: sign-off status is in transit, partial receipts are required, or tight coupling with financial AR is needed — those scenarios need stateful line-item sync, not this lightweight "one-shot date write-back" pattern.