WO2013014397A1 - Système d'optimisation de commandes de produits à distance - Google Patents

Système d'optimisation de commandes de produits à distance Download PDF

Info

Publication number
WO2013014397A1
WO2013014397A1 PCT/FR2012/051778 FR2012051778W WO2013014397A1 WO 2013014397 A1 WO2013014397 A1 WO 2013014397A1 FR 2012051778 W FR2012051778 W FR 2012051778W WO 2013014397 A1 WO2013014397 A1 WO 2013014397A1
Authority
WO
WIPO (PCT)
Prior art keywords
storage space
products
terminal
list
database
Prior art date
Application number
PCT/FR2012/051778
Other languages
English (en)
Inventor
Olivier Bourgeois
Thierry CONESA
Original Assignee
Proxi - Business
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 Proxi - Business filed Critical Proxi - Business
Publication of WO2013014397A1 publication Critical patent/WO2013014397A1/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/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"
    • G06Q10/047—Optimisation of routes or paths, e.g. travelling salesman problem
    • 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/04—Forecasting or optimisation specially adapted for administrative or management purposes, e.g. linear programming or "cutting stock problem"

Definitions

  • the present invention relates to the preparation of an order from products stored in a warehouse, on a platform or directly by taking them from the shelves of a point of sale where said products are placed for a self-service sale.
  • the subject of the invention is a system for optimizing the preparation of remote product orders.
  • Such a type of system is set up in a known manner in the context of warehouses with large storage areas or in certain hypermarkets which have set up a remote control service in which a picker carries out the collection. products ordered instead of the customer.
  • the known systems are arranged for the supervision of storage operations in a warehouse, taking orders into account and optimizing their preparation.
  • the order preparation step remains a long step, lasting about an hour per order.
  • the course of the user for the collection of the products is not optimal because it can be random and / or partitioned to a list of products of a specific order.
  • the present invention aims to solve all or part of the disadvantages mentioned above.
  • the present invention has the advantage of a system for optimizing remote product order preparation, characterized in that it comprises: an online ordering platform comprising a database comprising a list of products,
  • a local server dedicated to the storage space connected to the on-line control platform by first communication means and connected to the terminal by second communication means,
  • said dedicated local server comprising:
  • data flow management means arranged to allow the exchange of data between on the one hand the on-line control platform and the local server and on the other hand between the terminal and the local server,
  • this set of geolocation data of the products in the storage space being provided from the user's terminal
  • processing means arranged to calculate an optimized travel time during the collection of products from the list of product orders to be prepared from the database according to the geolocation data set of the products in the space of determined storage of the database.
  • the arrangements of the invention define an optimized remote control system through the online ordering platform allowing users to perform the collection of products within one or more storage spaces.
  • the system is suitable for storage spaces of any size, including outlets of any size, without the need for a fixed placement of products.
  • the term "user” in particular is understood to mean a order picker (s) carrying out a pick-up for one or more customers or, a customer seeking to optimize his travel time to make his purchases for the purpose of interior of the storage space or spaces.
  • the processing means calculate an optimized travel time according to several parameters among:
  • the database comprises a list of product commands prepared by the terminal and retrievable by the database of the on-line control platform.
  • the local server comprises means for modeling the storage space, in particular a graphics application, arranged to generate the storage space data set.
  • This arrangement makes it easier to locate the zones, shelves and shelves inside a point of sale in or on which the various products to be controlled are located.
  • the local server comprises configuration means arranged to allow an adjustment of all or part of a set of parameters by a supervisor of the storage space.
  • all the parameters proposed by the local server configuration means comprise at least one of:
  • the geolocation list comprises a series of products identified with an alphanumeric code corresponding to their location in the storage space.
  • This arrangement makes it possible to develop a simple coding making it possible to easily locate a product inside the point of sale.
  • the terminal is of the personal digital assistant or ordiphone type.
  • the system comprises in addition to the first terminal, a second terminal available to a supervisor of the storage space connected to the local server by third communication means.
  • the local server comprises decision support means arranged to provide on the second terminal of the su space storage optimal allocation of product orders to be prepared by the user , in particular according to several preparation methods integrating for example the number of available preparers and the time allowed for the preparation of orders.
  • the second terminal is of the microcomputer or ordiphone type.
  • the processing means arranged to calculate an optimized travel time are also arranged to calculate statistics for the supervisor and particularly concerning the products ordered, their situations in the storage space and information on the preparers.
  • the statistics comprise at least one of:
  • the processing means use several algorithms including:
  • Figure 1 is a block diagram showing an embodiment of a system 10 according to the invention.
  • a system 10 comprises an on-line control platform 20, for example of the Proxi-Store® brand, and a terminal 31 available to a user, customer or order picker, in a control space. storage 30 determined.
  • the on-line control platform 20 comprises a database 21 comprising a list of products present in a storage space 30 determined and a list of product orders to be prepared, the orders being made. remote by customers of the platform 20 online order.
  • the storage space 30 is managed by a set of supervisors who manage a set of order pickers for the determined storage space.
  • system 10 includes a local server 40 dedicated to the determined storage space 30.
  • the local server 40 is connected to the on-line control platform 20 by first communication means 1, for example of the Internet network type.
  • the local server 40 is connected to the terminal 31 by second communication means 2, for example of the wireless or wired type.
  • the terminal 31 may for example be a PDA or a printer providing a product list to be prepared in an operation of the system 10 in a degraded mode described later in the text.
  • the user may be an order picker performing the preparation of the order of a customer or a customer himself picking his own products ordered in the different departments of the storage space 30 or preparation zone 30, by example a dry warehouse, a fresh warehouse, an outside supplier ...
  • the system 10 comprises third communication means 3 with a second terminal 32 available to a supervisor of the storage space 30.
  • the third communication means 3 may for example be of the wireless or wired type.
  • the second terminal 32 may for example be a microcomputer or a PDA.
  • system 10 comprises configuration means 45 of the system 10 arranged to allow adjustment of all or part of a set of parameters by a supervisor of the storage space 30.
  • the system 10 also comprises data flow management means 42 comprising data import scripts and arranged to manage the contents of a database 41 of the local server 40.
  • this database 41 comprises in particular:
  • the list of orders of prepared products is not essential for the proper functioning of the system 10 but nevertheless allows feedback to the online ordering platform 20 to send back to the customer information about the product. the preparation of his order.
  • the geolocation data set of the products in the storage space 30 is supplied by the terminal 31 after a preparer has recorded on its terminal 31, the geolocation data of each of the products present in the storage space 30. .
  • This step is performed only once or each time a product is moved in the storage space 30.
  • the system comprises processing means 12 arranged to calculate an optimized travel time during the collection of the products of the list of product orders to be prepared from the database 41 according to the geolocation data set of the data bases. produced in the determined storage space 30 of the database 41.
  • These processing means 12 are preferably constituted by a microprocessor.
  • the database 21 also includes a set of data for modeling the storage space 30.
  • the local server 40 proposes modeling means 13, which are further detailed in the text, making it possible to generate the set of data for modeling the storage space 30, and thus facilitating the tracking products within the storage space 30 including through a graphics application.
  • the local server 40 comprises configuration means 45 arranged to allow an adjustment of all or part of a set of parameters by a supervisor of the storage space 30.
  • the configuration of the local server 40 by the configuration means 45 may be useful when associating the local server 40 with a particular storage space.
  • These configuration means 45 allow a supervisor of this storage space 30 to configure global parameters such as:
  • the supervisor of the storage space 30 is invited on his microcomputer 32 to choose the fineness with which the products are located in the storage space 30.
  • This fineness can be of the order of the radius, the segment in the shelf or shelf in the segment.
  • a spoke may comprise a plurality of segments corresponding to portions dividing the radius longitudinally, each segment may comprise several superimposed shelves.
  • the system 10 may operate in a degraded mode, in the case where the modeling data set of the storage space 30 would not be unavailable. In any case, the user must still geolocate the products but in a logical order of sampling. Indeed, without the dataset of modeling the storage space 30, the optimization of the course of the preparer is impossible, and is made alphabetically by geolocation codes detailed later in the text.
  • the width of the shelf is 1 m10. But it is possible to modify this parameter during the configuration of the system 1.
  • Import import paths and import script access must also be entered when configuring local server 40 to storage space 30.
  • the folders containing the files products and commands as well as URLs of the scripts to retrieve them from the online ordering platform 20 must be specified.
  • RRR-XX-EE 3 parts:
  • RRR Numeric, determines the radius
  • the local server 40 by the The intermediate of its processing means 43 automatically assigns it 005-BO as a geolocation code.
  • the geolocator activates the geolocation mode on the terminal 31.
  • the geolocator can scan the products to be geolocated and indicate their locations by radius, segment and shelf if necessary according to the fineness of geolocation chosen.
  • the terminal 31 used by the geolocalizer is embodied by the preparers of the storage space 30, is above all simple and intuitive. Indeed, the process of geolocation is relatively tedious, that is why this interface tries to simplify as much as possible the work of the geolocator. In order to limit the number of manipulations during this phase, conventions are put in place:
  • the de b e t of th e ray is located at the top of the geolocator when it is in front of the beam
  • the first shelf in the segment is the one at the top
  • the geolocator when the geolocator reaches the maximum level of geolocation (either the radius, the segment, or the shelf), the geolocator can scan the products in the order they want since all products at this level have the same geolocation code,
  • each segment is of fixed width (that of the shelf). For the system 10 to be fully operational, all the products of the storage space 30 must be scanned.
  • the data on the existing geolocations are loaded on the terminal 31 of the geolocator and unloaded at the end of geolocation in the database 41 of the local server 40.
  • the geolocation process can be performed in several times.
  • a product can be located at different places in the storage space 30, it then comprises different geolocation codes according to its location in the storage space 30.
  • the number of rays in the storage space 30 and their size are available.
  • a graphical application generated by the modeling means 44 then makes it possible to place these rays relative to one another in order to better model the storage space 30, and an indication of the products contained in the rays will facilitate this placement.
  • the rays can be composed of elements, namely segments and shelves, of different sizes and shapes, two different radii possibly being superimposed.
  • This placement is relative to the boxes that are modeled at the bottom of the modeling space. Resizable obstacles may also be added to prevent the preparer from moving to the location of the obstacle. When the placement is complete, the coordinates of the departments are recorded in the database 41.
  • a radius can belong to only one zone and a zone can belong to only one stage.
  • a summary screen summarizes all information about departments and areas such as the number and labeling of departmental departments, out-of-area departments, and so on.
  • Each ray can be ordered relative to the other radii to specify the priority constraints. For example, the radius containing the drinks will be part of the first rays.
  • the processing means 43 therefore use compulsory passage points to enter or leave a department. These points of passage, are placed automatically by the person modeling the storage space 30.
  • the modeler is a supervisor or even an administrator who can carry out this modeling remotely to then transmit it to the fourth means of communication 4 included in the local server 40.
  • the modeling of the storage space 30 is a long and tedious process that must be carried out only once (except physical change of the departments within the store). For this, the modeling means 44 do not involve the products but only the shelves, the segments, and the spokes.
  • a geolocation it is necessary for a geolocation to be previously performed or a radius list to be entered or imported by a supervisor or administrator.
  • the geo-location data of the products will provide a list of store shelves, as well as the number of segments they contain and the number of shelves per segment. From this information, a list of rays to be modeled is obtained with different sizes (proportional to the number of segments in the radius). This information will facilitate modeling. Indeed, the user will not have to add rays, define their sizes, the number of segments and the number of shelves per segment because all this information will already be known thanks to the phase of geolocation.
  • the administrator may be able to modify the modeling later. However, the calculation of the paths, detailed below, is restarted with each modification. In addition, a "reset" command allows the administrator to reset the modeling. However, the old model is saved in the database 41 to be able to recover it in case of error.
  • the processing means 43 of the local server 40 use different algorithms for calculating the paths:
  • the graphical modeling of the storage space 30 means that the user can position the rays with respect to one another as they actually are in the storage space 30.
  • the storage space 30 is modeled as a connected graph where the vertices are the sampling points as well as the corner points of the radii, and the edges are the connecting segments. dots.
  • each point is tested with all the other points of the graph so as to find the segments between the points that do not cut a radius or an obstacle. This phase is tedious and depends on the number of points, because each point and each added radius or obstacle seriously increases the complexity.
  • the development language of the algorithms used by the processing means 43 is, for example, P H P (Personal Home Page). Of course, other programming languages can be used.
  • An array in PHP is actually an ordered map.
  • a map is a type that associates values with keys.
  • Graphs in PHP are represented by two-dimensional arrays, where the keys are the vertices of the graph and the content is the distance between each point.
  • the notation differs for points that are unreachable. In our case, by convention, if the distance is 1,000,000, the two points are unreachable.
  • the graph of the storage space 30 (the edges) is constructed, and the adjacency matrix (calculation of distances) is filled.
  • the adjacency matrix will make it possible to know if it is possible to connect a waypoint to another waypoint without cutting an object.
  • Dijkstra's algorithm allows you to calculate the shortest path between one point and another. It applies to a connected graph whose edges are weighted. In other words, the algorithm needs an adjacency matrix as described above.
  • Dijkstra is used to know the best route to use to reach a waypoint that is not directly connected to another.
  • This algorithm is therefore applied to all the points of the graph, except the turning points, which are never start or end points since they do not correspond to products but only to intermediate points.
  • the path is preserved. While for unreachable points, the algorithm looks for the shortest path connecting them.
  • the processing means 43 calculate the optimal path connecting several points, which amounts to solve the problem of the commercial traveler.
  • the problem of the traveling salesman is a complex problem which consists of going through all the points of a graph and returning to the point of departure, so as to make the path as far as possible.
  • this problem is not soluble with a combinatorial linear approach in an acceptable time. Heuristic algorithms are used.
  • the journey is made on all the products starting from a starting point and arriving at a point of arrival which can be different.
  • a user-specified pick priority must be respected between the different products.
  • the algorithm used by the processing means 43 therefore takes these elements into account.
  • This algorithm takes as input a complete graph as well as an existing path between all the points which respects the order of the priorities. Indices of change of priority are also necessary.
  • This algorithm consists in swapping two edges in the graph if it causes an overall improvement of the distance traveled. In practice, this inversion consists of returning the path between two points.
  • the graph is traversed in full and for each point, the consequence of a permutation with a point located further in the graph is tested. If there is an improvement, the reversal is done and the course is continued. As long as there is at least one improvement in the path of the graph, the complete path of the graph is restarted.
  • the local server 40 also comprises supervisor decision support means 46 which allows an optimal allocation of the commands of the list of commands to be prepared from the database 41 to the different preparers.
  • decision support means 46 take into account the number of preparers available and the time allowed for the preparation of orders. According to these parameters, these means 46 propose a solution to the supervisor of the preparers, by affecting the different orders (or partial orders) to the different preparers. This assignment can then be changed at the convenience of the supervisor.
  • the decision support means 46 it is possible to set the decision support means 46 by specifying the mode or modes of preparation in which one wishes to operate. Thus, in the case where the supervisor wishes to use only one mode of preparation, this parameter is stored and used for each assignment. By default, all preparation modes can be used. If several modes are selected, the system 10 optimizes the best distribution in different modes.
  • Order preparations can be done in several ways:
  • a preparer In mono or multi-zone preparation mode in which a preparer can be assigned to one or more areas of the storage space 30. Thus, it is responsible for preparing partial orders located in his area.
  • the supervisor validates the assignment and the itinerary is calculated for each batch of orders to be made by the preparer.
  • iti ner files are generated for compression (PDF format) or for download on the terminal 31.
  • the supervisor In the case where a priority order arrives during the day, the supervisor has the possibility of assigning it to a preparer in priority mode, and will then be the next order processed by this preparer.
  • the processing means 43 arranged to calculate an optimized travel time are also arranged to calculate statistics for the supervisor and concerning in particular the products ordered, their situations in the storage space 30 and as information about the preparers.
  • the set of parameters proposed by the configuration means of the local server comprise at least one parameter indicating whether the preparation of the commands must be carried out in a Z or U mode.
  • U-mode means a mode in which the preparer completes a radius entirely before turning and moving to the opposite radius.
  • Z-mode means a mode in which the preparer takes products in both radii at once (the Z-mode). The Z mode is applicable in cases where aisles are narrow. It is possible to predict that the default mode of preparation is U-mode.
  • the set of parameters proposed by the configuration means of the local server comprise at least one parameter indicating a number of stages of the storage space 30.
  • the code of the location of a product generated during the geolocation comprises additional information N, numeric, determining the level of the stage, arranged for example at the beginning of the code, the format thereof then becoming N-RRR-XX-EE.
  • the Dijkstra algorithm is implemented as an object whose attributes are: ⁇ $ startNode: The starting point.
  • the constructor of the object is of the following form: function Dij kstra (& $ ourMap, $ infiniteDistance) ⁇
  • the findBestPathQ method Parameters $ ourDistance: the $ distance array.
  • $ obp the point to update. This function will traverse all the $ i points of the graph that have infinite distance and update the distance between the $ startNode and the $ obp point if the following conditions are true:
  • $ thi s-> stance [$ i] $ thi s-> stance [$ obp] + $ thi s -> map [$ obp] [$ i];
  • $ returnPVC Pvc :: calculation ($ full_field, $ Hamiltonian,
  • the computation function requires to pass in parameter a complete graph containing the distances between all the points, an existing path passing by all the points and respecting the priorities of sampling, as well as the indices of the elements of the path for which the priority changes.
  • All the points of the path are covered starting with the index 1, so as to impose the position of the starting point (index 0) and not to test inversions with this point.
  • the course of the points ends with the penultimate element so as to impose the point of arrival.
  • the gain of a permutation with the following points in the path is evaluated.
  • a stop value is set so that it can not invert elements with different priorities.
  • the index of the current point is compared with the indices of priorities passed in parameters. Thus, depending on the position of the point, it will be tested with all other points that have the same priority as him.
  • This function will calculate the gain caused by a permutation of the path between the element $ i and $ j.
  • This function will check the order of the indices $ i and $ j and call the function exchange_parcours () on each point between these two indices

Landscapes

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

Abstract

La présente invention a pour objet un système d'optimisation (10) de préparation de commandes de produits à distance caractérisé en ce qu'il comprend une plate-forme (20) de commande en ligne comportant une base de données (21) comprenant une liste de produits ainsi qu'une liste de commandes de produits à préparer par l'utilisateur parmi la liste de produits,un terminal (31) à disposition d'un utilisateur, client ou préparateur de commande, dans un espace de stockage (30) déterminé,un serveur local (40)dédié à l'espace de stockage (3) relié à la plateforme (20) de commande en ligne par des premiers moyens de communication (1) et relié au terminal (31) par des deuxièmes moyens de communication (2), des moyens de traitement (43) agencés pour calculer un temps de parcours optimisé lors de la collecte des produits de la liste de commandes de produits à préparer de la base de données (41) en fonction de l'ensemble de données de géolocalisation des produits dans l'espace de stockage (30) déterminé de la base de données (41).

Description

Système d'optimisation de commandes de produits à distance
La présente invention concerne la préparation d'une commande à partir de produits stockés dans un entrepôt, sur une plateforme ou directement en les prélevant dans les rayons d'un point de vente où lesdits produits sont placés pour une vente en libre-service.
Plus particulièrement, l'invention a pour objet un système d'optimisation de préparation de commandes de produits à distance.
Un tel type de système est mis en place de façon connue dans le cadre d'entrepôts avec de grandes surfaces de stockage ou dans certains hypermarchés qui ont mis en place un service de commande à distance dans l eq uel u n préparateur de commande effectue la collecte des produits commandés à la place du client.
E n pa rt i cu l ie r, d es systè m es d e g est io n d ' e ntre pôt ou WMS (Warehouse Management Systems), connus par exemple sous les marques Reflex® ou Magistore® sont utilisés.
Les systèmes connus sont agencés pour la supervision d'opérations de stockage dans un entrepôt, de prise en compte des commandes et d'optimisation de leur préparation.
Il apparaît toutefois que ces systèmes nécessitent une mise en place longue et complexe et se basent sur un positionnement défini des produits au sein de l'entrepôt qui n'est pas adapté à la préparation d'une commande dans un espace ouvert au libre service, en particulier dans le cadre de point de vente de proximité ou de petite surface.
En conséquence, l'étape de préparation de commande reste une étape longue, pouvant durer environ une heure par commande. Le parcours de l'utilisateur pour la collecte des produits n'est pas optimal car il peut être aléatoire et/ou cloisonné à une liste de produits d'une commande spécifique.
La présente invention a pour but de résoudre tout ou partie des inconvénients mentionnés ci-dessus.
A cet effet, l a présente i nvention a pou r obj et un système d'optimisation de préparation de commandes de produits à distance caractérisé en ce qu'il comprend : - une plate-forme de commande en ligne comportant une base de données comprenant une liste de produits,
- un terminal à disposition d'un utilisateur, client ou préparateur de commande, dans un espace de stockage déterminé,
- un serveur local dédié à l'espace de stockage relié à la plateforme de commande en ligne par des premiers moyens de communication et relié au terminal par des deuxièmes moyens de communication,
ledit serveur local dédié comprenant :
- des moyens de gestion de flux de données agencés pour permettre l'échange de données entre d'une part la plate-forme de commande en ligne et le serveur local et d'autre part entre le terminal et le serveur local,
- une base de données pour stocker des données reçues et transmises par le serveur local, ladite base de données comportant :
- une liste de produits présents dans l'espace de stockage déterminé, et fournie par la base de données de la plate-forme de commande en ligne,
- une liste de commandes de produits à préparer par l'utilisateur parmi la liste de produits, fournie par la base de données de la plate-forme de commande en ligne, et récupérable par le terminal,
- un ensemble de données de géolocalisation des produits dans l'espace de stockage déterminé, cet ensemble de données de géolocalisation des produits dans l'espace de stockage étant fourni à partir du terminal de l'utilisateur,
- un ensemble de données de modélisation de l'espace de stockage,
- des moyens de traitement agencés pour calculer un temps de parcours optimisé lors de la collecte des produits de la liste de commandes de produits à préparer de la base de données en fonction de l'ensemble de données de géolocalisation des produits dans l'espace de stockage déterminé de la base de données.
Les dispositions selon l'invention définissent un système de commande à distance optimisé par le biais de la plate forme de commande en ligne permettant à des utilisateurs d'effectuer la collecte de produits au sein d'un ou de plusieurs espaces de stockages. Le système est adapté à des espaces de stockages de toute taille, notamment à des points de vente de toute taille, sans nécessiter un placement fixe des produits.
Il est à noter qu'au sens de la présente invention, on entend par utilisateur notamment un préparateur(s) de commande effectuant une collecte pour un ou plusieurs clients ou, un client cherchant à optimiser son temps de parcours pour effectuer ses achats à l'intérieur du ou des espaces de stockages.
Selon un aspect de l'invention, les moyens de traitement calculent un temps de parcours optimisé en fonction de plusieurs paramètres parmi :
- les types de produit à préparer,
- la configuration spatiale de l'espace de stockage,
- le nombre de préparateurs disponibles,
- le temps imparti pour la préparation des commandes. Selon un aspect de l'invention, la base de données comporte une l iste de commandes de prod u its préparés, fou rn ie par le terminal, et récupérable par la base de données de la plate-forme de commande en ligne.
Selon un aspect de l'invention, le serveur local comprend des moyens de modélisation de l'espace de stockage, notamment une application graphique, agencés pour générer l'ensemble de données de modélisation de l'espace de stockage.
Cette disposition permet de repérer plus facilement les zones, les rayons et les étagères à l'intérieur d'un point de vente dans ou sur lesquelles se trouvent les différents produits à commander.
Selon un aspect de l'invention, le serveur local comprend des moyens de configuration agencés pour permettre un réglage de tout ou partie d'un ensemble de paramètres par un superviseur de l'espace de stockage.
Selon un aspect de l 'invention , l'ensemble des paramètres proposés par les moyens de configuration du serveur local comprennent au moins un paramètre parmi :
- la finesse de la géolocalisation,
- le cas échéant, l'utilisation ou non des moyens de modélisation,
- la largeur des étagères,
- l'ajout d'utilisateurs,
- les chemins d'import des flux de données et d'accès aux scripts d'import. Cette disposition permet d'adapter le système à la configuration spatiale de chaque espace de stockage.
Selon un aspect de l'invention, la liste de géolocalisation comprend une série de produits identifiés avec un code alphanumérique correspondant à leur emplacement dans l'espace de stockage.
Cette disposition permet d'élaborer un codage simple permettant de repérer facilement un produit à l'intérieur du point de vente.
Selon un aspect de l'invention, le terminal est du type assistant numérique personnel ou ordiphone.
Selon un aspect de l'invention, le système comporte en plus du premier terminal, un deuxième terminal à disposition d'un superviseur de l'espace de stockage relié au serveur local par des troisièmes moyens de communication.
Selon un aspect de l'invention, le serveur local comprend des moyens d'aide à la décision agencés pour proposer sur le deuxième terminal du su perviseu r de l 'espace de stockage une affectation optimale des commandes de produits à préparer par l'utilisateur, notamment en fonction de plusieurs modes de préparation intégrant par exemple le nombre de préparateurs disponibles et le temps imparti pour la préparation des commandes.
Selon un aspect de l'invention, le deuxième terminal est du type micro ordinateur ou ordiphone.
Selon un aspect de l'invention, les moyens de traitement agencés pour calculer un temps de parcours optimisé sont également agencés pour calculer des statistiques à destination du superviseur et concernant notamment les produits commandés, leurs situations dans l'espace de stockage ainsi que des informations sur les préparateurs.
Selon un aspect de l'invention, les statistiques comprennent au moins une donnée parmi :
- le temps de préparation d'une commande : temps moyen par jour, par mois ou sur une période et courbe d'évolution,
- l e temps de préparation d'une commande par mode de préparation, notamment en mode mono-commande ou multi-commande et/ou mono-zone ou multi-zone, et par mode de livraison,
- le temps de préparation d'une commande par préparateur ainsi que le classement des préparateurs, - le temps moyen de préparation par produit,
- le taux de rupture de stock des produits,
- le taux de substitution d'un produit par un autre,
- l e nombre de produits moyen par commande, notamment par période, ainsi que son évolution, et/ou
- l e nombre de produits moyen par commande et par type de commande, notamment livraison à dom icil e ou retrait dans l'espace de stockage.
Selon un aspect de l'invention, les moyens de traitement utilisent plusieurs algorithme dont :
- la matrice d'adjacence,
- l'algorithme de Dijkstra, et
- l'algorithme inhérent au problème du voyageur de commerce.
De toute façon, l'invention sera bien comprise à l'aide de la description qui suit, en référence au dessin schématique annexé représentant, à titre d'exemple non limitatif, un système selon l'invention.
La figu re 1 est un schéma synoptiq ue il l ustrant un mode de réalisation d'un système 10 selon l'invention.
Comme illustré à la figure 1 un système 1 0 comprend une plate- forme 20 de commande en ligne par exemple de la marque Proxi-Store® et un terminal 31 à disposition d'un utilisateur, client ou préparateur de commande, dans un espace de stockage 30 déterminé.
La plate-forme 20 de commande en ligne comprend une base de données 21 comprenant une l iste de produ its présents dans un espace de stockage 30 déterm iné a insi qu'une l iste d e commandes de produits à préparer, les commandes ayant été effectuées à distance par des clients de la plate-forme 20 de commande en ligne.
L'espace de stockage 30 est géré par un ensemble de superviseurs qui gèrent à l e u r to u r un ensemble de préparateurs de commandes de l'espace de stockage 30 déterminé.
En outre, le système 1 0 comprend un serveur local 40 dédié à l'espace de stockage 30 déterminé.
Le serveur local 40 est relié à la plate-forme 20 de commande en ligne par des premiers moyens de communication 1 , par exemple du type réseau Internet. Le serveur local 40 est rel ié au term inal 31 par des deuxièmes moyens de communication 2, par exemple du type sans fil ou bien filaire.
Le terminal 31 peut par exemple être un PDA ou bien une imprimante fournissant une liste de produit à préparer dans un fonctionnement du système 10 selon un mode dégradé décrit plus loin dans le texte.
L'util isateur peut être un préparateur de commande effectuant la préparation de la commande d'un client ou bien un client lui-même prélevant ses propres produits commandés dans les différents rayons de l 'espace de stockage 30 ou zone de préparation 30, par exemple un entrepôt sec, un entrepôt frais, un fournisseur extérieur...
De plus, dans le mode de réal isation présenté à la figure 1 , le système 10 comprend des troisièmes moyens de communication 3 avec un deuxième terminal 32 à disposition d'un superviseur de l'espace de stockage 30.
Les troisièmes moyens de communication 3 peuvent par exemple par exemple être du type sans fil ou bien filaire.
Le deuxième terminal 32 peut par exemple être un micro ordinateur ou bien un PDA.
En outre, le système 10 comprend des moyens de configuration 45 du système 10 agencés pour permettre un réglage de tout ou partie d'un ensemble de paramètres par un superviseur de l'espace de stockage 30.
Ces paramètres sont envoyés vers le deuxième terminal 32 d u superviseur via les troisièmes moyens de communication 3. Ces paramètres sont détaillés plus loin dans le texte.
Le système 10 comprend également des moyens de gestion 42 de flux de données comprenant des scripts d'import de données et agencés pour gérer le contenu d'une base de données 41 du serveur local 40.
Dans le mode de réalisation présenté, cette base de données 41 comporte notamment :
- une l iste de produ its présents dans l 'espace de stockage 30 déterminé, et fournie par la base de données 21 de la plate forme 20 de commande en ligne,
- une liste de commandes de produits à préparer par l'utilisateur, fournie par la base de données 21 de la plate forme 20 de commande en ligne et récupérable par le terminal 31 de l'utilisateur, - une l iste de commandes de produits préparés, fournie par le terminal 31 de l'utilisateur et récupérable par la base de données 21 de la plate-forme 20 de commande en ligne, et
- un ensemble de données de géolocalisation des produits dans l'espace de stockage 30 déterminé.
La liste de commandes de produits préparés n'est pas essentielle au bon fonctionnement du système 10 mais permet néanmoins un retour d'informations vers la plate-forme 20 de commande en ligne permettant de renvoyer au cl ient des informations su r le su ivi de l a préparation de sa commande.
L'ensemble de données de géolocalisation des produits dans l'espace de stockage 30 est fourni par le terminal 31 après qu'un préparateur ait enregistré sur son terminal 31 , les données de géolocalisation de chacun des produits présents dans l'espace de stockage 30.
Cette étape, détaillée plus loin dans le texte, n'est réalisée qu'une seule fois ou chaque fois qu'un produit est déplacé dans l'espace de stockage 30.
Enfin, le système comprend des moyens de traitement 12 agencés pour calculer un temps de parcours optimisé lors de la collecte des produits de la liste de commandes de produits à préparer de la base de données 41 en fonction de l'ensemble de données de géolocalisation des produits dans l'espace de stockage 30 déterminé de la base de données 41 .
Ces moyens de traitement 12 sont de préférence constitués par un microprocesseur.
La base de données 21 comprend également un ensemble de données de modélisation de l'espace de stockage 30.
Pa r défa ut, le serveur local 40 propose des moyens de modélisation 13, déta illés pl us loin dans le texte, permettant de générer l 'ensem ble de don nées de modél isation de l 'espace de stockage 30, et facilitant ainsi le repérage des produits à l'intérieur de l'espace de stockage 30 notamment grâce à une application graphique.
En o u t re , l e serveur local 40 comprend des moyens de configuration 45 agencés pour permettre un réglage de tout ou partie d'un ensemble de paramètres par un superviseur de l'espace de stockage 30. La config u ration d u serveur local 40 par les moyens de configuration 45 peut être utile lors de l'association du serveur local 40 à un espace de stockage 30 particulier.
Ces moyens de configuration 45 permettent à un superviseur de cet espace de stockage 30 de configurer des paramètres globaux tels que :
- la finesse de la géolocalisation,
- le cas échéant, l'utilisation ou non des moyens de modélisation,
- la largeur des étagères,
- l'ajout d'utilisateurs,
- les chemins d'import des flux et d'accès aux scripts d'import.
Une mod ification d'un de ces paramètres, à l'exception des informations concernant les bases de données et les utilisateurs, entraîne une nouvelle géolocalisation des produits dans l'espace de stockage 30.
Le superviseur de l'espace de stockage 30 est invité sur son micro- ordinateur 32 à choisir la finesse avec laquelle sont repérés les produits dans l'espace de stockage 30. Cette finesse pourra être de l'ordre du rayon, du segment dans le rayon ou de l'étagère dans le segment.
Un rayon peut comprendre plusieurs segments correspondant à des portions divisant longitudinalement le rayon, chaque segment pouvant comprendre plusieurs étagères superposées.
Le système 10 peut fonctionner selon un mode dégradé, dans le cas où l'ensemble de données de modélisation de l'espace de stockage 30 ne seraient pas d ispon ibles. D a n s c e ca s , l'utilisateur doit quand même géolocaliser les produits mais dans un ordre logique de prélèvement. En effet, sans l'ensemble de données de modél isation de l'espace de stockage 30, l'optimisation du parcours du préparateur est impossible, et est fait par ordre alphabétique des codes de géolocalisation détaillée plus loin dans le texte.
Par défaut, la largeur de l'étagère est de 1 m10. Mais il est possible de modifier ce paramètre lors de la configuration du système 1 .
Lors de la mise en place du système 10 dans l'espace de stockage
30, différents administrateurs en charge du développement du système 10 dans l'espace de stockage 30 sont ajoutés. Les utilisateurs, tels que les préparateurs sont ajoutés par la suite, de même que les superviseurs.
Les chemins d'import des flux et d'accès aux scripts d'import doivent également être renseignés lors de la configuration du serveur local 40 à l'espace de stockage 30. Notamment, les dossiers contenant les fichiers produits et commandes ainsi que les adresses urls des scripts permettant de les récupérer depuis la plate-forme 20 de commande en ligne doivent être précisés.
En fonction de la finesse de géolocalisation choisie, les produits sont identifiés avec un code correspondant à leur emplacement. Ce code est par exemple formé de 3 parties : RRR-XX-EE, avec :
RRR : Numérique, détermine le rayon,
XX : Alphabétique, détermine le segment,
EE : Numérique, détermine l'étagère.
Par exemple, dans le cas d'un espace de stockage 30 choisissant la finesse de géolocalisation de l'ordre du segment, un produit se trouvant dans le premier étage, dans le cinquième rayon et dans le segment B, le serveur local 40 par l'intermédiare de ses moyens de traitement 43 lui attribue automatiquement 005-B-O comme code de géolocalisation.
Lors du déploiement du système 10 dans l'espace de stockage 30, le géolocalisateur active le mode de géolocalisation sur le terminal 31 . Dans ce mode, le géolocalisateur peut scanner les produits à géolocaliser et indiquer leurs emplacements par rayon, segment et étagère le cas échéant en fonction de la finesse de géolocalisation choisie.
Le term inal 31 util isé par le géolocal isateur incarné par les préparateurs de l'espace de stockage 30, est avant tout simple et intuitif. En effet, le processus de géolocalisation est relativement fastidieux, c'est pourquoi cette interface s'attache à simplifier le plus possible le travail du géolocalisateur. Dans le but de limiter le nombre de manipulations lors de cette phase, des conventions sont mises en place :
- l e d é b u t d e c h a q u e rayo n se t ro u ve à l a g a u ch e d u géolocalisateur lorsqu'il se trouve en face du rayon,
- la première étagère dans le segment est celle se trouvant en haut,
- lorsque le géolocalisateur atteint le niveau maximal de géolocalisation (soit le rayon, soit le segment, soit l'étagère), le géolocalisateur peut scanner les produits dans l'ordre qu'il désire étant donné que tous les produits à ce niveau là possède le même code de géolocalisation,
- la numérotation des segments est incrémentée automatiquement à la fin du traitement d'un segment, et
- chaque segment est de largeur fixe (celle de l'étagère). Pour que le système 10 soit complètement opérationnelle, tous les produits de l'espace de stockage 30 doivent être scannés. Au lancement du mode de géolocalisation, les données sur les géolocalisations existantes sont chargées sur le terminal 31 du géolocalisateur et déchargées en fin de géolocalisation dans la base de données 41 du serveur local 40.
Le processus de géolocalisation peut être réalisé en plusieurs fois. De pl us, un produ it peut être situé à différents endroits dans l'espace de stockage 30, il comporte alors différents codes de géolocalisation en fonction de son emplacement dans l'espace de stockage 30.
Après la phase de géolocalisation , on dispose du nombre de rayons dans l'espace de stockage 30 et de leur taille (nombre de segments dans le rayon). Une application graph ique générée par les moyens de modélisation 44 permet alors de placer ces rayons les uns par rapport aux autres pour modéliser au mieux l'espace de stockage 30, et une indication sur les produits contenus dans les rayons permettra de faciliter ce placement. Les rayons peuvent être composés d'éléments, à savoir des segments et des étagères, de tailles et de formes différentes, deux rayons différents pouvant éventuellement être superposés.
Ce placement se fait par rapport aux caisses qui sont modélisées dans le bas de l'espace de modélisation. Des obstacles redimensionnables pourront également être ajoutés pour empêcher le préparateur de passer à l'endroit où est positionné l'obstacle. Quand le placement est terminé, les coordonnées des rayons sont enregistrées dans la base de données 41 .
Il est ensuite proposé de créer des zones regroupant plusieurs rayons, ainsi que d'ajouter des priorités de passages et des priorités d'effectifs à ces zones. Un rayon ne peut appartenir qu'à une seule zone et une zone ne peut appartenir qu'à un seul étage. Un écran de synthèse récapitule toutes les informations concernant les rayons et les zones telles que le nombre et libellé des rayons par zone, les rayons hors zone, etc. Chaque rayon peut être ordonnancé par rapport aux autres rayons pour spécifier les contraintes de priorité. Par exemple le rayon contenant les boissons fera parti des premiers rayons.
Etant donné que les rayons sont des obstacles infranchissables, ceux-ci doivent être contournés pour calculer l'itinéraire. Les moyens de traitement 43 utilisent donc des points de passages obligatoires pour entrer ou sortir d'un rayon. Ces points de passage, sont placés automatiquement par la personne modélisant l'espace de stockage 30.
Le modélisateur est un superviseur voire un administrateur qui peut effectuer cette modélisation à distance pour la transmettre ensuite vers des quatrièmes moyens de communication 4 compris dans le serveur local 40.
A parti r d e ces points, les différentes allées de l 'espace de stockage 30 par lequelles le préparateur peut passer sont déterminées. Il est alors possible de tracer le graphe qui permet de calculer l'itinéraire de la campagne de collecte des produits dans l'espace de stockage 30.
La modélisation de l'espace de stockage 30 est un processus long et fastidieux qui ne doit être effectué qu'une seule fois (sauf changement physique des rayons au sein d u magasin) . Pour cela, les moyens de modélisation 44 n'impliquent pas les produits mais seulement les étagères, les segments, et les rayons.
Cependant, il est nécessaire qu'une géolocalisation soit au préalablement effectuée ou qu'une liste de rayon soit rentrée ou importée par un superviseur ou un administrateur. Les données de géolocalisation des produits vont fournir la liste des rayons du magasin, ainsi que le nombre de segments qu'ils comportent et le nombre d'étagères par segment. A partir de ces informations, une liste de rayons à modéliser est obtenue avec des tailles différentes (proportionnelles au nombre de segments dans le rayon). Ces informations vont faciliter la modélisation. En effet, l'utilisateur ne devra pas ajouter des rayons, définir leurs tailles, le nombre de segments et le nombre d'étagères par segment car toutes ces informations seront déjà connues grâce à la phase de géolocalisation.
Il est possible que l'administrateur puisse modifier la modélisation ultérieurement. Cependant, le calcul des chemins, détaillé ci après, est relancé à chaque modification . De plus, une commande « réinitialiser » permet à l'administrateur de remettre à zéro la modélisation. Cependant, l'ancienne modélisation est sauvegardée dans la base de données 41 pour pouvoir la récupérer en cas d'erreur.
Les moyens de traitement 43 du serveur local 40 utilisent différents algorithmes pour le calcul des chemins :
- calcul de la matrice d'adjacence.
- calcul du plus court chemin entre deux points (algorithme de
Dijkstra). - calcul du chemin optimal reliant plusieurs points (Problème du voyageur de commerce).
La modélisation graphique de l'espace de stockage 30 signifie que l'utilisateur peut positionner les rayons les uns par rapport aux autres tels qu'ils le sont réellement dans l'espace de stockage 30.
Ainsi , pou r pouvoir déterm iner les chemins des préparations, l'espace de stockage 30 est modélisé sous forme d'un graphe connexe où les sommets sont les points de prélèvement ainsi que les points virages des rayons, et les arêtes sont les segments reliant les points.
Pour ce faire, chaque point est testé avec tous les autres points du graphe de façon à trouver les segments entre les points qui ne coupent pas un rayon ou un obstacle. Cette phase est fastidieuse et dépend du nombre de points, car chaque point et chaque rayon ou obstacle ajouté augmente sérieusement la complexité.
Le langage de développement des algorithmes utilisés par les moyens de tra itement 43 est par exemple l e l a ng ag e P H P (Personal HomePage). Bien entendu, d'autres langages de programmation peuvent être utilisés.
Un tableau en PHP est en fait une carte ordonnée. Une carte est un type qui associe des valeurs en clés.
Les graphes en langage PHP sont représentés par des tableaux à deux dimensions, où les clés sont les sommets du graphe et le contenu est la d istance entre chaque point. La notation diffère pour les points qui sont injoignables. Dans notre cas, par convention, si la distance vaut 1 000 000, les deux points sont injoignables.
Un exemple du calcul de la matrice d'adjacence d'un graphe est proposé en annexe.
De la même man ière, le graphe de l'espace de stockage 30 (les arêtes) est construit, et la matrice d'adjacence (calcul des d istances) est remplie.
Plus le nombre de points et de rayons est grand, plus le temps nécessaire pour remplir cette matrice sera long. Une optimisation possible est donc de limiter le périmètre à tester autour de chaque point.
En effet, si la distance entre le point en cours et un autre point est supérieure à une certaine distance, ce point sera considéré comme à l'infini et l'intersection entre le segment qu'il forme avec le point en cours et un rayon ou un obstacle ne sera pas testée.
De même, si la distance entre le point en cours et un rayon ou un obstacle est supérieure à une certaine distance, l'intersection avec cet élément ne sera pas testée non plus, puisque le segment entre le point en cours et le point testé sera plus court que la distance à l'élément.
La matrice d'adjacence va permettre de savoir s'il est possible de relier un point de passage à un autre point de passage sans couper un objet.
L'algorithme de Dijkstra permet quant à lui de calculer le plus court chemin reliant un point à un autre. Il s'applique sur un graphe connexe dont les arêtes sont pondérées. Autrement dit, l'algorithme a besoin d'une matrice d'adjacence comme celle décrite précédemment.
Maintenant que les distances sont connues pour relier les points de passage entre eux, une implémentation de Dijkstra est utilisée pour connaître la meilleure route à utiliser pour rejoindre un point de passage qui n'est pas relié directement à un autre.
Cet algorithme est donc appliqué sur tous les points du graphe, exceptés les points virage, qui ne sont jamais des points de départ ou d'arrivée de chemin puisqu'ils ne correspondent pas à des produits mais seulement à des points intermédiaires. Pour les points qui sont directement accessibles (par exemple dont la. distance est inférieure à 1 000 000 dans la matrice d'adjacence), le chemin est préservé. Tandis que pour les points injoignables, l'algorithme cherche le plus court chemin les reliant.
Plusieurs méthodes joi ntes en an nexe permettent par cet algorithme de Dijkstra de trouver le plus court chemin entre deux points.
Une fois le plus court chemin entre deux points déterminé, les moyens de traitement 43 calculent le chemin optimal reliant plusieurs points, ce qui revient à résoudre le problème du voyageur de commerce.
Le problème du voyageur de commerce est un problème complexe qui consiste à parcourir tous les points d'un graphe et revenir au point de départ, de façon à réaliser le chemin le plus cours possible. Cependant, ce problème n'est pas soluble avec une approche linéaire combinatoire dans un temps acceptable. Des algorithmes heuristiques sont donc utilisés.
Dans le cas présent, le parcours se fait sur tous les produits en partant d'un point de départ et en arrivant à un point d'arrivée pouvant être différent. De plus, une priorité de prélèvement indiqué par l'utilisateur doit être respectée entre les différents produits. L'algorithme utilisé par les moyens de traitement 43 prend donc en compte ces éléments.
Dans le cas présent, c'est le temps de calcul qui est primordial et non pas l'optimalité à 100% du résultat. En effet, à cause des priorités de passage, des trajets sont rallongés par rapport au parcours réellement optimal ne prenant pas en compte les priorités de prélèvement. Une légère marge d'erreur sur l'optimalité de la solution trouvée est acceptable.
Le choix s'est donc orienté vers un algorithme 2-opt qui donne des temps de réponses très courts tout en garantissant une solution approchée assez proche de l'optimalité.
Cet algorithme prend en entrée un graphe complet ainsi qu'un chemin existant entre tous les points qui respecte l'ordre des priorités. Les indices de changement de priorité sont également nécessaires.
Cet algorithme consiste à permuter deux arêtes dans le graphe si cela provoque une amélioration globale de la distance parcourue. En pratique, cette inversion consiste à retourner le chemin entre deux points.
Pour cela, le graphe est parcouru en entier et pour chaque point, la conséquence d'une permutation avec un point situé plus loin dans le graphe est testée. S'il y a une amélioration, l'inversion est effectuée et le parcours est poursuivi. Tant qu'il y a au moins une amélioration dans le parcours du graphe, le parcours complet du graphe est recommencé.
Pour appliquer cet algorithme au problème, il faut cependant lui appliquer deux modifications majeures :
- il faut imposer le point de départ et le point d'arrivée, - il ne faut pas inverser deux arêtes qui relient des points ayant une priorité différente.
Quelques méthodes permettant l'implémentation de cet algorithme sont proposées en annexe.
Dans un mode de réal isation , le serveur local 40 comprend également des moyens d'aide à la décision 46 des superviseurs qui permet une affectation optimale des commandes de la liste des commandes à préparer de la base de données 41 aux différents préparateurs.
Ces moyens d'aide à la décision 46 prennent en compte le nombre de préparateurs disponibles ainsi que le temps imparti pour la préparation des commandes. En fonction de ces paramètres, ces moyens 46 proposent une solution au superviseur des préparateurs, en affecta nt l es différentes commandes (ou commandes partielles) aux différents préparateurs. Cette affectation peut ensuite être modifiée à la convenance du superviseur.
Il est possible de paramétrer les moyens d'aide à la décision 46 en précisant le ou les modes de préparations dans lesquels on souhaite opérer. Ainsi, dans le cas où le superviseur souhaite n'utiliser qu'un seul mode de préparation, ce paramètre est stocké et utilisé pour chaque affectation. Par défaut, tous les modes de préparations sont utilisables. Si plusieurs modes sont sélectionnés, le système 10 optimise au mieux la répartition dans différents modes.
Les préparations de commandes peuvent se faire de plusieurs façons :
- en mode dégradé dans lequel le préparateur imprime la liste des commandes à préparer durant sa campagne de collecte des produits dans l'espace de stockage 30, de préférence en format PDF. Il est également possible de regrouper plusieurs commandes pour une campagne de collecte des produits dans l'espace de stockage 30,
- en mode mono commande dans lequel un préparateur est chargé de préparer une seule commande durant sa campagne de préparation. Une fois terminée, il revient à la zone de départ, dépose son terminal 31 et la prochaine commande à préparer est chargée sur son terminal 31 ,
- en mode multi commande dans lequel un préparateur peut préparer plusieurs commandes à la fois. Ces dern ières sont groupées par zones et sont traitées comme une seule commande,
- en mode mono ou multi zones de préparation dans lequel un préparateur peut être affecter à une ou plusieurs zones de l 'espace de stockage 30. Ainsi, il est chargé de préparer des commandes partielles situées dans sa zone.
Une fois que les commandes sont réparties et regroupées, le superviseur valide l'affectation et l'itinéraire est calculé pour chaque lot de commandes à effectuer par préparateur. A la fin du calcul, des fichiers d ' iti n éra i res sont gén érés pou r i m press ion (format PDF) ou pour téléchargement sur le terminal 31 .
Dans le cas où une commande prioritaire arrive en cours de journée, le superviseur a la possibilité de l'affecter à un préparateur en mode prioritaire, et sera alors la prochaine commande traitée par ce préparateur. Enfin, dans un mode de réalisation, les moyens de traitement 43 agencés pour calculer un temps de parcours optimisé sont également agencés pour calculer des statistiques à destination du superviseur et concernant notamment les produ its commandés, leurs situations dans l 'espace de stockage 30 ainsi que des informations sur les préparateurs.
Ces statistiques permettent d'afficher une évolution ou d'effectuer des comparaisons. Les superviseurs peuvent aussi avoir la possibilité d'exporter ces statistiques.
Ainsi , il est possible d'afficher des statistiques concernant les produits commandés, leurs situations dans l'espace de stockage 30 ainsi que des informations sur les préparateurs.
La l iste ci-dessous énumère de façon non exhaustive quelques exemples de statistiques pouvant être calculées par les moyens de traitement 43 :
- le temps de préparation d'une commande : Temps moyen par jour, par mois ou sur une période et courbe d'évolution,
- le temps de préparation d'une commande par mode de préparation, notamment en mode mono-commande ou multi-commande et/ou mono zone ou multi-zone, et par mode de livraison,
- le temps de préparation d'une commande par préparateur ainsi que le classement des préparateurs,
- le temps moyen de préparation par produit,
- le taux de rupture de stock des produits,
- le taux de substitution d'un produit par un autre,
- le nombre de produits moyen par commande, notamment par période, ainsi que son évolution, et/ou
- le nombre de produits moyen par commande et par type de commande, notamment livraison à domicile ou retrait dans l'espace de stockage 30.
Bien que l'invention ait été décrite en liaison avec des exemples particuliers de réalisation, il est bien évident qu'elle n'y est nullement limitée et qu'elle comprend tous les équivalents techniques des moyens décrits ainsi que leurs combinaisons.
Selon une variante, l'ensemble des paramètres proposés par les moyens de configuration du serveur local comprennent au moins un paramètre indiquant si la préparation des commandes doit être réalisée selon un mode en Z ou en U. On entend par mode en U un mode dans lequel le préparateur termine un rayon entièrement avant de se retourner et passer au rayon opposé. On entend par mode en Z un mode dans lequel le préparateur prélève des produits dans les deux rayons à la fois (le mode en Z). Le mode en Z est applicable dans les cas où les allées sont étroites. Il est possible de prévoir que le mode de préparation par défaut soit le mode en U.
Selon une variante, l'ensemble des paramètres proposés par les moyens de configuration du serveur local comprennent au moins un paramètre indiquant un nombre d'étages de l'espace de stockage 30. Dans ce cas, le code de l'emplacement d'un produit généré lors de la géolocalisation comprend une information additionnelle N, numérique, déterminant le niveau de l'étage, disposée par exemple au début du code, le format de celui-ci devenant alors N- RRR-XX-EE.
Annexes
1. La matrice d'adiacence :
Exemple du calcul de la matrice d'adjacence d'un graphe en langage de développement PHP :
Soit un graphe comportant 5 sommets nommés (A, B, C, D, E) et représenté comme suit :
Figure imgf000020_0001
La matrice d'adjacence de ce graphe est donc
A B c D E
A 0 1 4 1000000 1
B 1 0 1000000 2 1
C 4 1000000 0 1 2
D 1000000 2 1 0 1
E 1 1 2 1 0
2. L'algorithme de Dijkstra :
L'objet :
L'algorithme de Dijkstra est implémenté sous forme d'un objet dont les attributs sont : · $startNode : Le point de départ.
• $visited: Tableau, clés = les points du graphe, valeurs = true si le point a été visité, false sinon.
• $distance : Tableau, clés = les points du graphe, valeurs = les distances séparant le point de départ aux autres points.
· $previousNode : Tableau, clés = les points du graphe, valeurs = le point précédent la clé.
• $map : La matrice d'adjacence du graphe. • $infinteDistance : La distance représentant l'infini.
• $bestPath : Le chemin le plus court entre deux points.
Le constructeur de l'objet est de la forme suivante : function Dij kstra ( &$ourMap, $infiniteDistance) {
$this -> infiniteDistance = $infiniteDistance; $this -> map = &$ourMap;
$this -> bestPath = 0 ;
}
Il va définir la distance représentant l'infini, la matrice d'adjacence et initialiser le meilleur chemin à 0. Les différentes méthodes de l'objet Dijkstra sont décrire ci-après.
La méthode findShortestPathQ :
Paramètres
$start : le point de départ.
Valeur de retour
$distance : Tableau des distances entre le point $start et tous les autres points. Cette méthode va dans un premier temps initialiser l'attribut
$startNode par le paramètre $start.
Ensuite, elle va parcourir tous les autres points du graphe et mettre à jour le tableau $distance en positionnant toutes les valeur du tableau $visited à false sauf celle du $startNode. Enfin, pour tous les points, le tableau $previousNode sera rempli avec le $startNode. Cela correspond à une phase d'initialisation.
Par la suite, tous les points seront parcourus tant qu'il existera au moins un point non visité et la méthode findBestPathQ , puis la méthode updateDistanceAndPreviousQ seront appelées sur ces points.
La méthode findBestPathQ Paramètres $ourDistance : le tableau $distance.
$ourNodesLeft : les points non encore visités.
Valeur de retour
$bestNode
Cette fonction va parcourir tous les points non encore visités et retourner le point ayant la plus courte distance vers notre point de départ. La méthode updateDistanceAndPreviousO
Paramètres
$obp : le point à mettre à jour. Cette fonction va parcourir tous les points $i du graphe qui ont une distance infinie et mettre à jour la distance entre le $startNode et le point $obp si les conditions suivantes sont vérifiées :
• La distance entre $startNode et $obp est définie dans la matrice d'adjacence.
• La distance entre $startNode et $obp est différente de l'infini ou, différente de 0 dans la matrice d'adjacence.
• La somme de la d istance entre le $startNode et $obp dans le tableau $distance et la distance entre $obp et $i dans la matrice d'adjacence est inférieure à la distance entre le $startNode et $i dans le tableau $distance.
Si toutes ces conditions sont vérifiées alors :
$thi s->di stance [ $i ] = $thi s->di stance [ $obp ] + $thi s -> map [ $obp ] [ $ i ] ;
$thi s->previousNode [ $i ] = $obp ;
La méthode getResultsO
Valeur de retour
$path : Matrice contenant le chem in entre le $startNode et chaque point Cette fonction va parcourir tous les points du graphe et retracer pour chaque point le chemin inverse vers le point de départ. Si le chemin existe, ce chemin sera ensuite retourné et renvoyé dans le tableau Spath, sinon le texte « no route » sera retourné.
3. Implémentation de l'algorithme résolvant le problème du voyageur de commerce :
Utilisation :
$retourPVC = Pvc :: calcul ( $graphe_complet, $Hamiltonien,
$indicel ,
$indice2 ) ;
La fonction calcul nécessite de passer en paramètre un graphe complet contenant les distances entre tous les points, un chemin existant passant par tous les points et respectant les priorités de prélèvement, ainsi que les indices des éléments du chemin pour lesquels la priorité change.
La méthode calcuK)
Paramètres
$graphe_complet le graphe complet
$Hamiltonien le chemin existant
$indice1 l ' ind ice d u prem ier élément ayant u ne priorité moyenne
$indice2 l ' ind ice d u prem ier élément ayant u ne priorité faible
Valeur de retour
$Hamiltonien le chemin ordonné par l'algorithme Cette fonction va ordonner le chemin $Hamiltonien de façon à rendre la distance de parcours de tous les points la plus faible possible.
Tant q ue la boucle provoque un changement su r le chemin $Hamiltonien, une itération sera effectuée de façon à ce qu'il ne soit plus possible de trouver d'amélioration avec l'algorithme.
Tous les points du chemin sont parcourus en commençant à l'indice 1 , de façon à imposer la position du point de départ (indice 0) et ne pas tester des inversions avec ce point. De la même manière, le parcours des points se termine à l'avant dernier élément de façon à imposer le point d'arrivée. Pour chaque point, le gain d'une permutation avec les points suivants dans le chemin est évalué. Cependant, une valeur d'arrêt est définie de façon à ne pas pouvoir inverser d'éléments qui ont des priorités différentes. Pour cela, l'indice du point en cours est comparé avec les indices des priorités passés en paramètres. Ainsi, en fonction de la position du point, il sera testé avec tous les autres points qui ont la même priorité que lui.
Enfin, à l'aide de la fonction difference_cout(), l'amélioration que provoquerait l'inversion des deux points en cours est évaluée.
Si le gain est positif, il n'y a pas d'amélioration et le parcours des points va donc continuer.
Si le gain est négatif, c'est qu'il y a une amélioration et le chemin entre ces deux points va donc être renversé grâce à la fonction renverse _parcours() , puis le parcours des points sera repris.
A la fin, si le chemin a été modifié, le parcours recommence, sinon le chemin optimisé est renvoyé.
La méthode différence coutQ
Paramètres
$i l'indice de l'élément en cours
$j l'indice de l'élément testé
$graphe le graphe complet
$Hamiltonien le chemin existant Valeur de retour
Valeur du gain global provoqué par la permutation (négatif si le chemin est plus court)
Cette fonction va calculer le gain que provoque une permutation du chemin entre l'élément $i et $j.
Si le point testé n'est pas le dernier du chemin, le calcul suivant sera effectué :
Distance entre le point d'indice $/' et le point suivant l'indice $j + Distance entre le point précédent l'indice $i et le point d'indice $j - Distance entre le point précédent l'indice $i et le point d'indice $i
Distance entre le point d'indice $j et le point suivant l'indice $j
Si le point testé est le dernier, le calcul suivant sera effectué :
Distance entre le point précédent l'indice $/' et le point d'indice $j Distance entre le point précédent l'indice $i et le point d'indice $i
La méthode renverse parcoursO
Paramètres
$i : l'indice de l'élément en cours
$j : l'indice de l'élément testé
$Hamiltonien : le chemin existant
Valeur de retour
$Hamiltonien : le chemin mis à jour après retournement du chemin
Cette fonction va vérifier l'ordre des indices $i et $j et appeler la fonction echange_parcours() sur chaque point entre ces deux indices
La méthode échange parcoursO Paramètres
$ordre1 : l'indice du premier élément à inverser
$ordre2 : l'indice du deuxième élément à inverser $Hamiltonien : le chemin existant
Valeur de retour
$Hamiltonien : le chemin mis à jour après permutation de deux points
Cette fonction va inverser les deux points $ordre1 et $ordre2 dans le chemin $Hamiltonien.

Claims

REVENDICATIONS
1 . Système d'optimisation (10) de préparation de commandes de produits à distance caractérisé en ce qu'il comprend :
- une plate-forme (20) de commande en ligne comportant une base de données (21 ) comprenant u ne l iste de prod u its ainsi qu'une liste de commandes de produits à préparer par l'utilisateur parmi la liste de produits,
- un terminal (31 ) à disposition d'un utilisateur, client ou préparateur de commande, dans un espace de stockage (30) déterminé,
- un serveur local (40) déd ié à l'espace de stockage (3) relié à la plateforme (20) d e com m a nd e en l ig n e pa r d es p rem iers moyens de communication (1 ) et rel ié au terminal (31 ) par des deuxièmes moyens de communication (2),
ledit serveur local (40) comprenant :
- une base de données (41 ) pour stocker des données reçues et transmises par le serveur local (40), ladite base de données (41 ) comportant :
- une liste de produits présents dans l'espace de stockage (30) déterminé, et fournie par la base de données (21 ) de la plate-forme (20) de commande en ligne,
- une liste de commandes de produits à préparer par l'utilisateur parmi la liste de produits, fournie par la base de données (21 ) de la plateforme (20) de commande en ligne, et récupérable par le terminal (31 ),
- un ensemble de données de géolocalisation des produits dans l 'espace de stockage (30) déterm iné, cet ensem bl e de don nées de géolocalisation des produits dans l'espace de stockage (30) étant fourni à partir du terminal (31 ) de l'utilisateur,
- un ensemble de données de modélisation de l'espace de stockage (30),
- des moyens de traitement (43) agencés pour calculer un temps de parcours optimisé lors de la collecte des produits de la liste de commandes de produits à préparer de la base de données (41 ) en fonction de l'ensemble de données de géolocalisation des produits dans l'espace de stockage (30) déterminé de la base de données (41 ).
2. Système (10) selon la revend ication 1 , dans lequel les moyens de traitement (43) calculent un temps de parcours optimisé en fonction de plusieurs paramètres parmi : - les types de produit à préparer,
- la configuration spatiale de l'espace de stockage (30),
- le nombre de préparateurs disponibles,
- le temps imparti pour la préparation des commandes.
3. Système (10) selon l'une des revendications 1 à 3, dans lequel la base de données (41 ) comporte une liste de commandes de produits préparés, fou rn i e pa r le terminal (31 ), et récu pérable par la base de données (21 ) de la plate-forme (20) de commande en ligne.
4. Système (10) selon l'une des revendications 1 à 3, dans lequel le serveur local (40) comprend des moyens de modél isation (44) de l'espace de stockage (30), notamment une application graphique, agencés pou r générer l 'ensemble de données de modélisation de l'espace de stockage (30).
5. Système (10) selon l'une des revend ications 1 à 4, dans leq uel le serveu r local (40) comprend des moyens de configuration (45) agencés pour permettre un réglage de tout ou partie d'un ensemble de paramètres par un superviseur de l'espace de stockage (30).
6. Système (10) selon la revendication 5, dans lequel l'ensemble des paramètres proposés par les moyens de configuration (45) du serveur local (40) comprennent au moins un paramètre parmi :
- la finesse de la géolocalisation,
- le cas échéant, l'utilisation ou non des moyens de modélisation (44),
- la largeur des étagères,
- l'ajout d'utilisateurs,
- les chem ins d' import des fl ux de données et d 'accès aux scripts d'import.
7. Système (10) selon l'une des revend ications 1 à 6, dans lequel la liste de géolocalisation comprend une série de produits identifiés avec un code alphanumérique correspondant à leur emplacement dans l'espace de stockage (3).
8. Système (10) selon l'une des revend ications 1 à 7, dans lequel le terminal (31 ) est du type assistant numérique personnel ou ordiphone.
9. Système (10) sel o n l ' u n e d es reven d i catio n s 1 à 8, comportant en plus du premier terminal (31 ), un deuxième term inal (32) à disposition d'un superviseur de l'espace de stockage (30) relié au serveur local (40) par des troisièmes moyens de communication (3).
10. Système (10) selon la revend ication 9, dans lequel le serveur local (40) comprend des moyens d'aide à la décision (46) agencés pour proposer sur le deuxième terminal (32) du superviseur de l 'espace de stockage (30) une affectation optimale des commandes de produits à préparer par l'utilisateur, notamment en fonction de plusieurs modes de préparation intégrant par exemple le nombre de préparateurs d isponibles et le temps imparti pour la préparation des commandes.
1 1 . Système (10) selon l'une des revendications 9 à 10, dans lequel le deuxième terminal (32) est du type micro ordinateur ou ordiphone.
12. Système (10) selon l'une des revendications 9 à 1 1 , dans lequel les moyens de traitement (43) agencés pour calculer un temps de parcours optimisé sont également agencés pour calculer des statistiques à destination du superviseur et concernant notamment les produits commandés, leurs situations dans l'espace de stockage (30) ainsi que des informations sur les préparateurs.
13. Système (10) selon la revend ication 12, dans lequel les statistiques comprennent au moins une donnée parmi :
- le temps de préparation d'une commande : temps moyen par jour, par mois ou sur une période et courbe d'évolution,
- l e temps de préparation d'une commande par mode de préparation, notamment en mode mono-commande ou multi-commande et/ou mono-zone ou multi-zone, et par mode de livraison,
- le temps de préparation d'une commande par préparateur ainsi que le classement des préparateurs,
- le temps moyen de préparation par produit,
- le taux de rupture de stock des produits,
- le taux de substitution d'un produit par un autre,
- le nombre de produits moyen par commande, notamment par période, ainsi que son évolution, et/ou
- le nombre de produits moyen par commande et par type de commande, notamment livraison à domicile ou retrait dans l'espace de stockage (30).
14. Système (10) selon l'une des revendications 1 à 13, dans lequel les moyens de traitement (43) utilisent plusieurs algorithme dont :
- la matrice d'adjacence,
- l'algorithme de Dijkstra, et
- l'algorithme inhérent au problème du voyageur de commerce.
PCT/FR2012/051778 2011-07-26 2012-07-26 Système d'optimisation de commandes de produits à distance WO2013014397A1 (fr)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
FR1156784 2011-07-26
FR1156784A FR2978578A1 (fr) 2011-07-26 2011-07-26 Systeme d’optimisation de commandes de produits a distance

Publications (1)

Publication Number Publication Date
WO2013014397A1 true WO2013014397A1 (fr) 2013-01-31

Family

ID=46717893

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/FR2012/051778 WO2013014397A1 (fr) 2011-07-26 2012-07-26 Système d'optimisation de commandes de produits à distance

Country Status (2)

Country Link
FR (1) FR2978578A1 (fr)
WO (1) WO2013014397A1 (fr)

Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010151868A2 (fr) * 2009-06-27 2010-12-29 Bacompt Systems, Inc. Système et procédé d'achat

Patent Citations (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2010151868A2 (fr) * 2009-06-27 2010-12-29 Bacompt Systems, Inc. Système et procédé d'achat

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
KOUROUTHANASSIS P ET AL: "Developing consumer-friendly pervasive retail systems", IEEE PERVASIVE COMPUTING, IEEE SERVICE CENTER, LOS ALAMITOS, CA, US, vol. 2, no. 2, 1 April 2003 (2003-04-01), pages 32 - 39, XP011097591, ISSN: 1536-1268, DOI: 10.1109/MPRV.2003.1203751 *
OLIVIER BOURGEOIS: "Store-Picking / Entrepôt Centric :comment choisir entre ces 2 modèles ?"", 1 February 2011 (2011-02-01), pages 1 - 4, XP002669527, Retrieved from the Internet <URL:http://web.archive.org/web/20110201115748/http://lalettredue-tailing.com/n02/index.html> [retrieved on 20120214] *

Also Published As

Publication number Publication date
FR2978578A1 (fr) 2013-02-01

Similar Documents

Publication Publication Date Title
US11461732B2 (en) Logistics apparatus and method to assist delivery of items to recipients
EP3329447B1 (fr) Procédé de mise à jour de données d&#39;association entre des articles et des emplacements
EP2280871B1 (fr) Procede et systeme de depose automatique d&#39;objets en vue du transport desdits objets
US20130103539A1 (en) Intelligent shopping assistant
WO2019158862A1 (fr) Dispositif de stockage d&#39;objets, et procédé mettant en œuvre un tel dispositif
US20210065115A1 (en) Computer-implemented logistics method
US20140095221A1 (en) Systems and method for providing recommendations
CN110347777A (zh) 一种兴趣点poi的分类方法、装置、服务器及存储介质
US10317230B2 (en) Machine learning travel management system with wearable device integration
FR3023610A1 (fr)
CN105612537A (zh) 在线自助预订工具和第三方系统搜索结果的集成
EP4070295A1 (fr) Système et procédé de détection de fraude
FR3048093A1 (fr) Procede de gestion d&#39;acheminement de colis, et systeme informatique de gestion et conteneurs associes
WO2013014397A1 (fr) Système d&#39;optimisation de commandes de produits à distance
FR3079040A1 (fr) Systeme et procede de fourniture de produits
FR2807191A1 (fr) Systeme de consigne pour deposer et recuperer un objet
FR3063171A1 (fr) Gestion de donnees hors standard dans un systeme de gestion de donnees contexte
FR3104297A1 (fr) Dispositifs, systèmes et procédés pour fournir des objets auxiliaires à partir d&#39;une antémémoire et des objets de fournisseur catégorisés
FR3089670A1 (fr) Dispositif de stockage d’objets, et procédé mettant en œuvre un tel dispositif
FR2990543A1 (fr) Systeme et procede de transport de marchandises par vehicules circulant sur route
WO2016083101A1 (fr) Procede et systeme de gestion de consignes de livraison, et installation de livraison mettant en oeuvre un tel procede et/ou un tel systeme
FR3026521A1 (fr) Systeme et procede informatique d&#39;acquisition et de gestion d&#39;informations archeologiques de terrain
Ventura E-commerce last-mile deliveries strategy optimization for rural areas
FR3141453A1 (fr) Procédé d’affectation d’un emballage à une unité de charge logistique
FR3141452A1 (fr) Procédé de préparation d&#39;une unité de charge logistique à emballer

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: 12748746

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: 12748746

Country of ref document: EP

Kind code of ref document: A1