Archived Clearing POG batches from the system

Status
Not open for further replies.
Joined
Jun 26, 2017
Messages
10
I've pretty much gotten a handle of how to pull batches and what not, but the one thing I haven't been shown is how to clear batches from the system. A few coworkers have tried showing me how to do it when I've pulled and there have been no items to pull in the locations the PDA has given me, but they just didn't explain it all that well to me.

If anyone knows how do it I would greatly appreciate the help because it would save me some time.
 
If you go to a location and the item isn't there, I was taught you have to LOCU the location.

Exit the batch -> LOCU the location -> Backstock everything in the location -> Go back the batch

At that point it'll recognise that the item isn't there and remove it from the batch and you can carry on pulling.
 
If you go to a location and the item isn't there, I was taught you have to LOCU the location.

Exit the batch -> LOCU the location -> Backstock everything in the location -> Go back the batch

At that point it'll recognise that the item isn't there and remove it from the batch and you can carry on pulling.

Your trainer is cooking metrics. That clears the error from the system as never being noted. You should hit M for M-delete. Leaders who encourage this aren’t leading a green process, they’re faking team member proficiency.
 
I was about to say, in the PDA you should be able to hit M then M-delete or X-skip and it should delete that part of the batch
 
I've always done it when my WACO conveniently isn't event here or the item isn't there. Never once gotten talked to about it. Also, on that topic, does anyone know the correct thing to do if you have to pull say maybe 5 of an item, but only 3-4 items are present in the waco? What do you do? I've always just said I pulled five to denote that that object has been completely pulled, since I've got none there. I assume that messes up counts/creates audits so there's got to be a better way.
 
Messes up sales floor count. If there’s only 4 and it wants 5.....you removed 4. Always how many you removed. You probably generate an audit location every time you do that because the system triggers thinking it had the wrong number there or it’ll ask if you pulled all (y/n)
 
Yep. And they can’t coach you for hitting m-delete. If they do, ask them to why that’s the right way and talk to them or the ETL about it. Don’t accept that coaching
Lol tell that to my store, where the STL, ETLs, and TLs all say to never m-delete.

I still do it of course, but I do it correctly so it doesn't come back to me.
 
Lol tell that to my store, where the STL, ETLs, and TLs all say to never m-delete.

I still do it of course, but I do it correctly so it doesn't come back to me.

Just out of curiosity, how do you do it correctly?

And to others about skipping... you can't really skip once you scanned the location and started scanning the items in that location. You can exit, wait a little and then come back into the batch.
 
Just out of curiosity, how do you do it correctly?

And to others about skipping... you can't really skip once you scanned the location and started scanning the items in that location. You can exit, wait a little and then come back into the batch.
You need to be 110% certain that the item is not there and that you have scanned every single thing in the location (even items that appear to be exactly the same), and make sure the location is neat and there's no chance of something getting put in there by accident (like items on an adjacent shelf falling over).

If you m-delete and the item is scanned later when someone else is pulling a batch there or the when audit goes there, it will show up on the BRLA report that you caused an error with m-delete.
 
You need to be 110% certain that the item is not there and that you have scanned every single thing in the location (even items that appear to be exactly the same), and make sure the location is neat and there's no chance of something getting put in there by accident (like items on an adjacent shelf falling over).

If you m-delete and the item is scanned later when someone else is pulling a batch there or the when audit goes there, it will show up on the BRLA report that you caused an error with m-delete.

That one would appear in the baffle section on the BRLA right? But then that list also shows who is using m-delete as well accdg to my TL. There is m-delete column in that report.
 
Yep. And they can’t coach you for hitting m-delete. If they do, ask them to why that’s the right way and talk to them or the ETL about it. Don’t accept that coaching

We don't coach for you hitting m-delete.... You get coached for not m-deleting correctly.
 
you could be seriously malevolent in your actions and break the tie to the planogram or just LOCU the backroom locations. yeah don't do any of that, really :D
 
Your trainer is cooking metrics. That clears the error from the system as never being noted. You should hit M for M-delete. Leaders who encourage this aren’t leading a green process, they’re faking team member proficiency.

They are also lazy for not fixing the bad behavior. They are just covering it up..
 
I get told to always LOCU instead of M-delete as well. I just smile and nod and continue to M-delete properly so errors can show up and can be properly fixed (if anyone ever looked..). 99% BRLA when near every batch I go to pull has an error? Bull

If the waco/shelf is entirely empty sometimes I will, rarely, LOCU it though.
 
Your trainer is cooking metrics. That clears the error from the system as never being noted. You should hit M for M-delete. Leaders who encourage this aren’t leading a green process, they’re faking team member proficiency.
No M-delete is evil. As I was told during 45 minute huddle yesterday. M-delete ruins location accuracy and causes problems with flexible fulfillment. It automatically creates baffles and ghosts. So they would prefer you not make errors and run these new weekly reports first. But if you know you created an error, its better to locu the error.

Why? because no one gets yelled at when its green.
 
No M-delete is evil. As I was told during 45 minute huddle yesterday. M-delete ruins location accuracy and causes problems with flexible fulfillment. It automatically creates baffles and ghosts. So they would prefer you not make errors and run these new weekly reports first. But if you know you created an error, its better to locu the error.

Why? because no one gets yelled at when its green.

You also have no idea who sucks at their job.
 
You also have no idea who sucks at their job.
I honestly think he gave up finding that because when he discovered the phasing out of the pdas is when he started all this. Also, I think he already knows.
 
I honestly think he gave up finding that because when he discovered the phasing out of the pdas is when he started all this. Also, I think he already knows.

Maybe the current round of this, but I've seen the cyclical appearance of "don't m-delete" for years and years.
 
Status
Not open for further replies.
Back
Top