{"id":3160,"date":"2022-01-13T23:37:00","date_gmt":"2022-01-13T22:37:00","guid":{"rendered":"https:\/\/fiskaltrust.eu\/news\/\/"},"modified":"2025-05-02T01:52:19","modified_gmt":"2025-05-02T00:52:19","slug":"are-cash-register-certification-and-agile-development-mutually-exclusive-in-france","status":"publish","type":"news","link":"https:\/\/web-staging.fiskaltrust.eu\/news\/are-cash-register-certification-and-agile-development-mutually-exclusive-in-france\/","title":{"rendered":"Are cash register certification and agile development mutually exclusive in France?"},"content":{"rendered":"\n

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.<\/p>\n\n\n\n

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\u2019s own POS system or cash register.<\/p>\n\n\n\n

The \u201cFiscal Scope\u201d<\/h2>\n\n\n\n

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.<\/p>\n\n\n\n

Major version and Minor version<\/h2>\n\n\n\n

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 \u201cbreaking changes\u201d 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.<\/p>\n\n\n\n

Now, however, the two certification authorities have introduced their own versioning: As soon as something in the \u201cFiscal Scope\u201d is changed, the major version must be incremented.<\/p>\n\n\n\n

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 \u201cHappyPos > 1.4\u201d 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.<\/p>\n\n\n\n

Architecture of the software<\/h2>\n\n\n\n

We will see, everything depends on the internal architecture to decide whether they need to apply a complete \u201ccode freeze\u201d or only a part of the POS system must be protected from changes.<\/p>\n\n\n\n

If you haven\u2019t 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.<\/p>\n\n\n\n

Another solution would be better!<\/strong><\/p>\n\n\n\n

With the integration of fiskaltrust.Middleware you get \u201cCompliance-as-a-Service\u201d 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.<\/p>\n\n\n\n

Now you just need to summarize the fiscalization. Let\u2019s look at a diagram of the modules of a fictitious POS system.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

We immediately see the fiskaltrust.Middleware forms an independent block of POS system \u201cHappyPos\u201d and within the POS itself, there is a module \u201cFiscalization\u201d. 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 \u201cFiscal Scope\u201d is very clearly defined and does not spread over the whole system.<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

The savior is the fiscalization module<\/h2>\n\n\n\n

Now let\u2019s look at this module in detail:<\/p>\n\n\n\n

\"\"<\/figure>\n\n\n\n

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.<\/p>\n\n\n\n

The perfect solution<\/h2>\n\n\n\n

We don\u2019t 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.<\/p>\n\n\n\n

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:<\/p>\n\n\n\n