We receive data in EDI format as well as XML, Flat Files etc and have the capability of receiving data data in multiple protocols like HTTP, AS2, FTP/SFTP, etc. I'm trying to wrap my head around this API concept when it comes to traditional transaction processing since I'm use to doing traditional integrations where someone sends us a file in a certain format via various communication protocols, we translate it, and deliver the translated file via various communication protocols. We can send/receive data real-time via HTTP including EDI data. I have a few questions. 1. In your explanation you mentioned that in EDI, you are waiting for someone to send you the data vs an API you have more control because you are making your info available. Even if you have a URL that is available, aren't you still having to wait for them access the URL to make the request? 2. If you are exchanging PO and Invoice Data, can you give an example of how you would see a PO and Invoice API working vs your traditional Partner sends you PO data via HTTP, you translate it and deliver to backend system?
Hello Thank you for watching the video. We are going to relate this to Retail for examples. An API connection is always available unless the API server is made unavailable. Depending on your system setups as soon as an order is entered in your buyers system you have access to that information instead of waiting for the Buyers system to send you the order. Most people have the API connection check every 5 minutes for any new records. Most Buyer EDI systems are every hour or every couple of hours. Depending on the Buyers system if they use REST or SOAP will answer the formatting of the data exchanged. So think of your API connection checking every 5 minutes for a new purchase order. It finds a record available and the Purchase order information is in a XML formatted file. Then, it is your responsibility to handle the PO XML by what ever means you ERP allows. When you fill that Purchase order and send your Invoice Data out of the ERP. That Invoice is formatted into XML that can be posted via the API onto the Buyers system. You know that it successfully writes to the Buyer system. With EDI you don't know when that actual Invoice is processed until you get a 997 that is based from the Trading Partners processing. Most times the 997 is simply to say if the Invoice was received successfully not processed. Or 820/864/824 about that specific Invoice or you have to check the Invoice Payables portal. Let me know if that helps. Remember, we can't speak to every system or scenario as every one could be different. We can speak to what our team commonly sees :)
Hi, I am really enjoying your videos. Since the beginning of my career, I have been working with EDI, specifically as a data mapping specialist here in Brazil. I want to start learning API, what do you recommend for beginners in this field?
I am glad you are enjoying them and thank you for watching! I would recommend learning how to use the tool Postman and check out common API Documentation like NetSuite or Salesforce or Shopify. If you start reviewing and understanding the documentation along with a common API Tool you will take yourself along way. That is my thought
Thank you very much, you were very kind. I will follow your recommendation and start this process. I wish you success and I will keep watching your videos :)@@EDISupportLLC
@pranayakhadka3507 Typically a sdk describes how a programmer would interact with a system. Api uses a form of http to communicate with REST Or Soap. Along with showing the data available. Most have postman samples with the Api documentation
Thank you, very helpful. I still have a question. EDI is a format and has a structure with Data. So the API also has a structure, does API also has a structure and values/data from the EDI file? Thanks
ANSI X12 is a file format related to EDI. EDI will typically use FTP or AS2 communication. API is a communication that will use JSON or XML file format for its data. Does that help?
Yes EDI is here to stay and will be around for a long time. API is a form of EDI. EDI stands for Electronic Data Interchange. The File format can be anything that contains data
Is this API you're talking about refers to the same Application Programming Interface we all know in computer science. Sorry I'm new to this and big really want to get to wrap my head around it
@@EDISupportLLC Thank you so much for your answer. What text material, video or tutorials can you prescribe to me so I can learn the basics of this EDI ? My interest is in using EDI for Supply Chain and maybe retail. I will really love to get help from you thanks in advance.
Yes it is possible. It comes to reviewing what EDI document you are looking to automate. For example a 850 is received and you are looking to automate the 855. Well then you need to look at the 855 Specifications and see if you can obtain all of that data the 855 requires without having to have human intervention. That means being able to confirm the inventory available, meeting ship dates, knowing which shipper will be used etc... You can do it as long as you have places to obtain information.
We receive data in EDI format as well as XML, Flat Files etc and have the capability of receiving data data in multiple protocols like HTTP, AS2, FTP/SFTP, etc. I'm trying to wrap my head around this API concept when it comes to traditional transaction processing since I'm use to doing traditional integrations where someone sends us a file in a certain format via various communication protocols, we translate it, and deliver the translated file via various communication protocols. We can send/receive data real-time via HTTP including EDI data. I have a few questions. 1. In your explanation you mentioned that in EDI, you are waiting for someone to send you the data vs an API you have more control because you are making your info available. Even if you have a URL that is available, aren't you still having to wait for them access the URL to make the request?
2. If you are exchanging PO and Invoice Data, can you give an example of how you would see a PO and Invoice API working vs your traditional Partner sends you PO data via HTTP, you translate it and deliver to backend system?
Hello Thank you for watching the video. We are going to relate this to Retail for examples.
An API connection is always available unless the API server is made unavailable. Depending on your system setups as soon as an order is entered in your buyers system you have access to that information instead of waiting for the Buyers system to send you the order. Most people have the API connection check every 5 minutes for any new records. Most Buyer EDI systems are every hour or every couple of hours. Depending on the Buyers system if they use REST or SOAP will answer the formatting of the data exchanged. So think of your API connection checking every 5 minutes for a new purchase order. It finds a record available and the Purchase order information is in a XML formatted file. Then, it is your responsibility to handle the PO XML by what ever means you ERP allows. When you fill that Purchase order and send your Invoice Data out of the ERP. That Invoice is formatted into XML that can be posted via the API onto the Buyers system. You know that it successfully writes to the Buyer system. With EDI you don't know when that actual Invoice is processed until you get a 997 that is based from the Trading Partners processing. Most times the 997 is simply to say if the Invoice was received successfully not processed. Or 820/864/824 about that specific Invoice or you have to check the Invoice Payables portal. Let me know if that helps. Remember, we can't speak to every system or scenario as every one could be different. We can speak to what our team commonly sees :)
same here! also nice take a look of troubshooting ideas when it comes to the integrator we set those connection
Great video!! Very informative and explained a lot of questions I had!
Glad it was helpful!
Great explanation for my cluelessness. Thanks
Glad it was helpful!
Love this! Very informative. Thank you so much😁
Glad you enjoyed it!
Hi, I am really enjoying your videos. Since the beginning of my career, I have been working with EDI, specifically as a data mapping specialist here in Brazil. I want to start learning API, what do you recommend for beginners in this field?
I am glad you are enjoying them and thank you for watching! I would recommend learning how to use the tool Postman and check out common API Documentation like NetSuite or Salesforce or Shopify. If you start reviewing and understanding the documentation along with a common API Tool you will take yourself along way. That is my thought
Thank you very much, you were very kind. I will follow your recommendation and start this process. I wish you success and I will keep watching your videos :)@@EDISupportLLC
@@diegorezende3994 thank you! Keep learning!
Great elaboration 😊😊
Glad it was helpful!
It was very helpful but I have a question. What is the difference between API and SDK (Software development kit)
@pranayakhadka3507 Typically a sdk describes how a programmer would interact with a system. Api uses a form of http to communicate with REST Or Soap. Along with showing the data available. Most have postman samples with the Api documentation
Thank you, very helpful. I still have a question. EDI is a format and has a structure with Data. So the API also has a structure, does API also has a structure and values/data from the EDI file? Thanks
ANSI X12 is a file format related to EDI. EDI will typically use FTP or AS2 communication. API is a communication that will use JSON or XML file format for its data. Does that help?
Is API going to be an alternative to EDI going forward with so many new B2B apps and platforms (and more coming up)?
I truly believe Api is going to be an additional option not a replacement.
Does Edi has good scope in future.. Please suggest , i am new to Edi .
Yes EDI is here to stay and will be around for a long time. API is a form of EDI. EDI stands for Electronic Data Interchange. The File format can be anything that contains data
API could be used to transfer an EDI
@essaberyahya709 ok I can agree from a technical standpoint. But it's usually xml or json
Is this API you're talking about refers to the same Application Programming Interface we all know in computer science.
Sorry I'm new to this and big really want to get to wrap my head around it
Yes it is. Alot will refer too it as API instead of spelling it out. Thank you for checking out the video
@@EDISupportLLC Thank you so much for your answer.
What text material, video or tutorials can you prescribe to me so I can learn the basics of this EDI ?
My interest is in using EDI for Supply Chain and maybe retail.
I will really love to get help from you thanks in advance.
@@hafisodunuga7438 I would suggest ediacademy.com/ and following this channel. Check out our website www.IHateEDI.com
another resource is www.edibasics.com/what-is-edi/
@@EDISupportLLC Thanks so much for this
Is it possible to automate EDI files being sent?
Yes it is possible. It comes to reviewing what EDI document you are looking to automate. For example a 850 is received and you are looking to automate the 855. Well then you need to look at the 855 Specifications and see if you can obtain all of that data the 855 requires without having to have human intervention. That means being able to confirm the inventory available, meeting ship dates, knowing which shipper will be used etc... You can do it as long as you have places to obtain information.
When should I use EDI versus API? Is EDI or API better in e-commerce?
If you are familiar with API then I would say use that as you can get Real time results. I think it is better in e-commerce
So with API all fun dies
Api wont replace. Its simply another option in a lot of cases