Retail Pro est un logiciel de caisse haut de gamme assez répandu chez les enseignes de grande envergure, de par sa capacité à être adapté dynamiquement au niveau de l'interface utilisateur, des données et des process (de vente, commandes, mouvements de stock...).
De plus, il est possible de greffer des développements spécifiques répondant aux événements de création de fiches, changement de champs, ajouts de produits, validation etc... Ces événements interceptés par le plugin peuvent proposer à l'utilisateur un dialogue et ensuite modifier des champs dans la fiche en cours, ajouter ou supprimer des produits, des réductions, des moyens de paiement...
En dix ans, j'ai réalisé une quarantaine de plugins pour Retail Pro 8 et Retail Pro 9. La grosse différence entre les deux systèmes se situe au niveau de la technologie nécessaire pour construire les plugins, et les API pour échanger des données avec Retail Pro.
Dans la v8, il est obligatoire d'utiliser exactement le même environnement de développement que l'éditeur, à savoir Delphi v5 (sorti en 1999). Il faut alors créer une bibliothèque un peu spéciale, une BPL (Borland Pascal Library), qui a la particularité de pouvoir être chargée et liée dynamiquement au programme principal. L'accès aux données doit obligatoirement passer par l'API spéciale, car le système de base utilisé par RP8 est propriétaire, basé sur des fichiers locaux. Il n'y a pas de serveur centralisé, donc plusieurs caisses d'un même magasin ont chacun leur liste de ventes, sauf si un répertoire réseau unique est utilisé pour les données, ce qui ne manque pas de créer quelques particularités si deux caisses (ou plugins) modifient la même fiche. Dans le cadre du projet Global Blue, la fonction de consolidation de plusieurs ventes dans un même bordereau de détaxe a ainsi nécessité la mise en place d'un protocole de communication inter-plugins pour synchroniser les données. La plupart du temps cependant, cette architecture décentralisée n'a aucune importance pour les plugins qui ne travaillent que sur le périmètre d'une seule fiche à la fois.
Dans la v9, le choix de l'environnement de développement est totalement libre, tant que celui-ci permet de créer des librairies/objets COM. L'API de communication avec RP9 est aussi une interface COM. J'ai utilisé Delphi 7 puis assez rapidement Delphi XE pour ces développements. D'autre part, les données de Retail PRO 9 sont gérées par une BD Oracle. Outre donc la possibilité d'agir en lecture/écriture sur les données via l'API, il est possible de faire des requêtes en lecture directement dans la base de données, pour peu qu'on connaisse le Modèle de données. Ceci est autrement plus efficace pour récupérer, en une requête SQL modifiable/paramétrable, une masse d'information d'un coup comme la liste des produits achetés et leurs caractéristiques, plutôt que demander les valeurs une par une par une boucle en code dur. Les plugins peuvent même utiliser un espace réservé dans la base pour créer leurs propres tables et stocker leurs données, ce qui est très pratique.
Si je ne devais retenir qu'un exemple de projet de ce type, sans hésitation ce serait Global Blue, un projet d'envergure internationale et étalé sur plusieurs années, qui m'a obligé à exploiter toutes les capacités du système, puis à les repousser, bien au-delà de ce que les distributeurs Retail Pro dans le monde ont l'habitude de voir.