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.
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.