cancel
Showing results for 
Search instead for 
Did you mean: 

LE-WM using scan to count a Product during a TO confirmation

Miguel_Nava
Discoverer
0 Kudos
132

Hello Experts:

I am working with a cliente implementing LE-WM, this company is implementing RF as well. They have a very unique requirement (It is my impression) They want to use the scanner in the RF to count the Products, let me explain. Let's say there is a picking TO being executed in RF (for 3 pieces), according to the confirmation profile, the Quantity needs to be confirmed, They want that instead of entering a 3 in the confirmation filed, they scan 3 diferent units of the Product. I have never seen a scenarios like this been implmented, further more I have concerns that it could impact negatively the performance, a lot of scanning events.

Please shar if you have any experience in a scenario like this.

Also share any toughts

Regards

Miguel Nava

Accepted Solutions (1)

Accepted Solutions (1)

jagdeepsingh83
Active Contributor
0 Kudos

As @DomDom mentioned - i do not think it is a standard solution --if it is a custom solution -- Possible solutions --(i have not done it personally so use at your own risk)

my basic question is why does your client want to count each product every time they pick ?--are they serialized? or for a specific reason?

1. Say you have 10 qty - instead create a TO for 10 qty --you can create 10 TOs -- this will impact performance or may cause performance issue 

2. You can custom solution --i mean -- create a Header and Item table --which creates --you can call Picking Lot or Pick Count --Use TO # to create this table and let user pick each qty and product (this will be saved on item level) and header will keep count how many items scanned --then once TO# qty is = equal to Header qty -- you can ask them confirm using RF --once confirm TO will confirm -- you can get required reporting too and also your item table can used to scan any additional fields that your client reason to scan 1 item at time 

3. Check with ABAPer if he only creates from interim table using user exit --that only commit / confirm the qty once user press say another button final confirm --

Brainstorm or challenge your client why he has this requirement and have he thought through how labor intensive it would be and what value add he is going to get.

 

DominikTylczyn
Active Contributor
0 Kudos

It is a standard practice in some warehouse operations. It is faster, more convenient and less error prone to scan each piece of a product, instead of counting them. Go to any supermarket and see how cash registers work. You really don't need to mess up TO creation or any fancy solution. All you need to do is to implement a custom screen for a standard RF transaction. It is easy to do and it will work. 

I implemented a similar scenario for a telecommunication company. It was used during SIM cards picking. That was several years ago, in the times of physical SIMs.

Miguel_Nava
Discoverer
0 Kudos
Thanks that is useful

Answers (1)

Answers (1)

DominikTylczyn
Active Contributor
0 Kudos

Hello @Miguel_Nava 

That looks like a quite typical scenario. It's exactly the same way of working as at a counter at any store.

SAP standard RF transactions don't work this way. However you can replace standard RF screen and build own scanning logic with User Exit Screens 

I would not worry about performance as product scans in your scenario will not post any data. RF transaction needs just to count scans.

Best regards

Dominik Tylczynski

Miguel_Nava
Discoverer
0 Kudos
Thanks Dominik, I meant that, is typical but not in Warehouses running SAP. My concern is about the the traffic generated, much more transaction going back and fort, and of course speed of processing will not be like scanning in the supermarket. Any thoughts?
DominikTylczyn
Active Contributor
0 Kudos

Hello @Miguel_Nava 

I implemented a similar scenario for a telecommunication company. It was used during SIM cards picking. That was several years ago, in the times of physical SIMs. It was on LE-WM in ECC. It worked like a charm. 

If this is a valid business requirement then I think you should go ahead and implement it. You will not have much more transactions, but dialog steps, as each scan needs to be processed with a dialog step, but it doesn't have to save anything in the database. 

In my opinion hardware sizing should be adjusted to accommodate valid business requirements.

Best regards

Dominik Tylczynski