Logistics Global Issue

Joined
Apr 13, 2013
Messages
569
So there was a “global issue” overnight. Or rather that’s what we were told, or maybe it was the night before meh don’t really matter. IIRC there’s going to be another attempt to fix it sometime today. But any who…

Our toy aisle was unlocated, then automagically relocated but not all of it. Long story short 4 and a half pallets of toys were pulled. And the overseers wanted it all pulled and pushed within the poor TMs 4 hour shift.


Go team!!
 
Joined
Aug 14, 2018
Messages
385
I call BS! Someone messed up and this was their way to blame the system. Or! This is a setup to get rid of TM's that couldn't get "their work" completed during their 4 hour shift. Think about it!
 
Joined
Apr 13, 2013
Messages
569
  • Thread Starter Thread Starter
  • #4
yeah it is BS. that aisle has been messed up for was long as we've been E2E/Store Modernization/DBO. I think that when the sole remaining Backroom TM did an Empty Location report on the aisle and roughly 50% was not located a "Global Issue" was the Leadership's response.

BWHAHHA nope. More like no one has been doing their jobs correctly or something along those lines.
 
Joined
Jul 14, 2016
Messages
1,537
We had something similar happen few weeks ago where a bunch of stuff was scanned properly to locations in the backroom but the system didn't register many of them which we were unaware of until later. So this week I had to visually walk the aisle to find my 8 missing DPCIs for an endcap. They were all there, none located. Luckily they were all open stock items and easy to recognize.
 
Last edited:

GreasyGary

Presentation/Signing
Joined
Nov 9, 2017
Messages
208
Something does seem to be going on with the stowing. I was backstocking some stuff the other day and I found a couple of eaches of a product I had already stowed, but when I scanned it, it said there were none located.

I had just located it a few minutes prior so I KNEW I didn't forget to scan it in or anything. So I went and checked everything else I had stowed and found one other DPCI that acted like it hadn't been scanned in. So that was 2 DPCIs out of probably 25 that I stowed that just didn't take for whatever reason.

Also, maybe related, maybe not.. I've noticed that when I stow something, it will show a ridiculous "in back" count. Like, before I stow, there will be 0 in back, I'll stow 5 and it will say 256 in back. But if I scan the item again, it correctly shows 5. So it seems to just be a display error after stowing, but it's still troubling, especially given the other issue with items seemingly coming unlocated for no reason.

Another weird thing, I was running a SFS batch and checked an item in MyWork, it said we had -4 in the back. In a location for something that I had previously backstocked. In this case, no matter how many times I refreshed, it still had that negative number. So I had another TM enter the DPCI and it showed 0 in back on theirs. Then when i refreshed mine, it was no longer showing the -4.

So yeah, something very weird is going on with MyWork and the backroom. Which is kind of scary because that points to some sort of corruption/data integrity issue and that can get really nasty really quickly.
 

GreasyGary

Presentation/Signing
Joined
Nov 9, 2017
Messages
208
I agreed. There is something going with stow & locations. Same thing happened d at my store.
I had originally thought that all the unlocated product I was finding in our backroom when I was pulling POG fills was just because of the DBOs being new to backstocking or rushing through it. But after that, I wonder if this isn't an issue that's been happening for quite some time now. It's been several months since I first started noticing large amounts of unlocated stuff in the backroom.

If that's the case, it's going to be a mess. I always tell the ETL-LOG whenever I find a large amount of unlocated backstock, but he seemed to not really care. Really, he's lucky that we aren't still pulling with the PDAs. If people had no idea what they were pulling for and just randomly scanning everything trying to find it, that unlocated stuff would quickly kill the BRLA. Of course, that comes with the tradeoff that it would actually become located then and could fill the floor instead of the current system of perpetual outs since the system thinks we have it and it's just not selling.
 
Joined
Apr 13, 2013
Messages
569
  • Thread Starter Thread Starter
  • #11
So there is a chance me leadership was being honest? Well that’s a shock to the system. But even more troubling to be honest.
 
Joined
Apr 13, 2013
Messages
569
  • Thread Starter Thread Starter
  • #12
Really, he's lucky that we aren't still pulling with the PDAs. If people had no idea what they were pulling for and just randomly scanning everything trying to find it, that unlocated stuff would quickly kill the BRLA. Of course, that comes with the tradeoff that it would actually become located then and could fill the floor instead of the current system of perpetual outs since the system thinks we have it and it's just not selling.
If you STOd it with a PDA it was in the location you scanned it into. The PDAs were not killing BRLA if anything they were keeping it from the hellscape that we are finding ourselves in at the moment. Pulling to the picture means what’s not located in the waco will stay unlocated.

The PDAs worked. The Zebras look pretty and occasionally don’t totally mess everything up. The only thing that is semi good about the zebras is that we don’t pay licensing fees to Microsoft, as far as I know.
 
Joined
Jan 23, 2019
Messages
377
Something does seem to be going on with the stowing. I was backstocking some stuff the other day and I found a couple of eaches of a product I had already stowed, but when I scanned it, it said there were none located.

I had just located it a few minutes prior so I KNEW I didn't forget to scan it in or anything. So I went and checked everything else I had stowed and found one other DPCI that acted like it hadn't been scanned in. So that was 2 DPCIs out of probably 25 that I stowed that just didn't take for whatever reason.

Also, maybe related, maybe not.. I've noticed that when I stow something, it will show a ridiculous "in back" count. Like, before I stow, there will be 0 in back, I'll stow 5 and it will say 256 in back. But if I scan the item again, it correctly shows 5. So it seems to just be a display error after stowing, but it's still troubling, especially given the other issue with items seemingly coming unlocated for no reason.

Another weird thing, I was running a SFS batch and checked an item in MyWork, it said we had -4 in the back. In a location for something that I had previously backstocked. In this case, no matter how many times I refreshed, it still had that negative number. So I had another TM enter the DPCI and it showed 0 in back on theirs. Then when i refreshed mine, it was no longer showing the -4.

So yeah, something very weird is going on with MyWork and the backroom. Which is kind of scary because that points to some sort of corruption/data integrity issue and that can get really nasty really quickly.
I accidentally entered 40 for how many of an item I was backstocking instead of 4. I tried removing them via "Take" on mywork but it didn't recognize it as being stored in that location. Scanned the item again and that location was completely gone
 
Top