Answered Does entering a quantity higher or lower than actual unit cause a backroom error?

[TargetsDaddy]

Wondering if this situation causes a backroom error.

Example:

System shows 5 Dawn soap on location L01A009L04
Actual amount there is 3
Instead of pulling 5 I hit 3.
Does this cause a backroom error?? Would this be considered a ghost since there's less than what it's showing or only if it's completely not there?

 

[Dog]

Yes

 

[happygoth]

Follow-up question, so it's better to enter the five than the three? I've done both in the past and was never sure which was the "proper" way.

 

[Kaitii]

i was taught to prevent an error:

leave the batch
audit the location
go back into the batch

and it will ask you to pull the proper amount thats there (or skip it altogether if it wasnt even there)

 

[Far from newbie]

Same here. We are told to FIX the error and then return to a proper pull.

otherwise:
‘if it asks for 5 and you put 3 - system thinks there are still 2 in the backroom Or you create an error cause you found a mistake
if there are only 3 and you agree with the 5 - you have just messed up you salesfloor quantity

 

[FlowTeamChick]

i was taught to prevent an error:

leave the batch
audit the location
go back into the batch

and it will ask you to pull the proper amount thats there (or skip it altogether if it wasnt even there)

Yes, but how does this fix what's really the problem: someone or perhaps several someones aren't back stocking correctly? I used to do this until I was finding so many errors in one particular fill group that it couldn't be just random errors. There's a problem and my doing random patches doesn't really fix it. (And yes, I have spoken to my TL about it.)

 

[Far from newbie]

I thought each DBO pulls and back stocks in their own aisle.....so wouldn’t YOU have made those errors ?

There used to be a report that would note who was in that location last, uncertain if that still exists.

 

[FlowTeamChick]

I thought each DBO pulls and back stocks in their own aisle.....so wouldn’t YOU have made those errors ?

There used to be a report that would note who was in that location last, uncertain if that still exists.

Yes, but since all this COVID stuff, I've been pulling another batch as well as my own. Schedules are weird, we're getting extra trucks, a certain DBO is so slow and needs help keeping up - so many things are just not the norm.
And I've been surprised at how many errors I've been finding - not every day, but several times a week, and that's when I'm not even looking for them. Since I've been working on helping get this DBO's back room area in better shape (it's just not her thing and left to her, it'll never happen), I've been finding a crazy number of mistakes.

 

[jenna]

I thought each DBO pulls and back stocks in their own aisle.....so wouldn’t YOU have made those errors ?

There used to be a report that would note who was in that location last, uncertain if that still exists.

report still exists. An no, it usually isn't my "error" - I haved checked the report and found people backstocking freight and backstocking re-shop. Also SFS has their hands in the BR, too. There can be overlap between a pull and a SFS request (aka item not in location since it was in a 1-4-1 that was just pulled, so SFS creates an "error.")

I have also had errors in my fill group from people putting it into different backroom aisles... aka I didn't do that either.

I actually had a ERROR in my fillgroup last week -- but the location is my product in another backroom aisle. : face palm : This was the only error in my Fill group.

 

[Kaitii]

Yes, but how does this fix what's really the problem: someone or perhaps several someones aren't back stocking correctly? I used to do this until I was finding so many errors in one particular fill group that it couldn't be just random errors. There's a problem and my doing random patches doesn't really fix it. (And yes, I have spoken to my TL about it.)

yeah its not just random errors, its tms who are backstocking/pulling incorrectly

the only thing you really can do is track down who is doing it and teach them to do it properly or throw out the trash if that doesnt work. an etl once taught me how to check who's pulled and backstocked in a particular location on the computers. i unfortunately forgot how to look that up, but perhaps your leadership knows how and is willing to do so.

i used to just audit as i pulled but i got fed up with them doing nothing about it, so now i just let the errors happen in the hopes the metrics going down makes them finally do something about it

 

[seasonaldude]

report still exists. An no, it usually isn't my "error" - I haved checked the report and found people backstocking freight and backstocking re-shop. Also SFS has their hands in the BR, too. There can be overlap between a pull and a SFS request (aka item not in location since it was in a 1-4-1 that was just pulled, so SFS creates an "error.")

I have also had errors in my fill group from people putting it into different backroom aisles... aka I didn't do that either.

I actually had a ERROR in my fillgroup last week -- but the location is my product in another backroom aisle. : face palm : This was the only error in my Fill group.

Just for clarification, SFS doesn't create backroom errors per se. That is to say they don't count against your BRLA%. In the specific situation you described that backroom location might fall into the suspect task audit, but it won't count against your numbers. That specific situation isn't very common though.

 

[seasonaldude]

Fulfillment doesn't expose errors, but they certainly play a hand in creating them

Never implied they didn't. I was talking about one specific instance.

Anytime you find a casepack in a non-openstock location that is missing one or two things, that's 99% from a Fulfillment Expert.

That, however, is bullshit. Lazy GM and Inbound experts exist too. In abundance.

What other teams never seem to grasp is that fulfillment has no incentive to keep product unlocated in the backroom. Unlocated product is the bane of our existence. It creates additional work for us and tanks our productivity and INF metrics. There are certainly are bad fulfillment TMs, but their TLs have more reason than anyone to correct that behavior as the metrics that suffer the worst from it are their own.

When they don't take the amount they're supposed to, they're creating future ghosts.

We have no reason to not take the proper amount as directed by epick. If I need 3 and I only pull 2, that just creates an additional task for me because I'm going to have to go get the third one somewhere else. The only reason not to grab 3 isn't if there aren't 3 there, but that just begs the question why the system thought there would be 3 there? (I know. I know. Probably because fulfillment must have done um well something. It's always their fault.)

 

[jenna]

Just for clarification, SFS doesn't create backroom errors per se. That is to say they don't count against your BRLA%. In the specific situation you described that backroom location might fall into the suspect task audit, but it won't count against your numbers. That specific situation isn't very common though.

I just know that SFS has asked if an item was in my 1-4-1, because the batch they were pulling was asking for the same item, as though it was still located in the BR Waco.

 

[seasonaldude]

I just know that SFS has asked if an item was in my 1-4-1, because the batch they were pulling was asking for the same item, as though it was still located in the BR Waco.

Yeah it happens. It's just not particularly common. When we start a batch, ePick creates a task list of where everything is (hopefully) located at that second. If you happen to be pulling one of those exact items, then it'll happen. There's nothing to be done about it except exiting our carts and resetting them, which has the potential to create far too may other issues to do lightly. In any event the exact circumstances where epick and 141s are wanting the same item at the same time are rare overall.

 

[seasonaldude]

If locations are properly grouped, Move will never result in opened casepacks being left on the shelves. It always instructs the TM to pull the entire thing and push it to the floor.

You're giving far too much credit to GM here. Move will intruct that the entire casepack is pulled, but that doesn't mean that it all goes out. GM can be just as lazy as anyone else with how they treat the remainder. Unless, you are suggesting that it is acceptable for GM to not open the casepack at all and just rebackstock it until it all goes out. That laziness unfortunately does happen far too often and is one of the behaviors that going caseless is meant to correct.

ePick also instructs that the entire thing be pulled, but it usually only wants 1-2 things. So what do most Fulfillment Experts do? Pull 1-2 things out of the casepack and just backstock where it was.

Yeah, that happens. "Most" is pure hyperbole there though. By the time I even know specifically how many of the item I actually need (most of the time) I've already pulled the casepack, opened it, and removed one of the items to scan. Might as well just backstock the rest properly.

Unless there's an error that results in ePick asking you to pull 2 from a casepack when there should be 4, and you pull the entire casepack and leave the excess on a nearby vehicle to be pushed. That's a ghost.

There are actually two errors that go into that. The first is from GM or Inbounds. Let's say you have a pick label that reads 6/36. GM decides that's a casepack of 36 and backstocks it as such. That's a mistake. It's actually a breakpack (?) mega-casepack (?) that contains 6 casepacks of 6 each. ePick is going to say to pull 6 because that's what an actual casepack for that item is. Obviously, it's an error for fulfillment to remove the rest and leave it somewhere without flipping to MyWork and properly taking it out of location.

In the past, we also had Fulfillment Experts using the "All Items Scanned" button without actually scanning everything in the location, resulting in mass purges -- purges they didn't have to fix. Great incentive to be lazy.

Again, 2 errors. The first is whoever made it so that fulfillment had to hit All Items Scanned. The second is fulfillment not scanning everything. Since, fulfillment has no incentive to create unlocated items (just more work for us to deal with later), it's usually a lack of knowing they need to scan everything rather than malicious intent. Far more common, is for an area to be poorly backstocked to begin with. Similar looking items in the same waco. Too many DPCIs in a single waco. Pick labels or barcodes not facing forward. Boxes behind other boxes. Etc. Those errors make it too easy for anyone, including fulfillment, to accidently miss an item while scanning for everything.

 

[TargetsDaddy]

‘if it asks for 5 and you put 3 - system thinks there are still 2 in the backroom Or you create an error cause you found a mistake

I always thought that if you put a number less than what it's asking, it will be deleted from that location. Can you advise? @allnew2

 

[Ringwraith917]

Always be accurate in your work. If it says pull 5, but there are 3 there, put that you pulled 3. "Errors" are there so (good) management can locate the cause of the errors, and fix it. Usually it's someone being careless or lazy.

Also if you put that you pulled 5, but only really pulled 3, the system now thinks there are 5 on the shelf. Say the same thing happens again, now the system thinks there are 5 you just pulled (but really only pulled 3 again), plus the 2 from last time that never sold. So 7 now, but really only 3 on the shelf. Compuound this over time and you can see how the numbers get way off and don't pull right.

 

[allnew2]

I always thought that if you put a number less than what it's asking, it will be deleted from that location. Can you advise? @allnew2

That is correct. If the system ask for 5 and it’s only 3 you pull 3 which then prompts the question if you pulled all and you say yes ( which deletes the supposedly 2 remaining in that location) then it will send you to the next location if item is still located in the back. By pulling only 3 the error will go to the person who last pulled or backstock.

 

[Bosch]

I thought each DBO pulls and back stocks in their own aisle.....so wouldn’t YOU have made those errors ?

There used to be a report that would note who was in that location last, uncertain if that still exists.

Not really cause there are people working while you are not there, also we have a bunch of SFS/OPU "help" that don't have best manners with backroom locations. I would love to send most of the people helping us back to where they came from. I do the backroom audit and most of the issues I end up fixing are from then not bothering to backstock things properly.

And other than the audit I do not fix or rather hide the mistakes of others.

 

[NLE Shoppa]

...I pull chem every day with maybe 1 error a month...I check Greenfield daily...I often do what you are talking about and I never generate errors this way...what gives?

 

[seasonaldude]

If it's a normal casepack, GM would be right. You always backstock the higher number. The smaller number indicates how product inside the casepack is divided -- but it's all the same product, so 36 is correct in that scenario.

Breakpacks come with different labels on them, so for those you would need to detrash and backstock individually.

Well, that's just another good reason to go caseless. If there's a 6/36 box, ePick will not let fulfillment pull more than 6. But, if we just do that, we leave an opened box in a casestock location. To make things correct, we have to flip to MyWork, Take 30, detrash all that shit, and then backstock it in an open waco. Not a huge deal if it's once in awhile, but Hello BTS coming around the corner. It's a productivity killer at best. At worst, many fulfillment TMs, aren't going to bother so you do end up with open boxes all over the place.

 

[jenna]

I don't think you understand how the process works. The 36 on those casepacks is the VCP -- Vendor Casepack. That's the divisible quantity the system applies to DPCIs stowed in lower/uppercase locations unless less is stowed there than the VCP. Move, ePick, RevLog Pulls, etc.. all use that quantity to determine what to pull when encountering DPCIs in those types of locations. They will always pull at least that quantity unless those locations are incorrectly grouped as openstock or, again, less is stowed than the VCP. That's how the system is setup. That is how it is supposed to work. That's why it made sense to have casepacks in the back, because unless you needed more than what was stowed in openstock locations, it didn't have you pull casepacks.

That's it. The system tracks actual quantity and VCP. It does not track the smaller number on pick labels, because it is irrelevant outside of letting you know how product is packaged inside the casepack.

The real productivity killer is going to be GM having to detrash BTS freight and attempt to stow all of it in WACOs.

And then how do you do Sweeps? once it's all detrashed.....

 

[seasonaldude]

No. That is absolutely incorrect. ePick is coded to pull the inner pack amount in casestock locations inside boxes that have not previously been opened. Seen it hundreds of times. The only time that epick will request less than what it considers a full casepack from a closed stock location is if less than the full amount is located there, i.e., someone has say opened a case of 12 and pulled one out. If that's all that is there, ePick will say to pick 11. If somone opens a 6/36, pulls out 6 as requested leaving 30, the next fulfillment TM to come across it will also be instructed to pull out 6.

To be perfectly blunt, right now, corporate cares much more about fulfillment productivity than GM productivity. That's just the way the cookie crumbles.

 

[seasonaldude]

You can't.

That's how it works when I'm in fulfillment. Like I said before, I always pull the entire casepack and then backstock the rest in openstock locations. I don't have to go into myWork to pull a remainder unless the location is grouped wrong.

Possibly a difference in OPUs versus Ship? I only do OPUs. I don't see anything close to what you describe and the locations are grouped correctly.

 

[Dog]

Maybe. OPU is on a timer where SFS is not.

Yes it is a difference between OPU and ship from store batches