Architecture logicielle

TITRE

Architecture

DOC-TEC-1019

V1

DATE

REDACTION

VALIDATION

OBJET DE LA REVISION

NF525

Publication sur Google Site

NOM

19/10/2016

Régis FOLNY

Grégory Gallier-Lachaise

Grégory Gallier-Lachaise

13/12/2016

Régis FOLNY

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 :

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:

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:

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 dans le serveur de licences

L'application valorise les données cumulées en TTC

Les périodes automatiques:

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 csv doivent être ouverts avec LibreOffice Calc
Les fichiers xml et Json avec Notepad++


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:

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 :

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é :

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 :

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 :

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 :

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>

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

Entete

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

promotion/@nombre

promotion/article

promotion/article/@addon

promotion/article/@annee

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

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

Code interne de l’article

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.

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

<nom>/@iso

<nom>/date

<nom>/heure

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

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) :

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

Ligne Article (noeuds <article>)

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.

Menus

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.

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

(sous-total | plateau)/@valeur

(sous-total | plateau)/@typeRemise

(sous-total | plateau)/@remise

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

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

[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

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

bilan/avoir/@validite

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

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

bilan/voucher/@montant

bilan/voucher/@debut-validite

bilan/voucher/@fin-validite

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

Valeur du voucher

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

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.

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

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

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 :

 

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.

 

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é.

 

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é :

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…)

.