Cahier des charges de la facture électronique ERP

Construire un dossier que les candidats peuvent chiffrer

Le cahier des charges commence par la situation observée : ERP, version, hébergement, interfaces et personnes responsables. Décrivez ensuite les flux à couvrir, sans transformer une fonction souhaitée en fonction déjà disponible. Un inventaire daté évite que chaque candidat parte d’une hypothèse différente. Les données sensibles n’ont pas leur place dans le premier dossier ; utilisez des exemples fictifs représentant les champs et variantes nécessaires.

La trame CSV téléchargeable sur cette page est un document de travail à adapter. Elle vous aide à décrire les cas, les attentes et les preuves à recevoir. Les spécifications officielles et les normes applicables restent la référence pour les messages. Demandez au prestataire d’indiquer les versions retenues et les différences éventuelles avec votre environnement actuel.

Séparer les familles de flux

Une ligne de périmètre doit identifier l’application source, l’entité juridique, le type d’opération et la destination. Séparez les factures clients, la réception fournisseurs, les échanges publics et les données de reporting. Notez les volumes mesurés sur une période représentative et les pics connus. Si le volume n’est pas disponible, demandez comment le collecter plutôt que de saisir une estimation présentée comme un fait.

Ajoutez les variantes métier : avoir, acompte, remise, pièce jointe ou facturation pour plusieurs établissements. Indiquez ce qui est fréquent et ce qui est exceptionnel. La fréquence permet d’organiser les priorités de test, mais elle ne justifie pas l’omission d’un cas nécessaire. Pour chaque variante, nommez la personne pouvant valider le traitement comptable. Le prestataire peut alors expliquer les adaptations et les limites de son offre.

Définir des responsabilités utilisables

La matrice des responsabilités doit identifier qui produit la donnée, qui l’interprète et qui autorise une correction. Elle doit couvrir l’entreprise, l’intégrateur, la plateforme et les autres fournisseurs concernés. Évitez d’attribuer simplement « tous les incidents » à un support unique si plusieurs contrats se partagent le parcours. Précisez le responsable du ticket et les contacts d’escalade.

Une facture fournisseur litigieuse ne relève pas uniquement de la DSI. Une erreur d’authentification ne relève pas uniquement du comptable. Le cahier distingue décision métier et intervention technique. Il précise les accès autorisés, les environnements utilisés et les limites de consultation des données. Ajoutez un responsable pour l’adressage de réception et un responsable pour les droits du connecteur, afin que ces paramètres ne soient pas modifiés sans contrôle.

Écrire des exigences dont on peut constater le résultat

Une exigence telle que « suivi fiable » est difficile à réceptionner. Préférez une formulation observable : retrouver dans l’ERP la référence du document et sa dernière réponse documentée, après un scénario défini. Associez chaque exigence à un cas et à une preuve. Le tableau de recette comprend la donnée d’entrée, le résultat attendu, le résultat obtenu et la décision du validateur.

Préparez les erreurs avec autant de soin que les succès. Testez un destinataire absent, un document incomplet et une interruption réseau. Demandez une reprise qui préserve l’identité de la facture. La procédure doit expliquer comment éviter une nouvelle émission lorsque la première a peut-être été reçue. Exigez aussi un export des journaux et une consultation des documents sans dépendre exclusivement d’un écran de démonstration.

Décrire la bascule et l’exploitation

Le dossier doit expliquer comment les documents en cours sont traités au changement de système. Définissez les conditions d’arrêt d’une émission, de reprise et de rapprochement. La date de bascule n’est pas un engagement de délai prestataire avant étude ; elle est une contrainte du projet à faire examiner. Préparez une décision explicite des responsables métier et techniques.

Le support doit disposer des procédures, des contacts et des accès nécessaires. Demandez une remise de documentation et une séance de transmission aux équipes. Précisez les modifications qui pourront être réalisées par l’entreprise et celles qui nécessiteront une intervention. La maintenance comprend aussi les changements d’interface et de normes ; le contrat doit dire comment ils seront évalués puis testés avant production.

Organiser la réponse fournisseur

Faites répondre chaque candidat dans les mêmes colonnes : couvert, condition, exclusion, preuve et coût. Une réponse « couvert » doit renvoyer à une fonction démontrée ou à un engagement écrit. Une option proposée pour plus tard ne doit pas apparaître comme acquise. Conservez les questions ouvertes dans le registre du projet et attribuez chacune à un interlocuteur.

Pour la réception, prévoyez un procès-verbal avec réserves éventuelles. L’entreprise doit savoir quelles anomalies empêchent la bascule et lesquelles peuvent être suivies après acceptation. Ne remplacez pas cette décision par un pourcentage de tests réussis sans analyse des cas en défaut. Une anomalie rare peut empêcher un flux nécessaire. Le dossier final doit permettre à un autre intervenant de comprendre les choix et de poursuivre l’exploitation.

Grille à joindre à la consultation

Livrable attendu

Téléchargez la trame CSV, ouvrez-la dans votre tableur et ajoutez les cas propres à votre activité. Vous pouvez conserver plusieurs lignes pour une même famille de flux si les applications diffèrent. La trame ne demande aucun identifiant réel ni pièce de facture. Avant transmission, faites relire le périmètre par la comptabilité, les achats et la DSI. Les éléments encore inconnus doivent être identifiés comme tels dans le dossier de consultation, avec un responsable chargé de les établir.

Télécharger la trame de consultation CSV