Translate Between JSON and EDI | Hacker News Reader

Translate Between JSON and EDI

stedi.com

22 pointssid637612 comments

Stedi is the game changer when it comes to EDI. Let me take you on a journey. My company is building out a TMS for shippers. First few months we would only integrate with carriers that have APIs, because like {bena} said "EDI is a btch", so we wanted to avoid it at all cost. Eventually, it came time for us to take on the dreaded EDI integrations. Oh man, how I hated it. Stack Overflow could not save me. Storing the files on AWS or GCP would have been easy-ish, but then the real challenge of needing a trigger every time a file is drop onto the buckets. GCP has nothing clear. And AWS is evil. So I had to keep looking and looking. And then I remembered a company I chatted with 8 months prior, Stedi. They just now released the feature I was needing. "Buckets and Triggers". It was heaven sent. I could now host my EDI solutions on Stedi ({AnEro} says that it might be cheaper to build it in house. But the thing is, EDI is not our core competency as a company. We want to focus on providing different values for our customers. So would rather not having more technical debt with no meaningful impact.).
The journey continues...
Stedi overs 4 pillar features. Buckets, Triggers, Guides, Maps

The buckets and triggers is what hooked me. The guides and maps is what has been saving me. You see, EDI is a confusing btch. And trying to map out my json to those EDI files is a nightmare. Well, would be a nightmare without Stedi. Their UI makes it simple and easy to do. I'm able to now enjoy life again. Smile, laugh, love. All because of what Stedi is doing to shake up the EDI world.

In Stedi We Trust.

DISCLAIMER: I am not affiliated with Stedi in any way. Not financially nor socially, only emotionally because I love their product that much.

EDI is a bitch. X12 is not great. IIRC, and it's been a while, so I may not, it's essentially a positional Character Separated Value stream. You basically build a string and fill in data or nothing as appropriate. For example the result looks something like

*START*VALUE1*10.00*BOB*DOLE*100*ADDRESS*STREET*

Where the double asterisk is where a blank value is.

However, it is a standard. It is knowable. You can get the ANSI X12 standard for whatever industry you're in and implement this.

And let's be clear, you still have to do the dirty work with these guys. You still have to map values to fields, which is the hard part of working with the format. Once you have that, you can knock this together fairly simply.

It's definitely possible to write simple EDI transactions (no HL loops, etc) with a couple of trading partners using something akin to mustache templates – many of our customers come to us after getting something basic like this up and running in a day or two, and then hitting complexity.

It's difficult to use the method you're describing to write a transaction like this, particularly when the receiver's system can fall over due to a single character out of place: https://www.verizon.com/business/support/vec/onlinehelp/dam/...

(I'm the CEO of Stedi)

I had to process ANSI X12 835/837 sending and receiving.

So, you know, Healthcare billing information. It's tedious, but the worst part is the mapping from your own data source to the format. And you don't help with that part.

Yep, there's no way around mapping – the data has to get mapped somehow. The 835/837 are a bear. You can save some time if someone has built a mapping template already – say, from a transaction type in Oracle to the 837 – but if it's a custom system you're mapping to/from (like a homegrown API), it's impossible for a template to exist...it has to be done from scratch.

We've found that many of the fields end up being single-item enums, so those can be hardcoded (i.e. no mapping required). Guides (https://www.stedi.com/products/guides) generates JSON Schema for you, and Mappings (https://www.stedi.com/products/mappings) automatically populates any single-item enum. Both are free to configure in the UI.

Stedi is a fantastic platform. I absolutely despise EDI with a passion and Stedi has saved me from working with it. All their tooling and solutions for buckets, FTP are so well thought out. What a great company and vision to modernize EDI.

No option presented for installing locally, must make all calls to their api servers.

It's SaaS, hardly an unfamiliar concept! Our TMS uses at least a dozen services that work the same way. But to echo what other people in this thread have said: Stedi is a total game-changer. Their platform is outstanding and their support is second-to-none.

>a new API for creating and validating EDI files that conform to precise trading partner specifications

Unless you can host this locally this seems like a deal breaker in many industries (healthcare, insurance and perhaps others)

Even after the contracts being signed to make it complient, it was the pricing for what it is that gets us. It would be cheaper to write our own translation tool for our specific needs after 3 months of usage, and we are at a smaller scale than most for api calls.

Not sure which sweet spot they want to hit with this

What sort of scale? Would love to see the math. (Context: I'm the CEO – if our pricing doesn't make sense for certain use cases, I'd love to dig into it)

We have lots of customers in regulated spaces – healthcare is a big one – but it's definitely a dealbreaker for certain companies that have hard rules for running everything in their own environments.

Reply on news.ycombinator.com