Hello. Welcome to this quick tour of ZEDI.
This video describes the main features of the system without going into too much detail.
In short, we’ll briefly look at the following:
Transactions, searches, trading partners, tables, registers, mappings, actions, on-line transactions, and flat file processing.
These are the main functions of the system, but behind the scenes there are a wealth of other useful functions that can be used in specific situations.
Let’s start with transactions.
This page lists the files that have been passed to ZEDI for processing, either by your business systems or by your trading partners.
The filter fields in the column headings can be used to easily locate the transactions you’re interested in.
Clicking an entry in the list shows detailed information about that transaction.
Notice that all transactions have a current condition. It describes the state it’s currently at in its processing, and whether or not it was processed successfully.
The contents tab shows the data contained within the file.
The metadata tab lists items of information that could be useful when performing searches, and for controlling how the transaction gets processed.
The actions tab shows what actions would be performed on this transaction depending on its current condition.
The history tab records what happened to the transaction when it was processed, and would also show detailed information about any errors if there was a problem.
“Child files” lists the transactions that were generated from this transaction. For example, when a “Map the file” action had been used to map the data into the format required by your business systems or trading partner.
The “session logs” section lists the files that contain information about what happened when the file was sent to another system. For example, if the file was sent using AS2 you would find the MDN that confirms its receipt, here.
Searches can be performed in a number of ways, making it easy to locate a specific document, such as an order.
If you already know the ZEDI file name of the transaction, you can enter this, or just the numeric part of it, in the “Name” field to locate it quickly rather than page through the full list of transactions.
Alternatively, you can use the drop-down fields to specify which transactions you want to see and for what range of dates.
The metadata section allows you to find specific documents within the list of transactions. Here, for example, the transactions that reference order number 123456.
Trading partners are usually outside organisations with which your business exchanges transactions, such as your customers and suppliers. They can also represent your own business systems.
As with the transactions page, there are filter fields that can be used to quickly locate the required trading partner, by entering part of their name in the “Partner name” field for example.
A trading partner has basic information like their name and address, and there is a contacts section where you can record details of the people to talk to if there’s an issue.
The “identities” section lists the various IDs that are associated with this partner, such as their customer number, supplier number, mailbox ID and so on.
The “communications” section allows you to define the possible ways you might exchange transactions with this partner. These include things like FTP, AS2, OFTP2 etc. It’s worth pointing out that a trading partner can use more than one method of communication. They might, for example, send their invoices to you using AS2 but provide new product information via FTP.
Lookup tables are an essential part of any EDI system as they allow information to be translated into a form that your business systems, or your trading partner, can easily use. They can also be used to plug the gaps when specific items of information aren’t readily available.
Creating a table involves giving it a name and then defining the list of fields it needs to contain.
You can then edit the contents of the table in a number of ways.
The simplest is to edit the table on-line. This is fine if the table contains a small number of records that don’t change very often.
If the table contains a large number of records then you can download the table as an Excel spreadsheet, edit it to make whatever changes need to be made, and then upload the spreadsheet to replace the contents of the table.
If the data in the table changes very frequently, then it can also be maintained automatically by setting up a process to import the new information from a file that was generated by your business systems.
Registers are very similar to tables, but are used to achieve different things.
In your company, you probably have a number of colleagues who need to see the EDI transactions passing into and out of the business. People like Sales Administrators need to see a list of the EDI orders received from your customers, and Financial Controllers need to check that invoices are being sent correctly.
Because these colleagues are not necessarily au-fait with the technicalities of EDI processing, they might find it difficult to locate the information they need from the transactions page.
It would be far better if we could give them a customised view of the transactions that’s been designed to give them just the information they’re looking for. This is where registers come in.
A register is essentially what its name suggests, it contains a list of business documents together with information that’s needed by one or more of your colleagues.
This is an example of a register that records information about incoming orders.
The columns it contains are completely configurable, in the same way as you define the columns in a table, so you can design a register to store exactly what’s needed by the business, no more, no less.
As orders arrive from your trading partners, new entries are automatically added to the register. Similarly, as ASNs and invoices are sent, those entries in the register are automatically updated with the additional information.
All types of users can see the registers within ZEDI, but you can also define a user as a “register” user if you wish. When a “register” user logs on to ZEDI, they see just the “Registers” option on the menus and not all the other options that are used to manage and configure the system.
This gives the user a highly business-focussed view of the EDI transactions while maintaining good system security.
The mappings in ZEDI are used to convert files from one format to another as you would expect, but they can also be used to validate files as they get processed and extract metadata information that you might want to use in searches or control how the file gets processed.
Mappings can be downloaded, modified and then uploaded again via this page.
To assist with this, there is a piece of Windows software known as the ZEDI Developer Toolkit. This allows a mapping developer to thoroughly test a mapping in a simulated ZEDI environment before uploading it to the live environment.
Actions can be thought of as “the things that need to be done to the transactions”.
One of the most frequently used is the “Map the file” action, but a host of others are available to deal with specific situations.
In this example, an “Excel import” action is being used to process a spreadsheet that has been sent to us by one of our trading partners. Its job is to extract the information from the spreadsheet and get it into a form that we can automatically map and import into our business systems.
It’s possible that you’ll find that some of your trading partners will not be well equipped to handle EDI transactions. You may have a supplier that receives orders very infrequently, so they’re perfectly comfortable handling those orders manually.
In these situations, the trading partner would prefer to receive their orders, and submit their ASNs and invoices, by logging on to a web page. From your point of view, it would be preferable to treat them like any other supplier rather than manually e-mail or phone orders through to them.
ZEDI includes an on-line order processing environment that can be used in this situation.
Outbound orders for the supplier are processed using an action called “Add online transaction”, which records all the information in an on-line system.
The supplier has been defined as a user of type “Partner”, which means that they can logon to ZEDI and see just the transactions that belong to them. It also means they can use the on-line system to manage their orders and return ASNs and invoices.
This is an example for a supplier called “Morgan Fine Foods”. It shows a number of new orders which can be viewed on-line, or downloaded as an Excel spreadsheet.
Once an order has been viewed, they can then prepare an ASN to give the actual delivery quantities, and to indicate where product substitutions needed to be made.
The ASN information is then processed through ZEDI as though it had been received from an “EDI-capable” trading partner.
Once the ASN has been sent, the supplier can then compose the invoice they wish to submit. Again, from the customer’s point of view, this invoice gets processed in the same way as invoices from all other suppliers.
Some business systems and trading partners will provide files in CSV or fixed position format. In order to automatically process these, ZEDI needs to understand the structure of those files.
This is what flat file definitions do. They allow you to identify the meaning of each field in the file. With this, the information in the files can automatically be converted into a meaningful format and automatically mapped to the business system or trading partner that needs it.
We hope you found this video useful and informative. If you would like to know more about how ZEDI could benefit your business, please get in touch.
Thank you.