.jpeg)
Données Fournisseur de Référence : de qui est-ce la responsabilité dans un Groupe de Restauration ?
Les fournisseurs sont créés en amont dans l'ERP d'un Groupe, ressaisis manuellement dans les établissements, puis modifiés localement à chaque changement de prix ou de format de Conditionnement. L'objectif central du déploiement ERP – un référentiel fournisseur unique et fiable – disparaît dans la double saisie qu'il était censé éliminer. La solution ne consiste pas à changer d'outil, mais à trancher quatre questions de paramétrage avant que les deux plateformes ne commencent à communiquer.
Désignez le référentiel, puis verrouillez l'autre côté
Le référentiel d'un fournisseur est le seul système dans lequel les nouvelles données et les modifications peuvent prendre naissance ; tous les autres systèmes consomment cet enregistrement en lecture seule. Dans un Groupe de restauration qui exploite à la fois un ERP et une plateforme opérateur, ce choix doit être fait explicitement, car s'il ne l'est pas, les deux systèmes acceptent des modifications, se désynchronisent mutuellement et la boucle de double saisie se reproduit établissement par établissement.
Trois configurations sont possibles. Seules les deux premières fonctionnent.
| Configuration | Nouveaux fournisseurs créés dans | Modifications de prix et de conditionnement dans | Les utilisateurs des établissements peuvent modifier |
|---|---|---|---|
| ERP comme référentiel | ERP | ERP | Non |
| Plateforme comme référentiel | Plateforme opérateur | Plateforme opérateur | Non |
| Aucun verrou | Les deux | Les deux | Oui |
Lorsque l'ERP détient les données fournisseur côté Finance (conditions de paiement, immatriculation fiscale, coordonnées bancaires), l'ERP est le référentiel et la plateforme opérateur en est le consommateur. Lorsque la plateforme opérateur détient les données côté Approvisionnement (références, formats de conditionnement, tarifs unitaires, couverture des Points de vente), la plateforme peut être le référentiel et l'ERP en consomme les données. La troisième configuration, sans verrou, n'est pas un compromis : c'est l'état que la question de propriété visait à éliminer.
Alignez le schéma du catalogue fournisseur sur ce que l'ERP envoie
Un enregistrement fournisseur qui arrive de l'ERP sous forme d'une ligne unique n'est pas utilisable dans un établissement. Un établissement doit commander dans un format de Conditionnement précis, réceptionner selon une unité de mesure précise et renseigner un code article précis sur la Facture. L'enregistrement doit arriver dans un format portant tous ces champs, faute de quoi l'établissement les complète à la main – ce qui est la double saisie sous une autre forme.
| Champ | Ce qu'il contient | Pourquoi l'établissement en a besoin |
|---|---|---|
| Code article | L'identifiant de base de l'ingrédient dans le catalogue Groupe | Relie la référence du fournisseur à une ligne de Coût matière unique |
| Unité de mesure | L'unité de comptage en rayon (kg, litre, pièce) | Les inventaires et les réceptions doivent être enregistrés dans cette unité |
| Format de Conditionnement | La manière dont le fournisseur vend l'article (carton, plateau, fût) | Les bons de commande sont émis en unités de Conditionnement, pas en unités brutes |
| Facteur de conversion | Le nombre d'unités de comptage par unité de Conditionnement | Convertit automatiquement un prix à l'unité de Conditionnement en coût unitaire |
| Indicateur de disponibilité | Si le fournisseur peut actuellement livrer la référence | Évite de passer une commande qui ne sera pas honorée |
| Code fournisseur | L'identifiant de référence propre au fournisseur | Rapproche la ligne de Facture avec la référence plateforme à la réception |
Chaque référence fournisseur est son propre article dans l'établissement, portant sa propre unité, son Conditionnement, son facteur de conversion, son indicateur de disponibilité et son code fournisseur, relié à l'ingrédient de base correspondant dans le catalogue central du Groupe. C'est ce qui rend l'enregistrement fournisseur de l'ERP opérationnel au Point de vente plutôt qu'un nom que l'établissement doit réinterpréter à chaque bon de commande.
Définissez la lecture seule en établissement via des permissions basées sur les rôles
Si les utilisateurs des établissements modifient les enregistrements fournisseurs localement, c'est rarement parce qu'ils voulaient changer le référentiel. C'est parce que la plateforme leur a donné le bouton. La solution n'est pas la formation des utilisateurs : c'est de désactiver le bouton pour les rôles qui n'en ont pas besoin, tout en conservant la visibilité pour ceux qui doivent voir les prix et les formats de Conditionnement en rayon.
Le contrôle des permissions basé sur les rôles fonctionne comme un arbre de permissions granulaire par module. Les rôles par défaut sont livrés en lecture seule et ne peuvent pas être modifiés ; les administrateurs créent des rôles personnalisés depuis l'arbre, et les dépendances de permissions sont appliquées automatiquement afin qu'un rôle ne puisse pas recevoir une action en aval sans son prérequis en amont. Le paramétrage qui pérennise la propriété est un rôle établissement personnalisé avec lecture sur le module fournisseur et aucune écriture nulle part.
Configurez l'API : l'ERP écrit, la plateforme relit
Lorsque l'ERP est le référentiel, l'intégration n'est pas unidirectionnelle. Deux canaux doivent être configurés séparément et dans des directions opposées ; les confondre est la raison pour laquelle des données maîtres « intégrées » finissent encore par être ressaisies des deux côtés.
En amont, les nouveaux fournisseurs et les modifications transitent de l'ERP vers la plateforme opérateur via les endpoints fournisseurs de la plateforme, de sorte qu'un fournisseur ajouté côté Finance apparaît dans chaque établissement sans étape de ressaisie. En aval, l'Open API de la plateforme opérateur expose les données détaillées des bons de commande (historique du cycle de vie, quantités confirmées et réceptionnées, informations fournisseur enrichies) pour que l'ERP puisse retracer ce qui s'est passé pour chaque enregistrement fournisseur qu'il a transmis. Cette relecture en aval ferme la boucle ; sans elle, l'ERP n'a aucune visibilité sur l'utilisation de ses enregistrements fournisseurs et aucune base pour rapprocher les dépenses par fournisseur.
Préserver l'enregistrement lors des évolutions du parc
La propriété fournisseur est facile à maintenir quand le parc est stable. Elle devient fragile quand un Point de vente ouvre, ferme, change d'enseigne ou change de cuisine centrale, car la plupart des systèmes traitent « quels fournisseurs sont actifs où » comme une liste maintenue manuellement par site.
Lorsque la structure des Points de vente d'une entité de marque change dans la plateforme opérateur, la plateforme recalcule automatiquement quels fournisseurs sont actifs pour chaque ingrédient à chaque site, de sorte qu'un enregistrement fournisseur n'a pas besoin d'être réaffecté site par site à chaque évolution du parc. La décision de propriété prise une fois en amont survit à la réorganisation. Si votre intégration exige de réaffecter les fournisseurs à chaque ouverture ou fermeture de Point de vente, ce n'est pas un problème de parc : c'est un signe que le recalcul s'effectue encore manuellement dans l'ERP et qu'aucun enregistrement central unique n'a jamais existé.
Par où commencer dans votre propre paramétrage
Répondez à ces quatre questions avant de relier l'ERP et la plateforme opérateur. Si l'une des réponses est floue ou « les deux », c'est là que la double saisie reviendra.
Quatre questions de paramétrage. Répondez à chacune avant le début de l'intégration :
- Quel système est le référentiel ? Nommez-le. Partout ailleurs dans le Groupe, l'enregistrement fournisseur est en lecture seule.
- Le schéma de l'enregistrement convient-il ? Code article, unité de mesure, Conditionnement, facteur de conversion, indicateur de disponibilité, code fournisseur – six champs au minimum.
- Les utilisateurs des établissements sont-ils verrouillés en modification ? Par défaut en lecture seule. Rôles personnalisés depuis l'arbre de permissions. Aucun accès en écriture en dessous du siège.
- La direction de l'API est-elle configurée dans les deux sens ? L'ERP écrit les fournisseurs. La plateforme relit les données des bons de commande. Canaux séparés, tous deux requis.
Si l'une des réponses est floue ou « les deux », c'est là que la double saisie reviendra.
- Quel système est le référentiel ? Nommez-le. Partout ailleurs dans le Groupe, l'enregistrement fournisseur est en lecture seule.
- Le schéma de l'enregistrement convient-il ? La partie réceptrice a besoin de l'unité de mesure, du Conditionnement, du facteur de conversion, de l'indicateur de disponibilité et du code fournisseur pour que l'enregistrement soit utilisable en rayon – pas seulement le nom du fournisseur et les conditions de paiement.
- Les utilisateurs des établissements sont-ils verrouillés en modification ? Rôles par défaut en lecture seule, rôles personnalisés depuis l'arbre de permissions, aucun droit de modification sur le module fournisseur en dessous du niveau siège.
- La direction de l'API est-elle configurée dans les deux sens ? L'ERP écrit, la plateforme relit, sur des canaux séparés, tous deux requis.
Le module de gestion des fournisseurs de Supy gère chaque référence fournisseur comme un article distinct avec sa propre unité, son Conditionnement et son facteur de conversion ; son Open API retransmet les données détaillées des bons de commande par fournisseur afin que l'ERP puisse rapprocher ce qui s'est passé pour chaque enregistrement transmis. Combiné avec des permissions basées sur les rôles livrées en lecture seule par défaut, la décision de propriété prise une fois au siège survit à chaque évolution du parc et à chaque rotation de personnel. Si vous travaillez à ceci dans un déploiement en cours, notre guide sur les logiciels d'Approvisionnement pour restaurants couvre la chaîne d'Approvisionnement plus large ; le calculateur ROI gratuit peut aider à construire l'argumentaire pour verrouiller les données fournisseurs au siège.
