Loi finance - article 88 et Hikashop

Bonjour Nicolas,

D’après ce que vous dîtes, vous ne faite actuellement rien pour mettre Hikashop en conformité comme annoncé il y a quelques semaines et attendez que @jms2win "finisse" son pluggin ?

De plus si la solution de @jms2win fonctionne : (je vais prendre mon cas mais je pense que cela en concerne plus d’un)
-il s’agira alors d’un pluggin à rajouter à Hikashop ?
-Celui-ci fonctionnera-t-il sur les sites déjà réalisés ?
-@jms2win, pourrez-vous fournir une attestation aux personnes qui achèteront le module pour leur site ou pour celui de leurs clients ? Si non il n’y a peu d’intérêt à développer le pluggin car même s’il garantie la conformité d’hikashop, en tant qu’indépendante je ne peux pas faire une attestation à la place du développeur pour un pluggin que je n’ai pas développé…
-Comment cela se passera-t-il ? En tant qu’indépendante je fais des sites pour mes clients, pourrais-je continuer à faire de même avec Hikashop car le pluggin garantira la conformité ?
-Le pluggin sera-til inviolable ? de façon à faire en sorte que même si nous modifions quelques éléments du code d’hikashop et template, le pluggin sera tjs ok, actif, comment le serons-nous ?
-Si le pluggin est inviolable, seule l’attestation fournie par @jms2win sera suffisante et nous n’aurons pas besoin d’en faire une pour le client final ?

Désolée si je suis un peu abrupte mais j’ai des dizaines de clients paniqués qui ont un site Hikashop et à qui je leur ai dit que la solution serait mise en conformité courant 2018 et qu’ils pouvaient donc continuer à l’utiliser pendant cette période. De plus la question se pose aussi pour les nouveaux contrats à venir…


@alatak, c’est ici que j’ai vu pour le code NACE 5829€ : www.ecommerce-nation.fr/tribune-logiciels-de-caisse/

Merci
Bonne journée

Bonjour Sandrine

Pour la mise en conformité et respecter tous les éléments, il faut plusieurs choses.
- Garantir l'inaltérabilité des données. La solution en cours de dévelopement est une solution native MySQL et qui n'est pas un plugin joomla ni écrit en PHP.
Il y a juste un tout petit bout de code en PHP pour signaler la mise à jour de structure à MySQL. (Cas des Customs Fields)

- Garantir la conformité des factures:
Cette partie est fournie par l'extension HikaInvoices qui s'intègre à HikaShop et est capable de traiter les données venant de plusieurs extensions.
HikaInvoices normalise déjà les données venant de HikaShop et JoomShopping.
L'interface avec VirtueMart est déjà prévue comme pour les autres extensions mais ne fait pas encore partie du package de distribution.
Pour info, il faut savoir que nous même utilisons à la fois HikaShop, VirtueMart et Akeeba Subcription et que toutes les données sont consolidées via HikaInvoices.
Une interface avec Akeeba subscription est aussi prévue mais non publique actuellement.

Il manque actuellement simplement les clotures périodique et le total perpétuel pour être conforme.

- Garantir l'archivage des données.
Pour cela, nous avons notre weekly backup shell script que nous améliorerons pour ajouter des durées "monthly", "yearly" et "periodically".
Puisque notre weekly backup permet déjà de transférer les backups vers l'extérieur, nous réfléchissons également à mettre ne place un service de backup externe qui permettrait d'améliorer l'inaltérabilité des données et fournir une conservation externe sur la durée de 6 ans.
L'idée est de conserver à l'extérieur un backup des derniers 7 jours, un par mois sur la dernière période comptable et un par année comptable et civile.
Le système imaginé prévoit 2 clés de cryptage.
Une clé avant l'envoi vers le serveur de backup.
Une autre clé utilisée sur le serveur de backup pour re-crypter à nouveau les backups pour empêcher le client de modifier son contenu.
Comme cela, ni le client ni nous ne pourrons accéder aux données et nous pourrons aussi être conforme à la législation sur la protection de la vie privée qui va entrer en vigueur en mai 2018.

- Je crois que l'attestation devra être fournie au client finale et pas à l'agence qui n'aura pas l'autorité de délivrer ce type de certificat.
La mise en conformité d'un site devra faire l'objet d'un controle de la bonne installation et que tous les processus qui contribue à l'application des règles sont parfaitement configurés.
Je cherche des solutions pour essayer d'automatiser ce processus au maximum mais pour le moment cela nécessitera probablement de la consultance pour vérifier que tout est OK avant de délivrer le certificat.

- Concernant la violabiité du plugin, la réponse est quasiment non pour ce qui concerne l'inaltérabilité des données.
Le "runtime" est principalement écrit en MySQL et s'intalle directement sur MySQL indépendament du CMS et des extensions installées.
Le code chargé de son installation n'est pas présent sur le serveur du client et est crypté pour emppécher son altération.
L'installation est spécifique par nom de domaine et ne peut pas être utilisée pour un autre site.
Cela fonctionne comme un web service pour l'installation.
Le code installé dans MySQL est signé électroniquement pour permettre de vérifier son inaltérabilité.
La référence à la license et l'identification du client ainsi que le nom de domaine sont enregistrés dans les sources MySQL installées pour empêcher l'utilisation du code pour un autre client ou un autre site.
Les informations suivantes sont mise dans chaque source installée:
> {__company_name__}
> {__company_address__}
> {__company_zipcode__} {__company_city__}
> {__company_country__}
> {__company_vatnbr__}
> {__site_url__}
> {__license_number__}

L'accès au code source MySQL une fois installé n'est pas aisé. C'est ce qui réduit les risques de modification et qui explique que j'ai choisi de le développer en MySQL natif plutot qu'en PHP.

Je pense pouvoir vous rassurer sur le fait que la solution technique sera disponible en 2018.
Je compte d'ailleurs proposer une conférence sur ce sujet lors du prochain joomla day 2018 à Paris.
Laissez moi encore un peu de temps pour finaliser quelque chose concernant l'inaltérabilité.
Mon but est d'essayer d'avoir un prototype opérationnel dans les prochaines semaines et qui fonctionnerait d'abord pour HikaShop afin de valider la solution imaginée.
Avant de pouvoir délivrer des certificats, cela prendra encore plusieurs semaines puisque les étapes à franchir sont nombreuses et le coût est élevé.
Il faut d'abord s'assurer que la solution sera stable et ne nécessitera pas des modifications pour éviter des coûts supplémentaires.
Lorsque nous aurons la partie "Inaltérabilité", je crois que notre solution serait déjà techniquement OK à 90%.

Comme je l'ai déjà dit, nous avons créé à l'origine HikaInvoices pour réduire les risques de pénalités en cas de non conformité par rapport à la législation sur les factures et les déclarations TVA en europe ou ailleurs.
Ayant contribué à l'étabiissement de la norme française relative à la dématérialisation des factures fin 1999 et début 2000, j'ai voulu utiliser de cette connaissance acquise pour créer HikaInvoices et en faire bénéficier les autres.
Voir ma conférence effectuée au Joomla Day - Nice 2015 sur le sujet
www.hikainvoices.com/support/joomla-day/14-nice-2015.html

Donc le problème n'est pas nouveau.
La seule différence est que maintenant la législation française a mis en place des pénalités lourdes en cas de non respeect de la législation dont les règles devaient déjà être appliquées auparavent mais de manière non contraignante.
Sachez que d'autres pays ont aussi des amendes en cas de non conformités et qui peuvent aussi être lourdes.
C'est le cas par exemple en belgique où l'amende est de 250 EUR minimum par facture émise qui est non conforme.
Peut importe le type d'erreur et le montant de la facture. Il faut multiplier ce montant par le nombre de factures émisent qui contiendraient l'erreur constatée.
Des amendes peuvent être par exemple infligées pour une simple mention manquante comme la référence à un article de loi justifiant l'application d'une règle de calcul particulière.
HikaInvoices est capable de gérer ce genre de problème.

Je ne sais pas ce qu'il en est aujourd'hui mais ce que je peux dire c'est qu'en 2000, quand j'ai effectué le review des factures émisent par les 200 plus grosses entreprises en france, presqu'aucune n'étaient conforme à la législation de l'époque.

Bonjour Edwin,

Et merci pour ces précisions et votre retour rassurant. Je vois que vous avez bien avancé.

Si j’ai bien compris avec votre façon de faire, tout le monde peut faire un site avec hikashop, le personnaliser (template , module…)
+ ajouter l’extension HikaInvoices + bout de code php pour l’inaltérabilité + pour les clôtures et l’archivage (à voir comment tout cela sera mis en place via 1 élément à rajouter ou plusieurs)… pour avoir un site conforme à la législation ?

D’après ce que vous dîtes, pour le développeur qui fait le site pour son client il sera alors impossible de violer les 4 conditions exigées par la loi.
Mais en ce qui concerne l’attestation ou le certification (ça sera quoi ?), vous ( ?) la fournirez au client final (et non au développeur) car par le fait d’avoir installé votre extension inviolable vous pourrez garantir la conformité du site développé par quelqu’un d’autre que vous ?

Je vous laisse continuer et vais lire votre article
Merci
Sandrine

Re-bonjour Sandrine,

Pour la solution technique, effectivement il faudra ajouter HikaInvoices + le truc pour l'inaltérabilité + le backup pour l'archivage qui serait peut être optionnel.

Pour l'attestation, je ne suis pas encore en mesure de vous répondre précisement parce que cela dépend de plein de facteurs que je n'ai pas encore étudié dans le détail.
L'idée serait d'effectivement pouvoir fournir un certificat directement au client final mais pour cela, il faut que nous ayons fait le tour des problèmes techniques pour avoir une vision plus claire.

Comme vous le constatez, nous avancons bien et avons mobilisé toute nos ressources pour avancer sur ce sujet.

Pour les aspects technique, de mon point de vue, vous pourrez toujours créer votre propre template et faire des customisations pour vos clients.
La seule chose que je ne peut pas encore vous dire c'est s'il faudra figer la version hikashop, hikainvoices et/ou autre pour cela.

En tout cas, notre solution pour l'inaltérabilité et la tracabilité des modifications et suppression sur les tables auditées avance bien.
Donc sur ce point là, nous devrierions être OK.
A confirmer lors d'une possible certification ultérieure de notre solution qui ne pourra pas être envisagée avant plusieurs semaines ou mois tant qu'une solution stable ne sera pas disponible.

Merci pour ces précisions

Bonjour,

Ceci m'interpelle car je développe marketplace international depuis la Belgique, les vendeurs sont originaires de pays du monde entier.
Je suis un client direct Hikari, c-a-d je fais mon site moi-même sans passer par un développeur ( - et je ne suis pas un développeur moi-même).
Comment cette loi impacte-elle mon projet car les vendeurs du market sont payés directement?
Est-ce que HikaInvoice est une solution dans mon cas et quid du "+ le truc pour l'inaltérabilité + le backup pour l'archivage"?
Est-ce qu'HikaInvoice génère des factures spécifiques pour chaque vendeur (Facture conforme pour chaque vendeur du marketplace)?

Merci d'avance

@pprle, il est possible avec HikaInvoices de générer des factures pour difference sources et donc s'il faut utiliser des paramètres internes à HikaShop pour générer des factures spécifiques, c'est possible.
La numérotation des documents peut aussi être indépendante.
En fait l'astuce c'est que c'est le répertoire qui garde la copie des documents PDF qui sert à la génération des numéros de documents. Donc si pour chaque type de document l'on décide d'avoir un nomage spécifique des répertoires alors le tour est joué.

HikaInvoices a aussi été concu pour fonctionner avec plusieurs sites en mode multisite (voir jms2win.com) et aussi avec des comptes multiple sur un même serveur avec possiblité de consolidations des données venant de plusieurs sites afin d'avoir une seule comptabilité.

Les possiblités sont nombreuses.
Plus les conditions sont compliquées, plus la configuration l'est aussi parce qu'il faut dans ce cas savoir comment HikaShop a codé les informations en interne pour déclencher le bon document.
En tout cas, le champs qui permet de paramétrer cela existe dans HikaInvoices.

Il est même possible d'établir des documents (pas seulement des factures) avec des entêtes et formats différents.
C'est prévu pour le cas de société ayant des sièges dans différents pays et qui doivent obligatoirement établir des documents au nom des sièges présent dans ces pays quand le client final se trouve dans ce même pays. (Cas de la vente de service électronique).

En fait, il faut tenir compte de la hierachie des lois.
Dans le cas où la facture doit appliquer le taux de TVA du pays où est utilisé le produit ou le service, c'est la loi de ce pays qui s'applique quelque soit la localisation du vendeur.

Dans le cas particulier de la france, la loi française à exclut le cas de vendeur situés dans un autre pays sauf pour le cas des services électroniques dont la loi française devrait être appliquée. C'est parce que ici, la loi européenne prime sur la loi française.

HikaInvoices a mis en place les règles européenne et maintenant est en cours d'ajustement pour ajouter les règles supplémentaires françaises.

PayPal ne peut pas se substituer au site e-commerce parce qu'il n'enregistre pas tout depuis le début.

Je profite de ce message pour vous dire qu'une version de l'inaltérablité est en train d'être ajustée pour devenir un Web Service sécurisé. Une version alpha interne est prévue pour la semaine prochaine.

Bonjour


Après lecture de vos différents post avec interêt, j'interviens également dans la discussion.

Je suis moi même développeur de site e-commerce avec la solution hikashop.

Je trouve très honorable à Ikainvoices de développer un plugin afin de certifier Hikashop ou du mois de délivrer une attestation et merci de le faire.
Ce qui suit n’est pas contre vous mais juste des questions que je me pose.
Mais cela soulève plusieurs problèmes à mes yeux.

- comment un logiciel comme Hikashop peut se reposer sur un plugin externe pour être certifié (ou attester) sans en maîtriser la conception, le développement, et les mises à jour ?

- est ce qu’ aux yeux de la loi cela va être acceptable ? car s’il n’y a pas de certification, il me semble que seul ‘éditeur du logiciel / cms peut fournir une attestation…le développeur ou l’agence ne pourra pas fournir une attestation à son client final juste parce qu’elle a installé un pluggin qui sur « parole » assure la conformité du CMS Hikashop à la loi

- nous sommes (les développeurs et Hikashop) tributaire de ce plugin ce qui peut amener d'autres problèmes du type :
-"monopole" donc aucun contrôle sur le prix du plugin
- si le développeur d'ikainvoices stoppe son activité pour x raisons (décès, liquidation....), on fait comment ?

Pour moi un logiciel ne peut pas se reposer sur un plugin externe pour être certifié, cela doit être fait en interne et même pour Hiksahop cela peut être l’occasion d’acquerir de nouveaux clients. Si les autres CMS (woocommerce et magento ne font rien)

L'idée de Sandrine d'augmenter la licence est peut être une voie à suivre (nous pouvons payer quelques euros de plus) afin d'avoir un logiciel certifié (ou dont l’auteur délivre une attestation) et passer à autre chose (la loi est votée et il n'y aura pas de retour en arrière car comme Prestashop se certifie, Oxatis aussi, j'ai vu passer une information à ce sujet, la loi nous dira de passer sur ces logiciels), nous n'allons mettre 1 an a discuter et perdre des clients qui vont passer chez Prestashop et d’autant plus qu’actuellement nous ne pouvons pas refuser des projets VAD, que faisons-nous ? Nous continuons à les faire avec Hikashop ?.

Merci
Cordialement,
Stéphan

Stéphan,

Tout d'abord, mais je ne vais pas entrer dans les détails, notre société a une convention signée avec la société Hikari qui a été enregistrée auprès d'un bureau d'enregistrement en 2014.
Hikari a la possiblité d'avoir accès au code source.
Le décès d'une personne ne concerne pas une société qui peut continuer à fonctionner.
Seule la liquidation de notre société pourrait-être un problème mais dans ce cas, Hikari ayant le code source, pourrait poursuivre la maintenance.

La solution que nous mettons en place n'est PAS liée uniquement à Hikashop mais à un grand nombre d'extensions e-commerce et pas seulement Joomla. La seule contrainte actuelle c'est que les sites doivent utiliser MySQL. La solution n'est pas prévue pour d'autre serveur de base de donnée Microsoft, Oracle, ....
L'idée est de pouvoir réduire au maximum les coûts liés à cette mise en conformité.

Il est claire que si Hikashop et à coté VirtueMart et à coté CB Subs et autre obtiennent chacun une certification, cela va faire grimper les prix fortement puisqu'il faudra le répercuter d'une manière ou d'une autre sur le client final (francais uniquement).

ok par rapport à votre société et code source

mais cela règle pas la question
-au niveau de la loi si elle va accepter qu'un plugin certifie le logiciel
-la dépendance d'installer un plugin
...

Je crois que cela sera ok surtout que dans HikaInvoices, il peut aussi se substituer aux calculs standard de HikaShop.
Maintenant, on aura la réponse définitive qu'au moment d'une possible certification ultérieure.

Si l'on veut pousser le bouchon encore plus loin, on pourrait aussi se demander si l'on peut encore utiliser le language PHP parce que l'on est pas l'auteur de ce langage.
Dans le cas present, on pourrait considérer les extensions e-commerce comme des librairies qui fonctionneront dans un environment certifié.
C'est l'environement qu'il faut certifier. La boite noire qui enregistre tout.
Après, on met ce que l'on veut dans la boite noire.

C'est un peu comme un firewall qui examine tout le traffic et garde des traces de tout.

ok

mais je reste persuadé que l'administration n'accepter a pas qu'un plugin fasse l'affaire
la certification doit etre native

car rien ne va m’empêcher d'enlever et de remettre le plugin à ma guise ? Vous allez me dire que cela se verra dans la base, mais pour l'administration ou le contrôleur qui n'est pas technicien, il aura pas les compétences de vérifier.

il faut arrêter de tourner autour du pot.
Hikashop doit être certifié nativement.

Comme je l'ai d'jà dit, ce n'est PAS un plugin que l'on ajoute en PHP à Joomla mais un truc natif au niveau de MySQL.
Retirer le setup de MySQL entrainera automatiquement votre perte de conformité et sera détecté.

Bonjour Nicolas,

Merci pour cet éclaircissement.

Question sur l'attestation :

-Si j'ai bien compris, dans le cas d'une agence ou d'un indépendant qui réalise un site pour un client (template perso, modules, pluggin, configuration ...)
l'attestation sera co-signée entre l'éditeur (Hiksahop) et l'agence / indépendant qui fait le site ? et ce pour chaque sité réalisé ?

-pensez-vous qu'il faudrait également faire signer qq chose au client final ? ou seul le fait qu'on ne lui donne pas accès au FTP (code source) et base de données
suffisent puisqu'il n'aura accès qu'à l'administration du site ? faudra-t-il restraint sur accès à l'admin pour ne pas qu'il désactive des modules, composants.... ?

Merci
Bon WK
Sandrine