In this video I’ll be showing you how ZEDI handles EDI files.
We’ll look at how data exported by your business systems can be converted into an EDI format, and then delivered to your trading partners. We’ll also look at how EDI files being sent to your business by your trading partners can be mapped into a form that your business systems can import.
To illustrate this, we’ll use two fictitious companies. The first is “Big Supermarket”, a retailer of various types of grocery products. The other is “Johnson Pet Foods” who manufacture pet foods.
The starting point is an XML file containing supplier order information. This order information was originally exported from Big Supermarket’s purchasing systems and passed to ZEDI for processing.
It’s important to note at this point that the information in the file did not necessary arrive into ZEDI in XML format. It might, for example, have been presented as a CSV file which was subsequently converted to XML by ZEDI.
If we look at the actions for this file, you can see that there are a number of steps it goes through in its processing. We’re interested in the last of these, the one that runs the “Map the file” action.
This action looks like this.
It targets outbound transactions for Johnson Pet Foods that have a document type of “SupplierOrders” and a condition of “Validated”.
The action it performs is “Map the file” and the stylesheet that performs this mapping is selected here.
The stylesheet will produce a new file, containing the EDI message, so once the mapping has been performed, we don’t need to do anything else with the original XML file.
The output tab shows what will happen to the EDI message generated by the stylesheet. It will be added to the list of transactions as an outbound transaction for the same trading partner as the original XML file but with a document type of “SupplierOrders_EDIFACT”.
This is the transaction that was generated.
If we look at the action tab, we can see that the only thing that happens next is a “Send transaction” which will deliver the EDI file to Johnson Pet Foods.
The action looks like this.
So, the EDI data will be delivered to Johnson Pet Foods using their default means of communication, which in Johnson Pets Foods case is AS2.
Once the EDI has been sent, the “History” section for the transaction will show whether or not it was sent successfully. In this example, as is usually the case, the file was delivered successfully.
The “Session logs” section shows additional information about the transmission. This includes a log of the transmission, a copy of the data that was sent before it was encrypted, the data as it looked after it was encrypted, and the electronic receipt, or MDN, that was returned by Johnson’s AS2 server.
We’ll now look at what happened when the file was received by Johnson Pet Foods.
I’ve logged off from Big Supermarket and logged back on as Johnson Pet Foods.
The file arrived from Big Supermarket as a “SupplierOrders_EDIFACT” file.
Since we’re expecting files from Big Supermarket to contain EDI data, the first action to be performed is an “EDI Extract”.
This will scan the file for the presence of one or more EDI messages. Any that are found will be added as new entries on the list of transactions with the appropriate EDI document type, and a condition of “EDI Extracted”.
Since the file from Big Supermarket contained an EDIFACT ORDERS file, the new transaction will look like this.
Notice that the lower section of the screen shows two files. The first is the raw EDI file and the other is the XML representation of the same data. This XML is needed to map the data into a form that can be used by Johnson’s business systems.
If we look at the actions for this transaction we can see that it goes through two additional processes. We’re interested in the second one, “Map the file”. It looks like this:
It will map the data using the stylesheet specified here, which in this case will produce the kind of CSV data the business systems can import. It doesn’t necessarily need to be a CSV file. By selecting the appropriate stylesheet ZEDI could just as easily have produced an XML file, a flat file, a SQL script or whatever the business systems need.
The output tag shows that the output of the mapping will be added to the list of transactions as an inbound transaction destined for Johnson Pet Foods. It will be given a document type of “Order_CSV”.
It looks like this:
Once again, if we look at the actions for this file we can see that a “Sent transaction” action will be used to deliver it to Johnson’s business systems.
The action that does this specifies that the communications method will be “Local FTP”, which means that the CSV file will be placed in the “Download” folder on the FTP server to await collection by the business systems.
I hope this video has adequately explained how EDI files are processed by ZEDI. If you have any questions then please feel free to get in tough via the “Contact” page on the zirconblue.com web site.