Taking on EDI projects are the the most difficult jobs I've had as a dev or as an admin. Interacting with someone else's database schema is like trying to put y

Taking on EDI projects are the the most difficult jobs I've had as a dev or as an admin. Interacting with someone else's database schema is like trying to put yourself in its designer's head, and it's on a good day when you have a standard protocol or database format. I've mostly worked in the auto-industry as end-user support and currently employed by a wholesaler - the connection between parts manufacturers overseas and dealerships, body shops and others. The business is more complicated than that, but the auto industry is one with many standards, lots of vendor lock in, and proprietary formats and coding schemes for everything. With EDI you don't get to dictate standards, you can't demand JSON/web interfaces, you usually have to deal with flat text files (good luck) or schemaless XML (you're doomed) if that. Some vendors just provide XLS files to an FTP endpoint and call it a day. Some vendors send pricing information exclusively in PDF format over email. The manufacturers never maintain a format for more than a month, and downstream consumers of data can never decide how they want it. Finally, you'd think that once you get all of that mess sorted out you're golden. The only problem is that the auto industry is the land that time and UPC codes forgot, and there are multiple inconsistent standards for labeling parts, and data services that claim to have a mapping between them are selling snake oil at prices several orders of magnitude higher than what you'd think fair. Also no one in this industry believes in using software developed in the last ten years and I think I'll be near retirement age before my successors will first receive vendor data in JSON over HTTP/1.0.