7 ms·

I've never seen an EDI implementation that required nothing custom. The claim is oft-repeated but based on little substance.

SystemOut 4y ago
This is so true. Am in logistics so can't speak to other verticals but every-single-implementation has something unique to it. Either they're on a version we haven't tested on, or they only support some date/time formats, or they have custom codes, whatever.
- andrew_ 4y ago
  Worked in Logistics and can confirm. AT&T had a dozen different data formats for the same data across their network of warehouses.
- themadturk 4y ago
  Also in logistics, and agree. There is danger in over-promising with customizations. If you're not careful to you can spend more time and money meeting what the customer wants than the actual business the customer brings in.
themerone 4y ago
Our EDI code probably has multiple if blocks for every customer we communicate with. Implementing EDI is not for the faint of heart. For the variations I worked with, there was little useful documentation, I learned mostly be reading existing code. I would hate to have to start from scratch.
- pdimitar 4y ago
  I wrote an EDI parser from scratch some years ago (2 to 5, really don't remember). Almost until the end I kept second-guessing myself. It all looked so flimsy. Eventually I made a second parser that utilized a parser-combinator library (the first one was hand-rolled) and devised extremely detailed property tests that I ran against both parsers. Only then did I feel confident. Naturally, in production the code crashed on the second day because OF COURSE the senders didn't obey the EDI[FACT] spec and had quirky deviations from it. Shit like that makes people retire to the mountains and never touch a computer again, man.
  - donzog 4y ago
    I still work in the EDI-parser software but retiring to the mountain has never been more appealing.
P5fRxh5kUvp2th 4y ago
that's still not API though. EDI = data, API = functionality. They can work in tandem, but don't have to. you might as well say FTP is an API. In the most technical sense, sure.
sleepymoose 4y ago
Agreed, everyone needs something just a little different. And at least from my experience, the platforms and systems that build the integration are essentially disparate and held together with I.T. brand duct tape.
lksh_dev 4y ago
I used to do implementations for an EDI provider. They were almost always custom. I am shocked there’s a belief that it isn’t custom. Most projects took weeks to just setup a single partner relationship.
WesleyJohnson 4y ago
There are companies that can help with EDI integrations so that both ends can use their "flavor" of EDI and they do the translation. SPS Commerce is one such company I know of. Not affiliated, but we do use them at my employer. I don't work on that team, though, can't offer any thing in terms of ease of use, pricing, etc.
- Brian_K_White 4y ago
  Vans sound convenient but are really just another potential problem in the chain. I only use them when the other side insists on some truely inconvenient protocol I don't want to have to set up and maintain a special windows vm just to run a special client for one customer-of-a-customer.
jetti 4y ago
I worked at a healthcare company at my last job and dealt with the X12 EDI. We had several ETL processes just to convert X12 834s (benefits/membership enrollment) into a common file format because every client seemed to do something different that was not part of the spec. It was hard because we would get the data from clients and since we were taking their money we had to accommodate their butchering of the specs. The thing is, though, that many of the files we received were generated from a COBOL program and then moved to our SFTP server. It isn't like there are many (if any) COBOL libraries that validate or enforce the standards and it isn't like they would be able to just update their COBOL programs to make API calls either.
- donzog 4y ago
  I second that; it is the core of all EDI issues. Outdated software and ancient complex maps that no one dares touch. That's why so many adapter/data cleansing projects spring up to isolate the COBOL-style software from the rest.

SystemOut 4y ago

This is so true. Am in logistics so can't speak to other verticals but every-single-implementation has something unique to it. Either they're on a version we haven't tested on, or they only support some date/time formats, or they have custom codes, whatever.

andrew_ 4y ago
Worked in Logistics and can confirm. AT&T had a dozen different data formats for the same data across their network of warehouses.
themadturk 4y ago
Also in logistics, and agree. There is danger in over-promising with customizations. If you're not careful to you can spend more time and money meeting what the customer wants than the actual business the customer brings in.

themerone 4y ago

Our EDI code probably has multiple if blocks for every customer we communicate with. Implementing EDI is not for the faint of heart. For the variations I worked with, there was little useful documentation, I learned mostly be reading existing code. I would hate to have to start from scratch.

pdimitar 4y ago
I wrote an EDI parser from scratch some years ago (2 to 5, really don't remember). Almost until the end I kept second-guessing myself. It all looked so flimsy. Eventually I made a second parser that utilized a parser-combinator library (the first one was hand-rolled) and devised extremely detailed property tests that I ran against both parsers. Only then did I feel confident. Naturally, in production the code crashed on the second day because OF COURSE the senders didn't obey the EDI[FACT] spec and had quirky deviations from it. Shit like that makes people retire to the mountains and never touch a computer again, man.
- donzog 4y ago
  I still work in the EDI-parser software but retiring to the mountain has never been more appealing.

P5fRxh5kUvp2th 4y ago

that's still not API though. EDI = data, API = functionality. They can work in tandem, but don't have to. you might as well say FTP is an API. In the most technical sense, sure.

sleepymoose 4y ago

Agreed, everyone needs something just a little different. And at least from my experience, the platforms and systems that build the integration are essentially disparate and held together with I.T. brand duct tape.

lksh_dev 4y ago

I used to do implementations for an EDI provider. They were almost always custom. I am shocked there’s a belief that it isn’t custom. Most projects took weeks to just setup a single partner relationship.

WesleyJohnson 4y ago

There are companies that can help with EDI integrations so that both ends can use their "flavor" of EDI and they do the translation. SPS Commerce is one such company I know of. Not affiliated, but we do use them at my employer. I don't work on that team, though, can't offer any thing in terms of ease of use, pricing, etc.

Brian_K_White 4y ago
Vans sound convenient but are really just another potential problem in the chain. I only use them when the other side insists on some truely inconvenient protocol I don't want to have to set up and maintain a special windows vm just to run a special client for one customer-of-a-customer.

jetti 4y ago

I worked at a healthcare company at my last job and dealt with the X12 EDI. We had several ETL processes just to convert X12 834s (benefits/membership enrollment) into a common file format because every client seemed to do something different that was not part of the spec. It was hard because we would get the data from clients and since we were taking their money we had to accommodate their butchering of the specs. The thing is, though, that many of the files we received were generated from a COBOL program and then moved to our SFTP server. It isn't like there are many (if any) COBOL libraries that validate or enforce the standards and it isn't like they would be able to just update their COBOL programs to make API calls either.

donzog 4y ago
I second that; it is the core of all EDI issues. Outdated software and ancient complex maps that no one dares touch. That's why so many adapter/data cleansing projects spring up to isolate the COBOL-style software from the rest.