Specialist Mapping Services


	Specialist Mapping Services At AdvanceFirst Technologies we pride ourselves on being one of the most experienced and skilled mapping companies in Europe. Since our inception in 2003 our clients have been using us for mapping projects of varying sizes, from single maps to multiple maps. These relate to anything from major systems integrations projects to single EDI maps for electronic trading purposes. We are now offering via AMOS the ability to manage any mapping or data file transformation and delivery requirement as an outsourced solution. Some of the benefits of this are as follows: - Respond quickly to customer requirements for new document types or methods of delivery Reduce cost by eliminating the need to invest in specialist in-house software or mapping skills Get better visibility of the whole transformation and delivery process How does it work? Utilising any method of communication/delivery preferred by our clients: - We can accept input files from you in the following multiple formats .CSV Flat File (e.g. SAP iDocs) XML EDI In return we can create out output files for you or your trading partner in one or many of the following multiple formats .CSV Flat File XML EDI HTML PDF In most cases we convert all incoming files into XML en-route. These transformed file than then be either sent directly through to your trading partners or back to the sending client systems. To do this we would use our Specialist Delivery Services which allow us to send that file of documents or data files either back to you or through to you trading partner via multiple communication methods such as SFTP, AS2, EDI or the most secure of all AMMX (Advance Managed Message eXchange) unique to AdvanceFirst. For more information on AMMX, the fast, secure, low cost and fully auditable managed file transfer system, please go to http://www.ammxtech.com/. Complete visibility to our clients of the Mapping and Delivery process From your systems through the mapping and transformation process and onto the receiving trading partner systems, we monitor the whole process and deliver the full audit trail and security report to both the client and recipient. So by using AMMX it allows our clients to at all times, maintain full visibility of the progress any document or data file is making through the transformation and delivery process, ultimately confirming to both parties final delivery of the documents/data files safely and securely to the client. Using AdvanceFirst Technologies to keep pace with increasingly complex e-commerce demands. The Background In the early days of electronic commerce, the demands placed on a business were far simpler than they are now. For a UK company, the EDI standard was Tradacoms and the method of communications was Tradanet. Once you’d implemented your translation software and purchased a mailbox subscription you’d be in business. As time passed, things became more complex with the wider adoption of EDIFACT-based standards and the use of alternate methods of communication like AS2. The EDI translation packages were modified to handle these new requirements, sometimes a bit too hastily, so that the companies that use them can keep their customers happy. Now we are seeing more and more cases of XML and CSV files being used instead of the established EDI standards and protocols such as SOAP and FTP being used as the means of communication. The EDI translation systems were never designed to cope with such diverse requirements making it increasingly difficult for many companies to satisfy the demands of all their customers. Wouldn’t it be nice if we could go back to a simpler age where all documents were the same standard. You could then continue to use all the well established and trusted interfaces between your business and the outside world. This is what AdvanceFirst allows you to do. We can take all the complexity away from you and leave you with a simple interface to the outside world regardless of what your customers actually want. For example, say one of your customers has designed their own XML file structure for invoices and they want you to send them in that way instead of the Tradacoms INVFIL files you’ve used for the last 20 years. Not only that, they want the XML files to be delivered directly to their systems using SOAP1.2 instead of the relatively costly Tradanet service. This is where we can help. We can accept your existing Tradacoms invoices, using whatever method of communication you are most comfortable with, and our systems will convert them into the XML format required by your customer and deliver it to their systems using whatever means of delivery they want. Not only that, our systems can accept incoming documents like orders in whatever format your customer uses, and we’ll turn them into ORDHDR messages and forward them to you using your preferred means of communication. Essentially, whenever a customer asks you to do something new or complex all you’d need to do is pick up the phone to AdvanceFirst and tell us to get on with it. What we do and what we can do for you! (Some examples) AdvanceFirst’s technicians have been selected for our extensive experience in the electronic commerce industry and our “can-do” attitude to work. This, coupled with the sophisticated software tools we have developed and which we use ourselves, means that so far we have never been faced with a task we could not deliver. Here are a few examples of the type of things we have already achieved and can now offer as Outsourced Solutions via AMOS. On-the-fly translation between EDI and other formats. This involves taking your outgoing EDI files and turning them into other things like XML, CSV, flat-file or human-readable format. This is especially useful for customers who want to switch to an XML-based method of EDI but it can also be used to supply data to customers (or suppliers) who don’t have any form of EDI capability. For example, one commonly used approach is to turn the EDI documents into HTML which can be sent as an e-mail attachment. This is an excellent way of slashing the cost of sending common documents like invoices, statements, remittance advices etc. without requiring anything other than an e-mail address from the recipient. Another is to turn the EDI into a CSV file that the recipient can import into a spreadsheet or database application, effectively allowing them to “do EDI” without buying an EDI translation system. In exactly the same way, we can take an incoming XML, CSV or flat file and turn them into the EDI format your systems are setup to accept. For people who would have difficulty creating XML, CSV or flat-files, we can provide a web-based method of document data entry. Either way, the incoming documents would be presented as EDI data which can be brought into your systems in the tried and trusted way. Processing of ad-hoc files Some large companies (retailers especially) occasionally send documents like debit notes and remittance advices along with the normal purchase order messages. Most companies tend to process the orders but ignore the other message types as their EDI system was never setup to process them. This is a pity because quite often these “other” EDI messages contain information that could be very useful to people within your company. If you forward them to AdvanceFirst, we can process them on your behalf, convert them into a readable format and send them to the people in your organisation who would benefit from the information they contain. EDI backup strategy It’s quite surprising how few companies have a coherent EDI backup strategy. For example, how would your business continue to receive its orders if the machine you use to receive them suddenly became a smouldering heap of twisted metal? In such a situation, AdvanceFirst would be able to collect the orders on your behalf, turn them into a human-readable format and then e-mail them to you while your own EDI machine is being repaired. This is a perfect short-term fix which allows your business to continue trading with its most important customers regardless of the condition of your EDI system. Trading via FTP Good old FTP is becoming an increasingly common method of communication as it is far more cost effective that both the traditional value added networks (VANs) and does not require any complex software like AS2. Unfortunately, no two FTP servers are identical and each has its own particular “rules of engagement” that define how it is to be used. For example, what are the security arrangements? Where will I find the orders? Which folder should I use to upload invoices? What file naming conventions are used? Who is responsible for deleting the files once they have been downloaded? and so on. The solution is to produce a custom-written FTP script for each FTP server that you are expected to use. These scripts then manage the uploading and downloading of files according to the rules for that specific server. If you exchange EDI files with your suppliers, FTP can also be a way of avoiding the costs associated with VAN-based communications without requiring the use of special software by your suppliers. AdvanceFirst can run and manage an FTP server on your behalf. Any files you wish to send them will be routed to the appropriate “Get” folder for the supplier and any files they upload will be collected from each “Put” folder. Your suppliers can then log-on to this server, download their incoming files and upload their outgoing files as often as they choose. More importantly, because they are using an AdvanceFirst server, there is no security exposure to your own business network making this a very safe and cost-effective alternative to VAN-based communications. Data checkpoint AdvanceFirst can be used as a checkpoint between you and your customers if you so wish. Its job would be to look for specific errors in the incoming files and prevent any bad data from reaching your business systems. Details of any errors would be then returned back to the sender as an e-mail politely asking them to fix the cause of the problem and resubmit the message. One example of this would be to check the order number references on incoming invoices. Each order reference would be checked against a database of valid order numbers for the supplier and if any invalid numbers are detected, the invoices would not be forwarded to your systems for processing. Instead, the supplier would receive an e-mail explaining exactly what the problem is and suggesting ways of correcting it. Other examples could be to check VAT calculations, tax codes, product numbers location codes etc. according to the specific needs of your business.