In France, cash registers and POS systems must prove compliance with the law. For this purpose, a certification can be requested from one of the two organizations, LNE or Infocert. Or the cash register manufacturer can issue an individual confirmation to each cash register user.
But as soon as the source code of the fiscalization part of the cash register is changed, the certification or confirmation is annuled. Thism therefore, makes it difficult to further develop one’s own POS system or cash register.
The “Fiscal Scope”
In French POS system security, this part of the POS system is of central importance. It is the part that manages the fiscal scope. And it is precisely this scope that prevents the further development, the adaptation of the software.
Major version and Minor version
We all know there are different ways of versioning a software. And all variants have one thing in common: a main version and sub-versions. If we make major changes or “breaking changes” to an application, the major version number usually changes, for example from 1.0 to 2.0. Also, the minor version is usually reset, i.e. from 1.14 to 2.0. If there are only minor changes, patches and bug fixes, the minor version is incremented, as in the case of 1.14 to 1.15.
Now, however, the two certification authorities have introduced their own versioning: As soon as something in the “Fiscal Scope” is changed, the major version must be incremented.
This is because the certificate issued is tied to the name of the software and also to the major version. It is therefore only valid for those applications and versions that are listed on the certificate. For example, if “HappyPos > 1.4” is certified, versions 1.40, 1.41, 1.5 and so on may be used. However, a new certification must be performed for version 2.0.
Architecture of the software
We will see, everything depends on the internal architecture to decide whether they need to apply a complete “code freeze” or only a part of the POS system must be protected from changes.
If you haven’t just started developing a new POS system, then fiscalization will be distributed throughout the source code. And this is where the problem starts. Because for every file that contains part of the fiscalization code, a hash code is determined at the end of the audit and thus protected from changes. Most of the time this hits every file.
Another solution would be better!
With the integration of fiskaltrust.Middleware you get “Compliance-as-a-Service” and are mostly exempt from having to manage the rules for cash register security. This part is certified separately and is not a direct part of the POS.
Now you just need to summarize the fiscalization. Let’s look at a diagram of the modules of a fictitious POS system.
We immediately see the fiskaltrust.Middleware forms an independent block of POS system “HappyPos” and within the POS itself, there is a module “Fiscalization”. So to say, it is the ideal state to impose as few restrictions as possible on the developers. Because as we can see in the following picture, the “Fiscal Scope” is very clearly defined and does not spread over the whole system.
The savior is the fiscalization module
Now let’s look at this module in detail:
As we can see clearly, the data collected by the POS system (1) is transferred to the module via an interface. In the module, the data is prepared for the fiskaltrust.Middleware, the calculation and further steps are performed and the data set is then transferred to the fiskaltrust.CashBox (2). The middleware now saves, stores, fiscalizes the data and passes it back to the fiscal module. With an interface to the POS, the fiscalized receipt is transferred back to the POS system at the end.
The perfect solution
We don’t know, but something that comes very close. The simplest solution is to combine all the code within one module in the POS system. This can be either a file with all methods or for example a class which handles all fiscalization.
But even better would be to create a separate project, which for example creates its own dll file. This would kill several birds with one stone:
- All the code for fiscalization is outside the POS system.
- The dll file (the project) can be exchanged depending on the country and thus the POS system becomes internationally applicable.
- The project gets its own logic in versioning, for example “HappyPos Fiscal 1.1 FR”.
- Only the project is saved with a hash value.
The fiscal module will be submitted for certification and the POS system can be further developed at any time.
Summary
As you can see certification is not a nightmare! With a little planning in advance, agile software development, a SaaS and certification are not mutually exclusive. Especially the fiskaltrust.middleware facilitates the start here and expands the possibilities. Without additional costs “Compliance-as-a-Service” and an integration support are only a small part of the added value for your POS system.
We look forward to discussing with you the solutions that fiskaltrust offers to help your business.
We are Simplifying Complexity: Contact usCertification de caisse en France et développement agile s’excluent-ils ?
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.d an integration support are only a small part of the added value for your POS system.
Contactez l’un de nos experts dès aujourd’hui !
We are Simplifying Complexity: Contactez-nous