Rock Lobster
Executive Team Leader
- Joined
- Jun 11, 2011
- Messages
- 1,428
And challenge obviously... If you follow that procedure on all of those things you should be golden!
Archived Just dosen't stop pulling
- Thread starter rugrat
- Start date
- Status
And challenge obviously... If you follow that procedure on all of those things you should be golden!
- Joined
- Dec 18, 2011
- Messages
- 9
Correct me if im wrong on this but using subt without sto'ing it first will create a baffle in the system. Correct way would be to sto it then toggle to subt and reset it
- Joined
- Jun 8, 2011
- Messages
- 34,108
Sto first, then subt.
- Joined
- Jun 8, 2011
- Messages
- 162
No, you are wrong. Skipping STO'ing, does NOT create a baffle.
Rock Lobster
Executive Team Leader
- Joined
- Jun 11, 2011
- Messages
- 1,428
Correct it doesn't... the reason Target wants you to STO first is because of all the "filter" prompts that STO will show you that SUBT does not (like this item is on an MIR, item is clearance etc...) along with the fact that they probably assume you won't know the fillgroup off the top of your head...
- Joined
- Jun 8, 2011
- Messages
- 34,108
Thanks rock.
- Joined
- Jun 21, 2011
- Messages
- 704
Great answer Rock!! STO'ing using the SUBT is a very advanced move. You MUST know the fillgroup and you can inadvertently create baffles. Let me give an example. I have 4 cans of tomatoes. We will say they were overstock. In the SUBT function scan the item. Select the 1 option. It shows there are 2 other Tomatoes in location 01A14D35. Scan that location label. How many did you pull? 999. Did you pull all from this location? NO! Enter the number in location. HERE IS WHERE YOU CAN MESS UP. Enter the TOTAL number in the location. There were 2 and you are adding 4. There are now 6 in this location. If you enter any number besides six, you are creating errors. You have now successfully STO'd 4 new (remember there were already 2 STO'd there) tomatoes AND reset the accumulator. It's beautiful. Some will argue that you are creating a baffle if there are 0 in location to start with. I guess I don't know, because if you go searching for a baffle you won't find one because you are creating it and fixing it in 1 step. Maybe Rock can give some insight on that!!
- Joined
- Jun 8, 2011
- Messages
- 34,108
That's sounds about right for baffle corrections. I was coming from the prespective that the item on the shelf & not located when pulling something for a guest. Sorry for the confusion.
I do know if you are pulling an item with dpci in subt function & scan the wrong location(usually next to right one). That will create a ghost item in that location. Which can be fixed by locu & rescanning all items using sto on that location. It is suggested to review bp backroom with your tl on topics as ghosts, baffles, empty locations & how it will affects your be score. Proper training & understanding functions are keys to your team's success a great backroom score.
I do know if you are pulling an item with dpci in subt function & scan the wrong location(usually next to right one). That will create a ghost item in that location. Which can be fixed by locu & rescanning all items using sto on that location. It is suggested to review bp backroom with your tl on topics as ghosts, baffles, empty locations & how it will affects your be score. Proper training & understanding functions are keys to your team's success a great backroom score.
Last edited:
Rock Lobster
Executive Team Leader
- Joined
- Jun 11, 2011
- Messages
- 1,428
As far as I have been told my multiple leaders (and some old HIPO ETLs from this forum), your location accuracy score is only affected by the actual PULL application (ie Replenishment, Work Batches)... Using stand alone functions like Subt don't FIND errors to our system (they can cause them however if used incorrectly like you said)... Your instincts would tell you that if you Subt9999 an item without using STO first, it would be an error but it has been proven to have not!
There is a really helpful page on Workbench. In Workbench google search "resetting accumulator". This should help you troubleshoot some of the problems you are experiencing with over-pulling. We have had a number of these issues in my Logistics process during our remodel.
Here's an extreme, made up example that may help.
We received 501 copies of the new twilight DVD. We tied those 501 copies to the sales floor all over the floor. On endcaps, checklanes, home locations, etc (which makes no difference to the accumulator if they are tied are not, sales are sales). The first night we sold 488 of those copies. The next day we killed all other locations except one home location with a capacity of 12 and fill that home location to capacity. The sales accumulator is sitting at 488 for that item. That means that it believes we need 488 to be replenished. But we have one lone copy of the movie to backstock. When we backstock that 1 remaining copy the system drops it in the next pull at 11am, trying to fill that need of 488 copies that we sold. When we pull the one copy it reduces what the accumulator thinks we need to replenish what we sold. The sales accumulator is now sitting at 487. It can't fit on the sales floor so we backstock it again. The sales accumulator thinks we still need 487 on the floor so it drops it into the noon CAF batch. When we pull it we are sitting at 486 copies needed. This will continue to happen until you pull and backstock that copy 486 more times.
Sales at the checklanes add to the sales accumulator. There are 3 ways that you subtract from the sales accumulator: pulling an item in a system generated batch, acknowledging the item off of the trailer in the morning, and through the SUBT(guest/salesfloor) function. So rather than waiting around for the system to pull 486 more copies of Twilight on it's own, potentially creating massive amounts of inefficiency and wasted payroll in real-world scenarios, you can artificially subtract from the sales accumulator using the SUBT function to make it believe we have replenished the floor sufficiently. Using a quantity of 9999 will always make the sales accumulator read zero because it caps out at that amount of sales and can never be a negative value.
Something to keep in mind is that when you flex-out (or tie) product onto an endcap and pull everything out of the backroom (aka, having zero backroom locations that can come out in a pull and therefore be subtracted from the accumulator) you will increase the accumulator by whatever you sell. When you kill that endcap and backstock that item, the system will immediately drop that item into a batch to try to get the accumulator back to zero. It's simply pluses and minuses and works very well for everyday sales. When we move a lot of one product for a short time artificially (with sales and endcaps) that system may need some help.
There was mention of using the Stand Alone RSCH function to help alleviate this. Unfortunately, RSCH affects On Hands but doesn't influence the sales accumulator directly. If you have product in your backroom already it will come out in a pull, doing RSCH could potentially create another batch, causing even more work and possibly messing up your OH's. Doing what was described above could have some pretty "unsavory" effects on your replenishment!
Hope this helps! And don't ever be afraid to reach out to your GOL's on these kind of questions. Those people LIVE for these questions! =)
Here's an extreme, made up example that may help.
We received 501 copies of the new twilight DVD. We tied those 501 copies to the sales floor all over the floor. On endcaps, checklanes, home locations, etc (which makes no difference to the accumulator if they are tied are not, sales are sales). The first night we sold 488 of those copies. The next day we killed all other locations except one home location with a capacity of 12 and fill that home location to capacity. The sales accumulator is sitting at 488 for that item. That means that it believes we need 488 to be replenished. But we have one lone copy of the movie to backstock. When we backstock that 1 remaining copy the system drops it in the next pull at 11am, trying to fill that need of 488 copies that we sold. When we pull the one copy it reduces what the accumulator thinks we need to replenish what we sold. The sales accumulator is now sitting at 487. It can't fit on the sales floor so we backstock it again. The sales accumulator thinks we still need 487 on the floor so it drops it into the noon CAF batch. When we pull it we are sitting at 486 copies needed. This will continue to happen until you pull and backstock that copy 486 more times.
Sales at the checklanes add to the sales accumulator. There are 3 ways that you subtract from the sales accumulator: pulling an item in a system generated batch, acknowledging the item off of the trailer in the morning, and through the SUBT(guest/salesfloor) function. So rather than waiting around for the system to pull 486 more copies of Twilight on it's own, potentially creating massive amounts of inefficiency and wasted payroll in real-world scenarios, you can artificially subtract from the sales accumulator using the SUBT function to make it believe we have replenished the floor sufficiently. Using a quantity of 9999 will always make the sales accumulator read zero because it caps out at that amount of sales and can never be a negative value.
Something to keep in mind is that when you flex-out (or tie) product onto an endcap and pull everything out of the backroom (aka, having zero backroom locations that can come out in a pull and therefore be subtracted from the accumulator) you will increase the accumulator by whatever you sell. When you kill that endcap and backstock that item, the system will immediately drop that item into a batch to try to get the accumulator back to zero. It's simply pluses and minuses and works very well for everyday sales. When we move a lot of one product for a short time artificially (with sales and endcaps) that system may need some help.
There was mention of using the Stand Alone RSCH function to help alleviate this. Unfortunately, RSCH affects On Hands but doesn't influence the sales accumulator directly. If you have product in your backroom already it will come out in a pull, doing RSCH could potentially create another batch, causing even more work and possibly messing up your OH's. Doing what was described above could have some pretty "unsavory" effects on your replenishment!
Hope this helps! And don't ever be afraid to reach out to your GOL's on these kind of questions. Those people LIVE for these questions! =)
If you Subt an item from a location that it has not been backstocked into it will read 1 baffle error because you are telling the system that the item you are subtracting was sitting there the whole time un-located. The quantity is irrelevant. It will only ding you for 1 error.
Last edited:
- Joined
- Jun 8, 2011
- Messages
- 34,108
Hey! That is what I thought!
Rock Lobster
Executive Team Leader
- Joined
- Jun 11, 2011
- Messages
- 1,428
I have read that too... And while it would make sense for the system to read the error in that manner, multiple people have tested backstocking their challenge and plano backstock for a week or two using only Subt9999 and no STO first, and their accuracy remained green (would have caused hundreds of instantaneous errors!)... Like I said, it would make sense for it to function like you described (and I have made the same argument you have) but have been proven wrong on this subject 🙂
Rock, you may be arguing with the same people I was!! =) Where those people were confused was that they believed that quantities played a role in BRLA. They do not. If you read the ibutton on DTK for BRLA% and look at the formula used to calculate BRLA it reads something close to the following (sorry, I'm not at the store today):
1-(Number of Scans with Errors/Total Number of Scans) / 100 = BRLA %
The important thing to note is that it says "Number of Scans" not "Quantity" of anything. So, for example, you scan 1,000 dpci's in your back room (through pulls, subt, locu, etc., anything where you are telling the system whether something is in a specific location or not) and 3 dpci's were found to be baffles, then you would have had 997 accurate scans, 3 with errors, total of 1000 scans. The formula would look like this:
1-(3 scans with errors/1000 total scans) / 100 = 99.7%
So you have green BRLA even though those 3 dpci's scanned as baffles could have had a quantity of 100 each. If it were true that quantities matter in BRLA then you would have a BRLA in the 70% range when only 3 dpci's scanned in your back room were incorrect! Imagine how quickly BRLA would drop if you got dinged 24 errors for every casepack that was unlocated or a whole pallet of vegetables around the holidays!?!?!
This same thing applies to Subt but it's an even better example! With resetting the accumulator by subtracting 10k items from a location you should theoretically have NEGATIVE location accuracy when doing so because your "quantity" errors would quickly exceed your total number of scans. That is why I said earlier that "the quantity is irrelevant" because your BRLA is per DPCI scanned, not by quantities entered. It only gives you 1 single error if you Subt without STOing and zero errors if you Subt AFTER STOing, even when you Subt ridiculously large quantities because you were still "accurate" on whether the item was located or not. If you Subt more than the quantity you physically pull (leaving product in the waco but unlocated in the system) when someone scans that item as a baffle later it will score a SECOND error.
If you register 500 errors on your BRLA% in DTK you could potentially have thousands of eaches unlocated in your stock room!! Scary stuff!
Hope this helps!
1-(Number of Scans with Errors/Total Number of Scans) / 100 = BRLA %
The important thing to note is that it says "Number of Scans" not "Quantity" of anything. So, for example, you scan 1,000 dpci's in your back room (through pulls, subt, locu, etc., anything where you are telling the system whether something is in a specific location or not) and 3 dpci's were found to be baffles, then you would have had 997 accurate scans, 3 with errors, total of 1000 scans. The formula would look like this:
1-(3 scans with errors/1000 total scans) / 100 = 99.7%
So you have green BRLA even though those 3 dpci's scanned as baffles could have had a quantity of 100 each. If it were true that quantities matter in BRLA then you would have a BRLA in the 70% range when only 3 dpci's scanned in your back room were incorrect! Imagine how quickly BRLA would drop if you got dinged 24 errors for every casepack that was unlocated or a whole pallet of vegetables around the holidays!?!?!
This same thing applies to Subt but it's an even better example! With resetting the accumulator by subtracting 10k items from a location you should theoretically have NEGATIVE location accuracy when doing so because your "quantity" errors would quickly exceed your total number of scans. That is why I said earlier that "the quantity is irrelevant" because your BRLA is per DPCI scanned, not by quantities entered. It only gives you 1 single error if you Subt without STOing and zero errors if you Subt AFTER STOing, even when you Subt ridiculously large quantities because you were still "accurate" on whether the item was located or not. If you Subt more than the quantity you physically pull (leaving product in the waco but unlocated in the system) when someone scans that item as a baffle later it will score a SECOND error.
If you register 500 errors on your BRLA% in DTK you could potentially have thousands of eaches unlocated in your stock room!! Scary stuff!
Hope this helps!
Last edited:
- Joined
- Jun 8, 2011
- Messages
- 162
You're wrong.
Rock Lobster
Executive Team Leader
- Joined
- Jun 11, 2011
- Messages
- 1,428
Haha thanks ETLMan for not getting defensive! I understand the part of BRLA that you have described... My question about location accuracy is whether SUBT even counts into that formula in the first place! The way it has been explained to me (and I haven't seen any evidence that says otherwise) is that the system generated pulls are what find errors and count into your scoring... They have purposely NOT included SUBT into the scoring because of Subt9999... Think about how they have described BRLA (Errors/Total Pulls)... If Subt was included into that formula then all your Subt9999s (a few hundred a week) would go into your total pulls when there really isn't any product moving! To ensure accuracy with your Pull Types report they don't allow Subt to be included (and therefore don't allow it to go into those calculations at all)... Again I don't know for sure if that is correct, but it sounds right to me! My store never STOs any challenge before Subt9999 and we are about 99% on BRLA
First off, grats on some awesome results! 99% is awesome! The reason Subt doesn't result in thousands of errors when done incorrectly is that when you scan one DPCI incorrectly it is only logging one single error, not 9999 of them because eaches are not what is measured in that metric. One error out of around 20,000 scans in the back room through the course of a week doesn't have any impact on your score. It is entirely possible that Subt doesn't get factored into BRLA but it shouldn't be impacting it significantly one way or the other because most stores don't use that function more than a few dozen times a week.
More evidence for MisterLogistics here. If errors were based on eaches how would the following work? A case pack of 24 bottles of shampoo is baffled in your uppercase location. When you go through a pull looking for something else you scan the pick label on the shampoo. If errors were based on eaches, the system would have to stop you to ask how many are in that casepack or else it couldn't possible ding you for the appropriate 24 errors. Therefore, the system dings you one error for having one scan that was an error, not 24 errors because it doesn't have that information.
More evidence for MisterLogistics here. If errors were based on eaches how would the following work? A case pack of 24 bottles of shampoo is baffled in your uppercase location. When you go through a pull looking for something else you scan the pick label on the shampoo. If errors were based on eaches, the system would have to stop you to ask how many are in that casepack or else it couldn't possible ding you for the appropriate 24 errors. Therefore, the system dings you one error for having one scan that was an error, not 24 errors because it doesn't have that information.
Rock Lobster
Executive Team Leader
- Joined
- Jun 11, 2011
- Messages
- 1,428
Sorry, I guess I wasn't clear 🙂 We take 6-7 trucks a week... We get probably 3-5 flats of challenge per truck with probably 10-15 different DPCIs on them... All of these items are SUBT9999 without using STO first! That would be a few hundred extra Subt scans (and therefore a few hundred errors) a week! Not a few dozen
Again I'm not trying to be a jerk, but I understand that eaches don't go into BRLA 🙂
Rock Lobster
Executive Team Leader
- Joined
- Jun 11, 2011
- Messages
- 1,428
Also I just wanted to point out... I still think you SHOULD use STO before SUBT... I already said the reasons it is important to continue that practice earlier in this thread (for fillgroups, clearance, MIRs etc...) I am just saying that it isn't for BRLA scoring purposes 🙂
I am not a logistics leader in my store, I am currently a GSTL, I am good friends with the Flow TL and that is how he does it and it works for him!
I am not a logistics leader in my store, I am currently a GSTL, I am good friends with the Flow TL and that is how he does it and it works for him!
That would seem to be good evidence that Subt isn't going into BRLA. If you are an A volume store, I would guess that you are probably closer to 40,000 total scans per week then. The impact of even that much use of Subt would theoretically have a proportional effect on BRLA. With those 300-500 errors from the challenge alone your BRLA score would be at 98.7% at worst (plus with other errors it would be lower). So, it's not impossible that it still gets counted in BRLA but doesn't seem likely to me based on what you are saying. Do you happen to know about how many errors you see on DTK?
That does seem like an awful lot of challenge!! Do you know if they are working it back to the floor before resetting the accumulator?
That does seem like an awful lot of challenge!! Do you know if they are working it back to the floor before resetting the accumulator?
- Joined
- Jun 8, 2011
- Messages
- 34,108
gtc to both Rock & etlman for great answers!
Plus, we have now a better understanding of those function & how do it correctly.
Thanks!
I am staying with Sto, then subt.
Plus, we have now a better understanding of those function & how do it correctly.
Thanks!
I am staying with Sto, then subt.
Last edited:
- Joined
- Jun 8, 2011
- Messages
- 34,108
The test results are?
- Joined
- Jun 8, 2011
- Messages
- 162
I'm not talking about errors based on eaches. Incorrectly using SUBT (whether doing 9999 on an item or just for a regular guest request) will of course cause an error. I'm saying correctly using SUBT9999 without STO'ing first does NOT and can NOT cause an error, because the error has to be found while working a batch with that item/location.
Those two sentences seem to contradict one another. How does not STOing first qualify as using Subt correctly and what then is the incorrect usage? When you Subt something from a location that it is not located in you are giving the system all the information it needs to make a decision on whether that item was accurately located or not in exactly the same way it can determine a baffle error while pulling a batch. It now knows the DPCI of the item you are subtracting, the location you are subtracting it from, and whether it was located there a second ago. The two reasons I believe that to be true are 1) I read that a baffle error will be caused by using Subt without STOing it first in the "resetting the accumulator" guide and 2) the logic of it makes perfect sense to me. I'm not trying to argue with you but please help me understand why you believe that this information would be ignored by the system.
I'd love to be wrong! Help me see where I'm off track.
Last edited:
- Status
