An operator moves one pallet from one bin to another. Ten metres, maybe fifteen seconds of actual walking. Before the system lets them confirm it, they scan four barcodes: source HU, source bin, destination HU, destination bin.
Multiply that by every internal movement, every shift. The scanning takes longer than the movement.
Nobody chose that. It is what the system does by default, and it stays that way until somebody tells it otherwise. This post is about the setting that decides which fields an operator has to scan — and how to cut four down to two without losing the check that actually matters.
What the operator scans is a configuration decision, not a fact of life
In the previous three posts we worked our way inwards: which transactions a worker can reach (the RF menu), how to build that menu per role (Personalization Profiles), and what fits on the screen once they get there (the Display Profile). This post is the next layer in: of the fields on that screen, which ones does the system insist on having scanned before it accepts the confirmation?
SAP calls these verification fields. They are the fields the RF framework asks the operator to confirm — usually by scanning a barcode — when confirming a warehouse task. A detail worth knowing before you go looking for them on a screen: in the standard RF screens, the verification field sits to the right of the field it is verifying. The left field shows what the system expects; the right one is where the operator proves it.
Typical verification fields on a confirmation screen:
SrceHU— source handling unitSBin— source binDestHU— destination handling unitDstBin— destination binProd— productBatch— batchA Qty— actual quantity
Which of them are active is not fixed by the transaction. It is governed by a verification profile, and that profile can be different for different processes running through the very same RF transaction.
Why four scans for an internal movement is the wrong default
Scanning exists to catch mistakes. The question is which mistake you are actually trying to catch.
For an internal movement of a full handling unit, the HU is the thing that carries the identity. If the operator scans the correct source HU and the correct destination HU, the movement is verified: right pallet, right place. The two bin scans confirm something the HU scan has already established, because the system knows where that HU is and where the task says it must go.
Compare that with picking, where the calculus is completely different: there you are taking part of a quantity out of a bin, so bin, product, batch and quantity all carry information that nothing else confirms. Same RF framework, same warehouse, opposite answer.
That is the point of the verification profile: it lets the two processes use different rules instead of forcing the strictest one on everybody.
The two-step configuration
Setting this up is always two moves, and skipping the second is the usual reason people say «I created the profile and nothing changed».
Step 1 — Define the verification profile
Create a profile and list the fields it should verify. For the internal movement case that means source HU and destination HU, and nothing else. Systems normally ship with a couple of profiles already in place, so check what exists before adding a new entry — you may find one that already matches what you need.
Step 2 — Define the determination
A profile on its own does nothing. The determination is what tells the system when to apply it: in which process, in which warehouse operation. This is the step that makes the same RF transaction behave one way for an internal movement and another way for a pick.
Two things are worth knowing here. First, the fields used to determine the profile are themselves configurable, along with the sequence in which the system evaluates them — so what you see in your system depends on how that determination was set up, and it is worth looking before assuming. Second, once a verification profile is determined, it overrides the verification fields defined in the RF transaction. The profile wins. That is exactly what makes it useful, and also why a profile determined too broadly can quietly change behaviour in processes you were not thinking about.
Testing it without guessing
Create an ad hoc handling unit warehouse task with /SCWM/ADHU, then confirm it on the RF device and look at which fields the screen asks for. If the determination is right, the confirmation screen now asks for the two HU fields and stops there.
If it still asks for all four, the profile is almost certainly fine and the determination is not matching — that is where to look first, not at the profile you just built.
Back to the four barcodes
Two scans instead of four, on a movement that takes fifteen seconds, repeated across every internal movement of every shift. The verification that mattered — right pallet, right place — is still there. What went away was the part that confirmed something the system already knew.
Quick Reference
| Where | Transaction / IMG | What you do there |
|---|---|---|
| Verification Control | IMG · Extended Warehouse Management · Mobile Data Entry | Define the verification profile and its verification fields |
| Warehouse-specific verification determination | IMG · Extended Warehouse Management · Mobile Data Entry · Verification Control | Decide in which process and operation each profile applies |
/SCWM/ADHU | Transaction | Create an ad hoc HU warehouse task to test the result |
/SCWM/RFUI | Transaction | Confirm the task on RF and see which fields are actually requested |
A note on names: SAP’s own documentation is not fully consistent here — you will find the same object called a verification profile in most places and a validation profile in others, and the community uses both. They refer to the same thing.
Related Reading
- Why Every RF Menu Looks Different — Presentation and Personalization Profiles
- How to Build a Personalization Profile in RF, Step by Step — the menu-level customizing
- That Field Isn’t Missing. It’s Not Configured. — Display Profiles and the RF Screen Manager
Part of the RF series. ← That Field Isn’t Missing. It’s Not Configured. · Next: how work reaches the operator in the first place — queues, resources and resource groups.
Deja un comentario