L'interfaçage bon de commande détermine si un bon de commande est créé une seule fois et suivi partout, ou ressaisi d'un outil à l'autre. Dans beaucoup d'entreprises, un bon de commande (PO) est créé dans l'outil achats, ressaisi dans l'ERP, et finit avec un numéro différent dans chacun. Les réceptions ne correspondent pas, les factures sont bloquées, et personne ne sait quelle version fait foi. Ce guide suit un seul objet, le bon de commande, de la création à la clôture : qui possède le numéro de PO, ce que chaque étape transmet, comment gérer les modifications et les annulations, quels champs faire correspondre, et ce qui change pour les prestations. Pour la vue d'ensemble des systèmes et des méthodes, voir le guide sur l'intégration des achats.
Qu'est-ce que l'interfaçage bon de commande ?
L'interfaçage bon de commande est l'échange automatique des données de bon de commande entre les outils qui le créent, le valident, l'envoient, enregistrent les réceptions et le clôturent, en général un outil e-procurement, un VMS et un ERP. Il garde un seul numéro de PO, un seul jeu de champs et un seul statut dans chaque système, sans ressaisie.
Un PO traverse plusieurs outils, et chaque passage de relais est une occasion d'erreur de saisie, de retard ou de doublon. L'interfaçage définit, pour chacun, le déclencheur, les données et la réponse de confirmation.
Quels systèmes créent, reçoivent et mettent à jour un bon de commande ?
| Système | Rôle sur le PO | Exemples |
|---|---|---|
Outil e-procurement ou S2P | Saisit la demande d'achat, achemine les validations, crée souvent le PO | Coupa, SAP Ariba |
VMS | Gère les PO de prestations : missions, grilles tarifaires, CRA et jalons, et conserve la référence du PO | Eleven VMS |
ERP | Engage le budget, détient l'écriture financière, enregistre les réceptions et les factures | SAP S/4HANA, Oracle, Dynamics 365 |
Portail ou réseau fournisseurs | Transmet le PO au fournisseur et renvoie l'accusé de réception et les modifications demandées | Un portail fournisseur ou un réseau de fournisseurs |
L'interfaçage ERP bon de commande est en général le point de départ d'un projet, parce que l'ERP détient le budget et l'écriture financière. Le VMS se raccorde au même flux, par des API ouvertes pour l'ERP (SAP, Oracle, Workday) et pour les plateformes e-procurement (Coupa, Ivalua). Les méthodes sont détaillées dans le guide pilier, à la section sur les méthodes d'intégration.
Le cycle de vie de l'interfaçage du PO, étape par étape
Sept étapes mènent un PO de la demande d'achat à la clôture. Chacune suit le même format : déclencheur, données envoyées, outil source, outil cible et réponse attendue. C'est le cœur de tout interfaçage P2P, et le PO se situe au centre du processus source-to-pay, quels que soient les outils en place.
1. Demande d'achat créée et validée
Un manager exprime un besoin : demandeur, description, montant estimé, centre de coûts et catégorie de dépense. Pour les biens, la demande d'achat (DA) vit dans l'outil e-procurement. Pour les prestations, elle démarre souvent dans le VMS, avec le statement of work, et est poussée vers l'outil e-procurement. Elle ne passe à l'outil suivant qu'après la validation finale, et la réponse attendue est un statut validé.
2. Création du PO : quel système possède le numéro ?
Deux systèmes peuvent en général créer le numéro, et un seul devrait le faire. C'est la décision la plus importante de l'interfaçage.
| Option | Fonctionnement | Avantages | Risques |
|---|---|---|---|
L'ERP crée le numéro | L'ERP crée le PO et renvoie le numéro à l'outil achats | Une seule séquence de numérotation côté finance, l'ERP reste le registre unique des engagements | Le PO n'existe dans l'outil achats qu'après la réponse de l'ERP : une panne de l'ERP retarde le fournisseur |
L'outil achats crée le numéro | L'outil crée le PO et l'ERP le reprend | Le PO parvient immédiatement au fournisseur, sans attendre l'ERP | Les formats de numéro peuvent entrer en conflit avec les séquences de l'ERP, et des messages rejoués peuvent créer des doublons |
La règle est de nommer un propriétaire par type de PO, par exemple par catégorie de prestations, et de ne jamais laisser les deux systèmes créer un numéro. Quelle que soit l'option, chaque PO a aussi besoin d'un identifiant technique unique, pour qu'un message envoyé deux fois ne puisse pas créer deux PO.
3. PO transmis à l'ERP comme engagement budgétaire
Déclencheur : le PO est validé. Données : lignes, identifiant fournisseur, comptes, montants. Source vers cible : de l'outil achats vers l'ERP. Réponse : l'ERP confirme l'engagement, et renvoie le numéro s'il en est le propriétaire.
4. PO envoyé au fournisseur et acquitté
Déclencheur : le PO est émis. Données : le document de PO et ses conditions. Source vers cible : de l'outil achats ou du portail fournisseur vers le fournisseur. Réponse : un accusé de réception, ou un refus ou une demande de modification qui revient dans le flux du PO.
5. Réception : réception de biens ou CRA validé
Déclencheur : les biens sont livrés, ou un CRA est validé pour les prestations. Données : quantité ou jours, date, ligne de PO. Source vers cible : de l'entrepôt ou du VMS vers l'ERP. Réponse : la réception est enregistrée et le solde de la ligne de PO est mis à jour.
6. Facture rapprochée du PO et de la réception (rapprochement à trois)
Déclencheur : une facture arrive. Données : lignes de facture, référence du PO, réception. Source vers cible : de l'outil de facturation vers l'ERP. Réponse : si les trois documents concordent, le paiement est libéré, sinon la facture est bloquée et fait l'objet d'une demande de précisions.
7. Clôture du PO et retour des statuts
Déclencheur : le PO est entièrement reçu et facturé, ou clôturé par anticipation. Données : statut de clôture, montant libéré. Source vers cible : de l'ERP vers l'outil achats et le VMS. Réponse : le PO est clôturé partout et le budget non utilisé est libéré.
| Étape | Déclencheur | Source vers cible | Données | Réponse |
|---|---|---|---|---|
1. Demande d'achat | Un besoin est soumis et validé | Outil du demandeur vers circuit de validation | Demandeur, montant, centre de coûts, catégorie | Statut validé |
2. Création du PO | La demande d'achat est validée | Propriétaire du numéro de PO vers les autres systèmes | En-tête du PO, lignes, identifiant unique | Numéro de PO partagé |
3. Engagement | Le PO est validé | Outil achats vers ERP | Lignes, identifiant fournisseur, comptes, devise | Engagement confirmé |
4. Fournisseur | Le PO est émis | Outil achats ou portail vers fournisseur | Document de PO et conditions | Accusé de réception |
5. Réception | Livraison ou CRA validé | Entrepôt ou VMS vers ERP | Quantité ou jours, date, ligne de PO | Réception enregistrée |
6. Rapprochement | Une facture arrive | Outil de facturation vers ERP | Lignes de facture, PO et réception | Rapprochement validé ou facture bloquée |
7. Clôture | Entièrement reçu et facturé, ou clôture anticipée | ERP vers outil achats et VMS | Statut de clôture, montant libéré | PO clôturé partout |
Gérer les modifications, annulations et clôtures de PO
Les modifications sont là où les interfaçages cassent le plus, parce que chaque outil détient une copie du PO. Les chiffres sont illustratifs.
Modifications de commande et gestion des versions
Règle : le numéro de PO est conservé et le PO mis à jour est renvoyé en entier comme une nouvelle version, et non seulement la modification. Les destinataires remplacent l'ancienne version, et une modification manquée ne peut pas corrompre le PO. Une nouvelle validation est exigée quand le montant dépasse un seuil fixé. Exemple : un PO de 100 jours à 600 euros (60 000 euros) est prolongé de 20 jours. La version 2 porte 120 jours et 72 000 euros, la hausse de 12 000 euros repart en validation, et l'engagement dans l'ERP passe de 60 000 à 72 000 euros.
Annuler un PO après une réception partielle
Règle : on n'annule que la part qui n'a pas été reçue. Ce qui a été reçu reste sur le PO et est facturé. Exemple : sur le même PO de 60 000 euros, 40 jours (24 000 euros) ont été reçus. Annuler le reste libère 36 000 euros d'engagement dans l'ERP, et le fournisseur facture les 24 000 euros reçus.
Clôture anticipée et clôture définitive
Règle : un PO est clôturé par anticipation quand le solde ne sera pas consommé, et clôturé définitivement seulement quand les montants reçus et facturés concordent. Exemple : sur le même TJM de 600 euros, un PO a 3 jours inutilisés sur 100. La clôture anticipée libère 1 800 euros de budget, et le PO est clôturé une fois la dernière facture rapprochée.
Correspondance des champs : les données que chaque bon de commande doit porter
La synchronisation des bons de commande ne fonctionne que si les deux côtés s'accordent sur les champs. Le système de référence de chaque champ dépend de votre configuration : l'essentiel est un système nommé par champ, les autres le recevant en lecture seule. Le tableau montre une correspondance type.
| Champ | Système de référence | Obligatoire ? | Piège courant |
|---|---|---|---|
Identifiant fournisseur | ERP | Oui | Un même fournisseur a deux identifiants selon les outils, et le PO est rejeté ou dupliqué |
Entité juridique | ERP | Oui | Le PO est émis à la mauvaise entité, et la facture ne peut pas être rapprochée |
Centre de coûts | ERP | Oui | Le centre de coûts est fermé ou renommé après la création du PO |
Compte comptable ou catégorie de dépense | ERP | Oui | Une catégorie de l'outil achats n'a pas de correspondance dans le plan comptable |
Devise | ERP ou contrat | Oui | La devise du PO diffère de celle de la facture |
Taxes | ERP | Oui | Un code de TVA est absent ou erroné pour le pays du fournisseur |
Numéro de ligne | Outil achats | Oui | Les numéros de ligne changent quand on modifie des lignes, ce qui casse le lien avec les réceptions |
Unité de mesure | Outil achats ou ERP | Oui | Le jour, l'heure et l'unité sont confondus, ce qui compte surtout pour les prestations |
Date de livraison ou période de prestation | Outil achats ou VMS | Oui, pour les prestations | La période est absente, et les CRA sont rejetés comme hors du PO |
Numéros de DA et de PO | Outil achats ou ERP | Oui | Un numéro conservé dans un seul outil, et la traçabilité est perdue |
Les données de base comme les numéros de commande, les codes fournisseurs et les centres de coûts peuvent être propagées dans le VMS par API, comme le décrit le guide sur la connexion par API. Synchroniser d'abord les données de base évite de nombreux rejets.
Surveiller les erreurs et les bons de commande rejetés
Les rejets sont normaux. Ils deviennent un problème quand personne ne les voit. Les plus courants sont :
Fournisseur introuvable dans l'ERP : la fiche fournisseur n'a jamais été synchronisée. Le correctif est de synchroniser les données fournisseurs avant le premier PO.
Centre de coûts fermé : le PO vise un centre de coûts qui n'est plus ouvert. Le correctif est de valider le centre de coûts dès la demande d'achat.
Budget dépassé : l'ERP refuse l'engagement. Le correctif est de vérifier le budget disponible avant la validation finale.
Doublon : le même PO a été envoyé deux fois. Un identifiant unique par PO l'évite, pour qu'un renvoi remplace au lieu de dupliquer.
Chaque rejet a besoin d'un responsable et d'une alerte. L'acheteur voit la file des rejets, pas seulement l'IT, et un renvoi rejoue le même message avec le même identifiant au lieu de créer un nouveau PO.
Les bons de commande de services : ce qui change pour les SoW et le contingent workforce
Un PO de prestations ne se comporte pas comme un PO de biens. Cinq différences comptent pour l'interfaçage :
Une commande ouverte se consomme dans le temps. Un seul PO couvre une mission, et chaque CRA validé en consomme une part : le solde restant doit être visible dans chaque outil.
Les grilles tarifaires fixent le prix des lignes. Une ligne de PO est valorisée au TJM convenu : un tarif hors grille est un rejet, et non une exception découverte à la facturation.
Les jalons déclenchent les paiements sur un SoW. Les lignes de PO suivent les jalons, et la réception est la recette d'un livrable, et non un bon de livraison.
Une prolongation de mission est une modification de commande. Prolonger un consultant de 20 jours est une nouvelle version du PO, et suit les règles de versions et de nouvelle validation vues plus haut.
Un CRA validé vaut réception. Les jours approuvés par le manager sont enregistrés comme une réception sur la ligne de PO.
Le guide sur la validation des CRA (timesheet approval) explique comment fonctionne la validation elle-même, et le guide sur les achats sous SoW couvre les jalons et la recette.
Exemple : un flux de bon de commande entre un VMS, Coupa et SAP
Cet exemple est un montage possible, avec l'ERP comme propriétaire du numéro de PO. Dans un autre montage, l'outil e-procurement émet lui-même le PO, ce qui correspond à la seconde option de la décision ci-dessus.
Le SoW est signé dans le VMS. La mission, les tarifs et le budget sont fixés.
La DA est envoyée à Coupa, avec le SoW en pièce jointe, et validée dans l'outil.
Le PO est créé dans SAP. La demande d'achat validée devient un PO dans l'ERP, comme engagement budgétaire.
Le numéro de PO revient dans le VMS et est rattaché à la mission.
Les CRA validés déclenchent la réception. À chaque période de validation, les jours approuvés sont enregistrés comme réception sur la ligne de PO.
La facture est rapprochée du PO et de la réception dans l'ERP, et le paiement est libéré si tout concorde.
Un interfaçage Coupa et un interfaçage SAP Ariba diffèrent en général plus par les connecteurs que par la logique : les mêmes six étapes s'appliquent si l'outil e-procurement est SAP Ariba.
Checklist de l'interfaçage bon de commande avant mise en production
Le propriétaire du numéro de PO est décidé, par type de PO.
Un identifiant technique unique est défini pour chaque PO.
La correspondance des champs est validée par les achats, la finance et l'IT.
Les données de base (fournisseurs, centres de coûts, comptes) sont synchronisées avant le premier PO.
Les scénarios de modification sont testés : hausse, baisse et prolongation.
L'annulation après réception partielle est testée.
Les rejets sont testés avec des données réelles, doublons compris.
Les alertes sont configurées, avec un responsable nommé pour chaque type de rejet.
Les réceptions, CRA validés compris, sont testées sur les lignes de PO.
Le rapprochement à trois est testé de bout en bout, de la facture au paiement.
Synchroniser les bons de commande au même endroit
Eleven VMS se connecte par des API ouvertes aux ERP et aux plateformes e-procurement, et une équipe dédiée accompagne l'interfaçage. Un propriétaire du PO clair, une correspondance validée et des rejets testés retirent l'essentiel des mauvaises surprises à la mise en production.
Échangez avec l'un de nos experts pour une démo personnalisée.
