À compter du 1er janvier 2018, les entreprises enregistrant les règlements de leurs clients au moyen d'un logiciel de comptabilité, de gestion ou d'un système de caisse, devront respecter de nouvelles obligations légales : garantir l’inaltérabilité, la conservation et l’archivage des écritures comptables. Les plateformes OpenFlyers sous version 4.2 satisfont désormais à cette nouvelle réglementation tout en offrant une nouvelle fonction pour faciliter l'annulation d'une mauvaise saisie et la génération automatique de reçus d'encaissements envoyés par email.
INALTÉRABILITÉ DES ÉCRITURES
Depuis toujours, OpenFlyers 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 le client de la structure), la structure (cliente d'OpenFlyers) et OpenFlyers. 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 OpenFlyers.
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 d'OpenFlyers 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 OpenFlyers 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.
Jusqu'à présent lorsqu'une activité (par exemple un vol) était saisie, puis validée, si une erreur était détectée à posteriori, il fallait saisir manuellement des écritures comptables correctrices et modifier le total des heures de vol de l'aéronef pour que le calcul du potentiel restant ne se trouve pas faussé.
Désormais, il suffit d'annuler le vol, via la nouvelle fonction créée à cet effet, puis de le saisir à nouveau avec les bons éléments. L'annulation du vol génère automatiquement les écritures suivantes : création d'un nouveau vol dont la durée correspond à l'opposé de la durée du vol à annuler (pour un vol à annuler qui faisait 1h20, le vol généré fera -1h20), cela permet de déduire directement ce temps de vol du total des heures de vol du carnet de vol du pilote ainsi que du carnet de route de l'aéronef. D'autre part, des écritures comptables strictement identiques aux écritures comptables initiales mais de sens opposé sont générées. Ainsi, là aussi, « l'effet comptable » de la première saisie est annulé. L'ensemble des enregistrements générés en base de données sont automatiquement validés et ne peuvent donc être annulés. Ce faisant, la traçabilité des opérations est assurée.
La documentation concernant cette nouvelle fonction est disponible ici :
https://openflyers.com/fr/doc/of4/Gestion-des-activités#Annuler-une-activité-validée