Émission de facture

Cette section décrit, du point de vue de l'utilisateur d'AOS, le processus d'émission d'une facture électronique vers une PA. Elle se concentre sur la mise en œuvre côté AOS : où trouver l'information sur la fiche facture, quels statuts spécifiques le sous-module attache à la facture, et comment déclencher et suivre l'envoi.

Panneau sur la facture

L'activation de l'application E-Invoicing ajoute, sur le formulaire de chaque facture, un panneau dédié intitulé « E-Invoicing ». Ce panneau centralise toutes les informations propres à la facturation électronique de la facture courante.

Panneau E-Invoicing sur le formulaire de la facture : statuts, adresses électroniques, identifiants PA et historique des flux.

Le panneau présente, dans l'ordre :

• Un bandeau de statut affichant deux badges côte à côte : le statut d'émission spécifique au sous-module (statusFeSelect) et le statut AFNOR du flux courant (currentFlow.statusSelect). Le second n'apparaît que lorsque la facture a déjà donné lieu à un cycle de vie côté PA.
• L'adresse électronique émettrice (senderElectronicAddress) et l'adresse électronique destinataire (receiverElectronicAddress), automatiquement renseignées.
• Les identifiants attribués par la PA après transmission, en lecture seule :
  • Identifiant de flux PA (pdpFlowId) — identifiant unique du flux côté plateforme, renseigné par la PA en retour de l'appel POST /flows.
  • Identifiant de suivi (pdpTrackingId) — identifiant transmis par le sous-module dans la requête, retourné par la PA et conservé pour la traçabilité.
• Le sous-panneau « Données électroniques additionnelles » (InvoiceElectronicData), affichant le type de facture, le périmètre (scopeSelect), le profil de facturation EN16931 retenu (profileIdSelect), ainsi que les indicateurs « multi-livraisons » et « multi-commandes ». Ces données sont calculées automatiquement à la ventilation.
• Le sous-panneau « Historique des statuts électroniques », contenant deux dashlets :
  • Invoice flows — flux d'émission liés à la facture (tous les flux à l'exception des CDAR), permettant de visualiser le XML envoyé et la réponse brute de la PA pour chaque tentative ;
  • Life cycle — flux CDAR liés à la facture (statuts AFNOR du cycle de vie : 200, 202, 203, 204, 205, etc.), affichés par ordre chronologique.

Le sous-module renseigne automatiquement les adresses électroniques de la facture en fonction du type d'opération :

• Pour une facture de vente ou un avoir client (operationTypeSelect = 3 ou 4) : la société est l'émetteur, le tiers est le destinataire. L'adresse émettrice est prise sur la société (depuis l'adresse électronique par défaut du company.partner), l'adresse destinataire sur le tiers (depuis son adresse électronique par défaut).
• Pour une facture d'achat ou un avoir fournisseur (operationTypeSelect = 1 ou 2) : le tiers est l'émetteur, la société est le destinataire. Les rôles sont inversés.

Ce calcul est déclenché à deux moments : au changement de société sur la facture, et au changement de tiers. Les champs senderElectronicAddress et receiverElectronicAddress restent éditables : l'utilisateur peut sélectionner une adresse différente si plusieurs adresses sont enregistrées sur le tiers ou sur la société. Le filtre de sélection garantit que seules les adresses du bon partenaire (tiers ou société selon le rôle) sont proposées.

Statut d'émission de facture

Le sous-module E-Invoicing introduit sur la facture un statut spécifique nommé statusFeSelect (FE pour Facture Électronique), distinct du statut comptable standard d'AOS (statusSelect : brouillon, validée, ventilée, etc.) et distinct également des statuts AFNOR portés par les flux. Ces trois axes de statut coexistent et apportent chacun une information différente :

• statusSelect — statut comptable AOS de la facture (brouillon, ventilée, etc.).
• statusFeSelect — statut d'émission AOS, propre au sous-module, qui suit la progression de la facture du point de vue de la chaîne d'émission interne.
• Flow.statusSelect — statut AFNOR du flux échangé avec la PA (déposée, mise à disposition, refusée, etc.), positionné sur l'objet Flux et reflété sur le badge currentFlow.statusSelect du panneau.

Code	Libellé technique	Libellé	Signification
0	NOT PROCESSED	Non traité	État initial. La facture n'a pas encore donné lieu à émission. Statut d'une facture nouvelle ou réinitialisée.
1	PENDING GENERATION	En attente de génération	Génération du fichier XML en attente
2	ANOMALY	En anomalie	Anomalie lors de la génération du fichier XML (par exemple : règle de mappage invalide, donnée obligatoire manquante)
3	GENERATED	Généré	Fichier XML généré et prêt à être transmis à la PA
4	SENT	Envoyé	Fichier XML transmis à la PA avec succès. La facture entre alors dans son cycle de vie AFNOR, dont les statuts successifs sont consultables sur les flux liés.
5	INADMISSIBLE	Irrecevable	La PA a rejeté techniquement le flux (codes d'erreur normalisés AFNOR, ou autres rejets techniques retournés par la PA). Une intervention administrateur est nécessaire pour corriger et ré-émettre.

Les transitions entre ces statuts sont automatiques et correspondent aux étapes de la chaîne d'émission décrites dans les sections suivantes.

Préparation : ventilation de la facture

La ventilation d'une facture déclenche, pour les factures de vente et les avoirs clients (operationTypeSelect = 3 ou 4), le calcul automatique des données électroniques additionnelles (InvoiceElectronicData). Ces données sont nécessaires pour produire un XML conforme aux exigences AFNOR et viennent compléter la facture sans intervention manuelle de l'utilisateur.

Sous-panneau « Données électroniques additionnelles » calculé automatiquement à la ventilation de la facture.

Le calcul est lancé au moment de la ventilation d'une facture, peu importe le contexte d'origine de cette action (bouton « ventiler » sur la facture, bouton « valider et ventiler » sur les commandes, ou autres méthodes).

Les champs calculés sur la facture, visibles dans le sous-panneau « Données électroniques additionnelles » du panneau E-Invoicing, sont :

• Type (typeSelect) — type de facture (facture commerciale, avoir, facture pro-forma, etc.).
• Périmètre (scopeSelect) — qualification du flux dans le cadre de la réforme (B2B, B2G, B2C, B2BInt, etc.). Conditionne notamment l'envoi de la facture en e-invoicing ou e-reporting. En cours de développement.
• Cadre de facturation (profileIdSelect) — qualification du cadre de facturation tel qu'attendu par la réforme (Dépôt d'une facture de bien, Dépôt d'une facture de prestation de service, etc.).
• Multi-livraisons (isMultiDeliveries) — indicateur indiquant si la facture porte sur plusieurs livraisons distinctes.
• Multi-commandes (isMultiOrders) — indicateur indiquant si la facture porte sur plusieurs commandes distinctes.

À l'issue de la ventilation, la facture est en statusSelect = 3 (Ventilée) et son statut FE reste à Non traité (0) tant que l'émission n'a pas été déclenchée.

Soumission initiale d'une facture

Une fois la facture ventilée et les adresses électroniques renseignées, l'émission est déclenchée manuellement par l'utilisateur depuis la fiche facture. Une alternative automatique en masse via le batch « Envoi des flux de factures » est également disponible.

Bouton « Transmettre la facture » sur la fiche facture pour déclencher l'émission vers la PA.

Au clic sur le bouton, en cas de soumission initiale (pdpFlowId vide), les étapes suivantes s'enchaînent :

1. Identification de la règle de routage d'émission. Le sous-module recherche, parmi les règles de routage de type EMISSION, celle rattachée à la société de la facture. L'ordre de récupération est par identifiant croissant — si plusieurs règles existent pour la même société, la plus ancienne est utilisée. Si aucune règle d'émission n'est trouvée pour la société, ou si la plateforme d'accès rattachée à la règle est absente, l'émission échoue avec un message d'erreur explicite. (Fonctionnalité prévue en prochaine version : En cas de plusieurs configurations disponibles pour une même société, il sera possible de sélectionner une parmi une liste prédéfinie affichée en pop-up.)

2. Génération du fichier XML. Le sous-module File Generator est sollicité pour produire le fichier XML structuré conforme au format défini par la règle de routage (Factur-X, UBL ou CII), selon le paramétrage File Generator rattaché à la règle d'émission. Un objet Flux est créé à l'issue de cette étape, avec le fichier XML attaché (outXmlFile). Si la génération échoue (anomalie de mappage, donnée obligatoire manquante, etc.), le statut FE de la facture passe à ANOMALY (2) et la transmission n'est pas effectuée. L'utilisateur consulte le message d'erreur et reprend la facture (correction des données ou ajustement du paramétrage File Generator).

3. Préparation du message à la PA. Le sous-module construit l'objet flowInfo qui accompagne le fichier dans la requête multipart vers la PA. Il contient :

   • L'identifiant de suivi (trackingId).
   • Le nom de fichier transmis.
   • La syntaxe du flux (Factur-X, UBL ou CII).

4. Transmission à la PA. Un appel POST /flows (multipart/form-data) est effectué vers la PA via la couche client PA. L'authentification est appliquée selon le mode configuré sur la plateforme (Clé d'API ou OAuth2). La requête comporte deux parties : la métadonnée JSON flowInfo et le fichier XML binaire.

5. Traitement de la réponse. Selon le code HTTP retourné par la PA, le sous-module met à jour le flux et la facture. Si la PA accepte la requête (HTTP 200, 201 ou 202), le sous-module renseigne le flux et le statut de la facture est mis à jour.

À partir de ce point, le suivi du cycle de vie de la facture relève des statuts AFNOR portés par les flux CDAR successifs (statuts 200, 202, 203, 204, etc.). Ces statuts sont remontés par le batch « Synchronisation du cycle de vie des flux ».

Si la PA retourne une erreur (rejet technique au dépôt, code d'erreur AFNOR), le sous-module qualifie l'erreur :

• L'acquittement technique du flux passe à ERROR (3), avec code et message d'erreur renseignés (ackErrorCode, ackErrorMessage).
• La réponse brute de la PA est archivée.
• Le statut FE de la facture passe à Irrecevable (5), que l'erreur soit un code d'irrecevabilité normalisé (IRR_*) ou un autre rejet technique.
• Le message d'erreur visible côté utilisateur est complété par une invite à une action administrateur (« correction nécessaire avant nouvelle tentative »).

Une exception est ensuite remontée à l'utilisateur pour signaler la situation. La facture reste alors visible avec son statut Irrecevable et la trace de la tentative (flux émis sans sentToPA = vrai, avec son fichier XML, sa réponse brute, son code d'erreur). L'utilisateur peut consulter l'historique des flux pour identifier la cause et reprendre la facture.

Ré-émission et reprise d'une facture

Deux mécanismes permettent de relancer une facture déjà soumise : la réémission (re-tentative après un premier envoi) et la réinitialisation (remise à zéro après un rejet technique).

Lorsque la facture a déjà fait l'objet d'une soumission antérieure (pdpFlowId renseigné) mais n'est pas au statut FE Envoyé (typiquement en Irrecevable après un échec, ou après une réinitialisation à Non traité), le bouton « Transmettre la facture » déclenche une ré-émission.

La ré-émission applique d'abord un contrôle de plafonnement du nombre de tentatives. Le sous-module compte le nombre de flux sortants déjà attachés à la facture, si le compteur atteint ou dépasse ce plafond, la ré-émission est refusée avec un message d'erreur indiquant le seuil dépassé. L'utilisateur doit alors recourir à la réinitialisation (Bouton Ré-initialiser à non traité, ci-dessous) et reprendre l'analyse du dossier au cas par cas.

Si le plafond n'est pas atteint, le sous-module attribue un nouvel identifiant de suivi à la facture puis relance le workflow standard de soumission.

Action « Ré-initialiser à non traité » dans le menu Outils de la fiche facture, disponible après un rejet technique.

Une action « Ré-initialiser à non traité » est exposée dans le menu Outils de la fiche facture. Elle n'est visible que lorsque la facture est en Irrecevable et que les autres conditions d'éligibilité à l'émission sont par ailleurs réunies.

À ce moment là, le statut FE de la facture est repassé à Non traité, les flux précédents restent attachés à la facture pour audit (ils ne sont pas supprimés) et la facture redevient éligible à une nouvelle soumission via le bouton « Transmettre la facture » — sous réserve que le plafond maxRetries ne soit pas déjà atteint sur la plateforme.

Cette action est destinée aux situations où le rejet technique nécessite une intervention de fond (correction d'une donnée structurante, ajustement d'un paramétrage File Generator, correction côté PA) avant de pouvoir reprendre le cycle d'émission. Elle ne s'utilise pas pour les rejets fonctionnels normalisés AFNOR (statut 213) qui appartiennent au cycle de vie de la facture et se gèrent par traitement des flux CDAR correspondants.

La synchronisation périodique des statuts de cycle de vie des factures déjà émises est assurée par le batch « Synchronisation du cycle de vie des flux ».