| Name | facturix JSON |
| Version |
1.0.8
JSON |
| download |
| home_page | None |
| Summary | None |
| upload_time | 2024-12-13 16:04:22 |
| maintainer | None |
| docs_url | None |
| author | Virgile |
| requires_python | <4.0,>=3.10 |
| license | GPLv3 |
| keywords |
|
| VCS |
|
| bugtrack_url |
|
| requirements |
No requirements were recorded.
|
| Travis-CI |
No Travis.
|
| coveralls test coverage |
No coveralls.
|
# Usage du script `facturix.py`
Ce script permet de générer des factures au format Factur-X à partir de fichiers PDF et d'un fichier CSV contenant les données des factures.
## Arguments et Options
### `-i` ou `--input_dir`
- **Description :** Obligatoire. Spécifie le dossier contenant les fichiers PDF des factures.
- **Exemple :** `-i /chemin/vers/dossier`
### `-c` ou `--input_csv`
- **Description :** Obligatoire. Spécifie le fichier CSV contenant les données des factures.
- **Exemple :** `-c /chemin/vers/fichier.csv`
### `-o` ou `--output_dir`
- **Description :** Obligatoire. Spécifie le dossier où les fichiers de sortie seront enregistrés.
- **Exemple :** `-o /chemin/vers/dossier_de_sortie`
### `-f` ou `--force_recalc`
- **Description :** Optionnel. Si spécifié, force le recalcul du CSV de lien facture-fichier.
- **Exemple :** `-f` (pour forcer le recalcul)
### `-v` ou `--verbose`
- **Description :** Optionnel. Augmente le niveau de verbosité. Peut être utilisé jusqu'à deux fois pour obtenir plus de détails dans les messages de sortie.
- **Exemple :** `-v` ou `-vv` (pour augmenter le niveau de verbosité)
## Exemple de commande
Pour exécuter le script avec les options ci-dessus, utilisez une commande comme celle-ci :
```sh
python facturix.py -i /chemin/vers/dossier -c /chemin/vers/fichier.csv -o /chemin/vers/dossier_de_sortie -f -v
```
## Fichier CSV d'entrée
Le tableau ci-dessous décrit les colonnes attendues dans le fichier CSV d'entrée. Chaque ligne du fichier CSV représente une facture et doit contenir les informations requises. Un PDf Factur-X sera généré pour chaque ligne du fichier CSV, si le pdf correspondant est trouvé dans le dossier d'entrée (aka il existe un pdf contenant le numéro de facture dans le fichier).
_BT = dénomination dd'une donnée métier dans la norme sémantique européenne_
| Numéro BT | Description |
|-----------|-------------|
| BT-23 | Process Chorus A1 (dépôt facture), A2 (dépôt facture déjà payée) |
| BT-24 | Identification de spécification : référence au format et profil utilisé (pas besoin pour l'instant)|
| BT-1 | numéro de facture |
| BT-3 | type de facture ex 380 : Facture commerciale|
| BT-2 | date d’émission de la facture |
| BT-10 | référence acheteur |
| BT-27 | nom (raison sociale) du fournisseur |
| BT-30 | identification légale du vendeur |
| BT-31 | numéro de TVA intracommunautaire |
| BT-47 | identification légale de l’acheteur |
| BT-44 | nom de l’acheteur (raison sociale) |
| BT-13 | numéro de commande fourni par l’acheteur |
| BT-5 | devise de la facture (toujours EUR)|
| BT-109 | montant HT |
| BT-110 | montant de la TVA où currencyID = BT-5 |
| BT-112 | montant TTC |
| BT-115 | montant net à payer |
Pour le détail des colones : se référer à la section **Description sémantique du Profil MINIMUM** plus bas dans ce readme.
## Résumé des étapes principales
1. **Lister les fichiers PDF d'entrée** :
- Balayage du dossier spécifié pour lister tous les fichiers PDF présents.
2. **Faire le lien données - PDF** :
- Extraction des numéros de facture des fichiers PDF.
- Fusion des informations extraites des PDF avec celles contenues dans le fichier CSV d'entrée.
3. **Génération des XML CII** :
- Production des fichiers XML à partir des données fusionnées, en utilisant un modèle XML.
4. **Validation des XML générés** :
- Validation des fichiers XML générés contre un fichier Schematron et un schéma XSD spécifique.
5. **Intégration des XML dans les PDF** :
- Incorporation des fichiers XML validés dans les fichiers PDF originaux pour produire des PDF conformes au standard Factur-X.
6. **Création des archives ZIP** :
- Archivage des fichiers PDF intégrés dans des fichiers ZIP en respectant des contraintes de nombre de fichiers et de taille maximale.
## Choix arbitraires réalisés
### Comment Peupler le xml
Je vois deux façons de peupler le xml :
- mettre des placeholder et les replace dans un str, facile
- mettre des id dans les balises du xml modèle, puis remplacer les valeurs des balises correspondantes, plus carré, mais plus lourd
| Critère | **Placeholders (Approche 1)** | **XPath (Approche 2)** |
|-------------------------|-----------------------------------------------------------------|---------------------------------------------------------------|
| **Facilité de mise en œuvre** | **Plus facile** : Simple recherche et remplacement des placeholders. | **Plus difficile** : Nécessite une compréhension d'XML et XPath. |
| **Maintenabilité** | **Faible** : Nécessite une gestion minutieuse des placeholders à mesure que l'XML grandit. | **Élevée** : Conscient de la structure et plus facile à adapter avec le temps. |
| **Précision** | **Faible** : Le remplacement de chaînes peut entraîner des erreurs. | **Élevée** : XPath garantit que les bons éléments sont mis à jour. |
| **Performance** | **Rapide pour les petits fichiers XML** : Basé sur des chaînes, plus rapide pour les tâches simples. | **Optimal pour les grands fichiers XML** : Peut gérer des fichiers complexes et volumineux de manière structurée. |
| **Robustesse** | **Faible** : Ne gère pas bien les changements de structure. | **Élevée** : Gère mieux les changements de structure en ciblant précisément les éléments. |
| **Flexibilité** | **Faible** : Limité à des remplacements simples. | **Élevée** : Peut manipuler des XML complexes. |
| **Professionnalisme** | **Basique** : Adapté aux cas d'utilisation plus simples. | **Plus professionnel** : Meilleur pour les projets complexes et à long terme. |
Je dirais dans un premier temps go easy !
Principe : On met des balises `{{BT-XX}}` dans notre `MINIMUM_template.xml`, on le parse avec _xmltree_ on le transforme en str, puis on fait un simple replace de la balise par la bonne valeur issue de la dataframe d'entrée
## Connaissances et sources
### Factur-x
Le format Factur-X est un standard hybride de facture électronique combinant un fichier PDF lisible et des données structurées au format XML. Il permet de faciliter l'automatisation du traitement des factures, tout en conservant une version visuelle pour la consultation humaine, conforme aux normes européennes de facturation électronique `EN16931`.
Le XML embarqué dans une facture Factur-X est toujours conforme au standard CII (Cross Industry Invoice) de l'UN/CEFACT.
https://fnfe-mpe.org/factur-x/
#### Que vaut https://github.com/akretion/factur-x ?
- **facturx-pdfgen**: generate a Factur-X or Order-X PDF file from a regular PDF file and an XML file
- **facturx-pdfextractxml**: extract the XML file from a Factur-X or Order-X PDF file
- **facturx-xmlcheck**: check a Factur-X or Order-X XML file against the official XML Schema Definition
Cette lib python est capable de générer le Factur-X à partir d'un pdf et d'un xml. Puis de vérifier que le résultat est conforme à la norme définie par xsd.
Reste donc à générer le xml.
### CII (Cross Industry Invoice)
Le CII (Cross Industry Invoice) est un schéma XML normé par l'UN/CEFACT qui permet de structurer des informations de facturation de manière détaillée et interopérable. Il inclut des éléments couvrant des données essentielles telles que les informations de l'acheteur et du vendeur, les articles facturés, les montants, les taxes, ainsi que des métadonnées spécifiques au processus de facturation. Le modèle CII est conçu pour être extensible, permettant l'ajout de champs spécifiques à certaines industries tout en garantissant la conformité avec les standards internationaux d'échange de données commerciales.
Comme il est extensible, il va probablement falloir un générateur de CII par plateforme de destination des factur-x.
### Plateforme Chorus
Chorus est l'ERP 100% dématérialisé de l'État. Il permet de gérer l'ensemble des processus de facturation et de paiement électroniques entre les administrations et leurs fournisseurs.
### Format factures
La doc chorus est fournie, mais il est difficile de trouver le xml le plus simple à embarquer.
#### E1 VS E2
source https://communaute.chorus-pro.gouv.fr/documentation/specifications-externes/ Annexe EDI page 18
**Flux structuré Facture (E1)** :
- Ce flux contient toutes les données de facturation au format structuré XML.
- Il est destiné aux systèmes comptables et financiers de l'État, des collectivités locales ou des établissements publics nationaux.
- Les données sont suffisamment détaillées pour permettre une gestion complète de la facture par les systèmes informatiques de l'administration.
- Il est recommandé pour les entreprises ayant un processus de facturation très structuré, capable de générer toutes les informations sous un format XML détaillé et adapté aux besoins des administrations .
**Flux mixte Facture (E2)** :
- Ce flux combine des données structurées et des pièces jointes non structurées (comme des fichiers PDF).
- Il transmet le lot minimal de données nécessaires au traitement de la facture, avec la possibilité d'ajouter des pièces jointes pour représenter la facture dans d'autres formats (hors PDF/A3).
- Il est recommandé pour les fournisseurs qui souhaitent utiliser à la fois des formats structurés et des pièces jointes non structurées, par exemple lorsque le système du fournisseur ne permet pas une structuration complète des données .
**En Gros, si on a la possibilité de tout mettre en XML, Il vaut mieux choisir E1.**
Dans notre cas, **E2 est le choix du moindre effort**, car on aura pas besoin **d'extraire les données des factures du PDF
#### Choix du format pour le flux E2
| Format | Bibliothèque/Lien | Commentaire | + | - |
| ---------------------------- | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- | ------------------------------- |
| UBL-Invoice | Rien de probant | International | International | pas de lib |
| CPP Factures Minimal | VIDE | Spécifique CHORUS | Format de Flower | pas de lib et spécifique chorus |
| Cross Industry Invoice (CII) | VIDE | Plus complexe | | pas de lib et complexe |
| Factur-X | [factur-x](https://github.com/akretion/factur-x) | Franco-German complies with the European e-invoicing standard [EN 16931](https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/Obtaining+a+copy+of+the+European+standard+on+eInvoicing). | déjà lib* + supporté par Odoo + doc détaillée | Franco-German |
_A première vue, je dirais que Factur-X est plus simple car il existe déjà une implémentation, il faudrait voir exactement ce qu'elle fait._
#### Description sémantique du Profil MINIMUM
Source : la documentation de la norme Factur-X _VERSION 1.0.06 (ZUGFeRD V2.2) – 1er Mars 2022_ disponible ici [https://fnfe-mpe.org/factur-x/](https://fnfe-mpe.org/factur-x/) contient un exemple de facture Factur-X avec le XML associé, et évoque son utilisation pour Chorus
L’ensemble des données du profil MINIMUM sont présentées ci-dessous :
- **BG-2** : groupe « Contrôle de Processus » : entête de message, **groupe Obligatoire** :
- **BT-23** : identification du business process utilisé, donnée _facultative_, permet d’indiquer quel cas métier est utilisé. Ceci peut servir par exemple pour ouvrir vers une facturation B2C où les règles de calcul ne sont pas les mêmes que pour une facture B2B.
- **BT-24** : Identification de spécification : référence au format et profil utilisé : donnée **Obligatoire**
- **BT-1** : numéro de facture, donnée **Obligatoire**
- **BT-2** : date d’émission de la facture, donnée **Obligatoire** (ainsi que le format de date)
- **BT-3** : type de facture (facture ou avoir), donnée **Obligatoire**, appartenant à la liste UNTDID 1001. Dans le cadre du profil MINIMUM, le code retenu peut être 751 (en particulier pour l’Allemagne) car le fichier de données ne comporte pas toutes les mentions obligatoires d’une facture, mais uniquement des données permettant sa comptabilisation. Il en résulte que les avoirs doivent être codifiés sous forme de factures négatives pour ce profil. Toutefois, pour la France, il est autorisé d’utiliser l’ensemble des codes disponibles (codes de facture et codes d’avoir).
- **BT-10** : référence acheteur fournie par l’acheteur, permettant d’adresser la facture vers le bon service de l’acheteur. C’est une donnée _facultative_, mais qui peut être exigée par l’acheteur. Pour le Secteur Public, cette donnée est **obligatoire** et correspond au « Service Exécutant ».
- **BT-13** : numéro de Commande fourni par l’acheteur. C’est une donnée _facultative_, mais qui peut être exigée par l’acheteur. Pour le Secteur Public, cette donnée est **obligatoire** et correspond à « l’Engagement Juridique ».
- **BG-4** : groupe de données relatives au vendeur : **groupe Obligatoire**
- **BT-27** : nom du fournisseur (dénomination légale sous laquelle le fournisseur est enregistré), donnée **Obligatoire**
- **BT-30** : identification légale du vendeur (n° de SIREN / SIRET), donnée **Obligatoire** si le vendeur n’a pas de Numéro de TVA intracommunautaire, fortement recommandé sinon. Cette donnée fait l’objet d’un attribut venant indiquer le référentiel de l’identification.
- **BT-31** : numéro de TVA intracommunautaire du vendeur, donnée **Obligatoire** si le vendeur dispose d’un N° de TVA intracommunautaire.
- **BG-5** : sous-groupe d’information sur l’adresse postale du Vendeur, **groupe Obligatoire**
- **BT-40** : code Pays du vendeur, donnée **Obligatoire** (qui permet d’identifier la territorialité de la facture)
- **BG-7** : groupe de données relatives à l’acheteur, **groupe Obligatoire**.
- **BT-44** : Nom de l’acheteur (raison sociale), donnée **Obligatoire**.
- **BT-47** : identification légale de l’acheteur (n° de SIREN / SIRET), donnée _facultative fortement recommandée_ car permettant d‘identifier le destinataire de façon plus fiable qu’un nom. Pour le Secteur Public, cette donnée est **obligatoire** et correspond au numéro de SIRET de l’entité facturée. Cette donnée fait l’objet d’un attribut venant indiquer le référentiel de l’identification (SIRET recommandé).
- **BT-5** : code de la devise de facturation, donnée **Obligatoire**
- **BG-22** : groupe des montants totaux de la facture (ou avoir), **bloc Obligatoire** :
- **BT-109** : montant Total HT de la facture (y compris remises et charges de pied de facture), donnée **Obligatoire**
- **BT-110** : montant Total de la TVA de la facture, donnée **Obligatoire** si la facture n’est pas hors champ d’application de la TVA. Ce montant s’accompagne d’un attribut précisant la monnaie de comptabilisation de la TVA.
- **BT-112** : montant Total TTC, donnée **Obligatoire**
- **BT-115** : montant Net à Payer de la facture, donnée **Obligatoire**
_Source : Factur-X 1.0.06
© FNFE-MPE | FeRD – droits réservés – 1er mars 2022
Pages 36 et 37 / 133_
Raw data
{
"_id": null,
"home_page": null,
"name": "facturix",
"maintainer": null,
"docs_url": null,
"requires_python": "<4.0,>=3.10",
"maintainer_email": null,
"keywords": null,
"author": "Virgile",
"author_email": "virgile.dauge@pm.me",
"download_url": "https://files.pythonhosted.org/packages/ba/8d/8ba5aa963535a10aa6391fb13fa99fac67d490067ecac83ad7280045e2a5/facturix-1.0.8.tar.gz",
"platform": null,
"description": "# Usage du script `facturix.py`\n\nCe script permet de g\u00e9n\u00e9rer des factures au format Factur-X \u00e0 partir de fichiers PDF et d'un fichier CSV contenant les donn\u00e9es des factures.\n\n## Arguments et Options\n\n### `-i` ou `--input_dir`\n\n- **Description :** Obligatoire. Sp\u00e9cifie le dossier contenant les fichiers PDF des factures.\n- **Exemple :** `-i /chemin/vers/dossier`\n\n### `-c` ou `--input_csv`\n\n- **Description :** Obligatoire. Sp\u00e9cifie le fichier CSV contenant les donn\u00e9es des factures.\n- **Exemple :** `-c /chemin/vers/fichier.csv`\n\n### `-o` ou `--output_dir`\n\n- **Description :** Obligatoire. Sp\u00e9cifie le dossier o\u00f9 les fichiers de sortie seront enregistr\u00e9s.\n- **Exemple :** `-o /chemin/vers/dossier_de_sortie`\n\n### `-f` ou `--force_recalc`\n\n- **Description :** Optionnel. Si sp\u00e9cifi\u00e9, force le recalcul du CSV de lien facture-fichier.\n- **Exemple :** `-f` (pour forcer le recalcul)\n\n### `-v` ou `--verbose`\n\n- **Description :** Optionnel. Augmente le niveau de verbosit\u00e9. Peut \u00eatre utilis\u00e9 jusqu'\u00e0 deux fois pour obtenir plus de d\u00e9tails dans les messages de sortie.\n- **Exemple :** `-v` ou `-vv` (pour augmenter le niveau de verbosit\u00e9)\n\n## Exemple de commande\n\nPour ex\u00e9cuter le script avec les options ci-dessus, utilisez une commande comme celle-ci :\n\n```sh\npython facturix.py -i /chemin/vers/dossier -c /chemin/vers/fichier.csv -o /chemin/vers/dossier_de_sortie -f -v\n```\n\n## Fichier CSV d'entr\u00e9e\n\nLe tableau ci-dessous d\u00e9crit les colonnes attendues dans le fichier CSV d'entr\u00e9e. Chaque ligne du fichier CSV repr\u00e9sente une facture et doit contenir les informations requises. Un PDf Factur-X sera g\u00e9n\u00e9r\u00e9 pour chaque ligne du fichier CSV, si le pdf correspondant est trouv\u00e9 dans le dossier d'entr\u00e9e (aka il existe un pdf contenant le num\u00e9ro de facture dans le fichier).\n_BT = d\u00e9nomination dd'une donn\u00e9e m\u00e9tier dans la norme s\u00e9mantique europ\u00e9enne_\n\n| Num\u00e9ro BT | Description |\n|-----------|-------------|\n| BT-23 | Process Chorus A1 (d\u00e9p\u00f4t facture), A2 (d\u00e9p\u00f4t facture d\u00e9j\u00e0 pay\u00e9e) |\n| BT-24 | Identification de sp\u00e9cification : r\u00e9f\u00e9rence au format et profil utilis\u00e9 (pas besoin pour l'instant)|\n| BT-1 | num\u00e9ro de facture |\n| BT-3 | type de facture ex 380 : Facture commerciale|\n| BT-2 | date d\u2019\u00e9mission de la facture |\n| BT-10 | r\u00e9f\u00e9rence acheteur |\n| BT-27 | nom (raison sociale) du fournisseur |\n| BT-30 | identification l\u00e9gale du vendeur |\n| BT-31 | num\u00e9ro de TVA intracommunautaire |\n| BT-47 | identification l\u00e9gale de l\u2019acheteur |\n| BT-44 | nom de l\u2019acheteur (raison sociale) |\n| BT-13 | num\u00e9ro de commande fourni par l\u2019acheteur |\n| BT-5 | devise de la facture (toujours EUR)|\n| BT-109 | montant HT |\n| BT-110 | montant de la TVA o\u00f9 currencyID = BT-5 |\n| BT-112 | montant TTC |\n| BT-115 | montant net \u00e0 payer |\n\nPour le d\u00e9tail des colones : se r\u00e9f\u00e9rer \u00e0 la section **Description s\u00e9mantique du Profil MINIMUM** plus bas dans ce readme.\n\n## R\u00e9sum\u00e9 des \u00e9tapes principales\n\n1. **Lister les fichiers PDF d'entr\u00e9e** :\n - Balayage du dossier sp\u00e9cifi\u00e9 pour lister tous les fichiers PDF pr\u00e9sents.\n\n2. **Faire le lien donn\u00e9es - PDF** :\n - Extraction des num\u00e9ros de facture des fichiers PDF.\n - Fusion des informations extraites des PDF avec celles contenues dans le fichier CSV d'entr\u00e9e.\n\n3. **G\u00e9n\u00e9ration des XML CII** :\n - Production des fichiers XML \u00e0 partir des donn\u00e9es fusionn\u00e9es, en utilisant un mod\u00e8le XML.\n\n4. **Validation des XML g\u00e9n\u00e9r\u00e9s** :\n - Validation des fichiers XML g\u00e9n\u00e9r\u00e9s contre un fichier Schematron et un sch\u00e9ma XSD sp\u00e9cifique.\n\n5. **Int\u00e9gration des XML dans les PDF** :\n - Incorporation des fichiers XML valid\u00e9s dans les fichiers PDF originaux pour produire des PDF conformes au standard Factur-X.\n\n6. **Cr\u00e9ation des archives ZIP** :\n - Archivage des fichiers PDF int\u00e9gr\u00e9s dans des fichiers ZIP en respectant des contraintes de nombre de fichiers et de taille maximale.\n\n## Choix arbitraires r\u00e9alis\u00e9s\n\n### Comment Peupler le xml\n\nJe vois deux fa\u00e7ons de peupler le xml :\n\n- mettre des placeholder et les replace dans un str, facile\n- mettre des id dans les balises du xml mod\u00e8le, puis remplacer les valeurs des balises correspondantes, plus carr\u00e9, mais plus lourd\n\n| Crit\u00e8re | **Placeholders (Approche 1)** | **XPath (Approche 2)** |\n|-------------------------|-----------------------------------------------------------------|---------------------------------------------------------------|\n| **Facilit\u00e9 de mise en \u0153uvre** | **Plus facile** : Simple recherche et remplacement des placeholders. | **Plus difficile** : N\u00e9cessite une compr\u00e9hension d'XML et XPath. |\n| **Maintenabilit\u00e9** | **Faible** : N\u00e9cessite une gestion minutieuse des placeholders \u00e0 mesure que l'XML grandit. | **\u00c9lev\u00e9e** : Conscient de la structure et plus facile \u00e0 adapter avec le temps. |\n| **Pr\u00e9cision** | **Faible** : Le remplacement de cha\u00eenes peut entra\u00eener des erreurs. | **\u00c9lev\u00e9e** : XPath garantit que les bons \u00e9l\u00e9ments sont mis \u00e0 jour. |\n| **Performance** | **Rapide pour les petits fichiers XML** : Bas\u00e9 sur des cha\u00eenes, plus rapide pour les t\u00e2ches simples. | **Optimal pour les grands fichiers XML** : Peut g\u00e9rer des fichiers complexes et volumineux de mani\u00e8re structur\u00e9e. |\n| **Robustesse** | **Faible** : Ne g\u00e8re pas bien les changements de structure. | **\u00c9lev\u00e9e** : G\u00e8re mieux les changements de structure en ciblant pr\u00e9cis\u00e9ment les \u00e9l\u00e9ments. |\n| **Flexibilit\u00e9** | **Faible** : Limit\u00e9 \u00e0 des remplacements simples. | **\u00c9lev\u00e9e** : Peut manipuler des XML complexes. |\n| **Professionnalisme** | **Basique** : Adapt\u00e9 aux cas d'utilisation plus simples. | **Plus professionnel** : Meilleur pour les projets complexes et \u00e0 long terme. |\n\nJe dirais dans un premier temps go easy !\n\nPrincipe : On met des balises `{{BT-XX}}` dans notre `MINIMUM_template.xml`, on le parse avec _xmltree_ on le transforme en str, puis on fait un simple replace de la balise par la bonne valeur issue de la dataframe d'entr\u00e9e\n\n## Connaissances et sources\n\n### Factur-x\n\nLe format Factur-X est un standard hybride de facture \u00e9lectronique combinant un fichier PDF lisible et des donn\u00e9es structur\u00e9es au format XML. Il permet de faciliter l'automatisation du traitement des factures, tout en conservant une version visuelle pour la consultation humaine, conforme aux normes europ\u00e9ennes de facturation \u00e9lectronique `EN16931`.\n\nLe XML embarqu\u00e9 dans une facture Factur-X est toujours conforme au standard CII (Cross Industry Invoice) de l'UN/CEFACT.\n\nhttps://fnfe-mpe.org/factur-x/\n\n#### Que vaut https://github.com/akretion/factur-x ?\n\n- **facturx-pdfgen**: generate a Factur-X or Order-X PDF file from a regular PDF file and an XML file\n- **facturx-pdfextractxml**: extract the XML file from a Factur-X or Order-X PDF file\n- **facturx-xmlcheck**: check a Factur-X or Order-X XML file against the official XML Schema Definition\n\nCette lib python est capable de g\u00e9n\u00e9rer le Factur-X \u00e0 partir d'un pdf et d'un xml. Puis de v\u00e9rifier que le r\u00e9sultat est conforme \u00e0 la norme d\u00e9finie par xsd.\n\nReste donc \u00e0 g\u00e9n\u00e9rer le xml.\n\n### CII (Cross Industry Invoice)\n\nLe CII (Cross Industry Invoice) est un sch\u00e9ma XML norm\u00e9 par l'UN/CEFACT qui permet de structurer des informations de facturation de mani\u00e8re d\u00e9taill\u00e9e et interop\u00e9rable. Il inclut des \u00e9l\u00e9ments couvrant des donn\u00e9es essentielles telles que les informations de l'acheteur et du vendeur, les articles factur\u00e9s, les montants, les taxes, ainsi que des m\u00e9tadonn\u00e9es sp\u00e9cifiques au processus de facturation. Le mod\u00e8le CII est con\u00e7u pour \u00eatre extensible, permettant l'ajout de champs sp\u00e9cifiques \u00e0 certaines industries tout en garantissant la conformit\u00e9 avec les standards internationaux d'\u00e9change de donn\u00e9es commerciales.\n\nComme il est extensible, il va probablement falloir un g\u00e9n\u00e9rateur de CII par plateforme de destination des factur-x.\n\n### Plateforme Chorus\n\nChorus est l'ERP 100% d\u00e9mat\u00e9rialis\u00e9 de l'\u00c9tat. Il permet de g\u00e9rer l'ensemble des processus de facturation et de paiement \u00e9lectroniques entre les administrations et leurs fournisseurs.\n\n\n### Format factures\n\nLa doc chorus est fournie, mais il est difficile de trouver le xml le plus simple \u00e0 embarquer.\n\n#### E1 VS E2\n\nsource https://communaute.chorus-pro.gouv.fr/documentation/specifications-externes/ Annexe EDI page 18\n**Flux structur\u00e9 Facture (E1)** :\n\n- Ce flux contient toutes les donn\u00e9es de facturation au format structur\u00e9 XML.\n- Il est destin\u00e9 aux syst\u00e8mes comptables et financiers de l'\u00c9tat, des collectivit\u00e9s locales ou des \u00e9tablissements publics nationaux.\n- Les donn\u00e9es sont suffisamment d\u00e9taill\u00e9es pour permettre une gestion compl\u00e8te de la facture par les syst\u00e8mes informatiques de l'administration.\n- Il est recommand\u00e9 pour les entreprises ayant un processus de facturation tr\u00e8s structur\u00e9, capable de g\u00e9n\u00e9rer toutes les informations sous un format XML d\u00e9taill\u00e9 et adapt\u00e9 aux besoins des administrations .\n\n**Flux mixte Facture (E2)** :\n\n- Ce flux combine des donn\u00e9es structur\u00e9es et des pi\u00e8ces jointes non structur\u00e9es (comme des fichiers PDF).\n- Il transmet le lot minimal de donn\u00e9es n\u00e9cessaires au traitement de la facture, avec la possibilit\u00e9 d'ajouter des pi\u00e8ces jointes pour repr\u00e9senter la facture dans d'autres formats (hors PDF/A3).\n- Il est recommand\u00e9 pour les fournisseurs qui souhaitent utiliser \u00e0 la fois des formats structur\u00e9s et des pi\u00e8ces jointes non structur\u00e9es, par exemple lorsque le syst\u00e8me du fournisseur ne permet pas une structuration compl\u00e8te des donn\u00e9es .\n\n**En Gros, si on a la possibilit\u00e9 de tout mettre en XML, Il vaut mieux choisir E1.**\n\nDans notre cas, **E2 est le choix du moindre effort**, car on aura pas besoin **d'extraire les donn\u00e9es des factures du PDF\n\n#### Choix du format pour le flux E2\n\n| Format | Biblioth\u00e8que/Lien | Commentaire | + | - |\n| ---------------------------- | ------------------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------- | ------------------------------- |\n| UBL-Invoice | Rien de probant | International | International | pas de lib |\n| CPP Factures Minimal | VIDE | Sp\u00e9cifique CHORUS | Format de Flower | pas de lib et sp\u00e9cifique chorus |\n| Cross Industry Invoice (CII) | VIDE | Plus complexe | | pas de lib et complexe |\n| Factur-X | [factur-x](https://github.com/akretion/factur-x) | Franco-German complies with the European e-invoicing standard\u00a0[EN 16931](https://ec.europa.eu/digital-building-blocks/wikis/display/DIGITAL/Obtaining+a+copy+of+the+European+standard+on+eInvoicing). | d\u00e9j\u00e0 lib* + support\u00e9 par Odoo + doc d\u00e9taill\u00e9e | Franco-German |\n\n_A premi\u00e8re vue, je dirais que Factur-X est plus simple car il existe d\u00e9j\u00e0 une impl\u00e9mentation, il faudrait voir exactement ce qu'elle fait._\n\n#### Description s\u00e9mantique du Profil MINIMUM\n\nSource : la documentation de la norme Factur-X _VERSION 1.0.06 (ZUGFeRD V2.2) \u2013 1er Mars 2022_ disponible ici [https://fnfe-mpe.org/factur-x/](https://fnfe-mpe.org/factur-x/) contient un exemple de facture Factur-X avec le XML associ\u00e9, et \u00e9voque son utilisation pour Chorus\nL\u2019ensemble des donn\u00e9es du profil MINIMUM sont pr\u00e9sent\u00e9es ci-dessous :\n\n- **BG-2** : groupe \u00ab Contr\u00f4le de Processus \u00bb : ent\u00eate de message, **groupe Obligatoire** :\n - **BT-23** : identification du business process utilis\u00e9, donn\u00e9e _facultative_, permet d\u2019indiquer quel cas m\u00e9tier est utilis\u00e9. Ceci peut servir par exemple pour ouvrir vers une facturation B2C o\u00f9 les r\u00e8gles de calcul ne sont pas les m\u00eames que pour une facture B2B.\n - **BT-24** : Identification de sp\u00e9cification : r\u00e9f\u00e9rence au format et profil utilis\u00e9 : donn\u00e9e **Obligatoire**\n- **BT-1** : num\u00e9ro de facture, donn\u00e9e **Obligatoire**\n- **BT-2** : date d\u2019\u00e9mission de la facture, donn\u00e9e **Obligatoire** (ainsi que le format de date)\n- **BT-3** : type de facture (facture ou avoir), donn\u00e9e **Obligatoire**, appartenant \u00e0 la liste UNTDID 1001. Dans le cadre du profil MINIMUM, le code retenu peut \u00eatre 751 (en particulier pour l\u2019Allemagne) car le fichier de donn\u00e9es ne comporte pas toutes les mentions obligatoires d\u2019une facture, mais uniquement des donn\u00e9es permettant sa comptabilisation. Il en r\u00e9sulte que les avoirs doivent \u00eatre codifi\u00e9s sous forme de factures n\u00e9gatives pour ce profil. Toutefois, pour la France, il est autoris\u00e9 d\u2019utiliser l\u2019ensemble des codes disponibles (codes de facture et codes d\u2019avoir).\n- **BT-10** : r\u00e9f\u00e9rence acheteur fournie par l\u2019acheteur, permettant d\u2019adresser la facture vers le bon service de l\u2019acheteur. C\u2019est une donn\u00e9e _facultative_, mais qui peut \u00eatre exig\u00e9e par l\u2019acheteur. Pour le Secteur Public, cette donn\u00e9e est **obligatoire** et correspond au \u00ab Service Ex\u00e9cutant \u00bb.\n- **BT-13** : num\u00e9ro de Commande fourni par l\u2019acheteur. C\u2019est une donn\u00e9e _facultative_, mais qui peut \u00eatre exig\u00e9e par l\u2019acheteur. Pour le Secteur Public, cette donn\u00e9e est **obligatoire** et correspond \u00e0 \u00ab l\u2019Engagement Juridique \u00bb.\n- **BG-4** : groupe de donn\u00e9es relatives au vendeur : **groupe Obligatoire**\n - **BT-27** : nom du fournisseur (d\u00e9nomination l\u00e9gale sous laquelle le fournisseur est enregistr\u00e9), donn\u00e9e **Obligatoire**\n - **BT-30** : identification l\u00e9gale du vendeur (n\u00b0 de SIREN / SIRET), donn\u00e9e **Obligatoire** si le vendeur n\u2019a pas de Num\u00e9ro de TVA intracommunautaire, fortement recommand\u00e9 sinon. Cette donn\u00e9e fait l\u2019objet d\u2019un attribut venant indiquer le r\u00e9f\u00e9rentiel de l\u2019identification.\n - **BT-31** : num\u00e9ro de TVA intracommunautaire du vendeur, donn\u00e9e **Obligatoire** si le vendeur dispose d\u2019un N\u00b0 de TVA intracommunautaire.\n - **BG-5** : sous-groupe d\u2019information sur l\u2019adresse postale du Vendeur, **groupe Obligatoire**\n - **BT-40** : code Pays du vendeur, donn\u00e9e **Obligatoire** (qui permet d\u2019identifier la territorialit\u00e9 de la facture)\n- **BG-7** : groupe de donn\u00e9es relatives \u00e0 l\u2019acheteur, **groupe Obligatoire**.\n - **BT-44** : Nom de l\u2019acheteur (raison sociale), donn\u00e9e **Obligatoire**.\n - **BT-47** : identification l\u00e9gale de l\u2019acheteur (n\u00b0 de SIREN / SIRET), donn\u00e9e _facultative fortement recommand\u00e9e_ car permettant d\u2018identifier le destinataire de fa\u00e7on plus fiable qu\u2019un nom. Pour le Secteur Public, cette donn\u00e9e est **obligatoire** et correspond au num\u00e9ro de SIRET de l\u2019entit\u00e9 factur\u00e9e. Cette donn\u00e9e fait l\u2019objet d\u2019un attribut venant indiquer le r\u00e9f\u00e9rentiel de l\u2019identification (SIRET recommand\u00e9).\n- **BT-5** : code de la devise de facturation, donn\u00e9e **Obligatoire**\n- **BG-22** : groupe des montants totaux de la facture (ou avoir), **bloc Obligatoire** :\n - **BT-109** : montant Total HT de la facture (y compris remises et charges de pied de facture), donn\u00e9e **Obligatoire**\n - **BT-110** : montant Total de la TVA de la facture, donn\u00e9e **Obligatoire** si la facture n\u2019est pas hors champ d\u2019application de la TVA. Ce montant s\u2019accompagne d\u2019un attribut pr\u00e9cisant la monnaie de comptabilisation de la TVA.\n - **BT-112** : montant Total TTC, donn\u00e9e **Obligatoire**\n - **BT-115** : montant Net \u00e0 Payer de la facture, donn\u00e9e **Obligatoire**\n\n_Source : Factur-X 1.0.06 \n\u00a9 FNFE-MPE | FeRD \u2013 droits r\u00e9serv\u00e9s \u2013 1er mars 2022 \nPages 36 et 37 / 133_\n",
"bugtrack_url": null,
"license": "GPLv3",
"summary": null,
"version": "1.0.8",
"project_urls": null,
"split_keywords": [],
"urls": [
{
"comment_text": "",
"digests": {
"blake2b_256": "0dcb7495343a0ccb89d03c12839960158db663dfde55fc16fc2feecbf1cce98e",
"md5": "bcc8666c8be47143532650bfe2578e59",
"sha256": "91d40fed8c60c26edb69453c0bffde571a330b0470c7d80bf8395f13828ea1e4"
},
"downloads": -1,
"filename": "facturix-1.0.8-py3-none-any.whl",
"has_sig": false,
"md5_digest": "bcc8666c8be47143532650bfe2578e59",
"packagetype": "bdist_wheel",
"python_version": "py3",
"requires_python": "<4.0,>=3.10",
"size": 94793,
"upload_time": "2024-12-13T16:04:21",
"upload_time_iso_8601": "2024-12-13T16:04:21.335193Z",
"url": "https://files.pythonhosted.org/packages/0d/cb/7495343a0ccb89d03c12839960158db663dfde55fc16fc2feecbf1cce98e/facturix-1.0.8-py3-none-any.whl",
"yanked": false,
"yanked_reason": null
},
{
"comment_text": "",
"digests": {
"blake2b_256": "ba8d8ba5aa963535a10aa6391fb13fa99fac67d490067ecac83ad7280045e2a5",
"md5": "daa0ad709e9d4de030ead768068e914c",
"sha256": "92ea90d1e2115202cb64262a4e0641e2ebe2027c153d931c17516274c3553753"
},
"downloads": -1,
"filename": "facturix-1.0.8.tar.gz",
"has_sig": false,
"md5_digest": "daa0ad709e9d4de030ead768068e914c",
"packagetype": "sdist",
"python_version": "source",
"requires_python": "<4.0,>=3.10",
"size": 93484,
"upload_time": "2024-12-13T16:04:22",
"upload_time_iso_8601": "2024-12-13T16:04:22.753187Z",
"url": "https://files.pythonhosted.org/packages/ba/8d/8ba5aa963535a10aa6391fb13fa99fac67d490067ecac83ad7280045e2a5/facturix-1.0.8.tar.gz",
"yanked": false,
"yanked_reason": null
}
],
"upload_time": "2024-12-13 16:04:22",
"github": false,
"gitlab": false,
"bitbucket": false,
"codeberg": false,
"lcname": "facturix"
}
