CODEWITHSUNDEEP
edi
ranjit
ranjit

Reputation: 25

What is Needed at Receiver side for Receiving EDI documents?

I have Transport Management System. Now one of my carrier want to send me EDI document for Shipment Tracking. that document is EDI 214 (Transportation Carrier Shipment Status Message).Now I'm not clear what I'll need at receiving side. I did some search on google and there are lot's of information regarding EDI and it's workflow. But I'm not clear what should I need at Receiver Side. Do I need to open any port at my side for receiving document ? Do I need EDI Translator software ? Please Help me as I'm new to EDI.

Thanks so much for any help.

Upvotes: 0

Views: 166

Answers (2)

David Kanter
David Kanter

Reputation: 51

The good news is that receiving X12 is typically easier than generating X12, so your use case is simple relative to bi-directional communication. You are receiving X12 EDI 214s, so it is a single flow in one direction.

The best way to think about this is to ask 1) what is my input I am receiving? and 2) what is the output I want to generate? You are receiving an EDI 214, so presumably you want to generate a JSON/XML/CSV object with just the tracking data that you ERP (system of record) can ingest.

So you need a few things in a typical "EDI architecture"

  1. File transfer protocol (an SFTP is easiest) that you trading partner can connect to and send files to
  2. You need to translate that X12 to JSON (you should check out www.stedi.com/docs/edi-core to do that)
  3. You need to "Map" that file to your output schema (and perhaps convert it to XML/CSV)
  4. You need to post that file to your ERP system
  5. You need to send an EDI 997 (acknowledgement) back to the sender to say "I got it" (think of a read receipt on SMS). Note: some times this is optional

Upvotes: 1

Andrew
Andrew

Reputation: 2839

EDI is text, formatted a specific way (aligned to a published standard). To receive files, you have options (but also depends on what the sender supports). Everything from email to 3rd party value added networks, to signed/encrypted HTTP pushes (AS2).

You'll need to agree how you're trading these electronic documents. Once you receive it, then you'll need to parse it. This can be done using 3rd party translators, or you can write it yourself. If the partner requires a 997 (an acknowledgement you received the file), you'll have to generate that. Most 3rd party tools will do that for you. 3rd party tools typically consist of a mapper (drag and drop from source to target) as well as communication mechanisms. Some are cheap, some are expensive. It depends on what you and the sender agree upon to get to the level of effort that you have.

For simplicity sake, you could just set up FileZilla FTP and have the sender place the order there. Then have a process (script, program, etc) to pick up the file, parse it into something your ERP/WMS can understand (XML, JSON, CSV, etc). Again, that assumes the partner supports clear FTP. Some partners demand encryption.

Upvotes: 1

Related Questions