...
What does this section deal with?
This section deals with the EDI server responses when your file is checked, validated prior to adding to the system. These are designed for customers of the warehouse to be advised of an issue with their EDI document.
...
As is normal industry practise we validate information we are sent to ensure that it meets the requirements, we have a multi tier approach
API validation (only if using the API)
Initial Message validation - failure at this point would have the message completely rejected.
Item validation - failure of something within the file which means the item will have to be manually dealt with.
| Note |
|---|
It is not possible to code for every possible issue an inbound file may cause and sometimes error messages are not helpful, but they should be sent to the warehouse customer services to deal with further. |
Noitifications are available during this process as follows
...
Initial receipt of the file notification (this is optional)
...
| Table of Contents |
|---|
What is the process
The process of checking and passing the information into the WMS is fully automated, there is only a need for the warehouse to become involved if the data sent has any issues identified in stage 3
Incoming Process
Stage | Step | Description | Notifications
| ||||
|---|---|---|---|---|---|---|---|
1 | Customer Sends | Customer sends order xml via email or API | |||||
2 | System Initial Receipt | Order is received through email or via the API into the EDI system where it will be queued for validation. | Sent via EMAIL - you can opt to have the system acknowledge it received a file from you through email, this is not an indication that it has been processed, just that it has been received. Sent via API - generic error codes could be returned. You need to moinitor for a 200 response anything else means the inbound has failed a list of codes can be found here API Responses - Vision EDI - Vision Wiki (atlassian.net) | ||||
3 | XML Validation [Validation Stage 1 - we can not proceed to load the order into EDI] | We check that the file is authorised, your order types allowed and that the information can be read into the system.
| Sent via EMAIL - Email will be returned stating “FILE LEVEL VALIDATION FAILURE” Sent via API : inbound response error codes could be returned , a list of those codes is here API Responses - Vision EDI - Vision Wiki (atlassian.net)
| ||||
4 | Order is submitted to the queue. | Depending on the time of day and the volume of traffic this could take from a few seconds in the queue to a few hours | |||||
5 | Order Validation [Validation Stage 2 - we can read the order but can not send it into the WMS] | Checks are made for specific validation of fields, mandatory fields are in the file and product code / rotation number are existing for the customer. Warehouse EDI team can update and resolve items to allow it to progress | ALL : email is sent with an item level failure notification. | ||||
6 | Order is passed to WMS | Order moves from the EDI system to the WMS system | |||||
7 | WMS Validation [Validation Stage 3 - its loaded into WMS but it can not be progressed to picking] | Final Checks are made on the order, if there is an issue it is placed on HOLD e.g. Credit Checks, deferment checks, stock availability. The warehouse orders team will update the order on your behalf. | ALL : Warehouse Orders team generate a held order email or they manually email you or call you about the order being held.
| ||||
8 | Order is released to warehouse for picking |
How do we know if the order is available in the WMS
Once the file is loaded into the warehouse system you can then request an orders processed report which confirmed what the orders received were and what was processed on them.
Examples of
...
emails
These emails examples are sent by the EDI system to customers, it is fully automated
Example Email |
|---|
...
Acknowledgement of Receipt of Email FileThis is just our system saying we have something to process. At this point we have not checked or validated the information in the file.
|  | ||
XML File FailureThis is a complete failure of the xml file. The file will not be processed and is usually due to a complete failure of the information in the file. You should not resend, but contact the warehouse for assistance however most of the time you have to speak to your own developer to resolve this. This email is replaced by the API responses codes which are send in the event of a XML failure |  | ||
Order Item FailureThere is a problem with a line on your order or some details of the order header are incorrect. API customers will continue to receive this response via email as inbound orders are processed on FIFO basis and busy systems can take a few seconds to over an hour to process an incoming XML order. |  |
Using the API
This section deals with the EDI server responses when your file is checked, validated prior to adding to the system. These are designed for customers of the warehouse to be advised of an issue with their EDI document.
If you are using the API then there are other responses you will receive
...
Introduction
As is normal with most advanced web services, incoming submissions go through several stages of validation and various responses can be received should the submission fail at any of these stages.
First the file itself is validated
Second the elements (Sales Orders, Purchase Orders, Products etc) are validated.
As part of the approval process, we add approved accounts into a control table where we can control a number of settings and permissions, this process is carried out by Ontech / Vision support after testing.
The warehouse operator has the ability to maintain the email address for this approval as well as the sending of file receipt messages, but they have no other abilities to control other aspects of this control.
...
File receipt confirmation:
Depending on your setup, you can be configured to receive this email confirmation or not.
...
This email only confirms that the file has been received and nothing more, this is before any validation takes place.
The message body will look similar to below:
...
Stage 1 - File level validation:
Incoming files are queued and validated.
The initial validation checks that submitted files:
...
Are constructed correctly as per their file type (valid CSV / valid XML).
...
Meet our expected file format.
...
Should the submission fail, an email will be sent to you with a message body similar to below:
...
Stage 2 - Item level validation:
Should your submission pass the first stage of validation, it will move on to the second Stage.
Here we're checking the individual records within the file submitted.
If you've sent in a Sales Order file, then we're checking each individual Sales Order within.
If it's a Product file, then each individual product, and so on....
The validations which occurs here are specific to each file type, but to give a basic idea of what occurs:
We're performing the more advanced checks to ensure what has been sent in is logical (e.g. a Sales Order sent in for delivery, but with no delivery address).
That the data submitted exists in our system (where necessary.
For example: A Purchase Order sent in with values and currencies, but the currency code submitted is invalid and does not exist in our system.
Should the submission fail these checks, you will receive an email with a message body similar to below:
...
In this instance, some of the items within the file could have failed validation and others passed.
...
in addition to the XML File Failure API responses. API Responses contains a list of common and specific responses you may receive.