Hello.
My name is Mark Lancaster and I’m responsible for the development and maintenance of the ZEDI product.
In this video I’ll demonstrate, in practical terms, how ZEDI automates the processing of transactions exchanged with customers and suppliers.
I’ll use fictitious company called Johnson Pet Foods who receive orders from various customers, including Amazon, and an imaginary retailer called Big Supermarket.
Johnson also has a number of smaller customers who place orders via ZEDIs on-line system, so I’ll explain how that works as well.
Let’s look at Big Supermarket first.
This is one of the orders that came from Big Supermarket.
When one of these orders are received, a number of actions can be performed on it. ZEDI can be configured to perform whatever sequence of actions is required by your business.
In this case, the first action records the arrival of the order in a register. Registers allow non-technical users to see lists of the orders, invoices, ASNs etc. processed by ZEDI.
I’ll explain more about registers later.
Next, the file is mapped to produce a CSV file which can be imported into Johnson’s business systems.
The last two actions on this page are used to simulate the ASN and invoice that gets returned to Big Supermarket.
Normally this information would come from your business systems, but this is just a demo so we’re creating them automatically.
This is a list of the files that ZEDI generated from this order.
This is the CSV format that Johnson’s business systems requires in order to import the orders.
Their business systems collect this file from ZEDIs FTP server and then runs its import process to bring them in.
Now let’s look at the invoices.
This is the XML file that Big Supermarket needs in order to import invoices into their accounts payable system. It was generated in line with a specification provided by Big Supermarket.
The history shows that the file was sent to Big Supermarkets AS2 server and that a valid confirmation of receipt, or MDN, was returned.
The session logs section is shows technical information about what happened when the invoice was sent.
The *.response.txt file contains the MDN that came back from Big Supermarket’s AS2 server to acknowledge receipt of the invoices.
If necessary, Johnson Pet Foods could present this receipt as evidence that a given invoice or batch of invoices was successfully delivered and accepted by Big Supermarket.
Now let’s look at registers
Registers are a very user-friendly way to see lists of the various documents that have been processed through the system. This particular one records basic information about incoming orders.
These are the individual fields within the register, a register can be configured to contain whatever fields the business needs.
This is the information currently stored within the register. The sort order can be changed by clicking the column headings, and the list can be filtered using the text boxes above each column heading.
In this case we can see for each order, the ASN number used to report its despatch, as well as the invoice number.
This is a human readable version of the original order. If you need to, you can use the download icon on this page to get a PDF version of the order.
The contents of a register can also be downloaded as a spreadsheet.
This can be a useful way of reconciling list of orders, invoices etc with similar lists generated from your business systems.
In effect, you can use it as a cross check to ensure that all the invoices that should have been sent were actually sent.
We’ll now briefly look at how you manage users within ZEDI.
This is where you manage the users that can logon to ZEDI. Each user has a role that determines what they can see and what they can do once they’re logged on.
This one is defined as a “Register” user, which means he can only see and download the contents of the registers. He can’t change any of the system settings or affect the way files get processed in any way.
This one is defined as a “Partner” user. She’s a customer who is able to logon to ZEDI and see (but not affect) the transactions that relate to her business only. She’s also able to use the on-line functions to create orders.
I’ll log off and log back in as her now.
Note that she can’t see any of the Big Supermarket or Amazon transactions. Also, none of the configuration options are available to her.
Alison’s company owns four specific customers, Surrey Pet Supplies, Natureworld Pet Feeds, Wigan Bird & Pet Centre and Pet Supplies Megastore. Part of her job is to ensure that these four shops remain properly stocked.
These are the orders that have been created by Alison so far.
She can create a new order by entering her Customer’s order reference and then using the plus icon to specify what she wants to order.
Products can have different prices depending on the quantity being ordered.
The pencil icon is used to edit an order with a status of “New”, or view an order with a status of “Submitted”.
The thumbs-up icon is used to submit the order, the rubbish bin is used to delete an order and the clone icon is used to create a new order based on this one.
When she submits an order, the information is processed through ZEDI and passed to the business systems in the same way as the EDI orders.
Partner users are not just useful for customers, they can be good for suppliers as well.
Suppliers can use the on-line functions to view purchase orders received from your business, download them as excel spreadsheets if they wish, and then create ASNs and invoices which get processed through ZEDI in the same way as EDI ASNs and invoices.
Now let’s talk about Amazon.
Amazon support a range of transaction types. Orders, order responses, ASNs and invoices.
All four of them need to be used, but not necessary all in the same way. You could, for example, choose to receive orders by EDI and handle the remaining transactions manually via Vendor Central. Similarly, you might use EDI for orders and invoices but vendor central for order responses and ASNs.
These are simulated orders from Amazon, they have the same structure as real Amazon orders but the data they contain is just for demo purposes.
The original file (the one that has a document type of EDI) is received from Amazon using AS2 and then an action called “EDI Extract” is used to extract the EDI data contained within it, producing the ORDERS file we see here.
A “Map the file” action is then used to convert the orders into the format the business systems need.
In this case, the orders are being sent to a business system called IFS which requires this particular XML format for orders.
One thing to notice is that the original EDI data from Amazon contained just the <EAN_LOCATION_DELIVERY_ADDRESS> value to identify where the goods are to be shipped. It didn’t contain the name and address details associated with that address code.
These are needed for the DELIVER_TO/ORDER_ADDRESS section in the IFS file, so this is a potential problem.
ZEDI solved this by getting the information from a table called AmazonDeliveryLocations
Tables are a useful way of obtaining missing information and translating coded values.
This table contains the GLN code used by Amazon, as well as the name and address information associated with each GLN code.
ZEDI is able to use this table to lookup a given GLN code and get the name and address information that IFS needs.
Tables can be maintained in three ways: on-line, via a spreadsheet upload/download or via an action called “Table update”.
This is the on-line method. It’s best used for tables like this one where the contents change very rarely, in this case it would only need to be maintained when Amazon opens a new distribution centre or makes a change to an existing DC.
The second method is to edit the table by downloading it as a spreadsheet. This is useful when a lot of changes need to be made at the same time, and it would take too long to do it with the on-line method.
Using the spreadsheet, you can now make any number of changes, additions or deletions and save the new version of the spreadsheet to a folder on your PC.
You then then use the upload icon to upload the new version of the table to ZEDI.
The third method is to use a “Table update” action. This is best for situation where the data changes quite frequently, and you don’t want to maintain the tables manually.
Your business systems can export the data for the table to ZEDI whenever changes need to be made. ZEDI will then automatically run the “Table update” to import the new data into the table and keep it in sync with the information in your business systems.
Let’s now talk about EDI order responses.
Order response files tell Amazon how many of each ordered item will be supplied, how many will be placed on back order and how many cannot be supplied.
The order response information would have been exported from your business systems in whatever format it uses, and then sent to ZEDI for processing.
ZEDI will then map the data to produce the EDI message and then send it directly to Amazon via AS2.
When the goods have been picked, an advance shipping notification message can be sent via EDI.
ASNs tell Amazon what goods are being sent and when the delivery will be made.
Again, this would have been generated from information exported by your business systems and sent to ZEDI for processing. It then created the EDI message and sent it to Amazon.
Once the goods have been delivered, an EDI invoice can be sent to Amazon.
Invoice information was again exported by your business systems which ZEDI converted to EDI and sent to Amazon.
One of the main strengths of ZEDI is its wide range of actions that can be combined together to achieve whatever process flows the business needs. For example, it’s possible that some of your customers may already, or may want to, send you orders as Excel spreadsheets. ZEDI can handle these easily because it has an “Excel import” action that can read a spreadsheet, extract the information it contains and then convert it into a format that can be imported into your business systems.
Whatever the challenge is, ZEDI can probably already handle it but if something totally new comes along that nobody could have predicted, ZirconBlue will develop whatever new actions are needed to handle it.
In terms of cost, you have a couple of options.
The first is much like Microsoft Azure where you only pay for what you use. If you process a small number of transactions each month then you would be charged a low monthly subscription plus a charge for the number of actions used, and the amount of disk storage consumed.
Note that in ZEDI terms a transaction is not the same as a document. EDI order files could contain one order, or hundreds of orders, but would the cost of processing them would be the same.
You can control how much storage you use by defining housekeeping rules. You might, for example, wish to keep order transactions for 30 days, invoices for 180 days and everything else for 90 days. This allows you to satisfy your archiving needs while still keeping control of the costs.
The other option is a fixed price plan where you pay a fixed monthly subscription regardless of how many actions you run, and how much storage you use. This would be estimated initially but reviewed every 6 months to ensure that you not being over or under charged. If we find that you’re being under charged then we’d make recommendations about how you could configure the system more efficiently or use housekeeping rules to reduce the amount of storage used. If you’re being over charged, we’ll simply reduce your monthly subscription.
I hope you found this video useful and informative. If you want to know more about how ZEDI can benefit your business then please visit www.zirconblue.com.
Thank you for your time and we look forward to hearing from you.