INALTERABILITY OF ACCOUNTING ENTRIES

OpenFlyers 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 (customer OpenFlyers) and OpenFlyers. Just as you do not modify an amount recorded on a bank account statement, you do not change the entries validated in OpenFlyers.

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 OpenFlyers 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 OpenFlyers 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.

Until now when an activity (for example a flight) was entered and validated, if an error was detected a posteriori, it was necessary manually to enter corrective accounting entries and modify the total hours of flight of the aircraft so that the calculation of the remaining potential is not distorted.

From now on, it is enough to cancel the flight, via the new function created for this purpose, then to enter it again with the good elements. The cancellation of the flight automatically generates the following entries: creation of a new flight whose duration corresponds to the opposite of the duration of the flight to be canceled (for a flight to be canceled which was 1h20, the generated flight will be -1h20), this makes it possible to directly deduce this flight time from the total flight hours of the pilot's logbook and the aircraft's journey log. On the other hand, accounting entries that are strictly identical to the initial but opposite accounting entries are generated. Thus, here again, the "accounting effect" of the first entry is canceled. All records generated in the database are automatically validated and can not be canceled. In doing so, the traceability of operations is ensured.

The documentation concerning this new function is available here:

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