ITTV20100122A1 - METHOD AND SYSTEM FOR CONVERTING DIGITAL DOCUMENTS - Google Patents

Description

TITLE: METHOD AND SYSTEM FOR CONVERTING DIGITAL DOCUMENTS

DESCRIPTION

Systems for converting digital documents, such as e.g. US6397232. In these systems there is the problem that it is not possible to convert digital documents that have different formats in cases where eg. the format of the file to be converted is not known in advance, or when the file extension, which denotes the format, is wrong, non-existent or invented by a user or non-standard.

The user cannot rely on custom formats, because the available format translation systems only work between standard formats. If a user wants to convert files written with his own format into files of different formats, he has to invent the converter. And sometimes, even if you want, it is not possible, because the target format is owned by another person, who does not want to disclose confidential information.

The main purpose of the invention is to provide a new method and an electronic system for converting documents into digital format.

Other purposes are to solve all or some of the above problems, and to have a user

- must not use a communication standard or format imposed to send or receive;

- can use his own format or even invent one for transmission and reception without worrying about those used by other users with whom he exchanges documents;

- can use any means of transport / reception at will to deliver / receive documents without worrying about the transport / reception system used by the recipient.

The objects are achieved with a method defined in claim 1, i.e. a method performed in / by a data processing device to convert a digital document into another digital document with different formatting and possibly also format, comprising

- access a file to be converted including a document body to be converted,

- read fields that identify at least a First User and a Document Type;

- by indexing at least with the First User and Document Type fields, identify or select or search for a first procedure associated with the Document Type of the First User,

- perform the first procedure, which having formatting information to locate data in the document body such as eg. string or numeric fields, extracts localized data from the document body.

It is characteristic of the invention to be able to extract the data from the file to be converted through a mapping procedure and a specific map file for the user. This allows him and the processing system to disregard any standard format and formatting, and / or any format and formatting used internally only by the user.

In the text, the word 'formatting' of files indicates the standardization of information in a certain format and their arrangement, as is generally understood. The word 'file format' here indicates the convention that is used to read, write and interpret or represent the contents of a file. The format of a certain file is eg. commonly referred to by the extension. Examples of formats are an ASCII-type fiat file or an EXCEL file, a representation of a class in XML format, and so on.

In this text, 'indexing' has a broad meaning, and includes all the logical and / or algorithmic systems to find, through the indexing fields, the procedures to be performed specific to a user's file. Eg. you can search for a procedure among those of a database stored individually in a Hard Disk, a ROM or a permanent medium such as a Compact Disk or DVD. Or the procedure can be identified and selected (in systems with Windows® OS) in a dedicated DLL file that contains a series of them, in an .EXE or .COM file. The procedure is selected (and then executed) by program indexing, eg. through sequences of IF-THEN or CASE, SWITCH instructions.

The method can be performed in a data processing device e.g. as a dedicated program in a microprocessor, or from a processing device eg. a normal computer or server loaded with specific software.

The data extracted from the file to be converted can be exploited in all the known processing methods. In particular they can be transmitted eg. to a Second User. To do this, and also to favor the scalability of the system and reduce the size of the user archives, the method can provide that

- a field identifying a Second User is read from the file to be converted, - the localized data is extracted and grouped into a whole,

- an intermediate file is generated with the data contained in the set;

- at least the Second User and Document Type fields are associated with the intermediate file, e

- the intermediate file is transferred to another user system.

The intermediate file contains the data, which the sending user wants to send, in a single format, easily manageable by the system and regardless of the format and formatting used in the file to be converted and in the arrival file. Since the data to be transferred count for transmissions and not how they are presented or sorted, it is understood that the intermediate file can be processed in many ways while still containing the core of information to be transferred. In particular, the intermediate file can be used as a matrix or data source to generate another file or document with a specific formatting and / or format, standard or not. This other document can be received by a recipient user in their preferred formatting and format, regardless of those of the source document. To this end, the method includes

- optionally identify a Format of the document body by reading a related field of the file to be converted or deducing it from the Document Type field, - identify or select or search for a second procedure associated with the Document Type of a Second User by indexing at least with the Second User and Type fields Document extracted from the file to be converted or from the intermediate file,

- carry out the second procedure, which

has the Format information of the Second User,

is capable of generating a document body in its format, and

has formatting information associated with the Second User's Document Type, ed

is capable of inserting the data extracted from the file to be converted or from the intermediate file into the generated document body, building it with the formatting associated with the Document Type of the Second User.

The step of identifying a Document Body Format is optional because the system can be mono-format but with many Document Types.

The second procedure is conceptually similar to the first one, ie it is used to map data between files and / or memory areas. The destination file is the file to be sent to the Second User, while in one case the data is taken from the intermediate file, in another case directly from the set of data extracted from the file to be converted. The result is always that the Second User receives the data formatted according to his preference.

Other variants of the method are contained in the dependent claims, e.g.

- the first and / or second procedure is searched in a database of procedures, by means of indexing. This allows users to be sorted with their desired formatting, to transfer entire user databases between system modules, and to efficiently manage insertions, deletions or changes by users (if the databases are accessible to them) or by users, by system administrators;

- the file to be converted is received by a first remote user and the converted file is sent to a second remote user. The system can operate as a central node and serve remote users, eg. via a well-known data network. Thus each user can send messages to others using their own standards regardless of those of others;

- the first and / or second procedure is transferred and / or stored in the relative database by the users to whom the procedures are associated. This allows maximum system customization, and independence from the formatting and format of each system user;

- to make it easier for users to insert formatting mapping procedures, an interface is set up with which a user can build a mapping to map the formatting of his document body, the mapping by specifying the position and / or coordinates of and / or a pointer to one or more data contained in the document body, and / or sending in said database a map-file containing the mapping generated by the user so that it can be used by or with said first and / or second procedure. The interface can also allow you to map a user document body by associating a map file that is a predefined template and contained in a template database to that document body. The use of templates simplifies and speeds up the insertion of a mapping;

- the file received, or converted, is received, or sent, through a means of transfer selected among many from a field present in the file. Each user can thus select, directly eg. in the message, which transmission medium to use for the routing / sending and delivery of the message;

- the use of the conversion service is granted after validating the user's identity. In addition to ensuring the security of transmissions, access to the system can thus be verified and monitored, possibly offering it for a fee or as a resource limited by access criteria;

- the file to be converted and / or the converted file and / or the intermediate file is saved in a database, and the database can be consulted remotely by a user. This allows the traceability of messages and the recovery of their contents.

For a purely multi-user system, a method of the invention is performed in / by a data processing device to convert a digital document into another digital document with different formatting and possibly also format, and includes

- access a file including a document body to be converted and fields that identify at least a First User, a Second User and a Document Type;

- identify or select or search in a database (90) of procedures, by indexing at least with the First User and Document Type fields, a first procedure associated with the Document Type of the First User and execute it, the first procedure having formatting information to locate in the document body of the data such as eg. string or numeric fields, and being able to extract localized data from the document body;

- identify or select or search in a database of procedures (90), by indexing at least with the Second User and Document Type fields, a second procedure associated with the Document Type of the Second User and execute it, the second procedure being able to generate a document body and, having formatting information associated with the Second User's Document Type, being able to insert said extracted data into the generated document body by constructing it with the formatting associated with the Second User's Document Type.

The method is advantageously implemented by a data processing system suitable for converting a digital document into another digital document with different formatting and possibly also format, comprising

- means (eg a motherboard that reads a Hard Disk) to access a file comprising a document body to be converted and fields that identify at least a First User, a Second User and a Document Type;

- a database of specific data mapping procedures for each User and uniquely associated with his Document Type,

- means (e.g. a programmed microprocessor) to identify or select or search in the database, by indexing at least with the First User and Document Type fields, a procedure associated with the Document Type of the First User and execute it, the first procedure having available information formatting to locate data in the document body such as string or numeric fields, and being able to extract localized data from the document body;

- means to identify or select or search in the database, by indexing at least with the Second User and Document Type fields, a second procedure associated with the Document Type of the Second User and execute it, the second procedure being able to generate a document body and, having formatting information associated with the Document Type of the Second User, being able to insert said extracted data into the generated document body by constructing it with the formatting associated with the Type of the Second User.

Procedures can be stored in different databases or in a single one. Databases can be created eg. through procedure archives on a Hard Disk, or integrated in a program that selects / finds from time to time an internal procedure from a list or together through eg. conditioned jumps.

Advantageously, the system comprises means (for example a program) for generating an intermediate file containing said localized and extracted data, with the advantages already listed for the method.

In preferred variants the system includes:

- means (to allow users to) transfer and / or store mapping procedures in the relevant database, such as eg. a remote computer or terminal connected to the network. In particular, there may be an interface with which a user can build a mapping to map the formatting of his document body, the mapping by specifying the position and / or coordinates of and / or a pointer to one or more data contained in the body. document. The interface can be eg. software (a GUI program) or a dedicated terminal with keyboard and video;

- the interface may have means to map a user document body that associate a map file that is a predefined template and contained in a template database to that document body;

- means to send a map file containing the generated mapping to said databases, through which the user can upload the procedure to the system;

- a database of predefined mapping procedure templates associated with standard documents.

Other advantages of the invention will be clearer from the following description of a preferred embodiment, together with the attached drawings where

Fig. 1 shows a block diagram of a system according to the invention;

Fig. 2 shows a file structure and logical conversion path for the system of Fig. 1.

See fig. 1 for the block representation and the logical form of a system 100 according to the invention. A digital message 10 is received from a remote sending user U1 (e.g. a computer), and a digital message 20 is outgoing to another remote recipient user U2 (e.g. another computer). The message 10 (see fig. 2) is composed of one or more files (for example an ASCII file and a PDF file), which form a document body Bl, and an optional header HI comprising the information of the sender Ul, the recipient U2 and other ancillary properties such as the Document type or others defined by the user Ul. The data in the header H can be included directly in the document body Bl: in this case no further data or files external to the body Bl would be required nor the HI header. Message 20 can have the same logical structure as message 10. The U2 user can specify whether he wants an H2 header and the data fields it contains. If the data is all inside the document body received by the U2 user, very often an H2 header is not needed.

Optionally, the message 10 can be compressed, by means of software present on the remote computer, to make the transport lighter, or preferably also encrypted.

The types of documents in transit in the system 100 can be industrial or commercial documents such as bills, invoices, orders, and accessory files such as PDFs, images, or cards that accompany the document, but which are not necessary for its correct interpretation.

It is assumed here that message 10 has a formatting and possibly also a format other than that required by the recipient user U2, and that therefore message 20 has been converted by system 100 into the format used by user U2. Mainly, therefore, the diversity of formatting in messages 10, 20 counts.

The messages reach and depart from the system 100 through connector modules, generically indicated with 30. They are executable or web pages or software processes or physical means that allow the user to insert or receive files. Among the various possible connectors, there may be

- e-mail services, scalable by installing them on separate servers that monitor specific e-mail addresses. The connectors 30 are configured to monitor some addresses, select only the e-mails that come from a given address to avoid spam; and they can also host an SMTP server and create mailboxes dedicated to users;

- FTP services, which can be scalable by installing them on separate servers that monitor specific FTP addresses; read and write on remote FTP Servers and / or host a local FTP Server;

- Fax;

- SMS, a service that can be scaled by installing it on separate servers that monitor specific telephone numbers.

The main task of the input connector modules 30 is to receive a message 10 and save it within an input database 40, where for example can be managed by user U1 through a Web portal 32. User U1 can eg. download a sent message, view the list of messages sent or not yet sent, received, or delete some of them.

Similarly, the main task of the output connector modules 30 is to take a converted message 20 from an output database 60 and send it to the user U2, eg. via e-mail, web services, fax, SMS or FTP.

Each connector module 30 is preferable to be a separate service to which databases 40, 60 are visible; in this way each service can be delocalized on various dedicated machines. Eg. through a Web portal 32 the U2 user can automatically download a message 20 intended for him, view the list of messages to be sent to him and not yet sent, delete some or re-send or re-download them (without having to generate them again).

The heart of the system 100 is a logical architecture 110 that allows it to convert the formatting, and possibly also the formats, of messages 10, 20 with efficiency and maximum scalability. As an implementation, a server is preferably used on which appropriate software runs.

In the following, modules and procedures generally refer to software processes or programs or routines, preferably specialized in a function. Such software processes or programs run on one or more microprocessors and associated hardware devices, such as RAM or ROM memories (known and not shown), of the Server 110.

A control module 70 scans the database 40 checking for the presence of new messages 10 received. When it detects one, it activates a designated selector module 80 associated with a sender or recipient, indicated in the header of message 10, to carry out any translation of formatting and, if necessary, format.

In particular, the task of the module 70 is to obtain from the module 30 the list of completely received messages, and to instantiate a selector module 80 to process each message. The selector 80 receives as a command string Γ the unique identifier of a received message, and analyzes it to see if the associated files must be translated or not.

In addition, module 70 checks that modules 80 (a different one for each document format, regardless of the user, eg. EXCEL, PDF, TXT, etc.) do not take too long to perform their task.

The selector module 80 has the task of identifying the formatting to be used (and the digital format). Module 80 does not need to know which recipient U2 receives the document, since it is only responsible for translating into a target formatting, which can be eg. an intermediate format, v. beyond, or that of user U2. Module 80 then activates a formatting (and format) conversion procedure to which it sends the information and the body of the document to be converted. The Recipients and Document Type fields are read from the Bi body or the HI header and then passed to the selector module 80 and the conversion procedure uniquely associated with it. The data relating to user U2 preferences (Type and Format of Document and Means of Transport) are searched and found in a database. The sender U1 does not know how the recipient wants to receive. He may know this implicitly when faxing or texting, because he has to enter the phone number. The converted message is then saved in the database 60. From the database 60 a message 20 to be sent will be picked up by a transmission / reception module 30, which periodically scans the messages on the database 60, and sent to the correct user U2.

Having described the general architecture of the system 100 and of the server 110, we move on to expose the peculiar logi co-hard ware structure that allows not only the translation of formatting (and format) but also the convenience for each of the users Ul, U2 to send and receive documents with their own format, formatting and means of communication without worrying about the format, formatting and medium used by the other. See also fig. 2.

For each file contained in the received document body B1 the conversion procedure or service extracts, eg. from the HI header, the following:

- a U2 recipient field,

- a sender field Ul, e

- the FI format of the file used in the B1 document of the sender Ul (eg PDF or TXT), e

- the TI Document Type received (eg a type of document "invoice" or "bill" or "order").

The FI format can be an independent field or be a datum associated with the Document Type Tl.

Then it searches a database or table 90 for a mapping procedure by indexing the search with

- the sender field Ul, e

- the type of document received Tl,

- and possibly also the FI format.

In fact, a unique association with a Tl format of the user Ul may suffice, in which case the Document Type also defines the format.

The mapping procedure found in the database 90 comprises a map-file or a database that contains the information / instructions / coordinates that locate and identify within a document body file B1 the data, their formatting and position, and is either it can be used to activate or serve a data extraction / injection function from and into a file. The map-file eg. relative to an EXCEL file or a TXT file contains eg. the row-column coordinates.

By means of the map file relating to the sender Ul, the mapping procedure can extract from the received file (the document body Bl) the data which must participate in the formatting (and format) translation. Using a map file relating to the U2 recipient, the data extracted from the received file can be inserted into the converted file.

Called MP1 the mapping procedure or function with associated map-file, we can write MP1 = f (Ul, Tl) or MP1 = f (Ul, FI, Tl), with f (.) Generic search function in a database of mapping procedures, and associated map files, relating to users.

Then, with the execution of the MP1 mapping procedure, an intermediate UDX file or metafile is generated containing all the data that user U1 wishes to transmit to user U2, contained in the document body Bl. That is, UDX = MP1 (Bl). That is, the mapping procedure MP1 to the document body Bl is applied (by launching or passing it, for example, a handle to Bl).

The UDX file is either processed in real time or can be sent eg. on a remote server closest to user U2. In any case it is recovered from a database, eg. the same database 90, a second mapping procedure MP2 with the associated file-map for user U2 relating to the same Document Type TI sent by user Ul. In expression, we have MP2 = g (U2, Tl), with g (.) generic search function in a database of mapping procedures, and associated map files, relating to users.

The format of the file desired by the user U2 for the Tl type can be eg. information contained within the (univocal) mapping procedure for that Tl type.

Note that transferring the UDX file allows to contain the database size 90: only the users it serves can be stored on each single machine. In other words, function f (.) Will search (in the example) only among sending users Ul while function g (.) Among recipient users U2.

The procedure with the MP2 file-map is used to generate a converted B2 document body for user U2, simply by executing B2 = MP2 (UDX). That is, the mapping procedure sequentially reads the data in the UDX file and formats it into a file according to the instructions / information read in the MP2 file.

Eg. the two users U1, U2 will insert in the system 100 two of their own mapping procedures and relative map-files of an invoice, respectively MP1 and MP2. Ul uses PDF format and U2 EXCEL format. Let's imagine that the user who uses PDF sends is sent. System 100 receives the PDF, extracts sensitive data from it thanks to the MP1 mapping procedure and builds an EXCEL file by inserting the extracted data in the positions indicated by the MP2 mapping procedure. For the user who receives the EXCEL file, it is as if the sender had written it natively like this, and in the format and formatting of the recipient.

The map-files associated with a mapping procedure can be either (i) an integral part of the procedure, e.g. as DDL files, or separate and uniquely selected databases, or databases integrated into the body of the procedure but always created as compact data collections, or (ii) encoded in the program itself that makes up the procedure, eg. coding them in the instructions to be executed.

The system of the invention has the great advantage of being indifferent to the user's Document Type. A user can create as many types of documents as he wants. For each user the definition eg. of "Invoice Document Type" it becomes the identifier of a specific class of documents, which is used to recognize the Document Types to be converted. There is not necessarily only one Document Type for each user, although one is typically enough.

Each member of a Document Type class, eg. the "Invoice Document" class, is characterized eg. from a conversion / mapping procedure having univocally associated a file-map, a format field and a field to define which means of transport to use to transfer the document.

Eg. the U2 user could define an Invoice 1 Document Type, an Invoice 2 Document Type, an Invoice 3 Document Type, etc., all belonging to the "Invoice Document Type" class. So the user U2 eg. can receive in the three Document Types the same invoice sent by U1 with its Document Type. It is sufficient for the system, or the user, to store in the databases 90 three different mapping procedures (and the map-files) for the three different Document Types of the U2 recipient.

The logical system 110, in sum, for each document arriving from a sending user to be sent to a recipient:

- determines, among all the Document Type classes defined for that sending user, the Document Type class to which the document belongs;

- for the identified class, select a specific procedure or function for that Document Type received, which allows, thanks to a mapping, to extract the user-defined data to be converted from the received document;

- select a corresponding second procedure or function of the same class but this time relating to the recipient user; And

- performs a formatting conversion - and if needed a format - by launching the second procedure, which describes the formatting rules for that Document Type of that recipient user. These rules are used to build a file for the recipient by taking the data extracted from the incoming document.

If the fields U2, Ul, FI and TI are not in a header HI, but within the main document body Bl, it is sufficient to define their position within the document body Bl by mapping. Thus the system is informed that those are the fields that also identify the transmission. In practice, the header HI is incorporated into the body Bl, and the same thing can be done for the file to be transmitted to user U2.

It should be noted that using mapping procedures indexed by fields contained in the messages in transit is convenient because it easily allows the system 110 to add or remove users, simply by updating the relative databases. However, the procedures can eg. be indexed within a single management program through conditional instructions, such as IF-THEN or SWITCH.

As you can see, the connector modules are generic (FTP e-mail, web Service, etc.) and only deal with receiving and sending files, there are not one for each user, even the selector modules are generic and take care of recognize and read / write the document format (PDF, EXCEL, txt, etc.). Only the translator modules are characterized by the user-mapping present in the database.

There are other ways to perform the functions of the system 110, e.g. without using connector modules and / or using other software structures or algorithms.

It is possible to create and install 110 plug-in applications in the system, dedicated to specific formatting translations and inserted in place of the translation automatisms. Eg. in cases where the documents to be translated are too complex or where there are calculations with particular algorithms or logic, you can create an application that is installed as a plug-in and that will translate the document (s) from a Type and Format to another. In this case the selector module recognizes that it must execute the plug-in, and instead of starting the translation it starts the plug-in that will do the translation, following peculiar calculation logics.

The UDX file does not have to be created. It can only be a decomposition of the document body B1 in memory, necessary for the time it takes to call the procedure or mapping routine that reassembles the converted file.

It has been said that message 10 contains in the header HI at least the information of the sender Ul, to which a Document Type is associated. These fields can also be transferred in other forms, e.g. with a document-identification TAG that must be specified in some way, eg.

- in the subject of the message 10 if it arrives by e-mail;

- in body B 1;

- with the name of the file (s) attached or contained in the body B1, which creates an association between the file name and the Document Type, which also corresponds to a certain format;

- in one or more fields among those contained in the file to be sent.

The sender user Ul field can also be identified eg with your username and password in the case of transport via Web services, with the e-mail address in the case of transport via e-mail, with the name of a folder (folder) in the case of transport via FTP, or with fax number or ID of the sending fax.

System 110 can have conditional access. Eg. each user U1, U2 is recognized by the system 110 (also) through the sender / recipient field. Only if it provides valid credentials for access, such as a valid account given by login and password received with the subscription to the service, can operate in the system 100 by circulating or retrieving messages.

Claims (10)

TITLE: METHOD AND SYSTEM FOR CONVERTING DIGITAL DOCUMENTS CLAIMS A method performed in / by a data processing device (110) for converting a digital document (10) into another digital document (20) with different formatting and optionally also format, comprising - access a file to be converted (10) including a document body (Bl) to be converted, - read fields (Ul, U2, Tl) which identify at least a First User and a Document Type; - by indexing at least with the First User and Document Type fields, identify or select or search for a first procedure associated with the Document Type of the First User, - perform the first procedure, which having formatting information to locate data in the document body such as eg. string or numeric fields, extracts localized data from the document body. Method according to claim 1, wherein - a field (U2) that identifies a Second User is read from the file to be converted, - localized data is extracted and grouped into a whole, - an intermediate file is generated with the data contained in the whole; - at least the Second User and Document Type fields are associated with the intermediate file, e - the intermediate file is transferred to another user system. Method according to claim 1 or 2, comprising - optionally identify a Format (FI) of the document body by reading a relative field of the file to be converted or deducing it from the Document Type field, - identify or select or search for a second procedure associated with the Document Type of a Second User by indexing at least with the Second fields User and Document Type extracted from the file to convert or from the intermediate file, - carry out the second procedure, which has the Format information of the Second User, is capable of generating a document body in its format, and has formatting information associated with the Second User's Document Type, ed is able to insert the data extracted from the file to be converted or from the intermediate file into the generated document body, building it with the formatting associated with the Document Type of the Second User. Method according to one of the preceding claims, in which the first and / or second procedure is searched in a database of procedures (90), by means of indexing. Method according to claim 4, in which the first and / or second procedure is transferred and / or stored in the relative database by the users themselves with whom the procedures are associated. 6. Method according to one of the preceding claims, in which an interface is prepared with which a user can - build a mapping to map the formatting of your document body, the mapping by specifying the position and / or coordinates of and / or a pointer to one or more data contained in the document body, and / or - sending in said database a map-file containing the mapping generated by a user so that it can be used by or with said first and / or second procedure. Method according to claim 6, wherein the interface allows mapping a document body of a user by associating to that document body a map file which is a predefined template and contained in a template database. 8. Method performed in a data processing device (110) for converting a digital document (10) into another digital document (20) with different formatting and optionally also format, comprising - access a file (10) comprising a document body (Bl) to be converted and fields (U1, U2, Tl) which identify at least a First User, a Second User and a Document Type; - identify or select or search in a database (90) of procedures, by indexing at least with the First User and Document Type fields, a first procedure associated with the Document Type of the First User and execute it, the first procedure having formatting information to locate in the document body of the data such as eg. string or numeric fields, and being able to extract localized data from the document body; - identify or select or search in a database of procedures (90), by indexing at least with the Second User and Document Type fields, a second procedure associated with the Document Type of the Second User and execute it, the second procedure being able to generate a document body and, having formatting information associated with the Second User's Document Type, being able to insert said extracted data into the generated document body by constructing it with the formatting associated with the Second User's Document Type. 9. Data processing system (110) suitable for converting a digital document (10) into another digital document (20) with different formatting and possibly also format, comprising - means for accessing a file (10) comprising a document body (Bl) to be converted and fields (U1, U2, Tl) which identify at least a First User, a Second User and a Document Type; - a database (90) of specific data mapping procedures for each User and uniquely associated with his Document Type, - means to identify or select or search in the database (90), by indexing at least with the First User and Document Type fields, a procedure associated with the Document Type of the First User and execute it, the first procedure having formatting information to locate in the body data document such as string or numeric fields, and being able to extract localized data from the document body; - means to identify or select or search in a database (90), by indexing at least with the Second User and Document Type fields, a second procedure associated with the Document Type of the Second User and execute it, the second procedure being able to generate a document body and, having formatting information associated with the Second User's Document Type, being able to insert said extracted data into the generated document body by constructing it with the formatting associated with the Second User's Type. 10. A system according to claim 9, comprising means for generating an intermediate file containing said localized and extracted data.