INALTÉRABILITÉ DES ÉCRITURES

Depuis toujours, ReservationAutoEcole.com refusait de modifier en base de données les écritures comptables validées. En effet, la confiance dans le logiciel est partagée entre les trois parties prenantes que sont l'utilisateur final (souvent client de la structure), la structure (cliente de ReservationAutoEcole.com) et ReservationAutoEcole.com. Tout comme on ne modifie pas une somme enregistrée sur un relevé de compte bancaire, on ne modifie pas non plus les écritures validées dans ReservationAutoEcole.com.

ARTICLE 286 DU CGI

Cependant, cette règle, qui reposait uniquement sur notre volonté, n'est pas suffisante au regard du nouvel article 286 du Code Général des Impôts qui rentre en application au 1er janvier 2018 :
https://www.legifrance.gouv.fr/affichCodeArticle.do?idArticle=LEGIARTI000034309494&cidTexte=LEGITEXT000006069577&categorieLien=id&dateTexte=20180101

au travers de l'article 88 de la loi de Finance pour 2016 :
https://www.legifrance.gouv.fr/eli/loi/2015/12/29/FCPX1519907L/jo#JORFARTI000031732968

Le nouveau paragraphe de cet article concerne les logiciels de comptabilité ou de gestion ou les systèmes de caisse. Son objectif est de lutter contre la fraude à la TVA.

La version 4.2 de ReservationAutoEcole.com est conforme à la loi. La modification essentielle est la mise en place du cryptage chaîné des écritures afin de garantir qu'il ne puisse pas y avoir de modification des données validées et enregistrées en base de données.

Si votre activité est assujettie à la TVA et que votre structure n'utilise pas une plateforme ReservationAutoEcole.com sous version 4, alors nous vous recommandons plus que fortement de demander votre migration dès janvier 2018. Pour les autres structures, il vous appartient de vérifier si vous êtes concerné par cette loi et si vous avez donc nécessité à passer rapidement sous version 4.

Les clients qui le souhaitent peuvent retrouver une attestation de conformité à compléter et à produire à l'administration fiscale en cas de contrôle. Cette attestation est disponible dans l'espace client menu Fiche contact › Attestation art. 286 du CGI.

MECANISME DU CRYPTAGE

On parle de cryptage chaîné, car le cryptage d'une écriture génère un sceau qui prend en compte le sceau de l'écriture précédente.

Visuellement, l'inaltérabilité de l'écriture est symbolisée par un cadenas qui apparaît dans la colonne Actions de la ligne concernée sur les extraits de compte. Ce cadenas apparaît uniquement lorsque le chaînage des écritures est en place.

Un test a été implémenté pour s'assurer que le sceau de l'écriture n'a pas été falsifié. Ce test repose sur la regénération d'un sceau pour l'écriture concernée en prenant en compte le sceau précédent. Si les données « sources » sont identiques, le sceau regénéré doit être identique au sceau enregistré. Si ce n'est pas le cas, alors cela veut dire qu'une des données a été modifiée : la chaîne est cassée. Dans ce cas, le symbole du cadenas apparaît grisé avec une croix rouge. Normalement, ce pictogramme ne devrait jamais être visible.

Bien évidemment, cette sanctuarisation de la base de données ne change pas l'utilisation du logiciel.

Pour que ce chaînage soit totalement garanti, il faut que le sceau du chaînage soit remis entre les mains d'un tiers de confiance. En effet, informatiquement, on pourrait toujours imaginer qu'on intervienne sur la base de données pour modifier une écriture comptable et qu'on régénère ensuite l'intégralité des sceaux de la chaîne « en aval » de cette écriture, c'est à dire de l'ensemble des écritures qui avaient été enregistrées à posteriori de l'écriture modifiée.

En diffusant à un tiers le sceau initial, on le rend public et on perd donc la possibilité de le modifier « en cachette ».

En effet, n'importe quelle personne peut ainsi comparer le sceau transmis initialement au tiers de confiance et le sceau stocké en base de données pour vérifier qu'il n'y a pas de modification.

Pour le choix du tiers de confiance, nous avons imaginé une solution originale : les utilisateurs eux-mêmes au travers de la mise en place d'une nouvelle fonction : le reçu de paiement.

REÇU DE PAIEMENT

Dans la minute qui suit la validation des encaissements, le logiciel génère automatiquement un reçu, sous la forme d'un fichier PDF, pour chaque encaissement. Ce reçu contient le sceau du chaînage sous la forme d'une suite de 56 caractères et d'un horodatage. Il est envoyé automatiquement par e-mail à la personne concernée. Il est également disponible dans les extraits de compte où il est symbolisé par un ticket.

Ainsi, en transmettant le reçu, avec le sceau, à chaque utilisateur concerné, nous transmettons bien à chaque fois à un tiers l'information et nous ne pouvons « revenir en arrière ».

L'intérêt de cette solution est double :

• pas besoin de recourir à un tiers de confiance onéreux qui serait incompatible avec nos ressources
• cela permet de mettre en place une nouvelle fonctionnalité double : la génération de reçu ET l'envoi automatique de ces reçus.

De plus, nous avons rajouté un champ dans le formulaire de saisie des encaissements qui permet de saisir l'adresse e-mail d'un client extérieur dans le cas où la personne qui effectue le paiement n'est pas enregistrée dans la base de données en tant qu'utilisateur. Cela permettra aux structures de transmettre automatiquement et simplement un reçu d'encaissement à leurs clients extérieurs.

La documentation faisant référence à cette sanctuarisation est disponible ici :

https://openflyers.com/fr/doc/of4/Comptabilité#Inaltérabilité-des-données

CORRECTION DES ERREURS DE SAISIE DES ACTIVITÉS

Pour marquer cette sanctuarisation, nous avons souhaité l'accompagner d'une 2ème nouvelle fonctionnalité qui a vocation à simplifier la correction des erreurs de saisie des activités.

La documentation concernant cette nouvelle fonction est disponible ici :

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