Sales Order Status Feedback: A Practical Guide to the Sinopharm WMS Outbound Query Strategy
What This Strategy Solves
In the pharmaceutical retail supply chain, after a sales order is released from Kingdee Cosmos, the WMS-side outbound feedback is what truly drives inventory release and shipping rhythm. When a retail enterprise went live with Sinopharm WMS and Kingdee Cosmos, the business team kept reporting that "orders are already in ERP, but WMS still shows them as not shipped." The root cause was not that outbound did not happen, but that the feedback was not written back to the business view. This strategy targets exactly that gap: it periodically pulls the outbound feedback from Sinopharm WMS back into the integration platform, so it can drive the sales order status forward.
Data Flow and Field Mapping
Data flows from Sinopharm WMS to the Qeasy data integration platform. The source system exposes a WebService endpoint GetPktRstErp (GET, QUERY semantics). On the target side, the platform receives the payload through a RESTful "write-empty" operation, whose main job is to persist the response for downstream strategies to consume.
Key fields mapping (source → intermediate → target):
| Business meaning | Source field (Sinopharm WMS) | Intermediate field | Target handling |
|---|---|---|---|
| Owner code | PT_ERP_OWNER | Same name passthrough | Stored in platform context |
| Owner internal id | ERP_OWNERID | Same name passthrough | Used for cross-document linking |
| Pick type | PKT_TYPE | Same name passthrough | Marks the outbound type |
| Detail line count | DETAILLINES | Same name passthrough | Auxiliary pagination hint |
| ERP business group no. | ERP_GROUPNO (sample CD0000019) | Mapped to number | Used as the business number |
| Pick ticket no. | PKT_NO | Mapped to id | Used as the document primary key |
This follows a common Qeasy customer pattern — "centralized code mapping management" — so all Sinopharm-side constants (such as owner T0, pick type S) live in one mapping table and can be reused by later strategies.
How to Configure It on Qeasy
In the Qeasy data integration platform, this is a typical QUERY_ONLY strategy and is implemented in three steps.
Step one, register the source system. Add Sinopharm WMS as platform A with its WebService connection info; keep the Sinopharm code consistent with the integration scenario.
Step two, register the target. The target platform is "Qeasy integration platform" (datahub). Use the write-empty API with POST method to persist the response. Bind id and number to PKT_NO and ERP_GROUPNO respectively, and keep idCheck enabled to prevent duplicate writes.
Step three, attach scheduling. The strategy's crontab is null, which means it is normally triggered by the preceding push strategy in sequence A. In addition, a fallback polling schedule 1-59/10 8-22 * * * covers business hours every 10 minutes.
Implementation Steps
Phase one, starting point alignment. Confirm in Kingdee Cosmos that the sales order is approved and ERP_GROUPNO is generated; this is the input for the query. It is frequently missed and causes the first run to be empty.
Phase two, first full-volume trigger. On go-live day, trigger once manually and verify that DETAILLINES and PKT_TYPE match the expected semantics. If the first write is abnormal, the every-10-minute polling will keep amplifying the dirty data.
Phase three, switch scheduling frequency. Once stable, adopt the "incremental plus full-volume dual track" pattern: business hours (08:00–22:00) run incremental polling every 10 minutes; nightly switch to a daily full sweep that reconciles feedback not yet received from the previous day, then hands off to downstream to update sales order status.
Phase four, downstream handoff. This strategy only handles the query and persistence. The actual sales order status advancement is performed by subsequent strategies in the sequence that consume the intermediate table — a classic "header and body staged processing" pattern.
Lessons Learned
- Parameter semantics mix-up:
MsgBody.ERP_GROUPNOandMsgBody.PKT_NOare easy to swap. The first is the business group number exposed to downstream business systems; the second is the internal pick ticket number. If swapped,idCheckwill treat every callback as a duplicate and drop it. - Polling outside business hours: Some teams write
*/10 * * * *, which generates heavy alert noise from occasional night-time timeouts. A safe pattern is to constrain it to1-59/10 8-22 * * *. - Hard-coded
T0constants: Constants like owner and pick type hard-coded in scripts require global edits on every change. Centralizing them in a mapping table lets every dependent strategy follow automatically. - Misconfigured target platform: The target must be the Qeasy integration platform (datahub), not Kingdee Cosmos. This is an
INTERNALflow that lands data in the platform's intermediate layer; it must not write directly to the business system. - Disabled
idCheck: Turning it off lets the same pick ticket be written repeatedly, causing downstream sales order status to be pushed forward multiple times. Keep it on; only disable temporarily for troubleshooting.
When It Applies and When It Does Not
Applies: sales order status feedback lookup between Sinopharm WMS and Kingdee Cosmos (or similar ERP), where the outbound feedback is required to advance the business-visible order status. Does not apply: store-level POS scenarios requiring second-level real-time feedback, complex warehouse networks sharing pick tickets across owners, or flows where the target is a business system rather than the platform's intermediate layer.