---
title: "Migration vers le module communautaire einvoicing"
weight: 90
description: "Comment passer du module Facturx au module officiel einvoicing porté par la communauté Dolibarr, et ce qui est conservé ou à reprendre."
---

# Migration vers le module communautaire einvoicing

## Pourquoi cette page

Le code du module **Facturx** a été donné à la communauté Dolibarr. Il a servi de point de départ à un module officiel, maintenu par l'association et ses contributeurs, publié sous le nom **einvoicing** (anciennement `pdpconnectfr`).

Cette page explique comment passer de Facturx à `einvoicing` proprement, ce qui est conservé automatiquement et ce que vous devez reprendre à la main.

Le module `einvoicing` se télécharge ici :

- Dolistore : <https://www.dolistore.com/product.php?id=3309>
- Code source : <https://github.com/Dolibarr/dolibarr-community-modules> (dossier `einvoicing`)

> **À retenir :** la bascule se fait dans cet ordre : on installe et on **active** d'abord `einvoicing`, puis on lance le **transfert des données** depuis l'onglet Migration de Facturx (les deux modules sont alors actifs en même temps, le temps du transfert seulement), et enfin on **désactive** Facturx. Pendant la courte fenêtre où les deux modules sont actifs, ne générez et n'envoyez aucune facture : ils se branchent tous les deux sur la génération du PDF.

## Ce que fait chaque module

Les deux modules ne couvrent pas exactement le même périmètre. C'est important à comprendre avant de migrer.

| | Facturx (ce module) | einvoicing (communautaire) |
|---|---|---|
| Métadonnées Factur-X / CII dans le PDF | Oui (coeur du module) | Oui (protocole FacturX) |
| Champs Chorus Pro sur la facture | Oui | Oui (mêmes champs) |
| Connexion à un point d'accès (SuperPDP) | Oui, connecteur léger | Oui, connecteur complet |
| Réception des factures fournisseurs | Oui, via file d'import | Oui, via tables dédiées (flux, cycle de vie) |
| Routage des tiers (identifiant PDP) | Champ `peppol_id` sur le tiers | Table de routage dédiée (plusieurs identifiants par tiers) |
| Suivi du cycle de vie des factures | Limité | Détaillé (statuts, messages, historique) |
| Autres plateformes (ESALINK, etc.) | Non | Oui |

En résumé : `einvoicing` est plus ambitieux et plus complet côté plateforme agréée (PA/PDP). Facturx reste centré sur la génération du PDF Factur-X et une connexion SuperPDP simple.

## Ce qui est conservé automatiquement

Bonne nouvelle : les données **Chorus Pro** saisies sur vos factures sont conservées telles quelles. Les deux modules utilisent exactement les mêmes champs complémentaires (mêmes noms techniques), donc aucune donnée n'est perdue lors du basculement :

- Service exécutant (code service Chorus)
- Numéro d'engagement / de marché
- Code d'engagement
- Identifiant Chorus de la facture

Côté einvoicing, ces champs sont pilotés par l'option **EINVOICING_USE_CHORUS**. Pensez à l'activer si vous utilisez Chorus Pro, sinon les champs restent masqués (les données, elles, restent en base).

## Ce que vous devez reprendre à la main

Certaines informations propres à Facturx n'ont pas d'équivalent direct dans einvoicing, ou sont stockées différemment. Le point 1 (identifiants PDP des tiers) est **automatisé** par l'onglet Migration ; les points 2 à 4 restent à reprendre manuellement.

### 1. Identifiant PDP des tiers

Dans Facturx, l'identifiant de routage d'un tiers (SIREN, identifiant Peppol...) est stocké dans le champ complémentaire **`peppol_id`** sur la fiche tiers car le module FacturX est iso-compatible sur ces champs avec le module Peppol édité également par CAP-REL.

Dans einvoicing, cette information passe dans une **table de routage dédiée** (`llx_einvoicing_routing`), qui permet plusieurs identifiants par tiers, un identifiant par défaut, une source (manuelle / automatique / synchronisation), etc.

Ce transfert est **automatisé** par l'onglet Migration du module Facturx (voir la procédure ci-dessous) : il lit le `peppol_id` de chaque tiers et crée l'entrée de routage correspondante dans einvoicing. L'opération est sans risque et rejouable (un identifiant déjà présent est ignoré, aucune donnée Facturx n'est modifiée). Elle suppose qu'einvoicing soit déjà installé et activé, pour que sa table de routage existe.

### 2. Configuration du point d'accès (SuperPDP)

La connexion SuperPDP existe dans les deux modules, mais la configuration n'est pas transférée : les clés, jetons OAuth et paramètres sont stockés sous des noms de constantes différents (`FACTURX_AP_*` côté Facturx, `EINVOICING_SUPERPDP_*` côté einvoicing).

Il faut donc **reconnecter SuperPDP depuis la configuration d'einvoicing** (reprise du couple client / secret, nouvelle autorisation OAuth). Ce n'est pas un simple renommage de variables : refaites l'étape de connexion depuis l'écran de configuration du module communautaire.

### 3. Champs Factur-X spécifiques

Ces champs de Facturx n'ont pas d'équivalent repris automatiquement :

- **Référence de commande acheteur** (`fx_buyer_order_ref`)
- **Cible Chorus** (`fx_chorus_target`)
- **Tiers payeur** (`facturx_payer_id`, utile en profil EXTENDED / CTC-FR)
- **Exonération de TVA Peppol** (`peppol_vat_exemption`) et son dictionnaire de codes

Si vous les utilisez, notez leurs valeurs avant migration. Selon les versions d'einvoicing, la gestion du tiers payeur et de l'exonération de TVA peut être traitée autrement (directement dans le protocole d'émission).

### 4. Factures fournisseurs en cours d'import

Facturx stocke les imports en attente dans sa propre file (`llx_facturx_apimport`). einvoicing utilise ses propres tables (`llx_einvoicing_document`, `llx_einvoicing_call`).

Avant de basculer, **traitez ou videz la file d'import de Facturx** (validez ou rejetez les factures fournisseurs en attente). Ce qui reste dans la file Facturx ne sera pas repris par einvoicing.

## Procédure de migration recommandée

Faites ces opérations en dehors des heures de production, après une **sauvegarde complète** (base + documents).

1. **Sauvegarde** de la base de données et du répertoire des documents.
2. **Notez votre configuration Facturx** : profil Factur-X utilisé, paramètres SuperPDP, options Chorus. Une copie d'écran de chaque page de configuration suffit. L'onglet Migration de Facturx affiche aussi un état des lieux (nombre de tiers à transférer, imports en attente, etc.).
3. **Traitez la file d'import** des factures fournisseurs de Facturx (rien en attente).
4. **Installez et activez le module einvoicing.** C'est ce qui crée sa table de routage, nécessaire au transfert de l'étape suivante.
5. **Lancez le transfert des données** : dans Facturx, allez dans Configuration - onglet **Migration einvoicing**, puis cliquez sur **Transférer les identifiants de routage vers einvoicing**. Les identifiants PDP (`peppol_id`) de vos tiers sont recopiés dans le routage d'einvoicing. L'opération est rejouable sans risque de doublon.
6. **Désactivez le module Facturx** (Accueil - Configuration - Modules). Ne le désinstallez pas tout de suite : tant qu'il est seulement désactivé, ses champs et ses données restent en base, ce qui vous laisse une porte de sortie.
7. **Finalisez la configuration d'einvoicing** :
   - **Activez l'option Chorus** (`EINVOICING_USE_CHORUS`) si vous utilisez Chorus Pro. Vérifiez que les champs Chorus de vos factures sont bien remplis (ils doivent l'être, mêmes champs).
   - **Reconnectez SuperPDP** depuis la configuration d'einvoicing.
   - **Vérifiez le routage** des tiers transférés à l'étape 5.
8. **Testez** sur une facture : génération du PDF Factur-X, envoi de test vers le point d'accès, réception. Ne désinstallez Facturx qu'une fois ces tests concluants.

## Tableau de correspondance des données

| Donnée Facturx | Emplacement Facturx | Emplacement einvoicing | Reprise |
|---|---|---|---|
| Code service Chorus | `d4d_service_code` (facture) | `d4d_service_code` (facture) | Automatique |
| Numéro d'engagement / marché | `d4d_contract_number` (facture) | `d4d_contract_number` (facture) | Automatique |
| Code d'engagement | `d4d_promise_code` (facture) | `d4d_promise_code` (facture) | Automatique |
| Identifiant Chorus facture | `d4d_chorus_id` (facture) | `d4d_chorus_id` (facture) | Automatique |
| Identifiant PDP du tiers | `peppol_id` (tiers) | table `llx_einvoicing_routing` | Automatisée (onglet Migration) |
| Identifiant document au point d'accès | `facturx_id` (facture) | table `llx_einvoicing_document` | Non repris (recréé à l'usage) |
| Référence commande acheteur | `fx_buyer_order_ref` (facture) | pas d'équivalent direct | Manuelle si nécessaire |
| Cible Chorus | `fx_chorus_target` (facture) | pas d'équivalent direct | Manuelle si nécessaire |
| Tiers payeur | `facturx_payer_id` (facture) | géré par le protocole d'émission | À vérifier selon version |
| Exonération TVA Peppol | `peppol_vat_exemption` + dictionnaire | pas d'équivalent direct | Manuelle si nécessaire |
| Configuration SuperPDP | constantes `FACTURX_AP_*` | constantes `EINVOICING_SUPERPDP_*` | Reconnexion manuelle |
| File d'import fournisseurs | `llx_facturx_apimport` | `llx_einvoicing_document` / `call` | À vider avant migration |

## Questions fréquentes

**Puis-je garder les deux modules actifs en parallèle ?**
Seulement le temps du transfert (étapes 4 à 6). Les deux ajoutent les mêmes champs Chorus et interceptent tous les deux la génération du PDF de facture : pendant cette courte fenêtre, ne générez et n'envoyez aucune facture. Une fois le transfert fait, désactivez Facturx et gardez-le **désactivé mais installé** comme filet de sécurité ; ne le désinstallez qu'après validation.

**Vais-je perdre mes anciennes factures Factur-X déjà générées ?**
Non. Les PDF déjà produits (avec métadonnées Factur-X intégrées) restent dans vos documents. La migration ne concerne que la génération des futures factures et la configuration.

**Les données Chorus de mes factures existantes seront-elles visibles dans einvoicing ?**
Oui, car ce sont les mêmes champs techniques. Activez seulement l'option Chorus d'einvoicing pour les afficher.

**Où télécharger le module einvoicing ?**
Il est publié par la communauté Dolibarr sur le Dolistore : <https://www.dolistore.com/product.php?id=3309>. Son code source est hébergé sur <https://github.com/Dolibarr/dolibarr-community-modules>, dans le dossier `einvoicing`. Référez-vous à ces deux sources pour la version recommandée sur votre version de Dolibarr.

**CAP-REL assure le SAV du module communautaire ?**
Bien sûr, tout comme toutes les fonctionnalités de dolibarr CAP-REL assure le SAV et peut vous accompagner, assurez-vous simplement d'avoir un contrat de maintenance actif ou <a href="https://shop.cap-rel.fr/cat/product/SAV">quelques heures de service prépayé</a>.
