Archived How to fix my backroom location accuraccy???

[konk]

My accuracy is perfect. I know how to count. I am not doing anything to affect my accuracy. Last time I checked I wasn't getting a bonus for BRLA. This is pure selfishness to show my leaders how much better I am than everyone else.

I will also purposely scan different items if I know they were all backstocked as the same item. For example, blunt tip scissors and pointed.

 

[konk]

And you're a number fudger!

 

[Quattro]

I will also purposely scan different items if I know they were all backstocked as the same item. For example, blunt tip scissors and pointed.

I started doing this recently. Just yesterday, someone had backstocked 3 different toothbrushes as the same DPCI. Rubberbanded together and everything. Everyone makes this mistake once in a while, but this time the packaging wasn't even remotely similar. C'maaaaaaaaaan.

 

[whippingboy]

You could also cheat the system and have your team LOCU instead of using M-delete, that is if your a fan of doing extra work just to make a score green.

This will also erase any identifying marks of who STO'd it previously.

 

[Backroom22]

My accuracy is perfect. I know how to count. I am not doing anything to affect my accuracy. Last time I checked I wasn't getting a bonus for BRLA. This is pure selfishness to show my leaders how much better I am than everyone else.

I will also purposely scan different items if I know they were all backstocked as the same item. For example, blunt tip scissors and pointed.

It would be more productive to fix this when you come across it, besides creating baffle errors the items you scanned will just come up in the next pull and could possibly be missed by a less experienced team member creating an additional M-delete error. Also, your team leader will now have an extra location to do in the audit batch. Location accuracy is a team effort I don't see how what your doing makes your leaders see that you are better than everyone else.

 

[konk]

BRLA TM report. I agree though that they don't care. I just don't see why I should have to fix someone else's mistakes. I agree that it is a team effort therefore I shouldn't have to fix everything.

 

[Backroom22]

This will also erase any identifying marks of who STO'd it previously.

Just to clarify I don't recommend using LOCU instead of M-delete it is cheating, it can also get you in trouble if any of the district/group people dig into your numbers.

 

[konk]

We had a support team ETL notice that everyone except me had huge amounts of locu baffles.

 

[Backroom22]

BRLA TM report. I agree though that they don't care. I just don't see why I should have to fix someone else's mistakes. I agree that it is a team effort therefore I shouldn't have to fix everything.

The BRLA TM report only shows errors made by M-deleting wrong, using Y/N wrong, and using LOCU wrong. Unfortunately, it cannot determine who is responsible for an error caused by counting incorrectly because it could have been the person who backstocked it or the person who pulled it(or the person who pulled it from that location before them). That is why if you add up all the total errors from the BRLA TM report you will see that it is much lower than the number of errors from the regular location accuracy report.

 

[Noiinteam]

I had a guest ask me for something on a empty shelf. My device showed 4 in backroom. Showed my device to bkrm tm and he put dpci into the PDA. I recognized 3 on a shelf. Pda pulled full case pack of 4. So I said something like the 3 I saw must not have been located. He said they are now. I tell another tm about this, cause we have been told in huddle our bkrm errors have steadily been going up. Next day the other tm has another guest who wants same product ( it was on sale). Goes to bkrm tm and gives her the dpci and it says none on hand. However, she sees the 3 that were still on the shelf. He said take them they were never located. WTF Both tm's are experienced bkrm tm's. I only wish it was me the second day with the tm I dealt with on the first day. That would have been interesting.

 

[LogisticsFox]

I will also purposely scan different items if I know they were all backstocked as the same item. For example, blunt tip scissors and pointed.

I'll do this too, especially with MIRs. If I know what is going to pull from a location, I'll scan the item last so if there is something not scanned in, it will become a baffle. On the other hand, if something is obviously not scanned in, I'll toggle to STO and U-pdate the quantities in the location so it erases the baffle. I tend to be very hesitant about intentionally leaving baffles behind because the next person to pull from the location might mm-delete or I may not be the person to do the next days audit and the error may just be recreated.

 

[konk]

The BRLA TM report only shows errors made by M-deleting wrong, using Y/N wrong, and using LOCU wrong. Unfortunately, it cannot determine who is responsible for an error caused by counting incorrectly because it could have been the person who backstocked it or the person who pulled it(or the person who pulled it from that location before them). That is why if you add up all the total errors from the BRLA TM report you will see that it is much lower than the number of errors from the regular location accuracy report.

LOCU wrong is the same as audit wrong, right?

 

[Targetron]

I've gotten super fast with it using toggle and the left arrow for return. If I toggle over to STO and there are 6 in the location, but it asked for 4, I will hit return, toggle back to pull, and pull 4. If it says there are 4, but there are actually 6, I will pull 5, it will ask if I pulled them all, I will say no, then it will tell me if it wants more or not. Now the baffle has been created, but it will be fixed in the audit.

Thats the most ass backwards backroom idea I've heard in a while. Why would you need to create a baffle AND more work in the audit AND leave a single small item in the waco. If you notice the count is off by 1 or 2 just add the rest to the pull. The point is to fill the floor and empty the stockroom not create as much extra work as possible

 

[Backroom22]

LOCU wrong is the same as audit wrong, right?

Errors on the BRLA TM report under LOCU can be from the audit only if the person doing the audit missed an item in a location they scanned during the audit (this is because the audit is pretty much the same function as LOCU). So, any errors on the BRLA TM report under LOCU would only be from making a mistake while using LOCU or while making a mistake while doing the audit. So the errors people may have under LOCU are not from anything that was found by the team leader doing the audit.

 

[LogisticsFox]

Thats the most ass backwards backroom idea I've heard in a while. Why would you need to create a baffle AND more work in the audit AND leave a single small item in the waco. If you notice the count is off by 1 or 2 just add the rest to the pull. The point is to fill the floor and empty the stockroom not create as much extra work as possible

I think the idea could have some merit to it. If it is a location with several items, there could be another hidden error. I would rather flag it so the loc would be detailed tomorrow instead of waiting for it to pop up weeks/months down the line.

 

[konk]

No, he has a point. I guess I just like to make people look bad.

 

[incredulu]

I've gotten super fast with it using toggle and the left arrow for return. If I toggle over to STO and there are 6 in the location, but it asked for 4, I will hit return, toggle back to pull, and pull 4. If it says there are 4, but there are actually 6, I will pull 5, it will ask if I pulled them all, I will say no, then it will tell me if it wants more or not. Now the baffle has been created, but it will be fixed in the audit.

This is interesting though from what I understand a CAF pull is not going to necessarily ask for everything of a specific item from a location. In other words the CAF pull may only need 4 of a specific item and not 6 because 4 is whats needed on the floor.

 

[incredulu]

Errors on the BRLA TM report under LOCU can be from the audit only if the person doing the audit missed an item in a location they scanned during the audit (this is because the audit is pretty much the same function as LOCU). So, any errors on the BRLA TM report under LOCU would only be from making a mistake while using LOCU or while making a mistake while doing the audit. So the errors people may have under LOCU are not from anything that was found by the team leader doing the audit.

What exactly is the error that you'd make using LOCU...or Y/N, and how would the system recognize that?

 

[signingminion]

No, he has a point. I guess I just like to make people look bad.

And therein lies the problem. Yes it sucks to fix everyone's errors all the time, but to do your job and do it well means making it happen. Fixing errors without inflating metrics is in everyone's interests.

 

[Backroom22]

What exactly is the error that you'd make using LOCU...or Y/N, and how would the system recognize that?

The system recognizes errors during the pull process, every time you are in a batch doing a pull it is double checking to make sure that everything that you scan in the location is located in the system. If you are pulling from a location and scan something that was not located in that location this creates a baffle error. If you are pulling and can not find the item and have to use M-Delete it creates a ghost error.

Now most of the time the errors are not assigned to a TM because it could not be determined who caused the error (it could have been the person pulling or backstocking). When it does assign errors to a TM it is because they used M-Delete,Y/N, or LOCU wrong.

So for example, if a team member John was using LOCU on location 01B 007B001 and scans everything back in except he misses one DPCI and now it remains unlocated. Now later in the week another TM is doing a pull at 01B 007B001 and during the pull scans the item that John missed, this causes a baffle in the system and it is assigned to John b/c the item was located there before he used LOCU and found again during the pulls after he used LOCU and left it unlocated.

The same is true if someone is using M-Delete before scanning everything in a location or entering Y-yes when there are still quantities of the item in location. Because the item was located in the system before they used these functions and then found after they used them during the pulls the errors can be assigned to them in the BRLA TM report.

 

[asidius]

I have a question that relates to BR accuracy. When doing CAFs and it asks you to pull 5 of something but you only see 3. Do you guys enter in 5 and hope it asks if you pulled all of the item (so the system knows there are no more left) or do you enter how many you actually have? I've entered what it asks when we actually don't have that many and occasionally it won't ask if I pulled all of that item, thereby leaving the ghosts.

 

[sigma7]

I have a question that relates to BR accuracy. When doing CAFs and it asks you to pull 5 of something but you only see 3. Do you guys enter in 5 and hope it asks if you pulled all of the item (so the system knows there are no more left) or do you enter how many you actually have? I've entered what it asks when we actually don't have that many and occasionally it won't ask if I pulled all of that item, thereby leaving the ghosts.

If it asks for 5 and there are only 3 in location, key what you physically pull. Pulling less than the quantity the systems asks for will delete the item out of the location correcting any errors. Keying what the system asks for when it's not actually there understates the sales accumulator and could potentially leave ghosts or baffles. Additionally, if there is more of that DPCI backstocked in a different location then the batch will route you to the next location if the total need wasn't originally fulfilled. If you key the requested quantity when it's not actually there, any other locations with that DPCI will be dropped from the batch. So now the floor is not filled and you have product sitting in the back which may not pull later since the accumulator is understated.

 

[incredulu]

The system recognizes errors during the pull process, every time you are in a batch doing a pull it is double checking to make sure that everything that you scan in the location is located in the system. If you are pulling from a location and scan something that was not located in that location this creates a baffle error. If you are pulling and can not find the item and have to use M-Delete it creates a ghost error.

Now most of the time the errors are not assigned to a TM because it could not be determined who caused the error (it could have been the person pulling or backstocking). When it does assign errors to a TM it is because they used M-Delete,Y/N, or LOCU wrong.

So for example, if a team member John was using LOCU on location 01B 007B001 and scans everything back in except he misses one DPCI and now it remains unlocated. Now later in the week another TM is doing a pull at 01B 007B001 and during the pull scans the item that John missed, this causes a baffle in the system and it is assigned to John b/c the item was located there before he used LOCU and found again during the pulls after he used LOCU and left it unlocated.

The same is true if someone is using M-Delete before scanning everything in a location or entering Y-yes when there are still quantities of the item in location. Because the item was located in the system before they used these functions and then found after they used them during the pulls the errors can be assigned to them in the BRLA TM report.

Nice post. With regards to the Y/N, does that question also prompt when you're pulling an item under SUBT or a CAF pull and type in a quantity MORE than the system thinks is in location? Then hitting yes charges a baffle?

And is pipo any different

 

[Backroom22]

Nice post. With regards to the Y/N, does that question also prompt when you're pulling an item under SUBT or a CAF pull and type in a quantity MORE than the system thinks is in location? Then hitting yes charges a baffle?

And is pipo any different

The Y/N will prompt if you are entering more than the system thinks is in location, as far as doing this in the CAF pulls is concerned I am not really sure if this causes an error on the report I have not tested it. However doing this is SUBT will not causes errors, this is because errors are only calculated when pulling batches in the system.

PIPOs that do not have quantities (i.e. the ones that do not ask how many when you backstock them) you can enter more than it is asking for because the system does not know how many are there. With these just make sure when you hit Y-yes if all of the item is gone and you will be fine, however if you enter less than it asks for on these it assumes that you have taken everything and unlocates the item.