Mise en conformité LF 2016

Documents de référence

  • BOFIP : Bulletin officiel, contraintes minimales
  • Infocert, label NF525 (non disponible), attestation du logiciel
  • Label LNE, attestation du logiciel

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

toutes les données qui concourent directement ou indirectement à la réalisation d'une transaction (y compris […] au moyen d'un module de type « école » ou « test ») participant à la formation des résultats comptables et fiscaux. […] Sont également concernées l'ensemble des données permettant d'assurer la traçabilité de ces données concourant à la réalisation de la transaction et de garantir l'intégrité de celles-ci. 1)

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.

Inalterabilité

Le […] système de caisse doit enregistrer toutes les données d'origine relatives aux règlements. Il doit conserver ces données d'origine enregistrées et les rendre inaltérables. 2)

Il en découle :

Si des corrections sont apportées à des opérations de règlement, que ce soit au moyen du logiciel ou système lui-même ou d'un dispositif externe au logiciel ou système, ces corrections (modifications ou annulations) s'effectuent par des opérations de « plus » et de « moins » […]. Ces opérations de correction donnent également lieu à un enregistrement. 3)

Et finalement :

Pour respecter la condition d’inaltérabilité, l'intégrité des données enregistrées doit être garantie dans le temps par tout procédé technique fiable. 4)

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.

Cette sécurisation peut être assurée par tout procédé technique fiable, c'est-à-dire de nature à garantir la restitution des données de règlement dans l'état de leur enregistrement d'origine. Il peut notamment s'agir d'une technique de chaînage des enregistrements ou de signature électronique des données. 5)

Conservation

En plus du détail, il faut calculer des données cumulatives :

[…] Pour chaque clôture - journalière, mensuelle et annuelle (ou par exercice) - des données cumulatives et récapitulatives, intègres et inaltérables, doivent être calculées par le système de caisse, comme le cumul du grand total de la période et le total perpétuel pour la période comptable. 6)

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.

Les données de règlement étant des données servant à l'établissement de la comptabilité de l'entreprise, elles doivent être conservées pendant le délai de six ans […] 7)

Enfin comme Pastèque est en mode client/serveur, il faut assurer l'intégrité des remontées d'informations

[…] la conservation des données enregistrées ligne par ligne et la conservation des données cumulées peut être réalisée au niveau du système centralisateur, à condition qu'une traçabilité de la remontée des données de règlement des points de vente vers le système centralisateur soit prévue. Cette traçabilité doit permettre à l'administration de vérifier l'exhaustivité du flux des données transférées. 8)

Il n'est pas indiqué si les traces de remontées sont à conserver coté client ou coté serveur.

Archivage

Le logiciel de comptabilité ou de gestion ou le système de caisse doit permettre d'archiver les données enregistrées selon une périodicité choisie, au maximum annuelle ou par exercice. La procédure d'archivage a pour objet de figer les données et de donner date certaine aux documents archivés. Elle doit prévoir un dispositif technique garantissant l'intégrité dans le temps des archives produites et leur conformité aux données initiales de règlement à partir desquelles elles sont créées. Les archives peuvent être conservées dans le système lui-même ou en dehors du système lorsqu'il existe une procédure de purge. 9)

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.

Les archives doivent pouvoir être lues aisément par l'administration en cas de contrôle, y compris lorsque l'entreprise a changé de logiciel ou de système. 10)

La lecture des archives doit être possible indépendamment de Pastèque.

Le logiciel ou système doit prévoir une traçabilité des opérations d'archivage, selon un procédé fiable. 11)

Il faut ajouter un journal d'archivage.

[…] Avant la mise en œuvre de cette procédure de purge, le logiciel ou le système doit garantir la production d'une archive complète des données de règlement (données d'origine et éventuelles modifications), avec la date de l'opération de règlement (année – mois – jour), sur un support physique externe sécurisé. 12)

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.

[…] le système doit conserver dans un état sécurisé […] dans le système lui-même, les données cumulatives et récapitulatives contenues dans le grand total de la période et le total perpétuel pour la période dont les données ont été purgées.

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

Commande = sharedticket
Ticket = ticket clos (payé)

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.

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.

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.

  • Cas simple : pas de partage de commande. La caisse qui ouvre la commande est celle qui l'encaisse. C'est le cas de la plupart des configurations (une seule caisse par point de vente).
  • Cas gros restau : un seul point d'encaissement, plusieurs points de commande, en local. Dans ce cas il suffit de prévoir un reversement manuel d'un poste de prise de commande sur la caisse centrale en local (comme c'est fait avec le papier)
  • Cas extrême : plusieurs points d'encaissement avec plusieurs points de commande. OSEF ?

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

  • L'opération d'ouverture (permet d'ajouter un contrôle d'exhaustivité, début de bande)
    • OPEN <caisse> <hostsequence>
  • L'ouverture et selection d'une commande
    • CORD <id> (create order)
  • Le changement de commande (select)
    • SORD <id> (select order)
  • Tout ajout de ligne à une commande (y compris en quantité négative)
    • ADD <order> <line> <ref> <lbl> <qty> <ht> <rate> <vat>
      • L'identifiant de commande (order)
      • Le numéro de ligne (line)
      • Référence et intitulé (la référence fait office d'ID user-friendly, l'intitulé apparaît sur le ticket)
      • Quantité, montant HT, taux TVA, montant TVA
  • Toute modification d'une ligne à une commande (modification manuelle ou via remise, zone tarifaire)
    • EDT <order> <line> <ref> <lbl> <qty> <ht> <discount> <htdisc> <rate> <vat>
  • Tout ajout de paiement (et toute annulation), y compris le rendu monnaie (autre ligne)
    • PORD <id> <mode> <amount>
      • L'identifiant de ticket
      • Mode de paiement
      • Montant
  • Toute assignation à un client (peut ajouter la ligne de remise globale)
  • Tout changement de la zone tarifaire (ajoute les commandes d'update)
  • Toute application de remise globale sur la commande
    • DISC <id> <rate>
  • Toute finalisation de commande (création d'un ticket)
    • FORD <id> <caisse> <tktnum>
      • L'identifiant de commande
      • L'identifiant de ticket (caisse + numéro)
  • Toute impression d'un ticket (pour éviter la réutilisation du même ticket pour x clients et assurer que les tickets sont imprimés)
    • PRT <caisse> <tktnum>
  • Toute suppression de commande (si on peut le faire)
    • DORD <id>
  • Tout mouvement de caisse (optionnel mais facilite le contrôle de fin de session)
    • IO <mode> <amount>
    • Entrée, sortie, mode, montant
  • L'opération de clôture (permet d'ajouter un contrôle d'exhaustivité, fin de bande)
    • CLOSE

Plus généralement chaque fois que l'utilisateur appuie sur un bouton.

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.

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.

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

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.

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)

Contrôle d'intégrité

Le contrôle d'intégrité des bandes s'effectue à plusieurs niveaux :

  • Ligne par ligne : vérification de la continuité de la numérotation, vérification des checksum
  • Intégrité de la bande : opération 1 = ouverture de caisse, dernière opération clôture de caisse.
  • Intégralité des bandes : vérification de la continuité des hostsequence

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.

Le contrôle d'intégrité des tickets Z s'effectue avec les bandes :

  • Correspondance 1 à 1 entre une bande et un ticket Z (caisse et hostsequence)
  • Correspondance du total par mode de paiement
  • Correspondance du total HT et TVA par taux

Tickets et Agrégats

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.

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 :

  • Un enregistrement en bdd permet l'analyse informative performante (vente par produits, statistiques horaires etc). C'est l'enregistrement actuel, il ne constitue pas une archive et peut être purgé.
  • Un enregistrement fiscal inaltérable pour archive et contrôle. C'est un nouvel enregistrement autonome inaltérable à ajouter. Les déclarations fiscales sont basées sur ces données. Il s'agit d'une archive, elle ne peut être purgée.

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

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.

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.

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

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.

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

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
pasteque/lf2016.txt · Last modified: 2017/07/11 11:49 (external edit)
Recent changes RSS feed CC Attribution-Share Alike 4.0 International Donate Powered by PHP Valid XHTML 1.0 Valid CSS Driven by DokuWiki