auneor / lf2016 Goto Github PK

Rappelons que les entreprises ou opérateurs qui conçoivent ou éditent des logiciels de comptabilité ou de gestion ou des systèmes de caisse ou interviennent techniquement sur les fonctionnalités de ces produits, affectant la tenue des écritures du livre-journal, doivent présenter à l’administration fiscale tous codes, données, traitements ou documentation qui se rattachent à ces produits (LPF art. L. 96 J).
Le logiciel ou le système doit donc prévoir un accès de l’administration fiscale à l’ensemble des données enregistrées.

1) Conditions d'Inaltérabilité

Le logiciel de comptabilité ou de gestion ou le système de caisse doit enregistrer toutes les données d’origine relatives aux règlements. Il doit conserver ces données d’origine enregistrées et les rendre inaltérables.
Si des corrections sont apportées à des opérations de règlement, que ce soit au moyen du logiciel ou système lui-même ou d’un dispositif externe au logiciel ou système, ces corrections (modifications ou annulations) s’effectuent par des opérations de « plus » et de « moins » et non par modification directe des données d’origine enregistrées. Ces opérations de correction donnent également lieu à un enregistrement.

Autrement dit, le logiciel de comptabilité ou de gestion ou le système de caisse doit prévoir que l’administration fiscale puisse accéder aux données d’origine enregistrées initialement ainsi qu’au détail daté (année, mois, jour, heure, minute) des opérations et des corrections apportées lorsque ces données ont fait l’objet de corrections.
Pour respecter la condition d’inaltérabilité, l’intégrité des données enregistrées doit être garantie dans le temps par tout procédé technique fiable.

Remarque : même un utilisateur ‘administrateur’ ne doit pas pouvoir réaliser ces opérations

2) Conditions de sécurisation des données
Le logiciel de comptabilité ou de gestion ou le système de caisse doit sécuriser les données d’origine, les données de modifications enregistrées et les données permettant la production des pièces justificatives émises.
Cette sécurisation peut être assurée par tout procédé technique fiable, c’est-à-dire de nature à garantir la restitution des données de règlement dans l’état de leur enregistrement d’origine. Il peut, notamment, s’agir d’une technique de chaînage des enregistrements ou de signature électronique des données.
L’emploi d’une fonction « école » ou « test » destinée à l’enregistrement d’opérations de règlement fictives aux fins de formation du personnel doit être sécurisé, par une identification très claire des données de règlement, des pièces justificatives (par exemple en apposant la mention « factice » ou « simulation » en trame de fond de ces documents) et de toutes les opérations enregistrées lors de l’utilisation de cette fonction, ainsi que par l’identification de l’opérateur sous la responsabilité duquel le personnel en formation enregistre les données.

3) Conditions de conservation des données

Clôture au moins annuelle du système
Le logiciel de comptabilité ou de gestion ou le système de caisse qui enregistre les données de règlement doit prévoir une clôture. Cette clôture doit intervenir à l’issue d’une période au minimum annuelle (ou par exercice lorsque l’exercice n’est pas calé sur l’année civile).
Les systèmes de caisse doivent, de plus, prévoir obligatoirement une clôture journalière et une clôture mensuelle. Pour chaque clôture - journalière, mensuelle et annuelle (ou par exercice) - des données cumulatives et récapitulatives, intègres et inaltérables, doivent être calculées par le système de caisse, comme le cumul du grand total de la période et le total perpétuel pour la période comptable (BOFiP-TVA-DECLA-30-10-30-§ 170-03/08/2016).

4) Conditions d'archivage des donnée
Garantir l’accès aux données
Le logiciel de comptabilité ou de gestion ou le système de caisse doit permettre d’archiver les données enregistrées selon une périodicité choisie, au maximum annuelle ou par exercice. La procédure d’archivage a pour objet de figer les données et de donner date certaine aux documents archivés. Elle doit prévoir un dispositif technique garantissant l’intégrité dans le temps des archives produites et leur conformité aux données initiales de règlement à partir desquelles elles sont créées. Les archives peuvent être conservées dans le système lui-même ou en dehors du système lorsqu’il existe une procédure de purge (voir § 6-11).
Les archives doivent pouvoir être lues aisément par l’administration en cas de contrôle, y compris lorsque l’entreprise a changé de logiciel ou de système.
Le logiciel ou système doit prévoir une traçabilité des opérations d’archivage, selon un procédé fiable.

Par une attestation individuelle de l’éditeur du logiciel de comptabilité ou de gestion ou du système de caisse concerné, conforme à un modèle fixé par l’administration (BOFiP-LETTRE-000242-03/08/2016).

Ou par une certification remis par un organisme tiers
on exclut du domaine d’application de la certification les logiciels servant au
support des services après-vente (rapports de maintenance, rapports de services, générationde bons d’intervention, etc.) ainsi que les logiciels de comptabilité pure ou les applications monétiques (terminaux de paiement électroniques par exemple).

En pratique, il revient à l’éditeur du logiciel de demander la certification à un organisme agréé et de remettre une copie de ce certificat à l’acquéreur ou bien de délivrer une attestation individuelle.
Mais en définitive, l’obligation de production à l’administration du certificat ou de l’attestation incombe à l’acquéreur du logiciel ou du système, qui doit donc s’assurer être en possession, à compter du 1er janvier 2018, du document justifiant du caractère conforme du logiciel qu’il détient.
Notons que le distributeur du logiciel n’est pas concerné.
Qu’il s’agisse du certificat ou de l’attestation individuelle, c’est l’éditeur du logiciel de comptabilité ou de gestion ou du système de caisse qui fait produire le document (certificat demandé par l’éditeur à un organisme certificateur accrédité). Ce n’est pas l’assujetti qui demande la certification ou qui produit ce document (attestation individuelle).
En pratique, l’éditeur remet ce document (certificat ou attestation individuelle) à l’assujetti soumis à l’obligation (voir § 6-1), lors de l’achat du logiciel ou du système. À défaut (notamment lorsque le logiciel ou système a été acquis avant l’adoption du présent dispositif), l’assujetti peut demander à l’éditeur qu’il lui remette un certificat ou une attestation individuelle pour le logiciel ou le système en cause.

Je ne sais pas comment faire

1) Résumé des obligations
https://www.service-public.fr/professionnels-entreprises/actualites/A10279

Afin de lutter contre la fraude à la TVA liée à l'utilisation de logiciels permettant la dissimulation de recettes, la loi de finances pour 2016 instaure l'obligation à partir de 2018 pour les commerçants et autres professionnels assujettis à la TVA d'enregistrer les paiements de leurs clients au moyen d'un logiciel de comptabilité ou d'un système de caisse sécurisés et certifiés.
Cette obligation permettra de rendre impossible la fraude qui consiste à reconstituer par un logiciel frauduleux des tickets de caisse pour soustraire des paiements en espèces des recettes de la comptabilité.
À partir du 1er janvier 2018, devient obligatoire l'utilisation d'un logiciel de gestion ou d'un système de caisse satisfaisant aux conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données, attestées par un certificat délivré par un organisme accrédité ou par une attestation individuelle délivrée par l'éditeur.
L'administration fiscale a par ailleurs précisé les conditions que doivent remplir les logiciels et systèmes de caisse, les moyens de justifier du respect de l'obligation et les modalités de la procédure de contrôle spécifique.
L'administration précise expressément que l'obligation concerne tous les assujettis à la TVA qui enregistrent les règlements de leurs clients dans un logiciel de comptabilité ou de gestion ou un système de caisse qu'il s'agisse de personnes physiques ou morales, de droit privé ou de droit public, et même s'ils réalisent en tout ou partie des opérations exonérées de TVA ou s'ils relèvent du régime de la franchise en base.
En cas de contrôle, l'absence d'attestation sera soumise à une amende de 7 500 € par logiciel ou système non certifié, le contrevenant devant régulariser sa situation dans les 60 jours.
Dans certains cas, les assujettis pourront se mettre en conformité avec cette nouvelle obligation grâce à une simple mise à jour de leur logiciel de caisse, dans le cadre d'un contrat de maintenance souscrit lors de l'achat du logiciel.
2) Pour en savoir plus
Article 88 de la loi n°2015-1785 du 29 décembre 2015 de finances pour 2016 
Obligation d'utiliser un logiciel de comptabilité ou de gestion ou un système de caisse satisfaisant à des conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage des données en vue du contrôle de l'administration fiscale 
http://revuefiduciaire.grouperf.com/article/3661/hb/20160919173548859.html

3) Les données concernées
Les données concernées par l’obligation d’inaltérabilité, de sécurisation, de conservation et d’archivage sont celles qui concourent directement ou indirectement à la réalisation d’une transaction (y compris lorsque la transaction n’est que simulée au moyen d’un module de type « école » ou « test ») participant à la formation des résultats comptables et fiscaux – qu’il s’agisse d’une opération de vente ou d’une prestation de services (émission d’une note, d’un ticket, d’une facture), ainsi que de toutes les données liées à la réception (immédiate ou attendue) du paiement en contrepartie.
Est également concerné l’ensemble des données permettant d’assurer la traçabilité de ces données concourant à la réalisation de la transaction et de garantir l’intégrité de celles-ci. Sur cette question, l’administration renvoie à ses commentaires sur les obligations de conservation et de présentation des documents et pièces comptables dans le cadre d’une comptabilité informatisée (BOFiP-BIC-DECLA-30-10-20-40-13/12/2013).

L’éditeur du logiciel ou du système de caisse est la personne qui détient le code source du logiciel ou du système et qui a la maîtrise de la modification des paramètres de ce produit.
Lorsque le logiciel ou le système est conçu de manière ouverte pour permettre son adaptation aux besoins spécifiques des clients, l’éditeur qui peut valablement demander la certification ou fournir l’attestation individuelle est :
-soit le concepteur d’origine du logiciel ou du système, lorsque les conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données sont respectées par le logiciel ou le système conçu à l’origine par cette personne et qu’aucun des paramètres permettant le respect de ces conditions ne peut être modifié par d’autres intervenants que ce concepteur ;
-soit le dernier intervenant ayant paramétré le logiciel ou le système, lorsque son intervention a eu pour objet ou pour effet de modifier un ou des paramètres permettant le respect des conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage des données.
Il résulte de ces précisions données par l’administration que le dernier intervenant sera donc considéré comme éditeur et, à ce titre, il pourra attester des caractéristiques du logiciel ou du système (voir § 6-17) ou s’engager dans une certification (voir § 6-15).

1) héberger les clients

Il nous semble évident que les conditions d'inaltérabilité et de sécurisation des données ne peuvent être garanties que pour une base de données hébergée chez un partenaire, qui s'assurera de respecter les critères techniques d'accès aux données et de conservation.

2) adapter Odoo v8/v9/v10/v11 communautaire
POS

• adapation de la POS BOX pour une sécurisation des données, notamment en cas de déconnexion.
• Dans un premier temps interdire la vente en cas de déconnexion

comptabilité

• permettre les clotures mensuelles dans les version >=9
• interdire la modification des factures

administration

• interdire l'accès à database management (supprimer le lien)
• interdire l'accès à l'administrateur et à la gestion des droits
• interdire l'installation ou la suppression de modules

3) mettre en place un suivi rigoureux du versionning et des modifications effectuées pour mettre à jour les attestations clients

dsdsddsdsdsds