Imagine a simple warehouse picking process that uses a manual picking strategy in a storage unit (SU) managed warehouse. The warehouse worker creates a transfer order while picking for an outbound delivery by scanning an SU in a bin and loading the item onto a conveyor to a shipping door. At the shipping door, the SU is scanned again before it is loaded on to a truck to confirm the pick transfer order. Once all the items are picked and confirmed, the delivery is completed by posting a goods issue. Ideally, this warehouse should have smooth, fast movements of its SUs, but in the real world, things do not always run that well.

Situations that clog operations may occur during picking and bin-to-bin transfers. During the picking process, a warehouse worker might find an SU that is not supposed to be in the warehouse. This occurs when an SU that is listed as already shipped to a customer or transferred to another warehouse is still in the bin. This might sound unlikely, but this situation occurs quite often in fast-paced warehouse operations. The system status shows either the SU is shipped or in an interim storage type, but the physical location is only known during the picking or physical inventory process. This prolongs the error because the SU might not even be noticed until the bin is visited by a worker again. During a bin-to-bin transfer, the warehouse workers might find the bins blocked, which slows them down. In both of these situations, a supervisor needs to be alerted of the problem, slowing down not just the workers, but the whole warehouse operations as well. In fast-paced warehouse operations, it is business critical to address these exceptions as soon as they occur to maintain an uninterrupted flow of goods.

These scenarios were just some of the problems occurring in my warehouse. Together with the warehouse manager, we came up with a simple approach to reduce the complexity of SAP Warehouse Management (WM) processes; we implemented mobile transactions in the warehouse. These mobile transactions were user friendly and quick to execute, which improved the warehouse operator’s productivity. This way, when problems occurred, such as the item found in the bin during picking, the worker could flag the item during the picking process without slowing down. Or in the case of the blocked bins, the supervisor could quickly react and reduce unnecessary travel by the lift operators. This helped diminish the effort in the next physical inventory cycle as the problems were already accounted for by the supervisor.

SAP WM comes with a number of reports and a tool called warehouse activity monitor (WAM) to identify and manage the exceptions. These tools are mostly based on time dimension. Transfer orders or deliveries should not be open longer than a certain threshold of time, such as eight hours, as they are not designed to raise exceptions based on user- defined rules. In addition, these tools operate more in a PULL fashion when a supervisor needs to run a transaction online or schedule a periodic batch job that can potentially delay a supervisor response to an exception. For more information on WAM, refer to Srivathsan Narayanan’s article “Track and Fix Incomplete Warehouse Processes Effectively with WAM” in the SCM hub of SAPexperts.

With this background, I will show you how to set up a PUSH type alert system so that a supervisor is instantly notified through an email of any pre-defined exception triggered from a WM mobile transaction. I will also explain the concept using a couple of business scenarios and a custom WM mobile transaction. In just a few steps, you can set up an automatic email alert from custom radio frequency (RF) transaction ZWRF01 to handle the exceptions I described.

Step 1. Make sure your SAP system is set up for email.

You need your Basis colleague’s help to activate the Simple Mail Transfer Protocol (SMTP) node in transaction SCOT with the email server details (Figure 1).

Figure 1

Set the email server name

Step 2. Set up a distribution list for recipients of the email.

Depending on the administrative organization structure of your warehouse, determine who receives the emails, such as a supervisor or manager. Then, determine what types of transactions you need to establish and group them into mailing/distribution lists. In my example, the warehouse management decided to set up one distribution list for every combination of SAP warehouse numbers and SAP transaction codes. Thus, the distribution list name for warehouse 900 and transaction code ZWRF01 is 900_ZWRF01. Launch transaction SBWP (business workplace) and click on the Distribution lists button.

In the field Name, enter 900_ZWRF01, and in the field Title, enter Distribution List for WH 900 & ZWRF01. Click on the Create folder button. On the next screen, use the drop-down in the field folder and enter the EMAILALERTS in the Folder name field. In the Folder title enter Folder for Email Alerts and click on the Create folder button. On the next pop-up screen, click on the Transfer icon to close the screen and select the tab Distr. list content (Figure 2).

Figure 2

Create an email folder

Enter the email addresses of the alerts’ recipients and click on the save icon (Figure 3).

Figure 3

Enter the email addresses of recipients

Step 3. Set up a custom function module to trigger email.

Ask your ABAP colleague to help develop a custom function module Z_SAP_SEND_ EMAIL. This module takes distribution list name 900_ZWRF01, the contents of the email subject line, and the body as inputs. It sends the email based on the exception rule. This module can be called from the appropriate location in the ABAP code of the custom RF transaction based on the business rules for triggering an exception. You can also call this module from user exits in the standard SAP transactions for creating transfer orders. SAP provides a test program (BCS_TEST01) that your ABAP resource can use to develop the function module to send emails as described above.

The wording in the subject line needs to provide a quick summary of the alert with the details in the body of the email message. You should discuss what content is appropriate to the situation with your warehouse management team.

Step 4. Test drive.

If the data is set up to trigger the exception correctly, the mobile transaction shows a message to the picking operator (Figure 4).

Figure 4

Picking mobile transaction

Send the email alert to the supervisor (Figure 5). A bin-to-bin blockage scenario might trigger a similar email (Figure 6).

Since this is a standard email application, a variety of devices can receive the messages, such as PDAs, barcode scanners with PDA features, or any other handheld computers with email features. This means a supervisor or manager can attend to business-critical alerts while on the move or when not in the office.

Unlimited Opportunities

The example I have described is just a sample to show you the potential of this tool, which you can deploy in any module depending on the business need. You can modify the email alerts easily to suit your purposes. For example, my team and I have developed using a custom mobile transaction that functions as an email paging tool, which an operator can use to ask for the supervisor’s help simply by scanning a bin (Figure 7).

Figure 7

Simple email paging tool

The supervisor receives an instant email message with the name and location of the operator (Figure 8).

Any SAP module can benefit from this simple custom tool fairly easily. We have utilized this tool extensively in supply chain areas such as purchasing, inventory management, and interfaces between SAP and third-party logistics systems. We are currently working on enabling email alerts from the third-party/drop-ship order fulfillment process when the shipment is either delayed or likely to be delayed. This will help our buyers to work proactively with the vendors to maintain service levels for our customers. In a future project, we plan to enable email alerts from a standard SAP goods receipt process to notify internal planning/manufacturing teams of the arrival of certain critical raw materials mostly provided by our customers.

Ram Angara

Ram Angara is an IT director responsible for enterprise level business systems at a large CPG company. He has more than 20 years of experience in the areas of business and information systems, including 12 years of hands-on SAP functional and technical experience. He has successfully managed and implemented large SAP projects in MM, WM, FI/CO, PP, and BI, including multiple SAP upgrades. Prior to this role, he worked as a consulting manager at BearingPoint in its SAP practice. He has a master’s degree in industrial management, a bachelor’s degree in mechanical engineering, and SAP certification.

You may contact the author at ramangara@gmail.com.

If you have comments about this article or publication, or would like to submit an article idea, please contact the editor.