> Amélioration continue des processus > Purchase to Pay Purchase Order > SAP Ariba > Modèle de données

Votre modèle de données Purchase to Pay, commande d’achat

SAP Ariba

Purchase to Pay - Purchase Order : attributs (22) Purchase to Pay - Purchase Order : activités (14) Guides d'extraction (2)

Votre modèle de données Purchase to Pay, commande d’achat

Ce modèle fournit un guide complet pour rassembler les données essentielles nécessaires à l’analyse de votre processus Purchase to Pay, commandes d’achat. Il présente les attributs et les activités à suivre, ainsi que des conseils pratiques pour extraire les données de votre système source. Utilisez cette ressource pour disposer d’une base complète et fiable pour la découverte et l’optimisation des processus.

Attributs recommandés à collecter
Activités clés à suivre
Recommandations pour l'extraction

Vous découvrez les journaux d’événements ? En savoir plus sur la création d’un journal d’événements pour le Process Mining.

Télécharger le modèle

Purchase to Pay - Purchase Order : attributs

Voici les champs de données recommandés à inclure dans votre journal d’événements pour analyser en détail votre processus Purchase to Pay - Purchase Order.

3 Obligatoire 6 Recommandé 13 Facultatif

	Nom	Description
	Commande d’achat PurchaseOrderNumber	Identifiant unique de chaque document de commande d’achat, utilisé comme identifiant de cas central du processus.
Description Le numéro de commande d’achat est la clé primaire qui relie toutes les activités et tous les événements associés tout au long du cycle de vie des achats. Chaque numéro représente une transaction d’achat unique, depuis la création initiale de la commande jusqu’à son achèvement ou son annulation. Dans le Process Mining, cet attribut est fondamental pour l’analyse au niveau du cas. Il permet de reconstituer le parcours de bout en bout de chaque commande d’achat, de calculer les temps de cycle, d’identifier les variantes de processus et de suivre le statut de chaque commande. L’analyse des processus par numéro de commande d’achat aide à comprendre le flux complet et à repérer les goulots d’étranglement ou les écarts propres à certaines transactions. Pourquoi c’est important Il s’agit du Case ID essentiel qui relie toutes les étapes du processus et permet d’analyser le cycle de vie complet de chaque commande d’achat. Où les obtenir Il s’agit d’un champ principal du document Purchase Order dans SAP Ariba Buying and Invoicing ou SAP Ariba Sourcing. Exemples PO7000123456PO7000123457PO7000123458
	Heure de l’événement EventTime	Date et heure précises auxquelles une activité ou un événement donné s’est produit.
Description Event Time est l’horodatage associé à chaque activité, qui indique le moment où celle-ci a commencé. Ces données sont essentielles pour classer les événements dans l’ordre chronologique et calculer les durées et les délais de traitement entre les différentes étapes du processus. Cet attribut est indispensable à presque toutes les analyses temporelles, notamment aux Dashboards Purchase Order End-to-End Cycle Time et Purchase Order Approval Cycle Time. Il permet de calculer des indicateurs clés de performance tels que « Average PO Approval Cycle Time », en mesurant l’écart entre les horodatages des activités « Purchase Order Created » et « Purchase Order Approved ». Pourquoi c’est important Cet horodatage est fondamental pour ordonner correctement les événements et calculer toutes les métriques fondées sur la durée, comme les délais de traitement et les temps d’attente. Où les obtenir Ces informations se trouvent généralement dans la piste d’audit ou les données du journal des modifications des documents de commande d’achat dans SAP Ariba. Exemples 2023-04-15T10:30:00Z2023-04-16T14:05:22Z2023-05-01T09:00:15Z
	Nom de l’activité ActivityName	Nom de l’événement ou de la tâche précise survenu(e) à un moment donné du processus de commande d’achat.
Description Le nom de l’activité décrit une étape du cycle de vie de la commande d’achat, comme « Purchase Order Created », « Purchase Order Approved » ou « Goods Receipt Posted ». Cette séquence d’activités constitue la base de la carte du processus. L’analyse de ces activités est au cœur du Process Mining. Elle permet de visualiser le flux du processus, d’identifier les variantes fréquentes et rares et de mesurer la durée entre les différentes étapes. Comprendre la séquence et la fréquence d’activités telles que « Purchase Order Changed » est essentiel pour des Dashboards comme Purchase Order Change Rate Analysis. Pourquoi c’est important Cet attribut définit les étapes du processus. Il permet de visualiser le flux du processus et d’identifier les goulots d’étranglement, les reprises et les écarts. Où les obtenir Généré par l’association des changements de statut, des codes de transaction ou des journaux d’événements issus des tables SAP Ariba sous-jacentes liées à l’historique des documents et au flux de travail. Exemples Commande d’achat approuvéeCommande d’achat modifiéeRéception de marchandises enregistréeFacture reçue pour une commande d’achat
	Date de livraison demandée RequestedDeliveryDate	La date à laquelle le demandeur prévoit la livraison des biens ou l’exécution des services.
Description Il s’agit de la date de livraison cible indiquée par l’entreprise lors de la création de la demande d’achat ou de la commande. Elle sert de référence pour mesurer la performance réelle des livraisons. Cet attribut est fondamental pour le Dashboard de performance des livraisons fournisseurs et le KPI de taux de réception des marchandises dans les délais. En comparant la date de livraison demandée à la date réelle de réception des marchandises, les organisations peuvent mesurer la ponctualité des fournisseurs, calculer l’écart de livraison et identifier ceux qui ne respectent pas régulièrement les délais. Cette analyse est essentielle pour gérer les relations fournisseurs et réduire les risques liés à la chaîne d’approvisionnement. Pourquoi c’est important Sert de référence pour mesurer la performance des livraisons dans les délais, un élément essentiel pour évaluer la fiabilité des fournisseurs et l’efficacité de la chaîne d’approvisionnement. Où les obtenir Il s’agit d’un champ de date standard au niveau du poste du document Purchase Order. Exemples 2023-06-012023-07-152023-08-20
	Date de réception des marchandises GoodsReceiptDate	La date à laquelle la réception des marchandises ou l’achèvement des services a été officiellement enregistré dans le système.
Description Cet attribut indique l’horodatage de l’activité « Goods Receipt Posted » ou « Services Confirmation Entered ». Il constitue la confirmation officielle de la réception des articles commandés. Cette date est essentielle pour mesurer les délais de livraison réels. Elle correspond à la « RequestedDeliveryDate » et sert à calculer l’écart de livraison ainsi que les KPI de ponctualité. Le Dashboard de ponctualité de l’enregistrement des réceptions de marchandises s’appuie sur cet attribut pour évaluer la rapidité d’enregistrement des réceptions après la livraison, un élément important pour l’exactitude des stocks et le paiement ponctuel des factures. Pourquoi c’est important Représente la date réelle de livraison, indispensable pour calculer la performance des livraisons et identifier les retards dans la chaîne d’approvisionnement. Où les obtenir Il s’agit de l’horodatage du document de réception des marchandises ou de la feuille de saisie des services faisant référence au Purchase Order. Exemples 2023-06-02T11:00:00Z2023-07-14T15:30:00Z2023-08-22T09:45:00Z
	Montant du Purchase Order PurchaseOrderAmount	La valeur monétaire totale du Purchase Order.
Description Cet attribut représente le coût total de l’ensemble des biens et services indiqués sur le Purchase Order, hors taxes et autres frais, sauf indication contraire. Il s’agit d’un indicateur financier essentiel pour comprendre la valeur des transactions qui traversent le processus. Dans le cadre de l’analyse, le montant du Purchase Order sert souvent à segmenter le processus. Par exemple, les commandes de montant élevé peuvent suivre un circuit d’approbation différent et plus strict que les commandes de faible montant. Il peut également servir à prioriser les initiatives d’amélioration des processus sur les transactions les plus importantes sur le plan financier et à analyser les habitudes de dépenses par service ou par fournisseur. Pourquoi c’est important Fournit un contexte financier pour chaque cas, ce qui permet de prioriser les améliorations en fonction de la valeur et de comprendre l’incidence du montant de la commande sur le comportement du processus. Où les obtenir Il s’agit d’un champ calculé standard au niveau de l’en-tête du document Purchase Order, qui additionne la valeur de tous les postes. Exemples 1500.0025000.50500.75
	Nom de l’utilisateur UserName	Nom ou identifiant de l’utilisateur ayant exécuté l’activité.
Description Cet attribut identifie la personne responsable de l’exécution d’une étape précise du processus, comme l’approbation d’une commande d’achat ou l’enregistrement d’une réception de marchandises. Il peut s’agir d’un identifiant utilisateur unique ou d’un nom complet. L’analyse des performances par utilisateur permet d’identifier les besoins de formation ou de reconnaître les meilleurs contributeurs. Elle est également essentielle aux analyses liées à la conformité, comme le Dashboard PO Approval Compliance Deviation, qui permet de déterminer qui a contourné les étapes d’approbation requises. Elle peut aussi servir à comprendre la répartition de la charge de travail et l’allocation des Ressources. Pourquoi c’est important Fournit une traçabilité et permet d’analyser les performances, la charge de travail et la conformité par utilisateur, ce qui est essentiel pour identifier les besoins de formation ou les écarts du processus. Où les obtenir Ces informations sont généralement disponibles dans les journaux du flux de travail et de l’historique des documents de SAP Ariba, souvent associées à chaque événement. Exemples john.smithLROSSIjane.doe
	Nom du fournisseur VendorName	Nom du fournisseur auprès duquel les biens ou les services sont achetés.
Description Cet attribut identifie le partenaire externe associé à la commande d’achat. Le fournisseur est une entité essentielle du processus purchase-to-pay, et ses performances ont un impact direct sur l’efficacité de l’ensemble du cycle. Vendor Name constitue une dimension principale de l’analyse des performances. Il est essentiel au Dashboard Vendor Delivery Performance, qui compare les dates de livraison entre les différents fournisseurs. L’analyse des processus par fournisseur peut révéler ceux qui sont régulièrement en retard, génèrent davantage de reprises ou présentent des processus de facturation complexes, fournissant ainsi des éléments utiles à la gestion de la relation fournisseur. Pourquoi c’est important Permet d’analyser les performances des fournisseurs, d’identifier les partenaires fiables et de repérer ceux qui sont à l’origine de retards ou d’autres problèmes. Où les obtenir Il s’agit d’un champ standard au niveau de l’en-tête du document Purchase Order dans SAP Ariba. Exemples Global Office Supplies Inc.Tech Solutions LLCAdvanced Industrial Parts
	Nom du service DepartmentName	Service métier ou centre de coûts associé à la commande d’achat.
Description Cet attribut indique l’unité organisationnelle qui a lancé la demande d’achat ou pour laquelle l’achat est effectué. Il est souvent dérivé des informations relatives au centre de coûts figurant sur la commande d’achat. Cette dimension est essentielle au Dashboard Departmental PO Processing Efficiency, qui permet de comparer directement les délais de traitement et les variantes du processus entre les différents services. Elle aide à identifier les services qui appliquent les meilleures pratiques et ceux qui pourraient nécessiter une formation ou des améliorations du processus. Elle est également indispensable au calcul du KPI Departmental PO Cycle Time Variance. Pourquoi c’est important Permet de comparer les performances entre différentes unités opérationnelles, afin d’identifier les goulots d’étranglement des services et de partager les bonnes pratiques. Où les obtenir Ces informations se trouvent au niveau de l’en-tête ou des lignes de la commande d’achat, souvent associées au centre de coûts ou au profil du demandeur. Exemples MarketingOpérations informatiquesGestion des installationsRecherche et développement
	Comporte une reprise IsRework	Un indicateur calculé qui précise si un Purchase Order a suivi une boucle de reprise, par exemple après un rejet et une nouvelle soumission.
Description Cet attribut booléen est dérivé de la séquence des activités. Il prend la valeur « true » lorsqu’un Purchase Order revient en arrière dans le processus, par exemple lorsqu’une activité « Approve Purchase Order » est suivie d’une activité « Change Purchase Order », puis d’une nouvelle approbation. Cela indique un écart par rapport au processus idéal, exécuté sans interruption. Cet indicateur est essentiel pour calculer le KPI de taux de boucles de reprise des POs et pour filtrer la carte de processus afin de mettre en évidence les flux inefficaces. En identifiant les cas comportant une reprise, les analystes peuvent rechercher les causes profondes, telles qu’une saisie incorrecte ou des exigences imprécises, puis améliorer le taux d’approbation dès la première soumission. Pourquoi c’est important Signale directement les cas présentant des inefficacités ou des reprises, ce qui permet d’en mesurer l’incidence et de cibler les boucles à supprimer. Où les obtenir Cet attribut n’est pas présent dans le système source. Il est calculé lors de la transformation des données à partir de la séquence des activités de chaque cas. Exemples truefalse
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière actualisation ou extraction des données de cet événement depuis le système source.
Description Cet attribut fournit la date et l’heure de la dernière extraction des données depuis SAP Ariba. Il s’agit d’un élément de métadonnées essentiel pour évaluer l’actualité des données analysées. Dans toute analyse de Process Mining, il est essentiel de connaître la date de mise à jour des données pour établir des rapports et prendre des décisions. Cet horodatage permet de vérifier que vos Dashboards et vos KPI, comme Purchase Order Throughput Trend, reposent sur des informations à jour. Pourquoi c’est important Indique l’actualité des données, afin que les utilisateurs comprennent la date de leur analyse et puissent accorder leur confiance aux résultats. Où les obtenir Cet horodatage est généralement généré et ajouté au jeu de données lors du processus d’extraction, de transformation et de chargement (ETL). Exemples 2023-10-27T02:00:00Z2023-10-28T02:00:00Z
	Devise DocumentCurrency	Le code devise des montants monétaires figurant sur le Purchase Order.
Description Cet attribut indique la devise, par exemple USD, EUR ou GBP, dans laquelle le montant du Purchase Order est exprimé. Il fournit un contexte indispensable pour toute donnée financière. Lorsqu’un processus couvre plusieurs pays ou régions, la devise du document est essentielle pour interpréter et comparer correctement les montants. Tous les KPI financiers et Dashboards doivent utiliser ce champ afin de filtrer une devise unique ou d’appliquer les taux de change appropriés pour obtenir des agrégations et des comparaisons exactes. Pourquoi c’est important Fournit le contexte nécessaire à tous les champs monétaires, garantit la fiabilité de l’analyse financière et évite d’additionner à tort des montants exprimés dans des devises différentes. Où les obtenir Il s’agit d’un champ standard au niveau de l’en-tête du document Purchase Order dans SAP Ariba. Exemples USDEURGBPJPY
	Écart de livraison DeliveryVariance	La différence de temps calculée entre la date de livraison demandée et la date réelle de réception des marchandises.
Description Cette mesure quantifie la performance de livraison du fournisseur en indiquant si la livraison est en avance ou en retard. Elle est calculée en soustrayant la « RequestedDeliveryDate » de la « GoodsReceiptDate ». Une valeur positive indique un retard, une valeur négative une livraison anticipée et une valeur nulle une livraison dans les délais. Ce calcul constitue la base du Dashboard de performance des livraisons fournisseurs et du KPI d’écart de performance des livraisons fournisseurs. En analysant cet écart par fournisseur, les organisations peuvent identifier les partenaires fiables et ceux qui le sont moins, afin d’éclairer les négociations et les stratégies de gestion des risques fournisseurs. Cette approche va au-delà d’un simple indicateur « à l’heure » ou « en retard » et permet de mesurer l’ampleur des écarts de livraison. Pourquoi c’est important Quantifie la ponctualité des fournisseurs en mesurant précisément l’avance ou le retard des livraisons, un élément essentiel pour piloter leur performance. Où les obtenir Calculé dans la couche de transformation des données en soustrayant la « RequestedDeliveryDate » de la « GoodsReceiptDate ». Exemples P2D-P1DP0D
	Groupe de marchandises MaterialGroup	Une classification permettant de regrouper des marchandises ou des services présentant des caractéristiques similaires.
Description Le groupe de marchandises, appelé Commodity Code dans la terminologie d’Ariba, permet de catégoriser les articles achetés. Il facilite l’analyse des dépenses et l’application de stratégies d’approvisionnement adaptées aux différents types de biens ou de services. Dans le Process Mining, cet attribut permet d’analyser le processus en fonction de ce qui est acheté. Par exemple, le processus d’approbation de matériel informatique peut différer de celui des fournitures de bureau. Cette approche fournit des analyses plus précises et permet d’adapter les améliorations à chaque catégorie d’achat. Pourquoi c’est important Permet d’analyser le processus selon la catégorie de biens ou de services achetés et de mettre en évidence les différences dans la manière dont les articles sont approvisionnés. Où les obtenir Il s’agit d’un champ standard au niveau du poste d’un Purchase Order, souvent intitulé « Commodity Code ». Exemples Matériel informatiqueFournitures de bureauServices professionnels
	Heure de fin de l’événement EventEndTime	Horodatage indiquant le moment où une activité a été terminée. Il est utilisé pour calculer le temps de traitement des activités manuelles.
Description Alors que StartTime indique le début d’une activité, EventEndTime en marque la fin. Pour de nombreux événements générés par le système, les heures de début et de fin sont identiques. En revanche, pour les tâches manuelles ou les traitements automatisés de longue durée, l’écart entre l’heure de début et l’heure de fin correspond au temps de traitement de l’activité. Cet attribut sert à calculer la métrique « ProcessingTime », essentielle au Dashboard Purchase Order Activity Duration Analysis. Il aide à repérer les tâches qui prennent le plus de temps et à mettre en évidence les possibilités de formation, de réaffectation des Ressources ou d’automatisation. Pourquoi c’est important Permet de calculer précisément le temps de traitement de chaque activité et d’identifier les tâches qui prennent le plus de temps. Où les obtenir Consultez la documentation SAP Ariba. Si cette information n’est pas disponible explicitement, elle devra peut-être être déduite de l’heure de début de l’activité suivante. Exemples 2023-04-15T10:45:00Z2023-04-16T14:05:30Z2023-05-01T11:00:00Z
	N° de demande d’achat. PurchaseRequisitionNumber	L’identifiant unique de la demande d’achat à l’origine du Purchase Order.
Description Cet attribut relie le Purchase Order à la demande d’achat dont il est issu. Tous les Purchase Orders ne sont pas précédés d’une demande, notamment lorsqu’ils sont créés directement. Ce lien est essentiel pour analyser l’ensemble du processus d’approvisionnement, de la demande initiale à l’exécution de la commande. Il est requis pour le Dashboard de conversion des demandes d’achat en Purchase Orders et pour le KPI de délai de conversion d’une demande d’achat en Purchase Order. L’analyse de cette relation permet d’identifier les délais entre l’approbation d’une demande et la passation officielle de la commande auprès du fournisseur. Pourquoi c’est important Relie le Purchase Order à la demande initiale et permet une analyse de bout en bout, de la création de la demande à l’exécution de la commande. Où les obtenir Cette information est généralement disponible dans un champ de référence au niveau du poste du Purchase Order. Exemples PR10004567PR10004568PR10004569
	Organisation d’achat PurchasingOrganization	L’unité organisationnelle chargée d’acheter les matériaux et les services et de négocier avec les fournisseurs.
Description L’organisation achats est une entité essentielle de la structure d’approvisionnement, responsable des aspects stratégiques des achats. Plusieurs organisations achats peuvent coexister selon les régions ou les unités opérationnelles. L’analyse du processus par organisation achats peut révéler des écarts d’efficacité, de conformité et de stratégie de gestion des fournisseurs au sein de l’entreprise. Elle peut contribuer à standardiser les bonnes pratiques et à identifier les goulots d’étranglement ou les sources d’inefficacité à l’échelle de l’organisation. Pourquoi c’est important Permet d’analyser à un niveau global l’efficacité et la conformité des processus entre les différentes unités d’achat stratégiques. Où les obtenir Il s’agit d’un champ de données organisationnelles standard au niveau de l’en-tête du document Purchase Order. Exemples PO_US01PO_EMEAPO_GLOBAL
	PO modifié IsPurchaseOrderChanged	Un indicateur booléen précisant si le Purchase Order a été modifié après sa création initiale.
Description Cet attribut dérivé prend la valeur « true » lorsqu’une activité « Purchase Order Changed » existe pour un cas donné. Il simplifie l’analyse du taux de modification en fournissant un indicateur simple au niveau du cas. Cet indicateur sert à calculer le KPI de taux de modification des Purchase Orders. Il permet de segmenter rapidement les données afin de comparer les processus des commandes modifiées et non modifiées, ce qui peut révéler les conséquences en aval des modifications, comme des temps de cycle plus longs ou davantage d’écarts de facturation. Le Dashboard d’analyse du taux de modification des Purchase Orders l’utilise pour quantifier la fréquence des modifications. Pourquoi c’est important Fournit un indicateur simple pour identifier tous les Purchase Orders modifiés, ce qui facilite le calcul du taux de modification et l’analyse de ses effets. Où les obtenir Cet indicateur est dérivé lors de la transformation des données en vérifiant la présence d’un événement « Purchase Order Changed » pour chaque numéro de Purchase Order. Exemples truefalse
	Statut du Purchase Order PurchaseOrderStatus	Le statut actuel du Purchase Order dans son cycle de vie.
Description Cet attribut indique l’état actuel du Purchase Order, par exemple « Ordering », « Receiving », « Invoiced » ou « Completed ». Il donne une vue instantanée de la position du PO dans le processus global. Le Process Mining reconstitue le flux à partir des activités, mais le statut actuel reste utile pour filtrer les cas et comprendre la charge de travail en cours. Par exemple, un analyste peut souhaiter se concentrer uniquement sur les Purchase Orders « In-Flight » qui ne sont pas encore terminés. Cet attribut peut également servir à valider la dernière activité d’une trace de processus. Pourquoi c’est important Donne rapidement la position d’un Purchase Order dans son cycle de vie, ce qui facilite le filtrage et le suivi des cas actifs ou terminés. Où les obtenir Il s’agit d’un champ de statut standard dans l’en-tête du document Purchase Order de SAP Ariba. Exemples Commande en coursRéception en coursTerminéeAnnulée
	Système source SourceSystem	Identifie le système depuis lequel les données ont été extraites, en l’occurrence SAP Ariba.
Description Cet attribut précise l’origine des données du processus. Dans les environnements comprenant plusieurs systèmes intégrés, il est essentiel pour distinguer les données provenant de différentes sources et garantir leur traçabilité. Pour l’analyse, il permet de filtrer les données d’un système donné ou de comprendre les interactions entre les processus de différentes plateformes. Il constitue un élément clé des métadonnées pour la gouvernance et la validation des données, en garantissant que les analyses reposent sur le jeu de données approprié. Pourquoi c’est important Fournit un contexte essentiel sur l’origine des données, indispensable à leur gouvernance, à leur validation et à leur analyse dans les environnements multisystèmes. Où les obtenir Il s’agit d’une valeur statique (« SAP Ariba »), généralement ajoutée lors de l’extraction et de la transformation des données. Exemples SAP AribaSAP-Ariba-USAribaCloud
	Temps de cycle de bout en bout du PO POEndToEndCycleTime	Le temps total écoulé entre la création de la première demande d’achat et l’achèvement final du Purchase Order.
Description Cet attribut calculé mesure la durée totale de l’ensemble du processus de Purchase Order. Il commence généralement par l’événement « Purchase Requisition Created » et se termine par l’événement « Purchase Order Completed » ou par le dernier événement « Goods Receipt Posted ». Il fournit une vue globale de l’efficacité du processus. Il s’agit de la mesure principale du KPI « End-to-End PO Cycle Time » et du Dashboard « Purchase Order End-to-End Cycle Time ». Elle permet aux organisations de suivre leur performance globale et l’incidence des améliorations apportées au processus. La ventilation de ce temps de cycle total par fournisseur, service ou groupe de marchandises peut révéler les principaux facteurs responsables des délais longs. Pourquoi c’est important Représente le temps total de traitement d’un Purchase Order et fournit une mesure globale de l’efficacité du processus et de l’expérience client. Où les obtenir Calculé lors de la transformation des données en prenant la différence entre l’horodatage le plus ancien et l’horodatage le plus récent d’un cas donné. Exemples P15DP30D12HP7D
	Type de Purchase Order PurchaseOrderType	Une classification du Purchase Order, par exemple standard, accord-cadre ou sous-traitance.
Description Le type de commande d’achat catégorise les commandes selon leur finalité métier. Les différents types de commandes peuvent suivre des parcours distincts et être soumis à des règles différentes en matière d’approbation et d’exécution. Cet attribut permet de segmenter le processus pour obtenir des analyses plus pertinentes. Par exemple, l’analyse séparée du temps de cycle des « PO standard » et des « PO de services » peut révéler des goulots d’étranglement différents. Elle aide à constituer des sous-ensembles de données plus homogènes et à mieux comprendre certains scénarios d’approvisionnement. Pourquoi c’est important Permet de segmenter l’analyse par type de commande et d’obtenir des résultats plus précis, car les différents types suivent souvent des flux de processus distincts. Où les obtenir Consultez la documentation SAP Ariba. Il s’agit généralement d’un champ configurable au niveau de l’en-tête du PO. Exemples Commande standardCommande de servicesCommande forfaitaire

Obligatoire Recommandé Facultatif

Purchase to Pay - Purchase Order : activités

Voici les principales étapes et les jalons du processus à enregistrer dans votre journal d’événements pour découvrir précisément votre processus Purchase to Pay - Purchase Order.

6 Recommandé 8 Facultatif

	Activité	Description
	Commande d’achat approuvée	Indique que la commande d’achat a reçu toutes les approbations internes nécessaires et peut être envoyée au fournisseur. Cet événement est déduit du changement de statut du document PO, qui passe à « Approuvé » après l’achèvement du flux de travail défini.
Pourquoi c’est important Il s’agit d’une étape essentielle pour mesurer les temps de cycle d’approbation et repérer les goulots d’étranglement lors de la revue managériale. Les retards à ce stade ont une incidence directe sur les délais fournisseurs et l’efficacité des achats. Où les obtenir Déduit de l’horodatage correspondant au passage du statut du document PurchaseOrder ou de son champ « ApprovedState » au statut « Approved ». Les journaux d’historique des approbations fournissent des données détaillées. Collecte Déduit de l’horodatage de la dernière action d’approbation dans le flux d’approbation de la PO. Type d’événement inferred
	Commande d’achat créée	Cette activité correspond à la création du document officiel de commande d’achat dans SAP Ariba, à partir d’une demande approuvée ou directement. Elle est enregistrée à partir de l’horodatage de création du document de commande, qui marque le début officiel de son cycle de vie.
Pourquoi c’est important Pour les commandes d’achat directes, il s’agit du début du processus. Cette étape est essentielle pour mesurer le délai de conversion entre la demande et la commande, ainsi que le délai global de traitement de la commande. Où les obtenir Enregistré à partir de l’horodatage de création de l’objet document PurchaseOrder dans SAP Ariba Buying. À ce stade, le statut est généralement « Composing » ou « Submitted ». Collecte À partir de l’horodatage de création du document de commande d’achat. Type d’événement explicit
	Commande d’achat envoyée au fournisseur	Représente le moment où la commande d’achat approuvée est officiellement transmise au fournisseur, généralement via l’Ariba Network. Cet événement est enregistré lorsque le statut de la commande passe à « Sent » ou « Ordered ».
Pourquoi c’est important Cette étape marque le passage du traitement interne à l’exécution externe. Elle constitue le point de départ pour mesurer le délai du fournisseur et la performance de livraison. Où les obtenir Déduit de l’horodatage correspondant au passage du statut du document PurchaseOrder à « Sent » ou « Ordered ». Il s’agit d’un changement de statut standard dans Ariba. Collecte Déduit de l’horodatage du passage au statut « Sent » ou à un état similaire. Type d’événement inferred
	Commande d’achat terminée	Cette activité marque la fin réussie du cycle de vie de la commande d’achat, indiquant que les marchandises ou les services ont été entièrement reçus et facturés. Elle est déduite du passage du statut de la commande à « Received », « Invoiced » ou à un état final similaire.
Pourquoi c’est important Il s’agit du point final correspondant à la réussite du processus. La mesure du délai nécessaire pour atteindre cet état fournit le délai de traitement de bout en bout, un indicateur essentiel de l’efficacité globale du processus. Où les obtenir Déduit de l’horodatage correspondant au passage du statut de PurchaseOrder à un état final tel que « Received ». La commande est considérée comme terminée lorsque toutes ses lignes ont été entièrement reçues. Collecte Déduit du passage du statut de la commande d’achat à « Received » ou à un état final similaire. Type d’événement inferred
	Demande d’achat créée	Cette activité correspond à la création d’une demande d’achat, c’est-à-dire la demande officielle de biens ou de services qui précède une commande d’achat. Dans SAP Ariba, elle est généralement enregistrée lorsqu’un utilisateur sauvegarde et soumet un nouveau document de demande, ce qui crée un enregistrement explicite avec un horodatage de création.
Pourquoi c’est important Il s’agit du point de départ principal du processus d’approvisionnement. L’analyse du délai entre cet événement et la création de la PO est essentielle pour comprendre le temps de cycle entre la demande et la commande, ainsi que pour repérer les goulots d’étranglement en début de processus. Où les obtenir Cet événement est enregistré à partir de la date de création de l’objet document de demande d’achat dans le module SAP Ariba Buying. Le passage au statut « Submitted » marque souvent le début officiel du processus. Collecte À partir de l’horodatage de création du document de demande d’achat. Type d’événement explicit
	Réception de marchandises enregistrée	Représente la réception physique des marchandises, enregistrée dans SAP Ariba. Il s’agit d’un événement explicite, capturé lorsqu’un utilisateur crée et soumet un document Receipt pour une ligne de commande d’achat.
Pourquoi c’est important Cette étape confirme la livraison et constitue le point final pour mesurer la performance de livraison du fournisseur. Dans le cadre d’un rapprochement à trois niveaux, elle autorise également le paiement de la facture. Où les obtenir Enregistré à partir de l’horodatage de création ou de soumission du document Receipt associé au document PurchaseOrder. Collecte À partir de l’horodatage de soumission du document Goods Receipt. Type d’événement explicit
	Avis d’expédition reçu	Cette activité est enregistrée lorsque le fournisseur envoie un Advance Ship Notice (ASN) via l’Ariba Network, indiquant que les marchandises ont été expédiées. L’ASN contient des informations sur l’expédition, notamment les articles, les quantités et les données de suivi.
Pourquoi c’est important L’ASN offre une visibilité sur la chaîne d’approvisionnement et permet au service réception de se préparer à la livraison. Il constitue une donnée essentielle pour suivre les stocks en transit et prévoir les délais de livraison. Où les obtenir Enregistré à partir de la date de création du document ShipNotice associé aux lignes de la commande d’achat. Collecte À partir de l’horodatage de création du document Advance Ship Notice (ASN). Type d’événement explicit
	Commande d’achat annulée	Représente l’arrêt d’une commande d’achat avant son exécution. Cette décision peut être prise par l’organisation acheteuse ou, dans de rares cas, par le fournisseur.
Pourquoi c’est important Il s’agit d’une exception et d’un point final important du processus. L’analyse des raisons d’annulation des commandes d’achat peut révéler des problèmes de planification, de budget ou de fiabilité des fournisseurs. Où les obtenir Déduit de l’horodatage correspondant au passage du statut du document PurchaseOrder à « Cancelled » ou « Closed ». Collecte Déduit de l’horodatage du passage au statut « Cancelled ». Type d’événement inferred
	Commande d’achat confirmée par le fournisseur	Indique que le fournisseur a reçu et reconnu la commande d’achat, confirmant son intention de l’exécuter. Cet événement est enregistré lorsque le fournisseur soumet un document Order Confirmation via l’Ariba Network, ce qui met à jour le statut de la commande.
Pourquoi c’est important Cette activité confirme que la commande est prise en charge par le fournisseur. Elle permet de suivre sa réactivité et l’exactitude de la commande initiale. Où les obtenir Déduit de l’horodatage correspondant à la mise à jour du statut de PurchaseOrder au statut « Confirmed », après réception d’une confirmation de commande du fournisseur. Collecte À partir de la date de création du document Order Confirmation associé ou d’un changement de statut de la commande d’achat. Type d’événement inferred
	Commande d’achat modifiée	Cette activité enregistre toute modification apportée à une commande d’achat après sa création initiale, par exemple une modification de la quantité, du prix ou de la date de livraison. Une nouvelle version du document PO est créée, ce qui déclenche souvent un nouveau flux de travail d’approbation.
Pourquoi c’est important Le suivi des modifications est essentiel pour identifier les inefficacités du processus, les boucles de reprise et les causes profondes des erreurs d’approvisionnement. Un taux de modification élevé peut révéler une collecte initiale des besoins insuffisante. Où les obtenir En identifiant plusieurs versions du même document PurchaseOrder. Chaque nouvelle version possède un horodatage de création qui peut être utilisé pour cet événement. Collecte Enregistré lorsqu’une nouvelle version du document de commande d’achat est créée et sauvegardée. Type d’événement explicit
	Confirmation des services saisie	Représente la confirmation de la réalisation des services, équivalente à une réception de marchandises pour les prestations de services. Elle est enregistrée lorsqu’une Service Sheet est créée et approuvée pour une commande d’achat de services.
Pourquoi c’est important Cette activité est essentielle pour suivre l’exécution des commandes de services et autoriser le paiement. L’analyse de son délai permet de mieux gérer la prestation et les dépenses associées. Où les obtenir Enregistré à partir de l’horodatage d’approbation du document ServiceSheet associé au document PurchaseOrder. Collecte À partir de l’horodatage d’approbation du document Service Sheet. Type d’événement explicit
	Demande d’achat approuvée	Représente l’approbation finale d’une demande d’achat par toutes les parties prenantes requises, autorisant sa conversion en commande d’achat. Cet événement est généralement déduit du passage du document de demande au statut « Approved » et de l’horodatage de cette approbation finale.
Pourquoi c’est important Cette étape marque la fin de la phase d’approbation interne de la demande. Son suivi permet de mesurer l’efficacité des contrôles internes et des flux de travail d’approbation avant la création de la PO. Où les obtenir Déduit de l’historique des approbations ou du champ de statut du document de demande. L’horodatage de l’événement correspond à la date du passage au statut « Approved ». Collecte Déduit de l’horodatage correspondant au passage du champ « ApprovedState » de la demande au statut « Approved ». Type d’événement inferred
	Facture reçue pour une commande d’achat	Indique qu’une facture du fournisseur faisant référence à la commande d’achat a été reçue et saisie dans SAP Ariba. Cet événement relie le processus d’approvisionnement au processus de paiement qui suit.
Pourquoi c’est important Cette activité constitue un point d’intégration important entre les achats et la finance. Son délai est déterminant pour la gestion du besoin en fonds de roulement et le paiement ponctuel des fournisseurs. Où les obtenir Enregistré à partir de l’horodatage de création du document Invoice dans Ariba Invoicing, qui contient une référence au document PurchaseOrder. Collecte À partir de l’horodatage de création du document de facture associé à la commande d’achat. Type d’événement explicit
	Marchandises retournées au fournisseur	Cette activité enregistre le retour de marchandises au fournisseur, généralement en raison de dommages, de défauts ou de la livraison d’articles incorrects. Elle est enregistrée lorsqu’un document de réception de retour ou un avoir est créé pour la réception initiale des marchandises.
Pourquoi c’est important Le suivi des retours met en évidence les problèmes liés à la qualité des fournisseurs et à l’exactitude des livraisons. L’analyse de la fréquence et des motifs des retours peut contribuer à améliorer la sélection et la gestion des fournisseurs. Où les obtenir Cet événement peut être déduit de la création d’un document de réception spécifique aux retours ou de la présence d’une quantité négative dans une réception. Le mécanisme précis peut varier selon la configuration. Collecte Déduit de la création d’une réception avec une quantité négative ou un type spécifique « Return ». Type d’événement inferred

Recommandé Facultatif

Guides d'extraction

Comment extraire vos données de SAP Ariba

Étapes

Accéder aux rapports analytiques : Connectez-vous à votre instance SAP Ariba avec un utilisateur disposant des autorisations d'administrateur des rapports ou d'utilisateur des rapports. Accédez au Dashboard des rapports en cliquant sur Manage > Analytical Reporting.
Créer un nouveau rapport : Cliquez sur le bouton Create, puis sélectionnez Report. Parmi les options disponibles, choisissez Transactional Report afin de créer un rapport fondé sur des données transactionnelles.
Sélectionner le modèle de données (Fact) : Choisissez le modèle de données approprié contenant les données d'approvisionnement. Il s'agit souvent de Procurement Workspace Data, Sourcing and Procurement Data ou d'un Fact personnalisé similaire, tel que [Your Procurement Data Mart]. Sélectionnez ce modèle comme base de votre rapport.
Ajouter le contenu du rapport (Facts et Dimensions) : Dans le panneau Data Fields, faites pivoter le rapport en ajoutant les objets nécessaires à la requête. Incluez au minimum les Facts Purchase Order, Purchase Requisition, Receipt, Invoice et User. Faites glisser les champs requis de ces objets vers la section Report Columns.
Définir les colonnes du rapport : Ajoutez tous les champs nécessaires à la construction de l'Event Log. Il s'agira d'un export « large » que vous transformerez ultérieurement. Incluez :
- Purchase Order.ID (as PurchaseOrderNumber)
- Purchase Requisition.Time Created
- Purchase Requisition.Approved Date
- Purchase Order.Time Created
- Purchase Order.Approved Date
- Purchase Order.Version Time Created (for changes)
- Purchase Order.Ordered Date (for Sent to Vendor)
- Order Confirmation.Confirmation Date
- Advance Ship Notice.Time Created
- Receipt.Receipt Date (as GoodsReceiptDate)
- Service Sheet.Approved Date
- Invoice.Time Created
- Purchase Order.Closed Date (for Completed)
- Purchase Order.Canceled Date
- Ajoutez également User.Name, Department.Name, Supplier.Name, Purchase Order.Total Cost et Purchase Order.Req Delivery Date.
Définir les filtres du rapport : Accédez à l'onglet Filters. Définissez un filtre sur l'horodatage principal afin de limiter le volume de données. Un choix courant consiste à sélectionner Purchase Order.Time Created sur les 3 à 6 derniers mois. Ajoutez d'autres filtres importants, tels que Company Code ou Purchasing Organization, afin de limiter les données à votre périmètre d'analyse.
Enregistrer et exécuter le rapport : Enregistrez le rapport sous un nom explicite, tel que ProcessMind_P2P_PO_Extraction. Pour les volumes importants, utilisez l'option Schedule afin d'exécuter le rapport pendant la nuit et d'éviter tout impact sur les performances. Ne l'exécutez pas immédiatement.
Exporter les données du rapport : Une fois le rapport exécuté, accédez à vos rapports planifiés, localisez l'instance terminée et téléchargez le résultat. Choisissez CSV comme format d'export pour assurer la meilleure compatibilité avec les outils de transformation des données.
Transformer les données : Le fichier CSV exporté sera au format large, avec une ligne par PO. Vous devez le transformer en Event Log au format long. Utilisez un outil tel que Microsoft Excel Power Query, Python ou un outil ETL dédié pour « dépivoter » les colonnes de dates. Pour chaque ligne du fichier d'origine, créez plusieurs lignes dans le nouveau fichier, une pour chaque colonne de date non vide. Chaque nouvelle ligne contiendra PurchaseOrderNumber, ActivityName, dérivé de l'en-tête de la colonne d'origine, et EventTime, correspondant à la valeur de cette colonne de date.
Finaliser et importer : Vérifiez que le fichier CSV final transformé contient les en-têtes de colonnes requis, notamment PurchaseOrderNumber, ActivityName et EventTime. Le fichier est désormais prêt à être importé dans votre plateforme de Process Mining.

Configuration

Prérequis : Un compte utilisateur disposant des autorisations « Reporting User » ou « Reporting Administrator » est nécessaire pour créer, exécuter et planifier des rapports analytiques.
Type de rapport : Utilisez un Transactional Report. Il vous permet de combiner plusieurs Facts, par exemple les PO, les Requisitions et les Invoices, dans un même rapport, ce qui est nécessaire pour couvrir le processus de bout en bout.
Modèle de données (Fact) : Le rapport doit reposer sur un data mart d'approvisionnement complet, tel que Procurement Workspace Data ou un équivalent personnalisé, qui relie les Purchase Orders aux documents associés.
Filtrage par période : Appliquez toujours un filtre de date afin de limiter la taille du jeu de données. Pour commencer, il est recommandé de filtrer sur Purchase Order Creation Date pour les activités des 3 à 6 derniers mois.
Filtres de données clés : Pour garantir la pertinence des données et maîtriser le volume, filtrez par Company Code et/ou Purchasing Organization. Vous limitez ainsi l'extraction à certaines unités opérationnelles.
Considérations de performance : Pour les jeux de données dépassant plusieurs dizaines de milliers de Purchase Orders, planifiez toujours l'exécution du rapport en dehors des heures de pointe. L'exécution à la demande de rapports volumineux et complexes peut dégrader les performances du système pour l'ensemble des utilisateurs.

a Exemple de requête sql

/*
This is a conceptual SQL query representing the logic to be built in the SAP Ariba Analytical Reporting UI.
The final output is a single CSV file that is later transformed into an event log.
The Ariba UI does not use SQL directly; this query illustrates the required data structure and joins.
*/

-- Activity: Purchase Requisition Created
SELECT
  po.PO_NUMBER AS "PurchaseOrderNumber",
  'Purchase Requisition Created' AS "ActivityName",
  pr.CREATION_TIME AS "EventTime",
  pr_creator.USER_NAME AS "UserName",
  dept.DEPARTMENT_NAME AS "DepartmentName",
  vendor.VENDOR_NAME AS "VendorName",
  po.TOTAL_AMOUNT AS "PurchaseOrderAmount",
  po.REQUESTED_DELIVERY_DATE AS "RequestedDeliveryDate",
  NULL AS "GoodsReceiptDate"
FROM [Ariba.POHeader] po
LEFT JOIN [Ariba.PRHeader] pr ON po.PR_ID = pr.PR_ID
LEFT JOIN [Ariba.Users] pr_creator ON pr.CREATED_BY_USER_ID = pr_creator.USER_ID
LEFT JOIN [Ariba.Departments] dept ON po.DEPARTMENT_ID = dept.DEPT_ID
LEFT JOIN [Ariba.Vendors] vendor ON po.VENDOR_ID = vendor.VENDOR_ID
WHERE po.CREATION_TIME BETWEEN '[START_DATE]' AND '[END_DATE]' AND po.COMPANY_CODE IN ('[Your Company Code]')

UNION ALL

-- Activity: Purchase Requisition Approved
SELECT
  po.PO_NUMBER AS "PurchaseOrderNumber",
  'Purchase Requisition Approved' AS "ActivityName",
  pr.APPROVAL_TIME AS "EventTime",
  pr_approver.USER_NAME AS "UserName",
  dept.DEPARTMENT_NAME AS "DepartmentName",
  vendor.VENDOR_NAME AS "VendorName",
  po.TOTAL_AMOUNT AS "PurchaseOrderAmount",
  po.REQUESTED_DELIVERY_DATE AS "RequestedDeliveryDate",
  NULL AS "GoodsReceiptDate"
FROM [Ariba.POHeader] po
LEFT JOIN [Ariba.PRHeader] pr ON po.PR_ID = pr.PR_ID
LEFT JOIN [Ariba.Users] pr_approver ON pr.APPROVED_BY_USER_ID = pr_approver.USER_ID
LEFT JOIN [Ariba.Departments] dept ON po.DEPARTMENT_ID = dept.DEPT_ID
LEFT JOIN [Ariba.Vendors] vendor ON po.VENDOR_ID = vendor.VENDOR_ID
WHERE po.CREATION_TIME BETWEEN '[START_DATE]' AND '[END_DATE]' AND po.COMPANY_CODE IN ('[Your Company Code]') AND pr.APPROVAL_TIME IS NOT NULL

UNION ALL

-- Activity: Purchase Order Created
SELECT
  po.PO_NUMBER AS "PurchaseOrderNumber",
  'Purchase Order Created' AS "ActivityName",
  po.CREATION_TIME AS "EventTime",
  po_creator.USER_NAME AS "UserName",
  dept.DEPARTMENT_NAME AS "DepartmentName",
  vendor.VENDOR_NAME AS "VendorName",
  po.TOTAL_AMOUNT AS "PurchaseOrderAmount",
  po.REQUESTED_DELIVERY_DATE AS "RequestedDeliveryDate",
  NULL AS "GoodsReceiptDate"
FROM [Ariba.POHeader] po
LEFT JOIN [Ariba.Users] po_creator ON po.CREATED_BY_USER_ID = po_creator.USER_ID
LEFT JOIN [Ariba.Departments] dept ON po.DEPARTMENT_ID = dept.DEPT_ID
LEFT JOIN [Ariba.Vendors] vendor ON po.VENDOR_ID = vendor.VENDOR_ID
WHERE po.CREATION_TIME BETWEEN '[START_DATE]' AND '[END_DATE]' AND po.COMPANY_CODE IN ('[Your Company Code]')

UNION ALL

-- Activity: Purchase Order Approved
SELECT
  po.PO_NUMBER AS "PurchaseOrderNumber",
  'Purchase Order Approved' AS "ActivityName",
  po.APPROVAL_TIME AS "EventTime",
  po_approver.USER_NAME AS "UserName",
  dept.DEPARTMENT_NAME AS "DepartmentName",
  vendor.VENDOR_NAME AS "VendorName",
  po.TOTAL_AMOUNT AS "PurchaseOrderAmount",
  po.REQUESTED_DELIVERY_DATE AS "RequestedDeliveryDate",
  NULL AS "GoodsReceiptDate"
FROM [Ariba.POHeader] po
LEFT JOIN [Ariba.Users] po_approver ON po.APPROVED_BY_USER_ID = po_approver.USER_ID
LEFT JOIN [Ariba.Departments] dept ON po.DEPARTMENT_ID = dept.DEPT_ID
LEFT JOIN [Ariba.Vendors] vendor ON po.VENDOR_ID = vendor.VENDOR_ID
WHERE po.CREATION_TIME BETWEEN '[START_DATE]' AND '[END_DATE]' AND po.COMPANY_CODE IN ('[Your Company Code]') AND po.APPROVAL_TIME IS NOT NULL

UNION ALL

-- Activity: Purchase Order Changed
SELECT
  po.PO_NUMBER AS "PurchaseOrderNumber",
  'Purchase Order Changed' AS "ActivityName",
  ver.VERSION_CREATION_TIME AS "EventTime",
  changer.USER_NAME AS "UserName",
  dept.DEPARTMENT_NAME AS "DepartmentName",
  vendor.VENDOR_NAME AS "VendorName",
  po.TOTAL_AMOUNT AS "PurchaseOrderAmount",
  po.REQUESTED_DELIVERY_DATE AS "RequestedDeliveryDate",
  NULL AS "GoodsReceiptDate"
FROM [Ariba.POHeader] po
INNER JOIN [Ariba.POVersions] ver ON po.PO_ID = ver.PO_ID AND ver.VERSION_NUMBER > 1
LEFT JOIN [Ariba.Users] changer ON ver.CHANGED_BY_USER_ID = changer.USER_ID
LEFT JOIN [Ariba.Departments] dept ON po.DEPARTMENT_ID = dept.DEPT_ID
LEFT JOIN [Ariba.Vendors] vendor ON po.VENDOR_ID = vendor.VENDOR_ID
WHERE po.CREATION_TIME BETWEEN '[START_DATE]' AND '[END_DATE]' AND po.COMPANY_CODE IN ('[Your Company Code]')

UNION ALL

-- Activity: Purchase Order Sent To Vendor
SELECT
  po.PO_NUMBER AS "PurchaseOrderNumber",
  'Purchase Order Sent To Vendor' AS "ActivityName",
  po.ORDERED_TIME AS "EventTime",
  sender.USER_NAME AS "UserName",
  dept.DEPARTMENT_NAME AS "DepartmentName",
  vendor.VENDOR_NAME AS "VendorName",
  po.TOTAL_AMOUNT AS "PurchaseOrderAmount",
  po.REQUESTED_DELIVERY_DATE AS "RequestedDeliveryDate",
  NULL AS "GoodsReceiptDate"
FROM [Ariba.POHeader] po
LEFT JOIN [Ariba.Users] sender ON po.ORDERED_BY_USER_ID = sender.USER_ID
LEFT JOIN [Ariba.Departments] dept ON po.DEPARTMENT_ID = dept.DEPT_ID
LEFT JOIN [Ariba.Vendors] vendor ON po.VENDOR_ID = vendor.VENDOR_ID
WHERE po.CREATION_TIME BETWEEN '[START_DATE]' AND '[END_DATE]' AND po.COMPANY_CODE IN ('[Your Company Code]') AND po.ORDERED_TIME IS NOT NULL

UNION ALL

-- Activity: Vendor Confirmed Purchase Order
SELECT
  po.PO_NUMBER AS "PurchaseOrderNumber",
  'Vendor Confirmed Purchase Order' AS "ActivityName",
  oc.CONFIRMATION_TIME AS "EventTime",
  'System/Vendor' AS "UserName",
  dept.DEPARTMENT_NAME AS "DepartmentName",
  vendor.VENDOR_NAME AS "VendorName",
  po.TOTAL_AMOUNT AS "PurchaseOrderAmount",
  po.REQUESTED_DELIVERY_DATE AS "RequestedDeliveryDate",
  NULL AS "GoodsReceiptDate"
FROM [Ariba.POHeader] po
INNER JOIN [Ariba.OrderConfirmations] oc ON po.PO_ID = oc.PO_ID
LEFT JOIN [Ariba.Departments] dept ON po.DEPARTMENT_ID = dept.DEPT_ID
LEFT JOIN [Ariba.Vendors] vendor ON po.VENDOR_ID = vendor.VENDOR_ID
WHERE po.CREATION_TIME BETWEEN '[START_DATE]' AND '[END_DATE]' AND po.COMPANY_CODE IN ('[Your Company Code]') AND oc.CONFIRMATION_TIME IS NOT NULL

UNION ALL

-- Activity: Advance Ship Notice Received
SELECT
  po.PO_NUMBER AS "PurchaseOrderNumber",
  'Advance Ship Notice Received' AS "ActivityName",
  asn.CREATION_TIME AS "EventTime",
  'System/Vendor' AS "UserName",
  dept.DEPARTMENT_NAME AS "DepartmentName",
  vendor.VENDOR_NAME AS "VendorName",
  po.TOTAL_AMOUNT AS "PurchaseOrderAmount",
  po.REQUESTED_DELIVERY_DATE AS "RequestedDeliveryDate",
  NULL AS "GoodsReceiptDate"
FROM [Ariba.POHeader] po
INNER JOIN [Ariba.ASNs] asn ON po.PO_ID = asn.PO_ID
LEFT JOIN [Ariba.Departments] dept ON po.DEPARTMENT_ID = dept.DEPT_ID
LEFT JOIN [Ariba.Vendors] vendor ON po.VENDOR_ID = vendor.VENDOR_ID
WHERE po.CREATION_TIME BETWEEN '[START_DATE]' AND '[END_DATE]' AND po.COMPANY_CODE IN ('[Your Company Code]') AND asn.CREATION_TIME IS NOT NULL

UNION ALL

-- Activity: Goods Receipt Posted
SELECT
  po.PO_NUMBER AS "PurchaseOrderNumber",
  'Goods Receipt Posted' AS "ActivityName",
  rcpt.RECEIPT_TIME AS "EventTime",
  receiver.USER_NAME AS "UserName",
  dept.DEPARTMENT_NAME AS "DepartmentName",
  vendor.VENDOR_NAME AS "VendorName",
  po.TOTAL_AMOUNT AS "PurchaseOrderAmount",
  po.REQUESTED_DELIVERY_DATE AS "RequestedDeliveryDate",
  rcpt.RECEIPT_TIME AS "GoodsReceiptDate"
FROM [Ariba.POHeader] po
INNER JOIN [Ariba.Receipts] rcpt ON po.PO_ID = rcpt.PO_ID
LEFT JOIN [Ariba.Users] receiver ON rcpt.CREATED_BY_USER_ID = receiver.USER_ID
LEFT JOIN [Ariba.Departments] dept ON po.DEPARTMENT_ID = dept.DEPT_ID
LEFT JOIN [Ariba.Vendors] vendor ON po.VENDOR_ID = vendor.VENDOR_ID
WHERE po.CREATION_TIME BETWEEN '[START_DATE]' AND '[END_DATE]' AND po.COMPANY_CODE IN ('[Your Company Code]') AND rcpt.RECEIPT_TYPE = 'Goods'

UNION ALL

-- Activity: Services Confirmation Entered
SELECT
  po.PO_NUMBER AS "PurchaseOrderNumber",
  'Services Confirmation Entered' AS "ActivityName",
  ss.APPROVAL_TIME AS "EventTime",
  ss_creator.USER_NAME AS "UserName",
  dept.DEPARTMENT_NAME AS "DepartmentName",
  vendor.VENDOR_NAME AS "VendorName",
  po.TOTAL_AMOUNT AS "PurchaseOrderAmount",
  po.REQUESTED_DELIVERY_DATE AS "RequestedDeliveryDate",
  ss.APPROVAL_TIME AS "GoodsReceiptDate"
FROM [Ariba.POHeader] po
INNER JOIN [Ariba.ServiceSheets] ss ON po.PO_ID = ss.PO_ID
LEFT JOIN [Ariba.Users] ss_creator ON ss.CREATED_BY_USER_ID = ss_creator.USER_ID
LEFT JOIN [Ariba.Departments] dept ON po.DEPARTMENT_ID = dept.DEPT_ID
LEFT JOIN [Ariba.Vendors] vendor ON po.VENDOR_ID = vendor.VENDOR_ID
WHERE po.CREATION_TIME BETWEEN '[START_DATE]' AND '[END_DATE]' AND po.COMPANY_CODE IN ('[Your Company Code]') AND ss.APPROVAL_TIME IS NOT NULL

UNION ALL

-- Activity: Goods Returned To Vendor
SELECT
  po.PO_NUMBER AS "PurchaseOrderNumber",
  'Goods Returned To Vendor' AS "ActivityName",
  rcpt.RECEIPT_TIME AS "EventTime",
  returner.USER_NAME AS "UserName",
  dept.DEPARTMENT_NAME AS "DepartmentName",
  vendor.VENDOR_NAME AS "VendorName",
  po.TOTAL_AMOUNT AS "PurchaseOrderAmount",
  po.REQUESTED_DELIVERY_DATE AS "RequestedDeliveryDate",
  NULL AS "GoodsReceiptDate"
FROM [Ariba.POHeader] po
INNER JOIN [Ariba.Receipts] rcpt ON po.PO_ID = rcpt.PO_ID AND rcpt.RECEIPT_TYPE = 'Return'
LEFT JOIN [Ariba.Users] returner ON rcpt.CREATED_BY_USER_ID = returner.USER_ID
LEFT JOIN [Ariba.Departments] dept ON po.DEPARTMENT_ID = dept.DEPT_ID
LEFT JOIN [Ariba.Vendors] vendor ON po.VENDOR_ID = vendor.VENDOR_ID
WHERE po.CREATION_TIME BETWEEN '[START_DATE]' AND '[END_DATE]' AND po.COMPANY_CODE IN ('[Your Company Code]')

UNION ALL

-- Activity: Invoice Received Against PO
SELECT
  po.PO_NUMBER AS "PurchaseOrderNumber",
  'Invoice Received Against PO' AS "ActivityName",
  inv.CREATION_TIME AS "EventTime",
  'System/AP' AS "UserName",
  dept.DEPARTMENT_NAME AS "DepartmentName",
  vendor.VENDOR_NAME AS "VendorName",
  po.TOTAL_AMOUNT AS "PurchaseOrderAmount",
  po.REQUESTED_DELIVERY_DATE AS "RequestedDeliveryDate",
  NULL AS "GoodsReceiptDate"
FROM [Ariba.POHeader] po
INNER JOIN [Ariba.Invoices] inv ON po.PO_ID = inv.PO_ID
LEFT JOIN [Ariba.Departments] dept ON po.DEPARTMENT_ID = dept.DEPT_ID
LEFT JOIN [Ariba.Vendors] vendor ON po.VENDOR_ID = vendor.VENDOR_ID
WHERE po.CREATION_TIME BETWEEN '[START_DATE]' AND '[END_DATE]' AND po.COMPANY_CODE IN ('[Your Company Code]')

UNION ALL

-- Activity: Purchase Order Completed
SELECT
  po.PO_NUMBER AS "PurchaseOrderNumber",
  'Purchase Order Completed' AS "ActivityName",
  po.COMPLETED_TIME AS "EventTime",
  'System' AS "UserName",
  dept.DEPARTMENT_NAME AS "DepartmentName",
  vendor.VENDOR_NAME AS "VendorName",
  po.TOTAL_AMOUNT AS "PurchaseOrderAmount",
  po.REQUESTED_DELIVERY_DATE AS "RequestedDeliveryDate",
  NULL AS "GoodsReceiptDate"
FROM [Ariba.POHeader] po
LEFT JOIN [Ariba.Departments] dept ON po.DEPARTMENT_ID = dept.DEPT_ID
LEFT JOIN [Ariba.Vendors] vendor ON po.VENDOR_ID = vendor.VENDOR_ID
WHERE po.CREATION_TIME BETWEEN '[START_DATE]' AND '[END_DATE]' AND po.COMPANY_CODE IN ('[Your Company Code]') AND po.STATUS = 'Completed'

UNION ALL

-- Activity: Purchase Order Cancelled
SELECT
  po.PO_NUMBER AS "PurchaseOrderNumber",
  'Purchase Order Cancelled' AS "ActivityName",
  po.CANCELLED_TIME AS "EventTime",
  canceller.USER_NAME AS "UserName",
  dept.DEPARTMENT_NAME AS "DepartmentName",
  vendor.VENDOR_NAME AS "VendorName",
  po.TOTAL_AMOUNT AS "PurchaseOrderAmount",
  po.REQUESTED_DELIVERY_DATE AS "RequestedDeliveryDate",
  NULL AS "GoodsReceiptDate"
FROM [Ariba.POHeader] po
LEFT JOIN [Ariba.Users] canceller ON po.CANCELLED_BY_USER_ID = canceller.USER_ID
LEFT JOIN [Ariba.Departments] dept ON po.DEPARTMENT_ID = dept.DEPT_ID
LEFT JOIN [Ariba.Vendors] vendor ON po.VENDOR_ID = vendor.VENDOR_ID
WHERE po.CREATION_TIME BETWEEN '[START_DATE]' AND '[END_DATE]' AND po.COMPANY_CODE IN ('[Your Company Code]') AND po.STATUS = 'Cancelled'

Étapes

Prérequis : Vérifiez que vous disposez d'un compte développeur SAP Ariba et que vous avez créé une application avec un accès API. Vous aurez besoin de l'API Key, de l'OAuth Client ID et de l'OAuth Client Secret. L'application doit être approuvée et disposer des autorisations nécessaires pour l'Analytical Reporting API.
Configurer la Reporting View : Dans l'interface d'administration SAP Ariba, vérifiez qu'une vue de reporting analytique, également appelée view template, est configurée avec tous les champs nécessaires au cycle de vie du Purchase Order. Cette vue doit relier les données des Requisitions, Purchase Orders, Receipts et Invoices. Notez le nom exact de ce view template, car il est requis pour l'appel API.
Installer les bibliothèques Python : Configurez un environnement Python et installez les bibliothèques nécessaires : requests pour effectuer les appels API et pandas pour manipuler les données. Vous pouvez les installer avec pip : pip install requests pandas.
Configurer le script Python : Copiez le script Python fourni dans un fichier, par exemple ariba_p2p_extractor.py. Renseignez les variables d'espace réservé situées en haut du script avec vos identifiants Ariba, vos points de terminaison API et le nom de votre view template de reporting.
S'authentifier et obtenir un token : La première partie du script gère l'authentification OAuth 2.0. Elle envoie vos identifiants au point de terminaison d'authentification Ariba afin d'obtenir un token d'accès temporaire, requis pour les appels API suivants.
Définir et envoyer le reporting job : Le script construit une charge utile JSON qui définit le reporting job. Cette charge utile précise le view template à utiliser et définit des filtres, notamment une période pour la date de création du Purchase Order. Le script envoie ensuite ce job à l'API de reporting Ariba, qui commence à générer le rapport de manière asynchrone.
Vérifier l'achèvement du job : Comme la génération du rapport est asynchrone, le script lance une boucle de vérification. Il envoie périodiquement des requêtes à l'API pour contrôler l'état du job, jusqu'à ce que son statut passe à Completed.
Télécharger les données du rapport : Une fois le job terminé, le script récupère une URL de téléchargement dans la réponse indiquant son état. Il télécharge ensuite les données du rapport, fournies sous la forme d'un fichier CSV compressé au format GZIP, puis les décompresse.
Transformer les données en Event Log : Le CSV téléchargé est chargé dans un DataFrame pandas. Ces données sont généralement au format large, avec une ligne par Purchase Order. Le script transforme ensuite cette table large en Event Log au format long. Il parcourt les colonnes correspondant aux différents événements métier, par exemple pr.TimeCreated et po.ApprovedDate, et crée une nouvelle ligne pour chaque horodatage valide afin de représenter l'activité correspondante.
Mapper les Attributs : Pendant la transformation, le script renseigne les colonnes requises pour chaque événement : PurchaseOrderNumber (Case ID), ActivityName et EventTime. Il associe également à chaque ligne d'événement d'autres informations pertinentes, telles que UserName, VendorName et PurchaseOrderAmount.
Enregistrer l'Event Log final : Après avoir traité toutes les activités et créé l'Event Log complet, le script trie les données par identifiant de cas et par heure de l'événement. Enfin, il enregistre le DataFrame obtenu dans un fichier CSV nommé ariba_p2p_event_log.csv, prêt à être importé dans un outil de Process Mining.

Configuration

Application API : Une application doit être enregistrée dans le SAP Ariba Developer Portal et disposer d’un accès à l’« Analytical Reporting API ».
Modèle de vue de reporting : Cette méthode repose principalement sur une vue de reporting préconfigurée. Dans Ariba, cette vue doit être configurée pour relier tous les types de documents nécessaires, à savoir la demande d’achat, le bon de commande, la réception, la feuille de service et la facture, puis exposer tous les champs de date et d’attribut requis.
Authentification : Le script utilise OAuth 2.0 pour l’authentification. Vous devez fournir une clé API, un identifiant client et un secret client valides issus de votre application Ariba.
Filtre de période : L’appel API doit inclure un filtre sur la date de création du bon de commande (po.TimeCreated) afin de limiter le périmètre de l’extraction. Une période de 3 à 12 mois est généralement adaptée pour trouver un équilibre entre le niveau de détail et les performances.
Nom du realm : Le nom spécifique du realm Ariba de votre entreprise est nécessaire pour construire les points de terminaison de l’API.
Points de terminaison de l’API : Vérifiez que les URL de base correctes sont utilisées pour l’authentification (api.ariba.com) et le reporting ([your-realm].ariba.com).
Niveau de détail des données : La vue de reporting doit être configurée au niveau de l’en-tête du bon de commande ou du poste, selon le niveau de détail souhaité pour l’analyse du processus.

a Exemple de requête python

import requests
import pandas as pd
import json
import time
import gzip
import io

class=class="hl-string">"hl-comment"># --- Configuration Settings --- #
class=class="hl-string">"hl-comment"># Replace with your SAP Ariba Developer Portal application credentials
API_KEY = class="hl-string">'[Your_API_Key]'
CLIENT_ID = class="hl-string">'[Your_OAuth_Client_ID]'
CLIENT_SECRET = class="hl-string">'[Your_OAuth_Client_Secret]'

class=class="hl-string">"hl-comment"># Replace with your company's Ariba realm information
REALM = class="hl-string">'[Your_Company_Ariba_Realm]'

class=class="hl-string">"hl-comment"># Replace with the exact name of your pre-configured reporting view in Ariba
VIEW_TEMPLATE_NAME = class="hl-string">'[Your_P2P_View_Template]'

class=class="hl-string">"hl-comment"># --- API Endpoints --- #
AUTH_URL = class="hl-string">'https://api.ariba.com/v2/oauth/token'
API_BASE_URL = fclass="hl-string">'https://{REALM}.ariba.com/api/analytics-reporting-view/v1'

class=class="hl-string">"hl-comment"># --- Helper Functions --- #
def get_access_token():
    class="hl-string">"""Authenticates with Ariba and returns an access token."""
    auth_payload = {
        class="hl-string">'grant_type': class="hl-string">'client_credentials',
        class="hl-string">'client_id': CLIENT_ID,
        class="hl-string">'client_secret': CLIENT_SECRET
    }
    try:
        response = requests.post(AUTH_URL, data=auth_payload)
        response.raise_for_status()
        return response.json()[class="hl-string">'access_token']
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting access token: {e}")
        print(fclass="hl-string">"Response body: {response.text}")
        return None

def main():
    class="hl-string">"""Main function to run the extraction process."""
    access_token = get_access_token()
    if not access_token:
        return

    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}',
        class="hl-string">'apiKey': API_KEY,
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }

    class=class="hl-string">"hl-comment"># Define the reporting job with filters
    report_job_payload = {
        class="hl-string">"viewTemplateName": VIEW_TEMPLATE_NAME,
        class="hl-string">"filters": {
            class="hl-string">"createdDateFrom": class="hl-string">"2023-01-01T00:00:00Z",
            class="hl-string">"createdDateTo": class="hl-string">"2023-12-31T23:59:59Z"
        },
        class="hl-string">"outputFormat": class="hl-string">"csv"
    }

    class=class="hl-string">"hl-comment"># 1. Submit the report generation job
    print(class="hl-string">"Submitting report job...")
    try:
        submit_response = requests.post(fclass="hl-string">'{API_BASE_URL}/jobs', headers=headers, json=report_job_payload)
        submit_response.raise_for_status()
        job_id = submit_response.json()[class="hl-string">'jobId']
        print(fclass="hl-string">"Job submitted successfully. Job ID: {job_id}")
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error submitting job: {e}")
        print(fclass="hl-string">"Response body: {submit_response.text}")
        return

    class=class="hl-string">"hl-comment"># 2. Poll for job completion
    while True:
        print(class="hl-string">"Checking job status...")
        try:
            status_response = requests.get(fclass="hl-string">'{API_BASE_URL}/jobs/{job_id}', headers=headers)
            status_response.raise_for_status()
            status = status_response.json()[class="hl-string">'status']
            print(fclass="hl-string">"Current job status: {status}")
            if status == class="hl-string">'COMPLETED':
                download_url = status_response.json()[class="hl-string">'downloadUrl']
                break
            elif status in [class="hl-string">'FAILED', class="hl-string">'NO_DATA']:
                print(fclass="hl-string">"Job finished with status: {status}")
                return
            time.sleep(30)  class=class="hl-string">"hl-comment"># Wait for 30 seconds before polling again
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error checking job status: {e}")
            return

    class=class="hl-string">"hl-comment"># 3. Download the report data
    print(fclass="hl-string">"Job completed. Downloading data from: {download_url}")
    try:
        download_headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {access_token}', class="hl-string">'apiKey': API_KEY}
        data_response = requests.get(download_url, headers=download_headers)
        data_response.raise_for_status()
        class=class="hl-string">"hl-comment"># Decompress the gzipped content
        gzip_file = gzip.GzipFile(fileobj=io.BytesIO(data_response.content))
        df_raw = pd.read_csv(gzip_file)
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error downloading data: {e}")
        return

    class=class="hl-string">"hl-comment"># 4. Transform data into event log
    print(class="hl-string">"Transforming data into event log format...")
    event_log = []

    class=class="hl-string">"hl-comment"># Rename columns for clarity, assuming view template field names like class="hl-string">'Purchase Order Id',
    class=class="hl-string">"hl-comment"># class="hl-string">'Requisition TimeCreated', class="hl-string">'PO ApprovedDate', etc. Adjust these to match your view template.
    class=class="hl-string">"hl-comment"># Placeholder names are used here.
    column_mapping = {
        class="hl-string">'[Purchase Order Id]': class="hl-string">'PurchaseOrderNumber',
        class="hl-string">'[Requisition TimeCreated]': class="hl-string">'pr_created_time',
        class="hl-string">'[Requisition ApprovedDate]': class="hl-string">'pr_approved_time',
        class="hl-string">'[PO TimeCreated]': class="hl-string">'po_created_time',
        class="hl-string">'[PO ApprovedDate]': class="hl-string">'po_approved_time',
        class="hl-string">'[PO LastModifiedDate]': class="hl-string">'po_changed_time',
        class="hl-string">'[PO OrderedDate]': class="hl-string">'po_sent_time',
        class="hl-string">'[PO ConfirmedDate]': class="hl-string">'po_confirmed_time',
        class="hl-string">'[ASN TimeCreated]': class="hl-string">'asn_received_time',
        class="hl-string">'[Receipt Date]': class="hl-string">'goods_receipt_time',
        class="hl-string">'[Service Sheet End Date]': class="hl-string">'service_confirmed_time',
        class="hl-string">'[Return Date]': class="hl-string">'goods_returned_time',
        class="hl-string">'[Invoice Date]': class="hl-string">'invoice_received_time',
        class="hl-string">'[PO CompletedDate]': class="hl-string">'po_completed_time',
        class="hl-string">'[PO CancelledDate]': class="hl-string">'po_cancelled_time',
        class="hl-string">'[PO Submitter]': class="hl-string">'UserName',
        class="hl-string">'[Department Name]': class="hl-string">'DepartmentName',
        class="hl-string">'[Vendor Name]': class="hl-string">'VendorName',
        class="hl-string">'[PO TotalAmount]': class="hl-string">'PurchaseOrderAmount',
        class="hl-string">'[PO DeliveryDate]': class="hl-string">'RequestedDeliveryDate',
        class="hl-string">'[Receipt Date]': class="hl-string">'GoodsReceiptDate'
    }
    df_raw.rename(columns=column_mapping, inplace=True)

    class=class="hl-string">"hl-comment"># Define activities and their corresponding timestamp columns
    activities = {
        class="hl-string">'Purchase Requisition Created': class="hl-string">'pr_created_time',
        class="hl-string">'Purchase Requisition Approved': class="hl-string">'pr_approved_time',
        class="hl-string">'Purchase Order Created': class="hl-string">'po_created_time',
        class="hl-string">'Purchase Order Approved': class="hl-string">'po_approved_time',
        class="hl-string">'Purchase Order Changed': class="hl-string">'po_changed_time',
        class="hl-string">'Purchase Order Sent To Vendor': class="hl-string">'po_sent_time',
        class="hl-string">'Vendor Confirmed Purchase Order': class="hl-string">'po_confirmed_time',
        class="hl-string">'Advance Ship Notice Received': class="hl-string">'asn_received_time',
        class="hl-string">'Goods Receipt Posted': class="hl-string">'goods_receipt_time',
        class="hl-string">'Services Confirmation Entered': class="hl-string">'service_confirmed_time',
        class="hl-string">'Goods Returned To Vendor': class="hl-string">'goods_returned_time',
        class="hl-string">'Invoice Received Against PO': class="hl-string">'invoice_received_time',
        class="hl-string">'Purchase Order Completed': class="hl-string">'po_completed_time',
        class="hl-string">'Purchase Order Cancelled': class="hl-string">'po_cancelled_time'
    }

    for index, row in df_raw.iterrows():
        base_event = {
            class="hl-string">'PurchaseOrderNumber': row.get(class="hl-string">'PurchaseOrderNumber'),
            class="hl-string">'UserName': row.get(class="hl-string">'UserName'),
            class="hl-string">'DepartmentName': row.get(class="hl-string">'DepartmentName'),
            class="hl-string">'VendorName': row.get(class="hl-string">'VendorName'),
            class="hl-string">'PurchaseOrderAmount': row.get(class="hl-string">'PurchaseOrderAmount'),
            class="hl-string">'RequestedDeliveryDate': row.get(class="hl-string">'RequestedDeliveryDate'),
            class="hl-string">'GoodsReceiptDate': row.get(class="hl-string">'GoodsReceiptDate')
        }

        for activity_name, time_col in activities.items():
            if time_col in row and pd.notna(row[time_col]):
                event = base_event.copy()
                event[class="hl-string">'ActivityName'] = activity_name
                event[class="hl-string">'EventTime'] = row[time_col]
                
                class=class="hl-string">"hl-comment"># Special handling for class="hl-string">'Purchase Order Changed'
                class=class="hl-string">"hl-comment"># This event should only be created if it's after the PO creation time
                if activity_name == class="hl-string">'Purchase Order Changed':
                    if pd.notna(row.get(class="hl-string">'po_created_time')) and pd.to_datetime(row[time_col]) > pd.to_datetime(row[class="hl-string">'po_created_time']):
                        event_log.append(event)
                else:
                    event_log.append(event)

    df_event_log = pd.DataFrame(event_log)
    df_event_log[class="hl-string">'EventTime'] = pd.to_datetime(df_event_log[class="hl-string">'EventTime'])
    df_event_log.sort_values(by=[class="hl-string">'PurchaseOrderNumber', class="hl-string">'EventTime'], inplace=True)

    class=class="hl-string">"hl-comment"># 5. Save the final event log
    output_filename = class="hl-string">'ariba_p2p_event_log.csv'
    df_event_log.to_csv(output_filename, index=False, date_format=class="hl-string">'%Y-%m-%dT%H:%M:%SZ')
    print(fclass="hl-string">"Event log successfully created and saved to {output_filename}")

if __name__ == class="hl-string">'__main__':
    main()

Prêt à commencer ?

Utilisez ce modèle pour simplifier la préparation de vos données et commencer à optimiser votre processus Purchase to Pay, commandes d’achat, en toute confiance. Votre démarche vers plus d’efficacité commence ici.

Retour au guide d’amélioration Télécharger le modèle

Optimisez dès aujourd'hui votre processus Purchase to Pay - Purchase Order !

Réduisez de 30 % le temps de cycle et éliminez les goulots d'étranglement dans SAP Ariba.

Démarrer l'essai gratuit

Aucune carte bancaire requise. Configurez votre essai gratuit en quelques minutes.

Votre modèle de données Purchase to Pay, commande d’achat

Votre modèle de données Purchase to Pay, commande d’achat

Purchase to Pay - Purchase Order : attributs

Purchase to Pay - Purchase Order : activités

Guides d'extraction

Export CSV/Excel des rapports analytiques SAP Ariba

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant l'API de reporting SAP Ariba

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez dès aujourd'hui votre processus Purchase to Pay - Purchase Order !

Votre modèle de données Purchase to Pay, commande d’achat

Votre modèle de données Purchase to Pay, commande d’achat

Purchase to Pay - Purchase Order : attributs

Purchase to Pay - Purchase Order : activités

Guides d'extraction

Export CSV/Excel des rapports analytiques SAP Ariba

Étapes

Configuration

a Exemple de requête sql

Script Python utilisant l'API de reporting SAP Ariba

Étapes

Configuration

a Exemple de requête python

Prêt à commencer ?

Optimisez dès aujourd'hui votre processus Purchase to Pay - Purchase Order !

Nous attachons de l’importance à votre confidentialité

Purchase to Pay - Purchase Order : attributs

Purchase to Pay - Purchase Order : activités