INALTERABILITY OF ACCOUNTING ENTRIES

ReservationAutoEcole.com has always refused to modify the validated accounting entries in the database. Indeed, the trust in the software is shared between the three stakeholders that are the end user (often client of the structure), the structure (ReservationAutoEcole.com customer) and ReservationAutoEcole.com. Just as you do not modify an amount recorded on a bank account statement, you do not change the entries validated in ReservationAutoEcole.com.

ARTICLE 286 OF THE CGI

However, this rule, which rested solely on our will, is not sufficient in light of the new article 286 of the French General Tax Code which comes into effect on January 1, 2018:
https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI000034309494&cidTexte=LEGITEXT000006069577&categorieLien=id&dateTexte=20180101

through article 88 of the Finance Act for 2016:
https://www.legifrance.gouv.fr/eli/loi/2015/12/29/FCPX1519907L/jo#JORFARTI000031732968

The new paragraph in this article is about accounting or management software or cash systems. Its objective is to fight against VAT fraud.

Version 4.2 of ReservationAutoEcole.com complies with the law. The essential modification is the implementation of the encryption of the writes in order to guarantee that there can be no modification of the data validated and recorded in the database.

If your activity is subject to VAT and your organization does not use an ReservationAutoEcole.com platform under version 4, then we strongly recommend that you request your migration in January 2018. For other structures, it is up to you to check if you are concerned by this law and if you therefore need to pass quickly under version 4.

Customers who wish can find a certificate of conformity to complete and produce to the tax authorities in case of control. This certificate is available in the customer area menu Contact file › Certification art. 286 of the CGI.

MECHANISM OF ENCRYPTION

We are talking about chained encryption, because the encryption of a writing generates a seal that takes into account the seal of the previous writing.

Visually, the inalterability of the writing is symbolized by a padlock that appears in the Actions column of the line concerned on the statements of account. This padlock only appears when the scripting chain is in place.

A test was implemented to ensure that the seal of the writing was not falsified. This test is based on the regeneration of a seal for the writing concerned taking into account the previous seal. If the "source" data is identical, the regenerated seal must be identical to the registered seal. If this is not the case, then this means that one of the data has been modified: the string is broken. In this case, the padlock symbol appears grayed out with a red cross. Normally this pictogram should never be visible.

Of course, this sanctuarization of the database does not change the use of the software.

For this chaining to be fully guaranteed, it is necessary that the seal of chaining is put in the hands of a trusted third party. In fact, one could always imagine using the database to modify an accounting entry and then regenerate all the seals in the "downstream" chain of this entry, ie of the set of writings which had been recorded a posteriori of the modified writing.

By distributing the initial seal to a third party, it is made public and thus the possibility of modifying it "in secret" is lost.

Indeed, any person can compare the seal initially transmitted to the trusted third party and the seal stored in the database to verify that there is no change.

For the choice of trusted third party, we imagined an original solution: the users themselves through the implementation of a new function: the payment receipt.

PAYMENT RECEIPT

Within one minute of receipt validation, the software automatically generates a receipt, in the form of a PDF file, for each incoming payment. This receipt contains the chain seal as a 56-character sequence and a timestamp. It is sent automatically by e-mail to the person concerned. It is also available in account statements where it is symbolized by a ticket.

Thus, by transmitting the receipt, with the seal, to each user concerned, we transmit each time to a third party the information and we can not "go back".

The interest of this solution is twofold:

• no need to resort to an expensive trusted third party that would be incompatible with our resources
• this makes it possible to set up a new double functionality: the receipt generation AND the automatic sending of these receipts.

In addition, we have added a field in the form for entering receipts that allows us to enter the e-mail address of an external customer if the person making the payment is not registered in the database. as a user. This will allow the structures to automatically and simply send a receipt of receipt to their external customers.

The documentation referring to this sanctuarization is available here:
https://openflyers.com/fr/doc/of4/Comptabilité#Inaltérabilité-des-données

CORRECTION OF SEIZURE ERRORS OF ACTIVITIES

To mark this sanctuarization, we wanted to accompany it with a second new feature that aims to simplify the correction of errors in the seizure of activities.

The documentation concerning this new function is available here:

https://openflyers.com/fr/doc/of4/Gestion-des-activités#Annuler-une-activité-validée