Data Flips

myback

Well-Known Member
yeah ain't it great pas/edd rocks. its the best thing since sliced bread. thats what the mgrs were telling me when they were "fixing" my route. i resisted at first but now i'm begining to see the light. don't u see they fixed it why would i want to unfix it. if edd says main st then its going to main st and if the cust doesn't like it then he can call one of our charming, helpful 1800 operators. and if he still doesn't like it he can call our other number 1800hahahahahahaha. get those meathead idiot mgrs who said how awesome pas/edd would be on the phone so they can explain :censored2::censored2::censored2: is happening.
 

IDoLessWorkThanMost

Well-Known Member
I am very relieved to hear this. Guessing is a very bad practice some of our data scrub folks have gotten into that I just cannot understand. Whenever I audit an operation, I always emphasize that there are 3 possible outcomes when looking at package data that has failed validation 1) correct it to the right address so it gets SPA'd to the right car when it arrives, 2) do not find a good match in the data base and just F10 past it so it will go to DA when it arrives, and 3) correct it to a match in the database that is the wrong address. Of these, number three is far, far, far and away the worst of the possible outcomes. Yet I still see data OMS' looking up "Robert Smith" in choicepoint and then throwing in the first address that pops up. Like there is sure to be only one Robert Smith in a major metropolitan area.

ficticious Example: ( this is thought-provoking, to the people not "in the know")

A package enters the UPS system with incorrect information. It's your job correct the problem.

Company name - FedEx
Zipcode :11111
City: jonesville
Street name ( smith st.)


There is a fedex location on smith street, but it's not in Jonesville 11111, it's in another city. The correct zip is 11132 in johnstown.

Choicepoint lookup resolves to fedex locations on smith street in johnstown and jonesville....

What do you do - scrub it and let it goto decap, or correct it?


A good data corrector scrubs it to decap. A bad one tries to split the uprights with a 40 mph wind and takes a wild stab ( which could be an embarrasing mistake and makes for interesting PAL experiences)...
 

Mike Hawk

Well-Known Member
Agree with Mike here. I have seen truly good SPA people, and they are aware of the rhythm of the system and know when the timing is off. When I am training in the operation, I always tell them better to shut off the belt and double check if they think something is amiss.

As a side note re an earlier post, the system does not hiccup, nor does it get hives or belch. What does sometime happen that looks like a SPA hiccup is that the SPAer scans the Maxi barcode and then the scanner picks up the 1z as he is pulling the scanner away from the package to be ready for the next one. In this instance, the SPA system will give two labels for the same package, but the scanner will have beeped twice indicating that it read two labels. So as Mike has indicated, if you are paying attention you can catch it.
No, it does hiccup belch and take a poo on the operators, you just haven’t used it enough to see that. Sometimes when you scan a package it will beep but won't print a label, so you either A scanned the little mini bar code that is next to the SLIC on the label, B the barcode is just a bad barcode and won't scan properly but it will still make the beep when you scan it, or C the network hiccups(happens to the other SPA person at the same time) and there is a 1-4 second delay in the label printing. When this happens I usually scan the package again to rule out scanning a bad barcode, then my machine will spit out 2 of those labels. If this happens when you are scanning faster than you are putting labels on then it is very easy to get off because it beeps like a normal package. When I SPA I pause after every other package to make sure I didn't get off anywhere.

PS make the machines take less than 15 minutes to boot up! Really annoying to take break after 1 hour because a package fell on the power cable.

PPS Choicepoint sucks, the more parameters I put in to narrow down the search the wider the search gets, giving me results with only the state in common with what I searched for.
 

IDoLessWorkThanMost

Well-Known Member
No, it does hiccup belch and take a poo on the operators, you just haven’t used it enough to see that. Sometimes when you scan a package it will beep but won't print a label, so you either A scanned the little mini bar code that is next to the SLIC on the label, B the barcode is just a bad barcode and won't scan properly but it will still make the beep when you scan it, or C the network hiccups(happens to the other SPA person at the same time) and there is a 1-4 second delay in the label printing. When this happens I usually scan the package again to rule out scanning a bad barcode, then my machine will spit out 2 of those labels. If this happens when you are scanning faster than you are putting labels on then it is very easy to get off because it beeps like a normal package. When I SPA I pause after every other package to make sure I didn't get off anywhere.

PS make the machines take less than 15 minutes to boot up! Really annoying to take break after 1 hour because a package fell on the power cable.

PPS Choicepoint sucks, the more parameters I put in to narrow down the search the wider the search gets, giving me results with only the state in common with what I searched for.

Those are hardware issues, i.e. scan something and only shipper#/ town comes up but no tracking, or nothing at all. Some scanners work differently than others. Some only work well with maxi, others barcode, etc etc
 
Top