Sales Outbound to AR Generation: A Practical Guide on Writing Back Status from WMS to Kingdee Cloud

What This Strategy Solves (Scenario and Value)

In one real engagement, a retail customer ran their e-commerce outbound flow in a popular WMS while keeping back-office AR in an enterprise ERP. Both systems maintained their own copy of the sales outbound document. The numbers looked balanced on paper, but downstream AR generation kept mismatching. The root cause was simple but stubborn: on the ERP-side outbound document, two pieces of information were missing—whether the order was truly completed and the exact shipping timestamp—so finance had no basis to decide whether the receivable could be closed.

The strategy we deliver on Qeasy (the 轻易云 data integration platform), namely "Sales Outbound to AR Generation," is designed to close that last mile. It does not create new documents, nor does it touch line items. It only writes back the outbound status and ship time from WMS orders with status=110 (completed) onto two custom fields of an existing ERP sales outbound document, providing the status basis for downstream AR generation.

Data Flow and Field Mapping (Source → Middle Layer → Target)

The data flow is: WMS · Enterprise OpenAPI → Qeasy Platform → ERP Cloud. The middle layer does not run business logic; it owns the incremental time window, the cross-collection lookup, and the field rewrite.

It is worth emphasizing that this strategy does not involve line items (details_list / FEntity); it only modifies two custom fields on the header. This "split header and body into separate stages" pattern is also a common practice among Qeasy customers—nail down the status first, then consider extending to line items later.

How to Configure on Qeasy

When implementing this strategy on Qeasy, there are four typical configuration points:

First, the source API is wdt.stockout.order.query.trade (POST, QUERY). The incremental time window uses {{LAST_SYNC_TIME|datetime}} and {{CURRENT_TIME|datetime}}, and status is hard-coded to 110. The "dual track of incremental and full sync" approach is very common in our customer projects—in normal days it runs incremental, and on day one or during anomaly windows a full sync is replayed to balance timeliness and fault tolerance.

Second, the target FormId uses SAL_OUTSTOCK (sales outbound business object), Operation is set to Save, IsAutoSubmitAndAudit stays false, InterationFlags is STK_InvCheckResult, and SubSystemId is 21 (supply chain module). The most critical line is NeedUpDateFields, which only declares F_PBLH_Combo, F_PBLH_Date, ensuring that Save only updates those two fields and does not overwrite other business data.

Third, the cross-collection lookup is written into the value template of the target FID field, with the syntax _findCollection find FID from <hub strategy ID> where FBillNo={{stockout_no}}. Note that keywords are separated by a single English space, multiple where conditions are AND, and the condition format field={{source field}} must not contain spaces—this is the most error-prone detail in lookup syntax.

Fourth, centralized code mapping management: the mapping from outbound order number to ERP FID is entirely delegated to _findCollection from the hub, not hard-coded in scripts nor concatenated in target fields. The benefit of this approach is that if the lookup strategy is adjusted later, only one place needs to be changed and all dependent strategies follow automatically.

Implementation Steps (Phased Scheduling)

We recommend splitting the rollout into three steps for stability:

Step 1, confirm the prerequisites are in place. This strategy strongly depends on two upstream pieces: first, "Sales Outbound Sync" (strategy C), which creates the ERP sales outbound document; second, "Query ERP Sales Outbound" (strategy F), which lands ERP documents into the Qeasy hub for lookup. If either is broken, FID cannot be found and Save will fail.

Step 2, configure the incremental start point. For the first go-live, set LAST_SYNC_TIME to "yesterday 00:00:00" and run a small window replay (for example, 1 day) to verify that F_PBLH_Combo and F_PBLH_Date are written back as expected.

Step 3, set the scheduling frequency. Per the reference configuration: source 1 8 * * * (pull at 08:01 daily), target 30 8 * * * (land at 08:30). Leave a 30-minute buffer between the two crons for upstream strategies and hub landing. Once stable in production, it can be tightened to a 15-minute cadence depending on volume.

Pitfalls Revisited

• Spaces in lookup syntax: there must be a single English space between _findCollection and find, and no spaces around the = in FBillNo={{stockout_no}}. Adding spaces makes the lookup return empty, and from the logs alone it is easy to misdiagnose this as an upstream sync issue.
• NeedUpDateFields missing or wrong: if not declared explicitly, ERP batchSave submits all fields by default and may accidentally overwrite existing business fields on the ERP side. The safe approach is to list only the fields this strategy actually writes back.
• Blind spots from hard-coding status=110: this strategy only handles completed orders. If the business also needs "partial payment (105)" to trigger AR, this fixed value must be turned into a variable, or a parallel strategy added. A typical mistake is to leave status blank, causing outbound documents of every status to flow in and pollute the data.
• IsAutoSubmitAndAudit=false should not be flipped casually: this strategy only writes back status and should not auto-submit and audit, which would push the document downstream. Setting it to true effectively moves the "AR generation" trigger earlier than intended and easily desynchronizes with the finance cadence.
• Hub data lag: the lookup depends on "Query ERP Sales Outbound" landing first. If the target cron is scheduled earlier than strategy F, you will see the phantom problem of "upstream clearly finished but lookup is still empty." The safe approach is to declare the execution order explicitly in the dependency graph.

Applicable and Non-applicable Scenarios

Applicable: private-deployment supply chain integration from WMS to ERP Cloud where the ERP-side sales outbound already exists and only the WMS completion status plus ship time need to be written back onto custom fields, in order to drive downstream finance flows such as AR generation.

Not applicable: scenarios that require syncing line items (line rows, serial numbers, batch numbers), scenarios that require creating new ERP sales outbound documents rather than updating existing ones, or write-back needs where the upstream is not in a "completed" state—those each call for their own dedicated strategy.