Archived Backroom audits

Status
Not open for further replies.
Joined
Jun 12, 2011
Messages
99
Why can't target combine the merge report with the daily location audit? Just drop the locations of the old dpci into the morning batch and everything would get fixed in one process. Doesn't anyone else think it would work so much better? Target is AMAZZZZING :wacko:
 
2 days a week i get the joy of doing the audit and come in slightly early before doing the autofills with the rest of the BR O/N team, and the audit is more of a error fixing tool, at the end of each audit batch im told how many items were scanned vs how many error's i fixed.
 
Why can't target combine the merge report with the daily location audit? Just drop the locations of the old dpci into the morning batch and everything would get fixed in one process. Doesn't anyone else think it would work so much better? Target is AMAZZZZING :wacko:
I can't see that working because you wouldn't know when doing the audit if the item merge product needed to be relabled or not.
 
I can't see that working because you wouldn't know when doing the audit if the item merge product needed to be relabled or not.

Target would have to get their $i@* together and merge the items in a timely manner, like the day they flipping print the report, and then you would be deleting the old numbers and adding in the new without wasting time. The location would simply update. I always seem to have a cart of junk that I'm tucking away labeled "WAITING TO MERGE". Do you guys have product that sometimes takes forever to change in the system too?
 
Yea most of the time merchandise doesnt merge which is a pain. I put everything in a repack tape the dam thing so noone opens it ( which happened before.) And then write DO NOT OPEN! NOT MERGING YET!! After all that i hide it!
 
What populates the AUDIT? How does the system know there may be a problem in that location. I understand that items without a number of how many are in that location triggers some. What else?

The reason I ask is that one day's "scans/fixed errors" nearly equals an entire week's totals on the BR LOC ACY report.

And they are a pain because they take nearly 30 minutes a day to complete which seems to be a lot of time to fix errors each day.
 
Last edited:
What populates the AUDIT? How does the system know there may be a problem in that location. I understand that items without a number of how many are in that location triggers some. What else?

I don't know honestly... The thing is the audit has been around FOREVER... The only difference now versus before is the audit items were dropped into the CAFs, and you would go to a location to pull an item and it would be an M-Delete on purpose! The TM thought it was an error, but in all reality they just did some audits... Now they are in their own batch to do :)
 
I merge the items myself. Same computer you can look up the detail report on. I can't be bothered to wait for them to merge it for me. And if I went the suggested route and actually mysupported each case (like it says), I'd have 2-3 mysupports each week (assuming you can fit 6-8 DPCIs per mysupport ticket). And considering mysupport tickets seem to have a median turnaround time of 7-10 days....yeah. No.

I just wonder what the f*** takes them so g****mn long to do it, and why the report is only half-ass merged. Someone is probably getting paid 60-75k to sit there at HQ and retype DPCIs, yet they only do it half-assed.

On the topic of the audit, yeah, it's crossed my mind a few times that it'd be nice if the merging items just dropped into an audit, or maybe a separate batch that only populates on Tuesdays/Wednesday or something....but then I think, like someone said above, whoever does that s*** at HQ would need to actually be on top of it in a timely fashion each week. Which isn't going to happen.
 
What populates the AUDIT? How does the system know there may be a problem in that location. I understand that items without a number of how many are in that location triggers some. What else?

The reason I ask is that one day's "scans/fixed errors" nearly equals an entire week's totals on the BR LOC ACY report.

And they are a pain because they take nearly 30 minutes a day to complete which seems to be a lot of time to fix errors each day.

The audits are populated mainly by baffles, when you scan something during a pull that wasnt located, now its located with no qty. They are also populated by your overall on hands, if the stores on hands and the amount backstocked doesnt jive the system will throw that into the audits as well.

On the item merge, I usually do the updates each week and maybe 1 time every other month send a my support for anything that hasnt merged yet. I used to send them weekly like it says but the usuall response was "that item number is not listed to merge for 3 more weeks"....then quit putting it on the merge report morons.
 
Here is a better question. Why have the Item Merge in the first place. There are many times when an item conversion takes place. All affected DPCIs automatically become the new DPCI without an LOCU scan in that location. This has happened when paper went from 049 to 253, when frozen split into more departments, furniture going from 074 to 249, etc. Assuming the counts are correct in those locations, there should be no problem with HQ doing this. At least the Item Merge is a populated report now. At is beginning, it was only a list of DPCIs on workbench message boards.
 
Status
Not open for further replies.
Back
Top