There continues to be confusion around who pays the price for EDI. There are three answers to this based on the definition of the question.
As EDI continues to evolve, so does the thought of managing order changes electronically. In January I reported on managing PO changes through the E-Commerce Direct Ship/Drop Ship types of orders and for the last couple years I've commented on the status of communicating changes to a open order in general, so I thought it might be time for an update.
Change is one of those concepts that make most of us cringe at its mere mention. Whether it is benign as changing dinner plans with one’s spouse, or as dire as divorcing said spouse (funny how doing the former very often may lead to the latter, but I digress) every fiber in our character wants to resist it and keep the status quo. To deal with this, change management has become an academic pursuit, as well as embedded itself within the corporate lexicon, which have produced countless strategies on dealing with this force in one’s personal life as well as in the business environment.
Well, you’ve identified the software functionality you need and have talked to your sources to get their opinions on how to go about developing it. In the back of your mind, though, you still think it should be part of the base translator package and ought to be included in a future release. What’s your next step?
It's been nearly a years since I wrote on the topic of XML as a form of EDI. Over the that time I've received quite a bit of feedback on that article, some of which was around what appeared to my biases on EDI standards. So I thought I'd address XML again.