Testing Inbound EDI

What is testing

Ontech Solutions provide a testing facility to customers using Vision EDI, if you intend to send any electronic files into Vision EDI for your warehouse you need to complete testing prior to doing so.

Testing is Mandatory
All inbound XML being sent to Vision EDI for processing must be tested prior to being used in a live environment, you need to complete testing for each warehouse company you store with as not all operate using the same methods.
You will also be at risk financially if you send untested files into any EDI system.

You will need to submit for EDI testing if

  • You want to start sending EDI or change from email to API

  • If you change your sending computer system or method.

  • If you want to modify the order types you send

  • If you are changing or adding an account


To use this service see Testing Inbound EDI | Step by Step Guide to Testing or to ask general questions on any of the EDI formats, then please send an email to editest@visionsuite.co.uk

 

We aim to respond to your request within 3 working days but it is a first come service and it can become quite busy certain times of the year, if you have not heard back within 5 working days then let us know.

Where to Send Test XML

For Stage 1 & 2 email to editest@visionsuite.co.uk 

For Stage 3 you will be set up with an API token if you have chosen this transport route.

Blackout periods for testing

We do not offer this facility during the following periods

Year

Last day for submission of new test files

Received after “last day” will receive a reply from

2024

Friday 13th December 2024

Monday 6th January 2025

2025

Friday 12th December 2025

Monday 5th January 2026

 


Before you start

You must

  • complete testing at least 2 weeks before your required LIVE date

  • submit testing using the correct file name - see SO XML Structure for examples

  • send test files via email to editest@visionsuite.co.uk

  • Send the pre-testing questionnaire when you send your initial stage 1 test

  • Complete Sales Order testing on API before you begin pre-advice testing

You may find that

  • Many warehouses restrict customers going live during peak periods.

  • Testing turnaround is 3 working days from submission for testing

  • If you do not test for more than 6 weeks you will have to start again.

  • There are blackout periods for testing around Christmas and New Year

You MUST NOT

  • Zip up the file prior to sending

  • Send filenames ending .xml as these are automatically deleted


Limits of Testing

We allow for each stage of the testing to be run 5 times for the customer, should the customer fail for the fifth time then Ontech will contact the Vision customer as further tests are charged at £75 per test.

Outbound Files Testing

Generally where the customer exists already within the warehouse we suggest that if the customer wants to test some of the files going to them that they use the live system and have the files enabled from the live system, this can be done in the VCIS system or through your warehouse operator.

In theory your live system files will provide you with a real update of what's happening on the account, the only thing they will not be able to give you is a link to your incoming sales order line number field if you are using this to link the sales order to the order picked or the pre-advice to the goods received.


Step by Step Guide to Testing

Stage 1 - Initial Check

As you begin testing we will need to know some information, please click and download the form below, complete this and email it back to the editest@visionsuite.co.uk address along with your first test files.

Sales Orders pre-testing form

 

Pre-Advices pre-testing form

 

You do not have to request a testing slot or time, when you are ready to begin testing then files should be sent to editest@visionsuite.co.uk. Ensure that the pre-testing form is included with the first file sent to us. 

Any general queries can be sent to the above address.

We aim to turnaround requests within 3 working days of receipt.

 

What to send

  1. Pre-Testing Form

  2. Example Orders which should be one order of each order type which you ticked on the pre-testing questionnaire and in addition to this where you are using different delivery methods then you need to include an example of each delivery method you plan to use.
    Avoid using dummy data as we will then ask for a set of orders with something more realistic and we have to move to step 2 but where step 1 provides us with enough initial test orders to ensure you will not crash the API then we will move directly to step 3

The optional items on the final page of the pre-information need to be included in the initial test files, not everything is needed on every order but examples of you being able to submit what you need to within those optional fields is essential for smooth operations

If you are only changing your account within the warehouse then submit the form only, we will check to ensure that your current incoming EDI are not causing any issues and will decide whether you need to test or whether we can just change you to send into the new account.

 

General Checks

  • The data within the file is formatted correctly as per the specification definition and we can read in the file without any errors

  • The segments and elements are completed as expected.

Visual File Check

  • Visually check the data file for the correct information within the data fields

  • Check the date formats

  • Check the consistency of under bond/duty paid flags with excise accounts

  • Check product code/rotation numbers to required formats

  • Check order references delivery names and contacts

If the test data fails at any stage then the tests cannot be continued the customer will be instructed as to the reason for the failure and a new data sample will have to be provided.

File Naming Convention for Test Files

When testing or sending an API file using the fall back method the filename must conform to the following.

  1. It must be prefixed with SO

  2. The suffix must be the warehouse customer code.

  3. It must not be zipped nor should they end in .xml

  4. The filename should not exceed 32 characters

SO(YY)YYMMDD_hhmmssttt.<customer code>       e.g. SO051214_123204000.ABCD1234   OR
SO(YY)YYMMDD_<orderNo>.<customer code>       e.g. SO051214_SO0123456.ABCD1234  OR
SO(YY)YYMMDD_hhmmss_<orderNo>.<customer code>       e.g. SO051214_123204000_0123456.ABCD1234

Key YY = year / hh = hour / ttt = milliseconds / MM = month of the year / mm = Minutes past the hour / DD = day of month / ss = seconds 

Customer code for the filename would normally be the same code as HD1 (FKCustomer)

We use this convention to identify the filetype; allows pre-processing before we parse the XML; identify which XML model; process faster; check incoming customer permissions; provide acknowledgements back to you.

We also do not allow multiple different file types in the same file, so a sales order file can only contain sales orders, and this then negates the need to use XML namespaces.

If your data looks good in the initial test then you will move directly to perform the bulk test on the API, if we are having issues with consistency of data then we will ask you to continue the test using email and step to stage 2


Stage 2 - Real Data Checks

This stage is generally used when we notice many inconsistencies with your initial data tests and we continue a more thorough check of orders using the manual email method.

We will ask for some real world examples to be sent, it will be a number of orders of each type and for each delivery method and we will ask you to ensure all the optional fields that you plan to use are being used.

You also need to ensure that they are all to differing customers / addresses.

What to Send

You will be asked to send around a proportion of a weeks worth of orders, if your planned incoming number is low then this will be proportionally higher than a customer who has large volumes.

This data needs to be as real as possible, preferably information from live orders you are currently sending out to customers.

At this stage its very important that we are provided with a number of test files to allow us to see if in a normal week processing any issues occur, we find that generally at this stage it is your customer data setup that has issues and this stage always highlights some generally annoying problems which need to be corrected. 

We therefore ask you to provide initially at least three days of test data which should be a representative sample of not less than 75% of the normal daily orders, we may extend this to be full weeks worth if we have problems with the first batches.

This stage can take a while to set up as we need to update test system data in order to perform a full test receipt and to minimize product and rotation errors.

What we are looking for at this stage of testing is the following :

  • Duty is being charged correctly to the correct accounts

  • Delivery addresses are correct

  • Mandatory fields are all completed

  • Collections from warehouse are correctly marked

  • Rotations being used are correct and consistent with what is in the warehouse

 

If you are sending orders via API you proceed to step 3 otherwise if you are sending via email then you proceed to step 4

Stage 3 - API Testing

Access will be provided to the main system to allow you to send through the API, the system will then respond to your inbound files, as they should be generally good the responses should mainly be positive.

If you can have real orders sent to the API this will speed up the process of the final approval, if not then sending the batch you send with Stage2 is a good starting point or simply send tests.

When you send these API tests and have sent the required number please inform us by email that you have completed and we will review the test inbound messages.

We appreciate that you will initially test the API with some orders and perhaps fix some issues so to ensure we do not pick up the early tests provide us with a start date to look at the incoming files from to ensure those early tests do not influence the overall results.

You can not just start at this stage as the error processing on API is very strict and will keep providing you issue by issue until you get it correct, this can be very frustrating.

To use the API you must test and pass sales order testing prior to testing pre-advices

Stage 4 - Approval to use in Production system 

Ontech will liaise with the warehouse and the testing customer to agree on a go-live date.

An email authorizing you to go live will be sent with any provisions or conditions stated on it, you will only be able to send those orders types you have requested during testing phase, anything outside of this will require further tests.

Once a date has been agreed then the customer would then deal with the warehouse directly for any issues or problems as it is the warehouse who manage the day to day operations of their own EDI system

Related content

Copyright Ontech Solutions 2017-2024. All rights reserved, no part may be replicated or distributed without the express permission of the owner.