= Mise en conformité LF 2016 =
Résumé des contraintes.
Ce résumé concerne uniquement la mise en conformité au regard du BOFIP. Les cahiers des charges pour les attestations sont nettement plus lourds et précis.
Données concernées.
Concrètement, il s'agit de toutes les opérations réalisées sur la caisse (constitution d'un ticket, réception des paiements) ainsi que toutes les sommes de contrôles associées.
Par ailleurs, la comptabilité ajoute dans le journal de caisse toute entrée ou sortie de caisse. S'ajoutent donc les mouvements et les contrôles à l'ouverture et à la clôture.
Inaltérabilité.
Il en découle :
Et finalement :
Sécurisation.
La sécurisation va de pair avec l'inaltérabilité. Elle consiste à vérifier que les données ne sont pas altérées.
Conservation.
En plus du détail, il faut calculer des données cumulatives :
Ce sont les tickets Z quotidiens, plus un aggrégat mensuel et annuel (par exercice, au minimum annuelle). Ces données doivent être conservées pendant 6 ans.
Chaque ticket ajoute un champ cumul pour la période (taille supérieure). Les Z quotidiens conservent le cumul jusqu'à la fin du mois et mensuels jusqu'à la fin de l'exercice. La comparaison entre le cumul du dernier Z quotidien doit correspondre avec le mensuel, idem avec les mensuel et l'annuel.
Enfin comme Pastèque est en mode client/serveur, il faut assurer l'intégrité des remontées d'informations
Il n'est pas indiqué si les traces de remontées sont à conserver côté client ou côté serveur.
Archivage.
Une fois l'archive créée, il est possible de purger les données de Pastèque. À minima de les sortir de la base de données utilisée pour l'alléger.
La lecture des archives doit être possible indépendamment de Pastèque.
Il faut ajouter un journal d'archivage.
Les archives doivent être enregistrées sur un support physique externe. Par exemple par l'envoi d'une clé USB avec le fichier chiffré via clé privée et checksum.
La purge ne concerne pas les agrégats qui doivent rester enregistrés. Seules les données ligne par ligne peuvent être supprimées définitivement avec copie sur support physique (mais les conserver reste plus simple et pas forcément très coûteux en terme d'espace).
Solutions apportées.
<WRAP center round info 60%> Commande = sharedticket 
Ticket = ticket clos (payé) </WRAP>
Bande de caisse.
La bande de caisse enregistre toutes les opérations réalisées sur la caisse. Inaltérable, elle permet de contrôler que toutes les informations ont bien été enregistrées.
<WRAP center round important 60%> Ce truc peut vite devenir monstrueux avec le partage de commande et gestion de conflits en cas de connexion dégradée et non partage de verrous.
Une caisse autonome est facile à gérer. </WRAP>
Le problème vient du non partage des données en mode déconnecté et de la non séparation des fonctions commande et encaissement. C'est à dire qu'il est possible pour n'importe quel caisse d'être utilisé comme prise de commande et comme règlement de commande. Ce qui veut dire qu'il est impossible en mode déconnecté de savoir au moment de l'encaissement si la commande est complète.
On se contentera du modèle de caisse commande/encaissement unique pour commencer. On pourra rajouter des modules de prise de commande numériques dans la v9. Pour le cas extrême, il ne se présentera peut être jamais.
Contenu.
Plus généralement chaque fois que l'utilisateur appuie sur un bouton.
<WRAP center round important 60%> C'est un giga log qui permettrait même de rejouer les ventes en isolation complète d'une caisse et reconstituer l'intégralité du Z. Le format binaire permet de compresser le log au maximum. Il faut le conserver 6 ans. 32 octets de checksum minimum par opération. </WRAP>
Chaque ligne doit être datée. Pour assurer l'inaltérabilité, chaque enregistrement est numéroté et chaîné au suivant et au précédent. De cette manière, l'édition manuelle de la bande nécessite le recalcul complet de la bande et donc l'usage d'un programme externe. Pour plus de sécurité la bande peut être enregistrée au format binaire, ce qui implique d'étudier le format dans le code source pour la réalisation d'un programme d'édition. Le chiffrement par clé publique apporte plus de complexité sans pour autant ajouter de sécurité (la clé étant publique, la reconstitution de la bande suit le même procédé que pour le format binaire mais ajoute des difficultés à l'installation).
De plus, les données doivent être auto-suffisantes. Il n'y a donc pas de récupération de données externe par ID par exemple.
<WRAP center round help 60%> Si la bande enregistre toutes les modifications, ajout et suppressions, le ticket peut-il ne conserver que le résultat final (i.e. ne pas indiquer les lignes d'erreurs) ?
Réponse : non, ne prenons pas de risque </WRAP>
La bande de caisse est liée à la session (ouverture/clôture). Ces sessions étant numérotées, il est aisé de s'assurer que tout est remonté (pas de trou dans la suite des sessions de caisse). Ce checksum peut être utilisé pour le premier enregistrement de la prochaine bande histoire de chaîner tout de bout en bout.
<WRAP center round important 60%> Pour aller jusqu'au bout, il reste la possibilité de supprimer le cache en début de session. La bande peut donc ajouter un contrôle de continuité dans le cache (présence du précédent close) </WRAP>
Contrôle d'intégrité.
Le contrôle d'intégrité des bandes s'effectue à plusieurs niveaux :
<WRAP center round important 60%> Cas tordu : l'ouverture de la session sur un poste, abandon de ce poste puis reprise de la session sur une autre machine avec le même nom de caisse. La bande est coupée en deux. </WRAP>
Le contrôle d'intégrité des tickets Z s'effectue avec les bandes :
Tickets et Agrégats.
<WRAP center round info 60%> La notion d'archive dans le BOFIP fait référence à un document figé non éditable. Par exemple lors de la clôture d'une période comptable, celle-ci est archivée (non modifiable et datée définitivement).
La purge au sens du BOFIP concerne la suppression des données hors archive après intégration dans ces dernières. </WRAP>
Enregistrement des tickets.
Chaque ticket a valeur de facture, il faut donc s'assurer qu'ils ne sont pas altérés ni modifiés.
L'enregistrement des tickets est double :
Comme pour les bandes de caisse, les archives sont numérotés (nom de caisse + numéro de ticket), avec checksum et chaînage. Le contenu peut être du plain texte au format json pour garantir l'évolution du schéma dans le temps et assurer une retro-compatibilité.
L'archive est intégrée au moment de la clôture de la période (soit la clôture de la session de caisse). La périodicité choisie est donc d'approximativement 1 jour ce qui est conforme avec le BOFIP (maximum 1 an).
<WRAP center round important 60%> Pour les réfractaires à la clôture quotidienne, il faudra s'y mettre pour conserver l'attestation. Article 170 du BOFIP.
Nuance : le cahier des charges de LNE indique cette obligation comme donner la possibilité à l'utilisateur de le faire quotidiennement. À sa charge de le faire. </WRAP>
Enregistrement des tickets Z et agrégats.
Comme pour les tickets, les tickets Z font l'objet d'un enregistrement inaltérable. Il n'existe par contre pas de donnée dédiée actuellement. Les tickets Z sont directement archivés.
Le BOFIP n'indique pas si les cumuls sont à effectuer par caisse ou sur l'ensemble par période (quotidienne, mensuelle et par exercice).
Dans le doute, faisons les deux.
Chaque caisse donne un Z à la clôture. Si ce Z correspond vaguement à une journée, il est utilisé pour l'agrégat quotidien. Sinon une ou plusieurs coupures arbitraires doivent être effectuée.
L'agrégat quotidien regroupe chaque Z (ou portion ou concaténation de Z) et le total, plus le cumul du mois.
<WRAP center round info 60%> Exemple agrégat du 02/04 (avec un 01/04 à 50 de CA et 10 de TVA 20)
caisse 1 CA 100, TVA 20 100/20 
caisse 2 CA 10, TVA 20 10/2 
Total CA 110, TVA 20 110/22 
Cumul CA 240, TVA 20 240/48 Grand total CA 54600, TVA 20 54600/10920 </WRAP>
L'agrégat mensuel calcule les données de ventes des caisses sur toute la période du mois. Si une session de caisse est largement à cheval entre deux mois, une coupure doit être réalisée.
L'agrégat mensuel doit correspondre à la somme des agrégats quotidiens, sinon on dira que les données ont été altérées entre deux.
Idem pour l'exercice.
<WRAP center round todo 60%> Selon LNE, le texte est à comprendre dans le sens laisser à l'utilisateur la possibilité de faire une clôture journalière et mensuelle. Pas forcément de faire les deux.
N'est toujours pas indiqué si la clôture est caisse par caisse ou globale </WRAP>
Purge.
Les archives ne concernent que les données non archivées. C'est à dire les données tickets actuelles (TICKETS, TICKETLINES etc). Ne peuvent être purgées que les données qui ont fait l'objet d'une archive.
La suppression de ces données doit faire l'objet d'un enregistrement de purge. Une purge crée donc un document archivé listant tous les identifiants de tickets (caisse + numéro, mais aussi lignes et tout ça) purgés.
Notes en vrac.
Suppression des fonctionnalités hors encaissement.
BOFIP sur les documents justificatifs de comptabilité.
Les systèmes de gestion de stock, production, immobilisation, peuvent faire l'objet du contrôle. Histoire de ne pas s'embêter avec tout ça. Pastèque ne DOIT PAS être utilisé fiscalement pour tout autre usage que les déclarations de vente (CA, TVA).
Exit donc tout ce qui ne s'intègre pas dans un ticket, comme la gestion du stock.
Ces fonctionnalités doivent faire l'objet d'un logiciel annexe. Ça tombe bien les tables en bdd sont indépendantes des tables de ventes.
1)
BOFIP, article 50
2)
BOFIP, article 80
3)
BOFIP, article 90
4)
BOFIP, article 120
5)
BOFIP, article 140
6)
BOFIP, article 170
7)
BOFIP, article 200
8)
BOFIP, article 210
9)
BOFIP, article 220
10)
BOFIP, article 230
11)
BOFIP, article 240
12)
BOFIP, article 250