On the other hand, diversity and lack of consistency in EDI implementations is definitely not a good thing. As a case in point, I just started working on the mapping of the Footlocker 860 for my client. The experience brought to mind my cohort, Marlow Atticus’ recent column bemoaning the practices of companies that seem to fly by their own inconsistent guidelines. Take the simple, and frequent, act of canceling an item that’s been ordered previously. Marlow was right… there seems to be no consistency with how companies communicate how an order is being changed. In Footlocker’s case I learned that they can cancel and Item and then reinstate that same item on the same PO. I’m not certain what kind of logic is involved in producing this kind of an order. My guess is that it’s the result of some kind of kluge assembled by the line managers, IT department, and EDI staff. And I’d hate to see the logic diagram for this thing.
Most of my other customers will create a new PO if they decide they need the cancelled item after all. Keeping track of items after they’ve been cancelled can be a nightmare. In most of the order applications I’m accustomed to, we keep track of cancelled items for audit purposes. However, every time this client gets an order from Footlocker that re-instates a closed item, the 860 fails in to the system as a duplicate. The biggest pain has to do with Footlocker sending the reinstatement by sending it as an add! It would seem to make more sense to send this as a Change if they insist in re-instating the item.
All this adding, subtracting, and reading is making me think of streets and avenues. I know that at no matter which intersection I find myself at, I’m likely to find an interesting place to eat. I’m thinking of the smaller numbers right now, just to keep things simple. Maybe down around 1st Ave and 2nd St.