Retail EDI

I’ve discussed before how important Vendor Compliance is; but it’s from the retailer’s point of view.  I’ve mentioned how one piece of information is super important to the retailer (like the SKU) but matters little, if at all, to the vendor.  And I’ve mentioned how important the vendor may think that their style number or the UPC is.  But to the retailer; it’s not something we generally use to sell the products.

In the past, I’d spoken of how a vendor of ours asked if they could send additional data in their ASN document, as our spec differed in only that requirement from another vendor they supplied to.  For them, that extra data (the PID) was important to the retailer and, consequently, important to the vendor.  It was a case of coming to grips with a compliance issue.

But, again, today, I’m a vendor.

Or, what was it they used to say on those aspirin commercials?  “I’m not a doctor, but I play one on TV.”  So, I’m not a vendor, but I’ll play one online…

Think about what happens when you get wrong information to your buyer – the retailer (me in my other life).  What does that retailer do?  In worst case scenarios, they hit you with fines and fees (charge-backs); they delay receiving of the merchandise you’ve shipped; they delay payment of your invoice.  Some may just nag you and nag you and nag you until you comply.  They’ve set those rules, you must follow them.

Resistance is futile; you will comply.

Another old saying comes to mind – “ours is not to question why, ours is but to do or die”…  Basically, this means we are to follow the rules, even if we don’t understand them or the reason behind them, or we die…  Well, death may be a little on the extreme side for not providing a bit of data or an element you’re not sure of.

But, again, the retailer – your customer – needs that data for … well, for something.

There’s another old saying – especially true in retail – but true in any sales or service organization:

Again, this goes back to the buyer of your product – the retailer in this case – as being the driving force behind the data that is sent via EDI.  The customer is the one … in charge … and the one that gets to make all the decisions.  Think of the retailer as that bossy mother-in-law you may have or you’ve seen on TV.

Real life scenario - #1:

We require a “release number” in the BIG05 element of the inbound invoice.  This is to be used for all invoices and marks that invoice as “unique” from any other invoice processed that day.  Some of you may be thinking “well, the invoice number should be unique” – and yes, you’re mostly right.  But what if both Wrangler and Reebok send the same invoice number on the same day?  How can the system see them as different?  Oh, right.  By the vendor number; but what if Reebok doesn’t send the vendor number?

So this release number is a case of the customer wanting something that the vendor can – easily or with difficulty – provide in the documents, as requested.  Remember the “do or die” thing above?  It’s a system requirement of the back-end AP system to verify the data as unique.  It’s stupid and silly and doesn’t seem to make a lot of sense, but it does, somewhere down the line that you may not be aware of.

Now, again, I’m wearing a vendor hat today.  So that I don’t get hit with fines and fees and delays, it’s in the best interest of the company to find a way to provide that little bit of data that the retailer is requesting.  If the buyer is hitting us with charge-backs, it’s not making much fiduciary sense to ignore that request – especially with how high those charge-backs can get and how much they can add up to at the end of the year.

Real life scenario - #2:

We require two ISS loops/segments on the invoice – one is for the number of units that were shipped (and that the invoice is for) and then the second ISS is for the number of cartons that were shipped.  In both cases, our AP department needs that information on the Invoice “report” that they can print out if there is a problem.

Let’s say that you ship us 100 units in 10 cartons.  You invoice us 100 units in 10 cartons.  But our receiving dock only gets 9 cartons.  So the invoice doesn’t match the receipt.  By having both of these ISS segments/loops in the 810 data – and printed on the paper invoice report they can print – they can easily see that you said you shipped 10 cartons of 10 each, 100 total units.  It’s on the report because you’ve supplied it on the 810 document; at the request of the buyer.

This is another case of the customer requesting information that the vendor may not understand the reason for – why they want it.  But, as above, it’s not the vendor’s position to “know” why – just do it or face the consequences.

Previously, I’d explained the concepts behind some of the mandatory, optional and conditional requirements that your trading partners may have on their document specs.  I used highway and street signs as analogies and examples of those mandatory, optional and conditional aspects of the document.  You can be pretty assured that most of the time, when your trading partner is asking for the information, especially if it’s mandatory, there’s a pretty solid reason behind it. 

In some regards, it would be like going out and shopping for a new car or a new house.  You have a list of “requirements” you must have and a list of “optional” equipment that you’d like to have and that you want.  Maybe you’ve got kids, so you want to be sure that the door handles in back can be “locked out” to keep your kids from opening them (by mistake, of course!) while you’re running down the road.  But you’d also like to have a rear entertainment system to keep the kids happy on those long drives. 

One of those is a mandatory requirement and the other is more on the optional side.

When it comes to the guy selling you that car, however, he doesn’t need to know why you want those items; truly, he probably doesn’t care, either.  To him, you’re just somebody coming in to buy a car.  Maybe he doesn’t have kids, or he only drives 2 seat sporty convertibles, so all the back seat stuff makes no sense to him.  But he sure does want to sell you that car and so, he’s going to try to find a way to meet your requirements; your needs and your wants.

I’ve used the above because many, many years ago, I’d taken a stab at selling cars.  And it didn’t help to know why Bob and Carol wanted that bench seat instead of the buckets (maybe they like cuddling on long drives) but it sure was important enough that I find a car that fit that need; I was able to make the sale and they drove home happy.

As I’ve said before – it’s not really a question of why, but maybe more about “do or die”.  So when your customer makes some … seemingly odd requests … on the ASN or the 810 or whatever document – know that they probably have a good reason for it or they probably wouldn’t be asking for it…  You could always contact them and find out what the reason behind that segment or element is.  And if you have any doubts, see rule #1…