Retail EDI

In the world of EDI, you’re often faced with a number of major and minor compliance issues with your trading partners; with your “country” from above. Did you put the right SKU number or UPC in the document? How about properly figuring and rounding the invoice? Or did you get the right carton labels (UCC128) on the right cartons and get the right data into the ASN?

All of these compliance issues can be answered when you think of what you can do for your trading partners; what you can do for – and with – the people you do business with and deal with on a daily basis. What can you do to minimize the disruption that those compliance problems can cause?

Real world story time…. A vendor changed the way that they were going to be processing our orders for a particular line of products we were buying. For years, we’d bought these products through an office on the East Coast. The EDI guy there and I had developed a pretty good working relationship and things went smoothly. Any time something popped up, I got alerted or he got alerted, and the problem was smoothed out before it became anything big and problematic.

Well, the corporate powers that be decided that the product line would be moved from one division to another. With that move, there would be a change in the way things were done. Testing would now need to be redone (with the new division) and all those same questions and bug-a-boos started popping up all over again. “Why this, why that, how come…?” *sigh.

Well, testing was completed and we’re able to move the new relationship into place. Except here’s a big change and there’s really no solid answer. This division does not have “pre-defined case packs”… What that means is that instead of always shipping a quantity of “X” (X=12; X=24, X=30, whatever), now X can be ANYTHING. 1… 5…. 12… Any number of items can be placed within a carton for shipment.

Ouch. Can anybody see the compliance issues that can arise from this…?

When it comes to case pack information, one of the reasons that it can be so important to a retailer or a vendor, is that it can make ordering a snap. I know that ABC Company always packs Widgets twelve to a carton. So when I order, I order in quantities of 12… Then, I know that if I order 144 units, I’m getting 12 cartons. It allows the warehouse or receiving group a certain amount of planning before the ASN is actually created, sent or received, because they know I’ve ordered 12 cartons.
Now, however, ABC Company is going to package whatever fits into a box. Even though I’m ordering 144 eaches, I can get a carton of 10, one of 20, another of 15, another 20, another 20, a carton of 30 and one for the remaining 29. Now, instead of 12 cartons, maybe all nicely stacked on a single pallet in a truck, I’m getting 7 cartons – all of different sizes, presumably – and they’re probably not going to be nice and neat on a pallet. Plus, there’s the possibility that I won’t be able to pack all of those disparate cartons into a single location.

Hoo-boy. Compliance issues up the ying-yang!

This, of course, can now lead to another can of worms between ABC Company and us. And to some of the people in the EDI World – it’s a bad word. Ready…?

CHARGE BACK

ACK! The sky is falling, cats and dogs are living together, pigs are flying and a certain realm known for fire, heat, brimstone and torture is suddenly colder than the Arctic!

But here’s a case of “ask not what the trading partner can do for you; what can you do for them?” You can be the hard-case, hard-nose and force the issue. “You have to package in cartons that are 24 inches long, 24 inches wide and 24 inches high or we’re going to charge you $5.00 for every carton that does not match those dimensions!” A simple order of 100 cartons now costs the vendor an additional 500 bucks!

Not very friendly or charitable, is it?

But maybe instead, you can think “what can I do for them” and maybe – just maybe – make an exception and find a way to accept those odd-ball carton sizes and work around the compliance issue and find something that works for both you and the vendor. And not issue all those charge-backs.

Another real life experience to dwell upon: one of our vendor’s supplies products to us and to XYZ Stores. XYZ Stores requires the PID segment in the ASN – that’s the “product/item description” segment. So in that segment, the vendor sends the text “Widget A, size Large, Color Blue” – or whatever they have as that description. Other than that simple extra segment, the ASN specs are the same. So ABC Company has two options:

1 – Create 2 maps – one for us and one for them OR
2 – Ask for permission to use the same map with the extra data included.

Asking what we can do for them, it’s simply a question of “will those extra dozen characters in the ASN cause any issues for us?” And the answer is “no, it won’t.” So, we give that vendor an exception (or whatever you want to call it) and allow the extra data to flow. When it comes to translation, the map just ignores the data because we don’t tell it to look at it.

Sure, we could be that hard-nosed, hard-case again and demand that they not send the extra data and charge them for any time that they send it.

To what end?

If you work more with your vendors and suppliers or your buyers and customers, you can maybe offset future issues or increases. You can keep things more mellow and even – just by thinking about what you can do for your trading partner.

I’ll agree that there can be some pretty major compliance issues out there – where a vendor is consistently sending the wrong data or not sending the data at all. It can create issues for you. But the flip side is that it can also create issues for them.

Another real life situation; one of our vendors does not send us an ASN. They’re a smaller vendor and the items ship from overseas and the local offices have no way of knowing the carton information or the Bill of Lading or whatever – and so they cannot create the ASN to send to us.

For us, this creates problems where we have to have somebody take the packing list – when the order arrives – and “create” the ASN document into our receiving system. We have to create some kind of a label and apply it to the cartons and match them to the packing list and generate that ASN so that the warehouse can scan those cartons and receive those products.

Of course, this then slows down the process of receiving and the goods may take an extra day or two (or more!) to be received. This can also slow down the payment processing of the invoice.

Speaking of invoices, what if the vendor is constantly sending incorrect data on the 810, meaning somebody at your company needs to monitor all invoices from the vendor, check them for the data, and fix the data errors. This takes time. So it can delay the processing of that invoice, the entry into the system and delay the payment.
But, if the vendor thought about “what they could do for the trading partner” instead, then these manual processes could be eliminated and only occur when there really WAS an error or a mistake, instead of every time; they’d be the exception, rather than the norm.

If they provided the right data or the right documents, they’d be doing for us. And we’d still be doing for them.

The relationship between the citizens and their country is a two-way street. President Kennedy was, seemingly, implying that fact – that the country cannot always provide everything for its citizens and that the citizens may have to help out the country – asking themselves what they could do.

True, we’re in much different times now than we were then. But the same concepts can still hold true – whether in politics or EDI. That communication between retailers and wholesalers, vendors and buyers, is similar as that between citizens and their country – it IS a two way street. So maybe it’s time to drag Kennedy’s words from the past and make them work for today; ask what you can do for your trading partner and not just what they can do for you. It could mean a better world for us all.