France¶

FEC - Fichier des Écritures Comptables¶

Un fichier d’audit FEC Fichier des écritures comptables reprend l’ensemble des données et écritures comptables enregistrées dans tous les journaux comptables pendant’un exercice. Les écritures du fichier doivent être classées par ordre chronologique.

Depuis le 1er janvier 2014, chaque entreprise française est tenue de produire et de transmettre ce fichier à la demande de l’administration fiscale à des fins d’audit.

Import FEC¶

Pour faciliter l’intégration des nouveaux utilisateurs, le package de localisation fiscale française d’Odoo Enterprise inclut la fonctionnalité Import FEC (nom du module : l10n_fr_fec_import), qui permet d’importer des fichiers FEC existants à partir d’anciens logiciels.

Pour activer cette fonctionnalité, allez à Comptabilité ‣ Configuration ‣ Paramètres ‣ Import comptable, activez Import FEC et Enregistrez.

Ensuite, allez Comptabilité ‣ Configuration ‣ Import FEC, chargez votre fichier FEC et cliquez sur Importer.

Note

L’importation de fichiers FEC d’une année différente ne nécessite aucune action ou calcul particulier.

Si plusieurs fichiers contiennent des « Reports à Nouveau » (RAN) avec le solde initial de l’exercice, il se peut que vous deviez annuler ces écritures dans l’interface utilisateur. Odoo rend ces écritures (RAN) inutiles.

Formats de fichier¶

Les fichiers FEC ne peuvent être qu’au format CSV, car le format XML n’est pas pris en charge.

Note

Le fichier FEC CSV a un format de texte brut représentant une table de données, la première ligne étant un en-tête définissant la liste des champs pour chaque entrée, et chaque ligne suivante représentant une écriture comptable, sans ordre prédéterminé.

Notre module s’attend à ce que les fichiers répondes aux exigences techniques suivantes :

Encodage : UTF-8, UTF-8-SIG et iso8859_15.
Séparateur : l’un des séparateurs suivants : ; ou | ou , ou TAB.
Fins de ligne : les groupes de caractères CR+LF (\r\n) et LF (\n) sont tous deux pris en charge.
Format de date : %Y%m%d

Description et utilisation des champs¶

#	Nom du champ	Description	Usage	Format
01	JournalCode	Code du journal	`journal.code` et `journal.name` si `JournalLib` n’est pas fourni	Alphanumérique
02	JournalLib	Etiquette de Journal	`journal.name`	Alphanumérique
03	EcritureNum	Numérotation propre à chaque numéro d’ordre du journal de l’écriture	`move.name`	Alphanumérique
04	EcritureDate	Date d’écriture comptable	`move.date`	Date (aaaaMMjj)
05	CompteNum	Numéro de compte	`account.code`	Alphanumérique
06	CompteLib	Libellé du compte	`account.name`	Alphanumérique
07	CompAuxNum	Numéro du compte secondaire (peut être vide)	`partner.ref`	Alphanumérique
08	CompAuxLib	Libellé du compte secondaire (peut être vide)	`partner.name`	Alphanumérique
09	PieceRef	Référence du document	`move.ref` et `move.name` si `EcritureNum` n’est pas fourni	Alphanumérique
10	PieceDate	Date du document	`move.date`	Date (aaaaMMjj)
11	EcritureLib	Libellé de l’écriture comptable	`move_line.name`	Alphanumérique
12	Débit	Montant Débit	`move_line.debit`	Flottant
13	Crédit	Montant du crédit (le nom de champ « Crédit » n’est pas autorisé)	`move_line.credit`	Flottant
14	EcritureLet	Référence croisée de l’écriture comptable (peut être vide)	`move_line.fec_matching_number`	Alphanumérique
15	DateLet	Date de l’écriture comptable (peut être vide)	non utilisé	Date (aaaaMMjj)
16	ValidDate	Date de validation de l’écriture comptable	non utilisé	Date (aaaaMMjj)
17	Montantdevise	Montant en devise (peut être vide)	`move_line.amount_currency`	Flottant
18	Idevise	Identifiant de la devise (peut être vide)	`currency.name`	Alphanumérique

Ces deux champs se retrouvent à la place des autres dans le sens ci-dessus.

12	Montant	Montant	`move_line.debit` ou `move_line.credit`	Flottant
13	Sens	« C » pour Crédit ou « D » pour Débit	détermine `move_line.debit` ou `move_line.credit`	Caractère

Détails d’implémentation¶

Les entités comptables suivantes sont importées des fichiers FEC : Comptes, Journaux, Partenaires, et Mouvements.

Notre module détermine l’encodage, le caractère de fin de ligne et le séparateur utilisés dans le fichier.

Une vérification est ensuite effectuée pour voir si chaque ligne a le bon nombre de champs en fonction de l’en-tête.

Si la vérification est positive, le fichier est lu dans son intégralité, conservé en mémoire et analysé. Les entités comptables sont importées par type, dans l’ordre suivant.

Comptes¶

Chaque écriture comptable est liée à un compte, qui doit être déterminé par le champ CompteNum.

Correspondance des codes¶

Si un code de compte similaire existe déjà dans le système, le code existant est utilisé au lieu d’un créer un nouveau.

Les comptes dans Odoo ont généralement un nombre de chiffres qui sont par défaut pour la localisation fiscale. Puisque le module FEC est lié à la localisation française, le nombre de chiffres pertinents par défaut est de 6.

Cela signifie que les zéros de fin de code sont coupés à droite et que la comparaison entre les codes de compte dans le fichier FEC et ceux qui existent déjà dans Odoo s’effectue uniquement sur les six premiers chiffres des codes.

Example

Le code de compte 65800000 dans le fichier est mis en correspondance avec le compte 658000 existant dans Odoo et ce compte est utilisé au lieu d’en créer un nouveau.

Indicateur de lettrage¶

Un compte est techniquement marqué comme “compabile” si la première ligne dans laquelle il apparaît a le champ EcritureLet complété, car cet indicateur signifie que l’écriture comptable sera mise en correspondance avec une autre.

Note

Si ce champ de la ligne n’est pas complété, mais l’écriture doit toujours être lettrée avec un paiement qui n’a pas encore été enregistré, ce n’est pas un problème ; le compte est marqué comme compatible dès que l’importation des lignes d’écriture l’exige.

Correspondance entre le type de compte et les modèles¶

Comme le type de compte n’est pas précisé dans le format FEC, les nouveaux comptes sont créés avec le type par défaut Actif circulant et ensuite, à la fin du processus d’import, ils sont mis en correspondance avec les modèles de plan comptable installés. L’indicateur de lettrage est également calculé de cette manière.

La correspondance se fait avec les chiffres les plus à gauche, en commençant par tous les chiffres, puis 3, puis 2.

Example

Nom	Code	Comparaison complète	Comparaison à 3 chiffres	Comparaison à 2 chiffres
Modèle	`400000`	`400000`	`400`	`40`
CompteNum	`40100000`	`40100000`	`401`	`40`
Résultat				Correspondance trouvée

Le type de compte est ensuite marqué comme à payer et à lettrer selon le modèle de compte.

Journaux¶

Les journaux sont également comparés à ceux qui existent déjà dans Odoo pour éviter des doublons, y compris dans le cas d’imports multiples de fichiers FEC.

Si un code de journal similaire existe déjà dans le système, le code existant est utilisé au lieu d’en créer un nouveau.

Les nouveaux journaux se voient attribuer un préfixe FEC-.

Example

ACHATS -> FEC-ACHATS

Les journaux ne sont pas archivés et l’utilisateur est autorisé à les traiter comme il le souhaite.

Détermination du type de journal¶

Le type de journal n’est pas non plus précisé dans le format (comme pour les comptes) et il est donc créé avec le type général par défaut.

À la fin du processus d’import, le type est déterminé selon ces règles concernant les écritures et les comptes liés :

banque : Les écritures dans ces journaux ont toujours une ligne (débit ou crédit) affectant un compte de liquidité.

espèces / banque peuvent être interchangés, donc banque est défini partout lorsque cette condition est remplie.
vente : Les écritures dans ces journaux ont principalement des lignes de débit sur les comptes clients et des lignes de crédit sur les comptes des impôts sur les revenus.

Le débit/crédit est inversé pour les écritures comptables de remboursement.
achat : Les écritures dans ces journaux ont principalement des lignes de crédit sur des comptes fournisseurs et des lignes de débit sur des comptes des charges.

Le débit/crédit est inversé pour les écritures comptables de remboursement d’achats.
général : pour tout le reste.

Note

Un minimum de trois écritures est nécessaire pour pouvoir identifier le type de journal.
Un seuil de 70% des écritures doit correspondre à un critère pour qu’un type de journal soit déterminé.

Example

Disons que nous analysons les écritures qui partagent un certain journal_id.

Mouvements	Comptage	Pourcentage
qui ont une ligne de compte de vente et pas de ligne de compte d’achat	0	0
qui ont une ligne de compte d’achat et pas de ligne de compte de vente	1	25%
qui ont une ligne de compte de liquidité	3	75%
Total	4	100%

Le type de journal serait banque, parce que le pourcentage des écritures bancaires (75%) dépasse le seuil (70%).

Partenaires¶

Chaque partenaire conserve sa Référence du champ CompAuxNum.

Note

Ces champs sont consultables, conformément aux anciens imports FEC du côté de l’expert comptable à des fins fiscales/d’audit.

Astuce

Les utilisateurs peuvent fusionner des partenaires à l’aide de l’application de nettoyage des données, où les fournisseurs et les clients ou des entrées de partenaires similaires peuvent être fusionnés avec l’utilisateur, avec l’aide du système qui les regroupe par entrées similaires.

Mouvements¶

Les écritures sont immédiatement comptabilisées et lettrées après leur soumission, en utilisant le champ EcritureLet pour effectuer la correspondance entre les écritures elles-mêmes.

Le champ EcritureNum représente le nom des écritures. Nous avons remarqué qu’il arrive parfois qu’il ne soit pas rempli. Dans ce cas, le champ PieceRef est utilisé.

Problèmes d’arrondi¶

Il existe une tolérance d’arrondi avec une précision liée à la devise sur le débit et le crédit (par ex. 0.01 pour EUR). En dessous de cette tolérance, une nouvelle ligne est ajoutée à l’écriture, intitulée Différence d’arrondi à l’import, ciblant les comptes :

658000 Charges diverses de gestion courante, pour les débits ajoutés
758000 Produits divers de gestion courante, pour les crédits ajoutés

Nom d’écriture manquant¶

Si le champ EcritureNum n’est pas complété, il se peut que le champ PieceRef ne permette pas de déterminer le nom de l’écriture (il peut être utilisé comme référence de la ligne de l’écriture), ce qui ne permet pas de savoir quelles lignes doivent être regroupées en une seule écriture et empêche la création d’écritures équilibrées.

Une dernière tentative est faite en regroupant toutes les lignes du même journal et de la même date (JournalLib, EcritureDate). Si ce regroupement génère des écritures équilibrées (somme(crédit) - somme(débit) = 0), chaque combinaison différente de journal et de date crée une nouvelle écriture.

Example

ACH + 2021/05/01 –> nouvelle écriture dans le journal ACH avec le nom 20210501.

Si cette tentative échoue, l’utilisateur reçoit un message d’erreur avec toutes les lignes d’écriture qu sont supposées être déséquilibrées.

Informations relatives au partenaire¶

Si les informations relatives au partenaire sont précisées sur une ligne, elles sont copiées dans l’écriture comptable elle-même si le Journal ciblé est de type créditeur ou débiteur.

Exporter¶

Si vous avez installé le package de localisation fiscale française, vous êtes en mesure de télécharger le FEC. Pour ce faire, allez à Comptabilité ‣ Analyse ‣ France ‣ FEC.

Astuce

Si vous ne voyez pas le sous-menu FEC, allez aux Apps, supprimez le filtre Apps, puis recherchez le module intitulé France-FEC et assurez-vous qu’il est installé.

Pour plus d'infos

Rapports comptables français¶

Si vous avez installé la comptabilité française, vous aurez accès à certains rapports comptables spécifiques à la France:

Bilan comptable
Compte de résultats
Plan de Taxes France

Se conformer à la législation anti-fraude à la TVA avec Odoo¶

Depuis 1er janvier 2018, une nouvelle législation anti-fraude est d’application en France Métropolitaine et dans les DOM-TOM. Cette nouvelle législation impose l’utilisation par les entreprises concernées d’un logiciel de caisse respectant des critères d’inaltérabilité, de sécurité, de stockage et d’archivage des données de vente. Ces exigences légales sont implémentées dans Odoo, de la version 9 aux plus récentes, via un module additionnel à installer et une attestation de conformité individuelle à télécharger.

Mon entreprise est-elle tenue d’utiliser un logiciel anti-fraude ?¶

Votre entreprise est tenue d’utiliser un logiciel de caisse anti-fraude comme Odoo (CGI article 286, I. 3 ° bis) si:

Vous êtes assujetti à la TVA et n’êtes pas concerné par le régime de franchise de la TVA,
Certains de vos clients sont des particuliers (B2C).

Cette règle s’applique à toute taille d’entreprise. Les auto-entrepreneurs sont exemptés de la TVA et ne sont donc pas affectés.

Se conformer à la législation¶

Se conformer à cette nouvelle législation est très facile.

Your company is requested by the tax administration to deliver a certificate of conformity testifying that your software complies with the anti-fraud legislation. This certificate is granted by Odoo SA to Odoo Enterprise users here. If you use Odoo Community, you should upgrade to Odoo Enterprise or contact your Odoo service provider.

En cas de non-conformité, votre entreprise risque une amende de 7500€.

Pour obtenir la certification, suivez les étapes suivantes :

Si vous utilisez l’applicatino Point de Vente d’Odoo, installez le module France - Certification anti-fraude à la TVA pour Point de Vente (CGI 286 I-3 bis) en allant aux Apps, supprimant le filtre Apps, recherchant l10n_fr_pos_cert, et en installant le module.
Assurez-vous qu’un pays est bien défini sur votre société, sinon vos entrées ne seront pas cryptées pour la vérification de l’inaltérabilité. Pour modifier les données de votre société, allez dans Configuration ‣ Utilisateurs & Sociétés ‣ Sociétés. Sélectionnez un pays parmis la liste; Ne créez pas un nouveau pays.
Téléchargez votre attestation de conformité délivrée par SA ici.

Note

Pour installer le module dans n’importe quel système créé avant le 18 décembre 2017, vous devez mettre à jour la liste des modules. Pour cela, activez le mode développeur. Allez ensuite dans le menu Applications et appuyez sur Mettre à jour la liste des modules dans le menu supérieur.
Si vous utilisez Odoo hébergé sur serveur propre, vous devez mettre à jour votre installation Odoo et redémarrer votre serveur.
Dans le cas où vous auriez installé la version initiale du module anti-fraude (avant le 18 décembre 2017), you devez mettre à jour ce dernier. Le nom initial du module était France - Accounting - Certified CGI 286 I-3 bis. Après avoir mis à jour la liste des modules, sélectionnez le nouveau module dans le menu Applications et cliquez sur le bouton Mettre à jour. Enfin, vérifiez que le module l10n_fr_sale_closing est installé.

Fonctionnalités anti-fraude¶

Le module anti-fraude introduit les fonctionnalités suivantes:

Inaltérabilité: désactivation de toutes les méthodes d’annulation ou de modification des données clés des commandes de PdV, factures et entrées comptables.
Sécurité: algorithme de chainage pour vérifier l’inaltérabilié;
Stockage: clôtures de ventes automatiques avec calculs des totaux périodiques et cumulatifs (journaliers, mensuels, annuels).

Inaltérabilité¶

Toutes les possibilités d’annuler ou modifier les données clés des commandes de Point de Vente payés, factures confirmées ou entrées comptables sont désactivées, si la société est localisée en France ou dans les DOM-TOM.

Note

Si vous utilisez un environnement multi-sociétés, seuls les documents des sociétés françaises ou DOM-TOM sont cryptés.

Sécurité¶

Pour garantir l’inaltérabilité, chaque commande ou pièce comptable est chiffrée à la validation. Ce numéro (ou hachage) est calculé à partir des données clés du document et à partir du hachage des documents précédents.

Le module permet à l’utilisateur ou le contrôleur fiscal de vérifier l’inaltérabilité des données. Si une information clé est modfiée sur un document après sa validation, le test échoue automatiquement. L’algorithme recalcule toutes les clés de cryptage et les compare avec les clés initiales. En cas de différence, le système fournit la référence du premier document corrompu.

Les utilisateurs qui bénéficient de droits d’accès de type Gestionnaire peuvent lancer le test d’inaltérabilité. Pour les commandes de PdV, allez dans Point de Vente ‣ Rapports ‣ Déclarations françaises. Pour les factures et entrées comptables, allez dans Facturation ‣ Rapports ‣ Déclarations françaises.

Stockage¶

Le système procède aussi à des clôtures de ventes automatiques de façon journalière, mensuelle et annuelle. Ces clôtures calculent de façon distincte le total de ventes d’une période ainsi que le grands total cumulatif depuis la première entrée enregistrée dans le système.

Les clôtures sont accessibles depuis le menu Déclarations françaises des modules Point de Vente et Facturation.

Note

Les clôtures calculent les totaux des entrées comptables des journaux de ventes (Type de Journal = Ventes).
Dans les environnements multi-sociétés, les clôtures sont effectuées par société.
Les commandes de PdV sont comptabilisées dans les pièces comptables à la clôture de la session de PdV. Clôturer une session de PdV peut être fait à tout moment. Pour inciter l’utilisateur à le faire de façon journalière et ainsi permettre le calcul journalier des totaux de ventes, le module empêche de reprendre une session de vente ouverte depuis plus de 24 heures. Une telle session doit être clôturée pour pouvoir vendre à nouveau.
Le total de la période est calculé à partir de toutes les entrées comptables comptabilisées après la précédente clôture du même type (journalier, mensuel, annuel), quelque soit la date de comptabilisation.

Astuce

À des fins de test et d’audit, ces clôtures peuvent être générées manuellement en mode développeur.
Ensuite, allez aux Paramètres ‣ Technique ‣ Automatisation ‣ Actions planifiées.

Responsabilités¶

Ne désinstallez pas le module! Les numéros de cryptage seraient supprimés et toutes les données précedemment enregistrées ne seraient plus considérées comme étant inaltérées.

Les administrateurs de système sont responsables de leur instance Odoo et doivent l’utiliser et le configurer en bon père de famille. Il n’est pas autorisé de modifier le code source qui guarantit l’inaltérabilité des données.

Odoo SA se décharge de toute responsabilité en cas d’altération des fonctionnalités anti-fraude par des modules tiers non certifiés par Odoo SA.

Plus d’informations¶

Vous trouverez plus d’informations relatives à cette législation dans les documents officiels suivants.

Pour plus d'infos

Edit on GitHub