Export FEC

[Cédric Krier]

Bonjour,

En corrigeant l'issue6435, j'ai remarqué que l'export FEC n'était pas
tout à fait conforme. Du coup, j'ai créé l'issue6451.
J'en ai profité pour ajouter un scenario de test pour l'export FEC mais
j'aimerais quand même avoir une confirmation sur la validité du format
qu'on génère. Pour cela, je recherche quelqu'un qui a une comptabilité
Française sur Tryton et qui pourrait tester avec les deux patches un
export FEC. Il y a un utilitaire de vérification fournis par la
direction générale des finances publiques qui ne fonctionne que sous
Windows:
http://www.economie.gouv.fr/dgfip/outil-test-des-fichiers-des-ecritures-comptables-fec


https://bugs.tryton.org/issue6435
https://bugs.tryton.org/issue6451

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

[Cédric Krier]

On 2017-04-20 15:33, Cédric Krier wrote:
> Bonjour,
>
> En corrigeant l'issue6435, j'ai remarqué que l'export FEC n'était pas
> tout à fait conforme. Du coup, j'ai créé l'issue6451.
> J'en ai profité pour ajouter un scenario de test pour l'export FEC mais
> j'aimerais quand même avoir une confirmation sur la validité du format
> qu'on génère. Pour cela, je recherche quelqu'un qui a une comptabilité
> Française sur Tryton et qui pourrait tester avec les deux patches un
> export FEC. Il y a un utilitaire de vérification fournis par la
> direction générale des finances publiques qui ne fonctionne que sous
> Windows:
> http://www.economie.gouv.fr/dgfip/outil-test-des-fichiers-des-ecritures-comptables-fec

En fait, si nécessaire j'ai accès à la machine Windows de build de la
fondation, donc je peux faire le test si on me fait confiance pour
garder le secret des données ;-) (ma clé GPG est 0xD4B17469F47F75CA)

[Raphael Hertzog]

(merci de me mettre en Cc en réponse)

Salut,

Le jeudi 20 avril 2017, Cédric Krier a écrit :
> qu'on génère. Pour cela, je recherche quelqu'un qui a une comptabilité
> Française sur Tryton et qui pourrait tester avec les deux patches un
> export FEC. Il y a un utilitaire de vérification fournis par la
> direction générale des finances publiques qui ne fonctionne que sous
> Windows:
> http://www.economie.gouv.fr/dgfip/outil-test-des-fichiers-des-ecritures-comptables-fec

J'ai une compta française et je veux bien faire le test. Je tourne
avec Tryton 4.2, est-ce OK pour appliquer les patchs et les tester?

A+
--
Raphaël Hertzog ◈ Writer/Consultant ◈ Debian Developer

Discover the Debian Administrator's Handbook:
→ https://debian-handbook.info/get/

[Cédric Krier]

On 2017-04-28 12:38, Raphael Hertzog wrote:
> (merci de me mettre en Cc en réponse)
>
> Salut,
>
> Le jeudi 20 avril 2017, Cédric Krier a écrit :
> > qu'on génère. Pour cela, je recherche quelqu'un qui a une comptabilité
> > Française sur Tryton et qui pourrait tester avec les deux patches un
> > export FEC. Il y a un utilitaire de vérification fournis par la
> > direction générale des finances publiques qui ne fonctionne que sous
> > Windows:
> > http://www.economie.gouv.fr/dgfip/outil-test-des-fichiers-des-ecritures-comptables-fec
>
> J'ai une compta française et je veux bien faire le test. Je tourne
> avec Tryton 4.2, est-ce OK pour appliquer les patchs et les tester?

Normalement, le patch devrait s'appliquer.

[Raphael Hertzog]

Le jeudi 20 avril 2017, Cédric Krier a écrit :

> qu'on génère. Pour cela, je recherche quelqu'un qui a une comptabilité
> Française sur Tryton et qui pourrait tester avec les deux patches un
> export FEC. Il y a un utilitaire de vérification fournis par la
> direction générale des finances publiques qui ne fonctionne que sous
> Windows:
> http://www.economie.gouv.fr/dgfip/outil-test-des-fichiers-des-ecritures-comptables-fec

Voici en pièce jointe le rapport que j'obtiens.

Analyse des résultats:

- Structure fichier incorrecte, débit/crédit ... renseignés sur une même
ligne ... , ou débit=crédit=0 [33] fois dans le fichier

=> cela vient de la ligne générée pour les reports de soldes. Il faut donc
couper en deux chaque ligne ou juste mettre la différence dans la bonne
case, voire virer la ligne lorsque crédit=débit.

- Le champ COMPTENUM est incorrect , le numéro de compte doit commencer
par trois chiffres ; ... ... [33] fois dans le fichier

=> cela vient du compte 58 que j'utilise en intermédiaire pour les
virements internes, il faut sûrement corriger le plan comptable
pour que 58 ne soit pas utilisable directement qu'il ait un (ou
plusieurs) sous-comptes dédiés. Je l'utilise pour des virements
internes lorsqu'il y a des délais entre l'envoi et la réception
de l'argent (genre PayPal -> Banque). Ou alors aussi pour le relevé
de carte bancaire afin de pouvoir utiliser un relevé pour la carte
et pour le compte bancaire (car il est impossible de partager une
écriture entre deux relevés séparés à ma connaissance).

- Au moins un enregistrement dans le FEC ne contient pas de valeur pour le
champ JOURNALCODE

=> créer un code automatique pour les journal sans code officiel ?
(peut-être juste le numéro du journal)

- Au moins un enregistrement dans le FEC ne contient pas de valeur pour le
champ PIECEREF

=> remettre "EcritureNum" lors qu'on a rien à mettre en PieceRef? C'est le
cas de toutes les mouvements comptables que je saisis manuellement
(opérations diverse, charges saisies sans facture fournisseur, etc.)

- Au moins un enregistrement dans le FEC ne contient pas de valeur pour le
champ ECRITURELIB

=> la plupart des lignes correspondant à des entrées de relevé n'ont pas
de libellé, peut-on mettre un libellé automatique du genre "Encaissement
de X" ou "Paiement de Y" en fonction du signe et du nom du tiers ?

Note que l'écriture de report des soldes est également concernée par ces
trois derniers messages.

Cordialement,

[Dominique Chabord]

Le 2 mai 2017 à 10:12, Raphael Hertzog <rap...@ouaza.com> a écrit :

>
> => cela vient du compte 58 que j'utilise

Si je me souviens bien, un compte a obligatoirement 3 chiffres, à 2
chiffres il s'agit d'une "classe"

[Cédric Krier]

On 2017-05-02 10:12, Raphael Hertzog wrote:
> Le jeudi 20 avril 2017, Cédric Krier a écrit :
> > qu'on génère. Pour cela, je recherche quelqu'un qui a une comptabilité
> > Française sur Tryton et qui pourrait tester avec les deux patches un
> > export FEC. Il y a un utilitaire de vérification fournis par la
> > direction générale des finances publiques qui ne fonctionne que sous
> > Windows:
> > http://www.economie.gouv.fr/dgfip/outil-test-des-fichiers-des-ecritures-comptables-fec
>
> Voici en pièce jointe le rapport que j'obtiens.
>
> Analyse des résultats:
>
> - Structure fichier incorrecte, débit/crédit ... renseignés sur une même
> ligne ... , ou débit=crédit=0 [33] fois dans le fichier
>
> => cela vient de la ligne générée pour les reports de soldes. Il faut donc
> couper en deux chaque ligne ou juste mettre la différence dans la bonne
> case, voire virer la ligne lorsque crédit=débit.

J'ai créé: https://bugs.tryton.org/issue6483

[Cédric Krier]

On 2017-05-02 10:12, Raphael Hertzog wrote:

> Le jeudi 20 avril 2017, Cédric Krier a écrit :
> > qu'on génère. Pour cela, je recherche quelqu'un qui a une comptabilité
> > Française sur Tryton et qui pourrait tester avec les deux patches un
> > export FEC. Il y a un utilitaire de vérification fournis par la
> > direction générale des finances publiques qui ne fonctionne que sous
> > Windows:
> > http://www.economie.gouv.fr/dgfip/outil-test-des-fichiers-des-ecritures-comptables-fec
>
> Voici en pièce jointe le rapport que j'obtiens.
>
> Analyse des résultats:
>

> - Le champ COMPTENUM est incorrect , le numéro de compte doit commencer
> par trois chiffres ; ... ... [33] fois dans le fichier
>
> => cela vient du compte 58 que j'utilise en intermédiaire pour les
> virements internes, il faut sûrement corriger le plan comptable
> pour que 58 ne soit pas utilisable directement qu'il ait un (ou
> plusieurs) sous-comptes dédiés. Je l'utilise pour des virements
> internes lorsqu'il y a des délais entre l'envoi et la réception
> de l'argent (genre PayPal -> Banque). Ou alors aussi pour le relevé
> de carte bancaire afin de pouvoir utiliser un relevé pour la carte
> et pour le compte bancaire (car il est impossible de partager une
> écriture entre deux relevés séparés à ma connaissance).

J'ai créé https://bugs.tryton.org/issue6485
J'ai vérifié et c'est le seul compte avec moins de 3 chiffres qui n'est
pas une vue.

[Cédric Krier]

On 2017-05-02 10:12, Raphael Hertzog wrote:

> Le jeudi 20 avril 2017, Cédric Krier a écrit :
> > qu'on génère. Pour cela, je recherche quelqu'un qui a une comptabilité
> > Française sur Tryton et qui pourrait tester avec les deux patches un
> > export FEC. Il y a un utilitaire de vérification fournis par la
> > direction générale des finances publiques qui ne fonctionne que sous
> > Windows:
> > http://www.economie.gouv.fr/dgfip/outil-test-des-fichiers-des-ecritures-comptables-fec
>
> Voici en pièce jointe le rapport que j'obtiens.
>
> Analyse des résultats:
>

> - Au moins un enregistrement dans le FEC ne contient pas de valeur pour le
> champ JOURNALCODE
>
> => créer un code automatique pour les journal sans code officiel ?
> (peut-être juste le numéro du journal)

Je propose d'utiliser le nom du journal s'il n'a pas de code.

> - Au moins un enregistrement dans le FEC ne contient pas de valeur pour le
> champ PIECEREF
>
> => remettre "EcritureNum" lors qu'on a rien à mettre en PieceRef? C'est le
> cas de toutes les mouvements comptables que je saisis manuellement
> (opérations diverse, charges saisies sans facture fournisseur, etc.)

Je propose de faire comme Odoo et de mettre '-'.

> - Au moins un enregistrement dans le FEC ne contient pas de valeur pour le
> champ ECRITURELIB

Idem.

> => la plupart des lignes correspondant à des entrées de relevé n'ont pas
> de libellé, peut-on mettre un libellé automatique du genre "Encaissement
> de X" ou "Paiement de Y" en fonction du signe et du nom du tiers ?

Ce ne sera presque plus le cas depuis https://bugs.tryton.org/issue6205

J'ai créé https://bugs.tryton.org/issue6486

[Richard PALO]

Le 20/04/2017 à 15:33, Cédric Krier a écrit :
> Bonjour,
>
> En corrigeant l'issue6435, j'ai remarqué que l'export FEC n'était pas
> tout à fait conforme. Du coup, j'ai créé l'issue6451.
> J'en ai profité pour ajouter un scenario de test pour l'export FEC mais
> j'aimerais quand même avoir une confirmation sur la validité du format
> qu'on génère. Pour cela, je recherche quelqu'un qui a une comptabilité
> Française sur Tryton et qui pourrait tester avec les deux patches un
> export FEC. Il y a un utilitaire de vérification fournis par la
> direction générale des finances publiques qui ne fonctionne que sous
> Windows:
> http://www.economie.gouv.fr/dgfip/outil-test-des-fichiers-des-ecritures-comptables-fec
>
>
> https://bugs.tryton.org/issue6435
> https://bugs.tryton.org/issue6451
>
> Merci,
>

Un environnement M$Windoze sous VirtualBOX semble tourner ce programme convenablement...
Toutefois, je n'arrive toujours pas générer un FEC si l'exercice
n'est pas clos (https://bugs.tryton.org/issue5306)

bien cordialement,
--

Richard PALO

[Camille]

Quelques réflexions sur les comptes :

1 - Le compte 58

Le mardi 2 mai 2017 10:12:55 UTC+2, Raphaël Hertzog a écrit :

=> cela vient du compte 58 que j'utilise en intermédiaire pour les

   virements internes (...) Je l'utilise pour des virements

   internes lorsqu'il y a des délais entre l'envoi et la réception
   de l'argent (genre PayPal -> Banque).

Perso j'utilise systématiquement le 58 pour toute opération de transfert entre deux comptes financiers.
Par exemple pour un retrait en espèce à un DAB, on génère 4 lignes d'écritures :
  2 dans le journal dédié au compte 512x banque
       débit du 58
       crédit du 512x
  2 dans le journal dédié à 531x caisse
       débit du 531x
       crédit du 58
C'est le seul moyen pour retrouver l'opération dans les deux journaux.

Je me permets de répondre à Dominique :
1 chiffre = classe
2 chiffres = sous-classe
3 chiffres = sous-sous-classe (si on peut dire...)

Concernant les comptes à deux chiffres, j'en connais 2 :
    36 "stocks provenant d'immobilisations"
         ex quand on "désosse" une immo corporelle pour récupération de matériel
         Doit être soldé en fin d'exercice (contrepartie 603 variation des stocks)
         Ca ne doit pas être utilisé très souvent dans une petite entreprise;
    58 virements internes
J'ai repéré aussi le 22 et le 25 dont je n'avais jamais entendu parlé...

Et tiens ! Je rajoute une question à 2 balles :
Pourquoi avoir choisi de présenter les sous-classes 61 et 62 comme subdivision de la sous-classe 61/62 ?
Elles sont présentées toutes les 3 au même niveau dans le plan comptable officiel (français en tout cas)
Dans l'esprit, dans une petite compta simple, on ne va utiliser que la 61/62 et y glisser
les 61x et 62x dont on a besoin.
Quand on est au point, on peut ensuite désactiver 61 et 62 pour alléger le plan comptable.
Reprenez-moi si je me trompe.

[Cédric Krier]

On 2017-06-02 23:47, Camille wrote:
> Pourquoi avoir choisi de présenter les sous-classes 61 et 62 comme
> subdivision de la sous-classe 61/62 ?

Ça vient du modèle de plan comptable qui a été utilisé. Il n'y a pas
vraiment de choix particulier.

[Dominique Chabord]

Le 3 juin 2017 à 08:47, Camille <cam.r...@gmail.com> a écrit :

>
> Je me permets de répondre à Dominique :
> 1 chiffre = classe
> 2 chiffres = sous-classe
> 3 chiffres = sous-sous-classe (si on peut dire...)

merci
en effet, en me reportant à http://brochures.sisalp.fr/pcg_maj0712.pdf
qui était notre document de base si je me souviens bien, je vois qu'on
ne parle plus de sous-classe et que "par extension" tout est compte.

[Camille]

Le samedi 3 juin 2017 10:13:57 UTC+2, Dominique Chabord a écrit :

je vois qu'on ne parle plus de sous-classe et que "par extension" tout est compte.

Je viens de voir ça aussi :)

[Richard PALO]

Pour info, il n'est plus vraiment nécessaire d'avoir un poste M$Windoze ni Vbox installé.

Après `git clone` de https://github.com/DGFiP/Test-Compta-Demat
il n'était pas trop compliqué pour faire tourner nativement sous *nix...

d'abord: assurer que tous les modules perl requis sont bien installés (SQlite, PDF:{API2,TABLE}, ...)

puis: cd Test-Compta-Demat; chmod +x src/testeur/trt_txt.pl; export PERL5LIB=$(realpath src/testeur)

finalement: perl src/testeur/init.pl

Cordialement,

--

Richard PALO

[Richard PALO]

Nous sommes arrivés à la conclusion, avec notre expert comptable, que le
programme Test-Compta-Demat se démontre plutôt "léger".

Nous avons été conseillé de voir chez Les Éditions Francis Lefebvre qui ont mis en place un site
> https://www.fec-expert.fr/

Le diagnostic est *gratuit* du FEC et une analyse approfondie du FEC est disponible mais payante, utilisant des "jetons"... cette analyse détaille les points de conformité et d'alerte, le détail des anomalies et une liasse fiscale théorique.

Le diagnostic présente les points de conformité, d'alerte et d'anomalie dans les tests suivants:
1 - Tests initiaux
2 - Test du format du fichier
3 - Test d’exhaustivité des écritures
4 - Test des reports à nouveau
5 - Test des journaux
6 - Test des écritures
7 - Test des dates
8 - Test des comptes et du plan comptable
9 - Test des comptes auxiliaires
10 - Test des enregistrements en doublon
11 - Test des Immobilisations et des Valeurs Nettes comptables
12 - Test des comptabilisations potentiellement à tort en charges
13 - Test de la permanence du chemin de révision
14 - Test des délais de paiement
15 - Test des paiements en espèce et des comptes de caisse
16 - Calcul des taux de change
17 - Calcul de la CVAE théorique
18.1 - TVA - Analyse des taux de TVA appliqués
18.2 - TVA - Analyse de la TVA appliquée par tiers
18.3 - TVA - Analyse de la TVA par libellés et par comptes mouvementés
18.4 - TVA - Analyse des soldes cumulés des comptes de TVA
19 - Liasse fiscale
20 - Documentation descriptive obligatoire


Voici un extrait bref et sélectif de quelques anomalies que nous avons rencontré:

1. Tests initiaux:
Présence de caractères spéciaux à supprimer

2. Test du format du fichier:
2 colonnes semblent avoir un libellé erroné
Présence de 3 cellule(s) contenant un caractère pouvant empêcher
l’administration fiscale d’analyser le FEC.
Présence de 9318 cellule(s) ne contenant que des espaces ou des caractères
spéciaux, contrairement à ce qui est normalement attendu par
l’administration fiscale.

6 - Test des écritures
Présence de 2269 écriture(s) pouvant ne pas avoir pour libellé
l’identification littérale du motif de l'écriture comptable.

7. Test des dates:
Le fichier n’est pas trié par date de validation.

Je précise que nous n'avons aucune prise d'intérêt avec EFL.

Nous avons tout simplement une édition récente toujours sous le coude de certains mémentos dont comptabilité et fiscal, comme beaucoup d'autres en France.

Nous avons encore pas mal du boulot pour valider la plateforme avant la mise en production tryton sous account_fr:-( J'espère vivement que nous ne sommes pas les seuls à effectuer ces vérifications et validations.

Cordialement,
--

Richard PALO

[Cédric Krier]

On 2018-09-21 09:05, Richard PALO wrote:
> Voici un extrait bref et sélectif de quelques anomalies que nous avons rencontré:

C'est bien dommage que ce soit bref, ça ne va pas trop aider à faire des
corrections.

> 1. Tests initiaux:
> Présence de caractères spéciaux à supprimer

Sans avoir la liste de caractères spéciaux non admis, je ne vois pas
comment on peut corriger.

> 2. Test du format du fichier:
> 2 colonnes semblent avoir un libellé erroné

Idem sans savoir quelle écriture, génère par quel document, il sera
impossible de corriger.

> Présence de 3 cellule(s) contenant un caractère pouvant empêcher
> l’administration fiscale d’analyser le FEC.

Idem

> Présence de 9318 cellule(s) ne contenant que des espaces ou des caractères
> spéciaux, contrairement à ce qui est normalement attendu par
> l’administration fiscale.

Il faudrait savoir quelles cellules et quelles caractères.

> 6 - Test des écritures
> Présence de 2269 écriture(s) pouvant ne pas avoir pour libellé
> l’identification littérale du motif de l'écriture comptable.

Quelle sont ces écritures? Comment ont-elles été générées ?

> 7. Test des dates:
> Le fichier n’est pas trié par date de validation.

Le fichier est trié par numéro de postage, ce qui me semble est la
demande au point II.40 de http://bofip.impots.gouv.fr/bofip/9028-PGP.html

« Au sein de ce fichier, les écritures doivent être numérotées
chronologiquement de manière croissante, sans rupture ni inversion dans
la séquence. »

Par contre normalement, l'ordre des numéro de postage devrait aussi être
l'ordre de la date de validation puisqu'il y a une séquence unique. Sauf
s'il y a eu manipulation.

[Richard PALO]

Le 21/09/2018 à 09:50, 'Cédric Krier' via tryton-fr a écrit :
> On 2018-09-21 09:05, Richard PALO wrote:
>> Voici un extrait bref et sélectif de quelques anomalies que nous avons rencontré:
>
> C'est bien dommage que ce soit bref, ça ne va pas trop aider à faire des
> corrections.
>

Ce message était principalement pour faire part de l'adresse du site.

Nous sommes en train de trier et traiter le détail afin de bien déterminer les anomalies et points d'alertes directement liés à la plateforme à mettre sur bugs.tryton.org.

Il n'y a rien qui bloque d'autres utilisateurs à effectuer des essais approfondis aussi...

--

Richard PALO

[Cédric Krier]

En fait si la numérotation de postage n'est pas « padded », trier par
'post_number' ne donne pas un ordre chronologique.
J'ai créé https://bugs.tryton.org/issue7719

[Richard PALO]

Voici un lien intéressant "Les logiciels de contrôle du FEC":
https://www.compta-online.com/les-logiciels-de-controle-du-fec-ao3498

notamment un autre site de contrôle gratuit:
> Veryfec.com : un logiciel qui complète l'outil de la DGFIP
>
> Ce logiciel de contrôle du FEC est proposé par l'association Fidepros, une association d'experts-comptables. S'il n'a pas vocation à remplacer le logiciel de l'administration fiscale, il le complète pour mettre en avant des anomalies ou points d'attention.
>
> L'utilisateur envoie son FEC sur le site internet et complète un formulaire pour affiner l'analyse.
>
> Seuls les résultats anonymes des contrôles sont conservés. Le FEC ainsi déposé sur le site internet est détruit dès la fin des tests.

--

Richard PALO

[Richard PALO]

Le 03/05/2017 à 11:06, Cédric Krier a écrit :
>> - Au moins un enregistrement dans le FEC ne contient pas de valeur pour le
>> champ PIECEREF
>>
>> => remettre "EcritureNum" lors qu'on a rien à mettre en PieceRef? C'est le
>> cas de toutes les mouvements comptables que je saisis manuellement
>> (opérations diverse, charges saisies sans facture fournisseur, etc.)
> Je propose de faire comme Odoo et de mettre '-'.
>

Selon expert-fec (lefebvre) d'utiliser le '-' génère un point d'anomalie :
> Colonne n°9 dénommée "PieceRef" (devant être au format AlphaNumérique et devant toujours être remplie, se reporter aux questions/réponses n°1-18) : détection de 9142 anomalies de format du contenu dont :
> - 9142 cellules (champs) ne contenant que des espaces ou des caractères spéciaux alors que cette colonne devrait toujours contenir des données (fichier .xls) (fichier .csv) (cette colonne ne peut ni être à blanc ni remplie de caractères ne correspondant pas à des données).
>
> Pour information :
> - Le champ dans le FEC "PieceRef" devrait contenir la référence de la pièce justificative et devrait correspondre soit à une numérotation séquentielle des pièces comptables dans le système, soit à la référence figurant sur les pièces justificatives (se reporter au BOI-CF-IOR-60-40-20 n°180)
> - Nombre de cellules remplies : 25483 (sur 25483, soit 100%)
> - Nombre de cellules vides ou sans données : 0 (sur 25483, soit 0%)
> - Liste des caractères de la colonne n°9 : " &-./0123456789ABCDEFHIJKLMNOPQRSTVW[]adehkortuvx"
> - Liste des valeurs utilisées dans cette colonne : "-", et cetera...

Peut-être un expert-comptable ou commissaire-aux-comptes pourrait nous suggérer une autre valeur...
En tout cas, apparemment cette valeur devrait probablement se trouver dans le fichier config, tout comme fec_opening_*

cordialement,
--

Richard PALO

[Nicolas Évrard]

* Richard PALO [2018-10-08 19:00:25]:

Je ne suis pas sûre d'avoir tout suivi mais comment le caractère '-'
peut être une anomalie alors que dans le même temps on nous dit:

> > - Liste des caractères de la colonne n°9 : " &-./0123456789ABCDEFHIJKLMNOPQRSTVW[]adehkortuvx"

où '-' apparaît bien.

(et soit dit en passant que le législateur définisse les caractères
qui peuvent composer la référence d'une pièce, c'est croquignolesque
comme on dit chez vous :D).

--
Nicolas Évrard - B2CK SPRL
E-mail/Jabber: nicolas...@b2ck.com

[Sebastien Marie]

On Tue, Oct 09, 2018 at 11:36:04AM +0200, 'Nicolas Évrard' via tryton-fr wrote:
> * Richard PALO [2018-10-08 19:00:25]:

À mon avis, il faut faire une différence entre:
- la législation française (texte de loi et décrêts) et son
interprétation par les services fiscaux (BOFIP, et autres commentaires
de l'administration)

- un logiciel spécifique de vérification, qui interpréte lui aussi les
éléments


Au niveau du BOFIP (BOI-CF-IOR-60-40-20 n°180):
http://bofip.impots.gouv.fr/bofip/9028-PGP.html?identifiant=BOI-CF-IOR-60-40-20-20170607#170_0383

La référence de la pièce justificative correspond soit à une

numérotation séquentielle des pièces comptables dans le système,
soit à la référence figurant sur les pièces justificatives

(factures, tickets, etc.) reçues ou émises.

Dans le cas des écritures pour lesquelles il n’existe pas de
référence de pièce (par exemple, dans le cas des écritures d’à
nouveau), ce champ doit néanmoins être rempli. Dans ce cas
précis, la référence sera alors remplacée par une valeur
conventionnelle définie par l’entreprise. Celle-ci sera
précisée dans le descriptif remis au vérificateur en même temps
que le fichier des écritures comptables

Les critères que je vois sont:
- la cellule ne DOIT pas être vide
- le format du contenu n'est pas spécifié

Il peut être légitime que l'outil de vérification de expert-fec force un
format particulier pour essayer de s'assurer que le champ comporte une
donnée "valide" ; mais il reste sujet à des faux-positifs: au regard du
BOFIP, il me semble valide d'avoir "-" comme PieceRef pour une écriture
d'à nouveau par exemple.

--
Sebastien Marie

[Cédric Krier]

Pour moi c'est du zèle de l'outil.
L'Article A47 A-1 [1] définit le champ PieceRef comme Alphanumérique et
précise dans XII 1° "Les caractères utilisés appartiennent à l'un des
jeux de caractères ASCII, norme ISO 8859-15 ou jeu de caractères
unicode, norme ISO/ CEI 10646, de type UTF-8 ;"
Il n'est jamais question d'autre validation de contenu.
Le XSD définit ce champs comme: <xs:element name="PieceRef" minOccurs="1" maxOccurs="1" type="xs:string"/>
Et comme a priori les deux formats doivent être équivalent.
De plus, je ne trouve nul part l'obligation de remplir ce champ.

Alors évidement c'est toujours mieux d'avoir des pièces justificatives
pour les mouvements mais dans la réalité c'est pas toujours le cas.


[1] http://www.legifrance.gouv.fr/affichCodeArticle.do;jsessionid=1D905278ED63729D4CDF44E8064D8160.tpdila07v_3?idArticle=LEGIARTI000027804775&cidTexte=LEGITEXT000006069583&categorieLien=id&dateTexte=20150610

--
Cédric Krier - B2CK SPRL
Email/Jabber: cedric...@b2ck.com

[Richard PALO]

Le 21/09/2018 à 09:50, 'Cédric Krier' via tryton-fr a écrit :
>> 7. Test des dates:
>> Le fichier n’est pas trié par date de validation.
> Le fichier est trié par numéro de postage, ce qui me semble est la

> demande au point II.40 dehttp://bofip.impots.gouv.fr/bofip/9028-PGP.html

>
> « Au sein de ce fichier, les écritures doivent être numérotées
> chronologiquement de manière croissante, sans rupture ni inversion dans
> la séquence. »
>
> Par contre normalement, l'ordre des numéro de postage devrait aussi être
> l'ordre de la date de validation puisqu'il y a une séquence unique. Sauf
> s'il y a eu manipulation.

J'ai encore pas mal d'erreurs ici...

selon https://www.impots.gouv.fr/portail/files/media/1_metier/2_professionnel/comptabilite_informatisee_question_reponse.pdf?#page=8&zoom=50
réponse Q12:
> En application du VII de l’article A. 47 A-1 du LPF et conformément au premier alinéa du I de
> l’article L. 47 A de ce livre, l’ensemble des données comptables et des écritures retracées
> dans tous les journaux comptables au titre d’un exercice est remis dans un fichier unique,
> dénommé fichier des écritures comptables, dans lequel les écritures sont classées par ordre
> chronologique de validation.

j'ai remarqué que le code:
> return Line.search(
> domain,
> order=[
> ('move.post_number', 'ASC'),
> ])
ne marche pas correctement au cas de changement de pré/post fixe et/ou la numérotation
ou bien dans le cas d'importation de la compta depuis un autre système (comme openerp)
où le post_number peut être par journal...

Ce qui semble mieux fonctionner pour tous ces cas là aussi:
> @@ -270,6 +270,7 @@ class AccountFrFEC(Wizard):
> return Line.search(
> domain,
> order=[
> + ('move.post_date', 'ASC'),
> ('move.post_number', 'ASC'),
> ])
>

cordialement,
--

Richard PALO