IT202000024970A1 - Method and system for certifying the delivery/provision and conformity of goods and services - Google Patents

Description

DESCRIPTION of the invention with TITLE:

"Method and system to certify the delivery/supply and conformity of goods and services (evolved PoD or PoWD)"

Field of application

The present invention finds application in the sector of the sale and distribution of goods and/or the provision of services between commercial operators (Business to Business, B2B), between companies and public operators (Business to Government, B2G) and between commercial operators and citizens ( Business to Consumer, B2C) and has as its object the creation of an innovative method of integrated management of the executive phases of the process which, through the use of one or more IT tools, allows you to document, validly and with full legal effect, the compliance? of supplies and, therefore?, to prevent the occurrence of commercial disputes, as well as to optimize the administrative management of the activities? and to allow the measurement of the performance of the operators involved in the process.

State of the art

Ideally, the procurement cycle or process of goods and services can break down into the following stages:

to. definition of needs;

b. supplier selection;

c. contract stipulation;

d. supply order;

And. execution of the supply;

f. billing;

g. payment of the consideration.

Each of them is characterized by the production of specific documents (some of them are typical of B2B and B2C exchanges), such as the tender notice, the award provision, the contract, purchase orders, transport documents, the attestations of regular delivery of the goods and/or execution of services, invoices, payment orders, guarantees related to the supply, etc.

The aforementioned phases do not necessarily take place in the sequence shown. Just think of the circumstance in which the purchases resulting from the identification of the need are made using a framework contract already existing, or in the case of purchases of goods of modest value, in which all the steps take place at the same time. Furthermore, in several cases, some of the documents typical of each stage are not needed, or are incorporated into other documents. For example, the payment can be made in cash (without, therefore?, the need to issue a mandate to the bank), the delivery of the asset can? take place at the supplier (for which there is no issue of the transport document), the purchase order can? be implicitly contained in the contract, and so? Street.

In general, however, especially in B2B and B2G sales, each phase has its own relevance and is formalized through deeds or documents exchanged between customer and supplier or other actors in the process or, at most, through the "non-action" of one or of the others (for example, the "non-contest" of the supply within the established terms).

The lack (or unavailability?) of these documents, however, often contributes to misunderstandings and can be an obstacle in the settlement of disputes.

The full right of the supplier to the consideration in cash, in fact, arises only if the principal obligation ? been actually fulfilled and accepted by the customer. Hence the need to unequivocally prove the successful delivery and, even more so, the conformity? of goods delivered (or services provided) compared to ci? that ? requested in the purchase order, with the requirements established in the contract and, at most, even in relation to the provisions of the tender notice or other deed (or equivalent document).

This need is more forcefully manifested where third parties are involved in the transaction, both in terms of supply execution (carriers, distributors, logistics service providers and outsourcers in general) and in terms of managing the corresponding trade receivables (factor and intermediaries finance in general). In the first case, due to the fact that the various documents are dispersed among several? operators, with the consequence that the retrieval of the documents produced during the process can? be anything but easy. In the second, why? the subjects who finance the supplier company certainly have an interest in knowing the effectiveness? than shown in the invoices.

Furthermore, the national context in which the exchanges take place can present a further element of complexity? where the invoices (or equivalent documents) are issued, by law or for commercial use, in electronic format, while the other documents of the process, depending on the specific product sector and/or methods? with which the transaction takes place, are produced and/or transmitted in traditional ways or even in electronic form but using non-interoperable paths and protocols.

In this context, the "receipt of delivery" (Proof of Delivery, PoD), an expression typically used in the context of the sale of goods to indicate the "certification of receipt of goods" by the customer, assumes specific relevance, but what can? be applied, by extension, also to the provision of services with the meaning of "certification that the activity has been performed".

Specifically, the PoD is achieved with the signing, by the subject receiving the goods and/or services, of an act certifying the execution of the supply, such as: a paper copy of the transport document (DDT) which is kept by the carrier who delivered the goods, or a paper copy of the document describing the service provided which is retained by the person who physically carried out the activity, and so on? Street.

For illustrative purposes only, Figure 1 (the details of which are described on Page 31 in the Section "Brief description of the drawings") shows the simplified model of a typical process for the sale of goods in the B2B and B2G context: the supplier of the goods (Provider ) operates using an integrated logistics service provider (Third Party Logistic Service Provider, 3PL) which, in turn, uses a carrier (Carrier) for the transport and delivery of the goods to the final customer [Client].

? It is clear that the PoD presents two critical elements:

a) the attestation cos? carried out only demonstrates that the person in charge of the delivery has proceeded to return the goods to the recipient and that the latter has received it (or that the service has been provided), but says nothing about the conformity? you say? that ? been delivered (or on the quality of the service provided) compared to what was requested with the purchase order (or other document defining the supply) n? how much will it be? shown in the corresponding invoice (or in the corresponding invoices). For example, in the case of the sale of goods with delivery to the customer's home, normally the goods ? contained in one or more packaging (primary and / or secondary) that are opened at a time following delivery, therefore the signature affixed by the customer on the DDT only certifies that he has received one or more? casings and not even the quality? of the goods contained therein; similarly, in the provision of services, the customer, as a rule, can? evaluate the goodness of the activity? carried out only after having carried out suitable functioning checks or, even, a real test.

b) so that? the supplier of goods or services can update the "state of supply", it would be necessary:

? that the executor of the supply (for example, the carrier) promptly delivers the copy, countersigned by the customer, of the document certifying the activity? carried out (for example, the DDT);

that the supplier has the capacity? adequate organizational structure to punctually proceed to associate this document with the corresponding purchase order (or corresponding purchase orders), with the corresponding invoice (or with the corresponding invoices) and/or, if necessary, with the additional documents relating to the other phases of the procurement process (for example, the contract).

In real experience, the copy of the DDT countersigned by the customer for receipt (or the document certifying the provision of the service), is usually retained by the carrier (or by the person in charge of carrying out the activity) and the supplier requests its availability ? only in case of disputes.

In practice, you can? conclude that, since? the PoD is created with the customer's countersignature of a document issued by the supplier to certify receipt of the goods or service, even if the PoD is created in electronic format (for example: the electronic DDT digitally countersigned by the customer; a distinct electronic document signed by the customer certifying that the supply referred to a particular DDT has been performed; etc.), would it only resolve the issue mentioned in the first bullet of the previous point b), while all the other criticalities? would remain unsolved.

Presentation of the invention

Purpose of the present invention? that of creating an innovative method of integrated management of the executive phases of the process of sale of goods and / or provision of services in the B2B, B2G and B2C fields, through the use of one or more? computer tools capable of documenting, validly and with full legal effect, compliance? of supplies and, therefore?, to prevent the occurrence of commercial disputes, as well as to optimize the administrative management of the activities? and to allow the measurement of the performance of the operators involved in the process.

Such an end ? achieved through the generation, contextually with the supply of goods and/or services, of an integrated system of data in digital format, also in the form of an IT document, available to the various players in the supply process and to other stakeholders with access profiles adapted to the needs of each, containing the certification that the goods (or services) delivered (or provided), separately and/or as a whole, correspond or not to what was established between the parties.

The innovativeness? of the method mainly regards the evolution from the "delivery receipt" [Proof of Delivery, PoD) - which only certifies that the delivery of the goods or the provision of the service ? been carried out - to the "certification of execution and conformity?" (Proof of What Delivered, PoWD), which constitutes an unprecedented digital tool, which can also be implemented in accordance with to the commonly recognized international standard for business documents (Universal Business Language, UBL).

PoWD? the cornerstone of sui ? redesigned, with a cooperative approach, the architecture of the document flows underlying the supply chain.

Unlike the PoD, in fact, the PoWD pu? define itself as an integrated system of data in digital format , which can? have the form of a structured IT document or other set of data in digital format, which enables the creation of a management method suitable for certifying both the execution of the supply and the compliance? of the goods sold and/or the service provided with respect to the information contained in the purchase order (or in the purchase orders), in the invoice (or in the invoices) and in other documents relating to the various phases of the procurement process (for example, in the contract).

For the sole purpose of clarity and without constituting any limitation to the scope of protection claimed, the PoWD ? described using the concept of structured computer content. In particular, the following expressions are used:

? simple computer content, to indicate a computer representation in structured form, which can be signed electronically, of relevant acts, facts or data referring to a portion (phase or step) of a business process, implemented by means of the method or system object of the present invention; ? complex computer content, to indicate a logical or physical set of simple computer contents (as defined in the previous bullet), created by means of the method or system object of the present invention. A complex computer content, for example, pu? be constituted by a structured IT content composed of other IT contents (embedded or recalled) referring to a business process. In any case, it has the characteristic of being electronically subscribed, as both the contents that compose it and the respective computer connections can be subscribed electronically.

It is specified that a computer content can? take the form of or be incorporated into an electronic document.

An example of conceptual architecture of the PoWD - susceptible to numerous modifications and variations, all falling within the inventive concept set forth in the present document - ? represented in Figure 2 (the details of which are described on Page 32 in the Section "Brief description of the drawings").

In particular, PoWD has the following characteristics:

? has the properties of the computer document, therefore pu? be signed with an electronic signature in its various variants (simple signature, advanced signature, qualified signature, digital signature, digital seal, etc.) and has full legal effect (the strength of the legal effect between the parties and against third parties depends on the type of subscription used and by the legislation in force in the country of application);

? has the properties of the structured document, i.e. the information contained therein can be processed automatically by management software. In particular, in order to facilitate its use in cross-border trade, it can also be made up of one or more? modules compliant with the UBL standard;

? contains the exact description of the goods delivered (and/or of the service provided), with an indication of the purchase order (or purchase orders) to which the supply refers and the specific order lines, as well as of the other documents relating to the various phases of the procurement process (for example, the contract, any guarantees, etc.). There? allows PoWD to trace the results of the checks on the goods and/or services both as a whole and separately;

? constitutes the link between ordering and billing, as:

or can? directly recall the order (or orders) and the other documents (and for example, the contract) from which the supply derives or, in the event that the supply is carried out prior to or simultaneously with the issue of these documents, they can recall the PoWD;

or can? be directly referred to in the corresponding invoice (or in the corresponding invoices or equivalent documents) issued against the supply or, in the event that the invoice is issued prior to or simultaneously with the execution of the supply, it can be recalled in the PoWD;

? ? a progressive training content, that is, is it perfected in more? step. In the case of the sale of goods, typically (but not exclusively), these steps are: the preparation of the supply (which includes the packaging), delivery and verification of the goods (with indication, element by element, of the conformity or otherwise of the goods received). In the case of the provision of services, typically (but not exclusively), the steps are: the execution of one or more? activity?, the receipt of the result of these activities? and the verification of the actual conformity? and the proper functioning of the product created (with indication, element by element, of the conformity or otherwise of each of the elements that compose it). The various refinement steps can be obtained by multiple signing of the same document (in the case of the PoWD formed as a simple document) or (or in addition) by adding and signing separate documents (in the case of the PoWD formed as a complex document ).

Thanks to these characteristics, the PoWD overcomes all criticalities? unsolved by the PoD mentioned in the list starting on Page 5 in the Section "State of the art",.

Particularly:

a) with PoWD ? possible to certify, validly, with full legal effect and with a certain time indication, not only the successful shipment (or execution) and receipt of the supply, but also the outcome of the checks on the goods (or service) carried out by the customer (or by another actor in the process) with respect to what was ordered, what was invoiced and other criteria established between the parties. These checks can refer both to the supply as a whole and to the distinct elements (goods or services) that compose it and each element can be the subject of more checks: for example, if the supply provides for the delivery of a specific quantity? of goods to which a certain number of ancillary services are associated (installation, operational test in operation, etc.) some of which are not contextual to the delivery (because they require a trial period, because they need to be repeated after time, etc.), the checks (even multiple) and the related results can refer, separately, to each of the goods and to each of the individual services associated with them, b) moreover:

? the PoWD makes it possible to trace - in real time - both the progress of the supply and the results of the checks carried out by the customer and by the other actors in the process (for example, intermediaries, carriers, etc.). This information can be made available both to the actors who take part in the process (customer, supplier, carrier, etc.) and to any interested third parties (for example: the factor), each with visibility? profiled on the basis of related skills;

? the association with the other documents of the process (purchase order, invoice, etc.) can? be fully automated and not ? in no way constrained by relationships of type one or one. In other words, a PoWD can correspond to one or more? purchase orders (and vice versa), one or more? invoices (and vice versa) and cos? via, regardless of the sequence and/or the emission time;

? ? supplies can also be easily managed:

or divided into more? delivery batches;

or made through one or more? intermediaries;

or made by pi? separate suppliers.

Given the above, the PoWD pu? be seen as an integrated system of data in digital format, which pu? have the form of the computer document, which d? origin of a process innovation, consisting in the complete tracing of the various steps of the supply execution phase in order to:

? certify the completion of the principal obligation (the sale of goods and/or the provision of services) and, therefore, the actual right to receive the relative consideration in cash (the supplier's trade credit);

? optimize the administrative management of the activities;

? allow the measurement of the performance of the operators involved in the process.

By way of example only:

? in the context of the sale of goods with delivery to the customer's home or premises, PoWD pu? be seen as an evolved form of transport document (DDT), not only because? issued in electronic format, but also why? allows you to receive both the delivery receipt and the attestation by the customer, or other actor of the process, of compliance? of the goods received. These certificates can:

o be contextual or affixed at distinct times;

or cover both the totality? of the supply as each of the individual elements that compose it, indicating for each the outcome of the verification carried out (for example: goods or packaging received, goods or packaging rejected because it was received not intact, goods not compliant with the order, goods not compliant with contractual requirements, compliant and accepted goods, etc.);

o be carried out in partnership between the various actors in the process (for example, the carrier and the customer);

? in the context of the provision of services, the PoWD pu? be seen as an evolved form of delivery and testing report, not only because? issued in electronic format, but also why? allows the customer, or other actor of the process, to certify that the activity? expected ? been performed, what ? been carried out in accordance with what was established and, possibly, that the product of the activity? (for example, the equipment repaired, the software developed, the work carried out, etc.) meets the required requirements and/or works correctly. These certificates can:

o be contextual or affixed at distinct times;

or cover both the totality? of the supply as each of the distinct elements that compose it, indicating for each the outcome of the verification carried out (for example: activity performed, activity not solving the problem, product of the activity not compliant with the requirements, activity accepted following the favorable outcome of the test, etc.);

o be carried out in partnership between the various actors in the process (for example, for tests carried out jointly by commissions made up of the customer, the supplier and/or third parties).

Given the definition given on Page 8, some models are illustrated below, which can also be used in combination with each other, of how can? the internal structure of the PoWD and of the system architecture as a whole be realized. The models described are for illustrative purposes only and do not represent the totality of the possible implementations of the present invention.

1. PoWD in the form of simple computer content (see the definition of "simple computer content" on Page 8). PoWD can be implemented as a structured IT document, preferably (but not exclusively) described using a language based on a syntactic mechanism that allows the meaning of the contained elements to be defined and controlled, suitable for data interchange and independent of the type of hardware platform and the software on which it is used (for example, XML, JSON, etc.). Can? include attached files in formats commonly used in data representation, both textual (for example, RTF, PDF, HTML, XML, etc.), and multimedia (for example, BMP, GIF, MPEG, etc.), is of any other kind, including compressed formats (for example, BPEL, ZIP, etc.); or (or in addition) pu? contain references to external files and documents, which can be both in electronic and analog format.

2. PoWD in the form of complex computer content (see the notion of "complex computer content" on Page 8). PoWD can be made as a set of pi? simple computer contents related to each other (for example, a computer file), having the characteristics described in the previous point 1 of this list or from references to external files and documents. The relationships between the aforementioned contents may or may not be managed through one or more? orchestrator systems (see point C of the list beginning on Page 19).

3. Subscription to the PoWD. The PoWD and/or each of the contents that compose it, as defined in the previous points of this list, can be signed with an electronic signature (for example, the simple signature, the advanced signature, the qualified signature, the digital signature, the electronic seal , the qualified electronic seal), regardless of the modality? with which the subscription is affixed (for example, CAdES, PAdES and XAdES), or through another IT process that allows the subscriber to be associated with the content. They can also be associated with a timestamp (for example, electronic timestamp, qualified electronic timestamp).

4. Centralized and distributed hosting architecture. The PoWD and/or each of the contents that compose it can reside and/or be stored, jointly (centralized hosting architecture) or separately (distributed hosting architecture), on the computer system of one (or more than one) of the actors of the process (for example, the supplier, the customer, the 3PL, the carrier) and/or at the computer system of a third party (or more than one), which makes them available for the creation, modification of state, subscription, etc., as well as? for consultation by authorized subjects, duly profiled.

5. External references and embedded documents. Regardless of the hosting architecture used (centralized or distributed, see point 4 above of this list) the external references contained in the PoWD can be pointers (for example, URLs) to content residing on the same system as the PoWD (or one of the its elements) or on separate computer systems, or they can be the identifiers of other documents (for example, analogical documents). PoWD can also incorporate documents produced at stages of the procurement process other than that of supply execution (for example, purchase orders, invoices, contracts, etc.).

6. Content of the PoWD. Does the PoWD contain all the information necessary to allow at least the receipt and conformity certificates? of the goods sold and/or services provided, as a whole and separately, and those to trace the actions that the actors in the process have not implemented upon expiry of predetermined terms and/or conditions (for example, the date by which ? a certificate of conformity is required). To promote interoperability bilit? with other systems, ? possible (but not necessary) to use the elements and/or adopt the rules prescribed by the UBLo international standard of similar frameworks.

The PoWD enables a process innovation consisting in the reengineering of the administrative flows of the supply execution phase (and, in some cases, also of other phases of the procurement cycle) why? allows you to manage, in mode? cooperative, the contents and/or the progress corresponding to the various steps of the process. The contextuality? of the activity? administrative, traced through the PoWD, with the operational one, associated with the availability? online and in real time of business information, allows to achieve significant improvements in efficiency, particularly relevant with regard to the distribution chain (reduction of execution times of administrative operations, greater timeliness of responses, reduction of disputes, etc.), which reverberate in advantages in economic and financial terms (accuracy of the supply, recognition of the existence of commercial credits, etc.).

Below are some models, which can also be used in combination with each other, representative of how it can the cooperative approach of administrative flows using PoWD should be implemented. The models described are for illustrative purposes only and do not reproduce the entirety? of possible implementations.

A. Collaborative environment. Whether you adopt the centralized or distributed hosting architecture described in point 4 of the list starting on Page 15 and regardless of whether the PoWD is implemented in simple or complex document form (see points 1 and 2 of the 'list starting on Page 15), ? Is it possible to create a mechanism that allows the various actors in the process, duly identified, profiled and enabled on the basis of their respective skills, to access the contents (or parts of them) in a mode? secure (for example, using authentication protocols and asymmetric key encryption) for operations of creation, modification of state, subscription, etc., as well as? for consultation.

The same result can be obtained by implementing data flows between the various players who, from time to time, exchange the updated version of the contents.

In both solutions, suitable design patterns can be adopted (for example, publish-subscribe, observer, etc.), respectively, to notify status changes, to transmit updated content, whenever a replication mechanism is provided on pi? systems, and what? Street.

B. Tracking of process steps. The tracking/certification of the various steps of the execution phase (shipping, receipt, verification of conformity, etc.) takes place by updating the status of the PoWD. There? can? be obtained by producing a new corresponding component content (this solution, for example, can be adopted if the PoWD is a complex computer content, composed of several documents compliant with the UBL standard) or by updating one or more? elements of a pre-existing content (for example, modifying or enhancing the attributes of a structured IT document). In both cases, to give legal effect to the change of status of the PoWD, also taking into account specific national legislations, can be useful to electronically subscribe to the added content or the new version of the updated content. Generally, but not necessarily, using cleartext signing methods (for example, XAdES signing), where possible, aids portability? of content and interoperability? of the system.

C. Management model. For the management of PoWD, both centralized models (for example, n-tier client-server architectures) and distributed models (for example, peer-to-peer architectures, blockchain, etc.) can be adopted.

In the remainder of this document, for the sole purpose of brevity? exhibition, the expression PoWD management mechanism means the concrete implementation of any management model, regardless of the type of architecture adopted. A PoWD management mechanism, as defined above, can? predict or not the presence of one or more? orchestrator systems. In the remainder of this document, for the sole purpose of brevity? exhibition, the expression PoWD-Manager indicates a PoWD management system that performs one or more? orchestration functions within a management mechanism.

Examples of operation of the PoWD-Manager are illustrated, purely by way of example and without constituting any limitation to the scope of protection claimed, in the following points D, E, F and G of this list and in Figure 3 (the details of which are described in Page 35 in the Section "Brief description of the drawings"). D. Functionality? basic features offered by the PoWD-Manager. The orchestration functions of the PoWD-Manager include:

? the creation and status modifications of the PoWD by the actors of the process;

? activity tracking and management? of the process, including the actions that the actors in the process have not implemented upon expiry of predetermined terms and/or conditions (see point 6 of the list starting on Page 15); ? the sending to the actors of the process of alerts and notifications related to the activities? referred to in the previous bullets, also with the use of communication systems capable of certifying the certain date (for example, certified electronic mail, PEC).

Such features? they can be made available both to human users (for example, through web graphical interfaces, apps for mobile devices, etc.) and as services that can be called from external systems (for example, through web Services).

E. PoWD Management System (PoWD-Manager).

Regardless of the form and hosting architecture adopted for the PoWD (see points 1, 2 and 4 of the list starting on Page 15), the management system (PoWD-Manager) can? reside on the same infrastructure or on a separate infrastructure equipped with suitable connectors and content access protocols (see the following point F of this list) and can be implemented with centralized or distributed architecture. To obtain adequate scalability requirements? of the system, especially where the functionality? of PoWD management are provided as a service (see the following point G of this list), pu? be advantageous to provide these services in mode? cloud computing, for example by implementing the PoWD-Manager on a PaaS type infrastructure.

F. Content Management. The features? CD. of content management (storage, search, subscription of documents, management of document classes, etc.) can be provided by the PoWD-Manager, can be implemented by calling CRUD procedures offered by a DBMS or can be delegated to a CMS or other solution analogous.

G. Additional features? offered by the PoWD-Manager. The features? services offered by the PoWD-Manager may include, in addition to the basic ones (see point D of this list above), identification services, profiling, user authentication (human and/or other systems), management services and of content preservation, monitoring and business intelligence services, etc., as well as? the connection to the devices mentioned in the following point H of this list.

Such features? they can be made available both to human users (for example, through web graphical interfaces, apps for mobile devices, etc.) and as services that can be called from external systems (for example, through web Services).

H. PoWD Status Change. Operationally, changing the status of the PoWD pu? to come:

? manually, i.e. as a result of actions performed by a human operator through a graphical interface provided on a client device, fixed or mobile, through a custom application, a web interface, an app installed on a tablet or smartphone, etc.;

? semi-automatically, as a result of actions performed by a human operator by means of a device, typically (but not necessarily) mobile, which does not require interaction with a graphical interface. For example, the customer can use a device equipped with a scanning sensor for reading linear barcodes (linear barcode) and/or two-dimensional (matrix barcode) to register the packages (and/or other primary and secondary packaging, such as pallets) delivered by the vector;

? automatically, i.e. as a result of actions performed exclusively by non-human devices (for example using IoT technologies).

I. Supply Administrative Ecosystem. The mechanism of referencing and incorporating content, implemented in the PoWD (see point 5 of the list starting on Page 15), also through the PoWD-Manager (see the previous points C, E, F, and G of this list), creates an ecosystem, of which the PoWD constitutes the link, which makes it possible to connect all the documents produced in the various phases of the procurement process (for example, the tender notice, the contract, the sureties, the orders of purchase, invoices, payment orders, etc.) and, therefore, to reconstruct the entire chain of contents and documents referring to each supply, regardless of the cardinality of the relationships between them and between them and the PoWD, as already? highlighted in the second bullet of point b) of the list starting on Page 11 and as shown in the second bullet of point b) of the list starting on Page 28 in the following Section "Detailed description of a preferred embodiment". Merely by way of example, in Figure 4 (the details of which are described on Page 37 in the Section "Brief description of the drawings") ? represented a supply chain model, which includes the phases of signing the contract, ordering goods and/or services, executing the supply and invoicing (see the list of the phases of the procurement process on Page 1 in the Section " State of the art"), in which the sets of documents incorporated and/or connected to each PoWD (directly or indirectly, exclusively or shared) constitute as many ecosystems of the supply process.

Detailed description of a preferred embodiment The features and advantages of the invention as well as the possible implementations will become more evident in the light of the detailed description of a preferred, but not exclusive, embodiment of application of the present invention to a typical B2B and B2G sale process of goods analogous to the one described on Page 4 in the Section " State of the art", illustrated by way of non-limiting example, in which:

? the PoWD? realized in the form of the electronic DDT on which the various states corresponding to the various progress steps of the process are annotated. The use of this form has the advantage of not requiring an abstraction effort from the users, as the DDT ? an object of common use in the current state of the art for the realization of the PoD (see Page 4 in the Section "State of the art");

? the PoWD management mechanism ? achieved with the presence of a PoWD-Manager (see points C, E, F and G of the list starting on Page 19 in the Section "Presentation of the invention"). The process of the transfer of goods, with reference to the execution phase (see Pages 1 and following in the Section "State of the art"), takes place as described below with the help of Figure 5 (the details of which are described below Page 38 in the Section "Brief description of the drawings"), in which ? illustrated the process as a whole, and of Figure 6, of Figure 7 and of Figure 8 (the details of which are described, respectively, on Pages 40, 41 and 42 in the Section "Brief description of the drawings"), in which are shown, distinctly for each step, the interactions between the various players through the PoWD-Manager and the corresponding certificates affixed to the DDT.

Step 1. Shipping (see Figure 6)

In the face, for example, of one or more? purchase orders received, the supplier of the goods or the subject who takes care of the logistics (for example, a 3PL) proceeds with the packaging of the goods, prepares the shipment and entrusts the packages (and/or other primary and secondary packaging, for example pallets) to the delivery carrier. The corresponding electronic DDT (produced by the supplier of the goods or by the 3PL) ? made available, through the PoWD-Manager, both to the carrier in charge of the transport and to the customer receiving the goods, who, therefore, ? informed, in real time, that the goods have been shipped.

The PoWD assumes the status of "GOODS SHIPPED".

Step 2. Delivery (see Figure 7)

Upon delivery of the goods, the customer (or a person appointed by him) checks that all the packages (and/or other packaging) that make up the supply have been received.

The count of packages (and / or other packaging) can? be carried out, for example, by means of an optical scanning device - which can? also be a smartphone (or similar device) connected to the mobile network, on which ? a special app is installed - which reads the barcode printed on the external surface of each package (see point H of the list starting on Page 19 in the Section "Presentation of the invention").

The system that manages the optical reader (which can be the PoWD-Manager or a separate system) updates the electronic DDT with the results of the check (for example, it certifies that all the labels of the packages and/or other packages that make up the supply, uniquely identified, are scanned).

The PoWD assumes the status of "GOODS DELIVERED" or other status deriving from the result of the acknowledgment.

Status update? made available, through the PoWD-Manager, both to the carrier and to the supplier and/or to the 3PL, which, therefore, ? informed in real time of the delivery result.

Step 3. Check (see Figure 8)

At the same time or after delivery, the customer (or a person appointed by them), opens the packages (and/or other packaging), checks that the goods contained therein correspond to what has been established and updates the electronic DDT with the results of the verification.

The PoWD assumes the status of "VERIFIED GOODS" or other status resulting from the result of the verification.

Status update? made available, through the PoWD-Manager, to the supplier (and/or to the 3PL), who, therefore, ? informed in real time of the outcome of the verification and pu? issue the relative invoice (or invoices), which corresponds to a certain commercial credit.

The detailed description of a preferred embodiment now disclosed clearly shows that (see the list starting on Page 11 in the Section "Presentation of the Invention"):

a) the PoWD certifies, validly and with a certain time indication, not only the shipment of the goods (or the execution of the service) and the receipt of the goods and/or services, but also the outcome of the checks carried out by the customer and/or by the other actors in the process;

b) furthermore:

? the PoWD makes it possible to trace - in real time - the progress of the supply and to make this information available both to the actors in the process and to the other stakeholders, duly profiled;

? the relationship between the PoWD and other documents produced in the procurement process (for example, purchase orders and invoices) ? type many to many - that is, a PoWD pu? be produced against one or more? purchase orders (and vice versa), against a PoWD can one or more be issued? invoices (and vice versa), and so? via, regardless of the sequence and/or the emission time. Therefore, the administrative ecosystem of the supply described in point I of the list starting on Page 19 in the Section "Presentation of the invention" is created;

? the process described ? repeatable n times and aggregable, it follows that the illustrated method allows you to manage deliveries made by one or more? suppliers to one or more customers in one or more tranche, also through one or more? intermediaries.

The illustrated process can easily adapt both to other types of sales of goods (for example, the purchase at the supplier's headquarters), and to the provision of services. Therefore, the detailed description of a preferred embodiment disclosed above is to be understood merely as an absolutely non-limiting example.

From what has been described it is clear that the instrument according to the invention achieves the pre-established purposes.

The object of the invention ? susceptible to numerous modifications and variations, all falling within the inventive concept expressed in the attached claims. All the details can be replaced by other technically equivalent elements, and the implementing solutions can be different according to the needs, without departing from the scope of protection of the present invention.

Even if the object ? been described with particular reference to the accompanying figures, the reference numbers used in the description and in the claims are used to improve understanding of the invention and do not constitute any limitation to the claimed scope of protection.

Brief description of the drawings

The accompanying drawings are described below.

All diagrams contained in the drawings are represented using the following notations:

? UML (Unified Modeling Language);

? BPMN (Business Process Modeling Notation).

For the correct interpretation of the notation used and of the graphic symbols contained therein, reference is therefore made to the rules defined in the aforementioned international standards.

Figure 1 consists of:

? a free-form graphic illustration;

? a diagram represented in BPMN notation.

Below is the legend of the elements present.

> Actor 1: Client, represents the customer of the supply.

> Actor 2: Provider, represents the supplier of the goods.

> Actor 3: 3PL (Third Party Logistic Service Provider), represents the supplier of integrated logistics services that operates on behalf of the Provider.

> Actor 4: Carrier, represents the carrier performing the delivery. > Document A: Order, represents the purchase order.

> Document B: Delivery Note, represents the transport document (DDT).

> Countersigned Document B: Countersigned Delivery Note, represents the transport document (DDT) countersigned by the customer "for receipt".

> Type 1 flow: Document Flow, represents a flow of documents. > Type 2 flow: Goods and Document flow, represents a flow of documents and goods.

> Activity 1: "Send purchase order".

> Activity 2: "Place the order".

> Activity 3: "Arranges the shipment with DDT in two copies".

> Activity 4: "Deliver the goods".

> Activity 5: "Receive the goods".

> Activity 6: "Countersign a copy of the DDT".

> Activity 7: "Return the DDT countersigned by the customer".

In the figure ? shown the simplified model of a typical B2B and B2G assignment process:

the. the supplier of goods (Actor 2) receives a purchase order (Document A) from the customer (Actor 1) and issues the relative instructions to his logistics services manager or 3PL (Actor 3); ii. the 3PL (Actor 3) prepares the delivery, issues the DDT (Document B) in double copy and entrusts the goods to his own carrier (Actor 4); iii. the carrier (Actor 4) arranges for the delivery by asking the customer (Actor 1) to issue a copy of the DDT countersigned "for receipt" (Countersigned Document B), which constitutes the PoD;

iv. according to practice or what has been established between the parties, the countersigned copy of the DDT (Countersigned Document B) ? retained by the carrier (Actor 4) or revert to 3PL (Actor 3). It is rarely delivered to the supplier of the goods (Actor 2), unless the latter makes a timely request.

Figure 2 consists of a diagram represented in UML notation.

Below is the legend of the classes represented.

> Class 1: PoWD, represents PoWD.

> Class 2: Component, represents a component of the PoWD.

> Class 3: Element, represents an element of a Component. > Class 4: Container (abstract class), represents a generic class of type container.

> Class 5: Dataset, represents a structured set of data.

> Class 6: Structured_IT_Document, represents a structured IT document, i.e. a document in digital format containing processable data.

> Class 7: Document (abstract class), represents a generic document, indifferently in digital or non-digital (analog) format.

> Class 8: IT_Document, represents an IT document, i.e. a document in digital format.

> Class 9: Paper_Document, represents an analogue document, i.e. a document in non-digital format (normally, in paper format).

In the figure ? An example of PoWD conceptual architecture is shown, the characteristics of which are shown in the following list.

I. PoWD (Class 1) ? made up of one or more components (Class 2), which are containers (Class 4) made up of structured sets of data (Class 5) or structured IT documents (Class 6), i.e. IT documents (Class 8) containing processable data. In particular, if the PoWD ? in the form of simple computer content (see the notion of "simple computer content" on Page 8 in the Section "Presentation of the invention"), ? consists of a single component that pu? same PoWD coincide.

II. A component (Class 2) pu? aggregate (logically or physically) other components. The aggregation mechanism allows to realize the PoWD in the form of complex computer content (see the notion of "complex computer content" on Page 8 in the Section "Presentation of the invention").

III. Each component (Class 2) ? formed by more elements (Class 3), which describe the details of the supply, the results of deliveries and compliance checks? goods and/or services, etc.

IV. An element (Class 3) can? contain other elements.

V. Each element can? be associated (ie, can? contain the reference) to one or more? documents (Class 7), which can be in digital (Class 8) or analog (Class 9) format. For example: or an element can? report the identifiers of both analogue and digital documents (Class 7), issued, for example, in other phases of the procurement process, such as purchase orders, invoices, contracts, sureties, etc.;

or an element pu? report the link to digital documents (Class 8) residing on the same or on other systems, issued, for example, in other stages of the procurement process, such as electronic purchase orders, electronic invoices, electronic contracts, etc., which can also be components (Class 2) of PoWD (see point I above of this list).

YOU. Each element can contain (that is, can? embed) as attachments one or more? digital documents (Class 8), issued, for example, in other stages of the procurement process, such as electronic purchase orders, electronic invoices, electronic contracts, etc. The illustrated model has a purely explanatory value, it does not represent the totality of the possible implementations of the present invention and ? susceptible to numerous modifications and variations, all falling within the inventive concept disclosed in the present document.

Figure 3 consists of a diagram represented in UML notation.

Below is the legend of the elements present.

> System B: represents the PoWD-Manager.

> Actor type 1: Participant, represents a generic actor who takes part in the process of supplying goods and/or services.

> Actor 1: Client, represents the customer of the supply of goods and/or services.

> Actor 2: Provider, represents the supplier of goods and/or services. > Actor 3: Provider Delegate, represents a delegate of the Provider, for example ? an integrated logistics service provider (Third Party Logistic Service Provider, 3PL) or an outsourcer responsible for providing the services.

> Actor 4: Performer, does he represent the subject who physically delivers the goods and/or provides the service to the customer, for example ? a carrier (Carrier) or a contractor.

> Actor 5: Generic Participant, represents any actor other than the previous ones who takes part in the process of supplying goods and/or services, for example ? the recipient of the supply when he does not coincide with the customer.

> Actor type 2: Stakeholder, represents a generic subject, who does not take part in the supply process, to which ? granted access to the system.

> Actor 6: Credit Assignee, represents an assignee and commercial credits deriving from the supply of goods and/or services, for example ? a factor or another financial intermediary to whom? trade credit has been transferred.

> Actor 7: Successor in Title, represents an assignee other than the assignee of the credit, for example a backer, a guarantor or another person who has given guarantees related to the supply. > Use_Case A: "Create PoWD".

> Use_Case B: "Update PoWD".

> Use_Case C: "Query PoWD".

> Use_Case D: "PoWD Signature".

> Use_Case E: "Login Profile".

> Use_Case F: "Check PoWD status".

> Use_Case G: "Find linked documents" (linked documents are, for example, purchase orders, invoices, contracts, sureties, etc.).

In the figure ? shown, in the form of use cases, purely by way of example and without constituting any limitation to the claimed scope of protection, an example of the functionalities? which can be made available by the PoWD-Manager.

Figure 4 consists of a free-form graphical illustration.

Below is the legend of the elements present.

> Phase C: Agreement, represents the phase of signing the contract.

> Phase D: Ordering, represents the phase of ordering goods and/or services.

> Phase E: Fulfillment, represents the phase of the execution of the supply.

> Phase F: Billing, represents the billing phase.

> Actor Type 1: Client, represents a client type actor.

> Actor Type 2: Provider, represents a supplier-type process actor of goods and/or services.

> Document Type 1: Agreement, represents a contract-type document.

> Document Type 2: Order, represents a document of the purchase order type for goods and/or services.

> Document Type 3: Invoice, represents an invoice-type document

> System Type A: PoWD, represents the PoWD.

In the figure ? shown, purely by way of example and without constituting any limitation to the scope of protection claimed, a model of the supply chain, which includes the stages of signing the contract, ordering goods and/or services, executing the supply and invoicing, in which the sets of contents incorporated and/or connected to each PoWD (directly or indirectly, exclusively or shared) constitute as many ecosystems of the supply process.

Figure 5 consists of:

? a diagram represented with BPMN notation;

? a diagram represented in UML notation.

Below is the legend of the elements present.

> Actor 1: Client, represents the customer of the supply.

> Actor 2: Provider, represents the supplier of the goods.

> Actor 3: 3PL (Third Party Logistic Service Provider), represents the supplier of integrated logistics services that operates on behalf of the Provider.

> Actor 4: Carrier, represents the carrier performing the delivery. > Step 1: "Shipping".

> Step 2: "Delivery".

> Step 3: "Verify".

> Activity 1: "Prepares the shipment and generates the PoWD".

> Activity 2: "Transport the goods".

> Activity 3: "Receives the goods and updates the PoWD with the delivery receipt".

> Activity 4: "Check the goods and update the PoWD with the certificate of conformity?".

> System A: PoWD.

> Status 1: "Goods shipped".

> Status 2: "Goods delivered".

> Status 3: "Goods verified".

In the figure ? illustrated the preferred embodiment of the present invention described in the Section "Detailed Description of a Preferred Embodiment Example" (Pages 25 and following). Particularly:

? in the first diagram (the BPMN notation), the three process steps (Shipping, Delivery and Verification) described in the preferred embodiment of the present invention are formally described;

? in the second diagram (in UML notation), the states in which the PoWD finds itself in the three process steps (Shipping, Delivery and Verification) described in the preferred embodiment of the present invention are highlighted. The UML diagram ? enriched with free-form graphic illustrations that show, in a simplified form, how PoWD can be represented in the form of the electronic DDT on which the various states corresponding to the various progress steps of the process are annotated. The use of this form has the advantage of not requiring an abstraction effort from the users, as the DDT ? an object of common use in the current state of the art for the realization of the PoD (see Page 4 in the Section "State of the art").

Figure 6 consists of a free-form graphical illustration.

Below is the legend of the elements present.

> Step 1: "Shipping".

> Actor 1: Client, represents the customer of the supply.

> Actor 2: Provider, represents the supplier of the goods.

> Actor 3: 3PL (Third Party Logistic Service Provider), represents the supplier of integrated logistics services that operates on behalf of the Provider.

> Actor 4: Carrier, represents the carrier performing the delivery. > System A: PoWD, in the form of the electronic DDT.

> System B: PoWD Manager.

> Information flow 1: Message of Creation, represents the PoWD creation notification flow.

> Object 1: Package, represents the packaging containing the goods.

The Figure shows the interactions between the various players, carried out using the PoWD-Manager, and the corresponding certificates placed on the electronic DDT (which constitutes the form assumed by the PoWD) with reference to Step 1 (Shipping), of the process used to describe the preferred embodiment of the present invention, illustrated on Page 26 in the Section "Detailed Description of a Preferred Embodiment Example".

Figure 7 consists of a free-form graphical illustration.

Below is the legend of the elements present.

> Step 2: "Delivery".

> Actor 1: Client, represents the customer of the supply.

> Actor 2: Provider, represents the supplier of the goods.

> Actor 3: 3PL (Third Party Logistic Service Provider), represents the supplier of integrated logistics services that operates on behalf of the Provider.

> Actor 4: Carrier, represents the carrier performing the delivery. > System A: PoWD, in the form of the electronic DDT.

> System B: PoWD Manager.

> Information flow 2: Message of Update, represents a PoWD update notification flow.

> Object 1: Package, represents a packaging (primary and/or secondary) containing the goods.

> Device 1: Optical Reader, represents a device equipped with a scanning sensor for reading linear barcodes and/or two-dimensional (matrix barcodes);

> Label 1: Barcode, represents a label affixed to the packaging containing the goods, on which ? the identification barcode of the packaging itself and of the respective PoWD is reported.

The Figure shows the interactions between the various players, carried out using the PoWD-Manager, and the corresponding certificates placed on the electronic DDT (which constitutes the form assumed by the PoWD) with reference to Step 2 (Delivery) of the process used to describe the form embodiment of the present invention, illustrated on Page 27 in the Section "Detailed Description of a Preferred Embodiment Example".

Figure 8 consists of a free-form graphical illustration.

Below is the legend of the elements present.

> Step 3: "Verify".

> Actor 1: Client, represents the customer of the supply.

> Actor 2: Provider, represents the supplier of the goods.

> Actor 3: 3PL (Third Party Logistic Service Provider), represents the supplier of integrated logistics services that operates on behalf of the Provider.

> Actor 4: Carrier, represents the carrier performing the delivery. > System A: PoWD, in the form of the electronic DDT.

> System B: PoWD Manager.

> Information flow 2: Message of Update, represents a PoWD update notification flow.

> Object 2: Open Package, represents an open packaging (primary and/or secondary) to allow verification of the goods.

The Figure shows the interactions between the various actors, carried out using the PoWD-Manager, and the corresponding certifications placed on the electronic DDT (which constitutes the form assumed by the PoWD) with reference to Step 3 (Verification) of the process used to describe the form embodiment of the present invention, illustrated on Page 28 in the Section "Detailed Description of a Preferred Embodiment Example".

Claims (13)

CLAIMS of the invention having the TITLE: "Method and system for certifying the delivery/supply and conformity of goods and services (evolved PoD or PoWD)" 1. Method and integrated management system of the executive phases of the process of sale of goods and/or provision of services in the B2B, B2G and B2C fields, to validly document compliance? of supplies, consisting of: > a data schema for representing the supply and the relative execution process, containing the description: ? of the goods and/or services that make up each supply, ? of the actors who take part in the execution, receipt and verification of said provision and the data operations permitted to each of said actors, ? elements that allow further actors, who do not take part in the execution of the supply, read access to the data, ? references to documents produced in the stages of the supply process other than the execution ones, necessary to verify compliance? of the goods sold and/or services provided with respect to the agreements between the parties, the correct execution of the orders and the accuracy of the payment request, characterized by the fact that each instance of said data schema aggregates a pi? data sets, even nested, divided into one or more? data structures, even nested, each of which includes zero or more? computer documents and/or contains references to zero or more? analogue documents; > a management information system, which implements: ? the functions for creating, storing, searching, reading, updating and signing with electronic signature of the instances of said data schema, ? the functions of automatic updating of information on the progress of the execution of the supply as well as? of notification in the event that the actors do not carry out the foreseen operations upon expiry of predetermined terms and/or conditions, ? the functions for the identification, authentication and profiling of users and systems and devices enabled to operate on behalf of the actors who take part in the execution, receipt and verification of the supply as well as of the additional actors, who do not take part in the execution of the supply, to which pu? be allowed read access to the data, ? the functions for the certification of conformity? of the supply with respect to the agreements between the parties, the correct execution of the orders and the accuracy of the request for payment, by accessing or linking to documents produced in the phases of the supply process other than those of execution, ? the automatic reconstruction and representation functions of the entire document chain referring to each supply, including the phases other than the execution one, regardless of the cardinality? the relationships between instances of such data schemas and other documents, including contracts, orders, invoices, money orders, sureties, characterized by the fact that the data storage technique consists in allocating said data structures as self-consistent elements connected to one or more? of the instances of said schema d? data, of said actors and of said documents produced in the stages of the supply process other than the execution ones; one or more IT interaction systems and/or devices, in use by each actor, which implement: ? the functions for interacting with said management information system to perform the operations of creating, storing, searching, reading, updating and signing with electronic signature of the instances of said data schema, ? the functions to enable one or more? users who operate on behalf of the actor in the use of said systems and/or IT interaction devices with distinct profiles and roles, characterized by the fact that each of said systems and/or IT interaction devices in use by each actor automatically stores the instances of said data schema whose actor ? recipient. Said integrated management method and system includes: > a supply delivery phase, characterized by the fact that: ? the actor who delivers the supply, through said IT systems and/or interaction devices in use at himself, creates and stores on said IT management system an instance of said data scheme, which uniquely identifies the supply and includes the data structures containing the general information of the supply and those referring to the phase in progress (delivery phase), ? said management information system automatically pre-compiles the data structures containing the information that will be used in the subsequent phases, ? said management information system notifies the actors who will take part in the subsequent stages of the supply of the successful creation of said instance of the data schema, ? said IT interaction systems and devices, in use by the players who will take part in the successive stages of the supply, automatically memorize the instance of said data scheme; > one or more stages of receipt of goods and/or services, characterized by the fact that: ? the actor who receives the goods and/or services selects the instance of said data schema corresponding to the supply received, uniquely identified in said delivery phase, among those already stored on said systems and/or computer interaction devices in use at the same time, ? Does the actor who receives the goods and/or services certify the receipt of the supply, through said IT systems and/or interaction devices in use at the yes, by confirming or modifying the pre-compiled information in this delivery phase, ? said IT management system notifies the actors who took part in the previous phases and those who will take part in the subsequent phases of the supply of the successful receipt of the goods and/or services, ? said IT interaction systems and/or devices, in use by the actors who will take part in the successive phases of the supply, automatically memorize the instance of said data schema updated in said reception phases; > one or more phases of verification of goods and/or services, characterized by the fact that: ? the actor who verifies the goods and/or services selects the instance of said data schema corresponding to the supply to be verified among those already memorized on said systems and/or IT interaction devices in use at the same?, ? the actor who verifies the goods and/or services certifies the correctness of the supply, by means of said systems and/or computer interaction devices in use at himself, confirming or modifying the information pre-compiled in the said delivery phase and updated in the said phases of receipt and in the previous verification phases, ? said IT management system notifies the actors who took part in the previous phases and those who will take part in the subsequent phases of the supply of the receipt of the goods and/or services, ? said IT interaction systems and/or devices, in use by the actors who will take part in the successive phases of the supply, automatically memorize the instance of said data schema updated in said reception phases and said verification phases; > the update, in each of these phases of delivery, reception and verification, of the data of certification of conformity? of the supply with respect to the agreements between the parties, the correct execution of the orders and the accuracy of the payment request, by accessing or linking to documents produced in the phases of the supply process other than the execution ones. 2. Method and system according to claim 1, characterized in that said data schema comprises one or more? IT contents, also in the form of electronic documents, which contain the IT representation of deeds, facts or data relevant to the process of sale of goods and/or provision of services, also in the form of an IT file, i.e. the set of deeds, of the documents and data of the same process formed by anyone. 3. Method and system according to claims 2, characterized in that said computer contents comprise structured electronic documents, ie electronic documents whose information contained therein can be processed automatically by computer programs. 4. Method and system according to claims 2 or 3, characterized in that said structured electronic documents include the documents described in the UBL standard or similar frameworks. 5. Method and system according to any one of the preceding claims, characterized in that the components of the instances of said data schema reside, jointly or separately, on the computer system of one or more? of one of the actors who take part in the execution, reception and verification of said supply and / or in the computer system of a third party or more? dune. 6. Method and system according to any one of the preceding claims, characterized in that the instances of said data schemas are sworn by electronic subscription or other IT process which allows the subscriber to be associated with the data, including the simple signature, the advanced signature, the qualified signature, the digital signature, the digital seal, the biometric signature. 7. Method and system according to any one of the preceding claims, characterized in that the operations performed on the instances of said data schemas and the notifications issued by said computerized management system are sworn by means of computerized time stamping or other system capable of certifying a certain date, 8. Method and system according to any one of the preceding claims, characterized in that said data schema and the relative instances are called, respectively, PoWD and instance d? PoWD and that said management information system ? called PoWD-Manager. 9. Method and system according to any one of the preceding claims, characterized in that the interaction between said management information system and the actors who take part in the execution, receipt and verification of the supply as well as? of the additional actors, who do not take part in the execution of the supply, to which pu? read access to data is allowed via fixed or mobile devices, including smartphones, tablets and similar devices. 10. Method and system according to claim 9, characterized in that the interaction between said computerized management system and the actors who take part in the execution, receipt and verification of the supply as well as? of the additional actors, who do not take part in the execution of the supply, to which pu? be allowed access to read the data occurs as a result of the action carried out by human operators, in modality? semi-automatic or automatic. 11. Method according to claims 9 and 10, characterized in that the interaction between said computerized management system and the actors who take part in the execution, receipt and verification of the supply as well as of the additional actors, who do not take part in the execution of the supply, to which pu? data reading access is allowed through devices equipped with sensors, including optical readers, scanning systems for reading linear barcodes and/or two-dimensional (matrix barcodes) and/or IoT devices. 12. Method and system according to any one of the preceding claims, characterized in that the instances of said data schema and the elements of the related supply are uniquely associated by means of labels, linear barcodes and/or two-dimensional (matrix barcodes ) and/or IoT devices affixed to the goods, to the respective packaging or to the documents representing the goods and services to be supplied. 13. Method and system according to any one of the preceding claims, characterized in that the updating of the information on the progress of the execution of the supply takes place by means of detection, also by means of the devices and methods indicated in claims 9, 10, 11 and 12, carried out directly on the elements of the supply, uniquely identified, regardless of the sequence and/or the time in which the measurements take place.