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.