EDI Without the Headaches: AI Automation for Trucking

EDI Without the Headaches: AI Automation for Trucking

EDI Without the Headaches: AI Automation for Trucking

Webinar Icons Time

Session Time

45 Minutes

Webinar Icons Date

Thursday, March 19th

12:00 PM - 12:45 PM CT

EDI doesn’t have to be a bottleneck. In this 45-minute live demo, we’ll show you how Eradani Connect uses AI to take the complexity out of trucking EDI, from onboarding a new trading partner to handling the inevitable curveball of bad data. 

You’ll see us build a real integration for a new business partner, monitor all EDI transactions, troubleshoot a partner error in real time, and resolve it fast. No waiting on a vendor. No guesswork. Just a clear, repeatable process that puts you in control.

If your team is tired of unpredictable costs, slow partner setups, or EDI platforms that feel like a second job, this one’s for you.


Transcript

Maia Samboy
Hello, everyone. Welcome. We’ll give it just about another minute and then we will get this party started.

Maia Samboy
I am Maya, here with Eridani and I’m here with Dan and Erin. And today we will be talking about EDI without the headaches. AI Automation for trucking. We have a really cool presentation and some demos for you guys today. So I know we only have 45 minutes, so I’m going to pass it over to Dan to get us started with a little introduction. If you have any questions throughout, feel free to just put them in that Q and A box that’s on your zoom bar below, and we will try to answer them throughout and save a little time at the end if anyone else has any more questions. Also, just a heads up, we are recording and everyone who’s registered will receive the recording tomorrow morning. So, Dan, you can take it away.

Dan Magid
Sounds good. Thanks, Maya. Yes. So I’m really looking forward to this because we’re addressing an issue that we hear about all the time out in the marketplace, and that is how do you deal with this EDI technology that’s been around for, I think, 60 years now or so, maybe even longer than that, and how do you keep it up to date as what we’ll see is that it’s still growing, it’s still being a bigger and bigger part of business. So real quickly, what we’re going to talk about, I’m going to talk a little bit about the fact that EDI is still ubiquitous. It’s still out there, it’s still being used by lots and lots of companies. It still is a very central part of the supply chain. We’ll talk a little bit about the challenges of dealing with EDI in the modern environment, and then I’ll talk a little bit about how Aerodyne can help. But mostly the main focus of this is going to be the demonstration that Aaron is going to do. So Aaron’s going to show you some things that you can do to help eliminate some of those challenges of edi. As we’re going through this, if you have questions, please please post them to the Q and A section.

Aaron Magid
And.

Dan Magid
And while I’m talking, Aaron will try to answer them. And while Aaron’s talking, I will try to answer them, and then we’ll also try to get to them at the end and hopefully we’ll also leave a few minutes for questions once we’re done with the presentation. So real quickly, you can just see that EDI use continues to grow and is expected to continue to grow, and a big chunk of that is in the whole supply chain environment. So there’s lots and lots of stress stuff still being done in edi. And you can see it’s billions and billions of dollars of transactions. In fact, I think it actually goes into the trillions now of dollars that the value of the transactions that are being handled inside of the EDI world. So here you can see $4.8 trillion in 2024, with $4.8 trillion of transactions being handled in EDI. So EDI continues to be a very, very large part of, of our business environment. So what are some of the challenges? What are some of the things that make EDI difficult? And again, these are things we are hearing from customers out in the field. And one of the biggest frustrations is the time it often takes to onboard a new EDI partner. Because once you’ve set up in a relationship with a customer, you want to be able to start working with them immediately or a new supplier or a new channel for your, your products. You want to be able to get that going as quickly as possible. And we’ve had customers tell us it can take four, four to six weeks, even months sometimes to onboard a new partner. And the reason is, is that EDI is what we call the non standard standard. It’s that people have actually tweaked the EDI document. So even though EDI is supposed to be the standard way of sharing information, customers have, have customized those documents. So you have to figure out, okay, so how do I deal with the way this particular part using this particular document type? And so it can take time to onboard those new partners. And then people often change what they’re sending in their EDI documents. And so you have to maintain that. You have to keep up to date as your partners make changes in the documents that they’re sending or what they’re requiring from you. And the documents you send. EDI often also requires an EDI specialist because the x12 standard, they’re kind of cryptic the way EDI documents work. And so you need somebody who really understands how does an EDI document work, how is it formatted, what are the different segments of an EDI document and how do they work? And how, how does the data get into the EDI document? How does it come out of an EDI document? So oftentimes there are EDI specialists in the organization and you’re very, very dependent on, on those people. And then how do you do the data transformations? Because EDI document may have to go into your database, into a relational database, which is a Very different way of storing data than the EDI storage methods. Or maybe it has. You have to use that data to call a program, or maybe you create another EDI document from that, or you create other kinds of documents from the EDI data. So how do you perform those data transformations from the EDI documents into the format that you need them in and then monitoring and handling errors in the document? So one of the issues is that there can be errors in the document where the partner is sending you the wrong kind of data in the wrong fields. And how do you track those, how do you make sure you respond very quickly to any defective documents? And how do you deal with, when you have a very large volume of EDI documents that you’re processing, how do you trap the errors in a timely fashion? So we’ll talk about all of those things. So some of the things that Erdani can help is we have been able to accelerate the speed in onboarding new partners. And we do that by using our Erdani Connect software for generating the mapping code so that you basically can give it samples of the EDI document and then samples of what the data needs to look like in the target in the database, for example, and it will automatically generate for you the mapping code. So you don’t have to wait for a vendor to, to write the mapping code for you or to do it on your own. It will generate that for you. And then once you’ve generated the onboarding and you’ve got the partners online, you can then monitor it. We have monitoring dashboards for monitoring all of the transactions and for dealing with defects in the documents. And that’s some of the things that Aaron’s going to show you in just a second. But this is just a sample of monitoring. So you can monitor the, you can monitor the EDI transactions. In here you can see, I can see things like total transactions, the success rate. You can see transactions by partner, transactions by EDI document type. You can see lots and lots of information about what’s happening with your EDI documents. And again, Aaron’s going to show you how you can monitor for errors that come in or defects in the documents. You can monitor and see what’s happening with those. And, and you can then respond to that. Actually, here I can, I can show you a. Let me show you a sort of live version of that.

Dan Magid
So here, here you can see the actual. Here, here’s the, this is the live dashboard of, of that information that’s coming in. So you can, you can track all the data that’s coming in. So anyway, with that, I’m going to go ahead. Oh, actually, no, wait, one other. I want to. Forgot one other slide. Hang on, let me bring up this one other slide. Share the slideshow here.

Dan Magid
So when we generate that stuff, we’d want to generate more than just that connection. We also want to generate lots of the things that the connection has to do. So we’re going to generate the security, so we’ll make sure that those EDI connections are highly secure. We’re going to generate that transformation code to transform the data from the formats, from the EDI formats into other formats, formats like JSON or XML, or into your IBM IDB2 data or parameter data. So we’ll do all those data transformations for you. We’ll check the data to make sure that it’s valid and again give you ways of dealing with invalid data that’s coming in. And we do all the logging and error handling for you and setting up the monitoring. So with that, now I will turn things over to Aaron, and Aaron, you want to go ahead and show some things?

Aaron Magid
All right, great. Well, thank you very much, Dan, for that intro. I am very excited about this technology because one of my responsibilities at Eridani is actually to oversee some of our EDI implementations. And so I get sort of a first, a sort of firsthand view of exactly what goes on when we are working on an integration and also what the previous state was. You know, working with a lot of different companies, I get to see some fun situations. I’ve seen some crazy things. I have some war stories from, from, from some environments that we’ve stepped into where things were pretty messy. And that’s, you know, those environments are really where the inspiration for these technologies comes from. And one thing that we do at Eridani, we’re very, we’re very firm about this, that our product design comes from what we actually hear on the ground with our customers, because we want to make sure that it’s something that comes from a, you know, a real place, real problems, not just what we’re theorizing. So everything that I’m going to show you here is actually backed by real experiences that we have run into. And I hope some of it will, will resonate with you if you’re working in EDI in your companies. So the first thing for any integration, any EDI integration, obviously, is getting it up and running, right? How, how do we get an EDI integration up and running? And this is something where we’ve put a lot of, a lot of the effort. A lot of the design work and a lot of the new parts of the process live here in the process. Because in talking to EDI companies and companies that have to work with edi, what we have seen is that probably the biggest headache that, that we found among EDI users is trying to get new trading partners live. And then, and then after that, troubleshooting when things go wrong. And one of the reasons for that is as Dan mentioned, EDI has traditionally been a fairly cryptic standard. You need experts with a lot of experience generally to work with it or purpose built tools. And those groups in our experience typically become a bottleneck.

Dan Magid
Right.

Aaron Magid
We work with a lot of companies where they are working on some EDI integrations. They’ve got some things in production, they have a whole process and a whole team. And when they, and still when they want to get a new trading partner live, when a new business partner comes in and wants to set up communication with them, they’re still looking at a six to ten week delay just to get something live. And so that was the first problem we wanted to attack. And that’s the first thing we’re going to do here is generate an EDI integration. And I just want to say up front that what we found in our process. I’ll talk through the process in a minute. But what we found in our process is that we can typically get an EDI integration from zero information to production in about an hour. And the target of this process is to do the entire integration while we are on the phone. That’s really what we’re aiming for here and that’s what we do when we do these EDI integrations. So with that, let’s take a look at what this looks like. I’m going to share my screen here and bring up my EDI workbench.

Aaron Magid
All right, so what I’m looking at here is, is my main EDI workbench. This is where I have all of my utilities available. Some of you may recognize these kinds of interfaces. What I’m going to do first is I’m going to say, okay, I need to generate an EDI integration to start that up. And the one that I’m going to generate here, I got a new trading partner here. I’m going to do EFG2 when you do a 204. Okay, so I want to process an incoming 204 for the EFG to trading partner. That’s basically what I told the system. Now what it’s going to do is it’s going to generate the basics of that integration. And then it’s going to come back to me and it’s going to say, okay, but what’s the complicated stuff here? Right? Because generally speaking, EDI integrations aren’t as simple as oh yeah, I need a 204 with this training partner, go process it for me. Right. As Dan mentioned, first of all, for the entire lifetime of edi you’ve had to deal with situations where we have non standard documents, we have custom processing rules, we’ve got specific requirements that we need to adhere to for, you know, for, for a business partner who decided to make up their own formats. Right. We deal with that kind of thing all the time. But beyond that, there are actually even more requirements that we’re seeing now. In the last few years we’ve seen an uptick in what we call hybrid EDI integrations, meaning integrations where it’s EDI on one side and a completely different technology on the other. The most common example that we see in trucking and logistics is very common. We’ll get a 2:14 that comes out from a carrier and then that needs to go out to, gets translated into an API call to a logistics system that goes to a REST API on the other side. Right. So we’ve got EDI data coming in on one end and we’ve got JSON API calls going out the other side. We’ve also seen integrations where companies want to take in an EDI document and then publish a Kafka message or something like that. You use event broker systems to get data out to where it actually needs to go. So these integrations are getting more complex and, and that’s why we took this strategy here. So what I’m going to do, I told my system that I want to generate an EDI integration that goes from a, an incoming document to my core database. That is the most common integration that we see. So that’s the one that I’m going to use here. And it came back and it said, okay, I generated the basic integration for you. Should I make any changes to that integration? And it’s asking me for some samples of the data. So what I’m going to do here is I’m going to answer that request, I’m going to come in here, I’ve got a 204 here that I want it to process and I’ve got some samples from my database that I’m going to give it. This document needs to go into two tables. We got a DMO 204 drop in that sample and I’m also going to take in my DM0204D, drop that guy in and generate that integration. And what that’s going to do is it’s going to take my EDI document, it’s going to run it through a check to see what is non standard about this. Because there’s almost always something that doesn’t fit with the external specific. So we’re going to pull out exactly what we need to know about the document, map it all to the internal system that we need to talk to, build out all the mappings wherever possible and create the completed integration. Now this is really where the key process is. After this initial generate, we go into what we call our refinement loop. So it just finished its first pass on the integration. And typically what’s going to happen when you do one of these integrations, right. The first pass of the integration is likely going to be mostly correct. That’s usually what we see. But usually there will be something in the data that’s non standard or there’s something that we can’t quite map, you know, based on the data that we got. So what’s going to happen is the system is going to come back and it’s going to say, okay, well there’s something that I couldn’t figure out. So the way we do this process is at this point I have my integration, I can send a document into that integration, I can process it and I can see the results and then I can come back here and I can give it some more feedback on the integration. Right. This is how we get from, you know, what I’ve been doing. The work here, minus my explanation has probably been about, you know, 90 seconds of actual work in here. That’s how we get to the, you know, to the hour, you know that it takes on the phone to get one of these integrations to production. Right? Is we’ll generate initial integration and then we go in and we say, okay, what’s wrong with it? What do you need tweaked? We run that against the system, we try it out, get the feedback, feed it back in, the system will update the integration and then we try it again. Right? That is the process. And what that allows us to do is rapidly build out integrations. And that’s something that our team can do. It’s something that our users can do independently of us as well. So what I’m going to do here is I am going to go process a document. So I have that same 204 loaded in here. I’m going to Send that guy over. That’s going to process in my system. And at that point that data has been handled by my application. It actually went through that process and it really processed the data. And I can show that actually by going over to my dashboard here and I can see here I’ve got a transaction that was received by the system, right? And if I open that up and I take a look at that transaction, I can see that this is the 204 that I sent earlier, right. Just to pick out some values. So you can see that EFG2 got the same trading partner ID I got same information here, same addresses, same same values that I just put into that interface, right? So I can see exactly what happened in the system, right? And this is how we feed that process. If we had a problem with the integration, that would be the next thing that we would handle in the onboarding process, right? And again, that’s what allows us to get these integrations live in really what is a single conversation. But let’s talk about what happens when there’s an error, right? I think that’s a. Another key point here, right? Once you have an EDI integration live, once you’ve done the work to get that out, the next thing that we’re going to need to deal with is the inevitable case where you have a live integration and somebody sends you bad data or your system has a problem and the data cannot be processed. So what I’m going to do is I’m going to submit another document here. And so I’ve got this document that has the same address, this one, 234 Mendocino Blvd. But let’s say that I had a user who just had a little bit of a problem while they were entering the, the information into the system, right? And this is the actual EDI document that comes out. So I’m going to send that into the system. And once I do that, we’re going to get an error back. I’m going to get an error notification back from my system, which I can see on my dashboard that I’ll show you in a minute. And that’s going to cue me to take a look at my transaction dashboard, which is this system that I’ve been showing you. So if I go back here, I can see that there is an errored transaction in here, right? So it knows exactly when that came in. It knows that there was a problem. So let me take a look at that transaction. What this transaction is going to show me is that first of all it errored and it was an error that had to do with the document contents itself. So I can tell that there’s something wrong with this document. Now, if I’m an EDI expert, I might take a look at this document and look around for the error and try to figure that out. But most errors are not going to be quite as visible as, you know, a hundred A’s at the end of an address. So what I’m going to do here is I’m going to pull up the logs from my EDI integration, right? So in addition to seeing the actual document, and in addition to seeing the processing metrics and the times and everything else related to this transaction, I can also see exactly what happened while the system was processing this particular integration. Right? So I’m looking at these logs and I’m just going to scroll down and we can see in the logs, okay, at this time, I got the initial document received. I see it coming into the system. I see that the document text has been processed. I see that it detected it as a standard EDI document and it’s parsing it. I can see that that step succeeded. Okay, I can load the results if I want, go through the next processing steps, and eventually what I’m going to see is that it did encounter an error. Okay, so it says this EFGH 204 inbound processing of that document failed. Okay, so let’s take a look at that guy. Now, if I pull this up, what I’m going to see is the actual raw log information that came out of the system. That’s going to tell me, okay, we’re talking about. Now, here’s the ID for this, for this log. Here’s my partner, here’s my document type. I can see exactly what it was working on. And if I scroll through this, what I’ll see is, aha, the input data. Oops, hold on. The input data was too big to fit into the field. Okay, so I see an error there. That is where we start getting into actionable information. Right? So as a, as an experienced user in here, right. I know that I can go into that log data. I know that I can read that. I can see that that data is too big. I can see that there was something that was, that was outsized for this integration. And I can then take that back. I can go back to my inbound interface here, and I can see a likely culprit here. Right? So this is where I would be able to resolve this problem. And I can actually edit in here if I want to. I can go in here And I can edit this document and I can resubmit it

Aaron Magid
so that that really is the most basic path here for resolving an error. Right. I have access to everything that’s going through my system. I have access to all of the data I have, I have access to all of the logs and I can work through it with that process. But let’s take this a step farther because we live in the AI era, so no demonstration is complete unless you use an AI tool. But in all seriousness, this tool is more than just sparkles on this application. One of the key problems that we’ve talked about with EDI is, is not just that it can be hard to get a trading partner live. It’s not just that we’re waiting on people, but it’s also the expertise that is required to actually get one of these integrations live, and the expertise that’s required to actually understand the data and actually take and actually resolve the issue that has to that happened with this transaction. So the next thing I’m going to do is I’m going to take out the expertise requirement. I’m going to come over here to my assistant, and my assistant here understands everything that there is to know about this transaction, right? So over here I can say, this transaction encountered an error. What went wrong? I’m going to send that over. That assistant has access to every part of this dashboard. It knows the, what the data is that was sent. It knows what the data was that was written to the database. It knows exactly what the logs are and exactly where it is. And you can see actually here, without reading the entire message that came back right at the end, it’s asking me, hey, would you like me to fix the N3 segment by trimming it to just this 1, 2, 3, 4, Mendocino Boulevard. It actually knows exactly what is wrong with this document. If we scroll up a little bit, it’s going to give me a much more detailed explanation. Right? It says, okay, your logs are pointing to a clear, specific error. We have. This input data is too big to fit into the field. The database rejected the insert because that value was too big. And it says the culprit was my N3 segment. And it’s even going to give me a snippet of exactly what was wrong with that data and then come back and say, oh, yeah, okay. The address line has a massive string of A characters appended to it. It’s clearly corrupted or padded data. This field has a maximum length of 55 characters. This value far exceeds that. Right. So there’s a critical thing here, right, which is this is intelligently working with the data. Right. In the past, if I had an automated tool that was sort of a deterministic algorithm for fixing these things, what it would have done most likely is truncated the data at 55 characters, which means you’d still have a whole bunch of A’s at the end of that address. But this is an intelligent system that is actually thinking about what needs to be done with the data and proposing updates. So it’s actually reading that and going, oh, yeah, the correct address is probably 1-234-MENDOCINO BOULEVARD that’s probably the actual address here. So it’s going to recommend that to me. So it asked me if it should fix it. I’m going to say, yes, go ahead now, because we’re dealing with business transactions, it’s going to come in here and tell me very concisely, here is exactly what I’m going to do to the, to the, to your data. Before we’re going to have this with all the A’s on the end after, here’s what the M3 is going to look like. It’s asking for confirmation. I’m going to say, yes, go ahead and do it. And what it’s going to do now is take care of the entire process of fixing this document.

Dan Magid
Right?

Aaron Magid
That means it’s going to go into the document, it’s going to apply the change that we’ve discussed in here to fix the data. It’s going to update the stored document here, and it’s also going to parse the document and check it to make sure that after the edit, everything is valid. So if you look at my interface here, it says, okay, the inbound document has been updated in the editor. Review the changes and click Resubmit inbound to apply them. And I can see that if you look at the interface, yep, that address has been changed. It does actually have the updated data there. So I’m going to go over here and I’m going to say, okay, let’s resubmit that document. It’s going to ask for confirmation. Yes, go ahead. And it says, yep, okay, we resubmitted that transaction. And when I hit okay here, it’s going to take me over to the new transaction. So every transaction is going to be tracked as its own transaction with references to all of the older or related messages that we’ve received. So at this point, I can see in my interface that I have a transaction here that was completed and I can see when it was sent, when it was Handled what type it is, who it was going to. And I can see everything that has to do with this transaction, right? So for example, in here I can say, okay, here’s my data, just like I did with the error logs. Here are the logs. Here’s everything that happened when I was processing that document. So if I need to see if there are any warnings, if anything might be wrong, if I want to look into something, all of that’s in there. And I can even see exactly what database, right? So this is coming back. If you remember, when I generated this integration, it was going from an EDI document to my database. So after all of this I’m looking at here is the exact output that came from my mapping system. And this will cover whether you’re going to your database or going to a custom flat file format or to another EDI document. Wherever your data is going, this will show you where did it end up, what happened at the end of the integration. Right, and that’s critical for that refinement loop that we talked about earlier, right? Getting the output and saying, okay, maybe something wasn’t quite right, back to the system and refining the integration.

Dan Magid
Hey, Aaron, there’s a question.

Aaron Magid
Oh, great. See those?

Dan Magid
What happens if it. What happens if a trading partner sends a new segment or element that is not mapped?

Aaron Magid
Yeah, great question. So that is actually up to you. When you generate the EDI integration, there are two strategies here. One is ignore, the other is error. Right? Those are basically your two options. Now, when those. So I want to address two parts of this situation, right? One is how we get to a place where we have a new segment that’s not mapped and how we can avoid that situation.

Dan Magid
And.

Aaron Magid
And then the other is what to do when it happens. So let’s say that it happened. Let’s say that we got a new thing. We didn’t have any logic for it. When you create your integration, you’re going to tell the system what you want it to do. The default is that it will ignore any unrecognized data. You can tell it, though, if there’s unrecognized data in here that I didn’t map, I want you to error. In which case it would show up in this interface, you’d see exactly what the problem is. And at that point you can either fix the data so that it fits with your integration, or go back to your assistant, tell it about the new field, and it will update the mapping to have that, and then you can resubmit the document so that it gets processed Right. That’s the other way that you can handle that.

Aaron Magid
So that’ll take care of the situation where you get one right. You, you don’t have to lose the document because if it’s a mistake on the customer’s part or on trading partner’s part, you can fix the data resubmit. If it’s something you’re missing in your system, take that document, give it to your EDI assistant, it will regenerate the mappings based on that new segment that you have, and then you can resubmit the same document through this interface as soon as that update goes out, which usually takes a couple minutes, and then you’ll process it successfully. Right. But let’s also talk about how we avoid this happening in the first place when we do an EDI onboarding. The main part of the onboarding process is gathering samples of the actual EDI data. So typically what we’ll ask for, because most companies already have an EDI footprint, our standard ask in an onboarding is three months of EDI data. So just to give you a sample, Right. We did one of these plans recently for a company they gave us, for a logistics company, they gave us an export of all of their EDI documents, and that export included about 700,000 EDI documents. That’s basically what we’re looking at. Right. The reason why we need that data is we’re trying to establish a representative sample of the data that you’re going to be receiving from your trading partners. Once we have that, we can feed that into our tools and it will generate all of the integrations that fit the business rules that are represented in that data sample. Right. So that’s, that’s really the way that we address this issue upfront. If it’s an existing EDI integration that’s transitioning over to aerodync, at that point, we take the historical data, we feed it in, and it will be able to determine all of the business rules and get it generated successfully. If it’s a new trading partner, we ask for a healthy sample of test documents from that trading partner and that’s how we’re going to try to catch all those business rules and get those, get that data in to the generator, along with their implementation guide, of course, so that we can effectively hit all those segments. But that’s a great question. You know, really it’s, we’re trying to make sure that we hit on both sides, that we address the issue up front. And also if something gets through and you have a problem, you have a quick way of resolving that issue. By the way, this is actually something that I was on a call personally with one of our customers doing this recently. They got a document that didn’t fit, that had a new condition in it from all the other integrations that they had done. It was a new code that needed to be processed differently, not a new segment. But what we did is got on the, got on the phone with them, got the errant documents, fed that into the system, it regenerated. I forget how long we were on the call for, but it was somewhere between 30 minutes and an hour and they had the update pushed out to, to their system.

Aaron Magid
All right, next question. Very good question. What AI model is being used and how is proprietary data protected if the model is using customer data to learn from? Very important question. We want to make sure that all of our data is secure. So there’s, there are a couple of things to note here. First of all, Erdani Connect is not sending any of your EDI data to an AI model unless you ask us to. So that’s the first thing to understand, right? Unless you actually go in and you feed in a sample to the assistant, or unless you go in and you actually ask a question to this assistant in the transaction dashboard asking about your EDI data, none of that data is going to hit any AI model. That’s the first thing. The second thing is that the generator assistant, as a coding agent, goes through our systems so that by default we can ensure that those systems are only using models that will not learn from your data. So that’s the second piece we’re making sure on our side it’s not just going to, you know, we’re not just taking the data and piping it over to GPT, right? This is going through our systems so that we can control what models are being used so that we know that things aren’t going into just a public models box that they can do whatever they want with. But this is also an important point because we work with some companies that have intense restrictions. You know, we do this EDI outside of, you know, logistics. We work with with retail manufacturing, we work with, with insurance companies where we have extremely restrictive security requirements. And in those cases, the EDI or the, the coding assistant that is available in the workbench can be directed to a custom model endpoint. Now that’s not quite as effective as going at our system because our system is doing a lot more than just sending it to a model. It’s actually going through a whole workflow that we’ve set up along with some deterministic processes that we run. But you can take your, your coding agent and you can direct it at a custom model. So that means if you have an internal company model that’s hosted on your infrastructure that you want to use, right? If your company has a, a locally hosted model, you can direct it there. And that, that is the surest way to be absolutely certain that nothing is going to any public models, that nothing’s going anywhere because it’s never leaving your network. Right? So that’s really, really depends on how strict your company wants to be. And we see a lot of different levels of that. Just to summarize that, right? By default, all of the, first of all, only the data that you actually give to the assistant intentionally is going to an AI system so you don’t have to submit things that you don’t want to submit. Second thing is that our environment will always use models that do not learn from your data. But the third thing is if your company has restrictive policies and needs to be absolutely certain, you can redirect your coding agent to face to use an internal model. And at that point you’re, you know, then it’s never leaving your network. You don’t have to worry about it. It’s a good question though. Definitely a critical requirement for, for modern AI systems. Okay, cool. So looking at this data, I just have a couple more things that I wanted to go through here. And by the way, you know, keep them coming. If you guys have more questions, please feel free to ask.

Aaron Magid
Most DDI transactions are not going to just be one document, at least not the critical ones. So one of the things that I want to be able to do here is say, okay, let me look at this data. Now this is a case where I’m going to tell the assistant I want it to read my data. So it’s going to use that.

Aaron Magid
And what I want to do is I want to see all of the data related to all the transactions related to this particular BO number. So I’m going to take this guy out of here and I’m going to go over to my search here. And what I can do here is paste in that number. I can do this with any segment, any field, any value in any of my documents. And I can see all of the transactions that relate to that reference that particular value, right? So this is an important point because as I was processing this 204, I actually submitted it three times, right? I did a first submission with the new integration that I generated. Then I submitted the Errored integration. And then finally I submitted the corrected version, right? And I can see all of those documents in here, right? And if I had any other transactions relating to this, you know, for example, if there was a 990 I needed to work with, that would also be reflected in here, right? But I can go to one of these transactions and I can pull up this error transaction again from that search. And I can see this is the one we were talking about before, right? This transaction had an error. It was an error with the document. And here’s that original document that we were trying to process before that had the problem, right? And beyond that, this, this interface will show me what transactions are related to this particular one. So what I can do here, I know that this transaction was resubmitted and I know that it’s for this ID number that this is the ID of the corrected transaction that I submitted, right? And similarly, if I actually go to this completed one, which is that, that 1865 D, that same one that we were looking at, it says, yep, I’ve got a parent, which is this one, right? So this one says, I was resubmitted, I’m not an independent transaction. I was resubmitted from this other one. So if you need to reference between what’s going on through the different transactions and trace a particular business integration through the process, that’s one of the, one of the capabilities of, of this tooling.

Aaron Magid
So just to recap here, right, These tools, these tools are built based on what we have actually encountered on the ground doing these real integrations, right? This, this is really our target, right? So Dan showed you earlier the transaction dashboard that shows us our successes, our failures, our document sizes, processing times, rates of different trading partners and how much they’re sending, rates of increase or decrease of trading partners and how they’re actually working with us, how their integrations are going. We have our transaction review that allows us to actually get into the, into the weeds of a particular EDI transmission and figure out exactly what was going on with that data and correct it if we need to, and also extract feedback that we need to get back into our coding assistant. And we have that coding assistant, right? That allows me to come back here and say, remember, I have this feedback box. I can say I got an error on a transaction. Let’s say that instead of fixing the document, there was a problem in my mapping. I could have taken that data, fed it in right here, and it would have updated. My integration would take about 90 seconds and, and then I could Redeploy that integration and resubmit the same document and get the output back, you know, from the next run. Right. And the target here. Right. What this creates is a comprehensive system that allows me to rapidly onboard trading partners, usually in a single phone call, troubleshoot issues effectively. Whether or not I’m an EDI expert. I just want to point out that when I troubleshooted the EDI document, I had my assistant do the whole thing. Right. So even though I do understand EDI personally, I did not need to, to make that change.

Dan Magid
Right.

Aaron Magid
I asked it what was wrong and then I asked to fix it. Right. Those are things that can be done without a high level of EDI proficiency. And I can monitor this integration and, and track exactly what’s going on with it. And that includes, by the way, the monitoring includes alerting proactively on conditions that occur within the system. Right. One of my favorites, actually, just a side note on that, one of my favorite use cases of that is the system is tracking the usage rates of, of all the trading partners. One of the fun use cases of that is beyond just error resolution, is actually tracking how many documents a trading partner is, is sending so that if a change occurs in that, meaning, let’s say you have a, a customer who suddenly starts doing less business with you because. And they’re sending fewer documents that actually will show up in your dashboard.

Dan Magid
Right.

Aaron Magid
You’re actually able to see that even though it’s not an error condition. Right? We can see that and we can actually alert on that even though it’s not a technical error condition. So again, this system is really based on the real feedback that we’ve seen. I hope that it’s given you some, some food for thought, some, some interesting ideas for how you can work in your own EDI systems. And, and honestly, what these things, what these integrations can look like, you know, if you don’t have to wait, you know, six, 10 weeks for an EDI expert to get on and, you know, make a change to an integration. That’s, that’s kind of a black box, you know, really kind of bringing this down to, to your team and to, to whoever you, you have and whoever you need who needs to work with this, with this EDI data. So I hope that was helpful with that. I’m going to pass this back to Maya Closes out.

Maia Samboy
Awesome. Thank you so much, Erin. And thank you everyone for being here. Like I said, I will send out the recordings to everyone who is registered and if you have any questions after the fact, just feel free to reply to that email and I can answer it or pass it on to Aaron and Dan, and we’ll get you all squared away. So thank you so much for being here and hope you all have a great rest of your day.

Dan Magid
Thanks, everybody.

Aaron Magid
Thank you all.

Maia Samboy
Good one.

Dan Magid
Bye. Bye.