Fergus Nolan

SAP ABAP / WM Consultant with RF

HOMEResumeAvailabilityContactRatesRF*GENIESAPconsole Ergonomics

 

SAPconsole Ergonomics

by Fergus Nolan

What must you do to provide a good user interface on a 16X20 or 8X40 screen?

The answer must be: every little thing you can think of

No stone should be left unturned in the quest to fix the RF ergonomics.

Error Message

A warehouse user often has to perform repetitive scanning operations. He/she won't be peering in the screen looking for error messages, so you must use the SAPconsole beep feature to make the RF gun beep in order to attract attention. It should beep at least twice, as a single beep means a good scan. The standard SAP message is unformatted and sometimes truncated on the SAPconsole screen. The first order of business must be to provide a replacement for the SAP error message with beeps.

Function Keys

There is a good degree of acceptance of standard usage of function keys. My only enhancements are to offer a compromise to settle the F2-Clear dispute, and to suggest that all function keys and button labels that are not active should be suppressed both in the display and in the GUI.

I've seen a smaller set of function keys used. Some companies restrict function keys to the four or five available on some RF guns, which works well. Of course, you have to reuse keys more which requires more training, but the advantage of not using shifted function keys is significant. Some users also like to use the page-up and page-down keys available on some guns instead of F6 and F7. The important thing is to have a standard and use it consistently.


The suppression of display is required by the fact that the SAPconsole button displays are only a reminder to the user that that function key is available. It is irrational to display the button label if the function key is not usable at that time.


This is easy to program by manipulation of the screen 'table', and using an exclude list while specifying the GUI status.

List Selection

Lists are a good way to avoid laborious data entry. Lists should use the F3-Exit, F6-Up and F7-Down (or page-up and page-dow) keys as appropriate, selection should be by entering any character (0 and 2 are favorites) in the selection field, and the only method of navigation in the list should be by the <enter> key. Pressing enter moves one line down in the list, and back to the top line if you are on the bottom. No other list navigation feature is needed, or should be supplied.

Hiding Fields and Keys

It is confusing to display fields that are not yet ready for entry. They must be hidden and deactivated. The current input field is the only one visible for entry, and the cursor is placed there, ready for input. Future input fields are suppressed in the display, and input fields that are already filled are made read-only, accessible only via the F2-Clear function key. This is easy to program by manipulation of the screen 'table' and setting the cursor.
I have found that one of the most vexing problems with RF console development is not so much the warehouse users, but the super-users who perform user acceptance testing on regular PCs. They love to move the cursor around with the mouse, and report all sorts of errors that can only be found with a regular SAPgui.
The policy of hiding fields that are not yet ready for entry actually reduces the coding effort as you no longer have to code for data entered out of sequence.

Data Entry

Scanning is best, that is what the guns are designed for. Providing license plates for everything in the warehouse helps here. It is worthwhile to spend a lot of effort to access data using fields that can be scanned. A favorite of mine is the selection of a Purchase Order in Goods Receipt by scanning the vendor UPC code and presenting a list of all open POs that have the material. Usually it's a short list, and it beats keying in the PO number.

Intelligent Defaulting. It is usually not necessary to waste screen space and user time entering data like warehouse number, plant, storage location etc. A flexible defaulting mechanismn almost always provide basic fields like this, plus the screen size.

Function keys. SAP is heavily dependent on function key entry. Be kind to your warehouse workers and spring for the enhanced guns that have unshifted function keys. The difference in user acceptance is well worth the small added expense.

Enter key. This is usually the biggest key on the gun and should be used when possible.

Numeric entry. Sometimes you just have to enter a count. The numeric keys are usually fairly big, so this is OK when necessary. Occasionally this can be avoided by using alternative units of measure, e.g. cases or inner packs.

Alpha and alphanumeric entry. The alpha keyboard on a gun is just plain nasty and it is worth going around the world to avoid its use. Many gun users carry the gun in their dominant hand and punch keys with their other hand, i.e. a right-handed user might be using his/her left hand to key data. Avoid alpha entry.

Visibility. Many sites enforce an upper-case-only policy for RF gun displays. Often it's pretty dark in the aisles and the upper-case display is often clearer.

User and Developer Training

User training is a critical element of any SAPconsole implementation. It is vital to user acceptance of the system. Adherence to these standards makes user training simpler, quicker and less costly.

Programmer training is part of the package. Providing reusable code to automate the routine housekeeping makes the programmer training job quick and easy.

Programming Considerations

Some experts claim that any decent ABAP programmer can program a SAPconsole screen after 20 minutes instruction. In principle this is true. The SAP function modules for TO and movement creation and updating, perform 90% of the heavy lifting in SAPconsole programs.

Things can get sticky, though. Try creating a TO for a delivery or a handling unit, and you have to delve into dozens of internal function calls and external performs, which are not so straightforward. And all bets are off if Handling Unit Management is in use. Putaway proposals are also non-trivial, and most developments will require some obscure feature that will require research with the trace tool and debugger.

There is nothing like experience. Programs written by programmers at various points on the learning curve can cost from weeks or months down to 36 hours or less to write, and quality can be spotty at any point in the learning curve. Having the right reusable library code for SAPconsole makes all the difference in accelerating SAPconsole development and quickly attaining top-quality ergonomics.

So your programmers need a little more than 20 minutes instruction. They need a library of SAPconsole code, an example of delivery TO creation and confirmation, an example of a goods movement program (e.g. goods receipt), an example of a cycle count program and an understanding of the ergonomic requirements. A bit more than 20 minutes. Most programmers can be really productive within a week.

The above ergonomic specifications, while being addressable by straightforward screen table, steploop and cursor manipulation code, do typically require hundreds of lines of code per screen to implement fully. This is intricate, error-prone code that might take many hours or days to write and unit test.

Any programmer worth his salt will try to come up with a reusable solution to the programming of the ergonomic requirements, and RF*GENIE is the only such package available. Most vendors libraries concentrate on repackaging the WM code, which is already packaged quite nicely, and ignore the ergonomics, which is the hard part.