Application C# en tant que complément au logiciel de point de vente existant

1. Est-ce possible ?

Sur n’importe lequel Appareil de point de vente ? NON.

L’appareil de point de vente le plus répandu dans le monde est une bonne vieille caisse enregistreuse. Vous ne pouvez pas exécuter une application C# là-dessus.

Les prochains appareils de point de vente les plus courants dans le monde sont probablement les systèmes de point de vente propriétaires fournis par des sociétés comme NCR et installés chez les grands détaillants. Ils n’exécutent pas nécessairement Windos, et même s’ils le font, ils ne seront pas configurés pour vous permettre d’installer des modules complémentaires tiers.

Votre petite et moyenne entreprise moyenne utilise une caisse enregistreuse ou a acheté un appareil de point de vente à quelqu’un comme NCR ou HP qui leur a également vendu le logiciel qui l’exécute. Au minimum, le logiciel suit l’inventaire ou génère des rapports de ventes. Et ce même fournisseur dispose d’une option logicielle qui permettra de suivre des détails supplémentaires – et elle est déjà intégrée et fonctionne avec ce système. Il est peu probable que ces fournisseurs soient très incités à vous proposer une API ouverte à ajouter à leur système – et il est également peu probable que votre entreprise moyenne prenne le risque d’opter pour une solution tierce si elle peut l’obtenir auprès du même fournisseur. .

Alors, que ciblez-vous ?

En fait, allez trouver un appareil POS pour lequel vous souhaitez développer votre application.

S’agit-il simplement d’un lecteur de codes-barres, d’un lecteur de bande magnétique et d’un logiciel fonctionnant sur un ordinateur Windows ?

Dans ce cas, OUI, c’est possible en fonction de la quantité de travail que vous souhaitez effectuer.

(Mais avant d’aller plus loin, découvrez si quelqu’un utilisera réellement ce que vous avez en tête. Combien d’entreprises disposent de ce type de système de point de vente ? Le fournisseur d’origine propose-t-il déjà une option logicielle similaire à celle que vous avez en tête ? Enquêtez auprès de certains des entreprises et découvrez si (a) elles ont besoin ou veulent ce que vous avez en tête et (b) si elles l’achèteraient auprès de vous plutôt que auprès du vendeur d’origine.)

2. Si la réponse à la question 1 est oui, peut-il y avoir deux logiciels capables de recevoir des événements depuis un appareil POS ? Comme le code-barres scanné ?

OUI, mais vous devrez peut-être écrire votre propre pilote de périphérique pour le faire.

Il est peu probable que le logiciel de point de vente existant dispose d’une API ouverte à partir de laquelle vous pouvez simplement obtenir les données. Il est également peu probable que les auteurs originaux du logiciel de point de vente aient conçu le système avec l’idée de partager le lecteur de bande magnétique et le lecteur de codes-barres avec un autre logiciel.

Si tel est le cas, vous pouvez toujours remplacer les pilotes de périphérique existants pour ces périphériques (ou, peut-être plus simplement, ajouter un pilote à la chaîne de pilotes de périphérique pour les périphériques) afin de pouvoir intercepter les données du périphérique lorsqu’elles sont transmises au serveur. autre progiciel.

(Pour vous donner une idée de ce dont je parle, voici un article de projet de code sur l’interception des frappes :

Surveillance des frappes[^]

L’interception de données provenant d’un autre appareil est peut-être plus complexe, mais les concepts sont les mêmes.)

Si vous devez écrire un pilote au niveau du noyau pour faire ce que vous voulez, vous finirez par l’écrire en C ou C++ natif plutôt qu’en C#.

Donc les réponses sont :

Oui c’est possible.
MAIS, à moins qu’il n’y ait une raison vraiment impérieuse de le faire, cela ne vaut pas la quantité de travail impliquée.

C’est tout à fait possible ! Familiarisez-vous avec la façon dont les composants du point de vente fonctionnent ensemble. 1) Interface POS sur laquelle travaille le caissier. 2) EPS ou le système de paiement qui se connectera au terminal POS, au clavier NIP, au lecteur de code-barres, à la balance et se connectera au processeur/banque, etc. Découvrez le formatage du paquet TCP/IP car de nombreux processeurs utilisent un réseau spécifique protocole – du XML à une sorte de protocole TLV, etc. Créez une application client/serveur pour intercepter le paquet provenant de l’EPS allant au processeur, extrayez les données nécessaires que vous souhaitez stocker dans une base de données et transmettez le paquet au processeur, recevez ensuite la réponse du processeur et renvoyez-la au point de vente.
REMARQUE : tout cela suppose qu’aucun cryptage n’est impliqué ! De plus, avec cette approche, vous ne connaîtrez pas les transactions en espèces, par chèque ou par carte-cadeau, car elles peuvent être traitées par différents processeurs, à moins que vous n’ajoutiez un « renifleur » pour chaque destination possible.

POS—>EPS—->VOTRE SNIFFER—>Processeur—>Banque : Et puis retour.