FR3112636A1

FR3112636A1 - Procédé de gestion de transactions d’achat d’au moins un produit en vrac et dispositif pour sa mise en œuvre

Info

Publication number: FR3112636A1
Application number: FR2007405A
Authority: FR
Inventors: Sébastien LEFLOND
Original assignee: Individual
Current assignee: Individual
Priority date: 2020-07-15
Filing date: 2020-07-15
Publication date: 2022-01-21
Also published as: WO2022012914A1; EP4182874A1

Abstract

Procédé de gestion de transactions d’achat d’au moins un produit en vrac et dispositif pour sa mise en œuvre L'invention a pour objet un procédé de gestion de transactions d’achat d’au moins un produit en vrac (12) avec un contenant (10), caractérisé en ce qu’il comprend une étape de pesage lors de laquelle un identifiant unique « contenant » présent sur le contenant (10) rempli est lu et stocké dans une base de données « transactions » associé à au moins une donnée permettant d’établir un prix du produit en vrac (12) contenu dans le contenant (10) et une étape de passage en caisse lors de laquelle, pour déterminer le prix du produit en vrac (12) contenu dans le contenant (10), l’identifiant unique « contenant » du contenant (10) est lu et converti en un code numérique à partir des données contenues dans la base de données « transactions » associées à l’identifiant unique « contenant » lu. Figure 6

Description

Procédé de gestion de transactions d’achat d’au moins un produit en vrac et dispositif pour sa mise en œuvre

La présente demande se rapporte à un procédé de gestion de transactions d’achat d’au moins un produit en vrac ainsi qu’à un dispositif pour sa mise en œuvre.

Selon un mode opératoire, une transaction d’achat d’un produit en vrac comprend une première étape de pesage du contenant vide avec une balance qui génère une première étiquette autocollante sur laquelle est imprimé un code à barres comportant le poids du contenant vide. Cette première étiquette est ensuite collée sur le contenant vide.

En suivant, la transaction comprend une étape de remplissage du contenant avec un produit en vrac, une étape de lecture du code à barres de la première étiquette avec un lecteur de code à barres d’une balance pour qu’elle tienne compte du poids du contenant vide lors du calcul du poids du produit en vrac contenu dans le contenant ainsi qu’une étape de pesage du contenant et du produit avec la balance et de saisie de la référence produit. La balance génère alors une deuxième étiquette autocollante sur laquelle est imprimé un code à barres intégrant la référence du produit et son poids dont le format est normé de manière à pouvoir être lu par différents terminaux d’encaissement. Cette deuxième étiquette est collée sur le contenant rempli.

La transaction comprend une dernière étape de passage en caisse, lors de laquelle le code à barres de la deuxième étiquette est lu par le lecteur de code à barres d’un terminal d’encaissement. A partir de la référence du produit et de son poids, ce dernier détermine le prix du produit contenu dans le contenant pour finaliser la transaction.

Selon un autre mode opératoire, la transaction comprend, après l’étape de remplissage du contenant, une étape de pesage du contenant et du produit contenu dans le contenant avec une balance et de saisie de la référence du produit afin que la balance génère une deuxième étiquette autocollante sur laquelle est imprimé un code à barres comportant la référence du produit et le poids du produit et du contenant dont le format est normé de manière à pouvoir être lu par différents terminaux d’encaissement.

La transaction comprend enfin une étape de passage en caisse, lors de laquelle les codes à barres des première et deuxième étiquettes sont lus par le lecteur de code à barres d’un terminal d’encaissement qui, à partir des informations contenues dans les deux codes à barres, détermine le poids du produit en vrac et son prix.

Quel que soit le mode opératoire, il est nécessaire d’utiliser deux étiquettes et de les scanner toutes les deux ce qui requiert de devoir modifier la balance ou le terminal d’encaissement. De plus, le client doit systématiquement peser le contenant préalablement à son remplissage même si ce dernier a déjà été utilisé.

La présente invention vise à remédier à tout ou partie des inconvénients de l’art antérieur.

A cet effet, l’invention a pour objet un procédé de gestion de transactions d’achat d’au moins un produit en vrac avec un contenant, caractérisé en ce qu’il comprend :

une étape de pesage lors de laquelle un identifiant unique « contenant » présent sur le contenant rempli du produit en vrac est lu et stocké dans une base de données « transactions » associé à au moins une donnée permettant d’établir un prix du produit en vrac contenu dans le contenant à partir d’un poids du produit en vrac mesuré ou déterminé et d’un identifiant unique « produit » du produit en vrac acquis lors de l’étape de pesage, et
une étape de passage en caisse lors de laquelle, pour déterminer le prix du produit en vrac contenu dans le contenant, l’identifiant unique « contenant » du contenant rempli du produit en vrac est lu et converti en un code numérique, compréhensible par un terminal d’encaissement, à partir des données contenues dans la base de données « transactions » associées à l’identifiant unique « contenant » lu.

Cette solution permet de pouvoir utiliser les balances et les terminaux d’encaissement existants du fait que les étapes de pesage et de passage en caisse utilisent un même et unique identifiant ou code à savoir l’identifiant unique « contenant ».

D'autres caractéristiques et avantages ressortiront de la description de l’invention qui va suivre, description donnée à titre d'exemple uniquement, en regard des dessins annexés parmi lesquels :

est une représentation schématique d’un contenant vide pesé sur une balance illustrant une étape d’une transaction d’achat d’un produit en vrac,

est une représentation schématique d’un contenant en cours de remplissage illustrant une étape d’une transaction d’achat d’un produit en vrac,

est une représentation schématique d’un contenant rempli pesé sur une balance illustrant une étape d’une transaction d’achat d’un produit en vrac,

est une représentation schématique de bases de données « transactions », « contenants » et « produits »,

est une représentation schématique d’un contenant rempli scanné lors d’un passage en caisse illustrant une étape d’une transaction d’achat d’un produit en vrac,

est une représentation schématique d’un dispositif de gestion de transactions d’achat d’au moins un produit en vrac illustrant un mode de réalisation de l’invention,

est une représentation d’un code matriciel converti en un code à barres,

est une représentation schématique d’une partie d’un dispositif de gestion de transactions illustrant un autre mode de réalisation de l’invention,

est une représentation schématique d’une partie d’un dispositif de gestion de transactions illustrant un autre mode de réalisation de l’invention.

Sur les figures 1 à 3, 5, 6 et 10, on a représenté en 10 un contenant utilisé pour acheter un produit en vrac 12.

Selon une application, le produit en vrac est un produit alimentaire comportant des éléments ou des particules solides, comme des pâtes, des graines, des céréales, de la farine ou autres. Bien entendu, l’invention n’est pas limitée à cette application. Le produit en vrac pourrait être liquide, comme de l’huile par exemple, et ne pas être alimentaire, comme des produits de mercerie ou des produits de quincaillerie par exemple.

Le produit en vrac 12 peut être stocké de différentes manières. Selon une application, le produit en vrac 12 est conditionné dans un réservoir 14 avec une ouverture en partie inférieure, comme un silo par exemple, permettant un écoulement par gravité du produit en vrac 12 du réservoir 14 vers un contenant 10.

Selon un mode de réalisation, au moins un réservoir 14 comprend une commande 16 pour contrôler l’écoulement du produit en vrac 12, configurée pour occuper un état fermé dans lequel la commande 16 interdit tout écoulement du produit en vrac 12 et un état ouvert dans lequel la commande 16 autorise un écoulement du produit en vrac 12 en dehors du réservoir 14. Cette commande 16 peut être actionnée manuellement ou de manière motorisée.

Généralement, un lieu de vente propose plusieurs produits en vrac chacun d’eux étant stocké dans un réservoir et étant associé à un identifiant unique « produit » IDP1 à IDP5, à un prix par une unité de mesure (poids, volume,…) PX1 à PX5, comme illustré sur la figure 4.

A titre d’exemple, l’identifiant unique « produit » IDP1 à IDP5 est une référence produit sous la forme d’un nombre de cinq chiffres. Bien entendu, l’invention n’est pas limitée à ce format pour l’identifiant unique « produit » IDP1 à IDP5.

Quel que soit le format, pour chaque produit, l’identifiant unique « produit » IDP1 à IDP5 est associé à un prix par unité de mesure PX1 à PX5 dans une base de données « produits » 18 visible sur la figure 4.

Le contenant 10 peut être de toute forme et réalisé en différentes matières, comme en verre, en plastique par exemple. Il comprend une ouverture permettant son remplissage et un obturateur, comme un couvercle 20 par exemple, pour obturer l’ouverture.

Ce contenant 10 a un poids, appelé tare, qui n’est pas négligeable au regard du poids du produit en vrac contenu et impacte le prix d’achat du produit en vrac 12.

Selon une caractéristique de l’invention, chaque contenant 10 comprend un identifiant unique « contenant » ID1 à ID6 qui lui est propre. Ainsi, les contenants 10 ont tous des identifiants uniques « contenant » ID1 à ID6 différents. Cet identifiant unique « contenant » ID1 à ID6 est conservé sur le contenant 10 et peut être utilisé lors de plusieurs transactions faites en utilisant le contenant 10.

Selon un mode de réalisation visible sur la figure 7, l’identifiant unique « contenant » ID1 à ID6 est un code matriciel 22, appelé également QR code, imprimé sur une étiquette autocollante 24 apposée sur le contenant 10. En variante, l’identifiant unique « contenant » ID1 à ID6 pourrait être gravé ou apposé sur le contenant 10 par tout autre moyen. De même, l’invention n’est pas limitée à ce mode de réalisation pour l’identifiant unique « contenant » ID1 à ID6. L’identifiant unique « contenant » pourrait être un code alphanumérique ou être incorporé dans une puce RFID.

Selon un mode opératoire visible sur la figure 1, le procédé de gestion des transactions d’achat d’au moins un produit en vrac comprend une étape d’association d’un l’identifiant unique « contenant » ID1 à ID6 d’un contenant 10 et du poids PD1 à PD6 du contenant 10 dans une base de données « contenants » 26, visible sur la figure 4.

Selon un mode opératoire non limitatif, l’identifiant unique « contenant » ID1 à ID6 du contenant 10 est lu grâce à un lecteur 28 et le contenant 10 est pesé grâce à une balance 30. En suivant, l’identifiant unique « contenant » ID1 à ID6 lu et le poids du contenant 10 pesé sont associés dans au moins une base de données «contenants» 26. Selon un mode de réalisation, le lecteur 28 est intégré à la balance 30 qui comprend une unité de stockage 32 pour stocker la base de données «contenants» 26. Cette base de données «contenants» 26 peut être dupliquée et stockée dans au moins une unité centralisée 34 distante de la balance 30 et/ou dans d’autres balances.

Bien entendu, l’invention n’est pas limitée à ce mode opératoire pour l’étape d’association du poids et de l’identifiant unique « contenant » de chaque contenant 10 dans une base de données « contenants » 26. Ainsi, l’identifiant unique « contenant » et le poids du contenant 10 pourraient être saisis manuellement.

Cette étape d’association de l’identifiant unique « contenant » et du poids pour chaque contenant 10 n’est réalisée qu’une fois et n’a pas besoin d’être répétée à chaque transaction. Ainsi, un contenant 10 est toujours identifié avec le même identifiant unique « contenant ». Par conséquent, dans le cas d’un identifiant unique « contenant » imprimé sur une étiquette autocollante 24, cette dernière n’a pas besoin d’être décollée pour être remplacée par une nouvelle étiquette entre deux transactions.

Lorsque cette étape d’association de l’identifiant unique « contenant » et du poids a été faite pour un contenant 10, ce dernier peut être utilisé et rempli d’un produit en vrac 12, comme illustré sur la figure 2. Avant d’être pesé, le contenant 10 est refermé avec son couvercle 20 si nécessaire.

Comme illustré sur la figure 3, le procédé de gestion des transactions d’achat d’au moins un produit en vrac comprend une étape de pesage du contenant 10 et du produit en vrac contenu dans le contenant 10, ainsi qu’une étape d’association de l’identifiant unique « contenant » ID1 à ID6 du contenant 10 et d’au moins une donnée permettant d’établir le prix du produit en vrac contenu dans le contenant 10 dans une base de données « transactions » 36 visible sur la figure 4.

Selon les configurations, la (ou les) donnée(s) permettant d’établir le prix est (ou sont) :

le prix seul accompagné éventuellement d’un identifiant unique « produit » du produit en vrac contenu dans le contenant 10, ou
un identifiant unique « produit » et le poids du produit.

Selon un premier mode opératoire, le contenant 10 et le produit en vrac 12 contenu dans le contenant 10 sont pesés à l’aide d’une balance 38 qui permet de déterminer le poids du contenant 10 et du produit en vrac 12 contenu dans le contenant 10.

La balance 38 peut être la même que celle ayant permis de peser le contenant 10 vide ou une autre balance.

La balance 38 comprend un système de saisie 40, comme un écran tactile par exemple, pour permettre à un client d’identifier le produit en vrac 12 contenu dans le contenant 10.

Juste avant ou après le pesage du contenant 10 et du produit en vrac 12 contenu dans le contenant 10, l’identifiant unique « contenant » ID1 à ID6 du contenant 10 est acquis. Selon un premier mode opératoire, cette acquisition peut se faire manuellement en saisissant l’identifiant unique « contenant » ID1 à ID6 du contenant 10 à l’aide du système de saisie 40 de la balance 38.

En variante, l’identifiant unique « contenant » ID1 à ID6 du contenant 10 est lu grâce à un lecteur 42 intégré à la balance 38.

Selon un mode de réalisation, pour chaque transaction, l’identifiant unique « contenant » ID1 à ID6 du contenant 10 est associé à un poids PDS1 à PDS6 du produit en vrac 12 contenu dans le contenant 10 et à un identifiant unique « produit » IDP1 à IDP5 saisi par le client grâce au système de saisie 40.

Le poids PDS1 à PDS6 du produit en vrac 12 contenu dans le contenant 10 est calculé en soustrayant, au poids du contenant 10 et du produit en vrac 12 contenu dans le contenant 10 pesé par la balance 38, le poids du contenant 10 qui est retrouvé dans la base de données « contenants » 26 à partir de l’identifiant unique « contenant » ID1 à ID6 acquis lors de l’opération de pesage.

Selon un autre mode de réalisation, pour chaque transaction, l’identifiant unique « contenant » ID1 à ID6 du contenant 10 est associé à un prix du produit en vrac 12 acheté contenu dans le contenant 10 et éventuellement à un identifiant unique « produit » IDP1 à IDP5.

Le prix du produit en vrac 12 contenu dans le contenant 10 est calculé à partir du poids du produit en vrac 12 contenu dans le contenant 10 qui est calculé comme précédemment indiqué et du prix par unité de mesure qui est retrouvé dans la base de données « produits » 18 à partir de l’identifiant unique « produit » IDP1 à IDP6 acquis lors de l’opération de pesage.

Au moment du passage en caisse, le procédé de gestion des transactions d’achat d’au moins un produit en vrac 12 comprend une étape de lecture de l’identifiant unique « contenant » ID1 à ID6 du contenant 10, une étape de conversion de l’identifiant unique « contenant » ID1 à ID6 lu en un code numérique 44 compréhensible par un terminal d’encaissement 46 à partir des données associées à cet identifiant unique « contenant » ID1 à ID6 du contenant 10 retrouvées dans la base de données « transactions » 36 et une étape de détermination du prix à partir du code numérique 44.

Cette étape de lecture de l’identifiant unique « contenant » ID1 à ID6 du contenant 10 est réalisée grâce à un lecteur 48 associé à un terminal d’encaissement 46. Ces deux éléments ne sont pas plus détaillés car ils sont connus de l’art antérieur. Le lecteur 48 est configuré pour lire des codes matriciels 22. Toutefois, l’invention n’est pas limitée à ce format pour l’identifiant unique « contenant ». Par conséquent, le lecteur 48 peut être configuré pour lire d’autres formats pour l’identifiant unique « contenant ».

Si le terminal d’encaissement 46 est configuré pour déterminer des prix à partir de codes à barres de type poids, la base de données « transactions » 36 est structurée de manière à ce que pour chaque transaction, l’identifiant unique « contenant » ID1 à ID6 du contenant 10 soit associé à un identifiant unique « produit » IDP1 à IDP5 et à un poids de produit en vrac 12 contenu dans le contenant 10.

Dans ce cas, comme illustré sur la figure 7, l’identifiant unique « contenant » ID1 à ID6 du contenant 10 est converti en un code numérique 44 comprenant une succession de chiffres, le premier ou les deux premiers chiffre(s) 44.1 permettant d’identifier le format du code (code de type poids ou code de type prix), les cinq chiffres suivants 44.2 correspondant à l’identifiant unique « produit » IDP1 à IDP5, les cinq chiffres suivants 44.3 correspondant au poids PDS1 à PDS5 du produit en vrac 12 acheté contenu dans le contenant 10, le dernier chiffre 44.4 correspondant à un chiffre de contrôle.

Si le terminal d’encaissement 46 est configuré pour déterminer des prix à partir de codes à barres de type prix, la base de données « transactions » 36 est structurée de manière à ce que, pour chaque transaction, l’identifiant unique « contenant » ID1 à ID6 du contenant 10 soit associé à un identifiant unique « produit » IDP1 à IDP5 et au prix du produit en vrac 12 contenu dans le contenant 10.

Dans ce cas, l’identifiant unique « contenant » ID1 à ID6 du contenant 10 est converti en un code numérique 44 comprenant une succession de chiffres, le premier ou les deux premiers chiffre(s) 44.1 permettant d’identifier le format du code (code de type poids ou code de type prix), les cinq chiffres suivants 44.2 correspondant à l’identifiant unique « produit » IDP1 à IDP5, les cinq chiffres suivants 44.3 correspondant au prix du produit en vrac 12 contenu dans le contenant 10, le dernier chiffre 44.4 correspondant à un chiffre de contrôle.

Pour assurer cette conversion, un dispositif de gestion des transactions d’achat d’au moins un produit en vrac comprend un transcodeur 50 qui a accès à ou stocke au moins la base de données « transactions » 36, intercalé entre un lecteur 48 et un terminal d’encaissement 46 et qui est configuré pour convertir un identifiant unique « contenant » ID1 à ID6 lu par le lecteur 48 en un code numérique 44 compréhensible par un terminal d’encaissement 46 à partir des données associées à cet identifiant unique « contenant » ID1 à ID6 du contenant 10 retrouvées dans la base de données « transactions » 36.

Les liaisons entre le lecteur 48, le transcodeur 50 et le terminal d’encaissement 46 peuvent être filaires ou sans fil. Plus généralement, les différents éléments (balance(s), lecteur(s), transcodeur(s), système(s) d’encaissement, unité(s) centralisée(s),..) du dispositif de gestion de transactions peuvent être reliés entre eux par des liaisons filaires ou sans fil et formés un réseau local qui peut être relié à un serveur distant pour stocker des données accessibles via l’application 51 par exemple.

Selon une configuration visible sur la figure 6, le dispositif de gestion des transactions d’achat d’au moins un produit en vrac comprend également au moins une balance 30, 38 associée à ou intégrant un lecteur d’identifiant unique 28, 42 et un système de saisie 40 ainsi qu’au moins un terminal d’encaissement 46 associé à ou intégrant un transcodeur 50 et un lecteur d’identifiant unique 48.

Il comprend également au moins une unité centralisée 34 stockant au moins la base de données « transactions » 36. Le transcodeur 50 peut éventuellement assurer la fonction d’unité centralisée 34.

Les balances 30, 38 d’un même lieu de vente sont configurées pour accéder à ou stocker la base de données « transactions » 36, la base de données « produits » 18, la base de données « contenants » 26.

Les balances 30, 38 sont communicantes et peuvent échanger des données directement entre elles et/ou par l’intermédiaire de l’unité centralisée 34 de manière à ce que les bases de données « transactions » 36 des différentes balances soient toutes synchronisées. Chacune d’elles est configurée pour enregistrer au moment de chaque pesée les données associées à l’identifiant unique « contenant », comme l’identifiant unique « produit » et le poids du produit en vrac contenu dans le contenant 10 ainsi que pour les communiquer aux autres balances et éventuellement à chaque unité centralisée 34.

Ainsi, chaque balance transmet périodiquement aux autres balances et à chaque unité centralisée 34 des données, notamment les données relatives aux dernières transactions de la base de données « transactions » 36 qu’elle stocke afin que les bases de données « transactions » 36 des différentes balances et de chaque unité centralisée 34 soient toutes synchronisées et listent toutes les transactions. De la même manière, les données relatives aux bases de données « produits » et « contenants » sont partagées entre les différentes balances et chaque unité centralisée 34 de manière à ce que les bases de données « produits » et contenants » stockées dans les différentes balances et l’unité centralisée 34 soient toutes synchronisées.

Il en est de même des transcodeurs 50, des terminaux d’encaissement 46 qui sont également communicants de manière à avoir accès aux dernières données des différentes bases de données.

L’invention n’est pas limitée à ce mode opératoire pour les échanges de données entre les différentes éléments du dispositif de gestion des transactions d’achat d’au moins un produit en vrac. Quel que soit les modes opératoires, chaque balance est configurée pour ajouter dans la base de données « transactions » 36 les données relatives à chaque opération de pesage (identifiant unique « contenant », poids et identifiant unique « produit » du produit en vrac contenu dans le contenant 10) associées à un identifiant unique « contenant » lu. En parallèle, chaque transcodeur 50 et/ou chaque terminal d’encaissement 46 est configuré pour extraire de la base de données « transactions » 36 les données associées à un identifiant unique « contenant » lu.

Selon les cas, les bases de données « produits », « contenants » et « transactions » peuvent être dissociées ou être regroupées dans une même base de données et se présenter sous la forme de tables.

Selon un mode de réalisation, lorsque l’identifiant unique « contenant » ID1 à ID6 se présente sous la forme d’un code matriciel 22, ce dernier comprend un repère, comme un préfixe et/ou un suffixe, permettant à chacun des transcodeurs 50 de déterminer si le code matriciel 22 lu est un identifiant unique « contenant » ou non.

De la sorte, si le transcodeur 50 et/ou le lecteur 48 détecte(nt) un repère dans l’identifiant unique « contenant » sous la forme d’un code matriciel 22 alors une requête est formulée de manière à retrouver dans la base de données « transactions » 36 les données associées à l’identifiant unique « contenant ». Si aucun repère n’est détecté, aucune requête n’est formulée. Cette configuration permet d’obtenir un gain de temps en n’analysant pas la base de données « transactions » 36 inutilement si le code matriciel 22 lu ne correspond pas à un identifiant unique « contenant ».

L’unité centralisée 34 permet de centraliser les bases de données « produits », « contenants » et « transactions ». Selon une conception, elle est configurée pour demander de manière périodique, les données relatives aux dernières opérations de pesage réalisées par chaque balance ainsi que pour transmettre le contenu de la base de données « transactions » et éventuellement des autres bases de données « produits » et « contenants » à chaque balance et/ou à chaque terminal d’encaissement, notamment au moment de leurs démarrages.

Un même lieu de vente peut comprendre plusieurs balance(s) 30, 38, plusieurs transcodeurs/unités centralisées 50/34, comme illustré sur la figure 8, et éventuellement plusieurs terminaux d’encaissement 46.

Selon un autre mode de réalisation, pour chaque transaction de la base de données « transactions », l’identifiant unique « contenant » est associé à un identifiant unique « client » C1 à C3 appartenant au client possédant le contenant. En variante, l’identifiant unique « client » C1 àC3 correspond à un identifiant unique d’un panier virtuel comportant le contenant 10.

Selon un mode opératoire, au moment de la pesée du contenant et du produit en vrac contenu dans le contenant 10, l’identifiant unique « client » C1 à C3 est saisi par le client ou acquis par tout moyen approprié de manière à ce que l’identifiant unique « contenant » ID1 à ID6 soit associé à un identifiant unique « produit », IDP1 à IDP5, à un poids PDS1 à PDS6 et à un identifiant unique « client » C1 à C3 dans la base de données « transactions » 36.

Selon un autre mode opératoire ou en complément, pour chaque contenant 10 de la base de données « contenants », l’identifiant unique « contenant » est associé à un poids PD1 à PD6 ainsi qu’à un identifiant unique « client » C1 à C3. Dans ce cas, au moment de l’étape d’association d’un l’identifiant unique « contenant » ID1 à ID6 d’un contenant 10 et du poids PD1 à PD6 du contenant 10 dans une base de données « contenants » 26, l’identifiant unique « client » C1 à C3 est saisi par le client ou acquis par tout moyen approprié de manière à ce que l’identifiant unique « contenant »ID1 à ID6 soit associé à un poids et à un identifiant unique « client » C1 à C3 dans la base de données « contenants».

Selon un mode de réalisation, le dispositif de gestion des transactions d’achat d’au moins un produit en vrac comprend une application 51, installée dans un appareil mobile 52, configurée pour émettre une requête à une unité centralisée 34 et pour afficher le résultat de cette requête.

Selon un mode opératoire, la requête transmise à l’unité centralisée 34 comprend l’identifiant unique « client » C1 à C3. A réception de cette requête, l’unité centralisée 34 collecte les données associées à cet identifiant unique « client » et les transmet à l’appareil mobile 52 à partir duquel émane la requête. En suivant, l’application 51 affiche les données reçues.

Ainsi, il est possible de visualiser les transactions associées à l’identifiant unique « client », pour chacune d’elles le produit acheté, son poids, son prix et toute autre information relative au produit. Il est possible également de visualiser tous les contenants associés à l’identifiant unique « client » et pour chacun d’eux, toutes les transactions réalisées et pour chacune d’elles le produit acheté, son poids, son prix et toute autre information relative au produit.

Bien entendu, l’invention n’est pas limitée à ces informations.

Selon un mode de réalisation, l’identifiant unique « client » est intégré dans un support 54 comme un bracelet, un badge par exemple, de manière à pouvoir être lu par un lecteur.

Selon un mode de réalisation visible sur la figure 9, la commande 16 du réservoir 14 contenant le produit en vrac 12 comprend un système de verrouillage configuré pour occuper un état verrouillé dans lequel la commande 16 est bloquée à l’état fermé et un état déverrouillé dans lequel la commande 16 est libre et peut passer de l’état fermé à l’état ouvert et inversement.

Selon ce mode de réalisation, le réservoir 14 comprend un lecteur 56 configuré pour lire l’identifiant unique « client » intégré dans le support 54.

En parallèle, une base de données « clients » comprend une liste d’identifiants uniques « client » autorisés à se servir.

La commande 16 est configurée pour occuper l’état verrouillé par défaut et pour déterminer à partir de la base de données « Clients » si l’identifiant unique « client » lu est autorisé à se servir et si tel est le cas à passer à l’état déverrouillé.

Selon un mode de réalisation visible sur la figure 10, le dispositif de gestion des transactions d’achat d’au moins un produit en vrac comprend, pour au moins un réservoir 14, un capteur d’effort 58 auquel est suspendu le réservoir 14, permettant de déterminer le poids du réservoir 14 et de son contenu. Lors du remplissage d’un contenant 10, le capteur d’effort 58 mesure le poids du réservoir 14 avant et après le remplissage et détermine le poids versé dans le contenant 10 correspondant à la différence de poids du réservoir 14 entre avant et après le remplissage.

Dans ce cas, le procédé de gestion des transactions d’achat d’au moins un produit en vrac comprend une étape de lecture de l’identifiant unique « contenant » du contenant 10, une étape de détermination du poids versé dans le contenant 10 grâce au capteur d’effort 58, une étape de saisie de l’identifiant unique « produit » du produit versé dans le contenant 10 ainsi qu’une étape d’association pour chaque pesée dans la base de données « transactions » 36 de l’identifiant unique « contenant » du contenant 10, du poids et de l’identifiant unique « produit » du produit en vrac contenu dans le contenant 10.

En variante, la base de données « transactions » comprend pour chaque pesée l’association de l’identifiant unique « contenant », du prix et de l’identifiant unique « produit » du produit en vrac contenu dans le contenant 10.

Le procédé de gestion des transactions d’achat d’au moins un produit en vrac comprend une étape de passage en caisse lors de laquelle l’identifiant unique « contenant » du contenant 10 rempli du produit en vrac 12 est lu et converti en un code numérique 48, au format compréhensible par le terminal d’encaissement 46, à partir des données contenues dans la base de données « transactions » associées à l’identifiant unique « contenant » lu.

Quel que soit le mode opératoire, le procédé de gestion des transactions d’achat d’au moins un produit en vrac comprend une étape de pesage lors de laquelle l’identifiant unique « contenant » du contenant 10 rempli du produit en vrac 12 est lu et stocké dans une base de données « transactions » 36 associé à au moins une donnée permettant d’établir un prix du produit en vrac 12 contenu dans le contenant 10 à partir d’un poids du produit en vrac 12 mesuré ou déterminé et d’un identifiant unique « produit » du produit en vrac 12 acquis lors de l’étape de pesage et une étape de passage en caisse lors de laquelle, pour déterminer le prix du produit en vrac 12 contenu dans le contenant 10, l’identifiant unique « contenant » du contenant 10 rempli du produit en vrac 12 est lu et converti en un code numérique 44, au format compréhensible par le terminal d’encaissement 46, à partir des données contenues dans la base de données « transactions » associées à l’identifiant unique « contenant » lu.

Claims

Procédé de gestion de transactions d’achat d’au moins un produit en vrac (12) avec un contenant (10), caractérisé en ce qu’il comprend une étape de pesage lors de laquelle un identifiant unique « contenant » (ID1 à ID6) présent sur le contenant (10) rempli du produit en vrac (12) est lu et stocké dans une base de données « transactions » (36) associé à au moins une donnée permettant d’établir un prix du produit en vrac (12) contenu dans le contenant (10) à partir d’un poids du produit en vrac (12) mesuré ou déterminé et d’un identifiant unique « produit » du produit en vrac (12) acquis lors de l’étape de pesage et une étape de passage en caisse lors de laquelle, pour déterminer le prix du produit en vrac (12) contenu dans le contenant (10), l’identifiant unique « contenant » (ID1 à ID6) du contenant (10) rempli du produit en vrac (12) est lu et converti en un code numérique (44), compréhensible par un terminal d’encaissement (46), à partir des données contenues dans la base de données « transactions » (36) associées à l’identifiant unique « contenant » (ID1 à ID6) lu.
Procédé de gestion selon la revendication 1, caractérisé en ce que l’identifiant unique « contenant » (ID1 à ID6) est associé à un poids du contenant (10) vide pour chaque contenant (10) dans une base de données « contenants » (26) et en ce que, pour chaque étape de pesage, le poids du produit en vrac (12) contenu dans le contenant (10) est déterminé en soustrayant, à un poids mesuré du contenant (10) et du produit en vrac contenu dans le contenant (10), le poids du contenant (10) associé à l’identifiant unique « contenant » (ID1 à ID6) lu.
Procédé de gestion selon la revendication 1 ou 2, caractérisé en ce que, pour chaque transaction, l’identifiant unique « contenant » (ID1 à ID6) d’un contenant (10) est associé au poids et à un identifiant unique « produit » (IDP1 à IDP5) du produit en vrac (12) contenu dans le contenant (10).
Procédé de gestion selon la revendication précédente, caractérisé en ce que le code numérique (44) comprend un ou deux premier(s) chiffre(s) (44.1) permettant d’identifier le format du code numérique, cinq chiffres suivants (44.2) correspondant à l’identifiant unique « produit » (IDP1 à IDP5), cinq chiffres suivants (44.3) correspondant au poids du produit en vrac (12) contenu dans le contenant (10), un dernier chiffre (44.4) correspondant à un chiffre de contrôle.
Procédé de gestion selon l’une des revendications précédentes, caractérisé en ce que les étapes de pesage sont réalisées par plusieurs balances (30, 38) communicantes, échangeant des données directement entre elles et/ou par l’intermédiaire d’une unité centralisée (34) de manière à ce que les bases de données « transactions » (36) des différentes balances soient toutes synchronisées.
Procédé de gestion selon l’une des revendications précédentes, caractérisé en ce que, pour chaque transaction de la base de données « transactions » (36), l’identifiant unique « contenant » d’un contenant (10) est associé à un identifiant unique « client » (C1 à C3) appartenant à un client possédant le contenant (10).
Procédé de gestion selon la revendication précédente, caractérisé en ce que chaque produit en vrac est stocké dans un réservoir présentant une commande (16) configurée pour occuper un état fermé dans lequel la commande (16) interdit tout écoulement du produit en vrac (12) et un état ouvert dans lequel la commande (16) autorise un écoulement du produit en vrac (12) en dehors du réservoir (14), un système de verrouillage configuré pour occuper un état verrouillé dans lequel la commande (16) est bloquée à l’état fermé et un état déverrouillé dans lequel la commande (16) est libre et peut passer de l’état fermé à l’état ouvert et inversement ainsi qu’un lecteur (56) d’identifiant unique et en ce que la commande (16) est configurée pour occuper l’état verrouillé par défaut et pour déterminer à partir de la base de données « Clients » si l’identifiant unique « client » lu est autorisé à se servir et si tel est le cas à passer à l’état déverrouillé.
Procédé de gestion selon l’une des revendications précédentes, caractérisé en ce que, pour chaque contenant (10), l’identifiant unique « contenant » est un code matriciel (22).
Procédé de gestion selon la revendication précédente, caractérisé en ce que chaque code matriciel (22) comprend un repère afin de déterminer si le code matriciel (22) est un identifiant unique « contenant ».
Procédé de gestion selon la revendication 8 ou 9, caractérisé en ce que chaque code matriciel (22) imprimé sur une étiquette (24) apposée sur le contenant (10).
Dispositif de gestion de transactions d’achat d’au moins un produit en vrac pour la mise en œuvre du procédé de gestion selon l’une des revendications précédentes, caractérisé en ce qu’il comprend au moins une balance (30, 38), associée à ou intégrant un lecteur d’identifiant unique (28, 42) et un système de saisie (40), configurée pour ajouter dans une base de données « transactions » (36), pour chaque opération de pesage, des données relatives à l’opération de pesage associées à un identifiant unique « contenant » lu ainsi qu’au moins un terminal d’encaissement (46), associé à ou intégrant un lecteur d’identifiant unique (48) et un transcodeur (50) qui a accès à ou stocke au moins la base de données « transactions » (36), intercalé entre le lecteur d’identifiant unique (48) et le terminal d’encaissement (46) et qui est configuré pour convertir un identifiant unique « contenant » (ID1 à ID6) lu par le lecteur d’identifiant unique (48) en un code numérique (44) compréhensible par le terminal d’encaissement (46) à partir des données retrouvées dans la base de données « transactions » (36) et associées à l’identifiant unique « contenant » (ID1 à ID6) lu.
Dispositif de gestion selon la revendication précédente, caractérisé en ce qu’il comprend au moins une unité centralisée (34) configurée pour stocker au moins la base de données « transactions » (36), pour demander de manière périodique, des données relatives aux dernières opérations de pesage réalisées par chaque balance ainsi que pour transmettre le contenu de la base de données « transactions » (36) à chaque balance et/ou à chaque terminal d’encaissement.