Loi de finance 2016 et Logiciels Libres (suite).

503 views
Skip to first unread message

Christophe

unread,
Apr 5, 2016, 7:47:19 AM4/5/16
to tryt...@googlegroups.com
Bonjour,

Pour faire suite à mon précédent mail sur le sujet, vous trouverez sur
le site du Synpell [1] un détail [2] de ce qu'attend l'administration
fiscale française au sujet des logiciels de comptabilité (en particulier
la page 3 du [2]).

Maintenant la question est, est-ce que Tryton doit/peut aller vers ce
type d'exigences ?
Pour compléter la réflexion, je pense que la demande de l'administration
Française n'est que le prémisse, et que d'autres administration d'autres
pays vont aller vers ce type d'exigences.

Alors j'aimerais ouvrir le débat sur les 2 volets qui existe (a mon
sens) sur cette question :

- La question légale de qui et comment fournir la preuve à
l'administration ?
- et la question technique de comment répondre a cette exigence ?

Sur la question légale, j'aurais tendance a penser pour ma part que
c'est à l'intégrateur de fournir cette preuve, mais pour cela il faut
qu'il puisse s'appuyer sur le coté technique pour prendre cette
responsabilité.
Sur la question technique je crois qu'il faudrait implémenter un
mécanisme garantissant l'inaltérabilité des écritures mais je n'ai pas
(encore ...) la moindre idée du comment.

Qu'en pensez vous ?

[1] : http://www.synpell.fr
[2] :
http://www.synpell.fr/data/2016-04-04%20--%20Sollicitation%20commentaires%20art88%20-%20synpell.pdf

Bien cordialement.
--
Christophe CRIER
Adiczion (www.adiczion.com)
Tél : +33.6.65.59.39.68

Dominique Chabord

unread,
Apr 5, 2016, 8:50:14 AM4/5/16
to tryt...@googlegroups.com
Bonjour,

merci d'avoir recherché ce document.

Le 5 avril 2016 à 13:46, Christophe <c...@adiczion.com> a écrit :

>
> Maintenant la question est, est-ce que Tryton doit/peut aller vers ce type
> d'exigences ?

As tu identifié des évolutions nécessaires de Tryton ?

ir le débat sur les 2 volets qui existe (a mon sens)
> sur cette question :
>
> - La question légale de qui et comment fournir la preuve à
> l'administration ?

Il semble que le texte le précise : le dernier intervenant technique
en mesure de modifier le logiciel ou le système.

> - et la question technique de comment répondre a cette exigence ?
>
L'administration semble demander un certificat, pas une preuve.
Pour délivrer un certificat sans risque, je suppose qu'il faut
analyser et valider le code des modules utilisés.

>
> Qu'en pensez vous ?

Tel qu'est rédigé le texte, on dirait qu'un utilisateur ne peut plus
contrôler lui-même son serveur de comptabilité, sauf si son NACE est
un code de certificateur.
Je pense pouvoir émettre des certificats pour mes clients, mais je ne
pourrai pas utiliser moi-même le service de SISalp. Peut-être pourrait
on croiser le service : j'héberge ton système, tu héberges le mien ;-)

Autre cas qui ne semble pas adressé, celui des sociétés qui
sous-traitent la saisie de leur comptabilité. Faut-ils qu'ils
disposent de caisses autonomes ? C'est quand même assez régressif.

Ce qui m'étonne dans ce texte, c'est qu'on passe de la création de
facture à l'enregistrement des paiements, sans articulation. Pour
SISalp qui n'accepte pas de paiements en liquide et ne paie rien en
liquide, rien n'est plus fiable et complet que le relevé de la banque.
SISalp est également en mode TVA sur encaissement/décaissement.

Cédric Krier

unread,
Apr 8, 2016, 11:20:04 AM4/8/16
to tryt...@googlegroups.com
On 2016-04-05 13:46, Christophe wrote:
> Bonjour,
>
> Pour faire suite à mon précédent mail sur le sujet, vous trouverez sur le
> site du Synpell [1] un détail [2] de ce qu'attend l'administration fiscale
> française au sujet des logiciels de comptabilité (en particulier la page 3
> du [2]).
>
> Maintenant la question est, est-ce que Tryton doit/peut aller vers ce type
> d'exigences ?
> Pour compléter la réflexion, je pense que la demande de l'administration
> Française n'est que le prémisse, et que d'autres administration d'autres
> pays vont aller vers ce type d'exigences.
>
> Alors j'aimerais ouvrir le débat sur les 2 volets qui existe (a mon sens)
> sur cette question :
>
> - La question légale de qui et comment fournir la preuve à
> l'administration ?
> - et la question technique de comment répondre a cette exigence ?
>
> Sur la question légale, j'aurais tendance a penser pour ma part que c'est à
> l'intégrateur de fournir cette preuve, mais pour cela il faut qu'il puisse
> s'appuyer sur le coté technique pour prendre cette responsabilité.
> Sur la question technique je crois qu'il faudrait implémenter un mécanisme
> garantissant l'inaltérabilité des écritures mais je n'ai pas (encore ...) la
> moindre idée du comment.
>
> Qu'en pensez vous ?

D'abord, si je comprends bien à qui ça s'applique, ce ne sont que les
sociétés qui tiennent une caisse en interne (pas nécessaire si tout est
fait via transfert bancaire).

Personnellement, je pense que la Section 3, I, B a été écrite par une
personne qui n'a aucune connaissance en informatique. Et que donc si on
a une lecture de technicien sur la réglementation, on s'aperçoit très
vite qu'il faut un tiers de confiance pour pouvoir implémenter les
conditions d'inaltérabilité et de sécurisation.
Et en fait, c'est ce qu'a mis en place l'état belge pour les commerces
dans la restauration (le secteur plus marqué par la fraude) par
l'utilisation de boite noire branchée sur les caisses.

Si on reste pragmatique, je pense que ce qui est vraiment demandé c'est
que les écritures comptables une fois postée ne puisse plus être
modifiée par l'utilisateur "normalement" du système. C'est quasiment
garantie par Tryton si on enlève l'option "update_posted" sur le journal
(c'est de tout manière une option que je n'ai jamais considérée
correcte). Aussi non si on veut garder cette option, il faudra activer
l'historisation sur les écritures comptables.
Si la demande n'est pas pragmatique, je pense qu'il faudra trouver un
tiers (probablement les même qu'en Belgique) qui pourra fournir une
boite noir (certifiée) à la quelle on enverra toutes les écritures en
directe.

Quand à la certification, il n'est absolument pas clair sur quelle
critère elle va se baser. Je suppose que ce sera principalement, une
vérification manuelle que l'on ne peut pas modifier depuis l'interface
utilisateur les écritures postées. Dans ce cas, je ne pense pas que ce
sera difficile à obtenir. Et comme elle peut se baser uniquement sur les
versions majeurs, je suppose qu'on pourra mutualiser le coût et faire
certifier le module 'account' chaque année.

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com
Tel: +32 472 54 46 59
Website: http://www.b2ck.com/

Richard PALO

unread,
Apr 9, 2016, 6:28:40 AM4/9/16
to tryt...@googlegroups.com
Le 08/04/16 17:15, Cédric Krier a écrit :
>
> D'abord, si je comprends bien à qui ça s'applique, ce ne sont que les
> sociétés qui tiennent une caisse en interne (pas nécessaire si tout est
> fait via transfert bancaire).
>

*Tous* les assujettis à la TVA sont concernés par ces mesures, malheureusement.
Il ne s'agit pas d'un système de caisse", mais de tout règlement client, y compris bancaire.

--

Richard PALO

Dominique Chabord

unread,
Apr 9, 2016, 8:19:41 AM4/9/16
to tryt...@googlegroups.com
La cible est le paiement en espèce mais je pense qu'une entreprise ne
peut pas refuser les paiements en espèce.
Quel point particulier veux tu soulever ?


> --
>
> Richard PALO
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr.
> Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/5708D97B.1080901%40free.fr.

Christophe

unread,
Apr 9, 2016, 1:02:00 PM4/9/16
to tryt...@googlegroups.com
Le 09/04/2016 14:19, Dominique Chabord a écrit :
> Le 9 avril 2016 à 12:29, Richard PALO <richar...@free.fr> a écrit :
>> Le 08/04/16 17:15, Cédric Krier a écrit :
>>>
>>> D'abord, si je comprends bien à qui ça s'applique, ce ne sont que les
>>> sociétés qui tiennent une caisse en interne (pas nécessaire si tout est
>>> fait via transfert bancaire).
>>>
>>
>> *Tous* les assujettis à la TVA sont concernés par ces mesures, malheureusement.
>> Il ne s'agit pas d'un système de caisse", mais de tout règlement client, y compris bancaire.
>>
>
> La cible est le paiement en espèce mais je pense qu'une entreprise ne
> peut pas refuser les paiements en espèce.

Non pas seulement, si au départ c'était seulement les paiements en
espèces (dans le projet) l'article 88 précise maintenant :

"... Lorsqu'elle enregistre les règlements de ses clients au moyen d'un
logiciel de comptabilité ou de gestion ou d'un système de caisse,
utiliser un logiciel ou un système 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, attestées par un
certificat délivré par un organisme accrédité dans les conditions
prévues à l'article L. 115-28 du code de la consommation ou par une
attestation individuelle de l'éditeur, conforme à un modèle fixé par
l'administration
... "

> Quel point particulier veux tu soulever ?
>
>
>> --
>>
>> Richard PALO
>>
>> --
>> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr.
>> Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/5708D97B.1080901%40free.fr.
>

Dominique Chabord

unread,
Apr 9, 2016, 1:17:47 PM4/9/16
to tryt...@googlegroups.com
@Christophe

Dans quels autres cas les règlements sont ils enregistrés par un
logiciel, en dehors des règlements en espèces ?

Mais je pensais un peu dans ton sens, à savoir que même si on
n'enregistre pas de paiements, on risque de devoir quand même
certifier le logiciel de gestion, pour le cas où on serait un jour
payé en espèce.
> https://groups.google.com/d/msgid/tryton-fr/57093557.4070504%40adiczion.com.

Richard PALO

unread,
Apr 9, 2016, 2:53:43 PM4/9/16
to tryt...@googlegroups.com
Le 09/04/16 19:17, Dominique Chabord a écrit :
> @Christophe
>
> Dans quels autres cas les règlements sont ils enregistrés par un
> logiciel, en dehors des règlements en espèces ?

Sans répondre pour Christophe, je me demande comment on pourrait croire écarter règlement
par chèque ou bien tout mouvement par virement et/ou prélèvement, carte bancaire...
sans oublier le 'règlement' par compensation des créances et dettes.

Dans l'esprit du législateur, ce sont certainement des éléments permettant de contrôler
le fait générateur de l’exigibilité de la TVA (http://bofip.impots.gouv.fr/bofip/1463-PGP)

Il ne faut pas rêver... d'être d'accord ou pas d'accord, ça ne changera pas forcément des choses.

cdlt,
--

Richard PALO

Dominique Chabord

unread,
Apr 9, 2016, 5:28:41 PM4/9/16
to tryt...@googlegroups.com
Le 9 avril 2016 à 20:54, Richard PALO <richar...@free.fr> a écrit :
> Le 09/04/16 19:17, Dominique Chabord a écrit :
>> @Christophe
>>
>> Dans quels autres cas les règlements sont ils enregistrés par un
>> logiciel, en dehors des règlements en espèces ?
>
> Sans répondre pour Christophe, je me demande comment on pourrait croire écarter règlement
> par chèque ou bien tout mouvement par virement et/ou prélèvement, carte bancaire...
> sans oublier le 'règlement' par compensation des créances et dettes.


c'est le relevé bancaire qui enregistre les chèques et virements, pas
le logiciel de gestion.

>
> Dans l'esprit du législateur, ce sont certainement des éléments permettant de contrôler
> le fait générateur de l’exigibilité de la TVA (http://bofip.impots.gouv.fr/bofip/1463-PGP)

d'où probablement la mention des écritures liées à la facturation dans
le texte quand c'est la facture qui génère l'éxigibilité ? C'est bien
ma compréhension en effet.

>
> Il ne faut pas rêver... d'être d'accord ou pas d'accord, ça ne changera pas forcément des choses.

d'accord ou pas avec quoi ?

>
> cdlt,
> --
>
> Richard PALO
>
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr.
> Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/57094FDB.8060206%40free.fr.

Christophe

unread,
Apr 9, 2016, 7:09:41 PM4/9/16
to tryt...@googlegroups.com
Le 09/04/2016 19:17, Dominique Chabord a écrit :
> @Christophe
>
> Dans quels autres cas les règlements sont ils enregistrés par un
> logiciel, en dehors des règlements en espèces ?

Dans tous les autres cas. Je comprends ce que tu sous entends, a savoir
qu'il existe d'autres moyens de savoir qu'une entreprise a reçu un
paiement (comme par exemple le relevé bancaire), mais il n'y a que dans
le logiciel qui gère la comptabilité qu'il y a le détail de la
répartition de la TVA.
Mais je pense que nous entrons dans un débat inutile, le texte dit qu'il
faut fournir un moyen de garantir l'inaltérabilité des écritures
comptable et a défaut d'autre chose cela passe soit par la certification
soit par l'attestation.

Richard PALO

unread,
Apr 10, 2016, 2:00:34 AM4/10/16
to tryt...@googlegroups.com
Le 09/04/16 23:28, Dominique Chabord a écrit :
> c'est le relevé bancaire qui enregistre les chèques et virements, pas
> le logiciel de gestion.

?? le relevé de banque n'est rien d'autre qu'une pièce de support du journal
de banque informatisé.

>
> d'où probablement la mention des écritures liées à la facturation dans
> le texte quand c'est la facture qui génère l'éxigibilité ? C'est bien
> ma compréhension en effet.
> --

Ça dépend! Il ne faut pas toujours confondre le fait générateur et l'exigibilité.

Pour un prestataire de services n'ayant pas opté pour la TVA sur les débits,
c'est bien, par exemple, à la date de réception du règlement* qui détermine
l'exigibilité en matière de la TVA. (*la date d'échéance pour les BOR/LCR)

Que l'assujetti comptabilise "correctement" dans un premier temps au compte 511
avant la mise en banque relève d'une *tolérance* du fisc, ou non, lors d'un
éventuel contrôle de la comptabilité.

J'imagine que l'appréciation de la comptabilisation par seulement une écriture
en 512 pour les "encaissements" dans le même mois soit bien différente que pour les
montants systématiquement reportés dans une autre période...même au delà du mois suivant.
Pas le même effet pour une entreprise tenue de déclarer le CA3 par rapport à une au CA12.

Aussi, avec 'autoliquidation' de la TVA pour les sous-traitants, si c'est simplifié pour
le fournisseur sous-traitant, il y a quand-même des traitements à faire pour le preneur assujetti.

--

Richard PALO

Dominique Chabord

unread,
Apr 10, 2016, 4:49:12 AM4/10/16
to tryt...@googlegroups.com
Le 10 avril 2016 à 08:01, Richard PALO <richar...@free.fr> a écrit :
> Le 09/04/16 23:28, Dominique Chabord a écrit :
>> c'est le relevé bancaire qui enregistre les chèques et virements, pas
>> le logiciel de gestion.
>
> ?? le relevé de banque n'est rien d'autre qu'une pièce de support du journal
> de banque informatisé.


Le texte précise qu'il s'applique "dès lors qu'ils enregistrent
eux-mêmes les règlements de leurs clients" §A1 de la note
Le relevé de banque est l'enregistrement des paiements qui fait foi en
cas de litige. Ce sont pour moi les données d'origine relatives à
l'encaissement §B1 de la note

De mon point de vue naïf, le relevé de banque est une pièce
équivalente au rouleau de caisse enregistreuse. Pour ce dernier, à
partir du moment où la caisse est autonome et non paramétrable, le
logiciel de gestion qui est derrière n'est pas concerné semble t il,
même si on effectue une écriture centralisée des mouvements de caisse.

Bien sûr, mon discours serait différent si Tryton intégrait une
fonction point de vente, comme d'autres logiciels le font.

Je peux me tromper dans l'interprétation, mais s'il y a une chance que
j'aie raison, ça vaudrait le coût de confirmer.

>
>> --
>
> Ça dépend! Il ne faut pas toujours confondre le fait générateur et l'exigibilité.

je ne confonds pas.
>

Richard PALO

unread,
Apr 10, 2016, 7:09:44 AM4/10/16
to tryt...@googlegroups.com
Le 10/04/16 10:49, Dominique Chabord a écrit :
> Le 10 avril 2016 à 08:01, Richard PALO <richar...@free.fr> a écrit :
>> Le 09/04/16 23:28, Dominique Chabord a écrit :
>>> c'est le relevé bancaire qui enregistre les chèques et virements, pas
>>> le logiciel de gestion.
>>
>> ?? le relevé de banque n'est rien d'autre qu'une pièce de support du journal
>> de banque informatisé.
>
>
> Le texte précise qu'il s'applique "dès lors qu'ils enregistrent
> eux-mêmes les règlements de leurs clients" §A1 de la note
> Le relevé de banque est l'enregistrement des paiements qui fait foi en
> cas de litige. Ce sont pour moi les données d'origine relatives à
> l'encaissement §B1 de la note
>

Il est possible que la définition d'enregistrement soit plutôt dans le sens du PCG.

> De mon point de vue naïf, le relevé de banque est une pièce
> équivalente au rouleau de caisse enregistreuse. Pour ce dernier, à
> partir du moment où la caisse est autonome et non paramétrable, le
> logiciel de gestion qui est derrière n'est pas concerné semble t il,
> même si on effectue une écriture centralisée des mouvements de caisse.
>
> Bien sûr, mon discours serait différent si Tryton intégrait une
> fonction point de vente, comme d'autres logiciels le font.
>
> Je peux me tromper dans l'interprétation, mais s'il y a une chance que
> j'aie raison, ça vaudrait le coût de confirmer.
>

Pour être sûr de ne pas vous tromper dans votre analyse, il existe toujours
la procédure du rescrit fiscal qui vous permet de soumettre vos questions
au service des impôts des entreprises.

Sachant que certains cas de figure (ou bien, mesures de tolérance) ne sont pas
applicables à toute entreprise...

(et article R123-203 du Code de Commerce ne s'applique pas globalement non plus)

cdlt,
--

Richard PALO

Richard PALO

unread,
Apr 11, 2016, 7:41:41 AM4/11/16
to tryt...@googlegroups.com
Le 08/04/16 17:15, Cédric Krier a écrit :
>
> Si on reste pragmatique, je pense que ce qui est vraiment demandé c'est
> que les écritures comptables une fois postée ne puisse plus être
> modifiée par l'utilisateur "normalement" du système. C'est quasiment
> garantie par Tryton si on enlève l'option "update_posted" sur le journal
> (c'est de tout manière une option que je n'ai jamais considérée
> correcte). Aussi non si on veut garder cette option, il faudra activer
> l'historisation sur les écritures comptables.

J'ai eu l'impression par ta réponse du 10/12/2015 au
> [tryton-fr] désactivation de l'option 'update_posted' pour PCG français
que la décision a déjà été prise!

Restant dans cette attente...

--

Richard PALO

Christophe

unread,
Apr 13, 2016, 3:23:28 AM4/13/16
to tryt...@googlegroups.com
Si tu entend par caisse en interne la possibilité de marquer des facture
comme payées et que cette opération engendre une écriture comptable qui
sera utilisé pour calculer la TVA collectée alors oui.

>
> Personnellement, je pense que la Section 3, I, B a été écrite par une
> personne qui n'a aucune connaissance en informatique. Et que donc si on
> a une lecture de technicien sur la réglementation, on s'aperçoit très
> vite qu'il faut un tiers de confiance pour pouvoir implémenter les
> conditions d'inaltérabilité et de sécurisation.
> Et en fait, c'est ce qu'a mis en place l'état belge pour les commerces
> dans la restauration (le secteur plus marqué par la fraude) par
> l'utilisation de boite noire branchée sur les caisses.
>
> Si on reste pragmatique, je pense que ce qui est vraiment demandé c'est
> que les écritures comptables une fois postée ne puisse plus être
> modifiée par l'utilisateur "normalement" du système. C'est quasiment
> garantie par Tryton si on enlève l'option "update_posted" sur le journal
> (c'est de tout manière une option que je n'ai jamais considérée
> correcte). Aussi non si on veut garder cette option, il faudra activer
> l'historisation sur les écritures comptables.

Je pense aussi le l'option "update_posted" devrait être masquée/enlevée
pour faire un premier pas dans la réponse aux obligations.
Sur la question de l'historisation des écritures, peux tu me dire en 2
mots ce que ça fait ?

> Si la demande n'est pas pragmatique, je pense qu'il faudra trouver un
> tiers (probablement les même qu'en Belgique) qui pourra fournir une
> boite noir (certifiée) à la quelle on enverra toutes les écritures en
> directe.
>
> Quand à la certification, il n'est absolument pas clair sur quelle
> critère elle va se baser. Je suppose que ce sera principalement, une
> vérification manuelle que l'on ne peut pas modifier depuis l'interface
> utilisateur les écritures postées. Dans ce cas, je ne pense pas que ce
> sera difficile à obtenir. Et comme elle peut se baser uniquement sur les
> versions majeurs, je suppose qu'on pourra mutualiser le coût et faire
> certifier le module 'account' chaque année.

Oui ce n'est pas très clair, car la clarification passe par une journée
de formation proposé par un organisme : Infocert (~600€HT). Ensuite nous
devrions en savoir un peu plus sur ce qui est attendu. Après je ne sais
pas combien coûte la certification en elle même mais dés que j'ai l'info
je la communiquerais ici.

Richard PALO

unread,
Aug 19, 2016, 11:38:56 AM8/19/16
to tryt...@googlegroups.com
Pour infos, voici un document récemment publié:

http://bofip.impots.gouv.fr/bofip/10691-PGP.html

Sa lecture est vivement recommandée.

--

Richard PALO

Cédric Krier

unread,
Aug 24, 2016, 11:55:02 AM8/24/16
to tryt...@googlegroups.com
On 2016-08-19 17:38, Richard PALO wrote:
> Pour infos, voici un document récemment publié:
>
> http://bofip.impots.gouv.fr/bofip/10691-PGP.html
>
> Sa lecture est vivement recommandée.

B2CK va voir avec son avocat si on pourrait mettre en place un service
(payant) pour délivrer des attestations individuelles.

Dominique Chabord

unread,
Aug 24, 2016, 1:02:33 PM8/24/16
to tryton-fr
Le 24 août 2016 à 17:50, Cédric Krier <cedric...@b2ck.com> a écrit :
> On 2016-08-19 17:38, Richard PALO wrote:
>> Pour infos, voici un document récemment publié:
>>
>> http://bofip.impots.gouv.fr/bofip/10691-PGP.html
>>
>> Sa lecture est vivement recommandée.
>
> B2CK va voir avec son avocat si on pourrait mettre en place un service
> (payant) pour délivrer des attestations individuelles.


De mon côté, je pense tester un serveur virtuel
- dont l'accès au code et à la base est réservé par contrat
- sur lequel les copies de la base de production produisent des
documents taggés.

Cédric Krier

unread,
Jul 2, 2017, 12:30:05 PM7/2/17
to tryt...@googlegroups.com
On 2016-08-24 17:50, Cédric Krier wrote:
> On 2016-08-19 17:38, Richard PALO wrote:
> > Pour infos, voici un document récemment publié:
> >
> > http://bofip.impots.gouv.fr/bofip/10691-PGP.html
> >
> > Sa lecture est vivement recommandée.
>
> B2CK va voir avec son avocat si on pourrait mettre en place un service
> (payant) pour délivrer des attestations individuelles.

Changement du périmètre de la loi:

http://proxy-pubminefi.diffusion.finances.gouv.fr/pub/document/18/22503.pdf

Du coup, comme Tryton n'a pas encore de gestion de caisse, B2CK ne
mettra pas en place le site de vente d'attestation.
Par contre, B2CK pourra sur demande en fournir un car Tryton est quand
même prêt.

Dominique Chabord

unread,
Jul 3, 2017, 4:11:09 AM7/3/17
to tryton-fr
Le 2 juillet 2017 à 18:25, Cédric Krier <cedric...@b2ck.com> a écrit :

> Par contre, B2CK pourra sur demande en fournir un car Tryton est quand
> même prêt.

Qu'est ce que tu entends pas Tryton est prêt ?
Il est difficile d'attester qu'il est conforme à un règlement qui ne
le concerne pas.
En revanche, les logiciels de compta restent soumis à d'autres réglementations.
A quelle réglementation votre attestation certifie la conformité ?

Cédric Krier

unread,
Jul 3, 2017, 7:00:06 AM7/3/17
to tryton-fr
On 2017-07-03 10:11, Dominique Chabord wrote:
> Le 2 juillet 2017 à 18:25, Cédric Krier <cedric...@b2ck.com> a écrit :
>
> > Par contre, B2CK pourra sur demande en fournir un car Tryton est quand
> > même prêt.
>
> Qu'est ce que tu entends pas Tryton est prêt ?
> Il est difficile d'attester qu'il est conforme à un règlement qui ne
> le concerne pas.

Et bien c'est juste le périmètre de la loi qui change pas les
contraintes. Or on a déjà réglé les quelques points pour les quelles
Tryton n'était pas conforme (ex: la possibilité de modifier une écriture
postée).
Donc oui on est prêt à attester que Tryton (standard) est conforme à
cette loi mais évidement la demande pour ces attestations ne sera pas
très grande car ce ne sera utile que pour les personnes qui
l'utiliseront comme caisse. Or Tryton n'a pas vraiment les
fonctionnalités attendues pour un tel usage, et il y a probablement des
contraintes supplémentaires.

> En revanche, les logiciels de compta restent soumis à d'autres réglementations.
> A quelle réglementation votre attestation certifie la conformité ?

Je n'ai lu que cette loi.

Dominique Chabord

unread,
Jul 3, 2017, 8:41:03 AM7/3/17
to tryton-fr
Le 3 juillet 2017 à 12:55, Cédric Krier <cedric...@b2ck.com> a écrit :

>
> Et bien c'est juste le périmètre de la loi qui change pas les
> contraintes. Or on a déjà réglé les quelques points pour les quelles
> Tryton n'était pas conforme (ex: la possibilité de modifier une écriture
> postée).

Sur cet exemple, c'est une condition pour autoriser la comptabilité
sur Tryton, mais c'est pas en rapport avec ce que l'administration
appelle l'enregistrement des données de paiement.


> Donc oui on est prêt à attester que Tryton (standard) est conforme à
> cette loi mais évidement la demande pour ces attestations ne sera pas
> très grande car ce ne sera utile que pour les personnes qui
> l'utiliseront comme caisse. Or Tryton n'a pas vraiment les
> fonctionnalités attendues pour un tel usage, et il y a probablement des
> contraintes supplémentaires.
>
Tryton est il réellement conforme au règlement des caisses ?
(clotûre quotidienne, signature et archivage quotidiens, etc...)

Si on atteste Tryton, cela risque de faire croire que Tryton peut être
substitué à une caisse certifiée. Je ne le crois pas.

Cédric Krier

unread,
Jul 3, 2017, 9:50:05 AM7/3/17
to tryton-fr
On 2017-07-03 14:41, Dominique Chabord wrote:
> Le 3 juillet 2017 à 12:55, Cédric Krier <cedric...@b2ck.com> a écrit :
>
> >
> > Et bien c'est juste le périmètre de la loi qui change pas les
> > contraintes. Or on a déjà réglé les quelques points pour les quelles
> > Tryton n'était pas conforme (ex: la possibilité de modifier une écriture
> > postée).
>
> Sur cet exemple, c'est une condition pour autoriser la comptabilité
> sur Tryton, mais c'est pas en rapport avec ce que l'administration
> appelle l'enregistrement des données de paiement.

Si Tryton enregistre des paiements se sera avec cette object donc il
doit être conforme.

> > Donc oui on est prêt à attester que Tryton (standard) est conforme à
> > cette loi mais évidement la demande pour ces attestations ne sera pas
> > très grande car ce ne sera utile que pour les personnes qui
> > l'utiliseront comme caisse. Or Tryton n'a pas vraiment les
> > fonctionnalités attendues pour un tel usage, et il y a probablement des
> > contraintes supplémentaires.
> >
> Tryton est il réellement conforme au règlement des caisses ?
> (clotûre quotidienne, signature et archivage quotidiens, etc...)

Comme je l'ai dit, je n'ai pas lu (s'il y en a une) de norme sur le
règlement des caisses. Donc je ne peux pas dire.

> Si on atteste Tryton, cela risque de faire croire que Tryton peut être
> substitué à une caisse certifiée. Je ne le crois pas.

Si on atteste, on atteste que les conditions définies dans cette loi et
rien d'autre.

Richard PALO

unread,
Jul 3, 2017, 1:10:27 PM7/3/17
to tryt...@googlegroups.com
Le 03/07/2017 à 15:48, Cédric Krier a écrit :
> Si on atteste, on atteste que les conditions définies dans cette loi et
> rien d'autre.

Comme indiqué par Dominique et mentionné dans d'autres fils de cette liste,
il y a bien d'autres exigences pour une comptabilité conforme que le sujet
traité par ce seul chapitre particulier dans la Loi de Finances 2016/2017 --
notamment celles indiquées dans le PCG Français, le code de commerce, livre des
procédures fiscales, code général des impôts ...

C'est un très bon moment pour que la communauté française de Tryton et surtout
les utilisateurs (et prestataires) soumis à la legislation française lancent un
"audit" afin d'identifier formellement les besoins spécifiques et d'évaluer
le niveau de conformité assuré par la plateforme.

Idéal serait un document évolutif régulièrement mis à jour p.e. dans le dépôt 'account_fr'.

bien cordialement,
--

Richard PALO

Dominique Chabord

unread,
Jul 3, 2017, 1:24:10 PM7/3/17
to tryton-fr
Le 3 juillet 2017 à 15:48, Cédric Krier <cedric...@b2ck.com> a écrit :

>
> Si Tryton enregistre des paiements se sera avec cette object donc il
> doit être conforme.

Je n'y crois pas, mais je peux me tromper. Ca sera une bonne nouvelle.

>
>> > Donc oui on est prêt à attester que Tryton (standard) est conforme à
>> > cette loi mais évidement la demande pour ces attestations ne sera pas
>> > très grande car ce ne sera utile que pour les personnes qui
>> > l'utiliseront comme caisse. Or Tryton n'a pas vraiment les
>> > fonctionnalités attendues pour un tel usage, et il y a probablement des
>> > contraintes supplémentaires.
>> >
>> Tryton est il réellement conforme au règlement des caisses ?
>> (clotûre quotidienne, signature et archivage quotidiens, etc...)
>
> Comme je l'ai dit, je n'ai pas lu (s'il y en a une) de norme sur le
> règlement des caisses. Donc je ne peux pas dire.

On ne parle que de ça, c''est ce fameux article de la LF2016
et tu y trouveras cloture quotidienne, signature et archivage quotidiens, etc...
>
>> Si on atteste Tryton, cela risque de faire croire que Tryton peut être
>> substitué à une caisse certifiée. Je ne le crois pas.
>
> Si on atteste, on atteste que les conditions définies dans cette loi et
> rien d'autre.

Bon, je ne comprends pas, mais tant mieux.

lists.j...@symetrie.com

unread,
Aug 8, 2017, 2:12:38 PM8/8/17
to tryt...@googlegroups.com
Bonjour,


Le 3 juil. 2017 à 19:24, Dominique Chabord <dominiqu...@sisalp.org> a écrit :
>>> Tryton est il réellement conforme au règlement des caisses ?
>>> (clotûre quotidienne, signature et archivage quotidiens, etc...)
>>
>> Comme je l'ai dit, je n'ai pas lu (s'il y en a une) de norme sur le
>> règlement des caisses. Donc je ne peux pas dire.
>
> On ne parle que de ça, c''est ce fameux article de la LF2016
> et tu y trouveras cloture quotidienne, signature et archivage quotidiens, etc...
>>
>>> Si on atteste Tryton, cela risque de faire croire que Tryton peut être
>>> substitué à une caisse certifiée. Je ne le crois pas.
>>
>> Si on atteste, on atteste que les conditions définies dans cette loi et
>> rien d'autre.
>
> Bon, je ne comprends pas, mais tant mieux.

Dominique a relancé la discussion sur Twitter avec ce doc :
https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf

Il en ressort que tout encaissement de paiement de particuliers doit respecter tellement de conditions qu’il devra être externalisé chez un prestataires certifié…
Ou bien il faudra revenir à la vieille méthode du cahier manuscrit qui lui est autorisé.

Cependant, la question 5 pointe que ne sont maintenant concernées que les opérations d’encaissement de
> livraisons de biens et les prestations de services ne donnant pas lieu à facturation au sens du BOI-
> TVA DECLA-30-20-10.
> En conséquence, les opérations B to B sont exclues du champ du dispositif, les relations entre
> professionnels faisant obligatoirement l'objet d'une facturation.

Les ventes à distance comme le ecommerce nécessitent facturation, on pourrait donc les penser exclues de ce champ.

Cédric Krier

unread,
Aug 8, 2017, 4:20:05 PM8/8/17
to tryt...@googlegroups.com
On 2017-08-08 20:12, lists.j...@symetrie.com wrote:
> Bonjour,
>
>
> Le 3 juil. 2017 à 19:24, Dominique Chabord <dominiqu...@sisalp.org> a écrit :
> >>> Tryton est il réellement conforme au règlement des caisses ?
> >>> (clotûre quotidienne, signature et archivage quotidiens, etc...)
> >>
> >> Comme je l'ai dit, je n'ai pas lu (s'il y en a une) de norme sur le
> >> règlement des caisses. Donc je ne peux pas dire.
> >
> > On ne parle que de ça, c''est ce fameux article de la LF2016
> > et tu y trouveras cloture quotidienne, signature et archivage quotidiens, etc...
> >>
> >>> Si on atteste Tryton, cela risque de faire croire que Tryton peut être
> >>> substitué à une caisse certifiée. Je ne le crois pas.
> >>
> >> Si on atteste, on atteste que les conditions définies dans cette loi et
> >> rien d'autre.
> >
> > Bon, je ne comprends pas, mais tant mieux.

En fait, le document si dessous explique pourquoi une utilisation de
Tryton actuelle pourrait requérir une telle attestation.

> Dominique a relancé la discussion sur Twitter avec ce doc :
> https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf
>
> Il en ressort que tout encaissement de paiement de particuliers doit
> respecter tellement de conditions qu’il devra être externalisé chez un
> prestataires certifié…

Le problème n'est pas le nombre de condition mais la définition de
l'inaltérabilité des donnée (point 21).
Lors de ma discussion avec notre avocat sur l'interprétation de la loi
originelle, nous avions conclus que le premier point était suffisant
d'où le fait que B2CK envisageait de fournir des attestations.
Mais au vue du point 21-2, s'il faut être robuste contre un "homme de
l'art", il n'y a pas d'autre solution que le tiers de confiance (pour
moi).
Donc j'imagine deux solutions:

La première serait d'avoir un module qui envoie un hash du mouvement
posté avec l'identifiant du mouvement à un service web gérer par un
tiers de confiance. Ce tiers s'engage à publier à la demande les hash
afin de permettre la vérification que les mouvement n'ont pas été
modifié depuis le postage.
Une variante distribuée serait possible en utilisant un ledger distribué
comme BigchainDB.

La deuxième est la boite noire (ex: http://www.boîtenoire.be/) qui sert
de tiers de confiance local. Il faudrait voir s'il existe des
fournisseurs en France de telle boîte.

> Ou bien il faudra revenir à la vieille méthode du cahier manuscrit qui lui est autorisé.

Dans ce cas, il ne faut pas posséder de système informatisé car il
devrait quand même être certifié ou attesté (Cf point 16).

> Cependant, la question 5 pointe que ne sont maintenant concernées que les opérations d’encaissement de
> > livraisons de biens et les prestations de services ne donnant pas lieu à facturation au sens du BOI-
> > TVA DECLA-30-20-10.
> > En conséquence, les opérations B to B sont exclues du champ du dispositif, les relations entre
> > professionnels faisant obligatoirement l'objet d'une facturation.
>
> Les ventes à distance comme le ecommerce nécessitent facturation, on pourrait donc les penser exclues de ce champ.

Je ne pense pas que ce soit une interprétation correcte car elle est en
contradiction avec le point 9 du document.

Cédric Krier

unread,
Aug 8, 2017, 6:15:28 PM8/8/17
to tryt...@googlegroups.com
On 2017-08-08 22:17, Cédric Krier wrote:
> Le problème n'est pas le nombre de condition mais la définition de
> l'inaltérabilité des donnée (point 21).
> Lors de ma discussion avec notre avocat sur l'interprétation de la loi
> originelle, nous avions conclus que le premier point était suffisant
> d'où le fait que B2CK envisageait de fournir des attestations.
> Mais au vue du point 21-2, s'il faut être robuste contre un "homme de
> l'art", il n'y a pas d'autre solution que le tiers de confiance (pour
> moi).
> Donc j'imagine deux solutions:
>
> La première serait d'avoir un module qui envoie un hash du mouvement
> posté avec l'identifiant du mouvement à un service web gérer par un
> tiers de confiance. Ce tiers s'engage à publier à la demande les hash
> afin de permettre la vérification que les mouvement n'ont pas été
> modifié depuis le postage.
> Une variante distribuée serait possible en utilisant un ledger distribué
> comme BigchainDB.
>
> La deuxième est la boite noire (ex: http://www.boîtenoire.be/) qui sert
> de tiers de confiance local. Il faudrait voir s'il existe des
> fournisseurs en France de telle boîte.

J'ai peut-être une troisième option mais qui est moins sûr.
On pourrait utiliser un chainage de hash (comme mercurial ou github) des
mouvements postés. C'est ce qu'implémente Odoo apparemment pour répondre
à cette loi. Mais le problème c'est qu'il est très facile de recalculer
l'ensemble de la chaîne si on modifie un enregistrement, parce que les
hash sont conçu pour être rapide (particulièrement sha256 qu'Odoo
utilise).
Par contre on pourrait utiliser une méthode lente comme d'écrite sur
https://www.quora.com/What-is-the-most-compute-expensive-hashing-algorithm
Mais bon le coup rendrait peut-être le mécanisme trop lent pout une
utilisation.

Dominique Chabord

unread,
Aug 8, 2017, 7:11:56 PM8/8/17
to tryton-fr
Juste une question pour essayer de me sentir moins décalé dans cette discussion.

Pourquoi tenez vous à utiliser l'ERP pour faire l'enregistrement légal
des paiements ?

Quelle est la contrainte réelle que vous ne pouvez contourner ?

Cédric Krier

unread,
Aug 8, 2017, 7:45:07 PM8/8/17
to tryton-fr
On 2017-08-09 01:11, Dominique Chabord wrote:
> Juste une question pour essayer de me sentir moins décalé dans cette discussion.
>
> Pourquoi tenez vous à utiliser l'ERP pour faire l'enregistrement légal
> des paiements ?

Je ne comprends pas ce que tu entends par "enregistrement *légal*".
Si on veut tenir une comptabilité au moins de gestion, il faut entrer
les paiements sinon il est impossible de faire le suivit des impayés.

> Quelle est la contrainte réelle que vous ne pouvez contourner ?

Gérer les liquidités de l'entreprise.

Sebastien Marie

unread,
Aug 9, 2017, 3:00:06 AM8/9/17
to tryton-fr
On Wed, Aug 09, 2017 at 01:40:07AM +0200, Cédric Krier wrote:
> On 2017-08-09 01:11, Dominique Chabord wrote:
> > Juste une question pour essayer de me sentir moins décalé dans cette discussion.
> >
> > Pourquoi tenez vous à utiliser l'ERP pour faire l'enregistrement légal
> > des paiements ?
>
> Je ne comprends pas ce que tu entends par "enregistrement *légal*".
> Si on veut tenir une comptabilité au moins de gestion, il faut entrer
> les paiements sinon il est impossible de faire le suivit des impayés.
>
> > Quelle est la contrainte réelle que vous ne pouvez contourner ?
>
> Gérer les liquidités de l'entreprise.
>

Je suis assez d'accord avec Cédric: le point 16 soulève le cas où
l'assujetti enregistre les réglements de ses clients à la fois au moyen
d'un logiciel mais aussi sous format papier (facturier).

La réponse (comme je la comprends), c'est que le fait d'enregistrer via
un facturier ne change pas le fait que l'assujetti utilise aussi un
logiciel, et donc que celui-ci doit être conforme.

Il me semble que c'est ici que l'on avait évoqué cette possibilité
d'utiliser le facturier en complément par assurer le role de "preuve
comptable" et le logiciel ne servant que de "support" (enregistrer la
preuve) en reprennant le facturier. La réponse de l'administration
semble dire que cela n'est pas suffisant.

Ainsi, dès lors qu'une entreprise a des clients non assujettis, son
logiciel semble devoir être certifié (je n'ai pas encore pris le temps
de lire en détail les réferences du point 1 qui traite du type
d'opération/clients concernés: "ne donnant pas lieu à facturation au
sens du BOI-TVA DECLA-30-20-10").

--
Sebastien Marie

Sebastien Marie

unread,
Aug 9, 2017, 3:29:20 AM8/9/17
to tryton-fr
On Wed, Aug 09, 2017 at 08:46:28AM +0200, Sebastien Marie wrote:
>
> Il me semble que c'est ici que l'on avait évoqué cette possibilité
> d'utiliser le facturier en complément par assurer le role de "preuve
> comptable" et le logiciel ne servant que de "support" (enregistrer la
> preuve) en reprennant le facturier. La réponse de l'administration
> semble dire que cela n'est pas suffisant.
>

"que c'est ici" => rectification, ce n'était peut être pas ici que cela
avait été évoqué, mais possiblement sur la liste comptabilité de
l'APRIL (https://listes.april.org/wws/arc/comptabilite/), mais je ne
retrouve pas non plus.

--
Sebastien Marie

lists.j...@symetrie.com

unread,
Aug 9, 2017, 3:58:23 AM8/9/17
to tryt...@googlegroups.com
Bonjour,


Le 8 août 2017 à 22:17, Cédric Krier <cedric...@b2ck.com> a écrit :
> Donc j'imagine deux solutions:
>
> La première serait d'avoir un module qui envoie un hash du mouvement
> posté avec l'identifiant du mouvement à un service web gérer par un
> tiers de confiance. Ce tiers s'engage à publier à la demande les hash
> afin de permettre la vérification que les mouvement n'ont pas été
> modifié depuis le postage.
> Une variante distribuée serait possible en utilisant un ledger distribué
> comme BigchainDB.
>
> La deuxième est la boite noire (ex: http://www.boîtenoire.be/) qui sert
> de tiers de confiance local. Il faudrait voir s'il existe des
> fournisseurs en France de telle boîte.

Merci Cédric de chercher une solution.
Il me semble qu’il faut aussi avancer sur l’interprétation du champ d’application.
Il s’agit de manière certaines des *règlements* et uniquement de ceux concernant les non-assujéttis, donc les particuliers. Mais il se pourrait que ce ne soit que les particuliers lors des opérations de vente sans facture : si cela était, la vente à distance (ecommerce) serait donc exclue car il y a facturation obligatoire.
J’ai interrogé ma CCI et vous transmettrai son retour.

Voici des documents plus précis pour votre examen :

La page officielle
https://www.impots.gouv.fr/portail/actualite/obligation-dutiliser-un-logiciel-de-comptabilite-ou-de-gestion-ou-un-systeme-de-caisse

qui pointe vers les bulletins officiels
— TVA - CF - Obligation d'utiliser un logiciel de comptabilité ou de gestion ou un système de caisse conforme (loi n° 2015-1785 du 29 décembre 2015 de finances pour 2016, art. 88)
http://bofip.impots.gouv.fr/bofip/10693-PGP/version/10?identifiant=ACTU
— BOI-TVA-DECLA-30-10-30
http://bofip.impots.gouv.fr/bofip/10691-PGP.html?identifiant=BOI-TVA-DECLA-30-10-30-20160803

La page de l’AFNOR NF 525 :
http://marque-nf.com/categories/technologies-de-linformation-et-de-la-communication/nf-logiciel-de-gestion-dencaissement-nf525/

La liste des produits et logiciels certifiés :
http://infocert.org/index.php?option=com_content&view=article&id=5:certificats&catid=11:certificats&Itemid=454

Celle du LNE (qui a l’air de s’occuper uniquement des caisses) :
https://www.lne.fr/communiques-de-presse/logiciels-encaissement-certifies

lists.j...@symetrie.com

unread,
Aug 9, 2017, 4:32:29 AM8/9/17
to tryt...@googlegroups.com
Bonjour,

Le 9 août 2017 à 09:58, lists.j...@symetrie.com a écrit :
> J’ai interrogé ma CCI et vous transmettrai son retour.

Voici le document communiqué en réponse. Je n’aurai un expert au téléphone que début septembre.

Logiciels de caisse.pdf

Dominique Chabord

unread,
Aug 9, 2017, 4:35:05 AM8/9/17
to tryton-fr
pour ma part, depuis deux ans de discussion, rien ne m'a démontré :

- qu'on ne pouvait pas enregistrer les paiements sur un carnet facturier.
- qu'on ne pouvait pas utiliser des caisses homologuées sur les points de vente.

d'autre part, une de mes croyances n'a été ni confirmée ni infirmée.
Elle consistait à penser qu'on ne peut pas recevoir des espèces sans
un des deux moyens ci-dessus depuis 30 ans et que tous les commerçants
se sont équipés. Cette loi reprécise que ça sera interdit, donc la
question est close.

Cette loi ne change pas ces principes. Elle adapte les règles
d'homologation des caisses pour tenir compte de l'informatisation des
caisses et des logiciels multi-fonctions qui assurent directement une
fonction de caisse. Cette fonction n'existe pas sur Tryton.

Il y a cette fonction sur Pastèque, Dolibarr et Odoo qui ont un problème.
Aujourd'hui je pronostique que
- Pastèque qui ne fait que de la caisse, transpire, ils sortiront
peut-être une version crédible cet automne.
- Dolibarr va simplement supprimer son add-on POS
- Odoo-entreprise a promis mais ne fera pas.
- Odoo-community a regroupé quelques devs qui essaient de s'en sortir,
mais je pense qu'ils ont sous estimé la précision cahier des charges
et sont encore dans la créativité.

On a pensé à en développer la fonction caisse embarquée sur Tryton, et
à mon avis, il vaut mieux ne pas le faire. Au moins dans un premier
temps, interfacer Tryton à des systèmes de caisse homologués est plus
rapide, plus sûr, et beaucoup plus flexible car cette stratégie
s'adapte aux contraintes du client dans le choix de sa caisse.
Ces systèmes de caisse aujourd'hui ne peuvent être que propriétaires.
Si il existe un jour un système open-source homologué, il sera temps
de le considérer.

lists.j...@symetrie.com

unread,
Aug 9, 2017, 4:42:08 AM8/9/17
to tryt...@googlegroups.com
Bonjour Dominique,


Le 9 août 2017 à 10:35, Dominique Chabord <dominiqu...@sisalp.org> a écrit :
> pour ma part, depuis deux ans de discussion, rien ne m'a démontré :
>
> - qu'on ne pouvait pas enregistrer les paiements sur un carnet facturier.
> - qu'on ne pouvait pas utiliser des caisses homologuées sur les points de vente.

Il me semble que le premier § de BOI-TVA-DECLA-30-10-30 mentionne clairement les logiciels de gestion et pas seulement de caisse :

> TVA - Régimes d'imposition et obligations déclaratives et comptables - Obligations d'ordre comptable - 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
>
> I. Conditions d'inaltérabilité, de sécurisation, de conservation et d'archivage que doivent remplir les logiciels de comptabilité ou de gestion ou les systèmes de caisse
>
> 1
>
> En application du 3° bis du I de l'article 286 du code général des impôts (CGI), toute personne assujettie à la taxe sur la valeur ajoutée (TVA) qui enregistre les règlements de ses clients au moyen d'un logiciel de comptabilité ou de gestion ou d'un système de caisse, doit utiliser un logiciel ou un système 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.

et pour la tenue papier, le point 520

> Si l'assujetti ne présente aucun certificat ni attestation individuelle au motif qu'il ne détient pas de logiciel de comptabilité ou de gestion, ni de système de caisse (cas de l'assujetti qui dispose d'une caisse autonome sans fonction « enregistrement » – BOI-CF-COM-10-80 au XIII-A-1 § 180), il lui appartient de prouver par tous moyens qu'il n'enregistre pas les règlements de ses clients au moyen d'un tel logiciel ou système, par exemple en présentant un extrait de sa comptabilité tenue sur papier.


Source
http://bofip.impots.gouv.fr/bofip/10691-PGP.html?identifiant=BOI-TVA-DECLA-30-10-30-20160803

Dominique Chabord

unread,
Aug 9, 2017, 4:43:35 AM8/9/17
to tryton-fr
Le 9 août 2017 à 08:46, Sebastien Marie <sem...@online.fr> a écrit :

>
> Je suis assez d'accord avec Cédric: le point 16 soulève le cas où
> l'assujetti enregistre les réglements de ses clients à la fois au moyen
> d'un logiciel mais aussi sous format papier (facturier).

Il me semble évident qu'un paiement ne doit être enregistré qu'un
fois. Sinon on a une double comptabilité.
Par exemple un artisan a une caisse au bureau et un carnet quand il se déplace.

>
> La réponse (comme je la comprends), c'est que le fait d'enregistrer via
> un facturier ne change pas le fait que l'assujetti utilise aussi un
> logiciel, et donc que celui-ci doit être conforme.

Tous les équipements qui servent à enregistrer des paiements doivent
être conformes me paraît aussi évident.
On voit mal le commerçant disposer de deux caisses, un homologuée,
l'autre "chocolat" et répartir les paiements entre les deux.

Dominique Chabord

unread,
Aug 9, 2017, 4:48:03 AM8/9/17
to tryton-fr
Le 9 août 2017 à 01:40, Cédric Krier <cedric...@b2ck.com> a écrit :
> On 2017-08-09 01:11, Dominique Chabord wrote:
>> Juste une question pour essayer de me sentir moins décalé dans cette discussion.
>>
>> Pourquoi tenez vous à utiliser l'ERP pour faire l'enregistrement légal
>> des paiements ?
>
> Je ne comprends pas ce que tu entends par "enregistrement *légal*".
> Si on veut tenir une comptabilité au moins de gestion, il faut entrer
> les paiements sinon il est impossible de faire le suivit des impayés.


Ce n'est parce qu'on a enregistré un paiement sur un facturier ou sur
une caisse enregistreuse, qu'on ne peut pas reporter ces informations
de paiement sur le logiciel de gestion/comptabilité. Ce logiciel de
comptabilité ne devient pas pour autant un logiciel de caisse.

>
>> Quelle est la contrainte réelle que vous ne pouvez contourner ?
>
> Gérer les liquidités de l'entreprise.

Ma question est sur les contraintes pas sur l'objectif :
dans quel cas, devez vous enregistrer le paiement directement sur le
logiciel de comptabilité sans pouvoir utiliser un moyen de caisse
homologué ?

>

Cédric Krier

unread,
Aug 9, 2017, 4:50:05 AM8/9/17
to tryt...@googlegroups.com
On 2017-08-09 09:58, lists.j...@symetrie.com wrote:
> Bonjour,
>
>
> Le 8 août 2017 à 22:17, Cédric Krier <cedric...@b2ck.com> a écrit :
> > Donc j'imagine deux solutions:
> >
> > La première serait d'avoir un module qui envoie un hash du mouvement
> > posté avec l'identifiant du mouvement à un service web gérer par un
> > tiers de confiance. Ce tiers s'engage à publier à la demande les hash
> > afin de permettre la vérification que les mouvement n'ont pas été
> > modifié depuis le postage.
> > Une variante distribuée serait possible en utilisant un ledger distribué
> > comme BigchainDB.
> >
> > La deuxième est la boite noire (ex: http://www.boîtenoire.be/) qui sert
> > de tiers de confiance local. Il faudrait voir s'il existe des
> > fournisseurs en France de telle boîte.
>
> Merci Cédric de chercher une solution.
> Il me semble qu’il faut aussi avancer sur l’interprétation du champ
> d’application.
> Il s’agit de manière certaines des *règlements* et uniquement de ceux
> concernant les non-assujéttis, donc les particuliers.

Pour ce n'est si clair que ça.
Source: https://www.economie.gouv.fr/files/files/directions_services/dgfip/controle_fiscal/actualites_reponses/logiciels_de_caisse.pdf

La réponse 2 définit que les fonctions de caisse enregistreuses doivent
être uniquement certifiées/attestées.
Mais la réponse 1 définit ce qu'est un logiciel de caisse (et elle est
plus large que celle du sens commun).

« Ainsi, un logiciel de gestion qui permet l’enregistrement des
opérations de ventes ou de prestations de services qui concernent
les non assujettis à la TVA (clients particuliers) doit être
considéré comme un logiciel ou un système de caisse visé par le
dispositif. »

On parle d'*opération de ventes* et pas uniquement de règlement.

Bon après le document est remplis d'incohérence de vocabulaire, voir
même de contradictions. Puisque par après à réponse 6, on parle « qui
enregistre les règlements de ses clients ».

En fait, je pense qu'il est impossible dans l'état de savoir ce que veut
faire vos législateurs.

> Mais il se pourrait que ce ne soit que les particuliers lors des
> opérations de vente sans facture : si cela était, la vente à distance
> (ecommerce) serait donc exclue car il y a facturation obligatoire.

Ici encore, il y a la réponse 9 qui dit que l'e-commerce avec des
particuliers relève du champ d'application.
La réponse 5 explique que c'est le B2B qui est exclus en se basant sur
le fait qu'il est obligatoire de faire une facture.
Donc il semble qu'il n'est pas obligatoire de faire une facture dans
l'e-commerce avec particulier, bien que je pense que tout le monde le
fasse. Et j'ai l'impression que le fait de faire malgrès tout des
factures, n'exempte pas de la certification/attestation.

> J’ai interrogé ma CCI et vous transmettrai son retour.
>
> Voici des documents plus précis pour votre examen :
>
> La page officielle
> https://www.impots.gouv.fr/portail/actualite/obligation-dutiliser-un-logiciel-de-comptabilite-ou-de-gestion-ou-un-systeme-de-caisse
>
> qui pointe vers les bulletins officiels

Oui mais qu'il parle aussi de la publication ultérieur de la FAQ qu'on
est entrain d'analyser. J'ai tendance à considérer les dernières
publication comme étant plus valable.

> — TVA - CF - Obligation d'utiliser un logiciel de comptabilité ou de gestion ou un système de caisse conforme (loi n° 2015-1785 du 29 décembre 2015 de finances pour 2016, art. 88)
> http://bofip.impots.gouv.fr/bofip/10693-PGP/version/10?identifiant=ACTU
> — BOI-TVA-DECLA-30-10-30
> http://bofip.impots.gouv.fr/bofip/10691-PGP.html?identifiant=BOI-TVA-DECLA-30-10-30-20160803
>
> La page de l’AFNOR NF 525 :
> http://marque-nf.com/categories/technologies-de-linformation-et-de-la-communication/nf-logiciel-de-gestion-dencaissement-nf525/
>
> La liste des produits et logiciels certifiés :
> http://infocert.org/index.php?option=com_content&view=article&id=5:certificats&catid=11:certificats&Itemid=454
>
> Celle du LNE (qui a l’air de s’occuper uniquement des caisses) :
> https://www.lne.fr/communiques-de-presse/logiciels-encaissement-certifies

Cédric Krier

unread,
Aug 9, 2017, 5:30:06 AM8/9/17
to tryton-fr
On 2017-08-09 10:48, Dominique Chabord wrote:
> >> Quelle est la contrainte réelle que vous ne pouvez contourner ?
> >
> > Gérer les liquidités de l'entreprise.
>
> Ma question est sur les contraintes pas sur l'objectif :
> dans quel cas, devez vous enregistrer le paiement directement sur le
> logiciel de comptabilité sans pouvoir utiliser un moyen de caisse
> homologué ?

Quand le paiement est électronique.

Dominique Chabord

unread,
Aug 9, 2017, 5:32:17 AM8/9/17
to tryton-fr
> --
> Vous recevez ce message, car vous êtes abonné au groupe Google Groupes tryton-fr.
> Cette discussion peut être lue sur le Web à l'adresse https://groups.google.com/d/msgid/tryton-fr/20170809092532.GM3742%40kei.



--
Dominique Chabord - SISalp
Logiciel libre pour l'entreprise Tryton et open-source Odoo, OpenERP
18 avenue Beauregard 74960 Cran Gevrier
145A rue Alexandre Borrely 83000 Toulon
tel(repondeur) +33(0)950274960 fax +33(0)955274960 mob +33(0)622616438
http://sisalp.fr
http://openerp-online.fr
https://twitter.com/SISalp l'actualité de vos services en temps réel.

Dominique Chabord

unread,
Aug 9, 2017, 5:51:19 AM8/9/17
to tryton-fr
Le 9 août 2017 à 11:25, Cédric Krier <cedric...@b2ck.com> a écrit :
> On 2017-08-09 10:48, Dominique Chabord wrote:
>> >> Quelle est la contrainte réelle que vous ne pouvez contourner ?
>> >
>> > Gérer les liquidités de l'entreprise.
>>
>> Ma question est sur les contraintes pas sur l'objectif :
>> dans quel cas, devez vous enregistrer le paiement directement sur le
>> logiciel de comptabilité sans pouvoir utiliser un moyen de caisse
>> homologué ?
>
> Quand le paiement est électronique.


On est d'accord !
ouf

En effet, on n'utilise pas de caisse enregistreuse pour les virements
et pour les paiements par internet. Il n'est pas possible d'avoir les
informations de paiement sur un ticket de caisse dans ce cas. On ne
peut que le constater sur le relevé de banque.

Si la réception d'un paiement électronique n'est pas considéré comme
déjà enregistré par la banque, quelle est alors la pièce comptable
qu'il faut produire à la place du relevé de banque ? Comment peut elle
comporter des informations correspondant mieux à une réalité que le
relevé de banque ? et ensuite qu'est-ce qu'on en fait si on n'utilise
pas de logiciel de gestion ?

On en revient donc au point concernant le commerce électronique qui
semble totalement absurde à première lecture.
Je pense qu'il vaut mieux attendre que l'administration comprenne elle
même ce qu'elle a écrit.

cam....@azerttyu.net

unread,
Aug 9, 2017, 7:05:07 AM8/9/17
to tryton-fr liste
Salut

http://proxy-pubminefi.diffusion.finances.gouv.fr/pub/document/18/22503.pdf

Le périmètre est maintenant très réduit. Les solutions POS sont
concernées (pastèque), pas les ERP, e-boutique. Et ceux proposant en
complément du POS (module dolibarr, prestashop) ne seraient pas
concernés vu qu'ils ne sont pas logiciels de caisse mais autre chose.

Je pense aussi que chez dolibarr, on va plutôt tendre vers un couple
pasteque/dolibarr pour séparer les 2 périmètres et enlever toutes
ambiguïté. Cela me semble la solution saine à suivre.

Et je viens de voir passer cette dépêche qui compile déjà une partie
des liens échangés :
https://linuxfr.org/news/loi-finances-2016-un-soulagement-pour-les-logiciels-de-compta

Km

Cédric Krier

unread,
Aug 9, 2017, 7:35:05 AM8/9/17
to tryton-fr liste
On 2017-08-09 12:46, cam....@azerttyu.net wrote:
> Salut
>
> http://proxy-pubminefi.diffusion.finances.gouv.fr/pub/document/18/22503.pdf
>
> Le périmètre est maintenant très réduit. Les solutions POS sont
> concernées (pastèque), pas les ERP, e-boutique. Et ceux proposant en
> complément du POS (module dolibarr, prestashop) ne seraient pas
> concernés vu qu'ils ne sont pas logiciels de caisse mais autre chose.

Ce document date du 15 juin, la nouvelle FAQ plus récente contredit ce
périmètre réduit.

> Je pense aussi que chez dolibarr, on va plutôt tendre vers un couple
> pasteque/dolibarr pour séparer les 2 périmètres et enlever toutes
> ambiguïté. Cela me semble la solution saine à suivre.
>
> Et je viens de voir passer cette dépêche qui compile déjà une partie
> des liens échangés :
> https://linuxfr.org/news/loi-finances-2016-un-soulagement-pour-les-logiciels-de-compta

La première partie du commentaire
https://linuxfr.org/nodes/112440/comments/1710083 va dans mon sens. Bien
que je pense qu'il soit possible de mettre en place un système valide
mais basé sur un tiers de confiance.

Dominique Chabord

unread,
Aug 9, 2017, 7:39:42 AM8/9/17
to tryton-fr
Le 9 août 2017 à 12:46, cam....@azerttyu.net
<cam....@azerttyu.net> a écrit :
> Salut
>
> http://proxy-pubminefi.diffusion.finances.gouv.fr/pub/document/18/22503.pdf


le document dont on parle ici est plus récent. On ne rouvre pas la
discussion générale. Le nouveau document détaille des points de la loi
votée et est parfois en incohérence avec la déclaration du ministre
(qui n'est toujours pas traduite par un texte).

>
> Le périmètre est maintenant très réduit. Les solutions POS sont
> concernées (pastèque), pas les ERP, e-boutique.

ca c'est la déclaration du ministre, pas les textes. La FAQ a une
toute autre tonalité.

> Et ceux proposant en
> complément du POS (module dolibarr, prestashop) ne seraient pas
> concernés vu qu'ils ne sont pas logiciels de caisse mais autre chose.

Si, ça n'a jamais été discutable. les POS sont en plein dans le
collimateur : ils sont désignés comme fonction de caisse de logiciels
généralistes dans le nouveau document.

>
> Je pense aussi que chez dolibarr, on va plutôt tendre vers un couple
> pasteque/dolibarr pour séparer les 2 périmètres et enlever toutes
> ambiguïté. Cela me semble la solution saine à suivre.

C'est loin d'être fait.
D'une part Pastèque a renoncé à la certification, d'autre part, à ce
que j'ai regardé, la mise en relation des deux solutions est loin
d'être facile. Je suis rapidement arrivé à écarter la solution
Pastèque+Tryton.

J'aboutis à une conclusion similaire après avoir étudié la mise bout à
bout d'un POS Odoo sur un serveur Tryton. Le problème, c'est le POS
Odoo qui embarque obligatoirement 34 modules d'Odoo, la plupart sans
aucune ralation avec la fonction de caisse (Discuss, mail,
procurement, stok, plan comptable...). Encore faudrait il qu'il soit
certifiable à terme.
Pour l'instant, un logiciel de caisse open-source certifié n'est
qu'une spéculation.


>
> Et je viens de voir passer cette dépêche qui compile déjà une partie
> des liens échangés :
> https://linuxfr.org/news/loi-finances-2016-un-soulagement-pour-les-logiciels-de-compta

Oui, ça repart pour un tour.

Cédric Krier

unread,
Aug 9, 2017, 9:25:07 AM8/9/17
to tryt...@googlegroups.com
On 2017-08-08 22:17, Cédric Krier wrote:
> Mais au vue du point 21-2, s'il faut être robuste contre un "homme de
> l'art", il n'y a pas d'autre solution que le tiers de confiance (pour
> moi).
> Donc j'imagine deux solutions:
>
> La première serait d'avoir un module qui envoie un hash du mouvement
> posté avec l'identifiant du mouvement à un service web gérer par un
> tiers de confiance. Ce tiers s'engage à publier à la demande les hash
> afin de permettre la vérification que les mouvement n'ont pas été
> modifié depuis le postage.
> Une variante distribuée serait possible en utilisant un ledger distribué
> comme BigchainDB.

En fait, je pense qu'il est possible d'implémenter un service qui ne
demandera pas au tiers de confiance de stocker un hash pour chaque
mouvement posté (ça peut devenir assez volumineux). De plus une telle
solution requière de conserver les données pour au moins 6 ans.

Donc le nouveau design serait baser sur une signature asymétrique des
hash. On enverrait au service le hash du nouveau mouvement et le hash du
dernier qui a été signer. Le service verifie que le dernier hash est
bien le même que le dernier qu'il a signé, et retourne une signature
qui combine les deux hash. On stockerait cette signature dans la DB avec
le hash.
La clè publique que le service utilise serait donnée aux utilisateur
afin qui puisse vérifier l'intégrité de la comptabilité en vérifiant que
la dernière signature, que tous les mouvements postés sont signés et que
la chaîne de hash est complète.
L'intérêt est qu'il n'y a besoin pour le tiers de stocker que la clè
privée et le dernier hash signé. Et en plus, il est possible de changer
la clè à tout moment de manière transparent, il faut juste la gardée
secrète.

> La deuxième est la boite noire (ex: http://www.boîtenoire.be/) qui sert
> de tiers de confiance local. Il faudrait voir s'il existe des
> fournisseurs en France de telle boîte.

Une boîte noire pourrait être crée en utilisant le service ci-dessus et
en l'embarquant dans une machine celée.


Comme ce serait une solution générique, j'ai proposé à des intégrateur
français d'Odoo de collaborer sur cette solution:
https://twitter.com/cedrickrier/status/895244882528350209
L'idée serait d'avoir plusieurs fournisseurs de cette solution et ainsi
donner le choix aux utilisateurs. Mais aussi d'avoir la plus grande base
possible d'utilisateur afin d'assurer un logiciel de qualité.

Dominique Chabord

unread,
Aug 9, 2017, 10:09:17 AM8/9/17
to tryton-fr
Le 9 août 2017 à 15:21, Cédric Krier <cedric...@b2ck.com> a écrit :

>
>
> Comme ce serait une solution générique, j'ai proposé à des intégrateur
> français d'Odoo de collaborer sur cette solution:
> https://twitter.com/cedrickrier/status/895244882528350209
> L'idée serait d'avoir plusieurs fournisseurs de cette solution et ainsi
> donner le choix aux utilisateurs. Mais aussi d'avoir la plus grande base
> possible d'utilisateur afin d'assurer un logiciel de qualité.
>

Et donc on s'en servirait pour écrire un POS sur Tryton ?

Cédric Krier

unread,
Aug 9, 2017, 10:40:05 AM8/9/17
to tryton-fr
Non, c'est juste pour pouvoir répondre à la contrainte d'inaltérabilité
face à des homme de l'art (initialement B2CK, interprétait la contrainte
face à des utilisateurs).

Dominique Chabord

unread,
Aug 9, 2017, 11:20:39 AM8/9/17
to tryton-fr
Le 9 août 2017 à 16:38, Cédric Krier <cedric...@b2ck.com> a écrit :

>
> Non, c'est juste pour pouvoir répondre à la contrainte d'inaltérabilité
> face à des homme de l'art (initialement B2CK, interprétait la contrainte
> face à des utilisateurs).

et donc, à défaut de pouvoir rendre le POS Odoo conforme, ça leur
permettrait de rendre Odoo globalement conforme ?

Cédric Krier

unread,
Aug 9, 2017, 12:20:05 PM8/9/17
to tryton-fr
Je n'en sait rien moi des plan d'Odoo.
Moi je vois qu'il y a un besoin technique qui est commun donc je
propose de faire une solution à ce besoin.

Richard PALO

unread,
Aug 10, 2017, 4:23:00 AM8/10/17
to tryt...@googlegroups.com
Le 08/08/2017 à 22:17, Cédric Krier a écrit :
> Donc j'imagine deux solutions:
>
> La première serait d'avoir un module qui envoie un hash du mouvement
> posté avec l'identifiant du mouvement à un service web gérer par un
> tiers de confiance. Ce tiers s'engage à publier à la demande les hash
> afin de permettre la vérification que les mouvement n'ont pas été
> modifié depuis le postage.
> Une variante distribuée serait possible en utilisant un ledger distribué
> comme BigchainDB.
>
un simple horodatage certifié (ISO/IEC 18014-3) ?

l'avantage de la variante (distribuée en réalité on non) est la possibilité
de l'installer et la gérer localement et qu'elle aurait la possibilité d'assumer
davantage de rôles convenables: horodatage, notarisation et piste d'audit...
par exemple avec 'multichain'(vu que BigchainDB n'est pas encore en production),
voire quelque chose encore plus légère...

--

Richard PALO

Richard PALO

unread,
Aug 10, 2017, 8:47:14 AM8/10/17
to tryt...@googlegroups.com
Le 10/08/2017 à 10:22, Richard PALO a écrit :
> un simple horodatage certifié (ISO/IEC 18014-3) ?

pour ce cas plutôt simpliste, pourquoi pas servir de `openssl ts`?
(avec la possibilité d'une autorité d'horodatage configurée localement)


--

Richard PALO

Cédric Krier

unread,
Aug 10, 2017, 10:10:04 AM8/10/17
to tryt...@googlegroups.com
C'est encore mieux évidement si on peut réutiliser un standard (que je
ne connaissais pas).
Les points manquants sont:

- openssl ne gère pas l'envoie des requêtes/réponses.

Un simple site web avec authentification devrait faire l'affaire.

- cryptography n'a pas de binding pour cette interface
(https://cryptography.io/en/latest/hazmat/backends/openssl/)

Il faudra soit le proposer à cryptography. Par expérience le projet est
assez ouvert (j'y ai déjà contribué:
https://github.com/pyca/cryptography/commits?author=cedk).
Soit il faudra appeler les commandes via subprocess mais ça rendrait le
déploiement plus compliqué et moins portable (Windows, MacOSX, etc.).

Cédric Krier

unread,
Aug 10, 2017, 10:25:04 AM8/10/17
to tryt...@googlegroups.com
On 2017-08-10 16:05, Cédric Krier wrote:
> On 2017-08-10 14:47, Richard PALO wrote:
> > Le 10/08/2017 à 10:22, Richard PALO a écrit :
> > > un simple horodatage certifié (ISO/IEC 18014-3) ?
> >
> > pour ce cas plutôt simpliste, pourquoi pas servir de `openssl ts`?
> > (avec la possibilité d'une autorité d'horodatage configurée localement)
>
> C'est encore mieux évidement si on peut réutiliser un standard (que je
> ne connaissais pas).

En fait, ça ne protège pas contre la suppression des derniers
enregistrement signé. Il faut que le serveur de signature vérifie la
non-rupture de la chaîne.

Richard PALO

unread,
Aug 10, 2017, 10:42:13 AM8/10/17
to tryt...@googlegroups.com
Le 10/08/2017 à 16:05, Cédric Krier a écrit :
> On 2017-08-10 14:47, Richard PALO wrote:
>> Le 10/08/2017 à 10:22, Richard PALO a écrit :
>>> un simple horodatage certifié (ISO/IEC 18014-3) ?
>>
>> pour ce cas plutôt simpliste, pourquoi pas servir de `openssl ts`?
>> (avec la possibilité d'une autorité d'horodatage configurée localement)
>
> C'est encore mieux évidement si on peut réutiliser un standard (que je
> ne connaissais pas).
> Les points manquants sont:
>
> - openssl ne gère pas l'envoie des requêtes/réponses.
>
> Un simple site web avec authentification devrait faire l'affaire.
>
> - cryptography n'a pas de binding pour cette interface
> (https://cryptography.io/en/latest/hazmat/backends/openssl/)
>
> Il faudra soit le proposer à cryptography. Par expérience le projet est
> assez ouvert (j'y ai déjà contribué:
> https://github.com/pyca/cryptography/commits?author=cedk).
> Soit il faudra appeler les commandes via subprocess mais ça rendrait le
> déploiement plus compliqué et moins portable (Windows, MacOSX, etc.).
>
>


mais le certificat peut être auto-signé:
> https://superuser.com/questions/738612/openssl-ca-keyusage-extension
qui évite, dans ce cas, la nécessité d'envoyer la requête.

Sinon, il faut bien envoyer la requete à une autorité d'horodatage (TSA)
comme dans cet exemple:> http://unmitigatedrisk.com/?p=395

DuckDuckGo (ou g$ggle): openssl timestamp extendedKeyUsage

--

Richard PALO

Richard PALO

unread,
Aug 10, 2017, 11:33:16 AM8/10/17
to tryt...@googlegroups.com
Le 10/08/2017 à 16:21, Cédric Krier a écrit :
> On 2017-08-10 16:05, Cédric Krier wrote:
>> On 2017-08-10 14:47, Richard PALO wrote:
>>> Le 10/08/2017 à 10:22, Richard PALO a écrit :
>>>> un simple horodatage certifié (ISO/IEC 18014-3) ?
>>>
>>> pour ce cas plutôt simpliste, pourquoi pas servir de `openssl ts`?
>>> (avec la possibilité d'une autorité d'horodatage configurée localement)
>>
>> C'est encore mieux évidement si on peut réutiliser un standard (que je
>> ne connaissais pas).
>
> En fait, ça ne protège pas contre la suppression des derniers
> enregistrement signé. Il faut que le serveur de signature vérifie la
> non-rupture de la chaîne.
>

En effet, j'ai réfléchi à cela. Je me suis dit qu'il existe plusieurs cas
de figure dont le cas d'une simple restauration depuis une sauvegarde d'une
base après une panne de quelque sorte.

Ce sera incompréhensible si votre tiers vous met dans une situation où il
serait impossible (ou bien très difficile) de reprendre votre comptabilité.

Je pense qu'il existe des possibilités à évaluer comment éviter (ou au moins
permettre à détecter) cette sorte de malveillance.

Hélas, une fois détecté .. une restauration depuis une sauvegarde encore valable
s'impose ainsi que la nécessité de reprendre les écritures perdues...
sinon la comptabilité risque d'être déclarée non-probante.

cordialement,

--

Richard PALO

Dominique Chabord

unread,
Aug 10, 2017, 11:42:42 AM8/10/17
to tryton-fr
Le 10 août 2017 à 17:33, Richard PALO <richar...@free.fr> a écrit :

> sinon la comptabilité risque d'être déclarée non-probante.

Est ce que tu peux être plus précis sur ce que tu entends par là ?
Je pensais que la compta de devait être probante que sur les périodes
closes et qu'elle devait simplement correspondre aux pièces comptables
archivées.
Si j'ai faux, à quoi faut il veiller ?

Cédric Krier

unread,
Aug 10, 2017, 11:45:04 AM8/10/17
to tryt...@googlegroups.com
On 2017-08-10 16:42, Richard PALO wrote:
> Le 10/08/2017 à 16:05, Cédric Krier a écrit :
> > On 2017-08-10 14:47, Richard PALO wrote:
> >> Le 10/08/2017 à 10:22, Richard PALO a écrit :
> >>> un simple horodatage certifié (ISO/IEC 18014-3) ?
> >>
> >> pour ce cas plutôt simpliste, pourquoi pas servir de `openssl ts`?
> >> (avec la possibilité d'une autorité d'horodatage configurée localement)
> >
> > C'est encore mieux évidement si on peut réutiliser un standard (que je
> > ne connaissais pas).
> > Les points manquants sont:
> >
> > - openssl ne gère pas l'envoie des requêtes/réponses.
> >
> > Un simple site web avec authentification devrait faire l'affaire.
> >
> > - cryptography n'a pas de binding pour cette interface
> > (https://cryptography.io/en/latest/hazmat/backends/openssl/)
> >
> > Il faudra soit le proposer à cryptography. Par expérience le projet est
> > assez ouvert (j'y ai déjà contribué:
> > https://github.com/pyca/cryptography/commits?author=cedk).
> > Soit il faudra appeler les commandes via subprocess mais ça rendrait le
> > déploiement plus compliqué et moins portable (Windows, MacOSX, etc.).
> >
> >
>
>
> mais le certificat peut être auto-signé:
> > https://superuser.com/questions/738612/openssl-ca-keyusage-extension
> qui évite, dans ce cas, la nécessité d'envoyer la requête.

Ça n'a pas d'intérêt de s'auto-signé. Il faut justement avoir un tier de
confiance.
Après évidement ce tiers de confiance pourrait utiliser un certificat
auto-signé.

Cédric Krier

unread,
Aug 10, 2017, 12:25:05 PM8/10/17
to tryt...@googlegroups.com
Après une seconde réfection, je pense que ce ne sera pas un réel
problème d'attester une solution à base de "timestamping".
Car soit c'est le cas d'une restauration après crash et donc un honnête
utilisateur va réencoder les écritures manquantes qui auront un
timestamp décaler (voir même avec un très petit intervalle). Dans un tel
cas, il pourra se justifier par rapport au crash etc.
Soit c'est un utilisateur malhonnête qui a mis en place du code qui
supprime certaine écriture et re-fait le chaînage avec un nouveau
timestamp. Dans ce cas, il y aura une incohérence importante entre les
dates des mouvements et le timestamp qu'il ne pourra pas justifier. Et
vis-a-vis de l'attestation, on pourra l'invalider sous prétexte que
l'utilisateur a mis en place un contournement des protections.
Donc il faudra pouvoir présenter une vérification basé sur des anomalies
de décalage dans les timestamps.

Richard PALO

unread,
Aug 10, 2017, 12:33:46 PM8/10/17
to tryt...@googlegroups.com
Plutôt sur toutes les écritures validées.
http://bofip.impots.gouv.fr/bofip/2899-PGP.html

Pas mal d'infos à trouver sur la toile, dont:
> http://www.lacademie.info/evenements/les_conferences/cahier_n_20_le_controle_fiscal_informatise_comment_s_y_preparer


--

Richard PALO

Dominique Chabord

unread,
Aug 10, 2017, 12:48:03 PM8/10/17
to tryton-fr
Je ne trouve pas ma réponse sur ces documents.
Est-ce qu'on peut déclarer qu'une comptabilité est non-probante parce
qu'on n'a pas mis en place de solution de non-modification comme celle
que vous discutez ?

Dominique Chabord

unread,
Aug 10, 2017, 1:00:55 PM8/10/17
to tryton-fr
Le 10 août 2017 à 18:33, Richard PALO <richar...@free.fr> a écrit :
>
> Plutôt sur toutes les écritures validées.
> http://bofip.impots.gouv.fr/bofip/2899-PGP.html


sur le document que tu m'as indiqué, :
page 20
L’archivage est effectué à la suite du traitement de clôture de chaque période

ce n'est pas à ce propos que vous cherchez à valider l'intangibilité
de chaque écriture, "sinon la comptabilité risque d'être déclarée
non-probante".

Je vous laisse bosser, j'aurai le temps de comprendre plus tard.
Reply all
Reply to author
Forward
0 new messages