Direct answer: In a typical automated DWS integration, the WMS owns the business object and warehouse record: item, order, shipment, license plate, units and acceptance rules. The WCS coordinates real-time material handling: parcel tracking, conveyor state, device triggers, timing, routing and physical exceptions. The DWS captures identity, dimensions and weight, then returns a correlated result. The exact boundary is project-specific, but each decision must have one named owner.
Why the boundary matters
A DWS system creates physical logistics data at a point where software and material flow meet. If the WMS and WCS both assume the other system owns a timeout, duplicate or rejected measurement, the parcel can continue while its record becomes ambiguous.
Oracle describes WCS as a bridge between WMS and material-handling devices and notes that it can send tasks to devices and receive real-time device status. Oracle WMS Cloud documentation also shows WMS exchanging instructions and completion information with external control systems. These examples support a responsibility split, not one universal architecture.
A practical responsibility map
| Decision | Typical owner | Reason |
|---|---|---|
| Business object and workflow intent | WMS | The WMS knows the item, order, shipment or handling unit being processed. |
| Units, master-data policy and business validation | WMS | These rules determine how captured values affect warehouse records. |
| Parcel presence, tracking and trigger timing | WCS or PLC layer | Execution depends on real-time equipment and conveyor state. |
| Dimension, weight and barcode observation | DWS | The capture system produces the physical measurements and result status. |
| Divert, stop and remeasure execution | WCS or PLC layer | The physical parcel must be controlled immediately. |
| Final record acceptance and persistence | WMS or designated business service | Acceptance changes the authoritative warehouse record. |
What the DWS should return
The DWS event should identify the measured object or correlation key and carry dimensions, weight, explicit units, capture time, station identity and a result or quality status. The interface also needs a measurement or message ID so retries can be recognized. See the detailed guide to DWS-to-WMS data fields after its scheduled publication.
Three handshakes, not one vague success
- Capture completed: the DWS produced a technically valid observation.
- Physical action completed: the control layer allowed, stopped or diverted the parcel.
- Business record accepted: the WMS or receiving service validated and stored the intended update.
Calling all three states “success” makes recovery unsafe. Name them separately and define whether the physical parcel may advance at each state.
Who owns common exceptions?
| Exception | Immediate action | Longer-term owner |
|---|---|---|
| No barcode read | WCS/PLC diverts or stops while preserving tracking | Operations or WMS resolves identity |
| Incomplete measurement | WCS requests remeasure or diverts | DWS diagnostics and operations review cause |
| WMS unavailable | Integration layer queues with a stable message ID | WMS/integration owner restores and reconciles |
| Business validation rejected | WCS prevents uncontrolled continuation when required | WMS owner resolves object or rule |
| Duplicate retry | Receiver returns the prior outcome without applying the update twice | Integration owner audits idempotency |
CONLIDA engineering note: keep physical and data state reconcilable
For every event, the team should be able to answer two questions: where is the parcel, and what is the last accepted data state? A correlation key must connect DWS observation, control action and WMS outcome. Without that connection, replaying a message or remeasuring a parcel can create conflicting records.
Integration workshop checklist
- Name the authoritative system for each object and field.
- Define the trigger and correlation key through the capture zone.
- Separate device completion, physical routing and business acceptance.
- Define timeout, retry, duplicate and out-of-order behavior.
- Assign every exception a physical route and an operational owner.
- Test restarts, unavailable systems and delayed acknowledgements with representative parcels.
Connecting CONLIDA DWS to the architecture
CONLIDA can provide the physical capture point and relevant integration interfaces, but the project architecture must define WMS, WCS, PLC and integrator responsibilities. Protocols, field names, performance and compatibility must be confirmed for the selected configuration rather than inferred from this framework.
Plan the DWS integration boundary.
