Further information is contained on the following pages, which can also be accessed through the side menu
On this page
General Overview
Notes | |
---|---|
Overview | This contains general and hopefully useful information about how the system processes sales order / despatch of stock files. To ask general questions on any of the EDI formats, then please send an email to editest@visionsuite.co.uk |
Format | XML – a file structure which takes into account all the functionality and field within the warehousing system. We use a very basic form of XML which allows nearly anybody to create the file from many systems. Why not Tradacomms / EDIFACT ? – Whilst the larger organizations like to utilize these formats, we have used these formats in the past but their inability to be flexible, lack of fields and the cost of integration and development times mean that many smaller customers would not be able to afford the development costs to implements EDI trading. There are also serious limitations to the EDI format resulting in not all fields being submitted or fields having to be translated before use. There is also the added problem of using a third party in the sending of the data and all too frequently the third party is blamed for loss of data and for any problems which occur when actually in 99% of cases it is the customers lack of understanding of the process which has caused the problem. We offer a service using a third party, Atlas Products, who can take files from customers in this format and convert them to our import formats. If you require further details please contact sales@ontechsolutions.net |
Transmission | Each warehouse determine their own cut-off times for transmission of orders, but as Vision EDI is fully automated we prefer if customers are constantly sending sales orders throughout the day, not only does it keep orders flowing to the warehouse but it also stops delays at cut-off times when everybody tries to send. The other additional benefit is that should you have a system problem at the cut-off the effect is minimised. We would therefore strongly encourage customers to transmit files on a regular or real time basis. |
File naming | Your sale order file names should be of a standard format which will allow us to identify any file uniquely for a particular customer code, each Sales Order file would begin "SO....." 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 The customer code for the filename would normally be the same code as used in the customer code field of the order file, although we can accept a file which contains orders for multiple customer accounts. Please try to avoid exceeding 32 characters in the file name. We use this convention to identify the filetype, it allows us to pre-process the file before we parse the XML as we perform various checks on the filename existance for duplication purposes. It also allows us to identify which XML model we will be using for the filetype and allows us to process faster, it also allows us to check whether your customer code has permissions for the filetype without us having to load the file to see what is in it and finally it allows us to acknowledge we have the file back to you without having to open and read the contents. 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. |
Usage | See section below |
Limitations | See section below |
Usage & Limitation Information
Notes | |
---|---|
Accidental duplication of files | It is your responsibility to not duplicate the files you send to the warehouse, if you choose to resend please be sure that you are not going to duplicate orders. However, if you resend the same file within a short period of time we have a mechanism in place that it will not be processed. Instead we will fail the file and remove it from the upload queue. The period is usually within the same working day. |
Sending the Same Order in Multiple Files | Most customers using Vision will not have this check switched on. When this is on then we will check for the same number appearing again on another file, if that is the case we reject the order. If this is switched off, then customers could use this to provide an add-on order, although it will not be combined with the original the references you send are all the same and we would create another unique order, so it is important if you send the same order that you ONLY send additional lines in the new order, you can not amend, adjust, delete or edit the original order. If your original order failed and is held in the EDI service, you must ensure the warehouse REMOVE the original order from the EDI Service before you send it again otherwise we will COMBINE the Document Reference of both orders in EDI and when it is released it will be a single order in VW. |
Acknowledgement of files sent | The Vision EDI service has a facility to acknowledge files received. If you have tested and you wish to receive a receipt confirmation email then your nominated email address will be sent an email containing information about the file received, the number of orders, number of lines and time of receipt. |
Confirmation of orders processed | The Vision EDI service has a facility to confirm orders processed on the system, it can be schedule to be send on an hourly, daily, weekly basis. |
File retention | We archive files for 30 days after they have been sent. When its a HMRC warehouse this is usually 90 days. However our Vision EDI customers may choose to extend this |
Processing of order files | File errors where files can not be processedIf there is a data irregularity then we will reject the file. In this instance customers need to be able to fix the data and resubmit the orders back to the Vision EDI system. If your file fails and we can identify your customer code (it should be the file extension) then we will email you to tell you. Where no issues are foundWe upload and process the order which will go directly to the warehouse despatch, ready for picking. No user intervention is required and normally the first person to see this order is the warehouse picking manager. You can request a hourly orders processed report which will confirm the orders processed. Missing or Inaccurate DataWhen orders are received and found to contain missing information then the order will be placed on hold, and we will send you an email informing you that this is has occurred. Generally Orders are held for :
We will only send you an email with the issues if we can identify your customer code (it should be the file extension). |
Repeating Product Codes or Rotation Numbers | Due to the complexities with picking operations, its impossible to achieve accurate stock shortages when the same product is specified multiple times on the same order. If you need to do this then you have to specify the rotation number for each time the product appear, if the rotation has rotation line numbers then these should also be specified. |
Maximum Number of Lines | We generally set this to 50 lines per file and is dependant on whether the warehouse server can handle orders above this and whether the warehouse want orders with more than 50 lines. It is a generic figure, some Vision customers have a much higher limit, some have a lower limit. If your order exceeds the limit, all we do is automatically split the order into two orders, each processed separately, there is no duplication of lines nor is there any manual work involved in doing this. |
Orders - Using rotation numbers or batch references | Customer can order by
Note : You can supply a rotation number with or without a rotation line number, it is only required to state the line number when you have stocks owned by customer reserves. |