Accueil‎ > ‎Qualité‎ > ‎

Architecture logicielle




DOC-TEC-1019

V1

TITRE

Architecture

REDACTION

VALIDATION

OBJET DE LA REVISION

DATE

NOM

NF525

19/10/2016Régis FOLNY
Grégory Gallier-Lachaise
13/12/2016
Régis FOLNY
Grégory Gallier-Lachaise
Publication sur Google Site
 21/02/2017 Régis FOLNY
 Grégory Gallier-achaise
 Ajout Infos- JET
 05/01/2018 Régis FOLNY Grégory Gallier-achaise Ajout redactionnel


Ce dossier technique a pour vocation de présenter les grandes lignes de l’architecture et des fonctionnalités de Neptis. Il ne se substitue pas à une formation approfondie par CRISALID ou un revendeur agréé par CRISALID. L’ensemble des fonctionnalités est détaillé dans le guide utilisateur fourni .

Architecture

Le logiciel CRISALID client-serveur modulaire qui s’appuie sur un Serveur de Bases de Données Relationnelles Firebird.
Le stockage des données est réalisé par deux bases de données :
  • CONFIG.FDB qui gère le paramétrage commun à toutes les caisses connectées
  • DATA.FDB qui stocke les données produites par l’application

Gestion de la séquence continue

La numérotation des tickets suit les règles suivantes:

Chaque type de document possède sa propre séquence continue qui est composée de:

 Type de ticket

 (Type d'opération) num. caisse num. document Nb impression

ex: Ticket (VTE) 3-1.1

Les types de tickets

1 TCK TICKET
2 DUP DUPLICATA
3 FCT FACTURE
4 NTE NOTE
5 JSP JUSTIFICATIF DE PAIEMENT
6 IVT INVENTAIRE
7 EST ENTREE STOCK
8 SST SORTIE STOCK
9 IVD INVENDUS
10 RUP RUPTURE
11 ALT ALERTE
12 RAZ RAZ STOCK
13 FAB FABRIQUES
14 TRS TRANSFORMABLES
15 REI REINTEGRABLES
16 CDC COMMANDE CENTRAL
17 LVC LIVRAISON CENTRAL
18 TRM TRANSFERT MAGASINS
19 BCD BON DE COMMANDE
20 DEV DEVIS
21 CFR COMMANDE FOURNISSEUR
22 RCD RECAPITULATIF DE COMMANDES
23 BLV BON DE LIVRAISON
24 RGF REGROUPEMENT DE FACTURES
25 REG REGLEMENT COMPTE CLIENT

Les types d'opération

1 VTE VENTE (+)
2 ANN ANNULATION (-)
3 GES GESTION-TRESORERIE(0)

Le logiciel peut être étendu par un système de plugins. Les plugins sont des librairies de code exécutable (DLL).
Le cœur de l'application gère le ticket de caisse et les fonctionnalités associées au ticket de caisse (annulations, encaissements, manipulations sur le ticket), le pilotage de l’interface graphique et des périphériques.
Les tickets sont des documents XML et sont stockés comme tels dans des champs d’objet de la base de données.

Ce logiciel est plus précisément un progiciel destiné à être personnalisé en fonction de l’activité de chaque client. CRISALID propose plusieurs adaptations standard commercialisées sous des noms de marques déposées:
  • Atthis est spécifiquement destiné aux clients Tabac/Presse
  • Aliris aux clients Boulangers/Pâtissiers
  • Dyonis pour les Fleuristes/Horticulteurs
  • Régalis aux Bars/Brasseries/Restauration rapide/Snacking
  • Phasis pour les commerces de proximité
  • Athesis pour la billetterie
  • Ogyris pour la restauration à table
  • Orsis pour le restauration de collectivié
L’adaptation de l’interface du logiciel pour un client donné consiste à programmer chaque touche du clavier en lui associant un visuel et une fonction. Plusieurs dizaines de fonctions sont gérées en interne par le logiciel et les fonctions manquantes qui ne sont pas indispensables au fonctionnement du cœur du logiciel peuvent être programmées dans des Plugins (Modules d’Extension).

Le progiciel intègre un moteur de fidélité modulaire. Les données de chaque carte de fidélité sont gérées par la base de données mais le moteur de décision propre à chaque client est externe à l’application et peut ainsi être adapté aux besoins de chaque client.

Gestion des périodes

L'application génère et clôture automatiquement les périodes en tenant compte des valeurs de clôture d'exercice et d'heure ce clôture renseignés au premier démarrage du logiciel.

Les périodes automatiques:

 J Journalière
 H Hebdomadaire
 M Mensuelle
 T Trimestrielle
 S Semestrielle
 E Exercice

L'application créée automatiquement les GT et archives rattachées à chaque période

Gestion des archives

L'application génère automatiquement les archives fiscales liés aux clôture automatiques. Ces archives sont créés sous forme de fichier 7zip dans le répertoire /Archives du serveur de caisse:



Les fichiers sont identifiés de la manière suivante:

   ARC[num d'archive][type d'archive][date-heure de début][date-heure de fin][Uid-caisse]

Le contenu des archives est décrit dans le fichier Doc_archive.txt:


 archive.json descriptif et signature du fichier d'archive
 
 bilans.csv Totaux des tickets
 ID;NUMERO_DOCUMENT;NUMERO_LIGNE;TOTAL_HT;CODE_TVA;TAUX_TVA;MONTANT_TVA;TOTAL_REMISE;TAUX_SERVICE;CALCUL_SERVICE;MONTANT_SERVICE;TOTAL_TTC
comptes-clients.csv Totaux comptes clients
 ID;NUMERO_DOCUMENT;NUMERO_LIGNE;MONTANT_TTC;NUMERO_CLIENT;SOLDE;CUMUL_POINTS;SOLDE_POINTS;PART_SUBVENTION;PART_PATRONALE;
PART_SALARIALE;ADMIN_PATRONALE;ADMIN_SALARIALE;POINTS_PATRONALE;POINTS_SALARIALE
detail.csv Détail des lignes articles
 ID;NUMERO_DOCUMENT;NUMERO_LIGNE;RGPT;CODE_PRODUIT;ORIGINE;LIBELLE;QUANTITE;CODE_TVA;TAUX_TVA;CODE_TARIF;PRIX_TARIF;PU_HT;PU_TTC;CODE_REMISE;TAUX_REMISE;MONTANT_REMISE;
MONTANT_HT;MONTANT_TTC;QUANTITE_MESURE;UNITE_MESURE;TYPE_OPERATION;CODE_UTILISATEUR;HORODATAGE;CODE_MAGASIN;CODE_CAISSE;CODE_VENDEUR;CODE_OPERATION;
CODE_COMPTABLE;TAUX_SERVICE;CALCUL_SERVICE;MONTANT_SERVICE
 duplicatas.csv Historique des duplicatas
 ID;NUMERO_DOCUMENT;NUMERO_REIMPRESSION;NOMBRE_LIGNES;TYPE_DOCUMENT;CODE_OPERATEUR;HORODATAGE;SIGNATURE_PRECEDENTE;PREMIERE_SIGNATURE
 entetes.cs Historique des entêtes de documents
 ID;NUMERO_DOCUMENT;VERSION;IMPRESSIONS;DUPLICATAS;SOCIETE_NOM;ADRESSE;CODE_POSTAL;VILLE;PAYS;SIRET;CODE_APE;NUMERO_TVA;CODE_VENDEUR;NOM_VENDEUR;
CODE_OPERATEUR;NOM_OPERATEUR;CODE_CAISSE;RGPT;NOMBRE_CLIENTS;HORODATAGE;TYPE_OPERATION;TYPE_DOCUMENT;NOMBRE_LIGNES;SIGNATURE;PREMIERE_SIGNATURE
 factures.csv Historique  des factures
 ID;SOCIETE;NOM;ADRESSE;CODE_POSTAL;VILLE;PAYS;SIRET;CODE_APE;NUMERO_TVA;NUMERO_FACTURE;SIGNATURE_PRECEDENTE;PREMIERE_SIGNATURE
 gt-periodes.csv Grand totaux périodes
 ID;PERIODE;DEBUT;FIN;TAUX_1;TVA_1;TAUX_2;TVA_2;TAUX_3;TVA_3;TAUX_4;TVA_4;TAUX_5;TVA_5;MONTANT;GT;GP;SIGNATURE_PRECEDENTE;PREMIERE_SIGNATURE
 gt-tickets Grands totaux tickets
I D;NUMERO_DOCUMENT;TAUX_1;TVA_1;TAUX_2;TVA_2;TAUX_3;TVA_3;TAUX_4;TVA_4;TAUX_5;TVA_5;HORODATAGE;MONTANT;GT;GP;SIGNATURE_PRECEDENTE;PREMIERE_SIGNATURE
 jet.csv détail du JET
 ID;CODE_EVENEMENT;DESCRIPTIF;OPERATEUR;TERMINAL;TYPE_DE_DONNEES;HORODATAGE;INFORMATIONS;SIGNATURE_PRECEDENTE;PREMIERE_SIGNATURE
 reglements.csv historique des réglements
 ID;NUMERO_DOCUMENT;TYPE_REGLEMENT;NUMERO_CLIENT;CODE_REGLEMENT;LIBELLE_REGLEMENT;MONTANT_EURO;QUANTITE;CODE_DEVISE;TAUX_DEVISE;LIBELLE_DEVISE;
MONTANT_DEVISE;TYPE_OPERATION;CODE_UTILISATEUR;HORODATAGE;CODE_MAGASIN;CODE_CAISSE;CODE_VENDEUR;CODE_OPERATION
 totaux.csv historique des totaux tickets
 ID;NUMERO_DOCUMENT;NUMERO_LIGNE;TOTAL_HT;TOTAL_TTC;TAUX_SERVICE;CALCUL_SERVICE;MONTANT_SERVICE


Gestion de la séquence continue

DOC-TEC-18010410-Séquence Continue


La signature électronique

DOC-TEC-18010415-Signature Electronique



Journal électronique des transactions (jet)

L'application génère automatiquement un fichier de trace des transactions. Ce fichier est écrite dans le répertoire AppData\Local\Crisalid de l'utilisateur Windows:

Ci dessous la liste des évènements tracés dans le Jet:

DOC-TEC-18010514-Le JET


DOC-QLT-17081817-infos du JET


Le ticket



L’édition des tickets de caisse sur l’imprimante de tickets est réalisée par une feuille de style XSL-T qui transforme le contenu du ticket de caisse XML en un format d’impression propriétaire CRISALID. Ce format est basé sur XML et les balises qu’il contient servent à mettre en forme les données du ticket. Couplé à un fichier de définition des commandes d’impression (OPOS ou ESC-POS pour les imprimantes pilotées directement par le port série), ce format est interprété par un spooler multi-protocoles qui prend en charge l’impression physique des tickets.
Les tickets sont des documents XML autonomes : toutes les informations relatives à la transaction sont stockées dans le ticket. 

Pour imprimer un ticket il existe plusieurs méthodes :

  • ESC/POS (ou STAR) en direct
  • Surcouche OPOS
  • ESC/POS en mode RAW via le driver Windows
  • Mode graphique via le driver Windows
Quelle que soit la solution choisie, l’imprimante ne comprend de toutes manières que le jeu de commandes ESC/POS (ou STAR), même en passant par le driver Windows en mode graphique : le document à imprimer est converti en image qui est envoyée à l’imprimante via la commande ESC/POS adaptée (ou sous forme de commandes ESC/POS de dessin en mode graphique si le document à imprimer s’y prête et que le driver sait le décomposer en séquences de dessin.)



Les commandes ESC/POS ou STAR fonctionnent toujours sur le même principe : on envoie un code de contrôle à l’imprimante comme ESC (ASCII #27), FS (ASCII #28), GS (ASCII #29) ou suivi du code d’une commande (souvent une lettre majuscule ou minuscule) et de ses paramètres.



Le mode ESC/POS direct est très complexe à mettre en oeuvre lorsque l’imprimante est connectée en USB.



D’où l’idée de passer par une surcouche exposant une interface de programmation commune qui prend en charge la complexité de la communication avec le périphérique : OPOS



OPOS est l’implémentation d’une norme (UPOS : Unified Point of Sales) dans le monde Windows (OLE for Point of Sales). Il existe une autre implémentation d’UPOS dans le monde JAVA : JavaPOS.
OPOS s’appuie sur l’infrastructure OLE (ActiveX) de Windows. Le fabricant du matériel met à disposition les Objets de Service (SO : Service Objects) et en tant qu’éditeur de logiciel, nous n’en n’utilisons que la partie commune : les objets de contrôle communs (CCO : Common Control Objects). Via OLE/ActiveX nous demandons la création d’une instance du périphérique qui nous intéresse (OPOSPOSPrinter dans le cas des imprimantes) et Windows se charge du reste : il trouve l’objet de contrôle commun approprié et nous le renvoie. Lorsque nous appelons la méthode Open de l’objet, la magie opère grâce à la configuration qui est dans la base des registres (HKLM\Software\OLEforRetail) : l’objet de contrôle commun trouve l’objet de service correspondant au périphérique, l’instancie, cet objet se configure automatiquement et prend en charge la communication avec le périphérique à travers les drivers Windows de bas niveau qui ont été installés avec les périphériques.


La couche d’abstraction d’OPOS nous permet de communiquer de la même manière avec tous les périphériques compatibles et essaye de gommer les différences entre les différents périphériques.

OPOS est donc composé :

  • des objets de contrôle communs (CCO) que l’application caisse utilise, 
  • des objets de service (SO) que le fabriquant fournit
et en général d’un outil de configuration propre à chaque type de périphérique qui permet d’indiquer sur quel port est branché le périphérique et d’autres paramètres de communication ou de configuration spécifique à chaque périphérique.

Le processus de déploiement d’OPOS se fait en trois étapes :
  • Il faut commencer par installer les drivers spécifiques des fabricants
  • Puis utiliser les outils de configuration pour “créer” les périphériques et les configurer. C’est à cette étape que l’on peut donner un nom logique au périphérique (LDN : Logical Device Name ou plus simplement ”alias”). Le nom logique est un nom plus parlant qui permet de simplifier la configuration dans l’application caisse.
  • Et enfin il faut installer le pack OPOS Crisalid qui va forcer le déploiement des objets de contrôle communs dans la version exacte attendue par l’application caisse. L’architecture d’OPOS garanti que les objets de contrôle communs sont toujours compatibles avec toutes les versions des objets de service.
Pour imprimer un ticket il faut (et il suffit) d’envoyer des séquences de commandes ESC/POS (ou STAR) à l’imprimante. Peu importe le nombre et la complexité des couches intermédiaires entre l’application et l’imprimante. Or le ticket XML n’est pas composé de séquences ESC/POS. Il ne contient que des données plus ou moins brutes et absolument aucune information de mise en page ou de mise en forme.

L’impression d’un ticket est un processus d’extraction et de transformation des données contenues dans le ticket XML en commandes ESC/POS.
Les techniques pour réaliser cette opération sont nombreuses mais souvent propriétaires et fermées. Chez Crisalid nous avons choisi un moyen standard et ouvert de traiter les tickets XML afin de les convertir en “autre chose”. Cette technologie s’appelle XSL-T (eXtensible Stylesheet Language - Transformation). Elle utilise un processus externe appelé “Processeur XSLT” qui met en rapport le document XML et le script XSLT afin de produire un nouveau document. Le document produit peut être un fichier texte, une page HTML ou un nouveau document XML.
Le processeur XSLT utilisé par l’application caisse est celui de Microsoft et fait partie du package MSXML Core Services 6.0.
Pour des raisons techniques, il n’est cependant pas possible de générer un fichier de commandes ESC/POS par XSLT car les commandes ESC/POS contiennent des caractères non imprimables.
Nous avons donc créé un langage intermédiaire, en XML, qui représente ces séquences de commandes d’impression et qui est ensuite traité par l’application caisse pour générer les séquences ESC/POS ou OPOS définitives.
La liste des instructions de ce langage intermédiaire est décrite dans les fichiers “Drivers” : OPOS.XML, OPOS2.XML et RS232.XML. Les deux premiers génèrent des séquences d’impression “OPOS” et le dernier directement des séquences d’impression ESC/POS
Le flux de traitement de l’impression d’un ticket peut se résumer par le schéma suivant :

Ticket XML + modèle XSL + processeur XSLT → séquence de commandes d’impression XML + fichier des commandes (OPOS.XML, OPOS2.XML ou RS232.XML) → séquences de commandes ESC/POS ou OPOS + driver RS232 ou OPOS → périphérique.

L’avantage de ce système est qu’à partir d’un ticket XML et d’un même fichier XSL, on peut générer des commandes d’impression pour une imprimante pilotée par OPOS aussi bien que pour une imprimante RS232 pilotée en direct par l’application.

En résumé : Le but du fichier XSL est de générer un “fichier” de commandes d’impression en utilisant celles qui sont décrites dans les fichiers OPOS.XML ou RS232.XML
L’application se charge ensuite de faire le nécessaire en fonction du mode de pilotage de l’imprimante pour que ces séquences de commandes d’impression soient exécutées.

Structure d’un fichier XML


Un fichier XML minimal doit ressembler à ça :

<?xml version=”1.0” encoding=”utf-8” ?>
<noeud-racine>
<sous-noeud attribut=”valeur de l’attribut”>valeur du noeud</sous-noeud>
</noeud-racine>


La ligne <?xml… est une instruction de traitement. Elle sert à indiquer à l’analyseur XML ce qu’il va trouver dans la suite du fichier. En particulier, l’attribut “encoding” qui indique que les caractères Unicodes sont encodés en UTF8 (important pour les caractères spéciaux ou accentués comme €, é, à, ê...).

Dans un fichier XML, on ne peut pas utiliser les caractères suivants sans prendre de précautions car ils servent au balisage des données : <, >, “, ‘, &. Pour les utiliser dans les données ou dans les attributs il faut les “échapper” en utilisant la notation des entités : < devient &lt; > devient &gt; “ devient &quot; ‘ devient &apos; et & devient &amp;

Exemple : en XML, la chaîne de caractères PAINS & CHOCOLATS “du chef” (> 300g) s’écrit : PAINS &amp; CHOCOLATS &quot;du chef&quot; (&gt; 300g)
La règle est que dans un fichier XML les balises doivent être correctement balancées : toute balise ouverte doit être fermée dans l’ordre inverse :
<a><b> doit être fermé : </b></a>. Un fichier XML qui contiendrait cette séquence de balises <a><b></a></b> par exemple n’est pas “bien formé” et sa lecture provoquera une erreur.
La valeur d’une balise est ce qui se trouve entre la balise ouvrante <a> et la balise fermante </a>. Une balise peut donc contenir comme valeur soit rien, soit du texte, soit d’autres noeuds XML.
Une balise qui n’a pas de valeur peut-être fermée immédiatement : <a/> au lieu de <a></a>.
Il est possible d’inclure des commentaires dans un fichier XML en les encadrant à l’aide des balises spéciales <!-- et -->, lorsque le fichier XML est lu par l’analyseur, les commentaires sont ignorés.

Exemple : <!-- Ceci est un commentaire -->

Structure d’un fichier XSL

La première chose à noter concernant les fichier XSL c’est que ce sont des fichier XML dont certaines balises sont normalisées et ont un sens précis. Pour indiquer au processeur XSLT où sont ces balises spéciales, on les préfixe grâce à un espace de nommage.

Exemple : <xsl:value-of select=”...” /> est la balise XSL qui permet d’extraire les données du document “source” pour les injecter dans le document “cible”. L’espace de nommage est “xsl”

L’espace de nommage “xsl” des balises est déclaré au début du fichier dans un attribut xmlns (pour xml namespace)
Un fichier XSL minimal ressemble à ça :

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform">
<xsl:output method="xml" version="1.0" encoding="utf-8"/>
</xsl:stylesheet>

On retrouve l’instruction de traitement <?xml... qui nous confirme qu’un fichier XSL est bien un fichier XML ainsi que l’espace de nommage xsl dont la valeur est normalisée :

xmlns:xsl="http://www.w3.org/1999/XSL/Transform"

Ce que la balise xsl:output nous indique c’est que le document attendu à la sortie du traitement du document XML d’entrée par cette feuille de style XSLT sera un nouveau fichier XML (method=”xml”) qui sera encodé en UTF8 (encoding=”utf-8”)
Cette feuille de style XSL seule ne sert à rien puisque rien n’indique comment traiter le document d’entrée pour produire ce qui est attendu en sortie.


Modèle de ticket minimal :

<?xml version="1.0" encoding="utf-8"?>
<xsl:stylesheet version="1.0"
xmlns:xsl="http://www.w3.org/1999/XSL/Transform"
xmlns:msxsl="urn:schemas-microsoft-com:xslt">
<xsl:output method="xml" version="1.0" encoding="utf-8"/>

<!-- Paramètres fournis par l’application -->
<xsl:param name="double_affichage">false</xsl:param>
<xsl:param name="devise">Francs</xsl:param>
<xsl:param name="symbole">F</xsl:param>
<xsl:param name="taux">6.55957</xsl:param>
<xsl:param name="message"></xsl:param>
<xsl:param name="total_fidelite">false</xsl:param>
<xsl:param name="langue">FR</xsl:param>
<!-- Paramètres uniquement disponibles avec les tickets “cuisine” -->
<xsl:param name=”id_caisse”>1</xsl:param>
<xsl:param name=”caisse”>Caisse 1</xsl:param>
<xsl:param name=”observateur”>Chaud</xsl:param>

<xsl:template match="/">
<ticket>
<select>imprimante</select>
<pagecode>858</pagecode>
</ticket>
</xsl:template>
</xsl:stylesheet>

Les valeurs des paramètres xsl:param (double_affichage, devise, symbole…) sont passés au processeur XSLT par l’application caisse, leurs valeurs changent en fonction de la configuration de la caisse. Ce mécanisme permet aux feuilles de style XSL de s’adapter au comportement attendu par le paramétrage de la caisse.
Les balises XML en gras qui ne sont pas préfixées par xsl: ne font pas partie de XSLT : ce sont les balises qui constitueront le document XML de sortie. En l’occurrence, il s’agit des commandes d’impression qui seront traduites dans un second temps en commandes ESC/POS ou OPOS.

Liste des commandes d’impression disponibles :
 <select>imprimante</select>  Obligatoire au début du ticket pour s’assurer que les commandes vont bien être envoyées à une imprimante.
 <pagecode>858</pagecode>  Page de code des données à envoyer à l’imprimante. 858 obligatoire pour le symbole €.
 <lf/>  Saut de ligne
 <tab/>  Saut de tabulation (voir <definitabs>)
 <definitabs>...</definitabs>  … : position des taquets de tabulation
Exemple : <definitabs>0g 10d 42d</definitabs>
Premier taquet à 0 aligné à gauche, deuxième à 10 aligné à droite et troisième à 42 caractères aligné à droite.
On utilise ensuite <tab/> dans le texte pour sauter au taquet suivant et aligner automatiquement le texte correspondant.
 <identification niveau=”1” />  Imprime les infirmations d’identification du magasin. 
Niveau 1 = NOM du magasin, infos légales
Niveau 2 = ADRESSE du magasin, infos légales
Niveau 3 = ADRESSE du magasin + téléphone, fax, émailinfos légales
Niveau 4 = RESPONSABLE du magasin + ADRESSE + téléphone, fax, émailinfos légales
 <traduction langue=”EN” max=”20”>...</traduction>  Traduit une chaîne de caractères en regardant dans la table de traductions de la base de données.
langue : code langue parmi les langues disponibles
max : coupe la chaîne traduite au bout de max caractères.
… : chaîne à traduire
 <date format=”...” heures=”...” minutes=”...” jours=”...” semaines=”...” mois=”...” annees=”...” />
<heure />
<dateheure />
Imprime la date/heure courante.
format : chaine de format. ex : yyyy-mm-dd
autres paramètres : offset par rapport à la date/heure courante (servent à calculer des dates relatives à la date/heure courante)
 <contact id=”...” />
<fidelite id=”...” />
<compte id=”...” /> 
 Charge les informations dynamiques du contact (ou du compte fidélité ou du compte client) en cherchant l’id spécifié dans la base de données.
 <article tarif=”...” ref=”...” cab=”...” />  charge les informations dynamiques de l’article dont le cab ou la ref sont spécifiées avec les prix correspondant au numéro de tarif indiqué.
 <dynamic>...</dynamic>  Accède au champ spécifié de l’ensemble de données chargé par la commande <contact />, <fidelite />, <compte /> ou <article /> qui précède.
 <sequence synchro=”...” step=”...”>...</sequence>  Crée un générateur de séquence ou se synchronise avec un autre générateur de séquence.
 <aligne>gauche</aligne>  Change l’alignement de la ligne courante
Autres options :droite, centre
 <decoupe>defaut</decoupe>  Massicote le ticket manuellement
Autres options : immediat, etiquette
 <avance>coupe</avance> Massicote le ticket manuellement (autre méthode)
 <massicot>complet</massicot>  Massicote le ticket manuellement (autre méthode)
 <recule>ligne</recule>  Si l’imprimante le supporte, recule le papier.
Autre option : max
 <ecrit>petit</ecrit>  Change la police d’impression
 Autre option : normal <taille>double</taille> 
Change la taille d’impression
Autres options : normal, doublel, doubleh, quadruple, quadruplel, quadrupleh
 <style>gras</style> Changer le style d’écriture
Autre option : normal
 <couleur>rouge</couleur>  Change la couleur d’impresion (si l’imprimante le supporte) 
Autre option : noir
 <inverse>oui</inverse>  Imprime en inversion vidéo (blanc sur fond noir) 
Autre option : normal
 <souligne>fin</souligne> 
 Imprime le texte souligné
Autres options : non, epais
 <barre>oui</barre>  Imprime le texte barré 
Autre option : non
 <ligne>complete</ligne>  Imprime une ligne continue de différentes longueurs (complete = 42 caractères)
Autres options : l10, l20, demi, quart, tml60, tml76
 <logo>normal</logo>  Imprime le “logo” (chaîne de texte stockée dans l’imprimante)
Autres options : doublelarge, doublehaut, doublelargehaut
 <logonv>n1</logonv>  Imprime un logo graphique dynamique stocké dans l’imprimante. 
Autres options : n2, n3, …, n9
 <dessin>debut</dessin>Active le mode “dessin” ASCII 
Autre option : fin (pour sortir du mode dessin)
 <interligne>petit</interligne>  Réduit l’interligne (permet de condenser le ticket)
Autre option : normal
 <code-barres symbologie=”code128” binaire=”...” bcd=”...” masque=”...”>...</code-barres> 
 Imprime un code-barres calculé par l’imprimante. 
symbologies : code128_voucher, code128_ticket, ean13, ean8, ean8_notext
binaire=”oui” si les données sont données en binaire
bcd=”oui” si les données sont codées en BCD
sinon les données sont du texte.
… : données du codes barres

<qrcode taille=”moyen”>...</qrcode> 

Génère un QRCode de taille normale ou de taille moyenne et l’envoie comme une image à l’imprimante pour qu’elle l’imprime.
 <gadget type=”sudoku”>...</gadget>  Génère un gadget et l’imprime comme une image. 
Gadgets supportés : sudoku, logo
 <publicite max=”...” />  Imprime “max” caractères d’une des lignes du tableau de chaînes de publicité qui est envoyé en paramètre au processeur XSL lors du traitement du ticket.

Ces commandes permettent de générer du contenu dynamique à incorporer au ticket imprimé (contact, fidelite, dynamic, code-barres, qrcode, gadget, logonv…) et de mettre en page les données du ticket XML (aligne, ecrit, style, taille, inverse), de structurer la génération de tableaux (definitabs et tab).

Exemple de séquences d’impression de ticket

<ticket>
<select>imprimante</select>
<pagecode>858</pagecode>
<aligne>centre</aligne>”BIENVENUE CHEZ CRISALID”<lf/>
<logonv>n2</logonv>
</ticket>

Cet exemple permet de comprendre les points clés de ce format intermédiaire fait de commandes d’impression et de données à imprimer :

Les blancs (sauts de lignes et espacements)
En XML, les “blancs” sont significatifs et sont conservés par l’analyseur. Autrement dit, ces deux blocs XML qui ont, pour un humain, la même signification :

<a>TEXTE</a>

<a>

⌴⌴TEXTE

</a>


… sont vus comme deux blocs différents par l’analyseur XML (les crochets servent à matérialiser les bornes du texte bien qu’ils n’en fassent pas partie.)

[TEXTE]

[

⌴⌴TEXTE

]


Et si on envoie ces données telles quelles à l’imprimante, comme les sauts de lignes sont matérialisés dans le XML de la même façon que dans l’imprimante par le caractère ASCII #10, alors l’imprimante va imprimer des sauts de ligne et casser toute la mise en page.

TEXTE

⌴⌴TEXTE



Or le fait de pouvoir indenter par des blancs et des sauts de ligne le contenu de la feuille de style XSL est extrêmement pratique pour la lisibilité et le confort de travail.
La solution retenue a été de d’indiquer par des guillemets les bornes des sections de texte à imprimer :

XML

<a>”TEXTE”</a>

<a>

⌴⌴“TEXTE”

</a>

Texte vu par l’analyseur XML

[“TEXTE”]

[⤶

⌴⌴“TEXTE”

]

Texte envoyé à l’imprimante

[TEXTE]

[TEXTE]




Voici un exemple tiré d’un modèle de ticket qui montre comment les guillemets permettent d’indenter et de mettre en forme le modèle de ticket de façon qu’il soit facile à lire et à modifier.

<aligne>centre</aligne>”BIENVENUE CHEZ CRISALID”<lf/>

Grâce à la convention qui veut que le texte à imprimer soit mis entre guillemets, cette autre version du même bloc de commandes d’impression est équivalente et sera imprimée exactement de la même manière :

<aligne>centre</aligne>
”BIENVENUE CHEZ CRISALID”
<lf/>

La structure
Dans ce format intermédiaire, les noeuds XML ne sont pas imbriqués mais mis les uns au bout des autres, exactement comme les commandes ESC/POS (ou OPOS) qui sont envoyées à l’imprimante.

Exemple, pour écrire du texte en taille double et en gras, on peut utiliser la séquence :

<taille>double</taille><style>gras</style>
”TEXTE DOUBLE EN GRAS”
<style>normal</style><taille>normal</taille>

L’objet des feuilles de styles XSL est donc de générer cette séquence de commandes d’impression intermédiaires à partir du ticket XML d’origine.


Le ticket XML

Le ticket XML de l’application caisse Crisalid est une structure complexe qui évolue depuis une dizaine d’années grâce à XML et son langage de balisage “ouvert”. Il est en effet possible de faire évoluer la structure d’un document XML en ajoutant des noeuds ou des attributs sans casser la compatibilité avec d’anciennes versions. Ce qui serait problématique serait de supprimer des balises ou des attributs considérés comme obligatoires par d’anciennes versions de l’application.

La structure de base du ticket
Le ticket contient trois noeuds principaux : entete, lignes et bilan

<?xml version=”1.0” encoding=”utf-8” ?>
<ticket>
<entete></entete>
<lignes></lignes>
<bilan></bilan>
</ticket>


  • entete contient des métadonnées indispensables pour situer le ticket dans son contexte : date de création, date de modification, nombre de plateaux, informations sur le vendeur et la table s’il s’agit d’un ticket qui a été fait pour une table.
  • lignes contient le contenu principal du ticket : les articles, les sous-totaux et les menus avec leurs remises associées.
  • bilan contient les informations récapitulatives du ticket : le montant total, la remise globale, les encaissements et le récapitulatif par taux de TVA.
En plus de l’entête, le nœud racine “ticket” contient des attributs essentiels : le type de ticket, son numéro unique, le numéro de la caisse et le numéro séquentiel du ticket, s’il a été annulé, marqué pour annulation, imprimé, encaissé et dans quelle devise sont les prix.

Voir le XML du ticket

Une méthode pour voir le XML du ticket courant est d’utiliser la macro #VOIR_XML# : le ticket est formaté et affiché dans le bloc notes. Cette macro peut aussi être utilisée depuis le rappel ticket pour voir la source XML de n’importe quel ticket.

Pour un confort de lecture maximal, il est conseillé de sauvegarder le ticket sur disque dans un fichier avec l’extension XML et de l’ouvrir avec un éditeur muni de la fonctionnalité de mise en évidence de la syntaxe par coloration. Notepad++, SciTE et Sublime Text Editor entre autres savent le faire.

Exemple de ticket

L’indentation d’un ticket peut différer puisque les blancs (sauts de lignes et espacements) ne sont pas significatifs, l’ordre des attributs des nœuds n’est pas non plus significatif. Seule la structure d’imbrication des noeuds est importante.


<?xml version="1.0" encoding="utf-8"?>

<ticket version="2"

       type="VTE" devise="EURO"

       uid="{A39D6CC4-4073-4188-9D4F-56DA5E2EBD06}"

       caisse="1" numero="751"

       annule="N" memo="N" imprime="O" attente="N" encaisse="O"

       clotureID="201505004">


 <entete>

   <creation iso="2014-06-06T15:54:57.499+02:00">

     <date>06/06/2014</date>

     <heure>15:54:57</heure>

   </creation>

   <modification iso="2015-02-23T09:48:11.513+01:00">

     <date>23/02/2015</date>

     <heure>09:48:11</heure>

   </modification>

   <stats iso="2015-02-23T09:48:11.513+01:00">

     <date>23/02/2015</date>

     <heure>09:48:11</heure>

   </stats>

   <caissier numero="0">Inconnu</caissier>

   <vendeur numero="2" service="0.00">MARIE</vendeur>

   <table numero="6">

     <couverts>2</couverts>

   </table>

   <cab>VTE751D141570954</cab>

 </entete>


 <lignes nombre="1">

   <article

numero="1" plu="1208" quantite="1.000" ht="N" base="12.0000" base_ht="10.9091"

valeur="12.0000" valeur_ht="10.9091" net="12.0000" net_ht="0.0000" tva="10.00"

code="120120009" cab="" codif="" addon="" scanning="N" tarif="0" unite="U" pesee="N"

hca="N" coupon="N" annule="N" controle="O" imprime="O" points="0" action="0" bonus="0.00"

fidelite="O" stock="O" bloque_zero="N" achat="0.0000" etats="7" prioritaire="N"

horodatage="2014-06-06T15:54:57.497+02:00" tri="0" regroupement="N" fournisseur="">

     <libelle>PIZZA FRUIT DE MER</libelle>

     <groupe code="12">PIZZAS</groupe>

     <famille code="12">PIZZAS</famille>

     <tags>

       <cuisine>CHAUD</cuisine>

       <tag>57160</tag>

     </tags>

     <commentaires>

       <liste code="13" nom="PIZZAS-" optionnel="oui"/>

     </commentaires>

   </article>

 </lignes>


 <bilan montantTTC="12.00" brut="12.00" fidelite="12.00" remise="0.0000" service="0.00">

<tvas montantTaxes="1.09">

   <tva taux="10.00" base="12.00" nombre="1.000">1.09</tva>

</tvas>

<encaissements montantEncaisse="12.00">

     <encaissement

           horodatage="2015-02-23T09:48:11.446+01:00" mode="ESPECES" devise="EURO"

           nombre="1" rendu="oui" avoir="non" acompte="non">40.50</encaissement>

</encaissements>

 </bilan>


</ticket>


Informations disponibles dans le ticket XML
Conventions : pour différencier des attributs des autres noeuds enfants du noeud courant dans cette table ou dans les explications on les préfixe par @.

Exemple avec <ticket numero=”32”><entete /></ticket> : pour parler de l’attribut “numéro” on écrit @numero ou ticket/@numero selon le contexte. Si on écrit ticket/entete alors on parle du noeud entete, enfant du noeud ticket.

Ticket

@version

Numéro de version du ticket (mis à jour lorsque la structure du ticket est modifiée de telle façon qu’elle n’est plus compatible avec les versions précédentes.)

@uid

UUID unique du ticket

@type

code de 3 caractères qui identifie le type du ticket (VTE = Vente, MMO = Mémo, TAB = Table en cours, RUP = Rupture, IVT = Inventaire, IND = Invendus, RAZ = RAZ Stock…)

@clotureID

Numéro de la clôture à laquelle appartient le ticket. Pour mémoire, les numéros de clôture sont de la forme YYYYDDDNN avec YYYY l’année en cours, DDD le numéro du jour dans l’année (32 = 1er février) et NN le numéro de la clôture de cette journée.

@caisse

Numéro de la caisse sur laquelle le ticket a été encaissé. Caisse = -1 pour les tickets MEMO

@numero

Numéro séquentiel du ticket par rapport à la caisse sur laquelle le ticket a été encaiss”. Les tickets d’évènement sont numérotés en négatif et les tickets MEMO sont numérotés indépendemment.

@annule

[O/N] Vaut “O” si le ticket a été annulé par la macro TICKET ANNULE

@memo

[O/N] Vaut “O” si le ticket a été marqué pour annulation par la macro TICKET MARQUE

@imprime

[O/N] Vaut “O” si le ticket a été imprimé

@encaisse

[O/N] Vaut “O” si la ticket a été encaissé (si on annule l’encaissement, @encaisse reste à “O”)

@devise

La devise du ticket. En général vaut EURO

@attente

[O/N] Vaut toujours “N” lorsque le ticket est encaissé et imprimable. Vaut “O” lorsque le ticket est “en attente” mais lorsqu’un ticket est “en attente”, on ne peut rien en faire.

@prix-achat

[O/N] Si le ticket est un ticket d’évènement, ce flag indique que les prix sont des prix d’achat.

@gestion-stock

[O/N] Si le ticket est un ticket d’évènement, ce flag indique que le ticket est un ticket de gestion du stock.


Entete

creation, modification, stats

Même structure pour tous les horodatages attachés au ticket. Ces 3 horodatages sont toujours présents, ils contiennent respectivement la date de création du ticket, la date de la dernière modification du ticket et la date à laquelle les stats du ticket ont été calculées. L’intérêt est que si le ticket est modifié, les stats soient recalculée toujours au même moment.

@iso contient l’horodatage au format ISO8601 qui est décomposé dans les noeuds enfant <date> et <heure>

caissier

caissier/@numero

[ Pas utilisé ]

vendeur

vendeur/@numero

vendeur/@service

Nom du vendeur. Le code du vendeur est dans @numero et le taux de commission du service est dans @service

table/@numero

table/@sous-numero

Numéro de la table. S’il s’agit d’une sous-table, l’attribut @sous-numero est présent. En général on formate le numéro de table pour l’affichage en concaténant @numero et @sous-numero avec un “.” (1.1, 1.2…) :
@numero + “.” + @sous-numero

table/couverts

Nombre de couverts

cab

Code barres du ticket. Reprend le type du ticket, son numéro et son timestamp encodé comme un nombre entier. Cette valeur est destinée à être présentée dans un CAB Code128 qui, lorsqu’il est scanné par l’application caisse ouvre automatiquement le rappel ticket positionné sur le ticket correspondant.

carte

Code de la carte qui identifie le compte client ou le compte fidélité.

flash

Message “flash”, disponible uniquement dans les tickets “cuisine” qui disparaît lorsque le ticket est imprimé.

commentaire

Commentaire global au “ticket”, les lignes sont séparées par des tags <lf/>

plateau/@nombre

Nombre de sous-total “plateau” dans le ticket.

fidelite/@id

Numéro interne de la carte de fidélité (utile pour récupérer les informations “live” sur la carte de fidélité avec <dynamic />)

fidelite/@appliquee

[O/N] Vaut “O” lorsqu’une action fidélité a été appliquée dans le ticket.

compte/@id

Numéro interne du compte client (utile pour récupérer les informations “live” sur le compte client avec <dynamic />)

compte/@libelle

compte/@solde

Libellé (nom/prénom ou raison sociale) du compte client et solde du compte AVANT le ticket courant.

contact/@id

Numéro interne du contact (utile pour récupérer les informations “live” sur le contact avec <dynamic />)

facture/numero

facture/debut

facture/fin

Contient le numéro de la facture récapitulative des tickets d’un compte client qui a été générée entre les dates debut et fin.

remise/@typeRemise

remise/@valeur

remise/@montant

Type et valeur de la remise globale appliquée au ticket (en plus des éventuelles remises locales faites sur les articles et les sous-totaux.)

transfert/origine

transfert/origine/@code

Nom et code interne du magasin à l’origine d’un transfert de produits dont ce ticket est la preuve.

transfert/destination

transfert/destination/@code

Nom et code interne du magasin de destination d’un transfert de produits dont ce ticket est la preuve.

wallet/@balance

wallet/@encours

wallet/@ticket

Informations sur la transaction de paiement faite via Crisalid Wallet.


Entête - Promotions

Si des promotions automatiques ont été appliquées au ticket, un noeud enfant <promotions> est ajouté à l’<entete> du ticket. Et les informations sur chaque promotion appliquée sont dans un noeud enfant <promotion>. La liste des articles à l’origine de chaque promotion est ajoutée dans un ensemble de noeuds enfant <article>.

promotion/@code

Code de la promotion qui a été appliquée dans le ticket.

promotion/@nombre

Nombre de fois où cette promotion a été appliquée dans le ticket.


promotion/article

Code interne de l’article

promotion/article/@addon

promotion/article/@annee

Code addon et année de parution de l’article s’il s’agit d’un article presse


Entête - Paiements

Si des paiments via des services (ou des webservices) tiers ont été enregistrés (Paypal, FlashIZ, DigiCash…) alors les informations sur les transactions de ces paiement sont stockées dans des noeuds enfant <paiement> du noeud <paiements> qui est ajouté à l’<entete> du ticket.

paiement/@id

ID de la transaction de paiement fourni par le service tiers.

paiement/@service

Nom du service tiers qui a enregistré la transaction

paiement/@payeur

Nom ou ID interne au service tiers du payeur.

paiement/@montant

Montant de la transaction enregistrée par le service tiers.

paiement/tag

Contenu du code barres (ou du QRCode) qui déclenche la transaction chez le fournisseur du service tiers.

paiement/creation

paiement/modification

paiement/annulation

Horodatages des échanges avec le service tiers. Le format est celui des horodatages de l’entête du ticket. L’attribut @iso contient l’horodatage complet au format ISO8601 et la date et l’heure correspondantes sont dans les noeuds enfant <date> et <heure>.


Entête - Réclamations

En mode restaurant, le ticket est souvent envoyé en cuisine, il est possible pour les vendeurs d’envoyer des réclamations pour la suite du service. L’horodatage de ces réclamations est tracé dans des noeuds enfant du noeud <reclamations> qui est alors ajouté à l’<entete> du ticket.

Le nom des noeuds réclamation correspond au nom des noeuds <tag> séparateur des articles.

Exemple : si le tag “séparateur” configuré dans le logiciel est “cuisine”, alors les articles seront imprimés en cuisine d’après le contenu des tags article/tags/cuisine et les réclamations correspondantes seront enregistrées dans les noeuds entete/reclamations/cuisine

<nom>/@mode

Le nom de la séquence qui est réclamée. Correspond aux valeurs des noeuds tags des articles.

<nom>/@iso

<nom>/date

<nom>/heure

Les informations habituelles des horodatages :  L’attribut @iso contient l’horodatage complet au format ISO8601 et la date et l’heure correspondantes sont dans les noeuds enfant <date> et <heure>.


Lignes

@nombre

Nombre de lignes du ticket. Permet de naviguer dans le ticket en respectant l’ordre de création des lignes.



Tous les noeuds qui sont ensuite imbriqués dans le noeud <lignes> ont un attribut @numero qui est le numéro séquentiel de création de la ligne dans le ticket.

Exemple : 

<lignes nombre=”3”>

 <sous-total numero=”3”>

   <article numero=”1” />

   <article numero=”2” />

 </sous-total>

</lignes>


Il est alors possible de parcourir itérativement le ticket pour afficher à l’écran (ou imprimer) :
  • ARTICLE 1
  • ARTICLE 2
  • SOUS-TOTAL

Alors que dans la structure XML, les noeuds <article> sont enfants du noeud <sous-total>

Ligne Article (noeuds <article>)

@numero

Le numéro d’ordre séquentiel de création de la ligne dans le ticket

@plu

Code PLU de l’article

@code

Code interne de l’article. Généralement au format GGFFFAAAA[@CC] avec GG le numéro du groupe, FF celui de la famille, AA celui de l’article et CC le numéro du conditionnement (@CC est facultatif) et tous ces numéros sont encodés au format NEP36.

@quantite

Nombre d’unités, de pièces, poids...

@tarif

Numéro du tarif (utilisé pour les changements de tarif et les stats)

@ht

[O/N] Vaut “O” si l’article a été vendu Hors Taxes. Si “N”, l’article a été vendu TTC.

@base

Prix de base (utile pour les calculs de menus et de remises)

@base_ht

Prix de base HT

@valeur

Prix unitaire

@valeur_ht

Prix unitaire HT

@net

Prix de vente Net (après remises et proratas liés aux menus et aux remises sur le sous-total englobant). C’est la valeur qui est utilisée pour le calcul des stats.

@net_ht

Prix de vente Net HT

@tva

Taux de TVA (en pourcentage)

@participation

Montant des taxes supplémentaires (Eco-taxe par exemple)

@supplement

Montant du supplément engendré par le fait d’avoir mis cet article dans un menu.

@typeRemise

@remise

[N, S, P, M, …] Type et valeur (en montant ou en pourcentage) de la remise appliquée à cet article

@cab

Code Barres de l’article au moment de la vente

@codif

Codif de l’article pour les articles Presse

@addon

Addon de l’article pour les articles Presse

@annee

Année de parution d’un article Presse

@scanning

[O/N] Vaut “O” si l’article a été scanné (utile pour la remontée des ventes Presse)

@prioritaire

[O/N] Vaut “O” si l’article est un article Presse prioritaire

@unite

[U/P/K/M/L/E] Type d’article (Unité, Pièce, Kilo, Menu, Libre, Etendu)

@plugin

Si @unite = ‘E’ alors contient le nom du plugin (.AEM) qui gère cet article particulier.

@pesee

[O/N] Vaut “O” si l’article a été pesé (avec une balance connectée)

@brut_pesee

Valeur brute (en kg) de la pesée

@id_pesee

ID de la transaction de pesée (correspond à un enregistrement dans le fichier log des pesées)

@tare_pesee

Valeur de la tare au moment de la pesée

@hca

[O/N] Vaut “O” si l’article est Hors Chiffre d’Affaires (pour les stats). Info : dès lors qu’au moins UN article du ticket contient un article flaggé @hca=”O”, le ticket est comptabilité dans le nombre de tickets HCA du financier.

@coupon

[O/N] Vaut “O” si l’article doit, provoquer l’édition d’un coupon

@annule

[N/D/E/R] Vaut “N” si l’article n’a jamais été annulé. D = annulation de type “Dernier”, E = après encaissement et R = retour avant encaissement

@controle

[O/N] Vaut “O” lorsque l’article est sorti en cuisine ou sur une imprimante de contrôle

@imprime

[O/N] Vaut “O” lorsque l’article a été imprimé

@points

Nombre de points que rapporte l’article sur une carte de fidélité

@action

Nombre de points d’action que coûte l’article à une carte de fidélité

@bonus

Bonus que rapporte l’article sur une carte de fidélité

@fidelite

[N/A] Vaut “A” si une opération fidélité a été appliquée et que cet article est concerné.

@stock

[O/N] Vaut “O” lorsque le stock de l’article est géré

@valstock

Quantité en stock AVANT la vente

@alertstock

Niveau d’alerte du stock sur ce produit

@bloque_zero

[O/N] Vaut “O” lorsque la vente de l’article est bloquée car son stock est nul ou négatif.

@achat

Prix d’achat

@etats

ET binaire entre les états suivants : 1 : Vendable, 2 : Commandable, 3 : Exportable. 0 = retiré, 7 = article vendable, commandable et exportable.

@horodatage

Horodatage du moment où l’article a été mis dans le ticket

@tri

Ordre de tri de l’article (pour les éditions des bons en cuisine)

@regroupement

[N/F/G] Vaut “O” si l’article doit être regroupé avec les autres articles de la même Famille ou du même Groupe.

@fournisseur

Code du fournisseur de l’article

@date_validite

@heure_validite

Date et heure de validité du produit

@composant

Numéro du composant du menu auquel cet article correspond

@promos

Liste des codes des promotions séparées par des virgules que cet article a participé à générer.

@quantite_originale

@was_in_menu

Quantité originale de la vente: utilisé lorsque les articles sont dispatchés entre les menus pour reconstituer le ticket lorsque les menus sont annulés ou modifiés.

Et par souci d’exhaustivité @was_in_menu est un attribut Interne qui sert à se souvenir quels articles étaient dans quels menus lorsqu’il s’agit de recalculer les menus du ticket en provoquant le moins de modifications possibles.

libelle

Libellé de l’article

groupe

groupe/@code

Libellé et numéro du groupe auquel appartient l’article

famille

famille/@code

Libellé et numéro de la famille à laquelle appartient l’article

fournisseur

fournisseur/@code

Nom et Numéro du fournisseur de l’article

transaction/@id1

transaction/@id2

transaction/horodatage

Si la vente de l’article en engendré l’appel à un WebService (via un plugin d’extension .AEM - cf @unite et @plugin) alors les détails de la transaction sont stockés dans les attributs @id1 et @id2 ainsi que l’horodatage de la transaction au format habituel (@iso contient l’horodatage ISO8601 et date et heure correspondantes sont dans les noeuds enfant <date> et <heure>)

tags/tag

Liste des tags “automatiques” (ajoutés automatiquement lors de la vente de l’article car ils sont déclarés dans la fiche article)

tags/<nom>

Tags supplémentaires manuels. Par exemple en mode restaurant on tagge les articles en direct/à suivre à l’aide du tag “cuisine”.

(Macro : TAG ARTICLE cuisine=*/DIRECT) ce qui va générer cette structure de noeuds : <tags><cuisine>DIRECT</cuisine></tags>

commentaire

Commentaire libre, il s’agit de noeuds #TEXT séparés par des noeuds <lf/>. Exemple :

<commentaire>Code Postal<lf>57160<lf>Joyeux Anniversaire</commentaire>

commentaires/liste

Liste des commentaires automatiques associés à l’article. Le code de la liste est dans l’attribut @code, le nom de la liste dans l’attribut @nom et l’attribut @optionnel peut valoir [O/N]. S’il vaut “O”, le commentaire est optionnel et la fenêtre qui permet d’en demander la valeur ne s’affiche que si on le demande explicitement.


Articles composants de menu

Lorsqu’un menu est vendu en mode “restaurant”, les emplacement des articles dans le menu sont d’abord réservés puis lorsque les articles sont vendus, ils remplissent les trous des menus au fur et à mesure. Lorsqu’un article remplit un trou, on lui attache un noeud “composant” qui reprend les caractéristiques du composant du menu qu’il a servi à combler. De cette manière, lorsque l’article est annulé, le composant est réintégré dans le menu et permet ainsi à un autre article potentiel du composant de prendre sa place.

composant

Nom du composant correspondant dans le menu

composant/@numero

Numéro (pour l’affichage) du composant correspondant dans le menu

composant/@id

ID interne du composant correspondant dans le menu

composant/@code

Code interne du composant correspondant dans le menu

composant/@prix-max

Prix max du composant correspondant dans le menu

composant/@nombre

Nombre d’instances du composant correspondant dans le menu

composant/@sequence

Tag automatique de l’article pour le séquencement en cuisine


Menus

@numero

Le numéro d’ordre séquentiel de création de la ligne dans le ticket

@quantite

Nombre d’unités vendues

@code

Code interne de l’article. Généralement au format GGFFFAAAA[@CC] avec GG le numéro du groupe, FF celui de la famille, AA celui de l’article et CC le numéro du conditionnement (@CC est facultatif) et tous ces numéros sont encodés au format NEP36.

@tarif

Numéro du tarif (utilisé pour les changements de tarif et les stats)

@annule

[N/D/E/R] Vaut “N” si l’article n’a jamais été annulé. D = annulation de type “Dernier”, E = après encaissement et R = retour avant encaissement

@base

Prix de base du menu (somme des prix unitaire des articles * quantité * nombre de menus)

@valeur

Prix unitaire du menu

@typeRemise

@remise

[N, S, P, M, …] Type et valeur (en montant ou en pourcentage) de la remise appliquée à cet article

@supplement

Montant du supplément total des articles ayant généré un supplément dans le menu.

@net

@net_ht

Prix net et prix net_ht du menu (Prix de vente final tenant compte de la remise appliquée au menu, au sous-total englobant le menu ou globalement à tout le ticket)

@tri

Ordre de tri de l’article (pour les éditions des bons en cuisine)

@points

@action

@bonus

@fidelite

Nombre de points que rapporte l’article sur une carte de fidélité, nombre de points d’action que coûte l’article à une carte de fidélité, bonus que rapporte l’article sur une carte de fidélité.

@fidelité vaut “A” si une opération fidélité a été appliquée et que cet article est concerné, “N” sinon.

libelle

Libellé du menu

article

Voir la description des noeuds <article>


Composants de menu

Lorsqu’un menu est vendu en mode “restaurant”, les emplacement des articles dans le menu sont d’abord réservés par des composants (noeuds <composant>) qui sont remplacés par des noeuds <article> lorsque ceux-ci sont vendus. ces composants servent à générer les fenêtres de choix des articles parmi les articles configurés comme étant autorisés dans chaque composant.

composant

Nom du composant

composant/@numero

Numéro (ordre pour l’affichage) du composant

composant/@id

ID interne du composant

composant/@code

Code interne du composant

composant/@prix-max

Prix max des articles du composant. Si un article dont le prix dépasse @prix-max est associé au menu alors il générera un supplément.

composant/@nombre

Nombre d’instances de ce composant

composant/@sequence

Tag de séquencement automatique pour les articles de ce composant.



Rappel de ce qui est expliqué à la section “Articles composants de menu” : Lorsqu’un article est vendu et prend la place d’un composant du menu, le noeud <composant> correspondant est déplacé dans le noeud <article>. Ainsi, si l’article est annulé par la suite, on peut remettre en place le noeud <composant> dans le menu et revenir à l’état initial.

Sous-Totaux et Sous-totaux “Plateau”

Les sous-totaux sont simplement des regroupements d’articles ou de menus sur lesquels on peut faire des remises ou des offerts.

(sous-total | plateau)/@numero

Numéro (ordre pour l’affichage) du sous-total

(sous-total | plateau)/@valeur

Montant brut des articles ou des menus contenus dans le sous-total ou le sous-total plateau

(sous-total | plateau)/@typeRemise

(sous-total | plateau)/@remise

[N, S, P, M, …] Type et valeur (en montant ou en pourcentage) de la remise appliquée à ce sous-total



Sous-tickets

Ce noeud interne ne devrait jamais être accessible de l’extérieur. Il s’agit d’une espèce spéciale de sous-total temporaire qui est transformé en ticket au moment de l’encaissement. Je le mentionne ici uniquement par souci d’exhaustivité.

Bilan

@montantTTC

Montant TTC du ticket

@brut

Montant brut du ticket (hors remises)

@fidelite

Montant des articles qui ne sont pas hors fidélité dans le ticket

@remise

Montant de la remise globale effectuée sur le ticket

@service

Montant du service (dépend du taux de service défini dans la configuration du vendeur)


Avoir généré

Lorsque l’encaissement d’un ticket provoque la génération d’un avoir, son code est stocké dans le noeud bilan/avoir

bilan/avoir

Code de l’avoir (destiné à être imprimé sous la forme d’un code 128)

bilan/avoir/@validite

Validité de l’avoir généré


Voucher généré
Les vouchers (chèques cadeaux, bons d’achat) générés lors de l’encaissement du ticket suite à l’application d’un avantage fidélité ou d’une promotion sont stockés dans le noeud bilan/voucher.

bilan/voucher

Code du voucher (destiné à être imprimé sous la forme d’un code 128)

bilan/voucher/@montant

Valeur du voucher

bilan/voucher/@debut-validite

bilan/voucher/@fin-validite

Dates de validité du voucher (le début de validité d’un voucher peut commencer après la date du jour où il a été généré.)


Bilan des TVA

tvas/@montantTaxes

Montant total des taxes


Contenant un noeud <tva> par TVA représentée dans le ticket

tvas/tva

Montant de la TVA

tvas/tva/@taux

Taux en pourcentage

tvas/tva/@base

Montant taxable

tvas/tva/@nombre

Nombre d’articles concernés


Bilan des Encaissements
Les montants calculés dans @rendu, @surplus et @avoir dépendent de la configuration des modes de règlement utilisés dans le ticket.

encaissements/@montantEncaisse

Montant total des encaissements

encaissements/@rendu

Montant du rendu calculé

encaissements/@surplus

Montant du surplus calculé

encaissements/@avoir

Montant de l’avoir calculé


Chaque encaissement est tracé dans un noeud <encaissement>, <avoir>, <voucher> ou <acompte> enfant du noeud bilan/encaissements

.

Montant de l’encaissement (dans la valeur du noeud)

@mode

Nom du mode de règlement

@horodatage

Horodatage exact du moment où l’encaissement a été enregistré dans le ticket.

@devise

Devise du règlement. Vaut EURO en général.

@nombre

Nombre de règlements identiques

@rendu

[oui/non] Vaut “oui” si l’encaissement en surplus avec ce mode de règlement peut donner naissance à un rendu en monnaie.

@avoir

[oui/non] Vaut “oui” si l’encaissement en surplus avec ce mode de règlement peut créer un avoir.

@acompte

[oui/non] Vaut “oui” si l’encaissement est un acompte.

@cab

Code barres du mode de règlement (ticket restaurant) s’il a été scanné

@id

Numéro du mode de règlement (numéro du chèque s’il a été lu par un périphérique ou du ticket restaurant)

@validite

Validité du mode de règlement (cas des tickets restaurant)



Structure générale des modèles de ticket

Un document de type “ticket” imprimé se compose généralement de 3 parties :

une entête avec le numéro du ticket, la date a laquelle il a été fait, l’identification du magasin et éventuellement le nom et le code du vendeur qui l’a encaissé, le numéro de table, le commentaire global…

le corps du ticket avec les lignes articles contenant obligatoirement le libellé de chaque article, son prix unitaire et la quantité vendue

le pied du ticket avec le montant total, éventuellement le montant total hors-taxes, la liste des encaissements, le détail des TVA et éventuellement le commentaire global, des informations sur le compte client ou la carte de fidélité et un message de remerciement.

Il y a deux manières de “naviguer” dans un fichier XML avec XSL :

En mode “pull” on utilise <xsl:call-template name=”...” /> pour appeler des <xsl:template name=”...” /> dans lesquels on utilise <xsl:value-of select=”...” /> pour “tirer” les données du fichier XML, les extraire et les placer dans le document de sortie à l’endroit où l’on se trouve.

En mode “push” on “pousse” une sélection de noeuds avec <xsl:apply-templates select=”...” /> et on demande au processeur XSLT de trouver dans le document XSL les <xsl:template match=”...” /> qui correspondent le mieux à ces noeuds. Dans ces templates on utilise alors <xsl:value-of select=”...” /> pour extraire les données.
Le mode “push” est idéal pour travailler sur une collection de noeuds, c’est une sorte de boucle déguisée. Alors que le mode “pull” sert à extraire les données lorsqu’on sait exactement où elles se trouvent.

Pour générer le rendu du ticket on utilise les deux : le mode “push” pour organiser le ticket en sections “entête”, “corps” et “pied” et le mode “pull” dans ces sections pour extraire les données et les mettre en forme.

<?xml version="1.0" encoding="utf-8"?>

<xsl:stylesheet version="1.0"

               xmlns:xsl="http://www.w3.org/1999/XSL/Transform">

 <xsl:output method="xml" version="1.0" encoding="utf-8"/>


<!-- Paramètres fournis par l’application -->

<xsl:param name="double_affichage">false</xsl:param>

<xsl:param name=”...”>...</xsl:param>


<xsl:template match="/">

<ticket>

 <select>imprimante</select>

 <pagecode>858</pagecode>


 <xsl:apply-templates select="ticket/entete" />

 <xsl:apply-templates select="ticket/lignes" />

 <xsl:apply-templates select="ticket/bilan" />


 <xsl:call-template name="pied"/>

</ticket>

</xsl:template>


<xsl:template match=”entete”>

 <!-- Un ticket doit obligatoirement utiliser la commande “<identification/>” -->

<!-- NOM DU MAGASIN EN HAUT DU TICKET avec les coordonnées du magasin -->

 <lf/>

 <aligne>centre</aligne>

 <style>gras</style><identification /><style>normal</style><lf/>

 <identification niveau="3" /><lf/>


<!-- COMMENTAIRE GLOBAL EN HAUT DU TICKET -->

<!--

 <xsl:call-template name="commentaire" />

-->


 <!-- Imprimer l’entête du ticket : logo, vendeur, date, numero, entetes

      de la table des articles... -->

</xsl:template>


<xsl:termplate match=”article”>

 <!-- Imprimer la ligne correspondante à un article -->

</xsl:template>


<xsl:termplate match=”menu”>

 <!-- Imprimer la ligne correspondante à un menu -->

</xsl:template>


<xsl:template match=”sous-total | plateau”>

 <!-- Imprimer les articles du menu -->

 <xsl:apply-templates select="*" />

 <!-- Imprimer la ligne du menu -->

</xsl:template>


<xsl:template match="bilan">

 <!-- Imprimer le total du ticket -->


 <!-- Imprimer les encaissements dans un certain ordre -->

 <xsl:if test="encaissements[encaissement or acompte or avoir or voucher]">

   <xsl:apply-templates select="encaissements/acompte" />

   <xsl:apply-templates select="encaissements/avoir" />

   <xsl:apply-templates select="encaissements/voucher" />

   <xsl:apply-templates select="encaissements/encaissement" />

   <xsl:apply-templates select="encaissements/@rendu" />

   <xsl:apply-templates select="encaissements/@surplus" />

 </xsl:if>


 <!-- Imprimer les TVAs -->

 <xsl:apply-templates select="tvas"/>

</xsl:template>


<xsl:template match="acompte">

</xsl:template>


<xsl:template match="avoir">

</xsl:template>


<xsl:template match="voucher">

</xsl:template>


<xsl:template match="encaissement">

</xsl:template>


<xsl:template match="@rendu">

</xsl:template>


<xsl:template match="@surplus">

</xsl:template>


<xsl:template match=”tva[. &gt; 0]”>

 <!-- Imprimer la ligne TVA > 0 -->

</xsl:template>


<!-- La TVA est à zéro : ne rien faire pour ne pas l’imprimer -->

<xsl:template match=”tva[.=0]”>

</xsl:template>


<xsl:template name=”commentaire”>

</xsl:template>


<xsl:template name=”pied”>

<!-- COMMENTAIRE GLOBAL EN BAS DU TICKET -->

<!--

 <xsl:call-template name=”commentaire” />

-->


<!-- Un ticket doit obligatoirement utiliser la commande “<identification/>” -->

<!-- NOM DU MAGASIN EN BAS DU TICKET avec un message de remerciement -->

 <lf/>

 <aligne>centre</aligne>

 <identification />" VOUS REMERCIE..."<lf/>

 <aligne>gauche</aligne>

</xsl:template>


</xsl:stylesheet>


Technologies

Il s'agit d'une application Microsoft Windows. Elle est optimisée pour Windows XP Pro et Windows XP Embedded for Point of Sale (WePOS) et POS Ready2009,  POS Ready7.

elle est développée en Delphi (Pascal Objet) à l’aide de Borland Developer Studio 2006 Architect (www.codegear.com, anciennement Borland www.borland.com), CRISALID s’attache à suivre l’évolution des technologies Borland (tous les logiciels CRISALID ont été développés avec les outils Borland/CodeGear, depuis Turbo Pascal « Objet » version 5.5 pour les outils MS-DOS)

Pour une grande partie de ses développements et de ses architectures, le choix de CRISALID s’est porté sur le logiciel libre. La communauté et le dynamisme des développeurs de toutes les nationalités qui participent à ces projets permettent à CRISALID d’avancer toujours plus vite et de rester toujours à la pointe des innovations technologiques. CRISALID participe activement à l’amélioration, aux tests et au développement de Logiciels Libres.

Le SGBD utilisé est Firebird (www.firebirdsql.org), un dérivé Open Source issu d’Interbase 6.0. La version actuellement embarquée de Firebird est la 2.1. Firebird ne nécessite pas d’administration (hormis les sauvegardes régulières des bases de données) et embarque toutes les technologies de pointe en matière de SGBD : Multi-Plateformes (Windows, Linux, MacOS, Solaris), Architecture Multi-Générationnelle (MGA) de la lignée Interbase, Triggers (déclencheurs), Procédures Stockées, Fonctions Utilisateur, Exceptions, Domaines, Evènements, Blobs (Objets binaires), Optimiseur, Combinaison des index par les opérations de l’algèbre booléenne (Index Bitmaps)… Voir le livre blanc « Firebird en Entreprise » annexé à ce document.

le ogiciel utilise intensivement le format XML pour stocker les données et les configurations locales. Le moteur XML embarqué est MSXML 4.0 de Microsoft (http://msdn.microsoft.com/xml) qui permet la transformation des flux XML par des feuilles de styles XSL-T (eXtensible Styesheet Language - Transformation), l’interrogation des ensembles de données XML par XPath, la manipulation et la création par le Document Object Model (DOM).

Le reporting est réalisé par FastReport 4 (www.fast-report.com). FastReport permet l’export des rapports au format PDF, l’impression de codes à barres et la redistribution de son modeleur de rapports sans royalties au client final. Tous les rapports imprimables de Neptis sont ainsi modifiables sans recompilation du projet.

Les grilles de données sont gérées par les composants commerciaux de TMS Software (www.tmssoftware.com) et par Virtual TreeView (www.soft-gems.net)

L’interface est enrichie à l’aide des composants OpenSource JVCL (http://homepages.borland.com/jedi/jvcl) et JCL (http://homepages.borland.com/jedi/jcl)

La connexion à Firebird est prise en charge par les composants OpenSource UIB (www.progdigy.com) dont CRISALID est l’un des contributeurs.

Le pilotage des périphériques Point de Vente est opéré par OPOS (OLE for Point of Sales) et les objets de contrôle communs sont ceux fournis par Monroe Consulting Services (www.monroecs.com). Cette technologie permet à Neptis d’adresser tous les périphériques des classes de périphériques qu’il prend en charge et dont les fabricants fournissent des objets de service (comme Samsung, Epson, Citizen, PSC…) Neptis est cependant capable d’utiliser des imprimantes Windows (A4) et des imprimantes label professionnelles (Zebra, SATO, Toshiba…)

La gestion des exceptions non gérées par le code (bugs) est assurée par EurekaLog (www.eurekalog.com) qui permet l’envoi de mails contenant un rapport précis du problème qui permet à CRISALID d’obtenir jusqu’à la ligne de code qui a généré l’erreur et la pile des appels de méthodes qui ont conduit à cette erreur.

L’application est déployée à l’aide d’InnoSetup (www.jrsoftware.org) qui est un générateur d’assistants d’installation Open Source dont Crisalid est le traducteur officiel pour la langue française.


Panorama des fonctionnalités de Neptis

  • Encaissement tactile ergonomique qui permet une grande fluidité au magasin
  • Technologie exclusive de Queue Boosting qui permet d’augmenter sa capacité d’encaissement jusqu’à 20% lorsque 80% des encaissements sont réalisés habituellement en espèces
  • Contrôle du point de vente : rappel des tickets, filtrage multi-critères, éditions et rapports qui permettent au gestionnaire de suivre pas à pas le fonctionnement de son magasin
  • Gestion des comptes clients
  • Gestion des cartes de fidélité
  • Gestion des vendeurs, identification des vendeurs, hiérarchisation et gestion des autorisations
  • Attribution d’un tiroir par vendeur
  • Pilotage des périphériques point de vente standards :
    • Imprimantes
    • Afficheurs clients
    • Tiroirs caisse
    • Scanners et Douchettes de Codes à Barres
    • Systèmes d’identification des vendeurs (stylos magnétiques, clés dallas)
    • Imprimantes de chèques et lecteurs CMC7
    • Balances
    • Terminaux de Paiement Electronique
    • Gestion automatique des espècesLecteurs de cartes magnétiques
  • Edition d’étiquettes sur planches d’étiquettes (Imprimantes A4) ou sur rouleaux d’étiquettes (Imprimantes Label professionnelles). Les étiquettes sont personnalisables et tous les formats sont réalisables, par exemple : Etiquettes « anneaux » que l’on noue autours d’un arbuste ou étiquettes « piquets » à planter pour la fleuristerie.
  • Capacités de stockage limitées seulement par la taille des disques
  • Interface entièrement adaptable à chaque métier
  • Lancement d’applications Microsoft Windows tierce directement depuis l’interface du logiciel. Cela limite les risques d’erreurs de manipulation de Windows par du personnel qui n’est pas toujours formé à son utilisation ainsi que les risques d’utilisation frauduleuse du système par des opérateurs malveillants.
  • Modulaire : les fonctionnalités de gestion et de reporting sont réalisées par un ensemble de plugins
  • Extensible : l’architecture Client-Serveur de Neptis lui confère la capacité à se connecter aussi simplement en réseau LAN, WAN qu’à fonctionner en monoposte.
  • Communiquant : Neptis est un système ouvert, les partenaires logiciels et matériels sont encouragés à développer leurs propres extensions pour Neptis. Les technologies embarquées (SGBD Open Source, XML) permettent une compatibilité et une ouverture maximum vers les technologies de pointe.
  • Robuste : Chaque nouvelle version de Neptis subit une période de tests intensifs. Puis est déployée chez un ensemble de sites pilotes appartenant à tous les corps de métiers.

La politique de développement de logiciels de CRISALID est rationnelle et a pour objectif principal de limiter les risques. Toutes les demandes spécifiques de nos clients sont étudiées par nos services techniques et commerciaux. Lorsqu’un accord a été trouvé entre ces différents acteurs, les nouvelles fonctionnalités sont intégrées à la version standard du logiciel. Elles sont ainsi accessibles à tous les clients de CRISALID garantissant une évolutivité constante de nos solutions. De plus la limitation du nombre des versions du logiciel actives simultanément permet de réduire les coûts de maintenance et de formation des techniciens, des distributeurs et des commerciaux.

Fonctionnalités

La fonctionnalité principale est de gérer l’encaissement et la facturation dans un magasin.

L’accessibilité est considérée chez CRISALID comme une fonctionnalité indissociable du logiciel. Plus de 25 années d’expérience chez CRISALID nous ont permis de concevoir un logiciel ergonomiquement accessible à tous les publics d’utilisateurs.

La stabilité et la fiabilité son traitées prioritairement à toutes les autres fonctionnalités. CRISALID vend ses logiciels directement à ses clients dans les régions couvertes par ses filiales (Nord-est, Sud-est et Bourgogne). Cette proximité avec le terrain nous pousse constamment à améliorer la fiabilité de nos logiciels.

Fonctions standard :

ADDON

Permet de valider ou de modifier le code Addon lors de la saisie manuelle des articles presse.

ANNULE

Annule l'élément sélectionné sur le ticket actif. Gère automatiquement le type d'annulation (DERNIER, RETOUR, APRES ENCAISSEMENT) selon l'état du ticket.

AUTORISE

Utilise le TPE configuré pour autoriser un paiement électronique (CARTE ou CHEQUE). Supporte également le TPE Axalto et l’extension fidélité de la société APPLICAM.

AVOIR

Crée un avoir manuel en utilisant le montant tapé sur le pavé numérique.

CAISSE

Fonctions de gestion de la caisse, permet la saisie de fond de caisse, d’entrées et de sorties d’argent, les remises en banque, la clôture et le calcul du financier.

COMMENTAIRE

Permet d’ajouter un commentaire (Texte libre) au ticket ou à l’article sélectionné.

COMPTE

Accès aux comptes clients. Ajoute le ticket courant au compte spécifié.

EXECUTE

Exécute une application externe (exécutable Windows)

EXPORT

Export natif de certaines données (Presse et Pointages)

FICHE

Ouvre les fiches de paramétrage (articles, configuration, rappel de tickets, recherches alphanumériques…)

FICHE_REPAS

Impression d’une fiche type « Repas Complet » à partir du montant du ticket en cours.

FIDELITE

Accès aux cartes de fidélité.

GESTION

Fonctions de gestion, transforme le ticket actif en ticket d’inventaire, d’entrée de stock, de commande…

IMPORT

Import natif de tickets (XML)

MANUEL

Ouvre une boîte de dialogue dans laquelle l’utilisateur peut taper une fonction interne à exécuter.

PART

Accès aux conditionnements d’un article pendant la vente. Permet d’utiliser une même touche pour vendre plusieurs conditionnements d’un même article (Baguette et ½ Baguette ou Paquet et Cartouche, ou Gâteau en 2, 4, 6, 8, 10, 12… personnnes)

PLU

Vend un article d’après son code PLU

PLUGIN

Lance un module d’extension

POINTAGE

Pointage et dépointage des vendeurs

PORTABLE

Téléchargement des fichiers d’un portable de saisie Opticon PHL 1700/2700

PRIX

Gestion des prix de vente : activation, marquage pour mise à jour manuelle et modification des prix.

PROGRAMME

Accès au mode de programmation des touches du clavier.

QUANTITE

Modification du multiplicateur de quantité qui permet de vendre la même quantité de plusieurs articles en une seule fois.

QUITTE

Ferme l’application et permet de redémarrer ou d’éteindre Windows.

REMISE

Effectue une remise sur le dernier article ou le dernier sous-total. Remises supportées : en pourcentage, en montant, offerts, prix spécial et prix menu.

SON

Joue une séquence de notes sur le buzzer interne de la machine.

ST

Crée un sous-total ou un sous-total « Plateau » en regroupant tous les articles saisis jusqu’au précédent sous-total ou au début du ticket.

STOCK

Transforme le ticket actif en ticket de gestion du stock (inventaire, inventaires morcellés, remise à zéro du stock…)

TARIF

Modification du tarif de vente. Peut s’appliquer au ticket complet ou seulement aux nouveaux articles saisis.

TEST

Accès au mode test : les articles scannés ne sont pas vendus mais s’ils sont identifiés une fiche descriptive est affichée à la place du ticket.

TICKET

Fonctions de gestion du ticket. Permet de mettre un ticket en attente, de l’imprimer, de l’encaisser, de le marquer pour validation ultérieure, de l’annuler, de le transformer en commande (mise en attente prolongée), de faire une remise globale ou de pré remplir le pavé numérique avec une valeur calculée d’après un pourcentage du montant du ticket.

TIROIR

Ouverture manuelle du tiroir. Attribution d’un tiroir à un vendeur.

TOUCHE

Simule la saisie d’une touche sur le pavé numérique

VENDEUR

Connexion et déconnexion d’un vendeur.

 

Fonctions étendues :
Ces fonctions ne servent pas directement à la vente mais elles sont utiles pour la maintenance, les tests et le débogage du logiciel.

#ALEA#

Générateur de données aléatoires. Permet de générer des codes à barres, des prix, des valeurs numériques ou des quantités.

#FILTRER_RAPPEL#

Filtrage des tickets dans le rappel tickets. Permet de rechercher les tickets par leur numéro, le vendeur qui les a encaissé, leur montant, ceux qui ont été imprimés, mis en compte, marqués pour validation ultérieure ou annulés.

#MAINTENANCE#

Accès au module de maintenance des bases de données.

#RECALCULER_STATS#

Recalcule les Statistiques de tous les tickets.

#VOIRXML#

Permet de visualiser le document XML « brut » qui constitue le ticket.

 

Modules d’extension standard :
Ces modules d’extension sont fournis dans toutes les versions de Neptis. Ils permettent de réaliser les tâches administratives et de gestion. Ils permettent à CRISALID de spécialiser facilement l’application pour un métier donné.

ASSISTANT

Générateur de claviers. Ce module permet de créer des claviers d’articles en utilisant la base de données et une fenêtre modèle.

COMPTES

Traitements de masse sur les comptes clients et les cartes de fidélité.

ETICAB

Imprime une planche d’étiquettes à partir du ticket actif.

ETIQUETTES

Imprime une planche d’étiquettes à partir de la base de données.

EXPORT

Exportation du fichier des articles.

IMPORT

Importation des articles, des fenêtres et des comptes clients.

INTERNET

Lance une connexion réseau RAS. Supporte le service MiniDNS d’association d’IP dynamique avec un nom de domaine.

INVENTAIRE

Etat du stock et écart d’inventaire.

NAVIGATEUR

Navigateur Web simplifié.

STATS

Navigateur de Statistiques. Permet de naviguer intuitivement dans les résultats financiers.

SYNTHESE

Interroge les tickets et extrait toutes les informations de mouvement d’articles sur une période donnée. Ces informations sont corrélées avec la base des articles et cela permet de générer, par exemple des rapports de calcul de marges.

VENTES

Etat des ventes.

VERIFBDD

Vérifie la structure et les données des bases de données.



 



Modules d’extension métiers :

Pour Atthis (Tabac/Presse) nous fournissons un module de commande Tabac qui sait fabriquer des propositions de commande et les envoyer, via un émulateur minitel ou Internet au serveur d’Altadis Distribution France. Le Module Web d’Altadis Distribution France a été développé en collaboration avec CRISALID.

Pour Aliris (Boulangerie/Pâtisserie) nous fournissons deux modules d’exportation des bandes de contrôle (tickets et informations logistiques) vers EPI (Ancien logiciel CRISALID) et VIF (Fournisseur d’applications de gestion) .

Fidélité :

CRISALID fournit, en standard 5 moteurs de fidélité :

  • NULL permet d’utiliser le moteur d’identification et de stockage de la fidélité sans prendre de décision. C’est un moyen élégant d’identifier les clients par leur nom.
  • POINTS permet d’associer des points à chaque article acheté par le client. Les points sont cumulés dans la « CARTE de fidélité » gérée par l’application. Grâce à ses points le client peut acquérir d’autres articles.
  • BONUS permet de constituer un Porte Monnaie Electronique. Chaque article acheté par le client lui rapporte un bonus qu’il peut ensuite déduire du montant de son ticket comme bon lui semble (Remise Immédiate)
  • SIMPLE et PASSAGES permettent d’associer une action de fidélité (Ex. Remise d’un pourcentage du montant des achats cumulé sur la carte de fidélité) à un nombre de passages.

Architecture du moteur de fidélité Crisalid

Le fonctionnement du moteur de fidélité Crisalid repose sur deux constats : chaque client est différent et la nécessité d’ouverture. Le challenge a consisté à construire une architecture ouverte, capable de se connecter à des systèmes de gestion de la fidélité tiers et faciles à adapter aux besoins de chacun de nos clients en prenant en compte chacune de leurs spécificités. Cette architecture repose trois modèles de la base de données : le modèle d’articles, celui du ticket et le modèle des clients. Le moteur de fidélité permet de faire le lien entre les articles, la carte de fidélité ou l’historique du client et le ticket en cours de création.

Un moteur de fidélité gère un déclencheur qui peut être n’importe quelle variable des modèles ticket, article et client. Par exemple, un déclencheur courant est basé sur le nombre de passages, il s’exprime sous la forme : « au dixième passage faire quelque chose pour le client », ou bien « lorsque le montant du ticket dépasse … » ou encore « à chacun des ticket… »

Lorsque le déclencheur est activé, le contrôleur de l’application demande au moteur de fidélité de lui fournir les caractéristiques de l’action à effectuer : « … offrir tel ou tel article » ou bien « faire une remise de x % du cumul des achats précédents au ticket courant » ou encore « faire une remise de y % sur le montant du ticket courant »

Si le déclencheur n’est pas activé, le contrôleur demande au moteur de fidélité de prendre en compte le passage du client, cette opération est systématique : on cumule un passage sur la carte de fidélité ainsi que le montant des achats réalisés dans le compteur d’achats. Dans le cas contraire, si une action fidélité a été réalisée, la carte courant est cumulée dans un historique des cartes de fidélité et elle est remise à zéro. Dans certains cas on peut choisir de pré-initialiser la nouvelle carte, par exemple en prenant en compte un pourcentage du cumul des achats de la carte précédente.

Une autre méthode consiste à prendre en compte les attributs des articles présents dans le ticket. On peut alors décider qu’un article rapporte un certain nombre de « points ». Lorsque ces points sont cumulés ils permettent d’obtenir d’autres articles gratuitement en dépensant ces points pour acquérir des articles dont le nombre de « points d’action » est inférieur au nombre de points détenus par le client.

La dernière méthode est celle du porte-monnaie électronique. Chaque article rapporte un « bonus » convertible en euros que l’on peut à tout moment utiliser comme réduction immédiate sous forme d’une remise en valeur sur le ticket courant. Le montant est utilisé entièrement à chaque fois. Le déclencheur peut-être programmé pour n’autoriser l’utilisation du porte-monnaie électronique que dans certaines conditions (montant des achats minimum, valeur du porte monnaie…)



.
ċ
DocXmlCrisalidv3(7z)
(1385k)
Régis Folny,
8 janv. 2018 à 03:09
Comments