Loi finance - article 88 et Hikashop

Bonjour,

@jms2win : merci pour votre travail

@Nicolas : Merci pour ces précisions.
N'hésitez pas si je peux vous aider en quoi que ce soit pour avancer sur la conformité d'hikashop

Bonne journée
Sandrine

Bonjour

@sandrine: Un review de la solution mise en oeuvre est toujours le bien venu.
Pour cela, je vous propose de vous enregistrer sur hikainvoices.com ou simplement utiliser sa page de contact pour m'envoyer un message avec vos infos de contact.

Pour info, la solution MySQL en cours de test de faisabilité serait aussi applicable au core de HikaShop et ses tables order, order_product sans nécessiter de modification du code php (ou très mineure).
J'espère pouvoir vous donner un premier résultat de ces tests très bientot.

Bonne journée
Edwin

Bonne nouvelle.

Le test de faisabilité est concluant et permet de garantir l'intégrité et archivage automatique des données sans modification du code PHP utilisé pour les traitements.

Dans hikainvoices, nous avons simplement ajouté un helper qui est appelé à l'installation ou durant la vérification de la structure de la base de données.

Ce helper a pour but d'ajouter nativement à MySQL les instructions pour garantir l'intégrité des données et procéder automatiquement à l'archivage de toutes les modifications apportées dans certaines tables MySQL.

Dans le cas particulier d'HikaInvoices, il y a une copie des informations venant de HikaShop concernant la commande avec une sauvegarde à chaque modification nécessitant une MAJ d'un document (par example borderau de commande, bordereau de livraison, recu de paiement, facture, note de crédit dans le cas des remboursements, ...).

Toutes les modiciations, suppressions sont conservées dans une table parallèle avec les données d'origine.
La table "history" attachée à chaque table à surveiller a la meme structure que la table "original" pour lequel une conformité est nécessaire avec 3 champs supplémentaires qui donne le type d'action qui a nécessité l'archivage, le premier nom du champs qui l'a justifié ainsi que la date d'archivage.
Les actions sont
I = Insert
U = Update
D = Delete
C = Copy. La copie est parfois nécessaire pour garantir l'intégrité d'un tout (C'est principalement utilisé pour les lignes articles lorsque le document principal est modifié).

Pour le lien et la tracabilité, il faut simplement ajouter 3 champs dans les tables "original" nécessitant une mise en conformité.
- <le nom du champ auto increment>_history (suffix "_history")
- revision qui contient le numéro de la version du record. A chaque modification, le numéro est automatiquement incrémenté.
- periodclosed_id qui donne la référence vers la période cloturée.

Aucune modification n'a été nécessaire dans les traitements et l'archivage est automatique et transparent.
En outre, toute tentative de modification meme via PHPMyAdmin ou la console en mode MySQL sont également tracées et archivées.

Donc l'intégrité des données et la tracabilité est assurée.
Au niveau performance, la table principale n'est pas impactée en terme de nombre d'enregistrements.
C'est juste les tables "xxx_history" qui vont devenir très volumineuse.

Dans un premier temps, nous ne prévoyons pas de purge des tables historiques pour réduire leurs tailles puiqu'il faut conserver les données pendant au moins 6 ans.
Actuellement, notre solution interdit la modification et la suppression des données archivées.
Seul les ajouts (insert) sont autorisés dans les "history".
Donc cela laisse du temps pour implémenter un nettoyage qui actuellement est interdit.

Au niveau de HikaInvoices, il y a déjà une système qui est très proche de la cloture périodique.
C'est notre "export MOSS" qui permet de définir des périodes "de à".
A chaque export pour la période définie, une sauvegarde au format "Standard Audit Format" européen est conservé dans la BD pour la déclaration TVA ainsi que les totaux de la période.
Actuellement cet archivage est limité au facture nécessitant une déclaration MOSS mais nous allons modifier notre code pour permettre l'archivage de la totalité des factures.
La suppression de ces rapports est déjà impossible dans HikaInvoices. Donc cette tracabilité est déjà présente.
Nous devons simplement ajouter les totaux perpétuels pour etre conforme.

La technique utilisée pour garantir l'intégrité des données pourrait être étendu aux tables order et order_product de hikashop avec toutefois une difficulté supplémentaires à traiter qui concerne les champs personalisable (custom fields).
En effet, les "customs fields" peuvent modifier dynamiquement la structure de table order ce qui pose un problème de refresh automatique de la structure de la table "history" utilisée pour l'archivage et du test des champs modifiés.
La structure de la table "history" DOIT avoir exactement les mêmes champs et exactement dans le meme ordre pour que la requete INSERT INTO xxx SELECT * FROM yyyy WHERE id=zzz fonctionne.
En outre la détection des champs modifiés ne peut pas être calculé dynamiquement et doit être fait au moment ou le script MySQL qui contient les règles d'intégrité est installé.
MySQL doit compiler le code.

Actuellement, nous n'avons pas trouvé au niveau MySQL de solution pour intercepter des modifications de structure d'une table qui permettrait d'imaginer une solution automatique et transparente.
Donc uniquement pour ces "custom fields", une légère modification de hikashop devrait peut être nécessaire pour forcer la MAJ du script d'intégrité.

Maintenant que ce test de faisabilité est concluant, nous allons continuer l'implémentation au niveau HikaInvoices pour pouvoir fournir une solution qui safisfairait aux contraintes francaises en matière de conformité.

Bonjour JMS2WIN


Deux choses si je peux me permettre :

Concernant la base history, le bofip indique :

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.

Avec eux peut c est souvent doit, donc ajouterai tu 2 champs ( chainage ou empreinte et verification d empreinte) ?

Pour la purge si, seul les logiciels de caisse ne puevent purger la totalité, sur les autres tu peux en annuel à condition que les sauvegardes soient effectuées sur un support externe sécurisé :

Au-delà de la périodicité choisie et au maximum annuelle ou par exercice, le logiciel ou le système peut prévoir une procédure de purge des données de règlement. Avant la mise en œuvre de cette procédure de purge, le logiciel ou le système doit garantir la production d'une archive complète des données de règlement (données d'origine et éventuelles modifications), avec la date de l'opération de règlement (année – mois – jour), sur un support physique externe sécurisé.

Une chose cependant, c'est l'accès aux infos par les services du gouv.

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

@selige,

Tout feedback est le bien venu.

1) La solution contient un chainage des enregistrements avec le champs "<auto increment>_history" qui doit etre ajouté à la table "originale" et qui permet de retrouver toutes les modifications pour arriver à l'enregistrement d'origine.
Il n'y a pas de signature de l'enregistrement archivé. C'est une copie non modifiable ni supprimable.

2) Pour le purge, il n'y en a pas.
L'achivage est dans la BD elle meme.
S'il faut faire un backup de la BD pour un archivage externe, j'ai déjà un shell script sur mon site
www.jms2win.com/en/component/docman/doc_...ackup-script-all-dbs
qui est capable de crypter les backups avec une clé AES que l'on peut personnaliser.
J'ai mis en place cette solution il y a plusieurs années pour permettre d'archiver les données sur des serveurs externes qui ne se trouvent pas dans la société et pour éviter que les hébergeurs ne puissent exploiter ces données.

Ce genre de backup externe présente un très gros problème que j'ai déjà rencontré.
C'est celui qui concerne le transfert du fichier qui peut être corrompu par FTP ou autre.
Si certain bits ou bytes sont mauvais alors le décryptage du backup pour sa restauration échoue et rend le backup inutililsable.
Donc garantir que le backup déposé sur un serveur distant et qu'il n'est pas corrompu n'est pas nécessaire facile à réaliser.

C'est pour cela que pour le moment, je n'ai pas prévu des suppressions puisqu'il y a un "PEUT" et pas doit purger.

3) Pour l'accès aux données historique, actuellement je n'ai rien prévu si ce n'est d'utiliser éventuellement un PHPMyAdmin pour faire un export des tables archive vers un format CSV ou similaire.
Toutefois, je ne suis pas sur que Excel ou équivalent serait capable de lire des fichiers volumeux.
Je vais regarder s'il serait facile de pouvoir utiliser la même interface qu'actuellement pour accéder aux tables "xxx_history" plutot que la table originale.
En d'autre terme, visualiser les documents comme si c'était l'original.


4) Pour info, je continue à chercher une solution pour automatiquement détecter les modifications de structure des tables et pour automatiquement recompiler le code MySQL.
Dans l'état actuel de mes tests, toute modification sur une table dont la structure a été modifié sont rejeté.
Seul les inserts fonctionnent.
Avec ma solution actuelle, il faut retourner dans le menu système / configuration => Check database pour lancer la MAJ du code MySQL.

Oui nicolas.
GO pour le call de trigger pour les customs fields.
Comme cela, je pourrai ajouter le traitement dans le plugin d'intégration existant dans HikaInvoices et le tout serait transparent.

Pour info, je prévois d'ajouter des controles d'intégrité et d'inaltérabilité en MySQL natif aux tables order, order_product et history.
L'idée est que l'inaltérabilité ne commence qu'à partir du moment ou le paiement a été effectué.
En d'autre terme, tant que la commande est créée mais pas payée, on pourra toujours la modifier, changer les quantités, ....
Dès que le paiement sera effectué (en d'autre terme que le status passera a shipping ou confirmed) alors la révision démarera à 1 et par la suite toutes les modifications seront enregistrées.
Ceci a pour but de réduire la taille de l'archivage à chaque update d'une commande (ne serait-ce que pour changer son status ou imprimer une facture ou toute autre modif).

Dans mon prototype, j'ai déjà supprimée la possiblité du delete dans ces tables.

Comme dans JMS, j'ai la fonction maintenance qui est capable de comparer des structures de tables, je vais regarder à ajouter cette fonctionalité pour comparer les tables originales avec "history" afin de s'assurer que les structures sont compatibles.

Comme dans HikaInvoices, il y a déjà un export "document" qui est capable d'exporter les données pour les injecter dans un logiciel comptable ou autre,
je vais ajouter la possibilité d'exporter les données venant des archives.
Comme cela, les controleurs pourront avoir accès au données de manière simplifiés.

J'étudie aussi la possiblité de numéroter les tables "history" pour les renomer à la cloture de chaque période.
De cette manière, on pourrait envisager de faire le drop des tables "xxx_history_YYYYMM" après 6 ans ou plus.
Cela règlerait le problème du "purge" qui est interdit dans ces tables.

Bonjour

L'idée est que l'inaltérabilité ne commence qu'à partir du moment ou le paiement a été effectué.

Dans le document
www.economie.gouv.fr/files/files/directi...iciels_de_caisse.pdf
Point 22:

Les données de l'opération doivent être inaltérables de la prise de commande jusqu'à l'enregistrement du règlement.

Je comprends que l'inalterabilité démarre a partir du moment ou le client a accepté la commande, et consentit à la payer.

"Standard Audit Format"

@edwin, qu'entends tu par ce "Standard Audit Format" ?

En fait les mesures prisent par l'état français impacte tous les pays dans le monde qui vendent des services électronique à des citoyens français puisque dans ce cas, c'est la législation du pays du client qui s'applique.
La seule chose qui reste à voir dans ce cas, c'est comment l'état français pourrait mener les controles dans les autres pays pour faire respecter leur législation.

@Edwin: je ne suis pas sur de ce point la.

Bonjour,

Je suis assez d accord avec Valérie.
Même plus que les commandes puisque c est tous les éléménts concourrant à la facture, donc perso je comprends client, commande, produit....

@Valérie la norme SAF-T c est un moyen de produire des déclarations de revenus par voie électronique, mais pour certains pays, pas la France, nous on aura orchus.

Quid pour Nicolas.
Qui sera responsable aux yeux du gouv en cas de problème sur le plugin ou code ?

@alatak. Si j'ai bien identifié, c'est toi qui t'occupe de VirtueMart.
Pour ton info, HikaInvoices a été concu pour aussi fonctionner avec VirtueMart et donc la solution en cours pour la mise en conformité pourrait être étendue à VirtueMart puisque mon code est générique.
La seule chose est que pour faire fonctionner HikaInvoices, il faut au moins installer une version de HikaShop free pour disposer du framework d'HikaShop utilisé par HikaInvoices et pour être toujours compatible avec J1.5, 2.5 et 3.x

@jerome Merci pour l'info mais cela ne semble plus nécessaire.
Ceci dit, s'il faut enregistrer tout les modifications de la commande et pas uniquement à partir du paiement, c'est plus simple à faire mais va être gros consommateur de ressource dans l'historique puisque toute update sera enregistré.

Concernant HikaInvoices, il conserve au moment de l'enregistrement du document une copie des infos clients.
Donc si elles sont modifies ultérieurements, la copie reste dans HikaInvoices.


Le standard audit format est celui définit par l'europe.
Le liens que j'avais en 2014 n'est plus valide.
Je vous met le zip

@selige concernant la certification et les responsabilités, il semble que tout le code ne doit pas être certifié mais simplement la partie qui garanti l'inalterabilité et concours à remplir les obligations. Il n'y a pas d'obligation de moyen mais de résultat quelque soit la méthode employée.
J'essaye de faire en sorte que la solution soit le plus "externe" possible du code PHP de telle manière a réduire autant que faire ce peut le couplage avec les extensions.
Si maintenant on opte pour la solution qui consiste à ajouter un code NACE pour ne pas devoir payer une certification de 11K euro tous les ans, alors la responsabilité sera celle du propriétaire du site internet.
Si par contre, on trouve le financement qui permet d'obtenir la certification alors c'est le "papier" de certification qui fera fois et fournit pas la société qui aura obtenu la certification. Si par contre, le client modifie le code, cela sera de sa responsabilité.

Pour info générale aux différents lecteurs.
J'ai contribué à établir la norme francaise en matière de dématérialisation des factures entre 1999 et 2000.
J'ai d'ailleurs participé à Bercy pour donner mon avis sur l'article de loi chargé de la dématérialisation des factures.
Grâce à cette connaissance acquise et à l'établisement de la norme EANCOM et Gencod en france, quand l'europe est venue en 2014 avec la législation sur les déclarations MOSS et la mise au norme des factures, j'ai décidé de créer HikaInvoices pour remplir ces obligations et éviter d'éventuelles amendes.
C'est pour cela que HikaInvoices est très proche d'être conforme aux nouvelles obligations et contient déjà des mécanismes de controle des factures pour verifier que les factures établies respectent la législation (du moins européenne et définie dans le MOSS)
Donc je crois que HikaInvoices pourrait répondre au nouveau problème légal en france.

Attention, il ne faut pas se méprendre sur ce que je vais écrire, simplement la loi explique une chose, mais il faut prendre tous les liens qui s'y rapportent

Voici deux choses à lire

En premier la documentation et l obligation de communication.
Documentation

Perso, je ne l ai pas encore finalisée pour mon logiciel, ma priorité à été le codage.

et ceci, : l attestation
bofip.impots.gouv.fr/bofip/10692-PGP.htm...TTRE-000242-20160803

A vous de bien lire QUI doit faire l attestation, ce qui QUI doit être

@selge, Merci pour les infos et les liens.

Bonjour,

Dans le cas d’un indépendant ou d’une agence qui réalise des sites E-commerce pour des clients, voici ce que j’ai pu retenir.


Il me semble que la certification doit être demandée par l’éditeur du logiciel et qu’elle garantit les conditions d’inaltérabilité, de sécurisation, de conservation et d’archivage du CMS telle que définie par l’administration
« Il appartient à l'éditeur de demander la certification du logiciel ou système à un organisme accrédité…. ; »
paragraphe 320 et suivants : bofip.impots.gouv.fr/bofip/10691-PGP

Par exemple, la certification Prestashop se ferra par l’ajout d’un module « Certification NF525 – Conformité à la loi sur la fraude à la TVA ».
Si le prestataire (indépendant, agence…) qui réalise un site Internet pour un client (pour prendre cet exemple) ne modifie pas les parties relatives à la comptabilité et à l’encaissement, alors le module sera toujours « actif » dans l’admin et le prestataire n’aura pas besoin de fournir une attestation au client final. En revanche, si ces parties du code sont modifiées et que le module désactivé dans l’admin, alors la responsabilité de Prestashop est levée.



Dans le cas d’une Attestation individuelle de l'éditeur du logiciel (cas d’Hikashop) :
-comme le disait @Alatak : « on peut opter pour une attestation individuelle, individuelle veut dire que tu la délivres pour un client précis (indépendant, agence…) et qu'elle doit être cosignée par ce client qui s'engage du coup à ne pas altérer les dispositifs techniques garantissant sécurisation, inaltérabilité, conservation et archivage. »
-comme le disait @Nicolas : « D'après ce que j'avais lu (je ne sais plus où), tant que vous ne touchez pas aux fonctions de caisse/facturation l'attestation de l'éditeur suffit, d'autant vous l'avez signé en stipulant ne pas "altérer les dispositifs techniques garantissant sécurisation, inaltérabilité, conservation et archivage."
Restera à préciser quels programmes ne pas toucher afin de conserver la validité de l’attestation tout en réalisant un site conforme aux besoins du client.

Sandrine

Bonjour à tous

@nicolas, j'ai peut être trouvé un algorithme qui évite de devoir écrire un plugin pour synchroniser les structures des tables (Originale avec History).
Donc pour le moment, je n'aurais pas besoin d'écrire cela en PHP mais serait détecté à la volé au niveau MySQL.

La solution d'inaltérabilité en cours serait applicable à n'importe qu'elle extension (Hikashop, VirtueMart, CB Subs, ....).
Si mon idée fonctionne, elle permettrait aussi d'archiver les modifications de structure des tables qui doivent être auditée.

Je vous tiens au courant rapidement si l'algorithme fonctionne en MySQL.
Il pemettrait aussi de prendre en compte le purge future.

@sandrine, le liens bofip est intéressant parce qu'il offre peut être une autre solution pour la mise en conformité.
Il faudrait étudier la possibilité de procéder à une mise en conformité avec un autre état membre de l'union européenne et regarder si le cout est inférieur à celui de la france.

@nicolas, Malgré le fait que j'avais parfaitement pu détecter les changements de structure à la volée, malheureusement des contraintes MySQL empêchent d'exécuter des requetes SQL dynamique.
Donc on est obligé d'appliquer les changements de structure a partir d'un plugin PHP qui recompilera le code MySQL à la volée.

J'ai essayé de contourner cette restriction MySQL mais sans succès.
Voir le code d'erreur MySQL 1336;

Merci Nicolas.

Pour info, l'installation de la fonctionalité qui garantira l'inaltérabilité des données est totalement indépendant du CMS et n'a pas besoin de joomla pour s'installer.
Cela veut dire pour les agences web, que par example on on pourrait aussi l'utiliser pour des plugins wordpress ou autre.

Je prévois la définition des tables pour Hikashop, VirtueMart, CBSubs, JomRes, Sobipro.
Je verrai avec Nicolas pour les autres Hikamarket, Hikasubmission, .... ce qu'il y a lieu de définir.

A part le problème de mofiication de structure de tables qui nécessite un appel venant de l'extérieur, actuellement le code en cours de developement est 100% MySQL natif.
Il n'y a que le programme d'installation qui est en PHP.

Bonjour

@Nicolas,

Changer le code NACE d'une société n'est pas très compliqué. C'est comme pour un changement d'adresse de société, il suffit de faire une demande et déposer un dossier ( www.insee.fr/fr/information/1302169?reponse=2680
). Mais je ne crois pas qu'il soit nécessaire d'avoir un code NACE spécifique (je n'ai rien lu à ce sujet ?) et le code NACE n'est que l'activité principale, ça ne veut pas dire que vous ne pouvez pas avoir d'autres activités.

Le code NACE est obligatoire dans le cas suivant:
voir bofip.impots.gouv.fr/bofip/10691-PGP.htm...LA-30-10-30-20160803 point 370

L'attestation doit être établie par l'éditeur du logiciel de comptabilité ou de gestion ou du système de caisse ou par son représentant légal lorsqu'il s'agit d'une société. L'éditeur du logiciel ou système qui fournit l'attestation individuelle ne peut pas être l'assujetti à la TVA au nom duquel est établie l'attestation, sauf si l'activité déclarée par cet assujetti (code NACE) est une activité d'édition de logiciels de comptabilité ou de gestion ou de systèmes de caisse.

Je ne sais pas comment tu as l'intention de faire, mais si tu developpes une solution pour hikashop, tu ne peux pas utiliser en l'etat ta solution pour ton shop.
sauf si tu changes ton code NACE.

@Sandrine
tu as mentionné le code NACE 5829C ( www.hikashop.com/forum/orders-management...hikashop.html#285458 )

Je ne retourve pas ce code NACE dans la documentation officielle

édition de logiciels de comptabilité ou de gestion ou de systèmes de caisse

En attendant, la confirmation du code NACE, j'ai trouvé ca:

nace.comptable-en-ligne.fr/5829C

et je ne vois pas cette mention qui semble si restrictive: logiciels de comptabilité ou de gestion ou de systèmes de caisse

Je crois que le problème est encore un peu plus complexe que cela dans la mesure où la solution proposée doit faire l'objet d'une license spéfique délivrée au client et que celui-ci ne peut pas modifier le code.
Cela vient en opposition au principe de l'open source et de license GPL demandée par joomla pour être référencé dans la JED.

En d'autres termes, la solution ne pourra pas être proposée par les sites qui publient leurs extensions dans la JED mais devra l'être sous une autre nom sous peine de risquer d'être dé-référencé chez joomla.
En effet, joomla n'autorise pas d'avoir sur un même site des extensions GPL et d'autres avec un license.