Implémenter FPF dans votre logiciel
Un scan, et vous tenez l'identité de facturation de l'acheteur, structurée. Sans intégration, sans compte, sans contrat, et sans dépendre de FacturPass.
Pourquoi vous
La réforme oblige votre logiciel à porter l'identité de facturation de l'acheteur sur les ventes entre professionnels, y compris au comptant, sans lui donner le moyen de la saisir — le dernier mètre.
Lire un pass FPF est la façon la moins coûteuse de combler ce trou : du décodage local, sans appel réseau, sans habilitation à demander et sans partenariat à signer.
Ce que vous récupérez
| Champ FPF | Contenu | Usage dans la facture |
|---|---|---|
legal.name | raison sociale | nom de l'acheteur (BT-44) |
legal.ids[] | identifiants d'immatriculation, chacun qualifié par son schéma | identifiant légal de l'acheteur (BT-47) et son schéma (BT-47-1) |
…[].scheme | code ICD à 4 chiffres — même registre qu'einvoice.eas | en France : 0002 = SIREN, 0009 = SIRET |
…[].value | l'identifiant, toujours une chaîne | la valeur reportée sur la facture |
legal.vat | TVA intracommunautaire | identifiant TVA de l'acheteur (BT-48) |
einvoice.eas | code de schéma EAS | schéma de l'adresse électronique |
einvoice.address | identifiant d'adressage | la maille que l'acheteur a choisie |
contact.buyerReference | référence interne de l'acheteur | référence acheteur (BT-10) |
billing.* | adresse postale | adresse de facturation de l'acheteur |
Ce que ça coûte
Décoder tient en cinq gestes : détacher le préfixe de version, décoder le base64url,
décompresser en deflate-raw quand le préfixe est 2.,
analyser le JSON, valider.
// JavaScript
const payload = new URL(scanned).hash.slice(1); // "2.7VNNb…"
const doc = await decode(payload); // fpf.js, ~50 lignes
const errors = validate(doc);
// C#
var payload = new Uri(scanned).Fragment.TrimStart('#');
var doc = FpfCodec.Decode(payload);
Cinq implémentations de référence — JavaScript, Rust, C#, Pascal, Java — et un jeu de vecteurs de test partagé sont publiés dans le dépôt du format. Rien ne vous oblige à les utiliser : le format tient en une page.
Les pièges qui coûtent cher
Un identifiant est une chaîne, jamais un nombre
Un encodeur écrit à la main émet volontiers
"value": 73282932000074 au lieu de
"value": "73282932000074". Le document devient invalide, et un lecteur
naïf qui appelle une méthode de chaîne dessus plante au lieu de le signaler. Tous les
identifiants de FPF sont des chaînes, y compris ceux qui n'ont l'air que de chiffres —
un SIRET commençant par un zéro le perdrait, de toute façon.
Ne découpez jamais l'identifiant d'adressage sur « _ »
Le tiret bas est à la fois le séparateur et un caractère autorisé à l'intérieur d'un code de routage ou d'un suffixe. Un découpage naïf est donc faux. L'algorithme correct : les neuf premiers caractères sont le SIREN ; si le segment suivant fait quatorze chiffres et commence par ce SIREN, c'est un SIRET et tout le reste est le code de routage ; sinon tout le reste est un suffixe.
Tout préfixe autre que 1. ou 2. est une erreur
Ce n'est pas un cas à rattraper : refusez le payload plutôt que de deviner.
Le matricule de la plateforme n'est pas transporté
Il change dès que l'entreprise change de plateforme. C'est à la plateforme réceptrice de le résoudre à partir de l'identifiant d'adressage — c'est sa fonction.
Vous êtes une plateforme agréée
Trois rôles vous sont ouverts, indépendants les uns des autres.
- Émettre. Vous êtes la seule à connaître la maille exacte de chacun de vos clients, puisque c'est vous qui alimentez l'annuaire. Délivrer à chaque client un pass prêt à présenter est un service à coût quasi nul.
- Recevoir. Accepter un payload FPF en entrée de votre API de dépôt évite à vos clients éditeurs de remapper les champs eux-mêmes.
- Déclarer. Dire publiquement que vous acceptez le format lève le doute pour tous les éditeurs qui vous sont raccordés.
FPF, BT-49 et le cas français
FPF modélise l'adressage à la manière de BT-49 dans la norme EN 16931 : un code de schéma EAS et une adresse. Le flux 1 de la réforme française n'utilise pas BT-49 — l'adressage domestique passe par l'identifiant d'adressage de l'annuaire, et l'acheteur y est identifié par son SIREN qualifié 0002.
En pratique : en domestique, lisez einvoice.address comme
l'identifiant d'adressage de l'annuaire, avec eas à
0225 ; à l'international, eas et address
forment bien un BT-49 au sens de la norme.
Cette lecture s'appuie sur l'examen du flux 1 des spécifications externes. Le flux 2 n'en fait pas partie et pourrait porter BT-49. Si vous constatez le contraire, ouvrez une issue : la spécification sera corrigée.
Trois choses à faire maintenant
- Tester votre implémentation — collez ce que votre code produit ou lit, le validateur dit ce qui ne va pas.
- Déclarer votre compatibilité — sur l'honneur, dans le dépôt du format.
- Prendre le kit — spécification, schémas JSON, profil France, vecteurs de test, implémentations de référence.