Locating systems deliver what they promise. Forklifts, load carriers, material and orders are visible in real time, and wherever a geofence is defined, every movement automatically generates an event. That real-time transparency is not the goal, however; it is the foundation for everything that follows. The question is how to put that transparency to operational use.
The leading system in the warehouse is and remains, in most cases, SAP EWM. That is where stock sits, where processes run, where the data has to arrive. Location data only creates value once it is synchronized with EWM and with the business processes.
Is there a warehouse task for this manual warehouse movement? Was it fulfilled, or only started? Or is this an unplanned posting? Is the handling unit assigned to a storage bin or to a resource?
Data and events from a locating system are not enough for a posting in SAP EWM without logic and context. Between the two lies an integration step that can become a hurdle, because SAP resources are usually limited.
In an earlier article, we described what becomes possible when SAP EWM reacts to physical movement. This article focuses on how much DeepHub® and the SWAN Locating Connector simplify the integration of location-based solutions into SAP EWM.
The step everyone hesitates before
Every EWM has grown over the years and carries its own configurations and extensions, and on the other side the APIs of locating systems differ from one another. Connecting the two requires people who understand EWM and locating at the same time.
As an omlox-certified middleware, DeepHub® already reduces the complexity and the effort of the integration drastically, because it unifies data and events across every locating solution and technology and makes them available to the application layer through extremely lean APIs.
That leaves the SAP side. EWM has its own language, its own objects and its own logic: handling units, resources, storage bins, warehouse tasks. All of that has to be taken into account when translating events from a locating system into a correct warehouse movement. This is exactly where the SWAN connector comes in.
The connector sits inside SAP EWM, not in front of it
First things first: the SWAN Locating Connector is ABAP-based and runs inside SAP EWM.
DeepHub® processes and harmonizes location data from a wide range of locating systems, for example BLE, UWB, GPS or lidar, makes it available as live location data, and generates events when an object enters or leaves a geofence, for instance one representing a storage location.
The direct connection to DeepHub. The connector uses an ABAP Push Channel to actively open a WebSocket connection to DeepHub, so there is no polling and no additional component on the SAP side. The data and events are processed and call EWM’s business logic.
The connector also synchronizes the SAP objects such as storage locations, HUs and resources with their counterparts in DeepHub, meaning fences, trackables, zones and location providers, via a REST API. This makes the SAP metadata visible in DeepHub for third-party systems that access location data as well.
The prerequisite on the SAP side is an S/4HANA system with Basic or Advanced EWM, embedded or decentralized.
What is the benefit in day-to-day operations?
The benefit becomes concrete through a simple example: a transfer with a forklift. Normally this requires two posting steps by the operator: posting the HU out of the source bin and posting it into the destination bin. Locating the forklift and automatically identifying the HUs on the forks automates this.
- Pick-up. The forklift picks up an HU. The HU is automatically transferred from the storage bin to the resource.
- Leaving the storage bin. The resource (forklift) leaves the geofence (storage location). The connector checks whether a warehouse task exists for this movement or not.
- Set-down. The HU is positioned at a new geofence (storage bin). If the transfer had an EWM warehouse task, it is confirmed automatically. If not, a new warehouse task is created and confirmed automatically.
In both cases the handling unit is then released from the resource and assigned to the new storage bin.
The operator saves three manual actions per transfer: the scan when picking up, the scan when setting down, and the confirmation. No typos, no wrong storage bins, no correction postings. Every movement is represented correctly in the system by the connector. In the system this location-based posting looks like any other confirmed movement, which is why reporting, inventory and tracing keep working unchanged.
It’s worth highlighting the automatic capture of unplanned transfers that have no warehouse task. In practice these are not only unplanned but frequently happen without any posting at all: an operator sets a pallet aside because the bin was occupied, because the aisle was blocked, or simply because it saves time. In the system it then still sits at the old storage location. With the locating connector, manual posting activity of that kind, along with search effort, stock discrepancies, imprecise planning and coordination overhead, is minimized.
Standardize what can be standardized
The connector provides one uniform mechanism for the integration. Everything that can be standardized is standardized: the connection, receiving the events, master data synchronization, the building blocks for typical movements. What is not standardized is which process gets triggered when. That question has long been answered in the customer’s system.
The posting logic differs from customer to customer, because what counts as a deviation in one warehouse is the normal case in the next. Whether a change in stock automatically triggers a replenishment order or goes to planning for manual review is a process question, not a configuration option. That is why the SWAN connector deliberately uses the existing EWM logic, making a redundant layer of stock management unnecessary.
Where it pays off first
Bulk storage. EWM manages bulk storage either coarsely, as an area without precise bin information, or it enforces individual bin management. The first means search effort, the second means posting effort, which also brings a higher error rate. Based on locating systems, stock is managed bin-accurately and fully automatically.
Continuous inventory. Real-time transparency over stock and positions means considerably fewer stock discrepancies. Location-based automatic postings minimize deviations, both during stock counts and in day-to-day operations. The effort for the annual stock count shrinks considerably as a result.
Further application scenarios include:
- Assigning warehouse tasks to the nearest resource, for the shortest possible approach routes and fewer empty runs
- Path analysis and heat maps to optimize routes and identify bottlenecks and hazardous spots
Both scenarios can be optimized with the SWAN 3D Logistics Cockpit, thanks to its intuitive visualization and control interface built on EWM.
What IT asks
SAP EWM remains the leading system. Stock stays in EWM. No redundant second system is created that has to be reconciled. The connector triggers postings, it does not keep its own.
The connector is part of the SAP landscape. ABAP-based, inside EWM, connected through standard mechanisms. No separate application alongside it that has to be operated, secured and documented on its own.
No vendor lock-in. DeepHub® is vendor-neutral and built on omlox, the open locating standard. Combined with the connector, this enables a standardized and fast, often close to plug-and-play, integration of IoT solutions into SAP: flexible, technology- and vendor-neutral, scalable and future-proof.
Certified integration. The SWAN Locating Connector is certified as “DeepHub Connected”. The certification ensures that location data and events are exchanged between SAP and DeepHub via the omlox API, meaning through an open standard rather than proprietary APIs or purpose-built interfaces.
Our tip: start small
Rather than investing in locating hardware for the entire warehouse, a small pilot in one area or for one use case validates the benefit first. This minimizes the financial risk and creates a solid basis for a step-by-step rollout, with measurable results from the start.
What needs validating is not only whether the locating system is suitable, but also whether the locating solution harmonizes with the SAP process. It therefore makes sense to trial locating solutions within a small, controllable scope. A bulk storage area, one building, or a goods receipt and goods issue zone, for example.
Scanning and posting are second nature to warehouse staff; automating that through locating is new. A small pilot shows not only that the technology works, but above all it builds confidence in process reliability and in the postings being triggered correctly in SAP EWM.
Locating automates. SAP EWM provides the logic. DeepHub and the connector are the link that makes the integration seamless.
Get in touch to discuss what this could look like in your warehouse.