I gave a look at the few docs on WM/RF and failed to find good info on the processes not covered by SAP WM RF functionality, be it ITS / telnet or whichever you use.

This is meant to be used as a reference on a few projects.

1. Putaway – COVERED
2. Picking – COVERED
3. Replenishment – COVERED
4. Relocation – NOT COVERED
5. Physical inventory – COVERED
6. 2-step confirmation – NOT COVERED
7. 2-step picking – PARTIALLY COVERED
8. Return of the goods from delivery (LT0G) – NOT COVERED

Now, let’s see which of those is likely to be covered by a development of some sort.
There is always a way to develop a transaction / RF screens which will do anything, but in my experience, these approaches are good.
I will only list the uncovered processes and their development approaches.

1) Relocation:

As simple transaction as possible, 2 screens + 1 screen for messages.
Depending on the use of SU or not:
screen1- scan SU, or scan MATERIAL / BATCH
screen2- enter relocation qty and san the destination bin
actual processing- after screen 3 and before screen 4. You can use Function Module L_TO_CREATE_SINGLE
screen3- for messages – error and success message display
You can also implement less screens if you want to enter all the details on one screen,
but sometimes it is better in practice to show the scanned SU (quant) contents so the WH worker
can check if that is the right SU (or quant) to relocate to another bin.
Note: It’s good to allow relocation to another storage type, not nly bins in one storage type.
That might be tricky because one more entry field on RF is not a good option. In this case,
good planning can work miracles. If you don’t have duplicate bin coordinates in your entire
warehouse, you will know by only scanning a bin, from which storage type it is, and therefore
won’t have to enter the storage type itself on the RF screen.

2) 2-step confirmation:

Achievable, but requires much ABAP work on developing the transactions for 1st and 2ns step confirmation.
I will not go into detail on this, since it requires too much ABAp work and I would recommned if you need to use
2-step processes with RF to go with 2-step picking instead of confirmation.
Of yourse in some specific situations  you will require exactly this process.
Why would I recommend 2-step-pick instead of 2-step-conf?
It’s because you also have a record on both of the users/dates-times of confirmation of the both steps.
So you can monitor the work in your warehouse in more detail, and by individual steps.
So go with 2-step-picking unless you really require the functionality of 2-step confirmation.

3) 2-step picking:

In this case, much easier than the previous, you already have support for 1st step.
So you only need to develop a transaction / RF screens for 2nd step in the picking process (e.g. 200 => 916).
2 step picking makes sense mostly in cases with SU / HU management.

Possible transactions steps:
screen1- scan SU
screen2- list of quants on SU and confirmation
actual processing- with t-code L_TO_CREATE_SINGLE or L_TO_CREATE_MULTIPLE
screen3- mesages (success and error)
Note: what you need to take care of is if you have delivery grouping and using LT0E, you might have
the same group SU/HU for more deliveries/customers. (e.g. more customers/delvries picking zone => to 1 pallet)
You might use screen 3 for an info on this too if you have grouped TOs. Facing this depends mostly on your previous
processes – prior to 2nd step.

4) Return from delivery – lt0g:

As simple as possible, again. Possible steps:
screen1- scan/enter the delivery number and material.
screen2- check the qty confirmed on the delivery, and allow qty entry only up to that qty found on the delivery item
actual processing- process by L_TO_CREATE_SINGLE – if you have SU management active you will also have a SU printout as a result
screen3- message handling (error , success)
Note: While creating a TO for the return, see if your client requires return to the original bin or using the putway strategy. Apply the desired technique.

To report this post you need to login first.

2 Comments

You must be Logged on to comment or reply to a post.

    1. Raghu Govindarajan

      Mihailo Sundic

      When deciding on developing a custom RF transaction, you should take a lot more into account than just does the process exist or not in SAP. As an example, with Put away, some of the questions you have to ask are…

      1. Is the user going to be system directed or not
      2. will the user have any paperwork in hand (one user working on one receipt)
      3. what is the user scanning initially… for example if you want the user to scan the PO# to start working on all the related put aways, or is it an inbound delivery number? If you are scanning just a single TO, it may not cover the entire truckload – what are you going to do then?
      4. Do you want the user with the RF device to execute the Goods Receipt too – could that be covered on the initial scan?

      … and that is just to pull up the TO data with which to do the put away. There are several other steps from the SAP version that could be automated and over the course of a day, save the users an hour or more worth of data entry time – or safety because they are not pecking at a small screen on their forklift. There is no one good design, every business is different. Every single field or lack of, could make a large difference in operational efficiency on floor – let the warehouse operations direct your design.

      BVDV Prasad

      I have covered RF device selection here LE-MOB Which RF Hardware to choose

      Do you think it would be useful to move this to a Blog?

      (0) 

Leave a Reply