Comment by jellicle | Hacker News Reader

Comment by jellicle | Hacker News Reader

A little bit of a non-standard sort of HN post, but it illustrates an interesting sort of system failure.

My speculation, never having set foot in an Amazon warehouse:

1) Amazon stockers are told to put the incoming inventory in a spot, and scan all visible barcodes on the product, which are all associated with that product in Amazon's DB henceforth. Normally extraneous barcodes are no problem because they aren't SKUs, so no one ever tries to pick them by the extra codes. Easier to tell the stockers to scan everything than to try to get them to pick the right one.

2) Company X, Y, Z ship their products to Amazon with their own barcodes and fail to remove the box company codes. Dozens of different random products around the warehouse end up with a secondary, identical barcode associated with them.

3) Someone orders boxes. Inventory system probably automatically sends pickers to the closest source of SKU 12345, of which there are - unusually - many scattered around the warehouse. So the product received is essentially random, out of whoever uses these boxes. Product roulette!

4) Customer service can't solve this problem. Maybe there's someone in Amazon's inventory team that can go in and fix it, but it occurred for good reasons! Everyone was behaving rationally. There are probably other similar problems in the database as well.

> scan all visible barcodes on the product

Almost.

Amazon FBA requirements are that the UPC barcode for your product be the only visible barcode on your packaging.

I would bet money that in the name of "efficiency", warehouse employees are trained to scan the first barcode they see and use the result, whatever it may be.

But not the only instance of the only visible barcode - Aldi products are covered in large barcodes so scanning them there are no wrong sides https://www.motherjones.com/kevin-drum/2016/06/aldi-has-very...

LIDL does this too.

Just a thought, could this be engineered to work in one’s favour? For example, order a box of something expensive, receive it, attach a barcode for something cheap which is low in stock / rarely ordered, then send it back. Now order the thing you labelled it as, and see what turns up. Perhaps you’ll get a box of Epyc CPUs for the price of a box of out of season kwanza decorations.

That sounds like mail fraud - and you could get prosecuted by the feds for that. Not something I recommend trying, especially in the US.

If you don’t use USPS (use say fedex) can you still be prosecuted under those statutes? I though the USPS jealously guards whatever remaining prerogatives they retain.

It’s still regular old fraud, and still wrong and you deserve to get trouble for it. Just curious about who will finger your collar.

The statute on mail fraud (18 U.S.C. § 1341: https://www.law.cornell.edu/uscode/text/18/1341) clearly states:

> places in any post office or authorized depository for mail matter, any matter or thing whatever to be sent or delivered by the Postal Service, or deposits or causes to be deposited any matter or thing whatever to be sent or delivered by any private or commercial interstate carrier

(Emphasis mine). It is clear from this that committing fraud via FedEx and UPS would be treated the same as USPS.

The one difference, AIUI, is that the USPS is protected by the US Postal Inspection Service (who are, as you say, quite zealous), whereas I’m not sure the same extends to UPS/FedEx (where you’d probably be looking at an FBI investigation instead).

However if you (or Amazon) mailed e.g. the return labels over USPS the USPIS could still get involved.

Thanks.

I think you would have to be on the supplier side, no doubt they have more checks in place for returned items than ones coming from suppliers.

This reminds me of a problem I ran into in a previous life. It has nothing to do with inventory control, but all about how clean/sane is thd data you are storing in the database. We had a system with a set of webUI based forms used by non-technical users to use to add info to the database. However, the forms were outdated, and were importing bad default values. The devs told me they felt that bad data was better than no data. I laughed out loud at the reversed logic. It did nothing but cause grief, and was only solved (for me) by my no longer working for that company.

Everyone was behaving rationally maybe the first two times this happened. After that though someone should have double checked the outgoing package.

#4 is really by far the biggest problem here. No matter what, with a company of Amazons size things are going to go wrong that just cant be solved in an automated fashion. They need support with the training and authorization to escalate issues like this to staff that have the power to fix them.

Amazon has absolutely no memory. All of your customer support woes go to people working from a script. The likelihood of getting the same customer support person is zero.

You can get an actual human who can look at what’s going on if you send email to Bezos; that gets forwarded to the secret support team that can actually make decisions instead of just following a script. Or at least you could a few years ago.

might be a amazon.ca specific failure, other commentators who say the same are in canada.

Reply on news.ycombinator.com