WO2010040968A1 - Procede de gestion centralisee de chaines d'approvisionnement et de distribution de marchandises et systeme de mise en oeuvre dudit procede - Google Patents

Procede de gestion centralisee de chaines d'approvisionnement et de distribution de marchandises et systeme de mise en oeuvre dudit procede Download PDF

Info

Publication number
WO2010040968A1
WO2010040968A1 PCT/FR2009/051934 FR2009051934W WO2010040968A1 WO 2010040968 A1 WO2010040968 A1 WO 2010040968A1 FR 2009051934 W FR2009051934 W FR 2009051934W WO 2010040968 A1 WO2010040968 A1 WO 2010040968A1
Authority
WO
WIPO (PCT)
Prior art keywords
server
file
files
users
fields
Prior art date
Application number
PCT/FR2009/051934
Other languages
English (en)
Inventor
Frédéric TUSVELD
Original Assignee
Tusveld Frederic
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Tusveld Frederic filed Critical Tusveld Frederic
Publication of WO2010040968A1 publication Critical patent/WO2010040968A1/fr

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06Q—INFORMATION AND COMMUNICATION TECHNOLOGY [ICT] SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES; SYSTEMS OR METHODS SPECIALLY ADAPTED FOR ADMINISTRATIVE, COMMERCIAL, FINANCIAL, MANAGERIAL OR SUPERVISORY PURPOSES, NOT OTHERWISE PROVIDED FOR
    • G06Q10/00—Administration; Management
    • G06Q10/08—Logistics, e.g. warehousing, loading or distribution; Inventory or stock management
    • G06Q10/087—Inventory or stock management, e.g. order filling, procurement or balancing against orders

Definitions

  • the present invention relates to a method of centralized management of supply and goods distribution chains.
  • the field of the invention is that of the management of a supply and distribution chain of goods on the national and international level.
  • a supply and distribution chain is a set of methods used to produce, ship and sell goods and services on a national and international stage. These methods are used for better management of suppliers, manufacturers, stocks, modes of transport and especially buyers.
  • a good management of this chain allows an optimized production in order to deliver to the end customer the right product in the right quantities and in the expected delivery times.
  • the object of the invention is to provide in time to an entity goods, materials, supplies and / or services that are necessary for its operation, production or direct sale, under the best security conditions, cost and quality.
  • Another object of the invention is to authorize changes affecting documents in the supply and distribution chain of goods. These changes result in a real-time update of all the affected documents. These changes may include a change of delivery date.
  • Another object of the invention is to inform supply chain stakeholders, in real time, according to their type of authorization, of the course of the supply chain and of the distribution being run, by putting into practice evidence of the sequence of steps performed and their results.
  • This indication of the procedure makes it possible to determine the responsibility of all the parties involved in the event of a problem, such as late delivery, in order to identify the person to whom the penalty to pay lies.
  • the buyer creates and references in his computer management system a registration file corresponding to this commercial offer. Then, the delivery date is scheduled in the customer's management system and a purchase order is created. This purchase order is then sent to the manufacturer or the supplier by mail or fax or by mail.
  • a certificate or standard is a written document certifying that the goods conform to certain standards or that certain formalities have been completed.
  • the supplier or the manufacturer integrates the order form received into their IT management system. Then an invoice is generated according to this order form.
  • the supplier or the manufacturer sends the customer this invoice by mail or fax or by mail.
  • the customer entered in his computer management system the invoice received.
  • This delivery note is a document that provides detailed information on the goods to be delivered. It includes information on:
  • the forwarder / carrier entered in his computer management system the delivery slip received.
  • the forwarder / carrier routes the goods from the supplier or manufacturer to the customer.
  • documents are exchanged between the customer and the manufacturer or supplier and between the manufacturer or the supplier and the forwarder / carrier.
  • These exchanges are always done by mail or fax or by mail.
  • This current chain of supply and transport of goods has many disadvantages. Indeed, each stakeholder in this chain has its own computer management system distinct from the others, from the order to the delivery resulting in a lack of visibility throughout the chain. Thus, this supply and transport chain can not be controlled from end to end.
  • FIG. 1 shows an example of international routing of goods from three suppliers 10, 11 and 12 to three respective stores 17-19 of a customer.
  • each supplier 10, 11 and 12 is in collaboration with a respective forwarder 13, 14 and 15 to route the goods to a customer logistics site.
  • the customer Upon arrival at the customer's logistics site, the customer then handles the chartering of the goods received to the stores 17, 18 and 19.
  • the customer is in collaboration with a carrier for the chartering of the goods. to the corresponding store.
  • the invention is precisely to meet this expectation. To do this, the invention implements a single real-time shared computer management system accessible via the Internet to all stakeholders. The invention thus puts at the disposal of all stakeholders of the supply chain and distribution of the state of the art, a communication interface.
  • This interface allows the speakers to communicate directly without sending mails, faxes or letters. It also allows you to automatically manage physical operations, track goods and create documents necessary for managing the chain.
  • standardized documents relating to the supply and distribution chain are created and stored in a database. These documents may include purchase orders, an invoice, a delivery note, a certificate of compliance, a letter of credit ...
  • the invention comprises an algorithm able to organize the transmission of documents in a timely manner to the stakeholders concerned.
  • the algorithm of the invention is able to process the documents in order to detect missing elements, errors to transmit alerts to the concerned stakeholders.
  • the shared management system of the invention thus makes it possible to continuously know the results of activities of each participant. It also simplifies information channels between stakeholders.
  • the invention also includes a consolidation algorithm capable of pooling the flow of goods both nationally and internationally in order to reduce the number of carriers / freight forwarders, the delivery frequencies, the environmental impacts and the cost of the chain of delivery. supply and distribution.
  • Each document of the interface of the invention is associated with a bar row of a 2D barcode with the data in this document.
  • the 2D bar code is updated in real time with each change of documents and depending on the physical operations performed.
  • the real-time monitoring of the supply and distribution chain of the invention is done using the 2D bar code.
  • the invention makes it possible to manage in a centralized manner and in real time a database via the implementation of a common and shared communication interface to all the parties involved. Then, the invention also implements an algorithm for simplifying the use of this communication interface.
  • the invention certainly makes it possible in the end to solve an administrative problem that is secondary but it mainly allows the establishment of a shared communication interface, easy to use and transparent to stakeholders.
  • the subject of the invention is therefore a centralized management method of supply and product distribution channels via a centralization server.
  • - Records are stored in a database (standardized for a supply chain and product distribution, said files comprising fields to be filled, characterized in that it comprises the following steps:
  • centralization server being configured to be a common communication interface accessible to authenticated users via the Internet
  • said centralization server is transmitted to the users via push technology and in a previously defined coordination order said files, said fields of the transmitted files being accessible according to a profile of access to the fields of the files assigned to said users,
  • a two-dimensional barcode associated with each file is created, one of whose rows of bars comprises modifiable data relating to the fields of said file,
  • the invention is also characterized in that the Two-dimensional bar code further comprises a row of fixed and unmodifiable bar.
  • the invention is also characterized in that the first row of bars comprises a one-dimensional bar code, preferably of the EAN type.
  • the invention is also characterized in that
  • the invention is also characterized in that when the information of the same field of the same file or different files are contradictory in a chain then an error alert is sent to the users, according to their access profiles.
  • the invention is also characterized in that the authentication of the user connecting to the server via a network comprises the following steps:
  • an authentication database is associated in a computer database with at least one identifier of the user
  • an authentication request for authentication data entry is generated and transmitted to an interface of the user
  • the invention is also characterized in that the server comprises an authentication request cache memory.
  • the invention is also characterized in that a mode of transmission from the server to the users is an RSS technology.
  • the invention is also characterized in that
  • the invention is also characterized in that - the alerts are associated with a response time
  • the invention also relates to a server comprising means capable of implementing the centralized supply chain and distribution management method of the invention.
  • Figure 1 shows a schematic representation of an architecture of supply and distribution chains of the state of the art.
  • Figure 2 shows a schematic representation of a client / server architecture provided with the improved means of the invention.
  • Figure 3 shows an illustration of means implementing the method of the invention.
  • Figure 4 shows a schematic representation of an example of 2D bar code.
  • Figure 5 shows a schematic representation of a supply chain and distribution architecture according to the invention.
  • Figures 6-8, 10-11 show examples of documents produced by the server of the invention.
  • Figure 9 shows an example of reading a 2D barcode.
  • Figure 2 shows a schematic representation of a client / server architecture provided with the improved means of the invention.
  • server 29 is meant an application implemented by a device connected to a telematic network.
  • the device implementing the centralization server 29 of the invention is of the computer type whether it is of the domestic, professional or hardened type in order to obtain a high quality of service.
  • Said device conventionally comprises a microprocessor 30, a program memory 32 and circuits 52 for connection to the telematic network.
  • the program memory 32 then comprises instruction codes corresponding to the server 29. These instruction codes are executed by the microprocessor 30 which is able to control at least the connection circuits to the telematic network.
  • the server 29 is able to process requests reaching it in the form of messages formatted according to a protocol via the network. Telematics.
  • the server 29 is therefore also able to produce response messages to requests received via the telematic network.
  • Typical server examples are servers:
  • client 21-28 is meant an application implemented by a device connected to the telematic network.
  • the device implementing the client is of the personal computer, mobile phone, personal assistant and more generally any device capable of connecting to a telematic network.
  • Such a device conventionally comprises a microprocessor and a program memory (not shown) comprising instruction codes corresponding to the implementation of the "client” application.
  • the best-known customers are Internet browsers and email clients that connect to "web” servers and mail servers, respectively.
  • Clientt any application capable of communicating with a server.
  • the centralization server 29 also includes a memory of Data 33.
  • the data memory 33, the program memory 32 and the microprocessor 30 are connected to a communication bus 31.
  • the program memory 32 is divided into several zones, each zone corresponding to a function or a mode of operation of the program of the server 29.
  • a zone 34 includes instruction codes for assigning an access profile to the secure authenticated users of the network 20.
  • the access profile of a user is a parameter specification, of the user's access type to the files and server documents 29.
  • the authentication of the network 20 is preferably performed according to authentication by identifier and / or password.
  • a database is created in which data intervening in the authentication of the users by the network 20 are stored.
  • each identifier / address of a user is associated with an identifier and / or by password.
  • This database can be installed in the server 29. It can also be external to the server 29. In this case, the server 29 produces authentication forms and sends them to an interface of the client's client station.
  • the server may include a cache memory.
  • This cache memory can store, for a given user, its authentication data from its first authentication validated by the server. At each new request transmission from the user to the server 29, the latter extracts the authentication data corresponding to this user directly from the cache memory. This makes it possible not to ask the user to authenticate each time he sends a request to the server 29.
  • a field 35 includes instruction codes for receiving posts 21-28 of the users a commercial offer file via the network 20.
  • a commercial offer file may be an offer for sale of goods issued by the manufacturer's post or by the position 26 of the suppliers.
  • a commercial offer file can also be a transport offer issued by freight forwarders or carriers, a banking product issued by the bank etc ....
  • a file is understood to be a record of a document of the form type comprising fields to be completed.
  • restriction criteria which describes, for each field to fill out forms of the files which has the right to read it and / or to modify it.
  • a zone 36 includes instruction codes to create a file
  • the file 100 product corresponding to the commercial offer file.
  • An example of a file 100 produced is shown in FIG. 6.
  • the file 100 produced may furthermore comprise fields of the commercial offer file, fields indicating:
  • a zone 37 includes instruction codes for transmitting via the network 20 the file 100 produced to the stations 21-28 of the users according to their access profile.
  • the transmission of the data from the server 29 to the stations 21-28 clients is, in a preferred embodiment, carried out via push technology.
  • Data transmission via this push technology allows the server 29 to provide the user or "push" to him, directly and automatically, the information programmed according to his access rights.
  • RSS refers to a family of XML (eXtended Markup Language) formats used for syndication of Web content (World Wide Web).
  • Syndication is the fact of rendering to users, in a standardized and contractual manner, all or part of the contents of the data memory of the server 29 according to their access rights. This syndication system allows the server 29 to broadcast updates of files whose content changes frequently.
  • An area 38 includes instruction codes for creating a first row 110 of bar of a two-dimensional bar code 107.
  • An example of a two-dimensional bar code 107 is shown in FIG.
  • This first bar row 110 is a one-dimensional bar code. This first bar row 110 is created when the server 29 receives from the network 20 a request for validation of the file 100 produced by a buyer authenticated by the network 20.
  • This bar 110 code 1 D is associated with the file 100 produced. This 1D bar code is not modifiable.
  • This bar code 1D is preferably of the EAN type for European Article Numbering in English. This 1D bar code includes data on the country of origin of the goods, the order number, the EAN code, the product reference, the type of goods, the type of packaging, the weight, on the volume, on the destination, on the dimensions of the goods ...
  • a zone 39 has instruction codes for creating a second bar row 101 of the two-dimensional bar code 107.
  • the data in this second row of bars 101 corresponds to the data of the file 100 produced.
  • This second row 101 of bar is updated each time the file produced is modified.
  • a field 40 includes instruction codes for creating a command file 102 corresponding to the file 100 produced.
  • An example of a file 102 command is shown in FIG. 8.
  • the file 102 command may furthermore comprise fields of the file 100 produced, fields giving the estimated dates:
  • a zone 41 includes instruction codes for transmitting via the network 20 the file 102 command users according to their access profiles.
  • An area 42 includes instruction codes for creating and associating a third row 103 of the bar with the control file 102.
  • An area 43 includes instruction codes for creating a bill file 104 corresponding to the file 102 command.
  • An example of a file 104 invoice is shown in Figure 10.
  • the invoice file may further include fields of the file 102 order, fields indicating the means and payment method, the coordinates of the bank of the seller and possibly those of the buyer, the payment term ...
  • a zone 44 includes instruction codes for transmitting via the network 20 the file 104 invoices users according to their access profiles.
  • a field 45 includes instruction codes for creating and associating a fourth row 105 of bar to the 104 bill file.
  • a zone 46 includes instruction codes for generating different coordination alerts transmitted via the network 20 to the user stations according to their access profiles. These coordination alerts are triggered by the server 29 when a field of a file is not filled.
  • These coordination alerts can be a highlight of the fields to be filled out or in particular: - a request, sent to the manufacturer or supplier, information of the start date of manufacture, the manufacturing environment and the end of manufacture of the goods, these dates are provided in anticipation. A confirmation request for these dates will be automatically generated when the forecast date expires. - a request for information of the number of certificate of conformity etc ....
  • a zone 47 includes instruction codes for generating error alerts when two identical fields in the same file or in different files are contradictory.
  • the instruction codes of the zone 47 transmit the generated error alert to the users according to their access profiles. These error alerts can include:
  • An area 48 has instruction codes for generating delivery alerts.
  • the zone 48 instruction codes transmit these delivery alerts to users according to their access profiles. These delivery alerts allow the server 29 to fill in the fields of the forms of the files according to the responses received.
  • a field 49 includes instruction codes to associate a response time with each alert, delivery, coordination or error. When the response time expires, the instruction codes in field 49 generate response delay alerts and transmit them to the corresponding users. The response time can be expressed in hours or days.
  • a delay alert can be a message of the type "attention, form not yet filled in ".
  • the alerts generated by the server 29 may be accompanied by a visual and / or audible signal.
  • a zone 51 includes instruction codes for mutualizing at least the same type of field of two files each belonging to a different supply chain, according to previously defined consolidation criteria.
  • a field 52 includes instruction codes to create a delivery file 106 corresponding to a delivery note.
  • An example of a delivery file 106 is shown in FIG. 11.
  • the delivery file 106 is associated with the two-dimensional bar code 107.
  • This two-dimensional barcode 107 groups all rows of bars, 1D bar code, product, invoice and order files.
  • This delivery file 106 with its associated two-dimensional bar code 107 accompanies the goods delivered. They provide the buyer with the exact detail of the history of the procurement and distribution process. This delivery file 106 can be printed and delivered by hand to the buyer. It can also be transmitted by the server 29 to the buyer. This document is to be signed by the receiver. This signature can be done on the paper document or via a touch screen.
  • a field 53 includes instruction codes for verifying a format of the data received from the users' workstations.
  • the instruction codes of the zone 53 transcode the data received from the user stations according to the format of the centralization server 29.
  • the instruction codes of the zone 53 also transcode the data to be sent by the server 29 to the user stations according to the format of said stations.
  • the format of the server 29 may be XML.
  • the user's item format can be a standardized format according to the EDI standard for Electronic Data Interchange.
  • the format of the user workstations can be a format according to the integrated management software package known as ERP for Enterprise Resource Planning.
  • the format of the posts of the users can also be a format of email, fax, SMS, MMS etc.
  • the server 29 of the invention can thus be used with systems existing IT management. With the invention, there is no need to change the current stock of computer management systems.
  • the centralization server 29 serves as a communication interface between the current computer management systems of the users.
  • An area 54 includes instruction codes for transforming data contained in a one-dimensional bar code into a bar row of the two-dimensional bar code.
  • the server 29 when the server 29 receives, for example from a user station via a barcode optical reader, a bar code 1D, it integrates it into the data string.
  • This integration into the data string is made by a transformation of the code 1D into a row of bars and by an incorporation of this row of bars in the 2D bar code.
  • the representation of the data memory 33 is only an illustration of implementation of components and data recording.
  • the data memory 33 generally comprises several databases 50 of data.
  • the data bases 50 of the data memory 33 are unified or distributed according to constraints of size and / or speed of the desired processes.
  • the data memory 33 makes it possible to register one or more subscriber user identifier / address idu to the services of the server 29.
  • This identifier / idu address allows the network to identify the user.
  • This identifier / idu address can be linked to an IP Internet address (Internet Protocol). It can also be linked to a phone number identifying the user who owns the phone. This latter identifier / idu address is used in the context of a communication via SMS or MMS short messages, for example.
  • This identifier / address idu is associated with a file access profile of the server 29.
  • the data memory 33 provides the server 29 with the profile of the user corresponding to the list of services to which the user is entitled and the rules associated with this user.
  • the data base 50 of the data memory 33 is, for example, structured into a table.
  • each row of the table corresponds to a user
  • each column of the table corresponds to information about this user.
  • the database 50 comprises a column 50a corresponding to an identifier / address idu of the user, a column 50b corresponding to the access profiles of the user to the services offered by the server 29, a column 50c corresponding to a file of a commercial offer, a 5Od column corresponding to a product file, a 50th column corresponding to a barcode of type EAN, a column 5Of corresponding to a command file, a column 50g corresponding to the rows of modifiable bars of the two-dimensional bar code and a column 5Oh corresponding to an invoice file.
  • the customs, the chamber of commerce and banks may be part of the users of the server 29.
  • the use of the interface of the invention by these stakeholders facilitates the transmission of data between users of said server.
  • the database 50 may further comprise a column 5Oi corresponding to a customs file, a column 5Oj corresponding to a chamber file and a column 50k corresponding to a bank file.
  • Customs files can be certificates, standards or administrative documents. These files are preferably updated directly by the customs.
  • the Chamber of Commerce files are documents relating to the regulations and formalities governing national or international trade. These files are preferably updated directly by the Chamber of Commerce.
  • the bank files are documents relating to banking operations such as a letter of credit. These files are preferably updated directly by the bank. Knowing an identifier id u makes it possible to extract from the table of the database 50 of data N lines, N being any integer.
  • FIG. 3 shows an illustration of steps corresponding to an implementation of the method according to the invention.
  • Fig. 3 shows a first preliminary step 60 in which the server 29 receives a commercial offer file via the network 20.
  • the server 29 stores this commercial offer file in the data memory 33.
  • the server 29 transmits this commercial offer to the user stations according to their previously defined access profiles. For example, when it is a transport offer issued by the carrier or the freight forwarder, the server 29 only transmits this offer to the users concerned. which include, the supplier and the manufacturer. Likewise, when the commercial offer is an offer to sell goods, the server 29 transmits it only to the buyer.
  • the server 29 receives from a buyer station a request for validation of an offer for the sale of goods.
  • the server 29 creates a product file 100 corresponding to this offer of sale and stores it in the data memory 33.
  • a first bar row corresponding to bar code EAN type 110 is created.
  • a second row of bars is created and associated with the produced file. This second row of bars contains the data contained in the product file.
  • Certification and standardization files are transmitted by the server 29 to the users according to their access profiles.
  • An example of a 110 certification file is shown in FIG. 7.
  • the certification file includes, inter alia, fields specifying:
  • the server 29 transmits the file 100 product created at the post 26 of the buyer who issued the validation request with a confirmation request. If the server 29 receives, at a step 65, in response to the confirmation request a reversal of the product file, then it stops at a step 66 the supply management procedure of the invention. In step 66, it may be envisaged that the server 29 deletes from the data memory 33 the file 100 produces the rows of bars of the 2D bar code as well as the associated certificate and standards files. If in step 65, the server 29 receives in response to the confirmation request, a validation of the file then produces the server 29 created in a step 67 a command file.
  • the confirmation or validation of the confirmation request is obtained by pressing a validation key of the buyer's keypad station or an area of the screen of said station, when the latter is touch.
  • the server 29 creates a third row of two-dimensional bar code. This third row of bar code includes the data relating to the command file.
  • the server 29 transmits the command file created at the position 26 of the buyer with a confirmation request. If the server 29 receives, in a step 69, in response to the confirmation request a reversal of the file control, then it stops at a step 70 the supply management procedure of the invention. In step 70, it may be envisaged that the server 29 deletes from the data memory 33 the file 100 produced, the command file, the rows of bars of the 2D barcode as well as the associated certificates and standards files.
  • step 71 the server 29 receives in response to the confirmation request, a validation of the file then orders the server 29 transmits the order file to the supplier or manufacturer having issued the commercial offer of sale.
  • the supplier or the manufacturer fills in the fields of the form of the order file.
  • the server 29 receives a request for validation of the command file then it creates in a step 72 an invoice file according to the command file.
  • the server 29 creates a fourth row of bars of the two-dimensional bar code associated with this invoice file. This third bar row of the bar code includes the data relating to the invoice file.
  • the server 29 transmits the invoice file created at the supplier or manufacturer's station with a confirmation request. If the server 29 does not receive a response to the confirmation request, it sends, at a step 75, a delay alert to the supplier or the manufacturer. This delay alert can be sent at predefined time intervals.
  • the server 29 when three alerts are sent to the provider or the manufacturer, the server 29 retransmits the invoice file with the confirmation request.
  • a network administrator can contact by email or telephone or fax the supplier or the manufacturer for validation of the confirmation request.
  • the server 29 receives, in a step 76, in response to the confirmation request, a validation of the invoice file, then it transmits the invoice file to the buyer.
  • the server 29 generates coordination alerts and transmits them to the users according to their access profiles.
  • the responses to these coordination alerts allow the server 29 to fill in the fields of the forms of the files.
  • These coordination alerts interact with each other. These alerts are only generated when previous alerts are validated. For example, the alerts on the command file are generated only when all the alerts concerning the product file have received a response validated by the server 29.
  • the server 29 constantly checks the information contained in the fields of the file forms. In the case of conflicting data for the same information of a field in different files or in the same file, then the server 29 generates, in a step 78, an error alert and transmits it to the users according to their access profiles. . These error alerts allow the server 29 to harmonize the information of the fields of the file forms.
  • the server 29 receives from the manufacturer or the supplier an end of manufacturing validation request, at a step 79. Following step 79, the server 29 sends, at a step 80, delivery alerts to the users according to their profiles. 'access. These delivery alerts can be used to sequentially organize the delivery of the goods from a storage site from the supplier or manufacturer to the buyer. These delivery alerts enable the server 29 to fill in the delivery fields of the file forms according to the responses received.
  • the server 29 pools the merchandise flows by grouping at least two same types of fields of two files of two separate supply and distribution chains. These fields can be in different file types. This pooling is done according to previously defined consolidation criteria.
  • a consolidation criterion may be the delivery zone, the delivery date, the carrier, the freight forwarder, the volume of the goods, the weight of the goods, the nature of the goods, and / or the surcharge to be paid, etc.
  • the shared fields are those of the command files.
  • step 82 the server 29 creates a delivery file corresponding to a delivery note. This file is then transmitted to users according to their profiles. This delivery file accompanying the goods can be supplied in paper version. This delivery file is associated with the two-dimensional bar code grouping all the information of the rows of bars already created.
  • corrdination and delivery alerts are generated to populate the fields. These alerts are generated in a specific order previously defined.
  • the server file fields 29 can be modified by authorized users according to their needs. Any changes to these files will update all the files associated with the user ID / address and the 2D barcode. For example, when the carrier changes the delivery date, all files with a delivery date field are changed accordingly along with the 2D barcode.
  • Each secure authenticated user may, according to his access profiles, access a memory space 33 of data memory including the history of all the files associated with his identifier / address. This memory space is only viewable.
  • FIG 4 shows a shematic representation of the two-dimensional bar code 107.
  • This two-dimensional bar code 107 has several rows of stacked bars. It comprises a first bar row 110 which is the non-modifiable fixed part of the two-dimensional bar code 120. This first row has the code 110 one-dimensional bar type EAN. The other rows of bars form the modifiable part of the 107 bar code two-dimensional and searchable in real time.
  • This two-dimensional bar code 107 may further comprise a web address (URL) referring to the file 100 product, as shown in Figure 9.
  • URL web address
  • Fig. 9 shows a two-dimensional bar code reading means.
  • the reading means is a mobile phone 108. It can also be any other device comprising a two-dimensional bar code reading optical reader.
  • a camera of the mobile phone 108 scans the code 107.
  • the phone 108 includes software able to interpret it to read its contents. If the code includes a web address (URL), a request to open a link can be proposed. By opening the link, the user can directly view the files 109 of the server 29 according to his access profile.
  • URL web address
  • Figure 5 shows a schematic representation of the application of the supply and distribution system of the invention to the example of Figure 1.
  • the example of Figure 5 shows three distinct supply chains. Each supply chain corresponding to a sale of goods from one of the 10-12 suppliers.
  • fields of the three command files of the three suppliers 10-12 are pooled according to consolidation criteria which are: the delivery time, the weight and the volume of the goods, the place of delivery .
  • a single forwarder is used to transport the goods corresponding to the order form.
  • a single shipper is used to transport the goods from the logistics location of the customer to stores 17-19. The invention thus considerably reduces the number of transport modes used, the travel times and the number of trips for deliveries. This reduction significantly reduces pollution, lost time and unnecessary expenses ...

Landscapes

  • Business, Economics & Management (AREA)
  • Engineering & Computer Science (AREA)
  • Economics (AREA)
  • Quality & Reliability (AREA)
  • Tourism & Hospitality (AREA)
  • Human Resources & Organizations (AREA)
  • Marketing (AREA)
  • Operations Research (AREA)
  • Development Economics (AREA)
  • Strategic Management (AREA)
  • Entrepreneurship & Innovation (AREA)
  • Physics & Mathematics (AREA)
  • General Business, Economics & Management (AREA)
  • General Physics & Mathematics (AREA)
  • Theoretical Computer Science (AREA)
  • Accounting & Taxation (AREA)
  • Finance (AREA)
  • Management, Administration, Business Operations System, And Electronic Commerce (AREA)

Abstract

L'invention a pour objet une interface (29) de gestion information partagée en temps réel et accessible via internet à tous les intervenants d'une chaîne d'approvisionnement. Cette interface est destinée à gérer automatiquement des opérations physiques, de suivi des marchandises via un code (107) barre 2D et de création de documents (100, 102, 104) nécessaires à la gestion de la chaîne. Ces documents sont accessibles et ou envoyés aux intervenants selon leurs profils d'accès préalablement définis. L'invention comporte un algorithme apte à organiser selon un ordre prédéfini la transmission de ces documents aux intervenants concernés. L'invention comporte également un algorithme de consolidation apte à mutualiser les flux de marchandises tant sur le plan national qu'international afin de diminuer le nombre de transporteurs/transitaires, les fréquences de livraison, les impacts environnementaux et le coût de la chaîne d'approvisionnement et de distribution.

Description

Procédé de gestion centralisée de chaînes d'approvisionnement et de distribution de marchandises et système de mise en œuvre dudit procédé
Domaine de l'invention La présente invention a pour objet un procédé de gestion centralisée de chaînes d'approvisionnement et de distribution de marchandises. Le domaine de l'invention est celui de la gestion d'une chaîne d'approvisionnement et de distribution de marchandises sur le plan national et international. Une chaîne d'approvisionnement et de distribution est un ensemble de méthodes utilisé pour produire, expédier et vendre des biens et des services sur une scène nationale et internationale. Ces méthodes sont utilisées pour une meilleure gestion des fournisseurs, des fabricants, des stocks, des modes de transport et notamment des acheteurs. Une bonne gestion de cette chaîne permet une production optimisée afin de livrer au client final le bon produit dans les bonnes quantités et dans les délais de livraison prévus.
Le but de l'invention est de fournir en temps voulu à une entité des marchandises, des matières, des fournitures et / ou des services qui lui sont nécessaires pour son fonctionnement, sa production ou la vente directe, dans les meilleures conditions de sécurité, de coût et de qualité.
Un autre but de l'invention est d'autoriser des modifications affectant des documents de la chaîne d'approvisionnement et de distribution de marchandises. Ces modifications entraînent une mise à jour en temps réels de l'ensemble des documents affectés. Ces modifications peuvent être entre autres un changement de date de livraison.
Un autre but de l'invention est d'informer en temps réel les intervenants de la chaîne d'approvisionnement, selon leur type d'autorisation, du déroulement de la chaîne d'approvisionnement et de distribution en cours d'exécution, en mettant en évidence la succession des étapes exécutées et, leurs résultats . Cette indication du déroulement permet de déterminer la responsabilité de tous les intervenants en cas de problème, tel que retard de livraison, afin d'identifier celui à qui la pénalitée à payer incombe. Etat de la technique
Aujourd'hui, lorsqu'un acheteur accepte une proposition commerciale relative à une vente de marchandises d'un fabricant ou d'un fournisseur, divers échanges mails et/ou fax et/ou courriers ont lieu entre les différents intervenants de la chaîne d'approvisionnement et de distribution.
L'acheteur crée et référence dans son système de gestion informatique un fichier d'enregistrement correspondant à cette offre commerciale. Puis, la date de livraison est planifiée dans le système de gestion du client et un bon de commande est créé. Ce bon de commande est ensuite transmis au fabricant ou au fournisseur par mail ou fax ou par courrier.
En outre, plusieurs échanges mails et/ou fax et/ou courriers s'effectuent entre les intervenants afin de produire les certificats de conformité et les normes en vigueur. Un certificat ou un norme est un écrit attestant que la marchandise est conforme à certaines normes ou que certaines formalités ont été accomplies.
Le fournisseur ou le fabricant intègre dans leur système de gestion informatique, le bon de commande reçu. Puis une facture est générée selon ce bon de commande. Le fournisseur ou le fabricant envoie au client cette facture par mail ou fax ou par courrier. Le client saisi dans son système de gestion informatique la facture reçue.
Le fournisseur ou le fabricant produit la marchandise selon l'offre commerciale et crée un bon de livraison pour un transitaire / transporteur. Ce bon de livraison est un document qui fournit en détail des informations sur la marchandise à livrer. Il comporte notamment des informations sur :
- les numéros des certificats ou normes,
- le client, - le fournisseur ou le fabricant,
- la marchandise, etc....
Il envoie par mail ou fax ou par courrier le bon de livraison créé au transitaire / transporteur. Le transitaire / transporteur saisi dans son système de gestion informatique le bon de livraison reçu. Le transitaire / transporteur achemine la marchandise du fournisseur ou du fabricant vers le client. Durant toute la période de transport de la marchandise des documents sont échangés entre d'une part le client et le fabricant ou le fournisseur et entre d'autre part le fabricant ou le fournisseur et le transitaire /transporteur. Ces échanges sont toujours effectués par mail ou fax ou par courrier. Cette chaîne actuelle d'approvisionnement et de transport des marchandises présente beaucoup d'inconvénients. En effet, chaque intervenant dans cette chaîne a son propre système de gestion informatique distinct des autres, depuis la commande jusqu'à la livraison entraînant un manque de visibilité sur toute la chaîne. Ainsi, cette chaîne d'approvisionnement et de transport ne peut pas être maîtrisée de bout en bout. De ce fait, il est difficile de panifier ou de prévoir les délais de livraison de la marchandise car les données régissant la chaîne d'approvisionnement peuvent changer en permanence. Tout changement de données entraine un délai d'information de ce changement à tous les intervenants, allongant d'autant le délai de livraison. Les changements de données peuvent être dus aux demandes du client qui sont souvent incontrôlables et variables ou, aux délais d'échanges d'informations entre les intervenants. Le manque de visibilité fait que les coûts d'approvisionnement et de transport sont très élevés. Ces coûts sont d'autant plus élevés lorsque plusieurs fournisseurs envoient vers le même client des marchandises. La figure 1 montre un exemple d'acheminement, sur le plan international, de marchandises de trois fournisseurs 10, 11 et 12 vers trois magasins 17-19 respectifs d'un client. Comme le montre cette figure, chaque fournisseur 10, 11 et 12 est en collaboration avec un transitaire 13, 14 et 15 respectif pour acheminer la marchandise vers un site 16 logistique du client. À l'arrivée sur le site 16 logistique du client, le client gère ensuite l'affrètement des marchandises reçus vers les magasins 17, 18 et 19. Pour chaque magasin, le client est en colaboration avec un transporteur pour l'affrètement de la marchandise vers le magasin correspondant.
La visibilité sur cette chaîne d'approvisionnement et de distribution de la figure 1 est d'autant plus réduite que le nombre d'intervenants augmente. Cette augmentation du nombre d'intervenants accroît le nombre de documents à traiter par le client augmentant ainsi les coûts et les délais de livraison des marchandises.
Un besoin s'est fait sentir d'optimiser les chaînes d'approvisionnement et de distribution tant sur le plan national qu'international afin de réduire le nombre de transporteurs / transitaires réduisant ainsi la pollution tout en réduisant également les coûts logistiques d'approvisionnement et de livraisons. Exposé de l'invention
L'invention a justement pour but de répondre à cette attente. Pour ce faire, l'invention met en œuvre un système unique de gestion partagée informatique en temps réel accessible via internet à tous les intervenants. L'invention met ainsi à dsiposition de tous les intervenants de la chaîne d'approvisionnement et de distribution de l'état de la technique, une interface de communication.
Cette interface permet aux intervenants de communiquer directement sans envoyer des mails, des fax ou des courriers. Elle permet également de gérer automatiquement des opérations physiques, de suivi des marchandises et de création de documents nécessaires à la gestion de la chaîne .
Ainsi, dans l'invention, des documents standardisés relatifs à la chaîne d'approvisionnemnt et de distribution sont créés et enregistrés dans une base de données. Ces documents peuvent être notamment des bons de commande, une facture, un bon de livraison, un certificat de conformité, une lettre de crédit...
Ces documents sont accessibles et ou envoyés aux intervenants selon leurs profils d'accès préalablement définis.
L'invention comporte un algorithme apte à organiser à temps voulu la transmission des documents aux intervenants concernés. L'algorithme de l'invention est apte à traiter les documents afin de détecter des éléments manquants, des erreurs pour transmettre des alertes aux intervenants concernés.
Le système de gestion partagée de l'invention permet ainsi de connaître en permanence les résultats d'activités de chaque intervenant. Il permet également de simplifier les circuits d'information entre les intervenants. L'invention comporte également un algorithme de consolidation apte à mutualiser les flux de marchandises tant sur le plan national qu'international afin de diminuer le nombre de transporteurs/transitaires, les fréquences de livraison, les impacts environnementaux et le coût de la chaîne d'approvisionnement et de distribution. A chaque document de l'interface de l'invention est associé une rangée de barre d'un code barre 2D comportant les données de ce document. Le code barre 2D est mis à jour en temps réel à chaque modification des documents et en fonction des opérations physiques effectuées. Le suivi en temps réel de la chaîne d'approvisionnement et de distribution de l'invention se fait à l'aide du code barre 2D.
En résumé, l'invention permet de gérer de manière centralisée et en temps réel une base de données via la mise en œuvre d'une interface de communication commune et partagée à tous les intervenants. Puis, l'invention met également en œuvre un algorithme permettant de simplifier l'utilisation de cette interface de communication. L'invention permet certes au final de résoudre un problème administratif qui est secondaire mais elle permet principalement la mise en place d'une interface de communication partagée, simple d'utilisation et transparente aux intervenants.
L'invention a donc pour objet un procédé de gestion centralisée de chaînes d'approvisionnement et de distribution de produit via un serveur de centralisation,
- on enregistre dans une base de données des fichiers (standardisés relatifs à une chaîne d'approvisionnement et de distribution de produit, lesdits fichiers comportant des champs à renseigner, caractérisé en ce qu'il comporte les étapes suivantes :
- ledit serveur de centralisation étant configuré de sorte à être une interface de communication commune accessible à des utilisateurs authentifiés via Internet
- on transmet, dudit serveur de centralisation, aux utilisateurs via la technologie push et selon un ordre de coordination préalablement défini lesdits fichiers, lesdits champs des fichiers transmis étant accessibles en fonction d'un profil d'accès aux champs des fichiers affecté auxdits utilisateurs,
- on crée un code barre bidimensionnel associé à chaque fichier dont une des rangées de barre comporte des données modifiables relatives aux champs dudit fichier,
- on mutualise au moins deux champs de même type appartenant chacun à une chaîne distincte, selon des critères de consolidation préalablement définis. Avantageusement, l'invention est également caractérisée en ce que le code barre bidimensionnel comporte en outre une rangée de barre fixe et non modifiable.
Avantageusement, l'invention est également caractérisée en ce que la première rangée de barre comporte un code barre monodimensionnel, de préférence de type EAN.
Avantageusement, l'invention est également caractérisée en ce que
- on transforme un code barre 1 D reçu par le serveur en une rangée de barre modifiable du code barre 2D.
Avantageusement, l'invention est également caractérisée en ce que lorsque les informations de même champ d'un même fichier ou des fichiers différents sont contradictoires dans une chaîne alors on envoie une alerte d'erreur aux utilisateurs, selon leurs profils d'accès.
Avantageusement, l'invention est également caractérisée en ce que l'authentification de l'utilisateur se connectant au serveur via un réseau comporte les étapes suivantes :
- on associe dans une base de données informatique des données d'authentification à au moins un identifiant de l'utilisateur,
- on reçoit une requête d'accès à un fichier du serveur,
- on produit et on émet une requête d'authentification de saisie des données d'authentification à une interface de l'utilisateur,
- on valide la requête d'authentification en fonction de la base de données et on autorise l'accès aux fichiers du serveur selon le profil d'accès de l'utilisateur.
Avantageusement, l'invention est également caractérisée en ce que le serveur comporte une mémoire cache de requête d'authentification.
Avantageusement, l'invention est également caractérisée en ce qu'un mode de transmission du serveur aux utilisateurs est une technologie RSS. Avantageusement, l'invention est également caractérisée en ce que
- on transcode les données à transmettre au format des utilisateurs et les données reçues au format du serveur.
Avantageusement, l'invention est également caractérisée en ce que - on associe aux alertes un délai de réponse,
- lorsque le délai de réponse arrive à terme, on génère des alertes de retard de réponse, - on transmet ces alertes de retard aux utilisateurs correspondants. L'invention concerne également un serveur comportant des moyens apte à mettre en œuvre le procédé de gestion centralisée de chaîne d'approvisionnement et de distribution de l'invention.
Brève description des dessins L'invention sera mieux comprise à la lecture de la description qui suit et à l'examen des figures qui l'accompagnent. Celles-ci sont présentées à titre indicatif et nullement limitatif de l'invention.
La figure 1 montre une représentation schématique d'une architecture de chaînes d'approvisionnement et de distribution de l'état de la technique. La figure 2 montre une représentation schématique d'une architecture client/serveur munie des moyens perfectionnés de l'invention.
La figure 3 montre une illustration de moyens mettant en œuvre le procédé de l'invention.
La figure 4 montre une représentation schématique d'un exemple de code barre 2D.
La figure 5 montre une représentation schématique d'une architecture de chaîne d'approvisionnement et de distribution selon l'invention.
Les figures 6-8, 10-11 montrent des exemples de documents produits par le serveur de l'invention. La figure 9 montre un exemple de lecture d'un code barre 2D.
Description détaillée de modes de réalisation de l'invention
La figure 2 montre une représentation schématique d'une architecture client/serveur munie des moyens perfectionnés de l'invention.
Par «serveur» 29 on entend une application mise en œuvre par un dispositif connecté à un réseau 20 télématique. Le dispositif mettant en œuvre le serveur 29 de centralisation de l'invention est de type ordinateur qu'il soit de type domestique, professionnel ou durci en vue de l'obtention d'une qualité de service élevée. Ledit dispositif comporte de manière classique un microprocesseur 30, une mémoire de programme 32 et des circuits 52 de connexion au réseau 20 télématique. La mémoire de programme 32 comporte alors des codes instructions correspondant au serveur 29. Ces codes instructions sont exécutés par le microprocesseur 30 qui est apte à commander au moins les circuits de connexion au réseau 20 télématique. Le serveur 29 est apte à traiter des requêtes lui parvenant sous forme de messages formatés selon un protocole via le réseau 20 télématique. Le serveur 29 est donc aussi apte à produire des messages de réponses à des requêtes reçues via le réseau 20 télématique. Des exemples classiques de serveur sont des serveurs :
- « Web », c'est-à-dire des serveurs fonctionnant selon le protocole HTTP (hypertext transfer protocol, pour protocole de transfert hypertexte),
- de messagerie, c'est-à-dire des serveurs fonctionnant selon des protocoles de type POP, SMTP, IMAP...
- de « streaming », c'est-à-dire de diffusion vidéo permettant la diffusion de programmes multimédia animés en temps réel à travers un réseau télématique,
- applicatif, c'est-à-dire par exemple un serveur « web » dit dynamique capable d'effectuer des traitements avancés en réponse aux requêtes reçues, cette liste n'étant bien entendu pas exhaustive. Par «client» 21 -28 on entend une application mise en œuvre par un dispositif connecté au réseau 20 télématique. Le dispositif mettant en œuvre le client est du type ordinateur personnel, téléphone mobile, assistant personnel et plus généralement tout dispositif capable de se connecter à un réseau 20 télématique. Un tel dispositif comporte de manière classique un microprocesseur et une mémoire de programme (non représentés) comportant des codes instructions correspondant à la mise en œuvre de l'application « client ». Les clients les plus connus sont les navigateurs Internet et les clients de messageries permettant respectivement de se connecter à des serveurs « web » et à des serveurs de messagerie. D'une manière plus générale on appelle « Client » toute application capable de communiquer avec un serveur.
Dans la pratique le client et le serveur sont confondus avec les dispositifs qui mettent en œuvre ces applications.
Ainsi dans la description lorsque l'on parle d'une action réalisée par le client ou le serveur, celle-ci est en fait réalisée par un microprocesseur d'un dispositif comportant une mémoire de programme dans laquelle sont enregistrés des codes instructions correspondant au client ou au serveur. L'exécution de ces codes instructions correspond à la mise en œuvre du client ou du serveur. Le serveur 29 de centralisation comporte aussi une mémoire de données 33. La mémoire de données 33, la mémoire de programme 32 et le microprocesseur 30 sont connectées à un bus 31 de communication.
La mémoire 32 de programme est divisée en plusieurs zones, chaque zone correspondant à une fonction ou à un mode de fonctionnement du programme du serveur 29.
Une zone 34 comporte des codes instruction pour affecter un profil d'accès aux utilisateurs authentifiés sécurisés du réseau 20. Le profil d'accès d'un utilisateur est une spécification sous forme de paramètres, du type d'accès de cet utilisateur aux fichiers et documents du serveur 29. L'authentification du réseau 20 est de préférence effectuée selon une authentification par identifiant et/ou par mot de passe. Dans ce cas, il est créé une base de données dans laquelle sont stockées des données intervenant dans l'authentification des utilisateurs par le réseau 20. Dans cette base de données à chaque identifiant/adresse d'un utilisateur est associé un identifiant et/ou par mot de passe. Cette base de données peut être installée dans le serveur 29. Elle peut également être externe au serveur 29. Dans ce cas, le serveur 29 produit des formulaires d'authentification et les envoie à une interface du poste client de l'utilisateur.
Dans le but de réduire à une seule fois le nombre de demande d'authentification par utilisateur, le serveur peut comporter une mémoire cache. Cette mémoire cache permet de stocker, pour un utilisateur donné, ses données d'authentification dès sa première authentification validée par le serveur. A chaque nouvelle émission de requête de l'utilisateur vers le serveur 29, ce dernier extrait directement de la mémoire cache les données d'authentification correspondant à cet utilisateur. Ceci, permet de ne pas demander à l'utilisateur de s'authentifier à chaque fois qu'il envoie une requête au serveur 29.
La sécurisation des utilisateurs permet de sécuriser les données transitant via le réseau 20 contre l'altération et l'interception. Une zone 35 comporte des codes instructions pour recevoir des postes 21-28 des utilisateurs un fichier d'offre commerciale via le réseau 20. Un fichier d'offre commerciale peut être une offre de vente de marchandises émise par le poste 25 des fabricants ou par le poste 26 des fournisseurs. Un fichier d'offre commerciale peut être également une offre de transport émise par les transitaires ou les transporteurs, un produit bancaire émis par la banque etc....
Dans la description, on entend par fichier un enregistrement d'un document de type formulaire comportant des champs à renseigner.
L'affectation des droits d'accès définies par les codes instructions de la zone 34, est mise en œuvre au moyen de critères de restriction qui décrit, pour chaque champ à renseigner des formulaires des fichiers qui a le droit de le lire et/ou de le modifier. Ces critères de restriction permettent au serveur
29 de gérer les accès aux fichiers de la mémoire 33 de données.
Le fichier offre commerciale de vente de marchandises comporte notamment les champs suivants à renseigner :
- date et n° de l'offre,
- nom du responsable vendeur,
- caractéristiques techniques du produit ou du service, poids, volume, description, photos... - prix,
- devise,
- durée de validité de l'offre,
- conditions d'emballage,
- conditions d'expédition, - les conditions de règlement.
La liste n'est pas exhaustive
Une zone 36 comporte des codes instructions pour créer un fichier
100 produit correspondant au fichier offre commerciale. Un exemple de fichier 100 produit est montré à la figure 6. Le fichier 100 produit peut comporter en outre des champs du fichier offre commerciale, des champs renseignant :
- des numéros de certificats et normes délivré à l'émetteur de l'offre par des autorités compétentes,
- les références, du fabricant, du fournisseur et / ou de l'acheteur. Une zone 37 comporte des codes instructions pour transmettre via le réseau 20 le fichier 100 produit vers les postes 21 -28 des utilisateurs selon leur profil d'accès.
Dans la description la transmission des données du serveur 29 aux postes 21-28 clients est, dans un mode réalisation préféré, effectuée via la technologie push. La transmission de données via cette technologie push permet au serveur 29 d'apporter à l'utilisateur ou à «pousser» vers lui, de manière directe et automatique, l'information programmée en fonction de ses droits d'accès.
Dans une variante, la transmission des données du serveur 29 aux postes 21-28 clients est effectuée via la technologie RSS. RSS désigne une famille de formats XML (eXtended Markup Language, pour langage de balisage étendu) utilisés pour la syndication de contenu Web (World Wide Web en anglais). La syndication est le fait de rendre, aux utilisateurs, accessible de manière standardisée et contractuel tout ou partie du contenu de la mémoire 33 de données du serveur 29 selon leurs droits d'accès. Ce système de syndication permet au serveur 29 de diffuser des mises à jour des fichiers dont le contenu change fréquemment.
Une zone 38 comporte des codes instructions pour créer une première rangée 110 de barre d'un code barre 107 bidimensionnel. Un exemple de code 107 barre bidimensionnel est illustré à la figure 5.
Cette première rangée 110 de barre est un code barre monodimensionnel. Cette première rangée 110 de barre est créée, lorsque le serveur 29 reçoit du réseau 20 une requête de validation du fichier 100 produit d'un acheteur authentifié par le réseau 20. Ce code 110 barre 1 D est associé au fichier 100 produit. Ce code barre 1 D n'est pas modifiable. Ce code barre 1 D est de préférence du type EAN pour European Article Numbering en anglais. Ce code barre 1 D comporte notamment des données sur le pays de provenance de la marchandise, sur le numéro de commande, sur le code EAN, sur la référence du produit, sur le type de marchandise, sur le type d'emballage, sur le poids, sur le volume, sur la destination, sur les dimension de la marchandise...
Une zone 39 comporte des codes instructions pour créer une deuxième rangée 101 de barre du code 107 barre bidimensionnel. Les données de cette deuxième rangée 101 de barre correspondent aux données du fichier 100 produit. Cette deuxième rangée 101 de barre est mise à jour à chaque fois que le fichier produit est modifié.
Une zone 40 comporte des codes instructions pour créer un fichier 102 commande correspondant au fichier 100 produit. Un exemple de fichier 102 commande est montré à la figure 8. Le fichier 102 commande peut comporter en outre des champs du fichier 100 produit, des champs renseignant les dates estimées :
- de fabrication de la marchandise,
- de départ et d'arrivée de la marchandise à l'acheteur.
Une zone 41 comporte des codes instructions pour transmettre via le réseau 20 le fichier 102 commande aux utilisateurs selon leurs profils d'accès. Une zone 42 comporte des codes instructions pour créer et associer une troisième rangée 103 de barre au fichier 102 commande.
Une zone 43 comporte des codes instructions pour créer un fichier 104 facture correspondant au fichier 102 commande. Un exemple de fichier 104 facture est montré à la figure 10. Le fichier facture peut comporter en outre des champs du fichier 102 commande, des champs renseignant les moyens et mode de paiement, les coordonnées de la banque du vendeur et éventuellement celles de l'acheteur, le délai de paiement...
Une zone 44 comporte des codes instructions pour transmettre via le réseau 20 le fichier 104 facture aux utilisateurs selon leurs profils d'accès. Une zone 45 comporte des codes instructions pour créer et associer une quatrième rangée 105 de barre au fichier 104 facture.
Une zone 46 comporte des codes instructions pour générer différentes alertes de coordination transmises via le réseau 20 aux postes des utilisateurs selon leurs profils d'accès. Ces alertes de coordination sont déclenchées par le serveur 29 lorsqu'un champ d'un fichier n'est pas renseigné.
Ces alertes de coordination peuvent être une surbrillance des champs à renseigner ou notamment : - une requête, transmise au fabricant ou au fournisseur, de renseignement de date de début fabrication, milieu fabrication et fin fabrication de la marchandise, ces dates sont fournies en prévisionnelles. Une requête de confirmation de ces dates sera automatiquement générée lorsque la date prévisionnelle arrive à échéance. - une requête de renseignement du numéro de certificat de conformité etc....
Une zone 47 comporte des codes instructions pour générer des alertes d'erreurs lorsque deux champs identiques dans un même fichier ou dans des fichiers différents sont contradictoires. Les codes instructions de la zone 47 transmettent l'alerte d'erreur générée aux utilisateurs selon leurs profils d'accès. Ces alertes d'erreur peuvent être notamment:
- erreur référence acheteur,
- erreur nom et adresse fournisseur...
Une zone 48 comporte des codes instructions pour générer des alertes de livraison. Les codes instructions de la zone 48 transmettent ces alertes de livraison aux utilisateurs selon leurs profils d'accès. Ces alertes de livraison permettent au serveur 29 de renseigner les champs des formulaires des fichiers selon les réponses reçues.
Ces alertes de livraison peuvent être une surbrillance des champs à renseigner ou des requêtes sur :
- le choix du mode de transport,
- le choix des entreprises de livraison,
- la réservation de plage horaire des entreprises de livraison,
- le choix d'un emballage qui protège la marchandise, - les conditions d'expédition de la marchandise (conteneur),
- les conditions de protection de la marchandise (ajout d'un insecticide),
- le calendrier de livraison
- de s'assurer de remplir les conditions d'exportation, d'importation et de douanes,
- de s'assurer que la marchandise est livrée à terme et en bonne condition...
Le déclenchement de ces alertes de coordination et de livraison dépend des actions effectuées par les intervenants. En effet, lorsque le fichier produit est validé par l'acheteur, des alertes de coordination ou de livraison concernant les champs du fichier de commande ne sont pas produit. Seuls des alertes pour renseigner les champs du fichier produit sont déclenchées. Les alertes de livraison et de coordination sont générées successivement selon un ordre prédéfini. Une zone 49 comporte des codes instructions pour associer un délai de réponse à chaque alerte, livraison, coordination ou erreur. Lorsque le délai de réponse arrive à terme, les codes instructions de la zone 49 génèrent des alertes de retard de réponse et les transmettent aux utilisateurs correspondants. Le délai de réponse peut être exprimé en heures ou en jours. Une alerte de retard peut être un message du type "attention, formulaire pas encore renseigné".
Les alertes générées par le serveur 29 peuvent être accompagnées d'un signal visuel et/ou sonore.
Une zone 51 comporte des codes instructions pour mutualiser aux moins de même type de champ de deux fichiers appartenant chacun à une chaîne d'approvisionnement différente, selon des critères de consolidation préalablement définis.
Une zone 52 comporte des codes instructions pour créer un fichier 106 livraison correspondant à un bon de livraison. Un exemple de fichier 106 livraison est montré à la figure 11. Le fichier 106 livraison est associé au code 107 barre bidimensionnel. Ce code 107 barre bidimensionnel regroupe l'ensemble des rangées de barres, du code barre 1 D, des fichiers produit, facture et commande.
Ce fichier 106 de livraison avec son code 107 barre bidimensionnel associé accompagne la marchandise livrée. Ils fournissent à l'acheteur le détail exact de l'historique de la procédure d'approvisionnement et de distribution. Ce fichier 106 de livraison peut être imprimé et remis en main propre à l'acheteur. Il peut être également transmis par le serveur 29 à l'acheteur. Ce document est à signer par le réceptionnaire. Cette signature peut être effectuée sur le document papier ou via un écran tactile.
Une zone 53 comporte des codes instructions pour vérifier un format des données reçues des postes des utilisateurs. Lorsque ce format est différent du format du serveur 29, les codes instructions de la zone 53 transcodent les données reçues des postes des utilisateurs selon le format du serveur 29 de centralisation. Les codes instructions de la zone 53 transcodent également les données à envoyer par le serveur 29 aux postes des utilisateurs selon le format desdits postes. Le format du serveur 29 peut être du XML.
Le format des postes des utilisateurs peut être un format normalisé selon la norme EDI pour Echange de données informatisée. Le format des postes des utilisateurs peut être un format selon le progiciel de gestion intégré plus connu sous le nom anglais de ERP pour Enterprise Ressource Planning. Le format des postes des utilisateurs peut être également un format d'email, de fax, de SMS, de MMS etc.. Le serveur 29 de l'invention peut ainsi être utilisé avec des systèmes de gestion informatique existants. Avec l'invention, il n'est pas nécessaire de changer le parc actuel des systèmes de gestion informatique. Le serveur 29 de centralisation sert d'interface de communication entre les systèmes actuels de gestion informatique des utilisateurs. Une zone 54 comporte des codes instructions pour transformer des données contenues dans un code barre monodimensionnel en une rangée de barre du code barre bidimensionnel. Ainsi, lorsque le serveur 29 reçoit, par exemple d'un poste d'utilisateur via un lecteur optique de code barre, un code barre 1 D, il l'intègre dans la chaîne de données. Cette intégration dans la chaîne de données est faîte par une transformation du code 1 D en une rangée de barre et par une incorporation de cette rangée de barre dans le code barre 2D.
La représentation de la mémoire 33 de données n'est qu'une illustration d'implantation de composants et d'enregistrement de données. La mémoire 33 de données comporte en général plusieurs bases 50 de données. Dans la pratique les bases 50 de données de la mémoire 33 de données sont unifiées ou distribuées selon des contraintes de taille et/ou de rapidité des traitements souhaités.
La mémoire 33 de données permet d'enregistrer un, ou plusieurs, identifiant/adresse idu d'utilisateur abonné aux services du serveur 29. Cet identifiant/adresse idu permet au réseau d'identifier l'utilisateur. Cet identifiant/adresse idu peut être lié à une adresse Internet IP (protocole Internet). Il peut aussi être lié à un numéro de téléphone permettant d'identifier l'utilisateur à qui appartient ledit téléphone. Ce dernier identifiant/adresse idu est utilisé dans le cadre d'une communication via les messages courts SMS ou MMS, par exemple.
A cet identifiant/adresse idu est associé un profil d'accès aux fichiers du serveur 29. La mémoire 33 de données fournit au serveur 29 le profil de l'utilisateur correspondant à la liste des services auxquels a droit l'utilisateur ainsi que les règles de sécurité associées à cet utilisateur.
La base 50 de données de la mémoire 33 de données est, par exemple, structurée en une table. Par exemple chaque ligne de la table correspond à un utilisateur, chaque colonne de la table correspond à un renseignement sur cet utilisateur. Ainsi la base 50 de données comporte une colonne 50a correspondant à un identifiant/adresse idu de l'utilisateur, une colonne 50b correspondant aux profils d'accès de l'utilisateur aux services proposés par le serveur 29, une colonne 50c correspondant à un fichier d'une offre commerciale, une colonne 5Od correspondant à un fichier produit, une colonne 50e correspondant à un code barre de type EAN, une colonne 5Of correspondant à un fichier de commande, une colonne 50g correspondant aux rangées de barres modifiables du code barre bidimensionnel et une colonne 5Oh correspondant à un fichier facture.
Dans un exemple préféré, la douane, la chambre de commerce ainsi que des banques peuvent faire partie des utilisateurs du serveur 29. L'utilisation de l'interface de l'invention par ces intervenants permet de faciliter la transmission des données entre les utilisateurs dudit serveur. Dans ce cas, la base 50 de données peut en outre comporter une colonne 5Oi correspondant à un fichier douane, une colonne 5Oj correspondant à un fichier chambre de commerce et une colonne 50k correspondant à un fichier banque.
Les fichiers de la douane peuvent être des certificats, des normes ou des documents administratifs. Ces fichiers sont de préférence mis à jour directement par la douane. Les fichiers de la chambre de commerce sont des documents relatifs à la réglementation et aux formalités régissant le commerce national ou international. Ces fichiers sont de préférence mis à jour directement par la chambre de commerce. Les fichiers de la banque sont des documents concernant des opérations bancaires telles qu'une lettre de crédits. Ces fichiers sont de préférence mis à jour directement par la banque. La connaissance d'un identifiant idu permet d'extraire de la table de la base 50 de données N lignes, N pouvant être un entier quelconque.
La figure 3 montre une illustration d'étapes correspondant à une mise en œuvre du procédé selon l'invention. La figure 3 montre une première étape préliminaire 60 dans laquelle le serveur 29 reçoit un fichier d'offre commerciale via le réseau 20. Le serveur 29 enregistre ce fichier d'offre commerciale dans la mémoire 33 de données.
A une étape 61 , le serveur 29 transmet cette offre commerciale aux postes des utilisateurs selon leurs profils d'accès définis au préalable. Par exemple, lorsque c'est une offre de transport émise par le transporteur ou le transitaire, le serveur 29 ne transmet cette offre qu'aux utilisateurs concernés qui sont notamment, le fournisseur et le fabricant. De même, lorsque l'offre commerciale est une offre de vente de marchandises, le serveur 29 ne le transmet qu'à l'acheteur.
A une étape 62, le serveur 29 reçoit d'un poste 26 acheteur une requête de validation d'une offre de vente de marchandises. A une étape 63 suivante, le serveur 29 crée un fichier 100 produit correspondant à cette offre de vente et l'enregistre dans la mémoire 33 de données.
Lors de la création de ce fichier 100 produit, une première rangée de barre correspondant au code 110 barre de type EAN est créée. De même, une deuxième rangée de barre est créée et associée au fichier produit. Cette deuxième rangée de barre comporte les données contenues dans le fichier produit.
Des fichiers de certification et de normalisation sont transmis par le serveur 29 aux utilisateurs selon leurs profils d'accès. Un exemple de fichier 110 certification est montré à la figure 7. Le fichier de certification comporte entre autres des champs renseignant sur :
- l'expéditeur de la marchandise,
- le destinataire de la marchandise,
- les moyens de transport utilisés, - le numéro du certificat,
- les caractéristiques de la marchandise.
A une étape 64 suivante, le serveur 29 transmet le fichier 100 produit créé au poste 26 de l'acheteur ayant émis la requête de validation avec une requête de confirmation. Si le serveur 29 reçoit, à une étape 65, en réponse de la requête de confirmation une infirmation du ficher produit, alors il arrête à une étape 66 la procédure de gestion d'approvisionnement de l'invention. A l'étape 66, il peut être envisage que le serveur 29 supprime de la mémoire 33 de données le fichier 100 produit les rangées de barres du code barre 2D ainsi que les fichiers certificats et normes associés. Si à l'étape 65, le serveur 29 reçoit en réponse de la requête de confirmation, une validation du ficher produit alors le serveur 29 crée à une étape 67 un fichier commande.
L'infirmation ou la validation de la requête de confirmation est obtenue par l'enfoncement d'une touche de validation du clavier poste de l'acheteur ou d'une zone de l'écran de ladite poste, lorsque ce dernier est tactile. Le serveur 29 crée une troisième rangée de code barre bidimensionnel. Cette troisième rangée de code barre comporte les données relatives au fichier commande.
A une étape 68, le serveur 29 transmet le fichier commande créé au poste 26 de l'acheteur avec une requête de confirmation. Si le serveur 29 reçoit, à une étape 69, en réponse de la requête de confirmation une infirmation du ficher commande, alors il arrête à une étape 70 la procédure de gestion d'approvisionnement de l'invention. A l'étape 70, il peut être envisagé que le serveur 29 supprime de la mémoire 33 de données le fichier 100 produit, le fichier commande, les rangées de barres du code barre 2D ainsi que les fichiers certificats et normes associés.
Si à l'étape 71 , le serveur 29 reçoit en réponse de la requête de confirmation, une validation du ficher commande alors le serveur 29 transmet le fichier commande au fournisseur ou fabricant ayant émis l'offre commerciale de vente. Le fournisseur ou le fabricant renseigne les champs du formulaire du fichier de commande. Lorsque le serveur 29 reçoit une requête de validation du fichier commande alors il crée à une étape 72 un fichier facture selon le fichier de commande. Le serveur 29 crée une quatrième rangée de barres du code barre bidimensionnel associé à ce fichier facture. Cette troisième rangée de barre du code barre comporte les données relatives au fichier facture.
A une étape 73, le serveur 29 transmet le fichier facture créé au poste du fournisseur ou du fabricant avec une requête de confirmation. Si le serveur 29 ne reçoit pas de réponse à la requête de confirmation il envoie, à une étape 75 une alerte de retard au fournisseur ou au fabricant. Cette alerte de retard peut être envoyée à des intervalles dans le temps prédéfinies.
Dans un exemple préféré, lorsque trois alertes sont envoyées au fournisseur ou au fabricant, le serveur 29 retransmet le fichier facture avec la requête de confirmation. Dans une variante, un administrateur du réseau peut contacter par mail ou téléphone ou par fax le fournisseur ou le fabricant en vue de la validation de la requête de confirmation.
Lorsqu'avant la fin du délai de réponse, le serveur 29 reçoit, à une étape 76, en réponse de la requête de confirmation, une validation du ficher facture, alors il transmet le fichier facture à l'acheteur. A une étape 77, le serveur 29 génère des alertes de coordination et les transmet aux utilisateurs selon leurs profils d'accès. Les réponses à ces alertes de coordination permettent au serveur 29 de renseigner les champs des formulaires des fichiers. Ces alertes de coordination sont en interaction les unes aux autres. Ces alertes ne sont générées que lorsque les alertes précédentes sont validées. Par exemple, les alertes concernant le fichier de commande ne sont générées que lorsque toutes les alertes concernant le fichier de produit ont reçu une réponse validée par le serveur 29.
Le serveur 29 vérifie en permanence les informations contenues dans les champs des formulaires des fichiers. En cas de données contradictoires pour un même renseignement d'un champ dans des fichiers différents ou dans un même fichier, alors le serveur 29 génère, à une étape 78, une alerte d'erreur et le transmet aux utilisateurs selon leurs profils d'accès. Ces alertes d'erreur permettent au serveur 29 d'harmoniser les renseignements des champs des formulaires des fichiers.
Le serveur 29 reçoit du fabricant ou du fournisseur une requête de validation de fin de fabrication, à une étape 79. Suite à l'étape 79, le serveur 29 envoie, à une étape 80, des alertes de livraison aux utilisateurs selon leurs profils d'accès. Ces alertes de livraison permettent d'organiser de manière séquentielle la livraison de la marchandise d'un site d'entreposage du fournisseur ou du fabricant à l'acheteur. Ces alertes de livraison permettent au serveur 29 de renseigner les champs de livraison des formulaires des fichiers selon les réponses reçues.
A une étape 81 , le serveur 29 mutualise les flux de marchandise en regroupant au moins deux même type de champs de deux fichiers de deux chaînes d'approvisionnement et de distribution distinctes. Ces champs peuvent être dans des types de fichiers différents. Cette mutualisation est faîte selon des critères de consolidation préalablement définie. Un critère de consolidation peut être la zone de livraison, la date de livraison, le transporteur, le transitaire, le volume de la marchandise, le poids de la marchandise, la nature de la marchandise, et/ou la surtaxe à payer etc..
Dans un mode de réalisation préféré, les champs mutualisés sont ceux des fichiers de commandes.
A l'étape 82, le serveur 29 crée un fichier livraison correspondant à un bon de livraison. Ce fichier est ensuite transmis aux utilisateurs selon leurs profils. Ce fichier livraison accompagnant la marchandise peut être fourni en version papier. Ce fichier livraison est associé au code barre bidimensionnel regroupant l'ensemble des informations des rangées de barres déjà créés.
Pour chaque fichier des alertes de corrdination et de livraison sont générées afin de renseigner les champs. Ces alertes sont générées dans un ordre précis préalablement défini.
Les champs des fichiers du serveur 29 peuvent être modifiés par des utilisateurs autorisés selon leurs besoins. Toute modification de ces fichiers entraîne une mise à jour de tous les fichiers associés à l'identifiant/ adresse de l'utilisateur et du code barre 2D. Par exemple, lorsque le transporteur modifie la date de livraison, tous les fichiers ayant un champ date de livraison sont modifiés en conséquence de même que le code barre 2D.
Lorsque la livraison est effectuée et que l'acheteur a apposé sa signature, les fichiers et le code barre 2D ne sont plus modifiables. Chaque utilisateur authentifié sécurisé peut, selon son profils d'accès, accéder à un espace mémoire de la mémoire 33 de données comportant l'historique de l'ensemble des fichiers associés à son identifiant/adresse. Cet espace mémoire est uniquement visualisable.
La figure 4 montre une représentation shématique du code 107 barre bidimensionnel. Ce code 107 barre bidimensionnel comporte plusieurs rangées de barres superposées. Il comporte une première rangée 110 de barre qui est la partie fixe non modifiable du code 120 barre bidimensionnel. Cette première rangée comporte le code 110 barre monodimensionnel de type EAN. Les autres rangées de barres forment la partie modifiable du code 107 barre bidimensionnel et consultable en temps réel. Ce code 107 barre bidimensionnel peut en outre comporter une adresse web (URL) renvoyant au fichier 100 produit, comme montré à la figure 9.
La figure 9 montre un moyen de lecture de code barre bidimensionnel. Dans l'exemple de la figure le moyen de lecture est un téléphone mobile 108. il peut également être tout autre dispositif comportant un lecteur optique de lecture de code barre bidimensionnel.
Dans l'exemple de la figure 9, un appareil photo du téléphone mobile 108 scanne le code 107. le téléphone 108 comporte des logiciels aptes à l'interpréter afin de lire son contenu. Si le code comporte une adresse web (URL), une requête d'ouverture de lien peut être proposé. En ouvrant le lien, l'utilisateur peut directement visualiser les fichiers 109 du serveur 29 selon son profil d'accès.
La figure 5 montre une représentation schématique de l'application du système d'approvisionnement et de distribution de l'invention à l'exemple de la figure 1. L'exemple de la figure 5 montre trois chaînes d'approvisionnement distinctes. Chaque chaîne d'approvisionnement correspondant à une vente de marchandises d'un des fornisseurs 10-12. Dans l'exemple de la figure 5, des champs des trois fichiers de commandes des trois fournisseurs 10-12 sont mutualiser selon des critères de consolidation qui sont : le délai de livraison, le poids et le volume de la marchandise, le lieu de livraison. Avec l'invention, un seul transitaire est utilisé pour transporter les marchandises correspondant au bon de commande. De même avec l'invention, un seul affréteur est utilisé pour transporter la marchandise du lieu logistique du client aux magasins 17-19. L'invention permet ainsi de réduire considérablement le nombre de modes de transport utilisés, les temps de parcours et le nombre de trajets pour les livraisons. Cette réduction permet de diminuer de manière conséquente la pollution, le temps perdu ainsi que les dépenses inutiles...

Claims

REVENDICATIONS
1 - Procédé de gestion centralisée de chaînes d'approvisionnement et de distribution de produit via un serveur de centralisation (29), - on enregistre dans une base de données (50) des fichiers (100, 102,
104, 106) standardisés relatifs à une chaîne d'approvisionnement et de distribution de produit, lesdits fichiers comportant des champs à renseigner, caractérisé en ce qu'il comporte les étapes suivantes :
- ledit serveur de centralisation étant configuré de sorte à être une interface de communication commune accessible à des utilisateurs authentifiés via Internet
- on transmet (37), dudit serveur de centralisation, aux utilisateurs via la technologie push et selon un ordre de coordination préalablement défini lesdits fichiers, lesdits champs des fichiers transmis étant accessibles en fonction d'un profil d'accès aux champs des fichiers affecté auxdits utilisateurs,
- on crée un code (107) barre bidimensionnel associé à chaque fichier dont une des rangées (101 , 103, 105) de barre comporte des données modifiables relatives aux champs dudit fichier, - on mutualise (51 ) au moins deux champs de même type appartenant chacun à une chaîne distincte, selon des critères de consolidation préalablement définis.
2 - Procédé selon la revendication 1 , caractérisé en ce que le code (107) barre bidimensionnel comporte en outre une rangée (110) de barre fixe et non modifiable.
3 - Procédé selon la revendication 2, caractérisé en ce que la première rangée de barre comporte un code barre monodimensionnel, de préférence de type EAN.
4 - Procédé selon l'une des revendications 2 à 3, caractérisé en ce que
- on transforme un code barre 1 D reçu par le serveur en une rangée de barre modifiable du code barre 2D.
5 - Procédé selon l'une des revendications 1 à 4, caractérisé en ce que lorsque les informations de même champ d'un même fichier ou des fichiers différents sont contradictoires dans une chaîne alors on envoie une alerte (47) d'erreur aux utilisateurs, selon leurs profils d'accès.
6 - Procédé selon l'une des revendications 1 à 5, caractérisé en ce que l'authentification de l'utilisateur se connectant au serveur via un réseau (20) comporte les étapes suivantes : - on associe dans une base de données informatique des données d'authentification à au moins un identifiant de l'utilisateur,
- on reçoit une requête d'accès à un fichier du serveur,
- on produit et on émet une requête d'authentification de saisie des données d'authentification à une interface de l'utilisateur, - on valide la requête d'authentification en fonction de la base de données et on autorise l'accès aux fichiers du serveur selon le profil d'accès de l'utilisateur.
7 - Procédé selon la revendication 6, caractérisé en ce que le serveur comporte une mémoire cache de requête d'authentification. 8 - Procédé selon l'une des revendications 1 à 6, caractérisé en ce qu'un mode de transmission du serveur aux utilisateurs est une technologie RSS.
9 - Procédé selon l'une des revendications 1 à 8, caractérisé en ce que - on transcode les données à transmettre au format des utilisateurs et les données reçues au format du serveur.
10 - Procédé selon l'une des revendications 1 à 9, caractérisé en ce que
- on associe (49) aux alertes un délai de réponse, - lorsque le délai de réponse arrive à terme, on génère des alertes de retard de réponse,
- on transmet ces alertes de retard aux utilisateurs correspondants.
11 - Serveur (29) de centralisation caractérisé en ce qu'il comporte des moyens aptes à mettre en œuvre un procédé de gestion centralisée de chaînes d'approvisionnement et de distribution de produit selon l'une quelconque des revendications 1 à 10.
PCT/FR2009/051934 2008-10-10 2009-10-12 Procede de gestion centralisee de chaines d'approvisionnement et de distribution de marchandises et systeme de mise en oeuvre dudit procede WO2010040968A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR0856863 2008-10-10
FR0856863A FR2937167B1 (fr) 2008-10-10 2008-10-10 Procede de gestion centralisee de chaines d'approvisionnement et de distribution de marchandises et systeme de mise en oeuve dudit procede

Publications (1)

Publication Number Publication Date
WO2010040968A1 true WO2010040968A1 (fr) 2010-04-15

Family

ID=40578731

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2009/051934 WO2010040968A1 (fr) 2008-10-10 2009-10-12 Procede de gestion centralisee de chaines d'approvisionnement et de distribution de marchandises et systeme de mise en oeuvre dudit procede

Country Status (2)

Country Link
FR (1) FR2937167B1 (fr)
WO (1) WO2010040968A1 (fr)

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001099018A1 (fr) * 2000-06-22 2001-12-27 Eventra, Inc. Procede et systeme de gestion des relations fournisseurs
US20050273434A1 (en) * 2004-04-18 2005-12-08 Allen Lubow System and method for managing security in a supply chain
US7035856B1 (en) * 2000-09-28 2006-04-25 Nobuyoshi Morimoto System and method for tracking and routing shipped items

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2001099018A1 (fr) * 2000-06-22 2001-12-27 Eventra, Inc. Procede et systeme de gestion des relations fournisseurs
US7035856B1 (en) * 2000-09-28 2006-04-25 Nobuyoshi Morimoto System and method for tracking and routing shipped items
US20050273434A1 (en) * 2004-04-18 2005-12-08 Allen Lubow System and method for managing security in a supply chain

Also Published As

Publication number Publication date
FR2937167B1 (fr) 2012-06-01
FR2937167A1 (fr) 2010-04-16

Similar Documents

Publication Publication Date Title
US7814025B2 (en) Methods and apparatus for title protocol, authentication, and sharing
Treese et al. Designing systems for Internet commerce
US7240026B2 (en) Method, apparatus, and computer-readable medium for integration of online and offline commerce
US8073740B1 (en) Facilitating a supply of used items
US8571992B2 (en) Methods and apparatus for title structure and management
US20070179978A1 (en) Systems and methods for anti-counterfeit authentication
Goel E-commerce
US20050038724A1 (en) Methods and apparatus for enabling transaction relating to digital assets
US20060170759A1 (en) Methods and apparatus for optimizing digital asset distribution
US20050038707A1 (en) Methods and apparatus for enabling transactions in networks
US20040205113A1 (en) Methods and apparatus for the interoperability and manipulation of data in a compuer network
RU2700395C2 (ru) Система для гарантирования подлинности брендовых товаров
US20050234860A1 (en) User agent for facilitating transactions in networks
US20050246193A1 (en) Methods and apparatus for enabling transaction relating to digital assets
CN112565055B (zh) 促进对第三方发送的电子邮件进行认证的系统和方法
US9922369B2 (en) Transaction account interface
AU2014234956A1 (en) Systems and methods for managing sending of items
JP2002042008A (ja) 荷物の任意拠点受渡しサービス提供方法及びシステム
CN111292067A (zh) 订单分销系统
WO2003098398A2 (fr) Procedes et dispositif permettant la mise en oeuvre d'un reseau de transaction de titres
EP1766846A1 (fr) Procédés et appareils pour la validation de transactions dans des réseaux
JP2003160231A (ja) 物品配送先指定方法
Kutz Introduction to E-commerce
FR2810433A1 (fr) Systeme et procede de couponnage electronique
EP1578055A1 (fr) Procédé de consultation sécurisée de récépissés de livraison d'objets

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 09756005

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 09756005

Country of ref document: EP

Kind code of ref document: A1