However, users have been demanding transactions designed to achieve higher efficiency in logistics operations that go beyond what these standard functions offer. This has paid rich dividends in terms of automating and improving receiving and shipping processes, reducing errors due to elimination of manual data entry processes, and achieving better visibility of materials in warehouses by crisp labels and bar codes. The price for these dividends is the work required to write custom transactions.

If the standard SAPConsole suite does not meet user requirements (which is happening increasingly), you can create your own RF-enabled transactions that recognize RF devices. These need to be custom-written within ABAP if users require changes, integrate multiple transactions within one transaction, or need additional screens. Success depends on judicious and intelligent use of logic, SAP call routines, and standard SAP transactions to meet the user requirements.

I recently participated in two projects for Fortune 100 companies working with R/3 logistics modules where the RF and bar-coding projects were done with great success. They involved multiple production plants and distribution warehouses located over a one- to three-square-mile area and in warehouses of 250,000 to 500,000 square feet. The scope involved MM, WM, and some PP functionality. The logic used to customize the transactions is generally available in SAP R/3 in the form of call functions.

What follows are the types of transactions we had to RF-enable along with advice for customizing a few important transactions. If you are new to RF scanning, you might want to read the sidebar, “How RF Scanning Works."

What Transactions to RF-Enable?

You can enable transactions in the MM, WM, IM, LES, SD, and PP modules for RF scanning using bar-coding. You typically do so in plant and warehouse environments. These transactions are typically high-volume and need to be done in real time. Examples include:

• Sales & Distribution: Customer order ? delivery ? pick list ? pick list confirmation ? post goods issue
• Procurement (purchase order): Goods receipt (GR) for purchase order ? convert transfer requirement (TR) into transfer order (TO) ? TO confirmation
• Procurement (stock transport order): Create outbound delivery ? GR against outbound delivery ? convert TR into TO ? TO confirmation
• Physical inventory (PI)/cycle counting (within IM): Create PI document ? freeze book balances ? enter count ? post differences within IM
• PI/cycle counting (within WM): Create PI document ? activate document ? enter count ? clear differences within WM

Some companies train users to perform transactions like these manually on PCs within a company, plant, or warehouse. These users are typically not located where the actions are actually performed. Operators/users tend to record these transactions in logs, on worksheets, and so on to be performed later within SAP, typically after a lapse of two to 48 hours, depending on factors like company practices, plant layout, or warehouse operations. Manual transactions are also error-prone with omissions and incorrect data entry. RF-enabling these transactions allows you to capture the data in real time at the scene of the action. To further improve data-entry accuracy and speed, it is useful to put the transactional data into bar-code format.

How RF Scanning Works

The data collection process using RF scanning typically works as follows: RF terminals and scanners are used to scan information, which is captured through multiple networked access points in each plant or warehouse. An access point is a wireless data-capture point that “talks” to SAPConsole or a middleware system. The scanning takes place at actual bins or on the production line using a handheld wand, wedge, or RF scanner. The RF scanner can also be forklift mounted if the transactions are executed from forklift trucks.

The information may be captured using any number of means, such as scales, time clocks, or weighing platforms. The information is processed through telnet text screens in SAPConsole (Figure 1), which acts like a translator and processes data within R/3 using function modules and IDocs. The output information can be printed on various types of output devices in the form of bar codes: network printers, portable printers, bar-code printers, etc. The business logic is within R/3, and the transactions are built using familiar technology (ABAP). If you can use a standard transaction, no additional programming is needed.

Figure 1

SAPConsole is a simplified SAPGUI. Notice the familiar layout of the fields in the SAPConsole screen (top). For example, it has a field for line item next to Purchase order, as with SAPGUI (bottom).

Prior to R/3 4.6B, the only way to RF-enable certain transactions was to use middleware, a system with its own logic and data repository that sits between the front and back ends. From 4.6B onwards, SAP introduced SAPConsole to allow the use of certain transactions within MM and PP in an RF application (Figure 2). Transactions were added in R/3 4.6C. Table 1 lists the standard transactions currently available for mobile entry within SAPConsole. 

Goods receipt (GR) and goods issue (GI)	Pack and unpack
GR/GI: selected by delivery GR/GI: selected by handling unit GR/GI: selected by material staging area GR/GI: selected by shipment GR/GI: selected by other criteria GI: selected by group	Pack handling unit Unpack handling unit
Putaway	Inventory
Putaway Putaway: selected by storage unit Putaway: clustered Putaway: selected by transfer order Putaway: system-guided Putaway: selected by delivery	Executing storage bin count Storage bin count: system-guided Executing storage unit count Storage unit count: system-guided Posting changes
Interleaving	Inquiries
Interleaving: selected by storage unit Interleaving: system-guided	Inquiries: stock overview Inquiries: handling unit
Picking/replenishment	Load and unload
Picking: selected by transfer order Picking: selected by delivery Picking/replenishment: system-guided Movement: selected by storage unit Pick and pack Pick and pack by delivery	Load/unload: selected by shipment Load/unload: selected by delivery Load: system-guided Load: inquiries Inquiries: load by shipment Inquiries: load by delivery Inquiries: load by handling unit

Table 1 Standard suite of SAP R/3 4.6C mobile-entry transactions

With SAPConsole, the information is being scanned into the fields to replace manual data entry. The standard SAPConsole transactions use the same logic as in SAP R/3. The problem is that users have high expectations for the layout of the small RF scanner screen, which is typically 20 by 16 characters. They also do not want to see the fields they do not use. The transaction itself may have to be enhanced by linking multiple transactions, say the IM transaction for goods receipt, MIGO, linked to the transaction for creation of a transfer order within WM with reference to a material document, LT06. Another consideration is that the users may want to see the data prefilled, or they may want to scan one big scan code and expect the different fields to be separated (parsed) using logic within the transaction.

You will need to modify standard transactions for these situations to reflect the fields, captions, and additional screens that are required to meet user expectations. Long and arduous work to modify the transactions has been the case for every project on which I have been involved.The goal of any RF and bar-coding project should be to increase efficiency of material management, warehouse, and production processes. You accomplish this through ease of use for shop-floor personnel (no intimidating PCs) and increased speed and accuracy of data entry/data collection by elimination of human error. This results in improvements to business processes such as goods receipt, shipping, and cycle counting. In addition, it greatly improves data integrity. Automation also allows you to reduce manpower.

The following factors help you decide which transactions to RF-enable:

How many times is a transaction — say, putaways in a warehouse for purchase or stock transport orders — performed in a day? Some warehouses may receive up to 300 purchase order (PO) line items and 500 to 600 containers/boxes per day in a warehouse, which is difficult to handle manually. Goods receipts from production/process orders could also be of similar magnitude.

How important is the transaction? For example, customer delivery is much more important than goods issue to scrap and therefore a better candidate for RF enablement.

Does the transaction need to take place in real time? Picklist confirmation for customer deliveries as goods issue, for example, must enter the system as soon as it occurs and is a candidate for RF enablement.

Does the transaction need to be captured at the scene of the action? Examples of RF-enablement candidates include the picking from a warehouse bin and quantity for an outbound delivery. Otherwise, you need to record them in a log for later input into R/3.

What are the PC skill levels of the operators performing various transactions? To avoid training, you might decide that materials handlers in your warehouse should use only RF scanners and not PCs.

What is your scale of operations? In big plants or warehouses, it might be impractical to handle hundreds of multiple transactions unless you achieve automation through RF enablement.

What to Bar-Code

By placing the information needed for RF-enabled transactions into bar codes, you can more easily and quickly capture that information. Consider bar codes for the following items in a plant or warehouse:

• Material containers, boxes, drums, etc. with bar-code data for materials, batches, quantity, units of measure (UoM)
• PO with PO number, material numbers, quantity, UoM
• Production/process order with order number, material numbers, quantity, UoM
• Warehouse storage types and bins on racks, hanging signs, etc.
• TOs in warehouses
• Picklists for customer deliveries
• Material staging lists for production
• Labels for raw materials and finished goods
• Shipment pro numbers/tracking numbers

Key Custom RF-Enabled Transactions

The following transactions were RF-enabled via customization on my projects. These transactions are popular and RF-enabled in most RF projects.

• GRs for POs
• GRs of PO materials without material number (text item)
• GRs without PO, say for reuse materials (for example, the plastic sheet production process generates plastic waste that is ground and moved into stock)
• GRs for purchase/process orders
• Transfer postings — for example, between different storage locations within a plant
• Cycle counting (physical inventory) processes, say for raw materials and finished goods
• IM stock overview inquiries

LES/WM

• Production order putaways in warehouse
• PO putaways in warehouse
• GRs for outbound deliveries — say, stock transport orders delivery putaways
• Warehouse bin-to-bin moves
• Picklist confirmations for customer deliveries
• Post goods issues for customer deliveries and recording of shipment pro number/tracking numbers for customer deliveries
• Cycle counting (physical inventory) for raw materials and finished goods
• Warehouse bin-to-bin moves
• WM bin stock inquiries

PP/PP-PI

• Production order confirmations (stage/operations)
• Downtime reporting on production centers/resources
• Production/process order component consumption

Error message inquiry (for investigation):

• Error messages inquiries

Some of these transactions are more straightforward to RF-enable than others. You might find the following information useful as you design the more troublesome transactions and try to understand their logic:

Goods receipt for a PO for raw materials. This transaction is used to receive the materials from POs and place them in warehouse bins in a single transaction. All the items for a PO are retrieved, if open. Once all of the data has been pre-edited, two SAP transactions are called: MIGO/MB01 (post goods receipt for PO, movement type 101) and LT06 (create TO for material). This TO is automatically confirmed within WM configuration.

The IM transaction MB01 is linked with WM transaction LT06, so that if material from a PO is received into IM stock and the linked TR created, it is converted to a TO in WM for placing the material in a bin (Figure 3). The TO is confirmed automatically as per the WM movement type configuration. The information is scanned from the PO and moved from screen to screen using the F2 key. On completion of screen 6, the material is available in a WM bin. A transaction like this may take a trained material handler 15 to 30 seconds to complete. The quantities, storage types, and storage bins are scanned with an RF scanner. Figure 4 shows an example of a raw material label.

Figure 3

Example of a GR for a PO transaction using an RF scanner. IM transaction MB01 is linked with WM transaction LT06. In this transaction, the screens have been modified; notice the captions like Success and Information.

Figure 4

Example of a raw material label. Notice the human-readable text and bar codes for different fields on the raw material label. It is also possible to combine the bar codes for different fields such as material, batch, and quantity into one long bar code, which can then be parsed within the transaction (not shown). Likewise, a finished goods label contains different fields, as needed for scanning.

GR for a production/process order. Typically, this process is done by production workers on production lines, in production centers, and so on. This is a high-volume transaction. A GR for a production order is done automatically as a result of confirmation of the production order, which creates a TR. Production order putaway transactions refer to the TR, which is scanned. The transaction processes data based on the TR number. Once all the data has been pre-edited within the transaction, transaction LT04 (create TO from TR) is called. The TO is automatically confirmed within the WM configuration. The material is now available in the bin.

Warehouse picklists for customer deliveries (and stock transport orders). The picklist for all customer deliveries (and stock transport orders) is printed and sorted by delivery number. (It could be sorted by other criteria such as warehouse storage types or bin numbers.) The picklist contains multiple line items (TO items) representing picking from different bins (Figure 5). The confirmation on the picklist is done item by item by scanning the bar code for TO and TO item number. Once all the data has been pre-edited, the program calls transaction LT11 (confirm TO item). An experienced user can confirm a picklist with 200 items in 20 to 30 minutes.

Figure 5

Picklist for customer deliveries in a warehouse. Note the printed information for material, quantities, storage types, and bins. You also have references to sales orders and line items for each pick item. One bar code (Transfer Order/Line Item) is scanned. Within the transaction, the information is parsed (separated). After that quantity is scanned, the quantity is verified within the transaction.

GR from stock transport orders. The prerequisite steps for this transaction are delivery creation for a stock transport order (on a PC), picking confirmation, shipment pro number, and post goods issue from supplying plant. In the receiving plant, the delivery putaway process is done with reference to outbound delivery from the supplying plant. The delivery items are processed if the goods movement is still open. Three SAP transactions are called: MB01 (create material document), LT06 (create TO), and MBST (reversal of material document if a TO is not created for any reason, like master data errors).

Recording of shipment pro number (tracking number) on customer deliveries. This transaction updates the shipment pro number in the header text of a delivery number. It is also preferable to automate post goods issue against delivery within this transaction. The only edit done prior to going to the call transaction is to validate the delivery number and to validate that a carrier name has been entered. The shipment pro number and carrier name are accepted as scanned. These two fields are combined and placed in the header text. Once all the data has been pre-edited, the program calls transaction VL02N (change a delivery note). This completes the goods issue posting for delivery. This number is used by various tracking systems.

Bin-to-bin movements within the warehouse. This transaction moves materials within the warehouse, and it uses transaction LTO1. The bin storage type and storage bin information is scanned from the bin racks, and material information is scanned from the materials labels, thus reducing a lot of data entry. If the material is batch-managed, the user must enter a batch number. If the user enters a batch number and the material is not under batch control, the user receives an error pop-up screen to remove the batch number. Once all the data has been pre-edited, the program calls a function to create the TO. The TO is confirmed automatically within WM configuration.

Physical inventory for a warehouse bin. The physical inventory process within WM typically involves a number of manual transactions, which is time-consuming and slow. The physical inventory process with RF scanning (Figure 6) is automated by combining four transactions: LI01 (create physical inventory document), LI02 (activate inventory document), LI11 (enter count for materials with reference to physical inventory document), and LI21 (clear differences within WM).

Figure 6

The physical inventory process with RF scanning. You scan each material (screens 2, 3, 4, ...15) in the bin (screen 1). When all material scanning is done, the system compares all materials in the bin with those scanned and warns if a material is missing (screens 16 and 17). If you want to enter new material, due to omission, for instance, you can scan new materials (screen 18) exactly like in screens 2 to 14. After all materials are entered, press the F3 key to conclude the physical inventory process and automatically adjust the differences in quantities of various materials in the bin and post the differences within WM.

The bin inventory is adjusted at the WM level. The differences within IM are cleared in a separate transaction on a PC. Companies typically prefer to leave this transaction a manual process as some inventory write-offs and write-ons have consequential financial implications. This transaction allows scanning of materials with the quantity by scanning of material labels. It also has the following additional features: All materials in a bin must be counted. If not, the material quantity without the count is considered to be zero. The system prompts for all uncounted materials. Also, if a material is counted but not present, it is treated as a new material in the bin.

IM stock inquiry. This transaction displays inventory balances by plant and storage location within a plant. Transaction MMBE is used, and the stock is shown by stock category, special stock (such as customer stock with different sales order/line item numbers — customer specific stock “E”), batch numbers, and so on. The information is laid out on three screens: IM Inventory is the first screen, Location Totals is the second screen, and Plant Location Details is the third screen.

WM bin stock inquiry. This transaction is used to display the bin stock within WM. It displays inventory balances for a material within a warehouse. The bin stock is displayed for a warehouse using transaction LS24.

Error message inquiry. This is an inquiry transaction that allows the RF user to see the long text for an R/3 error message. If R/3 returns an error code during transaction processing, the RF process displays the message ID and number to the user on a pop-up screen. The user can then use this transaction to get more information about the error. The program reads the T100 table in R/3.

Vijay Garg

Vijay Garg, PMP, has more than 14 years of SAP project management and implementation experience with Fortune 500 companies in the high-tech, chemicals, CPG, and engineering industries using various SAP Business Suite applications as well as SAP APO. Prior to working in SAP, he had vast experience in the engineering industry, including software development and applications.

You may contact the author at vgarg@crestron.com.

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