AU2015283803A1

AU2015283803A1 - Text based information exchange management system

Info

Publication number: AU2015283803A1
Application number: AU2015283803A
Authority: AU
Inventors: Timothy Kevin Pope; Lee Van Hooff
Original assignee: Portalink Ip Pty Ltd
Current assignee: Portalink Ip Pty Ltd
Priority date: 2014-06-30
Filing date: 2015-06-30
Publication date: 2017-01-12
Also published as: WO2016000020A1

Abstract

This disclosure relates to Business-to— Business electronic information exchange and in particular text based electronic document exchange where there is a need to receive, handle and make available a text based set of data, image containing text, or voice, specific to a type of business transaction for being made available to a recipient data receiving system. The methods disclosed cater for the recipient system expecting data to be associated with respective fields and adapted to receive text based data in a predetermined format according to the type of business transaction, and types of transactions can include sending and receiving purchase orders and invoices, and in a particular example a recipient system is an Electronic Data Interchange (EDI) system. The methods disclosed cater for the one-to-many, many-to-one and many-to-many situation of source/s to recipients dealing with a variety of types of business transactions.

Description

WO 2016/000020 PCT/AU2015/000377 1

TEXT BASED INFORMATION EXCHANGE MANAGEMENT SYSTEM FIELD OF THE DISCLOSURE

[1] The field of the disclosure is Business-to-Business electronic information exchange and in particular text based electronic document exchange.

BACKGROUND

[2] In the field of Business-to-Business information exchange there are many types of transactions and some of the most common include the process of placing an order or receiving an invoice for goods and services both of which can be complicated or simple and many levels between.

[3] In the complicated version of such an exchange of information the source of the order, such as a buyer, retail outlet, agent, even a wholesaler, provides an order document in a format that is generally dictated by the order compilation system they have at their disposal and since they will deal with many suppliers it is unlikely it will be easily useable by the supplier to satisfy the order. Each source has their own way of creating an order and many will use their Point Of Sale (POS), accounting, or Enterprise Resource Planning (ERP) system to do so; thus there can be inconsistencies in the information generated by the source of the order to that expected by the many suppliers the buyer will send an order to. For example, the list of products may be referred to by the buyer's system are likely to be different to the list of the same products in the supplier's system, e.g. the buyer may add a prefix to those product names so the buyer can do easier searching; since there is a large administrative burden in updating the buyer's system with information from the supplier it is unlikely to match; and most importantly when dealing with suppliers that have a need for a bar code to be associated with the appropriate product in the buyer's system many systems do not hold that type of information; so when a buyer provides an order to a supplier there is very likely to be inconsistencies and issues with the data contained in the order. The following include but a small sample of the issues: instances of product codes having incorrect alpha-numeric characters; there may be times the quantity of the product is ordered singly WO 2016/000020 PCT/AU2015/000377 2 but the item is only available in a packet; there may be price differences because the person placing the order does not know the rate for a bulk purchase or that a special price applies; some buyers or their systems will not know that the product has been discontinued, etc. The examples provided are but a small sample of the inconsistencies that suppliers have to deal with when they receive orders for the products they sell.

[4] In the circumstances described, human intervention is required to not only enter the order into the supplier's own system because the original order is not in a digitally compatible form, but the human operator must also deal with the inconsistencies, the mistakes, and the incorrect information contained in the order. This intervention takes time, adds great cost and in some cases makes the system run unnecessarily badly to the frustration of the source, the supplier and ultimately the customer wanting the ordered product.

[5] The simplified version is when the order is created by the source using a software program and associated database that generates a document/message/file that is compatible with the supplier's desired format, for example, an Electronic Data Interchange (EDI) format and the EDI order can then be sent from the source to an EDI Value Added Network (VAN) and ultimately received by the EDI receiving system of the supplier and automatically processed using relational data field matching between databases typically with minimal errors. Even if the supplier does not use EDI, if they receive an order in a desired format such as an on-line web based order, the order will typically be processed with none or minimal errors.

[6] The above processes relate to orders placed from a source (buyer) to a supplier (goods and services supplier). In an example, the prior mentioned supplier of goods and services that is using, for example, an EDI system also has to receive invoices from the entities that provide them the raw materials to manufacture the finished goods that they then sell to the buyers. It therefore, may be the case that the supplier's EDI system will not be able to deal with received invoices that are not EDI compatible. In those cases where invoices incompatible with the system they are sent to, e.g. the invoice received by post in a physical form, sent via facsimile which is also a physical form since it is merely an image of the information, or as is more typical, attached to an email in digital data form, but still not in a supplier's preferred format, e.g. an EDI compatible form, the WO 2016/000020 PCT/AU2015/000377 3 receipt and processing of those forms of invoice adds cost and delay for each of the parties in the process of receiving, processing and paying the invoice.

[7] Thus, for example, the absence of an EDI information processing capability at the source of an invoice or the source of orders to suppliers will be a disadvantage, that cannot be overcome without the prohibitively expensive purchase, installation and maintenance of such a system at all the relevant entities.

[8] Unfortunately, there are a large number of entities which do not have the financial capability or a big enough business with each of their trading partners to purchase, install and use an EDI system despite the apparent advantages to both or all the parties. It is estimated by the applicant that some 80% of the entities that deal with suppliers do not have EDI compatible systems or systems that are completely compatible as between source and supplier.

[9] It is the intention of the disclosure in this specification to at least provide an alternative to the complicated version described in brief above that provides the advantages of the simplified version also described in brief above.

[10] BRIEF DESCRIPTION OF ASPECTS

[11] In a broad aspect there is a method for providing an interface for the exchange of electronic forms of information between a source and a supplier which is specific to the type of transaction between those entities which is suitable for the case of one source to one supplier, one source to many suppliers, many sources to one supplier and many sources to many suppliers as the case may be.

[12] In an aspect there is a method for receiving a text based set of data generated by a source being data specific to a type of business transaction for being handled and made available to a recipient data receiving system having recipient data associated with respective fields and adapted to have text based data in a predetermined format according to the type of business transaction made available to the recipient data receiving system, the method comprising the steps WO 2016/000020 PCT/AU2015/000377 4 of receiving the text based set of data associated with a source, intended recipient data receiving system and type of business transaction. Another step includes using a template determined by the source and type of business transaction, to associate one or more of the received text based set of data with one or more fields of data used by the receiving system. With another step being determining discrepancy between the received text based set of data and the recipient data for a respective field, where the type of business transaction determines the one or more fields to be checked for a discrepancy. Yet a further step is presenting one or more field and respective data for visual inspection including at least those fields having a discrepancy and another step is receiving an acceptance or correction of the data for an inspected field having a discrepancy. The step of making a set of data and associated fields including accepted or corrected data compliant for processing the type of business transaction by the recipient data receiving system. The outcome of the prior steps the compliant set of data being available to the recipient data receiving system.

[13] In an aspect the text based set of data received from a source is in Portable Document

Format [14] In another aspect the further method steps includes making available an Electronic Data Interchange compliant set of data.

[15] In a further aspect the type of business transaction is an order for the supply of goods or services to be provided by a receiver to a source.

[16] In yet a further aspect the type of transaction is an invoice for the supply of goods or services provided by a source to a receiver.

[17] In yet a further aspect the method step of making the data set compliant includes making the data set compliant for an Electronic Data Interchange with the recipient data receiving system.

[18] In yet a further aspect the method step of making available uses an Electronic Data Interchange Value Added Network to make the compliant set of data available to the recipient data receiving system. WO 2016/000020 PCT/AU2015/000377 5 [19] In another aspect there is a method for receiving a set of data including data specific to a type of business transaction generated by the source as an image of the set of data and a text based indication of the source and recipient and made available to a recipient data receiving system having recipient data associated with respective fields and adapted to have text based data in a predetermined format according to the type of business transaction made available to the recipient data receiving system; the method comprising the steps of receiving the image based set of data associated with a source, intended recipient data receiving system and type of business transaction; the step of applying optical character recognition to at least a portion of the received image of the set of data to transform at least a part of the received image into a received text based set of data; the further step of using a template determined by the source and type of business transaction, to associate one or more of the received text based set of data with one or more field of data used by the receiving system; the step of determining discrepancy between the received text based set of data and the recipient data for a respective field, where the type of business transaction determines the one or more fields to be checked for a discrepancy; the step of presenting one or more field and respective data for visual inspection including at least those fields having a discrepancy; the further step of receiving an acceptance or correction of the data for an inspected field having a discrepancy; the step of making a set of data and associated fields including accepted or corrected data compliant for processing the type of business transaction by the recipient data receiving system; and then the step of making the compliant data set available to the recipient data receiving system.

[20] In another aspect there is a method for receiving a set of data including data specific to a type of business transaction generated by the source as an image of the set of data and a text based indication of the source and recipient and made available to a recipient data receiving system having recipient data associated with respective fields and adapted to have text based data in a predetermined format according to the type of business transaction made available to the recipient data receiving system, the method comprising the steps of: receiving the image of the set of data associated with a source, intended recipient data receiving system and type of business transaction; displaying a single line of text of the image; using a template determined by the source and type of business transaction, to associate one or more data displayed in the single line of the image with a field of data; receiving input representative of the data associated with the field of WO 2016/000020 PCT/AU2015/000377 6 data; repeating steps b) and c) until predetermined types of fields are associated with respective input data to create a set of received input data; determining discrepancy between the received text based set of data and the recipient data for a respective field, where the type of business transaction determines the one or more fields to be checked for a discrepancy; presenting one or more field and respective data for visual inspection including at least those fields having a discrepancy; receiving an acceptance or correction of the data for an inspected field having a discrepancy; making a set of data and associated fields including accepted or corrected data compliant for processing the type of business transaction by the recipient data receiving system; and making the compliant set of data available to the recipient data receiving system.

[21] In another aspect there is a method according a prior aspect for receiving text based sets of data generated by two or more sources each set of data from a respective source being data specific to a type of business transaction for being handled and made available to an intended recipient data receiving system having recipient data associated with respective fields and adapted to have text based data in a predetermined format according to the type of business transaction made available to the recipient data receiving system, the method comprising the further step aa) performed prior to the steps of a an aspect being the step of receiving text based set of data and associating the text based set of data with one of the two of more sources.

[22] In another aspect there is a method according a prior aspect for receiving text based sets of data generated by two or more sources each set of data from a respective source being data specific to a type of business transaction for being handled and made available to a predetermined one of two or more recipient data receiving systems, each recipient data receiving system having recipient data associated with respective fields and adapted to have text based data in a predetermined format according to the type of business transaction made available to the respective recipient data receiving system, the method comprising the further step aa) performed prior to the steps of an aspect being the step of receiving text based set of data and associating the received text based set of data with one of the two of more sources and a predetermined one of the recipient data receiving systems.

[23] In another aspect there is a method for receiving, handling and making available a text based set of data generated by a source being specific to a type of business transaction from voice WO 2016/000020 PCT/AU2015/000377 7 responses on behalf of the source to a predetermined set of questions and generation for being made available to a recipient data receiving system having recipient data associated with respective fields and adapted to have text based data in a predetermined format according to the type of business transaction made available to the recipient data receiving system, the method comprising the steps of: applying a voice to text recognition mechanism to at least a portion of the received voice responses into a text based set of data; using a template determined by the source and type of business transaction, to associate one or more data with one or more field of data; determining discrepancy between the received text based set of data and the recipient data for a respective field, where the type of business transaction determines the one or more fields to be checked for a discrepancy; presenting one or more field and respective data for visual or audio inspection of the voice response including at least those fields having a discrepancy; receiving an acceptance or correction of the data for an inspected field having a discrepancy; making a set of data and associated fields including accepted or corrected data compliant for processing the type of business transaction by the recipient data receiving system; and making the compliant set of data available to the recipient data receiving system.

[24] It should be appreciated that the various aspects can be implemented in numerous ways, including as a process, an apparatus, a system, or a computer readable medium such as a computer readable storage medium or a computer network wherein program instructions are sent over wireless, optical, or electronic communication links. It should be noted that the order of the steps of disclosed processes and methods may be altered and still fall within the scope of the appended claims.

[25] Details concerning computers, computer networking, software programming, telecommunications and the like may at times not be specifically illustrated as such were not considered necessary to obtain a complete understanding nor to limit a person skilled in the art in performing the processes, methods and using the systems and apparatus disclosed, are considered present nevertheless as such are considered to be within the skills of persons of ordinary skill in the art.

[26] Throughout this specification and the claims that follow unless the context requires WO 2016/000020 PCT/AU2015/000377 8 otherwise, the words 'comprise' and 'include' and variations such as 'comprising' and 'including' will be understood to imply the inclusion of a stated integer or group of integers but not the exclusion of any other integer or group of integers.

[27] The reference to any background or prior art in this specification is not, and should not be taken as, an acknowledgment or any form of suggestion that such background or prior art forms part of the common general knowledge.

[28] Specific embodiments will now be described in some further detail with reference to and as illustrated in the accompanying figures. These embodiments are illustrative, and not meant to be restrictive of the scope of the appended claims. Suggestions and descriptions of other embodiments may be included within the scope of the disclosure but they may not be illustrated in the accompanying figures or alternatively features may be shown in the figures but not described in the specification.

[29] "Software," as used here in, includes but is not limited to 1 or more computer readable and/or executable instructions that cause a computer or other electronic device to perform functions, actions, and/or behave in a desired manner. The instructions may be embodied in various forms such as routines, algorithms, modules, or programs including separate applications or code from dynamically linked libraries. Software may also be implemented in various forms such as a stand-alone program, a function call, a servlet, an applet, instructions stored in a memory, part of an operating system or other type of executable instructions. It will be appreciated by one of ordinary skilled in the art that the form of software is dependent on, for example, requirements of a desired application, the environment it runs on, and/or the desires of a designer/programmer or the like.

[30] Those of skill in the art would understand that information and signals may be represented using any of a variety of technologies and techniques. For example, data, instructions, commands, information, signals, bits, symbols, and chips may be referenced throughout the above description may be represented by voltages, currents, electromagnetic waves, magnetic fields or particles, optical fields or particles, or any combination thereof. WO 2016/000020 PCT/AU2015/000377 9 [31] Those of skill in the art would further appreciate that the various illustrative logical blocks, modules, circuits, and algorithm steps described in connection with the embodiments disclosed herein may be implemented as electronic hardware, computer software, or combinations of both.

To clearly illustrate this interchangeability of hardware and software, various illustrative components, blocks, modules, circuits, and steps have been described generally in terms of their functionality. Whether such functionality is implemented as hardware or software depends upon the particular application and design constraints imposed on the overall system. Skilled artisans may implement the described functionality in varying ways for each particular application, but such implementation decisions should not be interpreted as causing a departure from the scope of the appended claims.

[32] The steps of a method or algorithm described in connection with the embodiments disclosed herein may be embodied directly in hardware, in a software module executed by a processor, or in a combination of the two. For a hardware implementation, processing may be implemented within one or more application specific integrated circuits (ASICs), digital signal processors (DSPs), digital signal processing devices (DSPDs), programmable logic devices (PLDs), field programmable gate arrays (FPGAs), processors, controllers, micro-controllers, microprocessors, other electronic units designed to perform the functions described herein, or a combination thereof. Software modules, also known as computer programs, computer codes, or instructions, may contain a number of source code or object code segments or instructions, and may reside in any computer readable medium such as a RAM memory, flash memory, ROM memory, EPROM memory, registers, hard disk, a removable disk, a CD-ROM, a DVD-ROM or any other form of computer readable medium. In the alternative, the computer readable medium may be integral to the processor. The processor and the computer readable medium may reside in an ASIC or related device. The software codes may be stored in a memory unit and executed by a processor. The memory unit may be implemented within the processor or external to the processor, in which case it can be communicatively coupled to the processor via various means as is known in the art.

[33] It will be appreciated by those skilled in the art that the aspects disclosed are not restricted in its use to the particular application described. Neither are those aspects restricted in WO 2016/000020 PCT/AU2015/000377 10 their preferred embodiment with regard to the particular elements and/or features described or depicted herein. It will be appreciated that various modifications can be made without departing from the principles disclosed herein. Therefore, the various aspects should be understood to include all such modifications within the scope of the appended claims.

[34] BRIEF DESCRIPTION OF THE FIGURES

[35] Figure 1 depicts a prior art order as would be created by a source for a supplier; [36] Figure 2 depicts a system for receiving information that is not compliant with EDI, processing the information and making available EDI compliant information in the form of an EDI compliant order; [37] Figure 2A depicts a simplified network arrangement for providing a single source to many supplier arrangement; [38] Figure 2B depicts a simplified network arrangement for providing a many sources to many supplier arrangement; [39] Figure 2C depicts a simplified network arrangement showing the ability of the arrangement to service groups of sources and groups of suppliers with multiple types of transactions and associated sets of data that need to be transformed into compatible sets of data for the receiving system; [40] Figure 3 depicts a flow diagram illustrating one embodiment of steps in the method of creating an electronic data interchange compatible order; [41] Figure 4 depicts a flow chart relating to the associate step involving an exact match process; [42] Figure 5 depicts a flow chart relating to the associate step involving determining a fuzzy WO 2016/000020 PCT/AU2015/000377 11 match process; [43] Figure 6 depicts a flow chart relating to the associate step; [44] Figure 7 depicts an illustration of an embodiment of the human intervention after the determine step; [45] Figure 8 depicts the output of the method being an EDI compatible file/document; [46] Figure 9 pictorially represents a particular supplier's database; [47] Figure 10 pictorially represents a known source's database; [48] Figure11 pictorially represents a known supplier's database; [49] Figure 12 depicts a pictorial representation of the compliance step following the receive step; [50] Figure 13 depicts a flow chart of the making available step following the compliance step of Figure 12; and [51] Figure 14 depicts a system for receiving information that is not compliant with EDI, processing the information and making available EDI compliant information in the form of an EDI compliant invoice.

[52] DETAILED DESCRIPTION OF EMBODIMENTS OF ASPECTS

[53] The embodiments provided are mainly directed to the area of electronic information exchange and in particular electronic document exchange for a particular type of transaction.

[54] The type of transaction will determine many things about the data sets of information to be WO 2016/000020 PCT/AU2015/000377 12 sent by the source of the transaction. In one example used extensively in this document, the transaction is an order from a source (a retailer of goods) for goods to be supplied by a particular supplier (the recipient of the order).

[55] Another type of transaction used by way of example in this document is an invoice issued by a supplier of raw materials to a manufacturer (that may also be the supplier to a retailer of finished goods), in another example, the invoice may be issued by the supplier to the retailer for the actual cost of an earlier fulfilled order.

[56] The term 'source' is used consistently as referring to the entity that generates or initiates the transaction using a set of related data and the term receiver is used consistently as referring to the entity that receives the transaction as a set of related data. However, depending on the situation and transaction the different entities, by way of example the retailer, supplier, wholesaler, manufacturer, etc. may be a source or a receiver in a transaction.

[57] As described, it is not unusual for the text based set of data and the way it is arranged and/or formatted for sending or being provided by a source to not be compatible with the format of a text based set of data, which can be automatically received by a recipient data receiving system, such as for example, an order sent from a buyer that does not have an EDI system to a supplier that does have an EDI system. There are also examples of the sending of a document (image or text based set of data) such as an invoice from the provider of raw material that do not have an EDI system to a manufacturer that does have an EDI system. Embodiments are provided to represent the receipt of documents (orders/invoices) from sources and enabling the compliance of the format of the document to that required by the receiving entity document receiving system.

Some of the embodiments disclose the receipt and handling of documents that may have a format and layout determined by the generating POS, accounting or ERP system of the source being accurately transformed for the needs of a supplier which would otherwise not be able to receive those documents without having to re-key all the relevant portions of the received document into the receiving system.

[58] This specification uses certain terms as a means to generalize the areas of application of WO 2016/000020 PCT/AU2015/000377 13 the aspects disclosed and one such example of that is the use of the term source, which is meant to include, in one example, a buyer that issues a non-EDI compliant order for goods to a supplier of those goods, and in another example, a source that issues a non-EDI compliant invoice since they are the provider of raw goods or services to a manufacturer, which may also be the supplier of manufactured goods to buyers.

[59] In an industry based example, let us say there is a Company A (any size) which manufactures widgets that are distributed to thousands of retail outlets - large and small.

[60] Company A has warehouses or Distribution Centers across the country full of the different varieties and sizes of Widgets they sell. They have some very big retail customers that, many years ago, demanded that they invest tens of thousands of dollars into electronic data interchange (EDI) technology that would enable them to receive Purchase Orders electronically from their software systems into Company A's software system.

[61] Company A's EDI service is facilitated by a third party logistics company called an EDI Bureau Company A's EDI Bureau receives orders from those very large retail outlets, either directly or relayed from another EDI Bureau across the EDI VAN, and automatically maps and on-forwards those orders for Company A in a file format that is compatible with their own (ERP) software.

[62] Even though Company A pays the EDI Bureau a small fee for every order they receive, the EDI system has paid for itself many times over. This is because their EDI orders do not need to be manually entered into their database which saves considerable time and money. They can also use the scan packing software provided by their EDI Bureau to pack their electronic orders which further improves order accuracy and turnaround times.

[63] Unfortunately only 20% of Company A's orders come from the large retailers. The other 80% come from 1,000 independently owned specialty retailers they sell to. Company A has asked their EDI Bureau if they can get these orders processed through their EDI network but they are unable to. As a result, most of the purchase Orders Company A receives from their independently owned specialty stores are sent to the suppliers' email inbox or to their fax machine, and the orders then have to be printed and then manually entered into their (ERP) software. WO 2016/000020 PCT/AU2015/000377 14 [64] Company A has a very good B2B website and the few online orders they receive from their buyers can be processed electronically without error, but unfortunately their buyers seldom use it. That's because ordering on the website creates more work for their customers. After a customer places an online order they still have to re-enter the order details into their own point-of-sale (POS) inventory system, effectively doubling their workload. So it's easier for their customers to continue doing what they've done for so long - enter the orders directly into their POS software system and send it as an email attachment or by fax.

[65] This '80/20 rule' makes servicing the smaller independent specialty stores much more expensive not only because of the additional time it takes to manually enter the orders, but also because of the costly keying and packing errors that result in goods being returned and credited.

[66] Databases used by suppliers and their buyers constantly get out of synchronization. When a supplier increases prices, not all of the retailers get around to updating their software system in a timely manner which results in Purchase Orders being sent with incorrect prices. When a supplier discontinues a product line, many retailers leave that code in their software system - maybe they still have stock - and they will re-order against the discontinued codes. Most commonly there are simple data entry errors at the retail end when entering the supplier's product data into their systems (like a zero instead of the letter '0') that all result in incorrect data being sent on purchase orders.

[67] By way of example, as depicted in Figure 1 (Prior Art) sources of orders such as a buyer, retail outlet, an agent, or even a wholesaler, provide in a document, their order 10, as depicted typically from their own POS system (which typically uses text based data to create the order) in a format that has been intended to provide an order 12 for use by the supplier and supposedly includes all the information the supplier will need to satisfy the original order 10. It is not unusual for the order 12 to be received via email (in the body or as an attachment (Portable Document Format (PDF) including extractable text or image only; Excel format (.csv file type); Text in a Word document (.doc or .docx file type); or via facsimile and since facsimiles are essentially only an image containing the relevant information (data set) this requires manual input of the information into the supplier's order system. Since these orders are not in a format acceptable to suppliers systems including the case of a supplier having an EDI system, manual input is typically required although WO 2016/000020 PCT/AU2015/000377 15 there may be some systems which can transfer, say the fields in a .csv file, to the fields in a larger system, or those systems where received documents are scanned and optical character recognition transforms certain information into text, there can be a need for a human to review the information for checking that information is correct (e.g. that the quantity ordered is commensurate with the units of those goods available, so if 18 single units were ordered and the goods are only available in packs of 6) and complete (e.g. whether a product identifier is missing). Even if the format of the data is compatible, the data contained within the set of data itself may be incompatible. Thus without some form of transformation a lack of compatibility will prevent desirable handling of the text bases set of data or document by either entity.

[68] There are many possible ways in which orders (text based sets of data or image only) are less than ideal for semi-automatic or even manual ways of processing them once received by the supplier. For example, the text based data in the source's POS system cannot always be up-to-date, thus, for example; when a product name 16 is chosen the latest model is not necessarily known to the POS system; when a price 18 is provided it may not be the most recent or applicable to multiple purchases within a given period; special rules may be applicable to certain transactions within certain periods; in some cases the price 20 may not even be known; when a product code 22 is used by the retail outlet it is not necessarily representative of the intended product code used by the supplier; when a product is no longer stocked by the supplier; the units 28 used to quantify the product need to be the expected units otherwise the total price will be wrong; anyone of the above issues and many others can cause delay and the cost of errors will burden both parties.

[69] When as is often the case, the received information is not provided by the source in a completely compatible form, the relevant data has to be inserted into the supplier's system manually, typically via a user interface to the front end of a purchase order-handling program, which uses fields and requires conforming content based on known field formats so as to be compatible with the larger product stock and manufacturing data systems in use by large suppliers. However, this information is generated only after a great deal of human intervention, by way of the operator carefully transcribing the data from the source document to the relevant field and in some cases the exchange of phone calls, emails and/or facsimiles between a representative of the supplier and a representative at the source. These efforts are ultimately useful but at the cost of the WO 2016/000020 PCT/AU2015/000377 16 lost opportunity to do other tasks, and the cost of the time devoted to the task by each party.

[70] It may seem simple to generate an order but it is known to be a major cost and time wasting exercise to convert those many different forms of orders (typically including at least one error whether they are text based or not) from many different sources into the order acceptance systems of the many suppliers needing to satisfy those orders. This is a many to one problem, which in the context of the embodiments yet to be described, is also related to the many-to-many issue: that is, there will be many sources needing to communicate, business to business, to many suppliers, whether that be the handling of orders or invoices or a myriad of other types of transactions.

[71] An embodiment of a system and method to handle the one to one and many to one issues is illustrated in Figure 2 by showing the processes involved in handling an order from one source to one recipient supplier, since in the case of many to one, that same supplier can receive many orders from many sources of orders but handle those orders in much the same way. The embodiment of a system to handle such orders is illustrative of one source (Doe's Retail Store) communicating an order to the one supplier (ABC Sports Supplies). A many-to-many situation is simply illustrated by multiplying the sources on one side and multiplying the suppliers on the other side (see Figure 2C).

[72] In this particular arrangement the source generates an order out of a POS system which is almost by definition a non-EDI set of data. Also in the embodiment depicted in Figure 2 the supplier is a user of the EDI systems including connection to the communication structures that make up an important part of the EDI network being an EDI VAN. Large product manufacturer's benefit from their large suppliers, generally of raw materials and services, also using EDI, but EDI is often not a viable option for small to medium retailers.

[73] The system illustrated in Figure 2 can be scaled up to deal with the many-to-many issue using the intermediate processing system 200 described herein, which can be, as depicted in Figure 2, provided as Software as a Service (SaaS) (in the many-to-one arrangement whereas many-to-many would not work for in-house software) and hardware implemented process, depending on the requirements of the supplier. Figures 2A, 2B and 2C depict various configurations of the basic WO 2016/000020 PCT/AU2015/000377 17 system. Yet to be described and depicted is the handling of invoices which will be disclosed later in this specification.

[74] Figure 2A illustrates the one-to-many configuration, depicted by the Source Doe's Retail Store using POS to issue an order 12, communicating that order using a network 212, being received by a SaaS provider system 200 for handling and making available, in this embodiment, an EDI compatible document for communication using a network 212' for receipt by one of the one or more suppliers (as depicted ABC Sports Supplies, where Supplier X and Supplier Y are shown in dotted lines since they are optional and do not change the principle of the processes of systems disclosed, etc.) expecting to receive orders as EDI compliant documents.

[75] Figure 2B illustrates the many-to-one configuration, depicted by the multiple sources,

Source Doe's Retail Store and its POS A 210'; Source 2 using POS B 210"; Source 3 using POS A 210'", Source 4 using POS Y 210'" each having their own databases and respective recipient data representing the various goods/services that can be supplied, issuing a respective order for the one supplier (ABC Sports Supplies) with communication of those orders using one or more networks 212, and received by a SaaS provider 200 for handling and making available an EDI compatible document for communication using a network 212' for receipt by one supplier expecting to receive orders as EDI compliant documents. It will be appreciated that even though different sources are using the same POS all the orders generated by the POS of each source are likely to be different in format even though they are intended for the same supplier, such is the lack of standardization or co-ordination between the respective industry entities.

[76] It may be necessary to pre-process received orders in the many-to-one configuration since the system 200 will receive orders from all of the sources. In one embodiment receiving a text based set of data will require associating that text based set of data with one of the two of more sources. The use of text based data associated with the received text based set of data, text within a header or subject line or even associated meta-data of the transporting email, the TO: and FROM: addresses which may be associated with text based and image based orders can be processed by many other methods all of which are readily implemented, and the association is stored in the memory associated with the system 200 for use as required. WO 2016/000020 PCT/AU2015/000377 18 [77] Figure 2C depicts multiple groups of sources (A1, A2, A3) and (B1, B2, B3) each entity issuing orders from their own POS meant for one of the recipient data receiving system of a supplier out of the 1 to M depicted. Also depicted is that each supplier recipient data receiving system receives orders in its own format to suit its own order receiving system and even with those suppliers that use EDI there can be differences from industry to industry.

[78] It may be necessary to pre-process received orders in the many-to-many configuration illustrated in Figure 2C since the system 200 will receive orders from all of the sources for one of the many recipient data receiving systems (suppliers, etc.). In one embodiment receiving a text based set of data will require associating that text based set of data with one of the two of more sources and a predetermined one of the recipient data receiving systems. The use of text based data associated with the received text based set of data, text within a header or subject line of the transporting email, the TO: and FROM: addresses which may be associated with text based and image based orders can be processed by many other methods all of which are readily implemented, and the associations are stored in the memory associated with the system 200 for use as required.

[79] Electronic Data Interchange (EDI) is a digital data exchange between an originator and a recipient typically the interchange is via a document exchange where the format of the document is in accordance with a shared standard. The documents or data elements of an EDI message can be electronically exchanged using various devices. The existence and adherence to the relevant standard is meant to all but eliminate human intervention, other than in certain error conditions or special situations, otherwise the exchange is part of a computer-to-computer only interaction between the parties. EDI includes the entire electronic data interchange method and model, including the transmission, message flow, document format, and software used to interpret the documents or data elements and can be achieved using computer networks connected to the world-wide network of computers or direct from originator to recipient computers or computer networks (peer-to-peer), via multiple forms of communication pathways. Often Value-Added networks (VANs) are used, and to be described by way of analogy, a VAN acts not unlike a regional post office acting merely on the From and To address of a message (contained within a header of the WO 2016/000020 PCT/AU2015/000377 19 document/file to be exchanged) and the many Bureaus that make up the VANs operate to handle very specific groupings of originators and recipients (such as within a particular industry). There can be different standards for different industries or regions. Thus when data is said to be compliant with EDI information there will be a known standard that the originator (source in this description of embodiments) and the recipient (in this description of embodiments) are using and the information is provided as an EDI message. The originator and the recipient can be interchanged within the EDI arrangement as long as the EDI information is compliant with the agreed and known standard. An EDI document can be used for any particular function, by way of example the document can be an order, an invoice, change document for goods, etc.

[80] Referring again to Figure 2 depicts a representation of an embodiment of a system (hardware and software) and associated method to deal with and provide an alternative way to deal with the problems illustrated by the description associated with Figure 1.

[81] The order 12 provided by a source is provided to and received by the supplier, by way of example, email (in the body or as an attachment); facsimile (this method being less likely than email but still used) or post (with post less likely than both facsimile and email).

[82] In a preferred embodiment the communication used by a source is email which is received electronically via what is generally termed the Internet, a collection of computers and computer communication networks which deliver electronic files and messages using well know protocols. In this example an email sent from the source is received at an email server or Web based email endpoint which is virtually intermediate the source and the recipient, since in this embodiment, the virtual intermediate recipient system 200 (Figure 2) will be the system that transforms the associated text based set of data/document into a form suitable for the recipient system. In this embodiment, the intermediate recipient system has an email domain of 'portalog.com'. The received email is usable in the form it is received, since the addressing of the email can provide particular information that is immediately useful to the system 200. For example, an address of the form From: myretail@myretail.com To: abcsports@portalogue.com provides both the source's name (the From: information) but also the intended supplier's name (the first part of the To: email address) which can immediately be used by the system 200, which is set-up to receive email to the portalog.com WO 2016/000020 PCT/AU2015/000377 20 domain mail server. The To address ensures that the email will be received by the email server acting for a third party entity which is the intermediate recipient system 200, in this example, Portalogue Solutions Pty Ltd (Portalog). The mail server can be programmed to direct the email in many ways but in this preferred embodiment, Portalog is the provider of the system 200 and the email header and email body and attachment is dealt with (e.g. the text based data within the email body or document attached is parsed) to provide the many functions described herein. Alternatively, the sender may send their email order directly to the recipient i.e. the supplier at orders@abcsports.com and a redirect rule applied by the supplier's email server redirects the email to abcsports@portaloa.com .

[83] Using the date included in an email, such as the header information and other meta data available in the body of the digital email message, ensures the accuracy of the identification of the intended recipient (intended supplier of the goods in the order and in particular that suppliers' recipient data receiving system) of the emailed order, such as when it is available in the To: identifier, since the To: identifier is preprogrammed at the source end email system and thus is more likely to be correct every time an email issues from the respective email system, thus avoiding human error. Furthermore, the TO: identifier is an email address which will be used over and over and is typically retrieved from the email system semi-automatically and hence will also be likely to be correct.

[84] Thus, the email header information can be used by the intermediate and recipient systems to a) refer to the respective 'myretail' Sources Database (210) for additional information relating to the source which has been collected, checked and configured where required to be in EDI format and in an associated named EDI required field; and b) refer to the respective 'abcsports' Recipient/suppliers database (220) for additional information relating to the supplier, optionally unique identifiers such as bar codes or Electronic Authorization Number's (EANs) (typically required for an EDI format) for their stocked products and associated product codes and descriptions, pricing, units of product, supplier level discounts, respective delivery requirements, freight terms, and maybe even stock levels at a particular time, which has been collected, checked and configured where required to be in EDI format and in an associated named EDI required field. WO 2016/000020 PCT/AU2015/000377 21 [85] However, it is not enough to merely receive the email representing an order 12 even with the addressing scheme described. The system 200 can determine that the email having been sent from a particular source to a particular recipient can and will identify the type of business transaction which is associated with the text based set of data, is in this case an order. However, there are other ways of determining the type of business transactions involved, such as the time of receipt of the email; the TO address may be unique to orders to a particular supplier, while in another example the TO address is indicative of an invoice to a particular recipient, etc.

[86] It is with the assistance of the information available to the system 200, that it is then possible to handle the text based set of data in one of many ways to transform that data into a format and ensure data/information accuracy which is acceptable to the recipient system, since some of the abovementioned problems will still be evident within the document attached or associated (link to Web based file, .csv file, etc.) with the email.

[87] A central processing unit and associated memory are depicted in Figure 2 since these are the minimal hardware aspects with which to operate the system 200. This is an overly simplistic illustration since the hardware configuration can be arranged in numerous ways, for example only, by way of a server (having one or more CPU's) or multiple servers or even virtual server/s at the same location, or as is becoming more often the case, a more complicated array of digital data communication networks that link dispersed servers or virtual servers that can be resident near or far from the nominal operating system location of the intermediate system 200, as in other Software as a Service, Platform as a Service and Infrastructure as a Service, for supporting the provision of the intermediate system 200. The latter mentioned configurations may be preferable when the scale of the service and servers required, needs to be changed, in one common example, as the demand for the service they provide becomes a preferred approach to multiple sources and multiple suppliers. In which case the increased number of servers required to service the increased need for computing power can be, almost instantly, made available and it may be that those additional servers are located in different parts of the same city, in another state/county/province or even in another country due to the disparate nature of systems and services available on demand. Commensurate with the increase in required computing power is the need for memory on which to store the active variables, the temporary field values, look-up-tables (LUTs), and raw data that WO 2016/000020 PCT/AU2015/000377 22 makes up the databases of the various recipients (suppliers) and the supporting database organizational and controlling software. The system 200 is used to execute a computer program product comprising a non-transitory computer useable medium (by way of a non-limiting example, a digital data memory device for example a hard drive, a Read Only Memory (chip or other hardware based), a non-powered digital data memory retention arrangement (again by way of a non-limiting example, organic or silicon based)).

[88] The software executed from the memory can comprise distinct software modules, including a processing module, a configuration file processing module, a data organization module, and a data display organization module and less or more software than described as deemed by the person skilled in the art as required to perform the desired functionality, the most relevant of which is described herein.

[89] There are various steps to a preferred method of performing the desired functionality displayed pictorially in Figure 2 as being associated with the memory of the system 200 as those steps are performed by a CPU but the respective data and intermediate and output data is stored in memory (Random Access Memory and what is generally referred to a long term memory on a Hard Drive or Redundant Array of Independent Discs (RAID) array). The steps of an embodiment of the method as described herein may have more or less steps; a receiving step 202, an identify step 203, a use template step 204, a determine step 205, a present step 206, a receive data step 207, a compliance step 208, and a make available step 209. More detail about each of these possible steps and some of their variations will be provided in this specification. The various steps disclosed can use the hardware/software and combinations thereof of the system 200 and not all of the steps need be in the order presented.

[90] The receipt of an appropriately addressed email is not the receiving step 202. The email is merely a carrier of the relevant information, such as an order (in this embodiment). As previously described the information can be supplied in many forms and in this embodiment the form of the information is a text based PDF document attached to the email. Being a text based PDF ensures that the set of data contained in the document can be extracted without any issues with regards the accuracy of that set of data. The system 200 and method described herein is arranged to deal with WO 2016/000020 PCT/AU2015/000377 23 errors/discrepancies in the data but for the purposes of the process, of this embodiment, the text based set of data is then receivable (step 202) into the processes to be described as performed by the system 200.

[91] The receive step 202, is in this embodiment, the receipt of the text based set of data representative of the transaction within the PDF document that was attached to the received email.

[92] Since the email header contains information that identifies the respective source and supplier, it is possible to determine various features of the PDF document attached to the respective email.

[93] In the first instance the receipt from a particular source of an email directed to a particular supplier can be indicative of the nature of the transaction. In the embodiment, the transaction is identified as an order since the system 200 can identify from the source and intended recipient (supplier) that the text based data will be associated with an order for that supplier. An alternative, identifying step 203 is to perform a scan of the text based set of data and determine if there is text that matches one of the terms: 'order'; 'invoice'; 'change order'; etc. and if there is a match, use that determination to identify the type of business transaction associated with the text based set of data. A further alternative is to use the TO address which can be arranged to be indicative of an order.

[94] Having identified the intended supplier from the TO: address detail, and the type of transaction, it is possible to apply a template relating to the source and type of business transaction to the PDF document and also if of assistance load from the respective databases various information, such as for example, patterns or rules that will assist with the following steps, so as to associate one or more of the received text based set of data with one or more field of data used by the receiving system.

[95] As mentioned previously the format of the received order can be varied, but it will be known that a particular source will use a particular format, e.g. PDF, attached Excel or .csv file, etc. all of which and others are output from the source's system, POS system, accounting software program, specialized order creation software, etc. the only common aspect of those outputs is that WO 2016/000020 PCT/AU2015/000377 24 they are not in an EDI compatible format. Thus knowing the format allows the system 200 to have additional knowledge of the particular layout of the information in the order and thus apply a predetermined template relating to that source and business transaction to associate one or more data with the one or more fields of data. There may be different formats of order generated by the supplier depending on the intended supplier so there may be multiple layouts of orders generated from the same source. There will be additional ways of handling the information provided even when supplied as a facsimile image and those ways will be described later in this specification.

[96] Thus by way of example, if the order format is in Excel or .csv format it is possible to transform and associate a particular cell content in the original order directly to a respective field and/or value suitable for use in the required (desirable) compliant set of data for the recipient data receiving system of the supplier. For example, cell B5 in the .csv file is known to contain the "Order No." so that field value is associated with a respective field value for the set of data intended for the recipient source but only after further steps in the process have been performed. In this example there is no transformation of the data but there is an association. Byway of a further example, cell C10 in the .csv file is known to contain the "Product Code" being the actual product that the source wishes to order from the supplier. The field contains the data "ABC.123" so that field value is associated with a respective field value. In programming terms the .csv file is transformed in to a library using a predetermined template that provides a list of the cell identifier associated with a particular field.

[97] Note that in the case of the received document being a PDF document and for the purposes of one example, the PDF includes embedded text (text based set of data), that text can be easily extracted. However, the text may then be unstructured, in that the content of the text may not be related in any particular way to the document layout. Moreover the meaning of the text is lost without the text being mapped to a respective title in the document, or its position, or its context, which are all obvious to a human reviewer of the original PDF document or of the extracted text but not so to a computer CPU and associated memory.

[98] Thus in one embodiment, in preparation for the receipt of an order in a PDF issued by a particular source, the format (layout) of the PDF order is reviewed by a human. The human is trained WO 2016/000020 PCT/AU2015/000377 25 to identify each information element displayed on the order, such as for example, order number, a product name field, a quantity field, a delivery address field, and the many other types of fields are identified.

[99] In one approach, if the PDF is capable of providing text (text based set of data), the order of the text can be noted and for each identifiable block of text the human allocates a field heading which can then be mapped or discarded for the purposes of creating a transformed form of the order details appropriately associating each identified text block with a field in the desired source document format. This mapping becomes the predetermined template relating to the source and type of business transaction which associates one or more data of the text based set of data obtained from the PDF with one or more field of data.

[100] In another approach, particularly in the case where the PDF is an image (no text extraction from the actual PDF file is possible) or the source of the document is a facsimile which is only an image (although if received in an IP environment there may be useful header/meta-data information in the session-management procedure of the transmission, such as TO and FROM data and, there may be in time, the ability to extract the binary coded data PCM and encapsulation in RTP used for transport frame(s) in a manner that also extracts the actual source text and thus the text based set of data).

[101] When otherwise dealing with a pure image, those case examples require a human to identify the relevant fields/headers and the associated text and to physically map the area (by identifying with a + shaped cursor the four apexes of a region of the facsimile page image (relying on a consistent registration of the page), within which the relevant text is located on the order document, so that some or all of the relevant text fields from the original document can be electronically/digitally identified. Thus since, as indicted earlier, if the actual Source is known it is possible to extract from the respective database rules/template to assist in the task of transforming and associating the transformed information with an appropriate field. Rules define the expected location of information, which is just another form of mapping, which assigns determined data to a highly likely field in a predetermined format. In one embodiment a received image would be pre-processed to convert the image based document into a text based document, and then the same WO 2016/000020 PCT/AU2015/000377 26 steps as previously described would be performed as if the originally received document was as a text based document containing a text based set of data.

[102] For example, a known Order will have a spatial format which can be expressed in many ways, but by way of example, the information which represents the Order No will always be located in an area of the form, defined by the coordinates (7,5)(18,5)(18,10)(7,10) on a x,y centimeter grid overlaid on the Order sheet. Having an appropriate rule of the type described will then allow population of selected fields identified by that mapping.

[103] This approach is not always possible and is labor intensive and not always suitable and the forms may change over time. However, this one time manual process facilitates repetitive machine handling of those types of orders that previously have only been dealt with manually.

[104] The operator mapping step enables the electronic handling of these types of orders but still requires the further step of Optical Character Recognition to transform the imaged text within the relevant regions to be transformed into digital text. Once the mapping of an image of the transaction/document has been performed it is possible to apply the optical character recognition to at least a portion of the received image containing the set of data so as to transform a part of the received image into digital text data. The portion or portions of the image to be transformed can be in one embodiment those portions identified as containing certain fields of data, such as for example, the order identifier, the product identifier, the quantity figure, the various column headings, the price figure, the total price figure, the special handling information, etc.

[105] A yet further way in which to transform the information in an image only transaction into a text based set of data useable by the system, is to display a predetermined portion of the image, say one line at a time, say of the table within the image, which represents the ordered goods while also displaying a set of fields and blank field data input areas adapted to accept data input. The display of the image of the order and the simultaneous display of a corresponding order receiving input page can be provided on a suitably large single monitor, the main advantage being that the operator is able to view all the relevant information at the same time. The line is typically readily identified by a human or a suitably programmed machine and the display of the line can be WO 2016/000020 PCT/AU2015/000377 27 presented to a human such that the line and only the line is clearly visible while in a further display the yet to be filled in data fields are presented to the same human. The display showing the line only is controlled to display the remainder of the imaged document but in a manner so that it is not clearly discernable, so as to focus the attention of the human reviewing the data displayed in that line. The image of the line can be supplemented by the overlay of a pointer having a heading that is related to the field of the data which is to be entered on the non-image display, for example, the Quantity field has a cursor within the field, hence the single line display has a pointer marked 'quantity' located over the quantity portion of the displayed line, which is achievable since the imaged information has been previously mapped in a manner similar to that described previously, wherein according to the source and type of business transaction it is possible to associate one or more data displayed in the single line of the image with a field of data. Once the one portion of the line image has been carefully viewed and the number depicted there is entered into the corresponding field in the order entry display, the cursor can tab automatically to the next field to be entered, for example, the product identifier field and while that occurs the marker along the line image moves above the portion of the line containing data relating to the product identifier, so that data can be carefully viewed and the data entered into the corresponding field, etc. until the required/predetermined fields of the order entry display are occupied with the provided set of data obtained from the image.

[106] Yet to be described though, is the advantage such a mapping process and consequent use of predetermined templates provides in that since each of the predetermined fields and the associated OCR text is correctly identified in a very reliable way, there is a high likelihood that the data will be correctly associated with a respective field, then the further steps of the process can be more accurately performed.

[107] There may be a combination of the above techniques and possibly other mapping techniques to provide the use template step 204 and the determine step 205. Indeed a fusion of such processes will ultimately improve the accuracy of the whole process.

[108] The inventor has also recognized that the information can be provided by way of a voice order from a human calling from the source/buyer (there being a number of ways in which that can WO 2016/000020 PCT/AU2015/000377 28 be achieved). By way of example only, the receipt of a digital file representative of the voice of the source order giver, in the form of a .wav file, saved to memory the .wav file contains a digital representation of a voice order provided according to a predetermined script which prompts when and the what of an order; or by way of another example, a phone ordering system (separate or web based) where a voice prompts responses by a person calling from the source, where all the required details are prompted by the voice and the person calling need only verbally respond to create an order.

[109] In all the prior examples, the voiced information can be transformed by a voice to text recognition mechanism operating on at least a portion of the received voice responses into digital data, in the form of text representative of the information, in particular, so that the text can be used to create a text based set of data with which to prepare the order information for yet further processing in accordance with the embodiments described hereafter. The advantage of such a system being that only the information required is requested and that the converted voice to text is associated with a particular field in a predetermined order. However, there is still a need to check the text for most of the same reasons that other orders need to be checked, since in one example, the transformation of the voiced details may not be accurate, e.g. the product name has been provided by the source, but a) the transformation into text is inaccurate, or b) the actual name of a product requested in the order is not the name used by the supplier of the correct product, or c) the product is no longer available, etc.

[110] As depicted in Figure 2 the determining a discrepancy step 205 is related to all the information that has been accumulated into the now text based set of data. In an embodiment, the transformation of, say a PDF document, where Figure 3 is a pictorial representation of the transformation process begins with the association of the PDF order with the source and supplier identified by way of example, in the email address as described above.

[111] Figure 3 depicts a flow diagram of the steps used to create an Electronic Data Interchange (EDI) compatible order (however it will be understood that the various steps described can be applied in such a way as to produce a document which would meet any desired requirement as to format and digital data content for the respective recipient system). WO 2016/000020 PCT/AU2015/000377 29 [112] In this particular embodiment as depicted in Figure 3, the steps 202, 203 and 204 are as described in some detail above, but they are preliminary steps in handling an order provided from a source as a document 300 in a digital file having a Portable Document Format (PDF), containing information which is not in EDI compatible format. The PDF document may be associated with an email, as described above. Knowing the various entities (source and supplier, even if there is an intermediate entity performing the processes described) allows the appropriate rules of transformation/association to be applied using the predefined rules and patterns. Thus, the transforming steps of a PDF document into text representative of various information is performed if required to ensure that the relevant information is associated with the relevant field as depicted in the box 204' of Figure 3.

[113] Patterns are used by a computer CPU and memory to review and identify information contained within the extracted text file without necessarily knowing the order or position of the information in the original document. A pattern or regular expression is a computer readable expression used to specify a set of character strings that match a particular purpose, including match, partial-match, exclusion, and fuzzy/close matching. Regular expressions consist of constants and operator symbols that denote sets of strings and operations over those sets. Various constructions of individual expressions can be combined to form arbitrarily complex expressions.

[114] For example, if there was to exist a color of a product that could be "grey" one way to match the field value correctly, while taking into consideration that the word grey can be spelt "grey" or "gray", is to use in a regular expression, as might be used in method step 204. The "or" operator "\" is ideal for this situation, so the relevant portion of the regular expression would look like grey | gray to match either the word "grey" or "gray". In another example, the term "Order no.: 12345" is an important identifier to locate since the characters following the string "order no.", in the extracted text file are likely to be the required Order Number to be associated with the order. Thus a simple example of a regular expression to identify the existence of a string of characters can look like the following, although there are many ways to create logically equivalent expressions to achieve the same outcome: A[0|o.rder]$[:]".*" WO 2016/000020 PCT/AU2015/000377 30 [115] Thus, first the string "Order" or "order" with some characters following, whether that be "no", or number" or "no." followed by a ":" indicates that the following string which is "12345" is the order number to be used in the respective field. The Order No example is not ideal since at this stage of the process the relevant data has already been identified as an order number, but the principle of the use of a regular expression to assist the association of a supplied text to what it should be according to the suppliers' database which contains recipient data, is readily apparent. This step could also be applied to the "apply template" step, wherein this step can form part of the rules of a template where the template can be a combination of pattern recognition and coordinates, as described previously.

[116] The compilation of a number of patterns to cover all the required fields and identifiers when a mapping is computer assisted, and related information is a non-trivial step for the purpose of achieving a portion of using a template step.

[117] By way of a non-limiting example, when the document received, as relates to method step 204, is not in a PDF format, or the PDF is an image only, data such as e.g.'1234' in the order form, is transformed from the printed sheet format by way of Optical Character Recognition (OCR) into a digital character string '1234'. However, it is not readily apparent which field that string is to be associated with. Is the string the product code or is the string the order number? Using a prior mapping of the relevant fields is one way to associate the field content with a corresponding field in the EDI compatible form. In another example, the order of the text located in the original document is used, so that by identifying that the term "Order No.:" it is a reasonable assumption that the next string of text is the actual order number, and just this example is disclosed above.

[118] The output of the foregoing steps, associated with method step 204, is a structured document file suitable for further processing by the system 200, which the text based PDF document is not. Figure 3 provides an example of the format of the structured document/file 204', wherein the categories include: source, supplier, order number, delivery, comments, instructions, and line items, including, product code as provided, description, quantity, unit, price, and other information, possibly including total price. This text based set of data can be displayed as a document, as a file, WO 2016/000020 PCT/AU2015/000377 31 or stored as a virtual document/file and each part of it is located in the memory associated with a CPU of the system 200 having the required flags, pointers, addresses, and if available a database reference or associated references, as would be used by a program to keep a record of the text based set of data. Copies of the data that make up this file may be stored elsewhere and possibly even in one or more databases.

[119] Figure 4 pictorially represents an exact match method which can be part of the method step 205, where the data, for example, "ABC123" which is associated with the product name field, is copied into the memory associated with a CPU and compared to, the data associated with the content of the associated field in the supplier product database (relational database containing recipient data and respective fields), where in this example, one of the product name fields has the data "ABC123". The example used indicates that there is an exact match. However that is not always the case and it is just as important to locate matches as to identify when there is no match and thus a possible discrepancy.

[120] Sometimes there is no match, which can relate to the method step 205, because for example, there is no information with which to match because the source did not have the relevant information with in the recipient data, such as price; or the information is based on old information for a product that is no longer available; or that the source has miss-typed information representative of the product code. In those situations there is the option for human intervention. Typically a skilled human knowledgeable of the supplier's offerings is able to make a match and this step will be described in greater detail later in the specification.

[121] When there is a match or an acceptable match as described above and as related to method step 205, it is possible to then extract recipient data relating to supplies, prices, stock levels, unique product codes, etc. from the respective recipient/recipient/suppliers database all related information associated with that product and use that to assist a human to check and manage the final association of the supplied text to that which is useable in a document/file to be made available to an EDI compatible or other recipient system. The extracted data/information being for example, the unique bar code of the product 1234, other characteristics, such as product name "Baseball", color "gray", size "229 to 235 mm", cover material "leather", etc. which all need WO 2016/000020 PCT/AU2015/000377 32 to be checked as can be the quantity of units, the cost and total cost for the order..

[122] Figure 5 pictorially represents a fuzzy match method, where data, for example, "12.ABC123" which is associated with the product code field provided by the source, is copied into the memory associated with a CPU and compared portion by portion with the data associated with the content of the respective category associated fields in the recipient/supplier database. As will be apparent, the product code from the text field is not quite the same as that in the recipient/supplier's database, and thus not correct, since it contains a prefix of "12.". As part of setting up a template for a given source, it is possible to store this information and compare it against the this source data ( and which can be used at other stages of the process to strip off characters before attempting a match in the supplier's database. Alternatively, it may be possible to split the received product identifier into portions, perform a search and add portions (maybe a character at a time) until only one search result match is identified. However, by using both or either of the examples suggested above, it is possible to suggest that the "12." prefix is superfluous and to be ignored, thus the product code is in fact ABC123 that would in an embodiment be presented to a human to check.

[123] The file itself may be nothing more than links to the data which has been transformed as described above and is resident in other memory with the system, on servers and their associated memory. The use of the term document/file is merely a convenient way to describe a collection of information and those terms are merely indicative of the real world 'order' that is typically the physical input to the system 200 received from a source.

[124] Thus it will be seen that the steps 202, 203, and 204 can be performed or not performed depending on the format of the order received and the existence of information in one or more of the fields including the order. However, as also explained, there can be an existing mapping of one or more fields of the information to a respective known Electronic Data Interchange field type. Not all the fields will include data and as has been mentioned previously this can result from inadequacies of the originating POS system, human error, or lack of information.

[125] So far, an ordered file has been created by operation of the receiving, identifying, and WO 2016/000020 PCT/AU2015/000377 33 determination steps. However, the information in this text based set of data is still vulnerable to most of the problems of the prior art and still not in an EDI compliant format or a compliant format with the recipient data receiving system at (ABC Sports).

[126] In the embodiment depicted in Figure 2, the system 200 may access two particular databases, the source database (which may only be by way of the receipt of the business transaction in one or other form); and the supplier database (ABC Sports). Access to the source databases is arranged as will be described in more detail later, to create a copy of relevant parts of that database which are called on in the performance of this process controlled by the system 200. The copy of the database may in fact reside in the same physical hardware media as the system 200 which has its own database/s that are used to store data over time or temporarily, but logically the source copy database and the system databases can be part of the same physical hardware but logically separate. The arrangement of computer hardware devices and software of the system 200 can be very different to that described in this embodiment. Indeed the number and configuration of various databases is a matter of design relating to ease of use, software licensing, hardware configuration, etc. all being matters known to those skilled in the art.

[127] These databases are searchable and information is readable from the databases as part of the computer processes available to a CPU and memory controlled by the operating software and the program software.

[128] Preferably the data in the copy of the supplier database 220 has previously been downloaded from other databases or entered manually. It is to the Suppliers benefit that the databases used by the system 200 are as up-to-date and correct as they can be, but that cannot always be the case.

[129] Figure 2 depicts a copy of the supplier's database within the system 200, containing searchable and managed information relating to Suppliers (see also Figures 9 and 11): such as the names of all the suppliers (e.g. ABC Sports Supplier Co., etc.); the names of all the sources which each supplier supplies product to (e.g. My Retail Store, etc.); all the products provided by each respective supplier (see also Figure 9); along with all the required details of each product, including WO 2016/000020 PCT/AU2015/000377 34 at least price, unit type, unique bar code of each product; predefined delivery addresses for each source; predefined delivery arrangements for each source; predefined invoice addresses for each source; payment terms for each source; suppliers used by each source; communication addresses "TO" and "FROM" used for information exchange; there may be a double up of some of the information on the Source's database and other information within the system 200. All the information within the database can be predefined and/or updated as required but in the main is supplied direct from the suppliers themselves from their EDI or other type of database, but typically not on an as needs basis.

[130] The supply of the information/recipient data from the recipient/suppliers database can be arranged, in one embodiment, using EDI data exchange protocols so that the information is available for the determining discrepancy step (with respect to various field types and related data) and for the steps preparatory to the making compliant step for making the EDI compatible order to be made available 209 to the supplier. The recipient data receiving system is adapted in various ways to have data made available to it as well as making the recipient data therein made available to external databases, and in one example, there is the option of, instead of there being a copy of the suppliers' database available to the system 200, there are calls made from the system 200 for various information, as required, by the program running on a CPU and Memory of the system 200 and this would ensure that the very latest information is available for the relevant steps of the method. However, there would need to be 100 percent availability of communications to and from the supplier's databases and 100 percent up time of the supplier's servers and an acceptably short delay in obtaining the information to ensure that large volume handling of transactions will be unaffected. This later approach is not typical and it is a preferred approach to pre-store the recipient/supplier database within or readily accessible to the system 200.

[131] As disclosed previously, Figure 3 depicts the step 205 of determination of whether a data value in a field is a match for the data in the respective field of the copy database. The disclosure of an exact match process is disclosed but fuzzy matching is an additional and optional process. Matching is used at the determination stage 205 to ascertain when data is not the type of data expected or the data expected is not as expected when compared to the data held in the system (the data being a copy of data in the supplier's database as disclosed previously). The present WO 2016/000020 PCT/AU2015/000377 35 stage of the method matching can be used to improve the presentation of choices and alternative data during the presentation step 206 of the process when a miss-match has been determined. However, the selection of the correct data for being sent and received by the system is made easier and assisted by this alternative or optional additional process.

[132] Checking every line item for a category against the data in the supplier database ensures that the data in a field matches the expected type of data in a respective field. This can be achieved in the number of ways described as well as many other ways known to those of skill in the art. The matching aspect of this step is described above which when completed allows the creation of an association of the data in a source field with the relevant correct data in a supplier field.

[133] Figure 6 also depicts a branch 610 which is also depicted in Figure 2 as the presenting step 206 being the process of human intervention that arises when no match is found or the match does not satisfy a fuzzy match criteria, or the matching process is deemed to be unsure of the match, between the data in a field from the now more structured source information and the data in the respective fields in the supplier database.

[134] Figure 7 depicts the human intervention 610 step of Figure 6 and details how a human 700 is, in one embodiment, presented information on a visual display 710, comprising both the original document 12 and a document 290' which is not yet ready to be used as the EDI compliant order 290. The person 700 is in this embodiment located at the suppliers' premises and is accessing the system 200 via the Internet and being presented 206 the original order and the, by then, more ordered data and having access to the copy database information relating to the one or more data that is not matching or is not correct. The ways in which this array of information can be presented is infinite so the following is but an example.

[135] Since the document/file containing the relevant data is available for human visual review there is an opportunity for the human (knowledgeable of such document formats and associated information since they are likely to be persons employed by the supplier and located at the suppliers premises) to check the entries in the fields but in particular, to review in some detail the apparent inconsistency between the digital data in one or more fields of the source document 12 WO 2016/000020 PCT/AU2015/000377 36 (order from the source) and the expected digital data of the supplier document 290' (order to the supplier). At this stage the order has not made it to the suppliers' order system but is being presented 206 for human review, since for one or more reasons the matching (exact/fuzzy/other) has not resolved the source data to a known supplier data transformation.

[136] Thus there is described a method for providing the order provided from a known source and the mapped one or more fields of the information to a visual display for review by a human and for the method to further include the system 200 accepting from a human user interface a command to alter one or more fields of the data/information; and making the altered data/information to be received 207 and for storing the altered information in a digital data memory associated with a CPU of the system 200 and then made available for the process thereafter.

[137] The example provided shows that the third item in the Code column is unfilled since there was no match for the product in the supplier's database based on the information provided in the source's unstructured document. The use of a unique identifier code such as a bar code is very important to the EDI compatibility of any document provided to an EDI system. In this case, a human can resolve the inconsistency and the appropriate product is identified and the associated bar code inserted into the document/file to thus make the data field/created document/file 290 more EDI compatible.

[138] Furthermore, the supplier's database typically has all the most current and correct price details and those are transferred into the appropriate data fields for respective items and combined with the quantity and unit for each item to allow for the calculation of the correct total price and inserted in to the appropriate field to thus make the data field/created document 290 EDI compatible.

[139] Since the supplier field data is EDI compliant, any file/document 290 created from the matched and created data is also EDI compliant. The compliance step 208 is almost automatic if the data set contains data which is in the expected form and then compliance is the process of formatting the data set into a file format expected by the suppliers' electronic data order receiving WO 2016/000020 PCT/AU2015/000377 37 system. In the embodiment described the format is a known EDI format and as shown in Figure 8 such a formatted file/document can be automatically made available 209 to an EDI VAN. It will be apparent that making compliant step relates equally to recipient data receiving systems that have their own requirements which will be different to EDI formats.

[140] Figure 8 pictorially depicts that the EDI compliant file/document can be made available 209 (Figure 2) to the supplier in multiple ways, such as via email as an attachment, copied in digital form as a data packet, PDF form, .csv file, etc. to a digital data storage (hard-drive/remote storage (cloud storage or storage related to a remote server controlled or not-controlled but accessible by the supplier system)) for copying by the supplier system; transferred using File Transport Protocol (FTP); and or using Hyper-Text Transport Protocol (HTTP), or any other convenient methodology. Preferably, the method used is suitable for use into an EDI VAN which is an interface between sources that use EDI compatible orders and suppliers that have EDI systems. An EDI VAN is a useful element of such a system since EDI VANs are typically a collection of like industry entities and their use ensures that the pathway to and from this collection of entities is utilized and the synergy of using this form of connection provides benefits to the suppliers, VAN operators and ultimately to the sources and the intermediate system 200 as disclosed herein. The various ways to make a compliant set of data available to the recipient data receiving system also relies on that system being adapted to receive the set of data.

[141] Figure 9 depicts an example supplier database illustrating in particular the EDI compatible data of the supplier Baseball Supplies and a breakdown of the various categories of data and the particular data held in respective fields within the database. Thus in this depiction the EDI compatible name, address and contact person is stored under the supplier category; the known sources that trade with the source are listed namely, Does Retail Store (reference link) and associated name; (or My Retail Store (reference link) and associated name); address for invoice to, address for delivery, trading terms, contact person (name, address, phone number, email); and a list of products namely, baseballs, baseball mitts, baseball bats, baseball caps, baseball jackets, miscellaneous and for each product the following data; product name, product SKU ID code, unique product bar code, unit of measure and a price matrix or array; EDI format of orders expected by this supplier; EDI format of invoices provided by this supplier, and other information about each WO 2016/000020 PCT/AU2015/000377 38 product, etc. A copy of all data or relevant data within the recipient/suppliers database is made available to the system 200 in the manner/s described previously.

[142] Figure 10 depicts an example database within the system 200 illustrating in particular known sources for example, AAA Mega Sports Store, Bruno's Hair Salon, The Coffee Place, Does Retail Store, My Retail Store, etc. and there may be other information relating to those entities, such as for example, address for correspondence, address for delivery, delivery requirements, address for invoices, payment terms, etc. Such a database is used in the many-to-many or the many-to-one arrangements described previously and illustrates that there will be a large amount of data to be received and managed with the system 200 to service those arrangements.

[143] Figure 11 depicts an example database illustrating in particular known suppliers for example, Baseball Supplies Co., Canoe Suppliers Co., Football Supplies Co., Hair care & Beauty Supplies co., Coffee Supplies Co., ABC Sports Supplies Co. etc. Such a database is used in the many-to-many or the one-to-many arrangements described previously and illustrates that there will be a large amount of data to be received and managed with the system 200 to service those arrangements.

[144] Figure 12 depicts a flow of the documents/files involved in the compliance step 208 following the receive step 207. As described previously the memory of the system 200 contains all the now transformed and associated data. In an embodiment, the format descriptor 1210 of an EDI order as expected by a supplier, ABC Sports Supplies Co. for example, is stored in the associated database (Figure 9) and that format descriptor is used to create an EDI packet 1220. The step of creating from the associated information and received information an Electronic Data Interchange compliant order is a program controlled step and the information included in the EDI compliant order includes at least the known source, the known supplier, the unique such as bar code of a product and an associated order quantity of the product. In the embodiment there will be multiples of this information for multiple product in the order and additional information, such as for example, color of the product if the unique bar code does not specify that characteristic; the names and addresses for various contact persons at the source and supplier; product SKU ID codes; terms of payment details; etc. where each of the data is EDI compliant. The actual format of the EDI packet WO 2016/000020 PCT/AU2015/000377 39 1220 is a matter of the EDI specification used by the supplier and an example of the makeup of such a packet is depicted in Figure 12. When the supplier has an electronic order receiving requirement which needs to be complied with the same steps as above are performed except that the format requirements will be different to that of an EDI compliant order.

[145] Note that although an order has been used as an example in the foregoing description the same process will apply to other types of business transactions and respective text based sets of data that make up the file/document involved.

[146] Figure 13 depicts a pictorial representation of the making available step 209 which follows the compliance step 208 an example of which is depicted in Figure 12. In this representation the EDI packet representing an EDI compatible order is available on the server memory of the system 200 and depending on the EDI protocols used, the packet can be made available on the basis of a poll from the supplier's server 1310, or as it is typical, the system 200 issues the EDI packet into an EDI VAN that will communicate the order to the supplier's EDI server 1310. The making available step is still effective if the compliant set of data is transmitted via a VAN, which is in some ways no different to using the Internet to communicate a digital file from the system 200 to a recipient data receiving system. In any event the EDI compatible order is made available for further processing within the systems available. Figure 8 also depicts this embodiment but also others, for example, the EDI compatible order is arranged to be communicated in an email, or as a file via FTP, or served from a web page accessed by a Supplier. There are numerous other mechanisms for communicating the EDI compatible order as long as the EDI compatibility is preserved. As described elsewhere the format of the order may not be EDI compliant but will be compliant with the recipient data receiving system of the supplier in which case one of the alternative delivery mechanisms depicted in Figure 8 will be useable of another which is not illustrated but still effective for this purpose.

[147] Figure 14 depicts a flow chart of the generation of an invoice.

[148] By way of example, sources of invoices such as a wholesaler, raw materials supplier, service company 1410 that provides services to others, provide their invoice 140, as depicted in Figure 14 typically from their own system in a format that has been intended to provide an invoice WO 2016/000020 PCT/AU2015/000377 40 for use by the receiver of the invoice such as a goods manufacturer or goods supplier 1420 to retail outlets. The invoice 140 supposedly includes all the information the supplier will need to pay the original invoice. It is usual for the invoice 140 to be received via email (in the body or as an attachment of the type (Portable Document Format (PDF); Excel format (.csv file type); Text in a Word document (.doc or .docx file type)); or via facsimile requiring manual input of the information into the goods supplier's system 1420'. Since these orders are not in a format acceptable to the suppliers EDI system, manual input is typically required although there may be some systems which can transfer, say the fields in a .csv file, to the fields in a larger system before the invoice can be acted on by the supplier using the then EDI form of the invoice.

[149] Clearly, very similar issues arise with regards the veracity and accuracy of the received non-EDI compatible invoices, as happens with non-EDI compatible orders as described in detail above. Thus it is possible for the invoice 140 to be received by a system 200 (Figure 2) to perform the steps described in detail previously, with appropriate adjustment for the nature of the transaction the source of the transaction and the eventual receiver of the information and representative text associated with the transaction, such as it is in this example, an invoice. Thus where the term "order" is used in the above described embodiments the term "invoice" can be substituted but the more complicated aspects of the adjustment arise where the incoming goods and services will relate to a different set of goods to those described previously, such as for example, the term "leather" will be the product, there may not be a unique bar code for a raw material such as leather, but there can be a unique identifying code none-the-less.

[150] Similarly, there will be buyers that are EDI compliant and although they are able to use EDI document exchange with EDI compliant suppliers of the goods they retail, there will be some suppliers of goods to them that are not EDI compliant and not able to issue EDI compliant invoices for the particular goods that they supply. The system described will enable the non-EDI supplier to provide the invoice to the system 200 described, for processing so as to make available an EDI compatible invoice to the EDI compliant buyer.

[151] Until all buyers and all suppliers have EDI compatibility there will be a need to process non-EDI invoices (and orders) in to EDI compliant equivalents. However, as also explained the WO 2016/000020 PCT/AU2015/000377 41 system and processes performed by the system 200 are also applicable to the situation where the invoice is provided in a format which is not compatible with the recipient data receiving system of the receiving entity and the ability to transform and establish the veracity of the text based set of data associated with the transaction is the great advantage provided by the system and the process described herein.

[152] The reference to any prior art in this specification is not, and should not be taken as, an acknowledgement of any form of suggestion that such prior art forms part of the common general knowledge.

[153] It will be understood that the term "comprise" and any of its derivatives (e.g. comprises, comprising) as used in this specification is to be taken to be inclusive of features to which it refers, and is not meant to exclude the presence of any additional features unless otherwise stated or implied.

Claims

1. A method for receiving a text based set of data generated by a source being data specific to a type of business transaction for being handled and made available to a recipient data receiving system having recipient data associated with respective fields and adapted to have text based data in a predetermined format according to the type of business transaction made available to the recipient data receiving system, the method comprising the steps of: a) receiving the text based set of data associated with a source, intended recipient data receiving system and type of business transaction; b) using a template determined by the source and type of business transaction, to associate one or more of the received text based set of data with one or more field of data used by the receiving system; c) determining discrepancy between the received text based set of data and the recipient data for a respective field, where the type of business transaction determines the one or more fields to be checked for a discrepancy; d) presenting one or more field and respective data for visual inspection including at least those fields having a discrepancy; e) receiving an acceptance or correction of the data for an inspected field having a discrepancy; f) making a set of data and associated fields including accepted or corrected data compliant for processing the type of business transaction by the data receiving system; and g) making the compliant set of data available to the recipient data receiving system.

2. A method according to claim 1 for receiving text based sets of data generated by two or more sources each set of data from a respective source being data specific to a type of business transaction for being handled and made available to an intended recipient data receiving system having recipient data associated with respective fields and adapted to have text based data in a predetermined format according to the type of business transaction made available to the recipient data receiving system, the method comprising the further step aa) performed prior to step a): aa) receiving text based set of data and associating the text based set of data with one of the two of more sources.

3. A method according to claim 1 for receiving text based sets of data generated by two or more sources each set of data from a respective source being data specific to a type of business transaction for being handled and made available to a predetermined one of two or more recipient data receiving systems, each recipient data receiving system having recipient data associated with respective fields and adapted to have text based data in a predetermined format according to the type of business transaction made available to the respective recipient data receiving system, the method comprising the further step aa) performed prior to step a): aa) receiving text based set of data and associating the received text based set of data with one of the two of more sources and a predetermined one of the recipient data receiving systems.

4. The method of claims 1, 2 or 3 wherein the text based set of data received from a source is in Portable Document Format.

5. The method of claim 1, 2 or 3 wherein the type of business transaction is an order for the supply of goods or services to be provided by a receiver to a source.

6. The method of claim 1, 2 or 3 wherein the type of transaction is an invoice for the supply of goods or services provided by a source to a receiver.

7. The method of claim 1, 2 or 3 wherein the method step f) includes making the data set compliant for an Electronic Data Interchange with the recipient data receiving system.

8. The method of claim 7 wherein step g) uses an Electronic Data Interchange Value Added Network to make the compliant set of data available to the recipient data receiving system.

9. A method for receiving a set of data including data specific to a type of business transaction generated by the source as an image of the set of data and a text based indication of the source and recipient and made available to a recipient data receiving system having recipient data associated with respective fields and adapted to have text based data in a predetermined format according to the type of business transaction made available to the recipient data receiving system, the method comprising the steps of: a) receiving the image based set of data associated with a source, intended recipient data receiving system and type of business transaction; b) applying optical character recognition to at least a portion of the received image of the set of data to transform at least a part of the received image into a received text based set of data; c) using a template determined by the source and type of business transaction, to associate one or more of the received text based set of data with one or more field of data used by the receiving system; d) determining discrepancy between the received text based set of data and the recipient data for a respective field, where the type of business transaction determines the one or more fields to be checked for a discrepancy; e) presenting one or more field and respective data for visual inspection including at least those fields having a discrepancy; f) receiving an acceptance or correction of the data for an inspected field having a discrepancy; g) making a set of data and associated fields including accepted or corrected data compliant for processing the type of business transaction by the recipient data receiving system; and h) making the compliant data set available to the recipient data receiving system.

10. A method according to claim 9 for receiving a set of data including data specific to a type of business transaction generated by two or more sources, each as an image of the set of data from a respective source and a text based indication of the respective source and being handled and made available to an intended recipient data receiving system having recipient data associated with respective fields and adapted to have text based data in a predetermined format according to the type of business transaction made available to the recipient data receiving system, the method comprising the further step aa) performed prior to step a): aa) receiving text based set of data and associating the text based set of data with one of the two of more sources.

11. A method according to claim 9 for receiving a set of data including data specific to a type of business transaction generated by two or more sources, each as an image of the set of data from a respective source and a text based indication of the respective source and being handled and and made available to a predetermined one of two or more recipient data receiving systems, each recipient data receiving system having recipient data associated with respective fields and adapted to have text based data in a predetermined format according to the type of business transaction made available to the respective recipient data receiving system, the method comprising the further step aa) performed prior to step a): aa) receiving text based set of data and associating the received text based set of data with one of the two of more sources and a predetermined one of the recipient data receiving systems.

12. The method of claim 9, 10 or 11 wherein the type of business transaction is an order for the supply of goods or services provided by a source to a receiver.

14. The method of claim 9, 10 or 11 wherein the type of transaction is an invoice for the supply of goods or services provided by a source to a receiver.

15. The method of claim 9, 10 or 11 wherein the method step f) includes making the data set compliant for an Electronic Data Interchange with the data receiving system.

16. The method of claim 15 wherein step g) uses an Electronic Data Interchange Value Added Network to make the compliant set of data available to the recipient data receiving system.

17. A method for receiving a set of data including data specific to a type of business transaction generated by the source as an image of the set of data and a text based indication of the source and recipient and made available to a recipient data receiving system having recipient data associated with respective fields and adapted to have text based data in a predetermined format according to the type of business transaction made available to the recipient data receiving system, the method comprising the steps of: a) receiving the image of the set of data associated with a source, intended recipient data receiving system and type of business transaction; b) displaying a single line of text of the image; c) using a template determined by the source and type of business transaction, to associate one or more data displayed in the single line of the image with a field of data; d) receiving input representative of the data associated with the field of data; e) repeating steps b) and c) until predetermined types of fields are associated with respective input data to create a set of received input data; f) determining discrepancy between the received text based set of data and the recipient data for a respective field, where the type of business transaction determines the one or more fields to be checked for a discrepancy; g) presenting one or more field and respective data for visual inspection including at least those fields having a discrepancy; h) receiving an acceptance or correction of the data for an inspected field having a discrepancy; i) making a set of data and associated fields including accepted or corrected data compliant for processing the type of business transaction by the recipient data receiving system; and j) making the compliant set of data available to the recipient data receiving system.

18. A method for receiving, handling and making available a text based set of data generated by a source being specific to a type of business transaction from voice responses on behalf of the source to a predetermined set of questions and generation for being made available to a recipient data receiving system having recipient data associated with respective fields and adapted to have text based data in a predetermined format according to the type of business transaction made available to the recipient data receiving system, the method comprising the steps of: a) applying a voice to text recognition mechanism to at least a portion of the received voice responses into a text based set of data; b) using a template determined by the source and type of business transaction, to associate one or more data with one or more field of data; c) determining discrepancy between the received text based set of data and the recipient data for a respective field, where the type of business transaction determines the one or more fields to be checked for a discrepancy; d) presenting one or more field and respective data for visual inspection including at least those fields having a discrepancy; e) receiving an acceptance or correction of the data for an inspected field having a discrepancy; f) making a set of data and associated fields including accepted or corrected data compliant for processing the type of business transaction by the recipient data receiving system; and g) making the compliant set of data available to the recipient data receiving system.