ITMI20111734A1 - SYSTEM FOR MANAGING THE EXCHANGE OF DOCUMENTS BETWEEN CUSTOMER AND SUPPLIER FOR THE EFFICIENT MANAGEMENT OF THE PROCUREMENT WORKFLOW. - Google Patents

Description

SYSTEM FOR THE MANAGEMENT OF THE EXCHANGE OF DOCUMENTS BETWEEN CUSTOMER AND SUPPLIER FOR THE EFFICIENT MANAGEMENT OF THE PROCUREMENT WORKFLOW.

DESCRIPTION

The present invention falls within the context of the automation services of the exchange of documents relating to the management of supplies, for example the purchase order of a product or service or a work order, with particular reference to systems and methods for the efficient management of the workflow related to the life cycle of an order.

Over the last few years there has been a notable development of the means of communication, both from the technological point of view and from the point of view of the diffusion of telematic networks, in particular the Internet. This development has given rise to a process of transformation in the management of numerous activities, traditionally carried out in manual mode, introducing the possibility of considerably increasing efficiency and at the same time reducing the management costs of a company thanks to the automation of numerous phases of the work cycles.

Furthermore, technological development extends to all fields, and leads companies to increasingly outsource their activities, both to ensure the benefits of production areas with lower labor costs, and to benefit from better scale efficiency. o of competence that specific suppliers can guarantee, keeping within only the strategic activities for their own sphere of competence, focusing their efforts on what is defined as their core business and delegating the management of secondary activities to third parties, resulting in a high level of collaboration and interaction between different companies.

The collaborations in question are typically hierarchical, of the customer-sub-supplier or customer-supplier type, often structured on different levels, such as the customer in the supply chain. In some cases they can also be of an equal type, for example following an agreement between entrepreneurs to market some components together in order to offer added value to the end customer.

As a result of the operational framework illustrated above, the concepts of IT integration between companies are becoming increasingly important, both for small and medium-sized enterprises, which need close collaborations to be competitive against large companies, and for large companies, who need efficient ways and tools to better manage their ever-changing and evolving supply chains.

The integration between companies, in particular, is linked to the problems of improving organizational performance, in which the attention is focused on the communication of information and on the coordination and optimization of the processes and decisions of the companies, in order to obtain higher levels of productivity, flexibility and quality. Various specific needs have therefore arisen for the electronic and automated management of procurement, in particular for the correct and efficient management of the workflow relating to the life cycle of a procurement process (workflow management).

The technological solutions and the products created to address this issue tend to offer solutions of the "companycentric" type, to be applied to specific companies rather than business districts (business communities) and supply chains (supply chains) in general.

Manufacturers of management applications have generally conceived the functionality of communicating with suppliers or with the supply chain through a module of the management program.

However, the fact of considering these functionalities within a module of the management program of a company presupposes a heavy integration with the management programs themselves, to be reached through tables that make up the company database.

Similarly, the producers of departmental programs, by which term the programs for the management of the progress of production are indicated, the schedulers, and so on, have conceived these functions as an extension of the management of the progress of internal activities.

These technological solutions allow a sophisticated management of the workflow relating to the life cycle of an order, but nevertheless have several drawbacks: they are in fact solutions characterized by high implementation and implementation costs, which require close integration with the systems. business and a long learning curve to be used. Furthermore, these systems introduce serious problems in suppliers, as they require an adaptation of the software systems adopted by suppliers to make them compatible with the communication protocols used; as these are proprietary protocols, suppliers are also forced to operate with different tools depending on the information system of the various customers and / or clients.

Alternative systems are also known for managing procurement which allow customers and suppliers to interact through standard HTML e-mail messages. These systems require a customer to prepare the order by filling in a form created, for example, in HTML and sending it to a supplier in the form of an e-mail message. In the HTML module there are special buttons generated by the customer's application based on the status of the document and the actions that the supplier can perform on that type of document in that status which, once pressed, allow the supplier to automatically generate the desired response. in the form of a new e-mail message containing, for example, a confirmation of the order received or a proposal to change the order obtained by entering the desired values directly on the fields of the HTML form received from the supplier.

These systems are advantageous in terms of ease of use for both customers and suppliers, and, being characterized by the adoption of standard messages and communication protocols, do not require the installation of ad hoc tools and allow uniform work management. between different customers and different suppliers. However, a limitation of these solutions lies in the fact that the asynchronous nature of e-mail communications, combined with the unstructured organization of mailboxes, does not allow the adoption of sophisticated workflow management methodologies, as for example a supplier does not have of automated tools to keep track of the various phases of the life cycle of an order, in particular to make sure that, in the case of modified orders, it is certain to examine the messages corresponding to the most up-to-date version of a given order.

It is therefore evident that the current state of the art does not yet present an optimal solution for workflow management in the context of procurement management.

The main task of the present invention is to overcome the limits of the prior art highlighted above, proposing a new system and method for managing the exchange of documents relating to procurement orders between customer and supplier capable of providing information relating to the supply cycle. life of the orders themselves in a more effective and efficient way than the state of the art.

In particular, the system and the method according to the invention propose to combine the simplicity of managing the exchange of documents by e-mail with the possibility of adopting sophisticated and flexible workflow management techniques typical of more complex frameworks.

Within the scope of this aim, the object of the present invention is to allow suppliers and customers to always be updated in a simple and immediate manner on the current status of an order.

A further object of the present invention is to provide a system that is able to keep track of all the transactions that have taken place between supplier customers and at the same time make transactions that have no impact on the current status of an order transparent to customers and suppliers.

Not least object of the present invention is to devise a system and method for managing the exchange of documents relating to supply orders which is practical, easy to use and has low implementation and management costs.

This task, these aims and others which will become clearer in the following, are achieved by a system for the exchange of documents for the management of the supply of goods and services in electronic form through one or more telematic networks according to claim 1.

Further characteristics and advantages of the invention will become clearer from the following detailed description, given in the form of an illustrative and non-limiting example, accompanied by the relative figures in which:

Figure 1 is a block diagram relating to a possible architecture of the system according to the present invention;

Figure 2a is a block diagram which illustrates in greater detail a first aspect of the architecture of Figure 1;

Figure 2b is a block diagram which illustrates in greater detail a second aspect of the architecture of Figure 1;

Figure 2c is a block diagram which illustrates in greater detail a third aspect of the architecture of Figure 1;

figure 3 is a flow diagram showing a possible embodiment of the method for managing the communication between customer and service manager according to the present invention;

Figure 4 is a flow diagram showing a possible embodiment of the method for managing the communication between supplier and service manager according to the present invention;

Figure 5 is a state diagram which graphically illustrates an example of a workflow;

Figure 6 shows an example of a customer order as displayed at the supplier's desk.

An exemplary architecture of the system according to the present invention is summarized in the block diagram of Figure 1.

The figure comprises a customer computer 10, a supplier computer 20, a service manager 30, storage means 40 and a communication network 50.

The elements schematized in figure 1 are shown by way of example and are illustrative of what are in reality a plurality of customer workstations and a plurality of supplier workstations.

Within a supply chain, in fact, there are more or less articulated collaboration relationships which, for the sake of clarity, can briefly be traced back to two-person relationships of the customer-supplier type, where the term "customer" means the party requesting a product or service, while the term "supplier" means the party providing the product or service.

The client's computer 10 is a client-type device, that is to say any device configured to connect to the service manager 30 via a telematic network, for example a personal computer, a tablet PC or a smartphone.

Similarly, the supplier's computer 20 is also a Client-type device, configured to connect to the service manager 30 via the network 50, for example a personal computer, a tablet PC or a smartphone.

The service manager 30 is a known server-type system, preferably a web server, comprising means for interfacing with the customer's computer 10 and with the supplier's computer 20, so as to allow the transmission of documents relating to procurement. of goods and services in electronic form from the customer to the supplier and vice versa.

In a preferred embodiment of the architecture of the system according to the invention, the service manager 30 is located in the private network of the customer 10, possibly protected by a security means such as a firewall, interposed between the private network and the communication network. 50. The service manager 30 can be located in a DMZ, that is to say an isolated segment, or subnet, of the corporate LAN reachable from both internal and external networks which, however, allows connections exclusively to the outside. This configuration allows the service manager 30 to provide services externally without compromising the security of the internal corporate network. In an alternative embodiment, the service manager 30 is located outside the private network of the customer 10, and the communication between the customer 10 and the service manager 30 takes place via the telematic network 50.

The service manager 30 comprises or has access to storage means 40, which may comprise for example a database or any data structure suitable for permanently storing information. In particular, the archiving means 40 comprise means for storing identification data of each order in progress between customer and supplier and data which allow to find the current status of each order, as will be illustrated in greater detail below.

The service manager 30, the customer's computer 10 and the supplier's computer 20 are equipped with interfaces that allow them to communicate with each other via a telematic communication network. For purely illustrative and non-limiting purposes, the invention will be described here with reference to the Internet network in the role of telematic network 50, and to the use of electronic mail on electronic computers in relation to the method of data transmission.

Naturally, the person skilled in the art will appreciate that the same inventive concept can be applied indifferently on numerous telematic networks, it can also be, for example, an intranet or any private network capable of implementing a client-server type communication protocol.

It will also be clear to the expert in the field that the same inventive concept can be realized using alternative communication systems, for example GPRS and UMTS cellular networks and e-mail programs for cell phones or PDAs, as well as browsers or anything else that allows management of this information.

With reference to the block diagram of Figure 2a, a possible architecture of the customer's computer 10 according to the invention of Figure 1 is now illustrated by way of example.

In particular, figure 2a schematises an information system 11, an adapter module 12, an interface 13 to the service manager 30 and a user interface 14.

The information system 11 is a well-known corporate information system, designed to generate and archive documents to be transmitted to suppliers and documents received from suppliers, according to the layout of the information system and the workflow and defined by the business rules of the company of the customer.

The adapter module 12 is an application capable of converting a document to be exchanged between customer and supplier, for example a purchase order, into a data packet compatible with any suitable communication method, standard or proprietary, usable on the network customer's premises or on the telematic network 50 and containing information on the content of the document and the expected work flow.

In particular, in the adapter module there is an interface 15 towards the information system 11, a data converter 16, a database 17 called "workflow" and a database 18 called "documents".

Workflow 17 is a database that contains information on the expected flow for each type of document and each type of supplier 20, as well as information relating to the layout of the message, as will be better illustrated below.

The documents database 18 contains all active documents classified according to appropriate strategies: for example, documents to be sent, documents sent and documents received from the communication network 50 and information regarding their status.

The interface 15 towards the information system 11 is a module capable of withdrawing or receiving from the information system 11 documents to be transmitted to suppliers 20 and updating or sending to the information system 11 the documents received from suppliers 20, according to the workflow and layout of the information system defined by the customer 10.

The data converter 16 essentially performs two functions.

The first function consists of the conversion of a document, taken or received by the information system 11, into the data packet to be sent to the service manager 30. The information contained in the data packet can be read and interpreted unambiguously by the service manager 30 .

A second, optional function of the data converter 16 consists in the conversion of the messages received from the supplier 20 through the service manager 30. The documents thus converted can be inserted into the information system 11 that owns the customer 10.

The interface 13 towards the service manager 30 is a network interface suitable for the exchange of data between the customer 10 and the service manager 30. As previously mentioned, depending on the architecture adopted for the location of the service manager 30 , it can be an interface between the corporate LAN and its DMZ portion, or an interface between the corporate LAN and the communication network 50. In both cases, through the interface 31 the customer 10 sends 30 communications to the service manager relating to orders to be forwarded to the supplier 20 and receives from the service manager 30 notifications relating to communications sent by the supplier 20, as will be illustrated in greater detail below.

Finally, the user interface 14 identifies the application used to view and organize the documents to and from suppliers 20. The user interface 14 mainly provides means for displaying the contents of the Documents database 18, but also means for customizing the state diagram that defines the flow of documents. For example, the possibility of having a "change request" status, which can be associated with a command that allows the supplier to request a change to the order received with the e-mail message, for example a change to the delivery date of an order of purchase received, or that allows to regulate the interaction between the flows of different documents, for example the possibility of sending a transport document only if the purchase orders relating to the products included in the transport document are in a specific state, for example example the status "confirmed".

With reference to the block diagram of Figure 2b, a possible architecture of the service manager 30 according to the invention of Figure 1 is now illustrated by way of example.

The figure comprises an interface 31, a state transition manager module 32, a customer converter module 33, a supplier converter module 34 and storage media 40.

The interface 31 is a network interface suitable for the exchange of data between the customer's local network 10 or the communication network 50 and the software and hardware modules present in the service manager 30. In particular, the interface 31 receives requests from the client 10, typically in the form of data packets, and from the supplier 20, typically in the form of HTTP requests, and sends them to the state transition manager module 32 for their processing and consolidation in the storage media 40.

The state transition manager module 32 is configured to interpret the data packets received from the customer 10 and to translate them into operations for inserting and updating the storage media 40.

Advantageously, the details of all the transactions that have taken place between supplier 10 and customer 20 can be stored in the storage means 40, in order to keep track of them and possibly communicate them to the customer and / or supplier.

The storage means 40 also store the current status of each order, where current status is understood to mean the status resulting from the execution of all the transactions which have so far occurred between customer and supplier. For example, if the customer creates a new order, subsequently sends a change to the quantities of the order itself, and then the supplier proposes a change in the delivery date, the state transition manager module 32 stores on the one hand the three transitions of status in their temporal sequence, on the other hand it keeps constantly updated the current status of the order or the order resulting from the application of the three transitions. The state transition management module 32 preferably also stores the nature of the last transition in the context of the workflow established for the order and the time stamp relating to this transition.

Furthermore, whenever there is a variation related to an order, or a transition from one state to another, the state transition manager module 32 triggers the sending of a notification to the actor concerned, that is to say to the customer 10 and / or to the supplier 20, as will be illustrated in greater detail below.

The storage means 40 can optionally be used by the customer 10 to carry out queries of various kinds on the order history, for example to indicate to the customer the supplier who has greater availability, or the one who most frequently confirms orders without changes.

The customer converter module 33 is configured to generate, on the basis of information provided by the customer 10 and on the impulse of the state transition manager module 32, a message, in the case illustrated here, an e-mail message, and to embed in the message itself, after any format conversion, additional data defined in the "workf low" database. In particular, the e-mail message, preferably in Mime Multipart format, includes an HTML (HyperText Markup Language) or XML (eXtended Markup Language) portion or written in other markup languages, which represents the documents and information relating to orders and / or the order lifecycle. The information contained in this portion can therefore be read directly by the supplier and can also be interpreted uniquely by an automatic processing system.

The e-mail message generated by the service manager 30 on behalf of the customer 10 is the actual document that is exchanged between the customer 10 and the supplier 20, and therefore allows the transfer of both the data relating to the order and the information on the flow of expected work.

The customer converter module 33 further comprises means for managing the sending of the e-mail message to the supplier 20 according to the selected protocol and known communication techniques.

Preferably, the protocols used for sending and receiving are the standard Simple Mail Transfer Protocol (SMTP) and Post Office Protocol / Internet Message Access Protocol (POP / IMAP), in particular POP3 / IMAP4, respectively.

The message can also be enriched with additional information attached automatically or manually, such as documents in different formats, such as Adobe Acrobatâ „¢ files as attached technical documentation, copy of order confirmation present in the body of the message, or other.

The service manager 30 further comprises a supplier converter module 34, suitable for analyzing the document received from the supplier 20 in response to the message described above, and for updating the storage means 40 accordingly, according to methods known to the skilled in the art. Optionally, the supplier converter module 34 may include a document analysis module sent by the supplier's computer 20, to check for any errors in filling in the received form or to interpret the action to be performed following receipt of the received document.

With reference to the block diagram of Figure 2c, a possible architecture of the computer of the supplier 20 according to the invention of Figure 1 is now illustrated by way of example.

The computer of the supplier 20 is a Client device of a known type, which includes in particular a traditional e-mail program 21 chosen from one of the programs available on the market, for example Microsoft Outlookâ „¢, Netscape Messengerâ„ ¢, Qualcomm Eudoraâ „¢ o Lotus Notesâ „¢. Alternatively or in addition, the supplier's computer 20 can comprise a common web page viewer or navigator configured to run a web application that allows managing an e-mail account (webmail).

The operation of the system is now illustrated in an exemplary form thereof schematized in Figure 3.

The customer 10 uses the interface of his own proprietary information system 11 to create a new order (step 300), according to the modalities provided by the information system on which he usually operates. When the order is ready to be sent, customer 10 can activate the document conversion procedure.

In particular, at step 305, the adapter module 12 receives, through the interface towards the information system 15, the data relating to the new order, and passes them to the converter 16, which is responsible for converting the data from the proprietary format used by the system. information 10 to a format in the standard chosen for forwarding the data to the service manager 30.

At the same time the converter 16 retrieves from the database 17 the workflow relating to the order, which can be different from order to order and can be modified by the user through the user interface 14, and completes the message with information relating to the workflow envisaged for the specific order. In particular, the workflow defines which operations the supplier 20 can carry out in response to the order received. A first possibility consists, for example, in asking the supplier 20 only to accept or reject the order. A more advanced possibility consists in enabling the supplier 20 to modify some parameters of the order, such as the delivery date of each individual product or service ordered, the quantity delivered or to be delivered, the purchase price and so on.

An example of a workflow, displayed graphically, is illustrated in figure 5 by means of a state diagram. The twelve possible state transitions (from 901 to 912) are shown in the following Table 1, which clarifies, in relation to the example shown, the change in state and the subject (customer 10 or supplier 20) who determined the new state, as well as the action defined within the exchanged message triggered by the change of state.

d State State Subject Action

initial final

01 New Proposed Customer notificationF omitor: send

Notification to the Supplier (proposal

order)

02 Proposed Proposed Customer notificationForer

03 Proposed Modified Notification Supplier Responsible: sending

Notification to a Manager

of the order

04 Modified Proposed Customer notification F ornitor

05 Modified Confirmed Customer notificationSupplier

06 Confirmed FrModif Provider notification Responsible 07 Confirmed Closed Customer

08 Confirmed Proposed Customer notification of Supplier

09 Proposed Confirmed Supplier notification Responsible 10 Proposed Canceled Customer notification Supplier

11 Amended Canceled Customer notification F ornor

12 Confirmed Canceled Customer notification by the supplier

Table 1

Once all related information

when ordering they are ready to be sent, they come

automatically forwarded to the service manager

30 (step 310). Following this, the 18

"Documenta" is automatically updated with

entering the message data (step 315).

At a later time the customer 10 will be able to

send information to the service manager 30

relating to the modification of the order itself with the same methods adopted for the creation of the order and according to the rules defined in the previously sent workflow. For example, the customer can send requests for changes in the quantity of goods ordered, changes in the delivery date, cancellation of the order.

Similarly to what happens for the request for order creation, each request for modification of the order is simultaneously sent to the service manager 30 (step 310) and reflected in the information system 11 of the customer 10 (step 315).

At step 320 the service manager 30 receives the request for insertion or updating of the order from the customer 10, and updates the storage means 40 accordingly.

In particular, in the case of a new order, this operation comprises the insertion of the data relating to the new order into the storage means 40 (step 330).

In the case, on the other hand, of a request to update an order, at step 340 the state transition manager 32 updates the order status with variable modalities according to the workflow defined by the customer at the time of creation of the order. In particular, the state transition manager 32 verifies that the modification proposed by the customer is compatible with the workflow previously defined by the customer; in the affirmative it proceeds to update the elements of the order on which the request for modification has an impact, for example the quantities of the products ordered or the delivery date. Finally, the state transition manager 32 updates the current state of the order, appropriately coding the state transition that has just occurred and the instant in time in which it occurred. In one embodiment, the state transition manager 32 stores a state transition code selected from the codes 901-912 illustrated in Figure 10 and a timestamp relating to the state transition. In a preferred embodiment, the state transition manager 32 further calculates a hash function of the document corresponding to the current state of the order, for example by means of a Message Digest algorithm 5 (MD5), and stores the resulting hash value.

This information will subsequently be used to assess whether the supplier is working on the most updated version of a document received or not, as will be illustrated in greater detail with reference to Figure 4.

Both in case of insertion of a new order (step 330) and in case of update of an order (step 340) the manager of the state transitions 32 also performs a logging activity of the operation just performed in order to keep track of the 'atomicity of all the state transitions occurred during the life cycle of the order, for any statistical or reporting needs by the customer or supplier.

Once the order and its current status have been created or updated, the service manager 30 generates the message to be sent to the supplier 20.

In particular at step 350, the supplier converter module 34 retrieves from the storage means 40 the information relating to the order, which includes the actual data of the order, the current status of the order and information relating to the workflow, and converts them into the format of the standard language chosen for sending the message to the supplier 20.

In a preferred embodiment the supplier converter 34 generates a standard HTML e-mail message. In particular, it prepares an HTML form in which there are specific buttons based on the status of the document and the actions that the supplier can perform on that type of document in that status which, once pressed, allow the supplier to automatically generate the desired response in the form of a new e-mail message containing, for example, a confirmation of the order received or a proposal to change the order obtained by entering the desired values directly on the fields of the HTML form received from the supplier.

Furthermore, in a preferred embodiment the supplier converter 34 inserts in the HTML message suitable portions of code which allow to signal, when the message is opened in the computer of the supplier 30, the possible availability of a more updated version of the message and, if so, to obtain this most up-to-date version.

An example of HTML code that allows version control, and, in case of an outdated version, the notification and display of a button to request the sending of the updated document by e-mail is shown for illustrative purposes and for descriptive purposes in Table 1.

<td>

<a

href = "http: // localhost: B080 / iungo / servlet / documentaiìonDownload / predef / PostReactive Servlet?

object = REACT Updated Requested 0A-11253sbody = ~ sTN = prRinvioOrdine; ~ oid = 1092; ~ dem = 28-05-2007;

~ num = l1253; ~ pServlet = l; ~lng=itidittaId=iungo@localmail.it_base & to = iungo @ localmail.it £ sender = supplier @ localmail.it "target =" blank <,, >>

<img src = "http: // localhost / iungo_support / imgRevision update reactive.php? sb ^ REACT Check Revision

A_11253sbody = ~ sTN = frChkRev; ~ log_notificald = 1316704731015; ~ oid = 1092; md = W64yiimFdPJP5oYMpqqsitw ==; & to = iungo @ localmail.it & aziendaId = iungo @ Localmail.it_base &from=fornitore@localmaìl.it&t=Check_Revision

& postReactiveUrl = http: // localhost; 8080 / iungo / servlet / documentationDownload / predel / P stReactiveServlet

lng = en "alt = <n>" title = "Request email with updated document" border = "0"> / a>

/ td>

Table 1

An example of HTML code that allows the

version control, and in case of non version

updated, reporting and viewing

a link to access the document directly

updated at the service manager 30 Ã ̈

reported by way of example and for purposes

descriptive in Table 2.

<td>

<a href="http://localhost:8080/iungo/servlet/app/template/ordini%2Cpopup %2CNotifica_preview_external.vm /orderid/1092/md5forn/3wmoHVe4zLjlDCdChjctpQ==">

<img src = "http: //localhost/iungo_support/imgRevision_vìew_reactive.php? sb = REACT Check Revision OA_11253

Sbody = ~ sTN = frChkRev; ~ log_notificald = 1316703933820; -md = SOiOk5zJOOc90qk4TkNcEA ==; & to = iungo @ localmail.ìt & dittald = iungo @ localmail.it base

&froiti=fornitore@locaLmail.it&t=Check_Revision&postReactiveUrl=http: // localhost: 8080 / iungo / servlet / documentationDownload / predef / PostReactiveServiet

& lng = en "alt =" "title =" Access updated document "border =" 0 ">

</a>

</td>

Table 2

Once the order is physically ready for dispatch, the message is automatically sent to supplier 30 (step 360).

Figure 6 shows an example of how a new order generated by the supplier converter module 34 of the service manager 30 following the request for sending by the customer 10 can appear on the screen at the supplier 20. In this case, the customer has enabled the possibility to confirm the order or to change the delivery date of the order and the possibility to insert notes next to each product ordered.

It should be noted that the supplier 20 receives in its electronic mailbox messages relating to orders that appear to have been sent by the customer 10, and may therefore not be aware of the fact that these messages have been sent by the service manager 30, as well as of the fact that its subsequent order confirmation or modification message is not sent directly to the customer's computer 10, but which instead passes through the service manager 30 for subsequent conversion. This represents an advantage in terms of flexibility, since the supplier is aware that he does not have to have special software applications to respond to the order request but that he simply has to intervene on the fields that he sees displayed through his e-mail program or through your web browser.

As already mentioned, however, a common e-mail program lists all messages received in the order in which they are received; in other words, it is an unstructured repository, which does not have specific functions for managing the workflow relating to an order, and in particular to identify all messages relating to the same order or the time sequence of requests sent by the customer and answers already sent by the supplier.

Since the customer and supplier proceed in asynchronous mode, situations could arise in which the supplier 20 responds to a procurement request without realizing that his mailbox contains one or more messages relating to the same request and subsequent ones, for example containing a request for modification of the previous procurement request, or a cancellation of the request itself. In other words, there is no guarantee that the supplier is processing the message corresponding to the current order status and not an obsolete message.

With reference to Figure 4, a possible embodiment of a method for managing the communication between the supplier 20 and the service manager 30 is now described, which allows to overcome this drawback, which is useful for better understanding the inventive concept underlying the present invention.

The method begins at step 410, in which the supplier 20 opens, within his own e-mail client or web browser, the message sent by the supplier 30 on behalf of the customer 20 at step 360 and received at step 370.

The opening of the message triggers the automatic sending from the supplier 20 to the service manager 30 of a request to verify the version of the document contained in the message, or of a notification containing identification data of the order to which the message refers, in particular data identifiers of the state in which the order was located at the time the message was sent.

In a preferred embodiment, the notification is achieved by setting an HTTP request to a page encoded in a scripting language, such as PHP, and residing on the web server of the service manager 30. The automatic sending of the HTTP request to the when the e-mail message is opened, it is carried out with background data exchange techniques between browser and web server, which allow the dynamic updating of a web page without explicit reloading by the user known in the art, for example example with Ajax techniques.

The notification sent by the supplier 20 is received by the service manager 30 at step 415.

On the basis of the information contained in this notification, at step 420 the service manager 30 checks whether the message refers to the current status of the order or not. In a preferred embodiment, the PHP page called upon opening the message in step 410 in turn calls a module contained in the state transition manager 32 configured to compare the version of the document contained in the message that sent the call with the version of the document corresponding to the current status of the order. Furthermore, in a preferred embodiment, this comparison takes place by comparing the MD5 hash values associated with the two documents. The service manager 30 then communicates the result of the check carried out in step 420; in particular, if the verification has given a negative result, at step 425 it responds to the notification received from the supplier 20 with a response that allows a warning, for example a text or an image, to be displayed on the e-mail message opened by the supplier 30, which indicates that the message is out of date, and also displays a button that allows you to get the updated version of the document. In one embodiment, a button is displayed which triggers the sending by the service manager 30 to the supplier 10 of the updated document via e-mail; in one embodiment, a link is displayed that allows downloading the updated version of the document via a web browser; in one embodiment both the button and the link are displayed.

In one embodiment, the exchanged email message may contain a link to an image. In the event that the open version of the message is the most recent, this link can produce, in response to the call to the server to retrieve the corresponding image, the display of a neutral image, for example an empty image. , where the version of the message does not match the latest version, the image returned by the server may be an image containing a prominent warning sign.

At step 430 the supplier 20 checks whether the open message contains a warning of this kind: if so, at step 440 it presses the button or selects the link displayed next to the warning; with this action the supplier 20 sends a second notification to the service manager 30, which indicates the request to receive the updated version of the message, that is the message corresponding to the current status of the order. This notification is received at step 445 by the service manager 30, who, at step 450, queries the storage means 40 to retrieve the current status of the order.

The service manager 30 then proceeds, at steps 455 and 460, to generate and send the updated document in the form requested by the supplier 20; in the case of an e-mail message, this is generated in a similar manner to what has already been described with reference to steps 350 and 360. In the case of a document made available via a web browser, this is generated dynamically on the web server associated with the service manager 30 with modalities known in the art.

At step 465 the updated message is delivered to the vendor computer 30.

At step 475 the supplier 30 after opening the message (original or updated) evaluates the content of the order, and can therefore decide (step 480) to send a reply to the customer 10, for example to confirm the order, or to propose changes (step 485), limited to what is foreseen by the message workflow and wired in the HTML code, for example by changing the delivery date of certain items.

In both cases the preparation of the message takes place automatically by acting on the graphic buttons associated with respective <post> commands (for example, <post> of the confirmed document or <post> of the modified document), thus sending the HTML portion o XML of the message (possibly modified by the supplier) in a "post" message (step 485) to the service manager 30.

At the service manager 30, the message generated by the <post> command and corresponding to the actual content of the order (possibly modified by the supplier! Is received (step 495) by the interface 31 and possibly analyzed by the supplier converter module 34 for any verification of the correctness of the changes made.

At this point, the service manager 30 updates the status of the order on the storage means 40 based on the content of the message, and then notifies (step 497) the customer 10 via the communication network 50 that the status change relating to the 'order.

Once the notification has been received (step 499) the customer 10 can view the status of the order by connecting to the service manager 30 through the interface 13 to the manager. The customer 10 will be able, for example, to view the indication of the order confirmation accompanied by the list of confirmed products or the list of products whose information has been changed.

Note that it is not necessary for the supplier to have special programs for receiving orders or modifying them, as the received message can be viewed in any email program and modified through the functionalities (for example, the <form> function in HTML) commonly offered by mark-up languages, which allow the modification of data and the generation of a new form with the modified data. Therefore, the same e-mail client used by the supplier 2 to receive the e-mail message 30 is, like all the most popular e-mail clients, also able to act as a tool for entering additional information, as defined in the HTML or XML portion of the message 30 received. Alternatively or in addition, the HTML / XML content of the e-mail 30 can also be viewed with a common web page viewer or browser.

Also note that the supplier 20 is not bound to process the messages relating to the same order in a specific sequence, as it is the service manager 30 who is responsible for ensuring that the supplier 20 always displays the most relevant version. updated of an order.

It has thus been shown that the described method and system achieve the intended aim and objects. In particular, we have seen how the system described allows the automation of customer-supplier communications while simultaneously guaranteeing the possibility for the customer to define workflows of any complexity and the possibility for the supplier to manage this workflow through a standard application, normally use, which is an e-mail client and \ or a web browser.

In fact, the system according to the invention, thanks to the code inserted in the HTML message present in each document received by the supplier, allows the supplier to be automatically notified, upon opening the message, of the availability of an updated version of the document to which the supplier can be accessed instantly or can be sent by e-mail.

Clearly, numerous modifications will be clear and can be readily carried out by the person skilled in the art without departing from the scope of the present invention. For example, it is obvious for those skilled in the art to replace one communication protocol with another, depending on the needs of the players participating in the system and the technology made available on the market.

It is also evident that the inventive concept underlying the present invention is independent of the actual implementation of the software modules, which can be realized in any language and on any hardware platform, just as the method of integration with the various management systems of customers and suppliers, as long as they are able to import and export information in a proprietary way or, also in this case, according to a standard, for example ebXML.

Therefore, the scope of the claims should not be limited by the illustrations or preferred embodiments illustrated in the description in the form of examples, but rather the claims should encompass all of the patentable novelty features that reside in the present invention, including all of the characteristics that would be treated as equivalent by the person skilled in the art.

Claims (10)

CLAIMS 1. System for the exchange of documents in electronic form for the management of supplies through one or more telematic networks (50), comprising: - at a customer station (10), means to define a procurement request, an operational flow and rules in proprietary electronic format; - at a service manager (30), means for converting said request, said operational flow and said rules into a first e-mail message; - at said service manager (30), means for sending said first e-mail message to at least one station of a supplier (20) through standard communication protocols, said at least one station being reached by at least one of said telematic networks (50 ); characterized by the fact that: said first e-mail message contains information to allow an automatic request relating to the version of said procurement request to be sent from said station of the supplier (20) to said service manager (30); - at said service manager (30), means for evaluating said request and means for sending a response to said supplier station (20); - at said station of the supplier (20), means for displaying said response within said e-mail message. 2. System according to claim 1, characterized in that said response comprises information relating to the availability of an updated version of said procurement request. 3. System according to claim 2, further comprising at said supplier station (20) means for displaying within said first e-mail message interface means configured to request generation and sending, at said service manager ( 30), of a second e-mail message containing said updated version of said procurement request. 4. System according to claims 2 or 3, further comprising at said supplier station (20) means for displaying, within said first e-mail message, interface means configured to request display, at said service manager (30) , of said updated version of said procurement request. 5. System according to one or more of the preceding claims, characterized in that said telematic network comprise the Internet network. 6. System according to one or more of the preceding claims, characterized in that said first and second e-mail messages are in the Mime Multipart format, with a portion in HTML or XML language. System according to claim 6, wherein said content of the first message is said portion in HTML or XML language. 8. System according to one or more of the preceding claims, characterized in that said standard protocols include SMTP and POP / 1MAP. 9. System according to one or more of the preceding claims, further comprising, at the supplier's station, means for: - receiving said first or said second e-mail message, displaying the message received on the screen in a user interface; - modify and / or confirm the content of said first or second e-mail message. System according to claim 9, wherein said means for modifying and / or confirming the content of said first or said second e-mail message consists of any one between an e-mail application or a web page viewer written in HTML or XML or a web browser, said content of said first or said second e-mail message including an address of said service manager (30).