En France, les caisses enregistreuses, les systèmes PDV doivent prouver qu’ils respectent la législation. Pour cela, il est possible de demander une certification à l’un des deux organismes accrédités (LNE ou Infocert), ou une attestation individuelle délivrer par  le fabricant de la caisse à chacun de ses utilisateurs.

Mais dès que le code source de la fiscalisation est modifié, la certification ou l’attestation devient caduque. Il devient alors difficile de faire évoluer son propre système PDV ou sa propre caisse enregistreuse.

Le cadre fiscal « Fiscal Scope »

Dans le cadre de la sécurité des caisses françaises, cette partie du système POS est d’une importance capitale. On peut aussi la désigner comme la partie qui s’occupe de la fiscalisation. Et c’est précisément ce domaine qui empêche l’évolution ou l’adaptation du logiciel.

Version majeur et mineur

Nous connaissons tous les différentes possibilités de versionner un logiciel. Et toutes les variantes ont un point commun : une version principale et des sous-versions. Lorsque nous apportons des modifications importantes ou même des « breaking changes » à une application, le numéro de la version principale est généralement modifié, par exemple de 1.0 à 2.0. La sous-version est également réinitialisée, c’est-à-dire de 1.14 à 2.0. S’il ne s’agit que de modifications mineures, de patches et de corrections de bugs, la sous-version est incrémentée, comme dans le cas de 1.14 à 1.15.

Les deux autorités de certification ont toutefois introduit leur propre système de versionnage : Dès que quelque chose est modifié dans le domaine du cadre fiscal « Fiscal Scope », la version principale doit être incrémentée.

En effet, le certificat délivré est lié au nom du logiciel et à la version principale. Il n’est donc valable que pour les applications et les versions mentionnées sur le certificat. Par exemple, si « HappyPos > 1.4 » est certifié, les versions 1.40, 1.41, 1.5 et ainsi de suite peuvent être utilisées. Toutefois, pour la version 2.0, une nouvelle certification doit être effectuée.

Architecture du logiciel

Nous allons voir que tout dépend de l’architecte interne, s’il doit appliquer un « gel de code » complet ou si une seule partie du système POS doit être protégée des modifications.

Si vous ne venez pas de commencer le développement d’un nouveau système POS, la fiscalisation sera répartie dans tout le code source. Et c’est là que commence le problème. Car pour chaque fichier contenant du code de fiscalisation, un code de hachage est déterminé à la fin de l’audit et est ainsi protégé contre les modifications. La plupart du temps, cela concerne chaque fichier.

Une autre solution serait préférable !

En intégrant le middleware fiskaltrust, vous bénéficiez de la « compliance-as-a-service » et êtes en grande partie exempté des règles de sécurité de la caisse. Cette partie est certifiée à part et ne fait pas directement partie du POS.

Il ne vous reste plus qu’à regrouper la fiscalisation. Regardons un diagramme des modules d’un système POS fictif.

Nous voyons tout de suite que le fiskaltrust.middleware constitue un bloc indépendant du système POS « HappyPos » et qu’au sein du POS lui-même, il y a un module « Fiscalization ». C’est en quelque sorte la situation idéale pour imposer le moins de contraintes possibles aux développeurs. En effet, comme nous pouvons le voir sur l’image suivante, le cadre fiscal « Fiscal Scope » est très clairement défini et ne se répartit pas sur l’ensemble du système.

Le sauveur est le module de fiscalisation

Regardons maintenant ce module en détail :

Comme nous le voyons clairement, les données saisies par le système POS (1) sont transmises au module via une interface. Dans le module, les données sont préparées pour le fiskaltrust.Middleware, le calcul et d’autres étapes sont effectués et l’ensemble des données est ensuite transmis à la CashBox fiskaltrust (2). Le middleware sauvegarde, enregistre et fiscalise maintenant les données et les transmet à nouveau au module fiscal. Grâce à une interface avec le point de vente, le justificatif entièrement fiscalisé est à nouveau transmis au système POS.

La solution parfaite

Nous ne connaissons pas la solution parfaite, mais quelque chose qui s’en rapproche. La solution la plus simple consiste à regrouper tout le code au sein d’un module dans le système POS. Il peut s’agir d’un fichier contenant toutes les méthodes ou, par exemple, d’une classe qui prend en charge toute la fiscalisation.

Mais il serait encore mieux de créer un projet propre, qui génère par exemple son propre fichier dll. Vous feriez ainsi d’une pierre plusieurs coups :

L’ensemble du code de fiscalisation se trouve en dehors du système POS.

  • Le fichier dll (le projet) peut être échangé en fonction du pays, ce qui rend le système POS utilisable au niveau international.
  • Le projet reçoit sa propre logique lors du versionnage, par exemple « HappyPos Fiscal 1.1 FR ».
  • Seul le projet est sauvegardé avec une valeur de hachage.
  • Le module de fiscalisation est soumis à certification et le système POS peut être développé à tout moment.

Résumé

Vous voyez que la certification n’est pas si terrifiante ! Avec un peu de planification préalable, le développement agile de logiciels, un SaaS et une certification ne s’excluent pas mutuellement. Le fiskaltrust.Middleware, en particulier, facilite le démarrage et élargit les possibilités. Sans frais supplémentaires « Compliance-as-a-Service » et une assistance à l’intégration ne sont qu’une petite partie de la valeur ajoutée pour votre système POS.

Contactez l’un de nos experts dès aujourd’hui !