L’équipe de fiskaltrust sait que le chemin de la mise en conformité avec la loi des systèmes d’encaissement est parsemé d’embuches. La législation a défini dans la loi, les principes fondamentaux de ce qui est attendu des fabricants et des exploitants de TPV. Puis les principes et les attendus ont été précisés par plusieurs Bulletins Officiels des Impôts. Enfin, les deux organismes de certification ont adapté leurs référentiels respectifs et ont interprété les exigences de la loi à leur manière. Mais qu’en est-il vraiment des principes de base de la loi aujourd’hui ? Lisez la suite pour un compte rendu neutre et indépendant.
Pourquoi seulement quatre piliers ?
En France, on ne pense pas beaucoup aux règles exactes qui définissent tout jusqu’au dernier virage. Non ! On part bien plus du principe que si les pierres angulaires sont définies, chacun peut les mettre en œuvre comme il l’entend. Cette liberté donne aux fabricants de caisses enregistreuses beaucoup de possibilités et aussi de liberté.
Dans le BOI-TVA-DECLA-30-10-30 du 30 décembre 2020, la 2e section définit plus en détail les quatre principes ou spécifications. fiskaltrust aussi, se penche sur la question pour réduire les mythes qui l’entourent et être en mesure d’offrir un système de point de vente sûr et conforme, avec une vision claire.
Les quatre principes ont besoin d’une base !
La législation indique clairement que seuls les systèmes de point de vente ou, dans le cas d’un logiciel multifonctionnel (PMS pour les hôtels, systèmes ERP ou similaires), seul le module de point de vente doit être sécurisé.
L’objectif est clairement défini comme étant la vérification des données enregistrées par les autorités fiscales. Cependant, aucune spécification exacte ou solution technique n’est prescrite dans la loi ou le règlement. Ainsi, l’élaboration de la solution technique est confiée à la seule responsabilité du secteur privé.
Le logiciel utilisé doit donc enregistrer toutes les données de paiement originales, les rendre inaltérables, les stocker en toute sécurité et permettre leur archivage.
Le 1er pilier – Inaltérabilité
C’est le I de Inaltérabilité dans ISCA et il définit comme première étape la prévention contre de modifications ultérieures. En examinant les données concernées, il s’agit principalement de données concernant des biens et/ou des services pour lesquels une contrepartie est attendue et pour lesquels un reçu est émis. La question de savoir si cela s’applique réellement n’a pas importance ici, il suffit que la contrepartie soit attendue et que le reçu soit délivré.
Quelles sont les données affectées ?
Il peut y avoir des données supplémentaires (déterminées par d’autres principes juridiques), mais la liste suivante fixe la barre inférieure à cet égard.
- Numéro du reçu
- Date et heure
- Numéro de caisse (ou numéro de terminal)
- Montant total de la recette (toutes taxes comprises)
- Détails de l’article et/ou du service (description, quantité, prix unitaire, montant total hors taxe, taux de TVA appliqué)
- Toutes les données concernant les méthodes de paiement
En outre, toutes les données qui assurent la traçabilité et l’intégrité des données ci-dessus.
L’administrateur peut-il modifier les données ?
Il est également clairement indiqué ici qu’une fois les données stockées, elles ne peuvent être modifiées directement par quiconque. Cela a également pour conséquence que toutes les modifications ne peuvent être effectuées que par des transactions plus/moins. Il est même précisé que si aucun bon/transaction lié n’est créé, le bon original doit être annulé et un nouveau doit être créé avec les modifications souhaitées.
La première étape consiste à s’assurer que les données sont sécurisées au niveau de l’application. Cela prive l’utilisateur de toute possibilité de modification par le système de caisse. Cela signifie qu’il ne doit y avoir aucune fonction, module ou outil permettant de modifier directement les données.
L’étape suivante est la sécurité au niveau du stockage des données. Comme l’accès aux données ou à une base de données ne peut jamais être empêché, il faut prouver ici que les données n’ont pas été modifiées. Cela peut être assuré par une ou plusieurs techniques. Par exemple, une empreinte digitale numérique (valeur de hachage sur toutes les données), un chaînage simple ou multiple est possible ou une copie miroir immédiate sur un support de données extérieur au système est également possible.
Et comment y parvenir techniquement ?
La législation fait ici plusieurs suggestions :
- empêcher l’accès des utilisateurs à toutes les possibilités de modification
- détecter chaque accès/changement de données et suivre chaque changement possible
- prouver que les données originales n’ont pas été modifiées
- fournir un système de preuve approprié.
Ces quatre points sont tous valables, mais ils ne sont pas tous techniquement réalisables. Par conséquent, un mélange des quatre se produira. L’accès aux données sera limité autant que techniquement possible,aussi le hachage et la concaténation pourront au moins être utilisés pour détecter les changements. Bien que le jeu de données original ne puisse être récupéré.
Voulez-vous savoir comment le fiskaltrust.Middleware implémente ceci pour votre système POS ? Contactez sans engagement notre responsable pour la France.
Le 2ème pilier – Sécurisation
Il s’agit du S pour Sécurisation dans ISCA et il définit la deuxième étape comme la prévention de la suppression ou de l’altération. Ici, il s’agit surtout de sécuriser les données enregistrées et de laisser des traces si les données ont été supprimées ou modifiées.
Le terme « sécurité » n’est pas utilisé dans le sens d’une restriction d’accès. Mais tous les paiements, qui sont enregistrés dans un système POS par n’importe quelle personne, doivent être sauvegardés. Mais toutes les modifications apportées aux données d’origine sont également soumises à la sécurité et doivent être conservées.
Afin d’exclure toute autre possibilité, les données d’un système POS qui sont enregistrées en mode école doivent être clairement identifiées. En externe, avec une mention clairement reconnaissable sur chaque reçu; et en interne, avec seulement cette mention et l’enregistrement de l’utilisateur ayant activé le mode école.
Voulez-vous savoir comment le fiskaltrust.Middleware rend la sécurité possible pour votre système POS ? Contactez sans engagement notre responsable pour la France.
Le 3ème pilier – Conservation
Il s’agit du C de Conservation dans ISCA et il spécifie comme troisième étape le stockage des données par le système POS. Il est particulièrement important quand on en vient à envisager la suppression des données si l’espace de stockage disponible est insuffisant.
En général, toutes les données doivent être conservées pendant la période légale requise (6 ans, plus l’année fiscale en cours). Il n’y a aucun doute à ce sujet et cela n’a rien à voir avec ce règlement. Cependant, les systèmes de point de vente peuvent ne pas avoir une capacité de stockage suffisante et les données doivent donc être supprimées.
Le législateur a reconnu ce problème et aussi les signes des temps. Les données ne doivent donc pas être imprimées, mais peuvent être traitées électroniquement. Toutefois, les données concernées doivent être exportées avant la suppression et une archive doit être créée avant la suppression. Ce n’est qu’à ce moment-là que le processus de suppression peut être exécuté.
Les données stockées sur un support de stockage externe sont bien entendu également soumises aux principes ISCA, elles doivent être protégées contre toute modification et l’archivage doit être traçable.
Il n’est pas suffisant de stocker uniquement les totaux des documents, les données cumulées d’un document ou autre. Bien que cela ne soit pas précisé dans le Bulletin Officiel des Impôts (BOI-30-10-30), les articles L102B – L02E du Code des impôts (article L102b Livre des procédures fiscales) fixent les obligations et les délais de conservation pour une entreprise.
Il y a un peu plus que le stockage !
Cependant, ce pilier définit également des processus supplémentaires qu’un système d’encaissement doit permettre et stocker les données générées en fait parti. Ces données supplémentaires générées ne doivent jamais être supprimées du système et, bien entendu, elles doivent être gérées conformément aux règles ISCA.
Nous parlons ici de l’ensemble des grands totaux et des clôtures nécessaires. Les systèmes POS purs doivent offrir une clôture quotidienne, mensuelle et annuelle. Et cette fin de période doit également être effectuée par l’utilisateur du TPV. Lorsqu’une clôture est effectuée, les totaux respectifs de la période doivent être sauvegardés. En outre, le total perpétuel doit être ajouté à chaque clôture. En effet, il enregistre les ventes depuis le démarrage du système d’encaissement.
Les totaux de période ne peuvent être mis à zéro qu’à la fin de la période en question. Tous les autres totaux ne peuvent être mis à zéro que si le logiciel ou le matériel est modifié. Si le logiciel est simplement modifié (par exemple, un saut de version), les totaux ne sont pas affectés.
Il est également souligné à plusieurs reprises ici que les données doivent être stockées dans le système de point de vente ou le logiciel. Toutefois, l’exception est faite pour les systèmes gérés de manière centralisée. Ceux-ci peuvent uniquement stocker les données détaillées dans un ordinateur central/centre de données.
Voulez-vous savoir comment le fiskaltrust.Middleware facilite le stockage des données et la gestion des compteurs de vente pour votre système POS ? Contactez sans engagement notre responsable pour la France.
Le 4ème pilier – Archivage
Il s’agit du A pour Archivage dans ISCA et il définit comme quatrième étape l’archivage des données par le système POS. Tout système d’encaissement doit proposer un archivage et une archive ne doit pas contenir plus d’une année ou d’un exercice de données.
L’objectif de l’archive est de fixer le stockage de données à un moment donné. La législation fait une distinction claire entre la sauvegarde et l’archivage des données. En effet, les archives sont également soumises aux règles ISCA et doivent donc être sauvegardées et conservées sous une forme immuable. Cependant, elle peut être stockée dès le début, même en dehors du système de caisse.
Dans tous les cas, les archives ne doivent pas avoir un format propriétaire. Elles doivent être lisibles par les autorités fiscales à tout moment sans logiciel spécial. Le contenu n’ayant pas été normalisé, une explication du contenu en français doit être fournie aux autorités fiscales.
La législation ne précise également le lieu de stockage que dans la mesure où il doit être sécurisé. Cependant, là encore, les règles ISCA s’appliquent et tout indique que le stockage doit être vérifiable.
Voulez-vous savoir comment fiskaltrust assure un archivage à l’épreuve des audits pour vos clients ? Contactez sans engagement notre responsable pour la France.
La construction à partir des principes de l’ISCA
Comme nous pouvons le voir, le bâtiment repose sur une large fondation avec quatre puissants piliers. Bien entendu, cela a des conséquences sur l’auto-attestation de votre système POS ou même sur l’obtention d’un certificat.
D’une part, vous devez de toute façon enregistrer certaines données (par exemple, la version du système d’encaissement ou le prix brut et la taxe et le prix unitaire, …) dans votre système d’encaissement. En outre, vous devez enchaîner l’ensemble des données et les signer électroniquement. Et à la fin, vous devez même fournir un outil de contrôle pour les archives. Car ceux-ci doivent également être liés et sauvegardés. Sinon, quelqu’un pourrait finir par modifier le contenu des archives sans que personne ne s’en aperçoive.
Vous voyez que le bâtiment est stable, mais pas si facile à construire ! Cependant, avec fiskaltrust, vous avez un partenaire fiable et transparent à vos côtés, avec lequel vous pouvez suivre le chemin vers un système de point de vente conforme à la loi à tout moment.