Writing the WDT Order No. Back into a Kingdee Transfer-In Remark: A Practical Walkthrough of a Lightweight Strategy
What This Strategy Solves
In retail and distribution chains, many retailers run both a front-end e-commerce WMS and a back-end Kingdee Cloud for finance and inventory. When a transfer arrives, Kingdee records a Transfer-In document while the WMS holds its outbound order number. People fill the cross-reference manually, and within two or three weeks the records drift apart — the warehouse says numbers are missing, finance cannot find them in the system, and reconciliation becomes a chat-log archaeology exercise.
This strategy automates that cross-reference: it writes the WDT order number back into a remark or custom field on the Kingdee Transfer-In document, removing manual work and keeping both sides aligned.
Data Flow and Field Mapping
The chain is MySQL → Qeasy → Kingdee Cloud, and the direction is a single one-way write-back.
| Role | System | Key Field | Notes |
|---|---|---|---|
| Source (lightweight pull) | MySQL | order_no | The real data column; serves as the primary key |
| Middle layer | Qeasy | {{order_no}} {{Id}} | Orchestration context variables |
| Target | Kingdee Cloud | FID, F_PBLH_WDTNO | Transfer-In inner ID + custom field |
| Target | Kingdee Cloud | FormId, Operation | STK_TRANSFERIN, batchSave |
The source step looks like a mere QUERY with no request body, but its real job is to pull records from MySQL into the Qeasy context. idCheck=true lets order_no act as the primary key, ensuring the same document is not picked up repeatedly.
The target step is Kingdee's batchSave. Two fields matter: FID decides which Transfer-In to modify, and F_PBLH_WDTNO is the custom field that carries the WDT order number. IsAutoSubmitAndAudit defaults to false — only the remark is touched, and the rhythm is left to the upstream business flow.
How to Configure on Qeasy
Inside the Qeasy Data Integration Platform, this strategy can be modelled as two nodes wired in series.
Source node (Platform → MySQL): pick the MySQL data source, write a query SQL that fetches the records to write back, keyed by order_no, and project the columns straight into the context with no heavy transformation. The schedule is 02 4 * * *, running once a day at 04:00 to mop up the previous day's anomalies.
Target node (Platform → Kingdee Cloud): pick the Kingdee Cloud data source, choose the batchSave API, hard-code FormId to STK_TRANSFERIN, hard-code Operation to batchSave, and leave IsAutoSubmitAndAudit as false. The field mapping is only two rows: FID ← {{Id}}, F_PBLH_WDTNO ← {{order_no}}. The schedule is 6-59/5 7-22 * * *, firing every five minutes during working hours for near-real-time closure.
Centralised mapping management: keep the Kingdee inner-ID
FIDto WDTorder_nomapping in a single Qeasy lookup table. Every write-back strategy shares the same mapping instead of duplicating maintenance in each pipeline.
Implementation Steps
A three-phase rollout keeps things safe.
Phase 1 — single-point validation. Hand-pick one Transfer-In record in MySQL, configure the source SQL and target batchSave in Qeasy, click "Run Once", then verify in the Kingdee UI that F_PBLH_WDTNO is written correctly. Do not wire up a schedule yet.
Phase 2 — full backfill. Trigger a one-off full run to fill in all historic Transfer-In documents whose remarks are still empty. Source them from a reconciliation view in MySQL, filtered by update_time. idCheck guarantees idempotency.
Phase 3 — switch to incremental. After the backfill, change the SQL filter to pull only "remark still empty AND created within the last N hours", and hook it up to the 6-59/5 7-22 * * * working-hours schedule. Keep 02 4 * * * at 04:00 as a safety net for the rare daytime miss.
Header and body in stages: stabilise the header write (
FIDplus the remark field) first. Only then consider extending the same pattern to line-level fields. Avoid a full-documentbatchSaveon day one — Kingdee's batch interface is sensitive to field ordering, and any tweak tends to break something.
Pitfalls We Have Seen On-Site
- Do not treat the source step as "no-op" just because there is no request body. No
requestdoes not mean no logic. The primary-key field,idCheck, and the SQL range still need care. Otherwise the target step receives an empty context and fails with a null pointer. - Do not substitute the document number for
FID. Kingdee'sFIDis an inner ID. Business numbers collide under concurrency. The reliable pattern is to resolvedocument number → FIDin a prior lookup, then write byFID. - Keep
IsAutoSubmitAndAuditoff by default. This strategy only fills in the remark; submission and auditing should be driven by the upstream business flow. Turning it on here creates "document state drift" dirty data on the Kingdee side. - Do not run 24×7.
6-59/5 7-22 * * *is the schedule we have seen validated at many customer sites — dense during the day, silent at night, with a single 04:00 catch-up. It avoids pressuring Kingdee and still guarantees the next day's reconciliation is clean. - Maintain incremental and full in parallel. Use full runs for historical rescue and incremental runs for daily assurance. Keep the two SQLs separate instead of merging them into one filter; one careless change then breaks both tracks.
Where This Fits and Where It Does Not
Suitable for scenarios that need to backfill an external system's order number into a Kingdee Transfer-In's remark or custom field, such as e-commerce warehouse to ERP reconciliation loops.
Not suitable for line-level detail backfill, scenarios that must trigger auditing or workflows, or cases where the Kingdee custom field has not yet been created — define the field on the Kingdee side first, then automate.