Module einvoicing communautaire einvoicing

Précondition : plateforme configurée, tâche planifiée activée, flux en attente côté plateforme.

Étapes :

1. Lancer la tâche depuis l'interface des tâches planifiées.
2. Consulter le compte rendu d'exécution.
3. Consulter les documents créés ou mis à jour.

Attendu :

• La tâche s'exécute sans erreur fatale, les classes nécessaires étant bien chargées même hors contexte web.
• Les flux entrants sont importés et les statuts des documents émis sont mis à jour.
• Le compte rendu affiché dans l'interface résume ce qui a été fait.
• Le début et la fin de l'exécution sont tracés dans les logs.

Précondition : plusieurs synchronisations déjà réalisées, avec des flux reçus à des dates différentes.

Étapes :

1. Relever la date de dernière synchronisation retenue.
2. Lancer une nouvelle synchronisation.
3. Faire déposer par la plateforme un flux daté juste avant cette date, puis synchroniser à nouveau.

Attendu :

• La synchronisation repart de la date de la dernière exécution, sans tout reprendre depuis l'origine.
• Une marge de sécurité est appliquée, de sorte qu'un flux déposé juste avant la limite n'est pas manqué.
• Aucun document déjà importé n'est dupliqué du fait de cette marge.
• La première synchronisation, sans historique, ne remonte pas indéfiniment loin.

Précondition : nombre important de flux en attente, plafond de flux par exécution configuré à une valeur faible.

Étapes :

1. Lancer la synchronisation.
2. Compter les documents traités.
3. Relancer la synchronisation.

Attendu :

• L'exécution s'arrête au plafond configuré, sans erreur.
• Le compte rendu indique que tous les flux n'ont pas été traités : le plafond n'est pas silencieux.
• L'exécution suivante reprend les flux restants, sans en sauter aucun.
• Un plafond nul ou absent ne limite pas le traitement.

Précondition : nombre de flux supérieur à la taille de page configurée, limite d'appels par exécution configurée.

Étapes :

1. Lancer la synchronisation et observer le nombre d'appels émis.
2. Modifier la taille de page et relancer.
3. Abaisser la limite d'appels et relancer.

Attendu :

• Les flux sont récupérés par pages de la taille configurée.
• Le nombre d'appels émis pendant une exécution respecte la limite configurée.
• L'atteinte de la limite est signalée dans le compte rendu et la suite est reprise à l'exécution suivante.
• Aucun flux n'est perdu entre deux pages.

Précondition : plateforme configurée, provoquer un échec pendant la synchronisation : jeton expiré non renouvelable, ou service indisponible.

Étapes :

1. Lancer la tâche.
2. Consulter le compte rendu et le statut de la tâche.
3. Rétablir la situation et relancer.

Attendu :

• La tâche se termine en erreur, ce qui est visible dans l'interface des tâches planifiées.
• Les messages produits par la synchronisation sont repris dans le compte rendu.
• Les documents traités avant l'échec restent correctement enregistrés.
• La relance après rétablissement se termine normalement.

Précondition : flux entrants dont certains ne peuvent pas être traités sans décision humaine : émetteur inconnu, référence ambiguë, produit non associé.

Étapes :

1. Lancer la tâche.
2. Consulter le compte rendu.

Attendu :

• Le compte rendu distingue les échecs techniques des situations qui appellent une action humaine.
• Chaque action requise est décrite en langage métier, avec le document concerné.
• La tâche est marquée en avertissement plutôt qu'en erreur pure quand seules des actions manuelles restent en suspens.
• Les documents traitables sont bien traités, sans être bloqués par ceux qui attendent une décision.

Précondition : identifiant d'un flux connu, correspondant à un document déjà traité ou en attente.

Étapes :

1. Lancer la synchronisation de ce seul flux depuis l'interface.
2. Consulter le document concerné.
3. Recommencer avec un identifiant de flux inexistant.

Attendu :

• Le flux demandé est récupéré et le document mis à jour, sans traiter tous les autres.
• L'appel est enregistré dans la liste des retours de la plateforme.
• Un identifiant inexistant donne un message explicite, sans effet de bord.
• L'opération est tracée avec l'identifiant demandé.

Précondition : volume de flux suffisant pour que la synchronisation dure, tâche planifiée activée.

Étapes :

1. Lancer la tâche et, pendant son exécution, déclencher une seconde synchronisation à la main.
2. Attendre la fin des deux et consulter les documents importés.

Attendu :

• Aucun document n'est importé en double malgré les deux traitements concurrents.
• La date de reprise n'est pas corrompue par l'exécution concurrente.
• Le comportement retenu est explicite : soit la seconde exécution est écartée, soit elle traite sans recouvrement.
• Les éventuels conflits sont tracés.

Précondition : plusieurs centaines de documents en attente côté plateforme, plafonds laissés à leurs valeurs par défaut.

Étapes :

1. Lancer la synchronisation et mesurer sa durée et sa consommation mémoire.
2. Consulter le nombre de documents traités.
3. Répéter jusqu'à épuisement de la file.

Attendu :

• L'exécution se termine dans un temps compatible avec une tâche planifiée horaire, sans être interrompue par une limite du serveur.
• La consommation mémoire ne croît pas indéfiniment avec le nombre de documents.
• Les exécutions successives finissent par traiter toute la file, sans oubli ni doublon.
• Les listes du module restent utilisables une fois ce volume importé.

Précondition : documents déjà transmis via une première plateforme, avec leur historique de statuts.

Étapes :

1. Changer de plateforme dans la configuration et saisir les identifiants de la nouvelle.
2. Consulter les documents déjà transmis.
3. Émettre une nouvelle facture, puis lancer une synchronisation.

Attendu :

• L'historique et les identifiants de flux des anciens documents sont conservés et restent lisibles.
• La nouvelle facture part sur la nouvelle plateforme.
• La synchronisation n'essaie pas de réclamer à la nouvelle plateforme des flux qui appartiennent à l'ancienne, ou elle traite proprement son refus.
• Le changement de plateforme est tracé.

Précondition : une plateforme exposant un service de validation, une autre n'en exposant pas.

Étapes :

1. Sélectionner la première et observer les actions proposées sur une facture.
2. Sélectionner la seconde et observer les mêmes écrans.

Attendu :

• L'action de validation par la plateforme n'est proposée que lorsque la plateforme la propose réellement.
• Aucune action inopérante n'est affichée dans le second cas.
• Le contrôle local des règles de gestion reste disponible dans les deux cas.
• Aucun appel n'est émis vers un service inexistant.

Précondition : flux reçus dans des profils différents : profil de base, profil étendu, extension nationale.

Étapes :

1. Synchroniser ces flux.
2. Consulter le profil reconnu pour chacun.

Attendu :

• Le profil déclaré par chaque document est reconnu et affiché.
• Un profil inconnu est signalé comme tel plutôt que ramené de force à un profil connu.
• Le profil reconnu conditionne la façon dont le document est lu, sans faire échouer l'import quand des éléments facultatifs manquent.
• L'information est disponible pour le support, dans l'interface comme dans les logs.

Précondition : compte Esalink de test valide (identifiant, mot de passe, clé d'API).

Étapes :

1. Sélectionner Esalink comme plateforme.
2. Saisir les trois éléments d'authentification et enregistrer.
3. Lancer la vérification de l'état de la plateforme depuis la page de configuration.
4. Demander les informations distantes du compte.

Attendu :

• Les identifiants sont enregistrés, le mot de passe et la clé ne sont jamais réaffichés en clair dans le formulaire.
• La vérification de l'état répond que la plateforme est joignable et le compte reconnu.
• Les informations distantes affichent le compte réellement rattaché aux identifiants saisis.
• Aucun secret n'apparaît dans les logs, même en mode debug.

Précondition : plateforme sélectionnée, identifiants volontairement faux.

Étapes :

1. Saisir des identifiants invalides et enregistrer.
2. Lancer la vérification de l'état de la plateforme.
3. Tenter d'envoyer une facture validée.

Attendu :

• La vérification échoue avec un message distinguant un refus d'authentification d'une plateforme injoignable.
• L'envoi de la facture est refusé, la facture n'est pas marquée comme transmise.
• Le motif exact est écrit dans les logs par dol_syslog, et l'appel en échec est consultable dans la liste des retours de la plateforme.
• Aucun jeton invalide n'est conservé en base et réutilisé au prochain appel.

Précondition : compte SuperPDP de test, identifiant client et secret disponibles, délégation par partenaire non activée.

Étapes :

1. Sélectionner SuperPDP comme plateforme.
2. Saisir l'identifiant client et le secret, enregistrer.
3. Vérifier l'état de la plateforme, puis consulter le jeton obtenu.

Attendu :

• Le jeton est obtenu en mode client_credentials et enregistré avec sa date d'expiration.
• La vérification de l'état répond favorablement.
• Le secret n'est pas réaffiché en clair après enregistrement.
• Aucun jeton de rafraîchissement n'est attendu ni exigé dans ce mode.

Précondition : constante EINVOICING_SUPERPDP_VIAPARTNER renseignée avec le nom du partenaire, module OAuth de Dolibarr disponible.

Étapes :

1. Ouvrir la configuration : l'entrée SuperPDP par délégation apparaît en première position, marquée comme recommandée.
2. La sélectionner et lancer l'autorisation.
3. Accepter la délégation sur la page du partenaire.
4. Revenir sur Dolibarr.

Attendu :

• L'autorisation se fait en mode authorization_code, pas en client_credentials.
• Le jeton d'accès et le jeton de rafraîchissement sont enregistrés à l'issue du retour.
• L'utilisateur est ramené sur la page des jetons OAuth de Dolibarr.
• L'état de la plateforme est vérifiable dans la foulée sans ressaisir quoi que ce soit.

Précondition : délégation OAuth configurée, autorisation en cours.

Étapes :

1. Lancer l'autorisation OAuth.
2. Provoquer un retour dont le paramètre d'état ne correspond pas à celui envoyé.

Attendu :

• Le module détecte l'incohérence et refuse d'enregistrer le jeton.
• Un message clair est affiché, avec la marche à suivre, et la constante de contournement EINVOICING_SUPERPDP_OAUTH_STATE_MISMATCH est documentée pour les cas où le partenaire ne renvoie pas l'état.
• Le refus est tracé dans les logs.
• Aucun jeton partiel n'est laissé en base après le refus.

Précondition : plateforme configurée avec un jeton valide et un jeton de rafraîchissement enregistrés.

Étapes :

1. Forcer l'expiration du jeton en base (date d'expiration dans le passé).
2. Déclencher une opération nécessitant un appel : envoi d'une facture ou synchronisation.
3. Relire le jeton en base.

Attendu :

• isTokenExpired() détecte l'expiration et refreshAccessToken() est appelé avant l'opération.
• Un nouveau jeton est obtenu et enregistré avec une nouvelle date d'expiration.
• L'opération demandée aboutit sans que l'utilisateur ait à réautoriser.
• Si le rafraîchissement échoue, l'opération est refusée avec un message explicite, tracé dans les logs, et non silencieusement rejouée en boucle.

Précondition : jeton OAuth enregistré et fonctionnel.

Étapes :

1. Supprimer le jeton depuis la page prévue à cet effet.
2. Tenter une opération nécessitant un appel à la plateforme.
3. Relancer une autorisation complète.

Attendu :

• Le jeton et le jeton de rafraîchissement sont effacés de la base.
• L'opération suivante est refusée avec un message demandant de se réauthentifier, et non par une erreur technique brute.
• Une nouvelle autorisation restaure le fonctionnement normal.
• Les données déjà transmises et l'historique des statuts ne sont pas affectés par la suppression du jeton.

Précondition : plateforme configurée en mode test (constante EINVOICING_LIVE non posée), avec des flux déjà échangés en test.

Étapes :

1. Relever l'URL d'API utilisée en mode test et le lien de création de compte affiché.
2. Basculer la configuration en mode production.
3. Relever à nouveau l'URL d'API et le lien affiché.
4. Envoyer une facture.

Attendu :

• getApiUrl() renvoie l'URL de test avant la bascule et celle de production après, sans qu'aucune URL de test ne subsiste dans les appels.
• Le passage en production est visiblement signalé dans l'interface : l'utilisateur ne peut pas croire qu'il est encore en test.
• Les identifiants du mode production sont exigés si ce sont des identifiants distincts.
• Les flux échangés en test restent consultables et ne sont pas renvoyés en production automatiquement.

Précondition : plateforme SuperPDP configurée, constante EINVOICING_ALLOW_LOCAL_URL absente, une URL de rafraîchissement pointant vers un hôte local ou en http.

Étapes :

1. Déclencher un rafraîchissement de jeton avec cette URL.
2. Poser EINVOICING_ALLOW_LOCAL_URL à 1 et recommencer.

Attendu :

• Sans la constante, seul le protocole https est accepté et l'appel vers un hôte local est refusé.
• Le refus est tracé, il ne se traduit pas par un jeton silencieusement non renouvelé.
• Avec la constante, http et les adresses locales sont acceptés, ce qui reste réservé aux environnements de test.
• La constante ne modifie rien d'autre que la liste des protocoles autorisés pour ces appels.

Précondition : plateforme configurée avec des identifiants valides.

Étapes :

1. Lancer la vérification de l'état depuis la page de configuration.
2. Couper l'accès réseau vers la plateforme et relancer.
3. Rétablir l'accès et relancer.

Attendu :

• Le premier appel indique la plateforme joignable et le compte reconnu.
• L'appel sans réseau échoue avec un message de plateforme injoignable, distinct d'un refus d'authentification, et le module ne reste pas bloqué sur un temps d'attente sans fin.
• L'échec est tracé dans les logs.
• Le troisième appel repasse au vert sans redémarrage ni réenregistrement de la configuration.

Précondition : plateforme configurée, compte de test rattaché à un SIREN connu.

Étapes :

1. Demander les informations distantes du compte depuis la page de configuration.
2. Comparer avec la configuration locale de la société émettrice.

Attendu :

• Les informations renvoyées par la plateforme sont affichées telles quelles, sans reconstruction locale trompeuse.
• Un écart entre le SIREN déclaré côté plateforme et celui de la société Dolibarr est visible, c'est précisément ce qu'on vient contrôler ici.
• L'affichage ne comporte aucun secret d'authentification.
• Un compte non provisionné côté plateforme donne un message compréhensible et non une page vide.

Précondition : plateforme configurée en mode test, société émettrice correctement renseignée.

Étapes :

1. Lancer la génération de la facture d'exemple sans envoi.
2. Examiner le fichier produit.
3. Lancer ensuite l'envoi réel de cette facture d'exemple.
4. Consulter la liste des retours de la plateforme.

Attendu :

• La préparation seule produit un fichier conforme au protocole choisi, sans aucun appel réseau.
• L'envoi réel dépose la facture sur la plateforme de test et enregistre un appel avec son identifiant de flux.
• Un échec d'envoi est remonté avec le message de la plateforme, pas par un simple retour négatif.
• Aucune facture réelle du dossier n'est modifiée par ces deux opérations.

Précondition : même tiers que le cas précédent, option d'exigence de destinataire routable positionnée à sa valeur stricte.

Étapes :

1. Lancer la consultation de l'annuaire.
2. Tenter d'envoyer une facture.
3. Repasser l'option à sa valeur normale et réessayer.

Attendu :

• En mode strict, l'indétermination bloque l'envoi, avec un message nommant le SIREN.
• Le motif du blocage distingue bien l'indétermination d'une absence pure et simple.
• Le blocage est tracé dans les logs.
• Le retour au mode normal débloque l'envoi sans autre modification.

Précondition : plateforme sélectionnée n'exposant pas l'annuaire normalisé, option d'exigence de destinataire routable activée.

Étapes :

1. Lancer la consultation de l'annuaire pour un tiers quelconque.
2. Envoyer une facture.

Attendu :

• Le statut retourné est non pris en charge, sans appel réseau inutile.
• L'envoi n'est pas bloqué : une plateforme sans annuaire ne doit pas paralyser la facturation.
• L'interface indique que le contrôle n'a pas pu être fait, plutôt que d'afficher un résultat favorable trompeur.
• Aucun message d'erreur technique n'est présenté à l'utilisateur pour cette situation attendue.

Précondition : plateforme configurée, une facture prête à être envoyée pour chacun des trois réglages du pré-contrôle.

Étapes :

1. Régler le pré-contrôle sur sans contrôle, valider et envoyer une facture.
2. Le régler sur manuel, ouvrir une facture, lancer le pré-contrôle à la demande, puis envoyer.
3. Le régler sur automatique et envoyer une facture sans rien demander.

Attendu :

• Sans contrôle, aucun appel de pré-contrôle n'est émis.
• En mode manuel, le pré-contrôle n'a lieu que sur demande explicite, et son résultat est affiché avant l'envoi.
• En mode automatique, le pré-contrôle est déclenché de lui-même au moment voulu, sans action de l'utilisateur.
• Dans les trois cas, le résultat du dernier pré-contrôle et son statut sont conservés et consultables sur la facture.

Précondition : accès sortant vers le service de recherche Peppol, un tiers dont le SIREN est publié sur Peppol et un autre qui ne l'est pas.

Étapes :

1. Lancer la recherche Peppol pour le tiers publié.
2. La lancer pour le tiers non publié.
3. La relancer en coupant l'accès au service.

Attendu :

• Pour le tiers publié, l'existence est confirmée et le point d'accès est retourné avec son libellé.
• Pour le tiers non publié, la réponse indique une absence, pas une erreur.
• Service injoignable : un avertissement est écrit dans les logs et la fonction renvoie une absence de réponse, sans exception ni page blanche.
• Un SIREN vide n'entraîne aucun appel réseau.

Précondition : validation par interrogation d'annuaires externes activée, deux tiers : l'un dont le SIREN n'existe pas, l'autre dont l'entreprise est administrativement cessée.

Étapes :

1. Consulter le contrôle pour le SIREN inexistant.
2. Consulter le contrôle pour l'entreprise cessée.
3. Couper l'accès réseau et recommencer.

Attendu :

• Le SIREN introuvable donne un avertissement citant le SIREN et le nom du tiers.
• L'entreprise cessée donne un avertissement distinct, citant le SIREN.
• Ces contrôles ne sont jamais bloquants : ils informent, ils n'interdisent pas la facture.
• Sans réseau, aucun avertissement trompeur n'est produit et l'indisponibilité est tracée.

Précondition : validation externe activée, tiers dont le SIREN existe mais dont le nom, le code postal et la ville enregistrés dans Dolibarr diffèrent de ceux publiés.

Étapes :

1. Consulter le contrôle sur une facture de ce tiers.
2. Aligner la ville sur la valeur publiée, recharger.
3. Aligner le nom et le code postal, recharger.

Attendu :

• Chaque écart donne son propre avertissement, affichant côte à côte la valeur locale et la valeur publiée.
• Corriger un champ fait disparaître l'avertissement correspondant sans toucher aux autres.
• Ces écarts ne bloquent jamais l'émission.
• Une différence de casse ou d'espaces seule ne doit pas produire d'avertissement inutile.

Précondition : validation externe activée, tiers dont les contrôles de format échouent, par exemple sans identifiant professionnel.

Étapes :

1. Consulter le contrôle sur une facture de ce tiers et observer le trafic sortant.
2. Corriger le tiers pour que les contrôles de format passent.
3. Consulter à nouveau.

Attendu :

• Tant que les contrôles de format sont en erreur, aucun appel externe n'est émis : on n'interroge pas un annuaire avec une donnée déjà connue comme fausse.
• Une fois le format correct, l'appel externe a bien lieu.
• Les avertissements externes viennent après les messages de format, pas à leur place.
• Désactiver la validation externe supprime tout appel, quel que soit l'état du tiers.

Précondition : option de validation par la plateforme activée, plateforme exposant un service de validation.

Étapes :

1. Générer un flux valide et lancer la validation.
2. Générer un flux volontairement non conforme et lancer la validation.
3. Désactiver l'option et régénérer.

Attendu :

• Un flux valide est déclaré conforme par la plateforme et l'envoi est proposé.
• Un flux non conforme remonte le détail des erreurs de la plateforme, affiché à l'utilisateur.
• Le résultat de validation est conservé et consultable sur la facture.
• Sans l'option, ou pour une plateforme sans service de validation, aucun appel n'est émis et le parcours reste utilisable.

Précondition : plateforme configurée en mode test, facture validée dont le flux est généré et les pré-contrôles favorables.

Étapes :

1. Lancer l'envoi depuis la fiche de la facture.
2. Consulter la fiche après l'envoi.
3. Consulter la liste des retours de la plateforme.

Attendu :

• La plateforme accepte le dépôt et renvoie un identifiant de flux.
• Cet identifiant est enregistré sur la facture et affiché sur sa fiche.
• Le statut de facturation électronique passe à l'état d'attente prévu après un dépôt.
• L'appel est enregistré avec sa date, son sens et son résultat.

Précondition : option d'envoi automatique à la génération activée.

Étapes :

1. Générer le flux d'une facture conforme.
2. Observer si l'envoi a lieu sans action supplémentaire.
3. Générer le flux d'une facture dont le pré-contrôle est en erreur.

Attendu :

• La facture conforme est déposée dans la foulée de la génération.
• La facture en erreur n'est pas envoyée : l'option n'outrepasse pas les contrôles bloquants.
• Le refus d'envoi est expliqué à l'utilisateur et tracé.
• Sans l'option, la génération laisse la facture en attente d'un envoi explicite.

Précondition : plateforme configurée, facture prête, provoquer un échec d'envoi : coupure réseau, ou refus de la plateforme.

Étapes :

1. Lancer l'envoi et laisser l'échec se produire.
2. Consulter la fiche de la facture et l'historique des appels.
3. Rétablir la situation et renvoyer.

Attendu :

• La facture n'est pas marquée comme transmise et aucun identifiant de flux n'est enregistré.
• Le message d'erreur de la plateforme est conservé et affiché, pas remplacé par un message générique.
• L'échec est tracé dans les logs et visible dans la liste des appels.
• Le renvoi après correction fonctionne : le verrou ne s'est pas posé sur un envoi qui a échoué.

Précondition : option d'annulation de la facture en cas d'échec de la facturation électronique activée, facture au brouillon complète.

Étapes :

1. Provoquer un échec au moment de la validation, par exemple en rendant la plateforme injoignable.
2. Consulter l'état de la facture.
3. Désactiver l'option et refaire la manipulation.

Attendu :

• Avec l'option, la validation est annulée et la facture revient au brouillon plutôt que de rester validée sans flux.
• Aucun numéro de facture définitif n'est consommé pour rien, ou la conséquence sur la numérotation est explicitée.
• Le motif de l'annulation est affiché et tracé.
• Sans l'option, la facture reste validée et le défaut de transmission est simplement signalé.

Précondition : option de traitement en temps réel activée.

Étapes :

1. Valider une facture conforme et mesurer ce qui se passe pendant l'enregistrement.
2. Valider une facture alors que la plateforme est lente ou injoignable.
3. Désactiver l'option et valider une troisième facture.

Attendu :

• En temps réel, la génération et le dépôt ont lieu pendant la validation.
• Une plateforme lente ne bloque pas l'utilisateur indéfiniment : un délai d'attente est appliqué et l'échec est explicite.
• Un échec en temps réel laisse un état exploitable, la facture restant reprenable plus tard.
• Sans l'option, le traitement est différé et repris par la synchronisation planifiée.

Précondition : plusieurs factures générées en attente d'envoi, dont une déjà transmise et une en erreur de pré-contrôle.

Étapes :

1. Sélectionner l'ensemble dans la liste de synchronisation.
2. Lancer l'envoi en lot.
3. Consulter le compte rendu et l'état de chaque facture.

Attendu :

• Seules les factures éligibles sont déposées.
• La facture déjà transmise est écartée par le verrou, sans second dépôt.
• La facture en erreur est écartée avec son motif.
• Le compte rendu détaille le sort de chaque facture, et chaque écart est tracé dans les logs.

Précondition : facture prête à être envoyée, plateforme répondant lentement.

Étapes :

1. Lancer l'envoi et, pendant l'attente, relancer la même action depuis un second onglet.
2. Consulter l'historique des appels et l'identifiant de flux après stabilisation.

Attendu :

• Un seul dépôt est retenu : la facture ne se retrouve pas déposée deux fois sur la plateforme.
• Un seul identifiant de flux est enregistré sur la facture.
• La seconde demande est refusée ou ignorée avec un message compréhensible, et l'événement est tracé.
• L'état final de la facture est cohérent, quel que soit l'ordre des réponses.

Précondition : facture transmise et acceptée par la plateforme, avoir créé pour la corriger.

Étapes :

1. Générer et envoyer l'avoir.
2. Consulter l'état des deux documents.

Attendu :

• L'avoir est transmis comme un document à part entière, avec son propre identifiant de flux.
• Il porte la référence de la facture qu'il corrige.
• Le verrou de la facture d'origine n'empêche pas l'envoi de l'avoir.
• Les deux documents restent liés dans l'interface, l'historique de chacun étant distinct.

Précondition : facture déposée sur la plateforme, aucun retour reçu.

Étapes :

1. Consulter le statut juste après le dépôt.
2. Lancer une synchronisation avant que la plateforme n'ait analysé le flux.
3. Lancer une synchronisation après analyse.

Attendu :

• Juste après le dépôt, la facture porte le statut d'attente d'analyse par la plateforme.
• Tant que la plateforme n'a rien renvoyé, le statut reste en attente d'acquittement et ne bascule pas de lui-même.
• Ces deux statuts d'attente sont bien distincts et compréhensibles pour l'utilisateur.
• La première réponse réelle de la plateforme fait sortir la facture de l'attente.

Précondition : facture déposée, la plateforme confirmant le dépôt.

Étapes :

1. Synchroniser pour récupérer le statut.
2. Consulter la fiche de la facture et son historique.

Attendu :

• Le statut 200 est enregistré avec sa date et l'identifiant de flux correspondant.
• Le libellé affiché est celui du dépôt, pas un code brut.
• L'historique conserve ce statut même après réception des suivants.
• Ce statut fait partie des statuts obligatoires en France et est signalé comme tel dans les listes de choix.

Précondition : facture déposée dont la plateforme fait remonter successivement l'émission, la réception par la plateforme du destinataire et la mise à disposition.

Étapes :

1. Synchroniser après chaque étape.
2. Consulter le statut courant et l'historique après chacune.

Attendu :

• Les trois statuts sont enregistrés dans l'ordre reçu, chacun avec sa date.
• Le statut courant affiché est le dernier reçu, pas le premier ni un mélange.
• Aucun de ces trois statuts n'est proposé à l'envoi manuel côté émetteur : ils viennent de la plateforme.
• L'historique reste lisible même lorsque plusieurs statuts arrivent dans une même synchronisation.

Précondition : facture émise dont le destinataire déclare la prise en charge.

Étapes :

1. Synchroniser pour récupérer le statut.
2. Consulter la fiche et l'historique.
3. Vérifier si ce statut est proposé à l'envoi sur une facture fournisseur reçue.

Attendu :

• Le statut est enregistré avec sa date et visible sur la facture.
• Il ne modifie pas l'état comptable de la facture dans Dolibarr.
• Côté réception, ce statut n'est pas proposé tant qu'il n'est pas pris en charge par cette version : la liste des statuts envoyables ne doit rien proposer que la plateforme refuserait.
• L'historique le distingue clairement de l'approbation.

Précondition : facture fournisseur reçue par la plateforme, en attente de décision.

Étapes :

1. Envoyer le statut d'approbation depuis la fiche de la facture fournisseur.
2. Consulter l'historique et la liste des statuts encore proposés.

Attendu :

• L'approbation est transmise à la plateforme et enregistrée dans l'historique.
• Le refus n'est plus proposé après une approbation acceptée : on ne refuse pas ce qu'on a approuvé.
• Le paiement transmis reste proposé : l'approbation ne clôt pas l'échange.
• L'approbation n'est plus proposée une seconde fois.

Précondition : facture reçue dont une partie seulement est acceptée.

Étapes :

1. Vérifier si l'approbation partielle est proposée à l'envoi.
2. Recevoir ce statut depuis la plateforme sur une facture émise.
3. Consulter la fiche et l'historique.

Attendu :

• Reçu de la plateforme, le statut est enregistré et affiché avec son libellé propre, distinct de l'approbation pleine.
• Le montant approuvé, quand la plateforme le fournit, est conservé et visible.
• Côté envoi, ce statut n'est proposé que s'il est réellement pris en charge par cette version.
• L'historique permet de comprendre qu'une partie seulement a été acceptée.

Précondition : facture fournisseur reçue et contestée.

Étapes :

1. Ouvrir l'envoi de statut et dérouler la liste des motifs proposés pour la mise en litige.
2. Envoyer le statut avec un motif, par exemple une erreur de taux de TVA.
3. Consulter l'historique.

Attendu :

• La liste des motifs proposés est celle prévue pour ce statut, avec leur libellé lisible et non le seul code.
• Le motif retenu est transmis avec le statut et conservé dans l'historique.
• Un envoi sans motif est refusé si le motif est obligatoire pour ce statut.
• La mise en litige ne clôt pas l'échange : d'autres statuts restent proposés ensuite.

Précondition : facture reçue dont le traitement est suspendu.

Étapes :

1. Envoyer ou recevoir le statut de suspension.
2. Consulter les statuts encore proposés ensuite.

Attendu :

• La suspension est enregistrée avec son motif quand il en est fourni un.
• Elle ne règle rien : l'approbation, le refus et la mise en litige restent proposés après.
• Le libellé affiché est distinct de celui du litige.
• Une suspension déjà envoyée et acceptée n'est plus reproposée.

Précondition : facture émise dont la plateforme signale l'achèvement du traitement.

Étapes :

1. Synchroniser pour récupérer le statut.
2. Consulter la fiche et l'historique.

Attendu :

• Le statut est enregistré avec sa date et affiché avec son libellé.
• Il n'est pas proposé à l'envoi manuel côté émetteur.
• Sa réception n'écrase pas les statuts financiers déjà reçus, comme l'encaissement.
• L'historique du document reste complet et ordonné.

Précondition : facture fournisseur reçue que l'on décide de refuser.

Étapes :

1. Dérouler les motifs proposés pour le refus.
2. Envoyer le refus avec un motif.
3. Consulter la liste des statuts encore proposés.

Attendu :

• Les motifs proposés sont ceux prévus pour le refus, distincts de ceux du litige.
• Le refus est transmis avec son motif et enregistré.
• Une fois le refus accepté par la plateforme, plus aucun statut n'est proposé sur ce document : l'échange est clos, rien n'est plus dû.
• Ce statut fait partie des statuts obligatoires en France.

Précondition : facture fournisseur approuvée puis réglée dans Dolibarr.

Étapes :

1. Enregistrer le paiement de la facture fournisseur.
2. Envoyer le statut de paiement transmis, avec les données de paiement demandées.
3. Consulter l'historique.

Attendu :

• Le statut est transmis avec la date et le montant du paiement quand la plateforme les attend.
• Il n'est jamais proposé comme statut initial d'un document en cours de création : il suit forcément l'approbation.
• Le statut est enregistré dans l'historique avec ses données.
• Une facture non approuvée ne se voit pas proposer ce statut à contretemps.

Précondition : facture client transmise, encaissée par l'émetteur.

Étapes :

1. Enregistrer l'encaissement dans Dolibarr.
2. Envoyer le statut d'encaissement à la plateforme.
3. Consulter l'historique et le statut courant.

Attendu :

• Le statut est transmis et enregistré, avec la date d'encaissement.
• Il fait partie des statuts obligatoires en France et le signale dans les listes de choix.
• L'envoi n'a lieu qu'une fois : un second envoi du même statut n'est pas proposé.
• Le statut d'encaissement n'écrase pas l'historique antérieur du document.

Précondition : facture déposée avec une adresse de destination non routable, provoquant un rejet de la plateforme.

Étapes :

1. Synchroniser pour récupérer le rejet.
2. Consulter la fiche, le motif et l'historique.
3. Corriger le routage et réémettre selon la procédure prévue.

Attendu :

• Le rejet est enregistré avec le motif renvoyé par la plateforme, lisible par l'utilisateur.
• La facture est clairement signalée comme non délivrée, et non laissée dans un état d'attente indéfini.
• L'utilisateur dispose d'une marche à suivre : corriger le routage, puis réémettre.
• Ce statut fait partie des statuts obligatoires en France.

Précondition : facture fournisseur reçue par la plateforme.

Étapes :

1. Choisir un statut dans la liste, saisir un motif quand il est demandé, et envoyer.
2. Provoquer un échec d'envoi du statut et observer.
3. Consulter l'historique après chaque tentative.

Attendu :

• L'envoi réussi enregistre le statut et le rend visible sur la fiche.
• L'échec est signalé avec le message de la plateforme et tracé, sans que le statut soit considéré comme envoyé.
• Après un échec, le statut reste proposé pour une nouvelle tentative.
• L'utilisateur sans droit d'écriture ne peut pas envoyer de statut.

Précondition : facture pour laquelle la plateforme renvoie des statuts dans un ordre inattendu, par exemple un encaissement avant l'approbation, ou deux statuts datés dans le désordre.

Étapes :

1. Synchroniser pour récupérer ces statuts.
2. Consulter le statut courant et l'historique.

Attendu :

• Tous les statuts reçus sont conservés, aucun n'est écarté parce qu'il paraît prématuré.
• Le statut courant retenu est cohérent, fondé sur les dates de la plateforme et non sur l'ordre d'arrivée.
• L'anomalie de séquence est tracée pour analyse.
• L'affichage ne laisse pas croire à un état plus avancé que la réalité.

Précondition : plateforme renvoyant un code de statut que le module ne connaît pas.

Étapes :

1. Synchroniser pour récupérer ce statut.
2. Consulter la fiche de la facture et l'historique.

Attendu :

• Le message est enregistré avec son code brut, il n'est pas perdu.
• L'affichage indique un statut inconnu plutôt que de retomber par erreur sur un statut connu.
• L'événement est tracé dans les logs, avec le code reçu, pour permettre l'ajout ultérieur de ce statut.
• La synchronisation continue de traiter les autres documents.

Précondition : option d'envoi du statut de paiement activée, facture fournisseur reçue et approuvée.

Étapes :

1. Enregistrer un paiement partiel et observer.
2. Enregistrer le solde et observer.
3. Consulter l'historique.

Attendu :

• Le statut de paiement est envoyé au moment prévu par l'option, avec le montant et la date du règlement.
• Un paiement partiel est traité selon la règle annoncée, sans envoyer un statut de règlement complet à tort.
• L'envoi n'a lieu qu'une fois pour un même règlement.
• Un échec d'envoi est tracé et n'empêche pas l'enregistrement du paiement dans Dolibarr.

Précondition : plateforme configurée, flux entrant contenant une facture fournisseur CII conforme, émise par un fournisseur déjà enregistré.

Étapes :

1. Lancer la synchronisation des flux entrants.
2. Consulter la facture fournisseur créée.
3. Comparer avec le contenu du flux reçu.

Attendu :

• Une facture fournisseur est créée au brouillon, rattachée au bon fournisseur.
• La référence du fournisseur, les dates, les lignes, les taux et les totaux correspondent au flux.
• Le fichier reçu est conservé et accessible depuis la fiche.
• L'identifiant de flux est enregistré, ce qui permet de retrouver l'origine du document.

Précondition : flux entrant contenant un PDF Factur-X portant son XML.

Étapes :

1. Lancer la synchronisation.
2. Consulter la facture fournisseur créée et les fichiers rattachés.

Attendu :

• Le XML embarqué est extrait et exploité pour créer la facture.
• Le PDF reçu est conservé tel quel comme pièce du document.
• Les données importées proviennent bien du XML et non d'une lecture du PDF.
• Un PDF sans XML embarqué est traité comme un document non exploitable, avec un diagnostic clair.

Précondition : trois flux entrants, l'un d'un fournisseur dont le SIREN est enregistré, l'un d'un fournisseur identifié par un identifiant de routage connu, l'un d'un émetteur totalement inconnu.

Étapes :

1. Synchroniser.
2. Consulter le rattachement de chacune des factures créées.

Attendu :

• Le fournisseur est retrouvé par son identifiant professionnel ou par son identifiant de routage.
• L'émetteur inconnu ne provoque pas de rattachement approximatif à un autre tiers.
• Le cas de l'émetteur inconnu est signalé, avec les données reçues, pour permettre une décision humaine.
• Un identifiant reçu avec des espaces est nettoyé avant recherche.

Précondition : flux entrant dont les lignes portent des références fournisseur, dont certaines déjà associées à des produits du catalogue.

Étapes :

1. Synchroniser.
2. Consulter les lignes de la facture fournisseur créée.

Attendu :

• Les lignes dont la référence est connue sont rattachées au bon produit du catalogue.
• Les lignes inconnues sont traitées selon l'option retenue, sans rattachement arbitraire à un produit voisin.
• Le prix, la quantité et le taux de TVA de chaque ligne restent ceux du flux, même quand un produit est reconnu.
• Le rattachement effectué est visible et modifiable par l'utilisateur.

Précondition : option d'import en lignes libres activée, flux entrant dont certaines lignes correspondent pourtant à des produits connus.

Étapes :

1. Synchroniser avec l'option activée.
2. Consulter les lignes créées.
3. Désactiver l'option et importer un flux équivalent.

Attendu :

• Avec l'option, toutes les lignes sont créées en lignes libres, sans rattachement au catalogue.
• Les libellés, quantités, prix et taux restent fidèles au flux.
• Sans l'option, la correspondance avec le catalogue reprend.
• Le choix d'option ne modifie jamais les totaux de la facture importée.

Précondition : option de création automatique des produits activée, flux entrant comportant des références inconnues.

Étapes :

1. Synchroniser.
2. Consulter le catalogue produits.
3. Importer un second flux portant les mêmes références.

Attendu :

• Les produits manquants sont créés, avec la référence, le libellé et le prix d'achat issus du flux.
• Le second import réutilise les produits créés au lieu d'en créer des doublons.
• Sans l'option, aucun produit n'est créé et les lignes concernées suivent le traitement de repli prévu.
• Les créations sont tracées, pour que l'on sache d'où viennent ces produits.

Précondition : flux entrant contenant un document XML mal formé ou tronqué.

Étapes :

1. Synchroniser.
2. Consulter le diagnostic du dernier document non traité.
3. Synchroniser un flux correct et reconsulter.

Attendu :

• Aucune facture fournisseur n'est créée à partir du document illisible.
• Le contenu du dernier document non traité est conservé dans un emplacement de diagnostic, consultable par un administrateur.
• Le motif de l'échec est tracé dans les logs.
• Un flux correct reçu ensuite est traité normalement : un document illisible ne bloque pas la file.

Précondition : flux entrant contenant un document dans un format que le module ne traite pas, par exemple un format non retenu dans cette version.

Étapes :

1. Synchroniser.
2. Consulter le message produit et le diagnostic.

Attendu :

• Le format non pris en charge est reconnu comme tel et distingué d'un document illisible.
• Le document est conservé pour pouvoir être traité autrement.
• Le message indique le format détecté.
• La détection de format s'appuie sur le contenu et non sur la seule extension du fichier.

Précondition : flux entrant comportant à la fois le document structuré et une vue lisible, puis un flux sans vue lisible.

Étapes :

1. Synchroniser les deux.
2. Consulter les fichiers rattachés à chaque facture créée.

Attendu :

• La vue lisible reçue est conservée et consultable depuis la fiche de la facture fournisseur.
• Le document structuré reste disponible séparément.
• Sans vue lisible fournie, la fiche le signale plutôt que de proposer un lien mort.
• Les fichiers sont rangés dans le répertoire du document et non dans un répertoire temporaire.

Précondition : lot de plusieurs flux entrants, dont un provoque une erreur en cours de traitement.

Étapes :

1. Lancer la synchronisation et laisser l'erreur se produire.
2. Consulter l'état des documents déjà traités et de ceux qui restaient.
3. Relancer la synchronisation.

Attendu :

• Les documents traités avant l'erreur sont conservés en base, complets.
• Le document en erreur n'a pas laissé de facture à moitié créée.
• La relance reprend là où il faut, sans dupliquer ce qui a déjà été importé.
• L'erreur est tracée avec l'identifiant de flux concerné.

Précondition : flux entrant dont le document original est fourni par la plateforme, option de préférence pour l'original activée puis désactivée.

Étapes :

1. Synchroniser avec l'option activée et consulter le fichier conservé.
2. Synchroniser un flux équivalent sans l'option.
3. Comparer les deux fichiers conservés avec ce que la plateforme a transmis.

Attendu :

• Avec l'option, le document original du fournisseur est conservé tel quel, sans réécriture.
• Sans l'option, le document conservé est celui que la plateforme a mis à disposition.
• Dans les deux cas, ce qui est archivé correspond à un fichier réellement reçu, jamais à une reconstruction locale.
• Le choix retenu est visible pour l'utilisateur qui consulte la pièce.