Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter
Langage de programmation : Caisse
Salut tt le monde,
en bref, ma question est la suivante :
quels sont les langages de programation les plus utilisés et les plus performants dans les applications qui tournent sur les caisses qu'on trouve dans les restaurant, magasins ,....
et merci d'avance
ça dépend sans doute des constructeurs, mais j'en ai souvent vu tourner avec Access.
merci de votre réponse. mais moi je parle des applictions client-serveur. les caissis se connectent vers une autre machine de la base de données
De quelles caisses parles-tu ?
On peut souvent remarquer que par exemple les magasins comme Dary ou Confo sont sous AS400
J'ai très bien compris de quoi tu parles, et je confirme :
J'ai souvent vu des modèles de caisse avec écrans tactiles tourner avec Access.
Ensuite il est possible qu'Access ne serve que de FrontEnd pour accéder à une base de données centrale, mais il est tout aussi possible qu'Access conserve les données de caisse et qu'elles ne soient envoyées vers un serveur central qu'une fois la journée finie.
Par ailleurs, il existe des modèles de caisse plus "anciens", sans écran, avec des touches, etc...qui sont à ma connaissance programmées en C.
En résumé, ça dépend du constructeur et du modèle.
merci à vous tous.
moi je parle de caisses bien puisantes; elle est équipé d'un OS Windows avec 512Mo RAM et 120Go Disque Dur. donc nous pouvons la considérer comme un ordinateur mais sans clavier ni souris, juste avec un écran tactile.
j'aimerais bien entendre vos conseils concernant le choix du langage de programmation qui me permet de :
- créer des bons interfaces graphiques
- application client/ serveur
- ...
et merci d'avance
tout à fait ou sinon Visual Basic 5/6 parfois Delphi...Envoyé par Keihilin
L'intérêt d'une telle machine pour gérer une calculatrice graphique glorifiée m'échappe (surtout les 120Go de DD), tu pourrais expliquer un peu ?
--
Jedaï
Lorsque je parlais de caisse sous Access, c'était en connaissance de cause, et c'est donc sur la base de cette expérience que je vais te répondre.
On est quand même un cran au-dessus de la calculatrice graphique en terme de fonctionnalités...
- Un peu avant l'ouverture du magasin, les caisses sont allumées.
- Elles commencent par télécharger les mises à jour concernant les produits, les nouveau prix, les promotions du jour, etc...Et là on parle de plusieurs milliers (voir dizaines de milliers) de références.
- En cours d'utilisation, les caisses ne communiquent pas en temps réel avec les serveurs centraux, elles conservent l'historique des opérations en local.
- Les caisses doivent gérer des profils de clients, car certains clients professionnels bénéficient d'avantages particuliers. Il existe par ailleurs des rabais au volume qui doivent être pris en compte parfois hebdomadairement, parfois mensuellement...
- Les formats d'impression des factures (le ticket de caisse en gros), peut varier en fonction du profil du client...
- En fin de journée, les caisses envoient leur historique aux serveurs centraux.
Bref, afin d'avoir des temps de réponse viables pour un supermarché très fréquenté, il faut quand même des machines avec un minimum de puissance.
Tout ce que tu me décris est tout à fait dans le champ d'une calculatrice graphique actuelle...
Qu'il soit plus facile de programmer une interface graphique à ce genre de problématique sur un ordinateur récent, je veux bien, mais je ne doute pas que si le programmeur employé est un minimum compétent il peut faire tourner ça sur un ordinateur des années 2000 (et encore) sans aucune latence. Ce qui oblige à avoir de tels monstres (tu te rends compte qu'il y a 5 ans de ça j'aurais tué pour avoir un tel ordinateur ?) c'est l'usage de langages tels que Java ou C# par des programmateurs qui ne se soucient guère de performance, ainsi que l'emploi de WindowsXP (qui bouffe une quantité de mémoire RAM considérable).
--
Jedaï
Ouais enfin il y a 5 ans, 512Mo de RAM c'etait assez frequent.
Et 120Go ca pouvait aussi se trouver facilement pour un prix abordable.
En soit vu la quantite de donnees a conserver sur une caisse ca ne me semble pas aussi enorme que ca (surtout maintenant ou les "tickets commercants" ne sont plus imprimes sur la bande comptable mais enregistres) et c'est surtout a l'heure actuelle plus simple a trouver et pas forcement beaucoup plus cher qu'une config moindre.
Quant a comparer une caisse a une simple calculatrice:
* ce n'est pas faux pour les caisses les plus simples (comme celle que l'on trouve chez les petits commercants lambda) qui se contente grosso-modo de faire des additions.
* par contre pour les caisses plus evolues comme celles presentent en supermarche qui, outre le cote graphique plus evolue, gerent tout ou partie l'anim commerciale (reduction, offre promotionnelle, fidelite, etc.), permettent d'emettre des factures, pilotent un nombre de peripheriques consequent (lecteur code barre, lecteur de cheque, terminal de paiement - pour lesquels elles peuvent avoir un role de convertisseur serie/ethernet - balance, etc.), effectuent leur mise a jour automatique, font de la remonte d'information technique, financiere et comptable, etc., la comparaison ne tient plus (et encore je ne parle pas des caisses sans caissier)
La quantité de données à conserver ? Sur 120 Go, je doute qu'on puisse en occuper beaucoup avec une centaine de milliers d'articles (sauf s'il y a une photo associée à chacun je suppose, et encore... (30 Go suffisent pour 100000 images de 300ko)).
Par contre le second argument est sans doute recevable (mais traduit un déficit de bas de gamme pour utilisation spécialisée).
--
Jedaï
Aucune de ces tâches n'est exigeante côté calcul, en fait la plupart des problèmes que tu décris n'exige qu'un peu de réflexion du programmeur, mais pratiquement pas de calcul côté machine.
--
Jedaï
Il n'y a pas que les infos sur les produits sotcker sur les caisses, il y a egalement les differents programmes (ce qui peut, avec les interfaces graphiques et les differents enrichissementsgraphique, peut chiffrer. Et bien que ces fioritures ne soient indispensables pour la fonctionnalite premiere ca peut etre un differenciateur par rapport a une solution concurrente), les duplicatas des tickets de caisses et monetiques, des log sur l'activite de la caisse, etc.)
Meme si on ne remplit pas a fond les 120Go (et heureusement, il faut toujours se prevoir une marge confortable, on ne sait pas comment les choses vont evoluer) ca represente une taille non negligeable.
Je suis d'accord, ce n'est pas tres gourmand en terme de calcul. D'ailleurs je n'ai jamais pretendu le contraire. La discussion portait plutot sur la memoire utilisee.
Si, comme je le pense, cette remarque sur la puissance de calcul se rapporte a la comparaison precedente avec une calculatrice, ce n'est effectivement pas sur la puissance de calcul qu'une caisse se distingue d'une calculatrice un tant soit peu evoluee mais bel et bien sur le volume de stockage et la connectivite.
Vous avez un bloqueur de publicités installé.
Le Club Developpez.com n'affiche que des publicités IT, discrètes et non intrusives.
Afin que nous puissions continuer à vous fournir gratuitement du contenu de qualité, merci de nous soutenir en désactivant votre bloqueur de publicités sur Developpez.com.
Répondre avec citation
Partager