He is correct. For whatever reason errors are only detected in generated batches. The only down side to not STOing first is SUBT will not detect clearance. I however find that to be a fair trade off for the time saved not STOing first. You can in fact test this theory by SUBTing 9999 without STO an item from a fill group you do not normally see into a Z location. Then check the next weeks DTK report for a error in the fill group in that area. I think many of us have tried this and gotten the same results, no error.
Archived Just dosen't stop pulling
- Thread starter rugrat
- Start date
- Replies 73
- Views 11K
- Status
He is correct. For whatever reason errors are only detected in generated batches. The only down side to not STOing first is SUBT will not detect clearance. I however find that to be a fair trade off for the time saved not STOing first. You can in fact test this theory by SUBTing 9999 without STO an item from a fill group you do not normally see into a Z location. Then check the next weeks DTK report for a error in the fill group in that area. I think many of us have tried this and gotten the same results, no error.
- Joined
- Jun 8, 2011
- Messages
- 162
I understand your confusion, I really do. If you scan an item, that wasn't in location while in a batch, it causes an error, now logically doing the same thing while using SUBT should cause an error, but it simply DOES NOT. I promise you, it does not. Target's system doesn't generate the error while using SUBT, even if Target themselves thinks it does. Maybe it's a bug in the system, maybe their "resetting the accumulator" guide is misinformed, but it just doesn't work that way. Now, you can cause something while using SUBT that will lead to a baffle, when/if the mistake is found in a batch.
Target is just a simple retail company, with their logistic system and other numbers, reports, and scores, they make it seem like rocket science. They don't have headaches like this at Walmart. Take product off a truck, put product on the salesfloor, if all product doesn't fit, store it in a stockroom.
- Joined
- May 15, 2011
- Messages
- 1,845
Was about to suggest this purpose-built test. My backroom TL and I did this, with the LIQR fillgroup, location Z. Just a random margarita mixer SUBT'd in without STOing first. Next week and the week after, the LIQR group was a solid green bar on the DTK report. We showed it to the leadership in the building and it was decided then and there that it was value-added to save the time by not STOing first, and we've been doing it ever since.
Like others have said, technically this activity fits the criteria for making an error, and it certainly would if it were done while working a pull batch. But the standalone SUBT app is just not included in the error reporting. The system sees it happening, but turns a blind eye to it, per se.
Again, as it's been mentioned, the only reason the Resetting Accumulator guide on Workbench states to STO first is because STO acts as a filter for items that are Clearance, MIR, or Challenge. Obviously, SUBT doesn't throw these prompts because the system already thinks you're removing items from the stockroom...
- Joined
- Jun 8, 2011
- Messages
- 33,855
Whew!
- Joined
- Jun 21, 2011
- Messages
- 704
I went full scale this week. We are Pfresh store. I STO'd PRO1 and PRO2 fillgroups on 2 FDC trucks this week, using ONLY the SUBT function. I am 100% sure that BRLA will be unaffected. I've been onto this backroom secret for some time and I'm glad that ya'll are here to better explain!
Rock Lobster
Executive Team Leader
- Joined
- Jun 11, 2011
- Messages
- 1,428
Yes... when you look at HOW these functions change the accumulator, it makes sense as to why it doesn't matter! Basically, the reason you Subt9999 is to "satisfy" any lingering values in the accumulator! There is no way to tell how much the accumulator THINKS it needs on the salesfloor... sometimes its off by 50, sometimes its off by 5000! We use 9999 because its the largest value you can enter... Will 999 take care of a majority of the issues you come across? Yes I doubt its off by more than 1000 very often, but sometimes it is and thats when just 999 won't be enough to get rid of those values...
- Joined
- Jun 8, 2011
- Messages
- 33,855
Let me guess, bts backstock!
frugm, I think you've said this more eloquently than I ever could. Burning batches is a sin. Team members improperly creating EXFs or OUTS can cause this same problem, as both affect the accumulator. GIGO. Haven't heard that since college programming days.
I think your RSCH idea would work fine, except for its negative impact on RSCH w/ Loc % on the DTK. An EXF could accomplish the same thing without affecting your scores.
- Joined
- Jun 8, 2011
- Messages
- 33,855
at my store, the accumulator is way messed up. it didnt help when the backroom locations dropped, either. we are working very hard on resolving those issues. brtl did have a chat with some of the new br tm's who were caught burning batches.
so I had an interesting "glitch" with the accumulator today, I was backstocking some stuff the closing team and a vendor had pulled off of an endcap in hardlines the night before. They forgot to push it to the remaining home locations, we just "hoped" that they had done the right thing and pushed it to the remaining home locations. But we were pressed for time because our truck was big, so we backstocked and subt9999'ed everything without checking it. well, as I was backstocking some of this stuff, it got challenged (two out of about 25 DPCI's did). Now, neither of these two DPCI's were on our truck, they were last received earlier this month, and they got challenged because they were both on a checklane endcap. one dpci entirely went out (and exactly filled the salesfloor) and one sent 4 to backstock (out of an on-hand of about 50). Now, before I backstocked it I had to break the tie to the old endcap (the vendor could break the tie himself).
My question is how did the accumulator know to challenge these two items when they weren't even on our truck and it was regular active product? Does it do the math of "On-hand < or = salesfloor capacity = challenge" for all items at all times? or only for items expected to be received that day?
My question is how did the accumulator know to challenge these two items when they weren't even on our truck and it was regular active product? Does it do the math of "On-hand < or = salesfloor capacity = challenge" for all items at all times? or only for items expected to be received that day?
So this doesnt really sound like a glitch at all. The accumulator is as smart as you think. It souds like something was done at some time to cause the values to show as a need one the floor. I would point to the instocks process first. Just as subt9999 will reset the accumulator value to 0 because the accumulator doesnt recognise a negative number, the rsch process can reset values to what it needed to fill to capacity. Kind of the reverse to subt 9999. So he k the last rsch date it could of been scanned i. Rsch or worked in a rig task. That would explain the need value. An exf can also bloat your values that the floor needs too.
- Joined
- Mar 6, 2013
- Messages
- 64
My backroom team hates using STO on backstock from POG revisions and plano resets when the same stuff comes out every hour in our CAFs, but our backroom/instocks TL and ETL-LOG say using SUBT9999 is a bad thing because it negatively affects our "numbers". In what instances would using SUBT9999 negatively impact our scores? It shouldn't impact the backroom, so I'm assuming it impacts numbers on the DTK somewhere, so would using SUBT9999 cause some sort of in-stocks error? Or maybe someone on our in-stocks team is doing something wrong when SUBT9999 happens?
- Joined
- Jun 23, 2012
- Messages
- 426
It does create an error for the backroom because you are pulling more than the system thinks is in the location so it assumes an incorrect amount was stowed into the location. A potential workaround would be to sto 9999 and then subt9999 and the toggle back to sto and sto the correct amount. More steps but it should avoid the issue.
- Joined
- Sep 14, 2012
- Messages
- 600
SUBT9999 doesn't throw off any numbers, I thought the same thing when I started but no errors will show up on any report about it. As far as I know and have seen.
There is no "the wrong number was STO'd here" error. Now, if the system thinks there are 6 in location but there are 8, and a batch tells you to pull 6, and you do, leaving the 2 as a baffle (or reverse the first two numbers and now it's a ghost), now THAT will be an error if someone stumbles upon it later. However, if it thinks there are 6 and you tell it you're pulling 8 (and that yes, that was all of them), that will NOT generate an error. Similarly, SUBT'ing 10 when it thought there were only 4 does not create an error. SUBT'ing 99, or 999, or 9999 when it thought there were none at all? Still not an error. In fact, SUBT will never actually directly generate an error on the report--errors are only "found" when pulling batches. You can go SUBT an item from a thousand locations in a row that never had it STO'd there, and you won't have any effect on the location accuracy score. (Of course, if you don't tell it that you pulled all of the item from those locations, leaving ghosts behind, you'll be hurting the accuracy score in the future every time a batch goes to any of those locations and the TM has to M-delete, just like if you had fake-STO'd instead of fake-SUBT'ing.)
I used to work backroom and was told for years that SUBT9999 was bad and not to use it(but I refused to listen to them and later found that it was actually best practice). However, no one else seems to use it because it "takes too long." I work presentation now and if I have time I'll backstock what I bring back and subt9999 it in. But I know for a fact that if someone else backstocks it they don't bother doing it, even if I tell them it needs to be done. So, what happens is the poor solitary backroom evening dude gets stuck with loads of pointless pulls. So glad it's not me anymore.
Same thing with endcaps. I really don't understand why Target thinks its a good idea to put 5000 packs of macaroni cheese on a back endcap for a week when only a handful are going to even sell. Then it gets backstocked(painfully so) and takes up room for months. Just an example. I rarely set endcaps, but when I do I do NOT fill the endcap. It's pure stupidity. And then things that we could possibly send back we can't because they've been broken from original boxing. We still have like 100 of those stupid ride-on wagon things from black friday when they thought it would be genius to fill like 4 endcaps with them. >_>
Same thing with endcaps. I really don't understand why Target thinks its a good idea to put 5000 packs of macaroni cheese on a back endcap for a week when only a handful are going to even sell. Then it gets backstocked(painfully so) and takes up room for months. Just an example. I rarely set endcaps, but when I do I do NOT fill the endcap. It's pure stupidity. And then things that we could possibly send back we can't because they've been broken from original boxing. We still have like 100 of those stupid ride-on wagon things from black friday when they thought it would be genius to fill like 4 endcaps with them. >_>
- Joined
- Nov 23, 2012
- Messages
- 219
Errors are only found by baffles, M-delete, Locu, ghost. Where some are saying the subt9999 is a "baffle" its not. Baffle stands for -backstock found and fixed in ex2- which is simply old terminology for a pull. Since your not in a pull while doing subt9999 there is no error.
sigma7
Former ETL-All the Things
- Joined
- Jun 15, 2011
- Messages
- 2,415
Does subt9999 count against your backstock score as far as unload goes? I've never really looked at that report, but it seems like it has volume for eaches sent to backstock, sto only, and subt-add. But I think that's only for trailer unload.
G
Guest
Guest
One of the reason why the 12pm CAF pulls are huge at my store is because the bozos in the early morning backroom refuse to use SUBT and 999 when they backstock. That is just pure laziness. You can't use the ESC button or shift 7 and type in SUBT and do the 999? Really? During the hourly CAF pulls 11am to 5pm, if you only use STO when you backstock, there is a great chance that the backstock will get pulled.
- Status
