Incident de facturation : contenir, rapprocher et reprendre
Une réponse opérationnelle aux échecs Peppol, résultats incertains, pannes d'intégration, risques de doublon et anomalies de preuve.
- Mis à jour
- Responsable du contenu
- Exploitation du service
- Pour
- Équipes de service · Opérations financières · Support intégration
L’essentiel
Contenez le flux touché, distinguez les refus des résultats incertains et rapprochez les transactions avant la reprise.
Avant de commencer
- Un pilote d'incident et un décideur financier
- L'accès aux identités source, documents et erreurs
- Des contacts internes et fournisseur à jour
Résultats attendus
- Un inventaire rapproché des transactions affectées
- Une reprise évitant doublons et réémissions ambiguës
- Un dossier de cause, impact, preuves et actions
Sur cette page
Un incident de facturation affecte recettes, relations clients et preuves comptables même si le site fonctionne. Identifiez son impact concret : entités touchées, transactions, montants, documents et possibilité qu'une opération ait déjà réussi.
Les niveaux de gravité, délais et contacts doivent venir de votre organisation et du contrat réel. Ce guide propose une méthode ; il ne fixe pas de délai de support.
Nommer le pilote et cadrer l'impact
Un pilote maintient chronologie et décisions ; un responsable finance décide des corrections commerciales. L'intégration diagnostique les erreurs techniques. Le fournisseur du point d'accès rapproche les résultats réseau lorsque nécessaire. Les communications clients passent par le responsable et le canal convenus.
| Rôle | Responsabilité |
|---|---|
| Pilote d'incident | Périmètre, coordination, chronologie et reprise |
| Responsable finance | Dette, avoirs, remboursements et impact client |
| Responsable intégration | Suspension ciblée, recherche et nouvelles tentatives |
| Responsable exploitation | File manuelle et suivi quotidien |
| Support fournisseur | Confirmation de réception ou rejet réseau |
Le dossier indique société, flux, première observation avec fuseau, nombre affecté, montants par devise, source et conséquence. « Peppol en panne » ne décrit pas correctement un seul destinataire inaccessible.
Contenir et préserver les preuves
Suspendez la file ou l'émetteur affecté dans votre système d'exploitation. Préservez transactions et identités stables. Limitez la suspension à l'entité ou au type connu. Ne supprimez pas les factures numérotées et ne changez pas les identifiants pour répondre à un délai dépassé.
Conservez numéro, identifiant produit, external_id, espace d'intégration, identifiant document Peppol, dernier état, code et réponse expurgée. Excluez clés et données personnelles inutiles des tickets. Gardez XML/PDF originaux et instantanés de transmission disponibles.
Si une clé est réellement exposée, son propriétaire autorisé organise révocation ou rotation et modification du connecteur. Distinguez cette situation d'une permission manquante ou d'une clé expirée.
Classer chaque transaction
- Refus explicite avant acceptation : correction des champs, permissions ou prérequis indiqués par le code.
- Écriture financière potentiellement créée : recherche par identité externe après réponse perdue, sans nouvelle identité de facture.
- Transmission incertaine :
transmission_state: uncertainouPEPPOL_TRANSMISSION_UNCERTAINnécessite rapprochement fournisseur ou mise à jour signée avant réémission. - Livrée puis contestée : décision commerciale, distincte du transport.
- Preuve inaccessible ou altérée : conservation du refus et escalade de restitution ; un fichier reconstruit n'est pas l'original.
OpenPeppol sépare accusés transport et réponses métier. Un message livré peut donc être contesté pour son prix ; un échec réseau ne prouve pas qu'il faut émettre une note de crédit.
Reprendre à partir d'un inventaire
Construisez un tableau avec identité source, identifiant produit, résultat créé/absent/inconnu, livraison, action et responsable. Cherchez les créations incertaines avec /api/v1/invoices/lookup?external_id=... et les paiements avec leur route de recherche. Conservez espace d'intégration et contenu original.
Une opération récupérable doit être rejouée à l'identique avec ses identités. Une transmission ambiguë reste bloquée. Si un envoi connu comme rejeté peut être retenté, utilisez le document et les octets émis d'origine. Un contenu commercial modifié exige une décision finance de correction.
Exemple : interruption de lot
Un lot de 50 factures s'arrête après 30 demandes : 28 réponses réussies, deux réponses perdues et 20 demandes non exécutées. La recherche retrouve les deux factures persistées. L'une est livrée, l'autre a une transmission incertaine.
Les 20 transactions non exécutées reprennent avec leurs identités prévues. La facture livrée ne repart pas. L'incertaine attend la preuve fournisseur. Deux nouvelles factures de remplacement auraient créé une dette et un chiffre d'affaires en double.
Vérifier la reprise et remettre le service
Rapprochez populations, montants, règlements et livraison séparément. Exécutez un petit lot contrôlé puis récupérez ses documents. Documentez les gestes manuels pendant l'arrêt pour que l'automatisation ne les répète pas.
La restauration du fournisseur ne suffit pas à déclarer le backlog résolu. Chaque transaction affectée doit être expliquée ou attribuée à un responsable de cas résiduel. Conservez cause, période d'impact, correction, preuves et amélioration avec échéance.
La reprise de responsabilité indique position de file, envois incertains restants, litiges clients et prochain contrôle. Mettez à jour la fiabilité des intégrations et les critères du déploiement lorsque la cause peut se répéter.
Vérifiez aussi les gestes manuels avec la trésorerie avant de réactiver leur synchronisation automatique.