La caisse enregistreuse LIPE

PREAMBULE

Dans un premier temps ce document vise ˆ dŽfinir le point de dŽpart pour ouvrir le dŽbat. Et dans un second, donnera naissance ˆ une RFC destinŽe ˆ aider tout dŽveloppeur voulant participer ˆ l'Žlaboration du simulateur de caisse enregistreuse du projet LIPE.

PARTIE I : LES FONCTIONNALITES

Dans sa premi�re version, le programme de simulation de caisse enregistreuse ne comportera que quelques fonctionnalitŽs essentielles ˆ ce type d'application : gestion des utilisateurs (ou vendeurs), des familles d'articles, des modes de paiements, pour ne citer que les principales.

I-1. LES UTILISATEURS

Deux cas de figure se prŽsentent. La caisse est utilisŽe par une seule personne ou plusieures mais la distinction entre utilisateurs n'est pas souhaitŽe. Si aucune gestion d'utilisateur n'est demandŽe, il faudra que toute rŽfŽrence ˆ un vendeur soit ŽvitŽe au niveau de l'Interface Homme Machine ('IHM' dans ce qui suivra).
Dans le cas d'une gestion multi-utilisateurs, deux solutions sont envisageables. Permettre le choix de l'utilisateur pour un ticket de caisse donnŽ ou en associer un par dŽfaut si aucun n'a ŽtŽ choisi. Soit imposer un choix systŽmatique de l'utilisateur afin d'Žviter un cumul involontaire et excessif de ticket de caisse sur le compte de l'utilisateur par dŽfaut. Sans pour autant gŽrer un syst�me complexe de droits d'acc�s pour la caisse enregistreuse, un utilisateur 'principal' sera dŽclarŽ avec un simple mot de passe faisant office de clŽ. La possibilitŽ de limitŽ certaines actions ˆ cet utilisateur seul Žvitera par exemple une cl™ture non autorisŽe.

I-2. LES FAMILLES D'ARTICLES

Il est ˆ noter que la premi�re version du programme de caisse enregistreuse ne gŽrera pas les articles mais les familles d'articles uniquement. Chaque ligne d'un ticket de caisse devra obligatoirement �tre associŽe ˆ une famille. Comme pour les utilisateurs, deux possibilitŽs sont autorisŽes. Si aucune famille n'est explicitement indiquŽe, une par dŽfaut est utilisŽe. M�me remarque ici aussi, afin d'Žviter de 'sur-employer' la famille par dŽfaut, le choix de la famille peut �tre obligatoire. La sŽlection d'une famille pourra impliquer un prix par dŽfaut qui restera modifiable si nŽcessaire. Cela dans un souci d'optimisation de la saisie.
I-3. LES PRIX ET QUANTITES

Les prix sont des nombres ˆ dŽcimale fixe. Le nombre de chiffres derri�re la virgule Žtant dŽterminŽ une seule fois pour toute ˆ l'installation du logiciel de caisse. Chaque ligne de ticket comportera un prix qui ne peut �tre nul. La quantitŽ par dŽfaut est toujours 1. De plus, dans cette version de la caisse enregistreuse, seuls les nombres entiers seront autorisŽs.

I-4. LES MODES DE PAIEMENTS

Un mode de paiement sera associŽ ˆ chaque ticket de caisse. Il n'est pas prŽvu pour le moment de permettre plusieurs modes pour un m�me ticket. L'utilisateur principal pourra ajouter des modes de paiements personnalisŽs ˆ ceux prŽvus par dŽfaut, c'est-ˆ-dire : esp�ces, ch�que ou carte bancaire.

I-5. LES TOTAUX (X et Z)

Un cumul par journŽe devra �tre tenu pour les catŽgories suivantes : utilisateurs, familles d'articles, modes de paiements, ainsi qu'un total des totaux. Seul l'utilisateur principal aura acc�s ˆ ces totaux. Le 'X' consiste en un total ˆ l'instant t durant une session de travail (autrement dit une journŽe). Lorsqu'un utilisateur demande un X, il doit prŽciser pour laquelle des catŽgories citŽes ci-dessus et obtient le total pour celle-ci. Une journŽe est cl™turŽe par un 'Z'. Attention, il s'agit ici de demander une confirmation ˆ l'utilisateur car le Z aura pour effet de remettre tous les totaux ˆ zŽro.

I-6. LES T.V.A.

Deux types de TVA seront prŽ-Žtablies mais l'utilisateur principal pourra en ajouter si nŽcessaire. Leurs gestion peut s'aparenter aux cumuls citŽs pour les modes de paiements et autres totaux (voir ci-avant). Il faudra donc maintenir un cumul par type de TVA, par ticket et par journŽe.

I-7. LES TICKETS

Un ticket de caisse dŽbute par un ent�te au nom de la sociŽtŽ suivi d'un nom d'utilisateur (ou vendeur) que si le mode multi-utilisateur a ŽtŽ retenu ˆ l'installation du logiciel de caisse. De plus, suiveront date et heure, prŽcŽdŽes Žventuellement d'informations telles que adresse, tŽlŽphone, tŽlŽcopie, etc. Chaque ligne comportera un libellŽ de famille, son prix unitaire TTC et la quantitŽ que si elle est diffŽrente de 1. Aucun total (quantitŽ) x (prix) n'est prŽvu pour le moment afin d'Žviter de surcharger la ligne de ticket. En fin de ticket, un total par type de TVA, un total TTC pour l'ensemble et le mode de paiement utlisŽ pour le rŽglement. S'il y a lieu de rendre de la monnaie, cette information figurera ˆ l'Žcran mais non sur le ticket.

PARTIE II : L'ARCHITECTURE

Pour ce qui est de l'architecture logiciel de la caisse enregistreuse, il faut garder ˆ l'esprit que la connexion avec le serveur de donnŽes LIPE ne se fera que dans un second temps. Il s'agit donc de penser 'simple' pour favoriser l'adaptation future. II-1. LES DONNEES Un unique fichier de donnŽes principal acceuillera les informations concernant la caisse enregistreuse. Ce fichier sera de type texte afin de le protŽger des inconvŽnients gŽnŽralement constatŽs dans l'utilisation de fichiers binaires et propriŽtaires. Les donnŽes ne seront inscrites dans ce fichier qu'apr�s validation du ticket de caisse. Aucune modification ou suppression ne sera autorisŽ sur le fichier principal.

II-2. LES TRAITEMENTS

Tous les traitements associŽs au simulateur de caisse enregistreuse seront rŽunis dans un 'module-traitements' unique. Ce programme validera les donnŽes Žmises par les 'modules-interface' (voir ci-apr�s) et les inscrira dans le fichier de donnŽes. Ne pas oublier ici que le module-traitement sera autonome dans la premi�re version de la caisse enregistreuse.

II-3. LES INTERFACES HOMMES-MACHINES

Deux types d'interfaces sont retenues dans un premier temps. Une en mode 'console' pour les postes de travail peu performants et une seconde en mode 'graphique' pour les plus puissants. Quelque soit l'interface choisie, la premi�re des prioritŽs sera l'intuitivitŽ de celle-ci. L'idŽal ici Žtant qu'un simple coup d'oeil sur l'Žcran permettra ˆ l'utilisateur de comprendre comment cela fonctionne.

II-4. LE PROBLEME DE L'EURO

Dans le cadre de la premi�re version de la caisse enregistreuse, le module-traitements aura la charge d'accepter ou de refuser ainsi que de convertir les devises que les modules-interface lui transmettront. Toujours dans cette version, l'Euro sera choisi ˆ titre arbitraire et dans un premier temps seulement. Tout changera tr�s certainement dans les versions qui suivront...

PARTIE III : LES OBLIGATIONS LEGALES

L'auteur exprimera ici le profond regret de n'avoir aucune compŽtence ˆ ce niveau. Donc toute personne sachant de quoi il en retourne sera Žvidemment la bienvenu sur la mailing-list *lipe_gestion*. A suivre...

III-1. LES ARCHIVES

Il est envisageable de procŽder ˆ un archivage systŽmatique, mensuellement par exemple, pour rŽpondre ˆ une des premi�res obligations lŽgales : reproduire un double de chaques tickets de caisse qui ont ŽtŽ editŽs.

III-2. LES EDITIONS

Pour les m�mes raisons que celles citŽes ci-avant, les tickets pourront �tre ŽditŽs en double pour archivage et/ou le service comptable.

REMERCIEMENTS

L'auteur tient ˆ remercier toutes les personnes qui ont de loin ou de pr�s inspirŽ ce document, dont JŽr™me Bouton, Alain Couchot, JŽr™me Dautzenberg, Bernard Frit, ainsi que l'irrempla�able Max James :). Et mille excuses ˆ ceux qui auraient ŽtŽ oubliŽs...

Longue vie ˆ LIPE, FrD.16032000