> Amélioration continue des processus > Demande d’achat, de la commande au paiement > SAP Ariba > Modèle de données

Votre modèle de données Purchase to Pay - Demande d’achat

SAP Ariba

Attributs Purchase to Pay - Demande d’achat(19) Activités Purchase to Pay - Demande d’achat(13) Guides d’extraction(2)

Votre modèle de données Purchase to Pay - Demande d’achat

Ce modèle de données complet vous aide à recueillir et à structurer efficacement les informations nécessaires à l’analyse de votre processus Purchase to Pay - Demande d’achat. Il présente les attributs et les activités essentiels à la constitution d’un journal d’événements fiable, pour étudier en détail les performances de votre processus. Vous y trouverez également des conseils pratiques pour extraire ces données de votre système source et démarrer votre démarche de Process Mining.

Attributs recommandés pour une analyse complète
Activités et jalons clés du processus à suivre
Conseils détaillés pour extraire les données de votre système

Vous découvrez les journaux d’événements ? Découvrez comment créer un journal d’événements pour le Process Mining.

Télécharger le modèle

Attributs Purchase to Pay - Demande d’achat

Voici les champs de données recommandés pour votre journal d’événements afin d’analyser en détail le processus Purchase to Pay - Demande d’achat et de ne manquer aucune information importante.

3 Obligatoire 8 Recommandé 8 Facultatif

	Nom	Description
	Horodatage de l’événement EventTimestamp	Date et heure précises auxquelles l’activité s’est produite, utilisées pour ordonner les événements.
Description L’horodatage de l’événement indique le moment exact où une activité a eu lieu. Cette précision est indispensable pour ordonner correctement les événements de chaque cas et calculer la durée entre les différentes étapes du processus. Dans les analyses, cet horodatage sert de base à tous les calculs temporels, notamment les temps de cycle, les temps d’attente et les durées de traitement. Il alimente les Dashboards de suivi des performances, comme ceux consacrés au temps de cycle d’approbation des demandes et à l’analyse des goulots d’étranglement des circuits d’approbation. La fiabilité de tous les indicateurs de performance dépend directement de l’exactitude de ce champ. Pourquoi est-ce important ? Cet attribut établit l’ordre chronologique des événements et sert de base aux calculs de performance et de durée, notamment aux temps de cycle et aux goulots d’étranglement. Où trouver ces données Ces données figurent généralement avec les enregistrements d’activité ou de changement de statut dans les pistes d’audit ou les tables de journaux de transactions SAP Ariba. Exemples 2023-10-26T10:00:00Z2023-10-26T11:30:00Z2023-10-27T14:05:00Z
	ID de la demande d’achat PurchaseRequisitionId	Identifiant unique d’un document de demande d’achat, utilisé comme identifiant principal du cas dans le processus.
Description L’ID de la demande d’achat est la clé centrale qui relie toutes les activités associées à une même demande de biens ou de services. Chaque demande créée dans SAP Ariba reçoit un ID unique, conservé tout au long de son cycle de vie, de sa création et de son envoi jusqu’à son approbation, son refus ou sa clôture. Dans une analyse de Process Mining, cet attribut est fondamental pour relier les événements à chaque cas. Il permet de reconstituer le parcours complet de chaque demande, de calculer précisément les temps de cycle, de repérer les variantes du processus et d’analyser les boucles de reprise. Sans cet identifiant, il serait impossible de distinguer les événements associés à différentes demandes. Pourquoi est-ce important ? Cet identifiant essentiel relie toutes les activités associées et permet d’analyser le processus complet de chaque demande. Où trouver ces données Il s’agit d’un champ de clé primaire dans les principales tables d’en-tête des demandes de la structure de données SAP Ariba. Exemples PR-102345PR-102346PR-102347
	Nom de l’activité ActivityName	Nom de l’événement métier qui s’est produit à un moment donné du cycle de vie de la demande.
Description Le nom de l’activité décrit une étape ou un jalon du processus de demande, par exemple « Demande créée », « Étape d’approbation approuvée » ou « Demande clôturée ». Ces données proviennent généralement des journaux d’événements, des changements de statut ou des actions consignées dans SAP Ariba. Cet attribut est indispensable à la création de la carte du processus, qui représente visuellement le déroulement des activités. En analysant leur séquence et leur fréquence, les analystes peuvent repérer les parcours les plus courants, les goulots d’étranglement, les écarts par rapport à la procédure standard et les reprises. Il constitue la base de toute analyse de Process Mining. Pourquoi est-ce important ? Il définit les étapes du processus et permet de visualiser et d’analyser le flux de travail des demandes, notamment les goulots d’étranglement et les écarts. Où trouver ces données Ces données proviennent des journaux d’événements, des pistes d’audit ou des enregistrements de changements de statut dans SAP Ariba. Elles sont souvent associées aux tables d’en-tête des demandes et de leurs lignes. Exemples Demande envoyéeÉtape d’approbation approuvéeDemande modifiéeBon de commande créé
	Catégorie d’article ItemCategory	Classification des biens ou des services demandés, par exemple « Matériel informatique », « Fournitures de bureau » ou « Services professionnels ».
Description La catégorie d’article précise la nature des achats. Cette classification aide à comprendre les habitudes de dépenses et à appliquer des stratégies et des règles d’achat adaptées à chaque catégorie. Dans le Process Mining, cet attribut est essentiel au Dashboard « Analyse des modifications des demandes ». Il peut révéler si certaines catégories d’articles font plus souvent l’objet de modifications, ce qui peut signaler des spécifications imprécises ou des prix instables. Il permet aussi de comparer les performances du processus, comme les délais d’approbation, entre différents types d’achats et de repérer les catégories qui rencontrent davantage de difficultés. Pourquoi est-ce important ? Cet attribut permet d’analyser les processus selon le type de biens ou de services achetés et de repérer les goulots d’étranglement ou les problèmes de conformité propres à certaines catégories. Où trouver ces données Consultez la documentation SAP Ariba. Ces informations figurent généralement au niveau des lignes de la demande d’achat. Exemples Matériel informatiqueServices de conseilFournitures de bureauSupports marketing
	Circuit d’approbation ApprovalWorkflowPath	Séquence prédéfinie des étapes d’approbation que la demande est censée suivre.
Description Cet attribut définit la variante standard du processus ou la matrice d’approbation que la demande doit respecter selon ses caractéristiques, comme son montant, sa catégorie d’article et son service d’origine. Il représente le processus cible ou le parcours nominal. Il est fondamental pour vérifier la conformité et alimente le Dashboard « Vue d’ensemble de la conformité des demandes ». En comparant la séquence réelle des activités au circuit d’approbation attendu, les analystes peuvent détecter automatiquement les infractions aux règles, les étapes d’approbation non autorisées ou les contrôles omis. Cette vérification est essentielle à l’audit interne et à la gestion des risques. Pourquoi est-ce important ? Il définit le processus standard à suivre et permet de détecter automatiquement les écarts et les infractions aux règles lors des contrôles de conformité. Où trouver ces données Consultez la documentation SAP Ariba. Cet attribut peut être déduit de la configuration de la matrice d’approbation ou d’un champ spécifique de la demande. Exemples Informatique standard > 10 000 $Services marketing < 5 000 $Dépenses d’investissement > 100 000 $
	Montant total de la demande TotalRequisitionAmount	Valeur monétaire totale de la demande d’achat.
Description Cet attribut indique la valeur financière totale de la demande. Il apporte un contexte métier important pour classer les demandes et définir leur priorité. La comparaison des indicateurs du processus avec cette valeur peut révéler des tendances utiles. Par exemple, les demandes de montant élevé peuvent suivre des circuits d’approbation différents et plus stricts, ou présenter des temps de cycle plus longs. Cet attribut est essentiel pour comprendre l’incidence financière des inefficacités et répartir les demandes par tranche de valeur afin de les comparer. Pourquoi est-ce important ? Il apporte un contexte financier essentiel et permet d’analyser l’incidence du montant de la demande sur le déroulement du processus, notamment sur les délais d’approbation et la complexité du flux de travail. Où trouver ces données Consultez la documentation SAP Ariba. Il s’agit d’un champ standard de l’en-tête de la demande d’achat. Exemples 1500.0025000.5099.95
	Motif du rejet RejectionReason	Motif indiqué par un approbateur lorsqu’une demande ou une étape d’approbation est rejetée.
Description Lorsqu’une demande est refusée, les approbateurs en indiquent souvent le motif, soit en texte libre, soit en le sélectionnant dans une liste prédéfinie. Cet attribut consigne cette information. Ces données sont au cœur du Dashboard « Analyse du taux de rejet des demandes ». L’analyse des motifs de rejet les plus fréquents aide à repérer les causes des échecs du processus, comme une imputation incorrecte, une justification insuffisante ou un problème de budget. Ces résultats peuvent ensuite servir à mieux former les auteurs des demandes et à améliorer la qualité des demandes initiales, afin de réduire les reprises. Pourquoi est-ce important ? Cet attribut indique directement pourquoi les demandes échouent. Il permet d’en rechercher les causes afin de réduire les reprises et d’augmenter la part des demandes correctes dès le premier envoi. Où trouver ces données Consultez la documentation SAP Ariba. Ces informations figurent généralement dans les commentaires ou l’historique associés à un événement de rejet. Exemples Compte général incorrectBudget dépasséJustification insuffisanteDemande en double
	Niveau d’urgence UrgencyLevel	Indicateur de priorité de la demande, par exemple « Normal », « Urgent » ou « Critique ».
Description Le niveau d’urgence, souvent indiqué par un marqueur de priorité, signale la nécessité d’accélérer le traitement. L’auteur de la demande le définit généralement pour que les besoins prioritaires soient pris en charge rapidement. Cet attribut alimente le Dashboard « Suivi des demandes urgentes » et l’indicateur « Durée de traitement des demandes urgentes ». Il permet de comparer directement les temps de cycle des demandes urgentes et standard afin de vérifier si leur traitement prioritaire est efficace. L’analyse des écarts et des retards concernant les demandes urgentes contribue à assurer la continuité des activités. Pourquoi est-ce important ? Il permet de donner la priorité à certaines analyses et de vérifier si les demandes prioritaires sont traitées plus rapidement, afin de répondre aux besoins importants de l’entreprise. Où trouver ces données Consultez la documentation SAP Ariba. Ce champ est souvent proposé dans le formulaire de création d’une demande. Exemples ÉlevéMoyenFaible
	Service de l’auteur de la demande RequesterDepartment	Service ou centre de coûts de l’employé qui a créé la demande d’achat.
Description Cet attribut situe la demande dans l’organisation en indiquant quelle partie de l’entreprise en est à l’origine. Il provient généralement du profil de l’auteur de la demande ou est renseigné directement dans le formulaire. Dans une analyse, il constitue un axe de filtrage et de comparaison utile. Il est utilisé dans presque tous les Dashboards, notamment ceux consacrés au temps de cycle d’approbation et au taux de rejet des demandes, pour ventiler les indicateurs par service. Vous pouvez ainsi repérer les services où les temps de cycle sont les plus longs, où les modifications sont les plus fréquentes ou qui présentent le plus de demandes non conformes, puis cibler les améliorations du processus. Pourquoi est-ce important ? Cet attribut permet de segmenter et de comparer les performances du processus entre les différentes parties de l’organisation, et de repérer les problèmes propres à certains services ou les pratiques à reprendre. Où trouver ces données Consultez la documentation SAP Ariba. Ces informations figurent généralement dans les données d’en-tête de la demande et sont souvent liées au profil de son auteur. Exemples MarketingOpérations informatiquesFinanceRecherche et développement
	Statut de la demande RequisitionStatus	État actuel de la demande d’achat dans son cycle de vie.
Description Cet attribut indique en temps réel le statut d’une demande, par exemple « En cours de rédaction », « Soumise », « Approuvée », « Refusée » ou « Clôturée ». Il donne un aperçu de l’étape à laquelle se trouve chaque cas au moment de l’extraction des données. Le Process Mining reconstitue le déroulement passé du processus, tandis que cet attribut est essentiel à son suivi opérationnel. Il constitue la principale source de données du « Suivi en temps réel du statut des demandes » et permet aux responsables de visualiser la charge de travail actuelle et de repérer les demandes bloquées ou en attente depuis longtemps. Il offre une visibilité immédiate sur les demandes en cours. Pourquoi est-ce important ? Permet de suivre en temps réel les demandes en cours, afin de repérer et de traiter celles qui sont bloquées ou en attente depuis longtemps avant que la situation ne se complique. Où trouver ces données Consultez la documentation SAP Ariba. Il s’agit d’un champ de statut standard dans l’en-tête de la demande. Exemples ApprouvéSoumisRefuséEn cours d’approbation
	Utilisateur à l’origine de l’événement EventUser	ID ou nom de la personne qui a effectué l’activité, par exemple l’auteur de la demande ou l’approbateur.
Description L’attribut « Utilisateur à l’origine de l’événement » identifie la personne responsable d’une étape précise du processus. Il peut s’agir de l’employé qui a envoyé la demande, du responsable qui l’a approuvée ou de l’agent des achats qui l’a traitée. Cet attribut est essentiel à l’analyse de la charge de travail, à la comparaison des performances et au repérage des besoins de formation. Il alimente le Dashboard « Charge de travail et performance des approbateurs », qui permet d’analyser les délais d’approbation par utilisateur. Il sert également à rechercher les causes des retards ou des écarts en les reliant à des personnes ou à des équipes précises. Pourquoi est-ce important ? Il permet d’analyser la répartition de la charge de travail, les performances des utilisateurs et l’affectation des ressources, et de repérer les goulots d’étranglement liés à certains utilisateurs ou à certaines équipes. Où trouver ces données Consultez la documentation SAP Ariba. Ces informations figurent souvent dans les tables de pistes d’audit ou d’historique, liées aux données de référence des utilisateurs. Exemples john.doejane.smithmanager123
	A été modifié IsAmended	Indicateur booléen précisant si la demande a été modifiée au moins une fois après sa soumission initiale.
Description Cet attribut calculé repère les cas comportant au moins une activité « Demande modifiée ». Il permet d’identifier facilement les demandes qui ont nécessité des changements au cours de leur cycle de vie. Cet indicateur sert à calculer le KPI « Taux de modification des demandes ». En comptant les cas pour lesquels il est vrai, les analystes peuvent mesurer la fréquence des reprises et en rechercher les causes en croisant ces informations avec d’autres attributs, comme « Nom du demandeur » ou « Catégorie d’article ». Pourquoi est-ce important ? Simplifie le calcul du KPI de taux de modification, aide à mesurer les reprises et met en évidence les cas où les spécifications initiales gagneraient à être plus claires. Où trouver ces données Vrai si un cas comporte au moins une activité « Demande modifiée », faux dans le cas contraire. Exemples truefalse
	Comporte des reprises IsRework	Indicateur booléen précisant si la demande a nécessité des reprises, par exemple après un rejet ou plusieurs modifications.
Description Cet attribut calculé mesure les inefficacités de manière plus large que « A été modifié ». Il signale les cas ayant connu des reprises importantes, généralement définies par la présence d’au moins un événement « Étape d’approbation rejetée » ou de plusieurs événements « Demande modifiée ». Cet indicateur sert à calculer le KPI « Taux de reprise des demandes ». Il permet de mesurer les coûts cachés et les retards liés aux échecs du processus. L’analyse des cas signalés peut révéler des tendances associées à certains approbateurs, services ou types de demandes, qui compliquent le déroulement du processus. Pourquoi est-ce important ? Repère les cas où le processus rencontre des difficultés importantes, comme des rejets, afin d’analyser les causes des inefficacités et des retards. Où trouver ces données Vrai si un cas comporte une activité de rejet ou plusieurs activités de modification. Exemples truefalse
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière actualisation de ces données depuis le système source.
Description Cet attribut indique la date et l’heure de la dernière extraction ou mise à jour des données d’un événement. Il permet de connaître leur fraîcheur, un point particulièrement important pour le suivi des processus en cours. Les analystes s’en servent pour déterminer si les analyses produites reposent sur des données récentes. Dans un Dashboard comme le « Suivi en temps réel du statut des demandes », ce champ indique aux utilisateurs la date d’actualisation des informations affichées. Il permet ainsi de préciser dans quelle mesure les données sont à jour. Pourquoi est-ce important ? Cet attribut indique si les données sont récentes, ce qui permet d’évaluer l’actualité et la pertinence des analyses de Process Mining. Où trouver ces données Cet horodatage est généralement généré et ajouté à chaque enregistrement lors de l’ingestion des données. Exemples 2024-05-21T02:00:00Z2024-05-22T02:00:00Z
	Est automatisé IsAutomated	Indicateur booléen précisant si une activité a été effectuée par un système ou par un utilisateur.
Description Cet attribut distingue les événements automatisés, comme les approbations automatiques ou les changements de statut déclenchés par le système, des activités effectuées manuellement par les utilisateurs. Cette distinction est essentielle pour comprendre le degré d’automatisation du processus. L’analyse permet ainsi de mesurer précisément le travail humain et de repérer les possibilités d’automatisation supplémentaires. Par exemple, le filtrage des activités manuelles permet de calculer avec précision les durées de traitement imputables aux utilisateurs. Il aide également à vérifier que les règles automatisées fonctionnent comme prévu dans le processus. Pourquoi est-ce important ? Distingue les actions humaines des actions du système, ce qui permet de mesurer le taux d’automatisation et de repérer de nouvelles possibilités d’automatisation. Où trouver ces données Cet attribut est généralement calculé en vérifiant si l’attribut « Utilisateur de l’événement » correspond à un identifiant de système ou de traitement par lots. Exemples truefalse
	ID de commande d’achat PurchaseOrderId	Identifiant de la commande d’achat créée à partir de la demande approuvée.
Description Cet attribut relie une demande d’achat au document qui en découle, la commande d’achat (PO). Sa présence indique que la demande a bien été convertie en commande. Il est essentiel à l’analyse de bout en bout, qui couvre également les étapes suivant la demande. Il sert à calculer le KPI « Délai entre la demande et la commande » en reliant l’événement de création de la demande à celui de création de la commande. Vous obtenez ainsi une vue d’ensemble de la première partie du cycle d’approvisionnement. Pourquoi est-ce important ? Relie la demande à la commande d’achat qui en découle et permet de mesurer le temps de cycle de bout en bout entre la demande et la commande. Où trouver ces données Consultez la documentation SAP Ariba. Cette information est généralement stockée dans les données des lignes de la demande après la création d’une commande d’achat. Exemples PO-4500012345PO-4500012346PO-4500012347
	Nom de l’approbateur ApproverName	Nom de l’utilisateur chargé d’approuver une étape précise du flux de travail.
Description Cet attribut désigne le responsable ou la partie prenante chargée d’une activité d’approbation. Contrairement à l’attribut général « Utilisateur de l’événement », il concerne spécifiquement les tâches d’approbation. Il s’agit d’un attribut clé du Dashboard « Charge de travail et performance des approbateurs ». Il permet de suivre le nombre de demandes traitées par chaque approbateur ainsi que leur temps moyen d’approbation. Ces informations aident à repérer les goulots d’étranglement individuels, à mieux répartir la charge de travail et à évaluer les performances au regard des objectifs. Pourquoi est-ce important ? Désigne la personne chargée d’une approbation et permet d’analyser en détail la répartition de la charge de travail et les performances des approbateurs. Où trouver ces données Consultez la documentation SAP Ariba. Ces informations sont stockées dans les données du flux d’approbation associées à la demande. Exemples Sarah JonesDavid ChenMaria Garcia
	Nom du demandeur RequesterName	Nom de l’employé à l’origine de la demande d’achat.
Description Cet attribut au niveau du cas désigne la personne qui a créé la demande d’achat. Il précise l’origine de la demande et identifie la partie prenante concernée. Lors de l’analyse, cet attribut sert à filtrer le processus et à étudier le comportement de certains demandeurs. Par exemple, les Dashboards « Analyse des modifications de demandes » et « Analyse du taux de rejet des demandes » s’appuient sur ces informations pour repérer les personnes qui pourraient avoir besoin d’une formation complémentaire en raison d’un nombre élevé de modifications ou de rejets. Elles permettent d’adapter les retours et les initiatives d’amélioration à chaque situation. Pourquoi est-ce important ? Désigne la personne à l’origine de la demande et permet d’analyser le déroulement et la qualité du processus pour chaque demandeur. Où trouver ces données Consultez la documentation SAP Ariba. Il s’agit d’un champ standard dans l’en-tête de la demande, souvent nommé « Créé par » ou « Demandeur ». Exemples Alice WilliamsBob MillerCharles Brown
	Système source SourceSystem	Système de référence à partir duquel les données ont été extraites.
Description Cet attribut indique l’origine des données du processus. Dans cette vue, sa valeur serait toujours « SAP Ariba ». Si les données provenaient de plusieurs systèmes, ce champ serait essentiel pour retracer leur origine et faciliter le diagnostic des problèmes. Il permet de confirmer la provenance des données et de filtrer ou de comparer les processus qui couvrent plusieurs systèmes. Il clarifie la source des données et renforce la confiance dans l’analyse, ce qui facilite l’adhésion des parties prenantes. Pourquoi est-ce important ? Cet attribut indique l’origine des données. Il est essentiel à leur gouvernance, au diagnostic des problèmes et à la bonne compréhension du contexte de l’analyse. Où trouver ces données Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction et de la transformation des données pour indiquer l’origine du jeu de données. Exemples SAP AribaSAP_ARIBA_P2PAribaCloud

Obligatoire Recommandé Facultatif

Activités Purchase to Pay - Demande d’achat

Voici les principales étapes et les principaux jalons à enregistrer dans votre journal d’événements pour découvrir précisément le processus et repérer les goulots d’étranglement.

6 Recommandé 7 Facultatif

	Activité	Description
	Bon de commande créé	Marque la conversion réussie d’une demande d’achat approuvée en bon de commande. L’événement est enregistré lors de la création d’un bon de commande faisant référence à la demande.
Pourquoi est-ce important ? C’est le principal résultat attendu du processus de demande d’achat. Il est essentiel au calcul de l’indicateur « délai entre la demande et le bon de commande ». Où trouver ces données Il s’agit d’un événement explicite. Utilisez l’horodatage de création du document de bon de commande, qui contient un lien ou une référence directe à l’ID de la demande d’achat source. Données à recueillir Dans la table d’en-tête des bons de commande, recherchez le bon lié à la demande et utilisez son horodatage de création. Type d’événement explicit
	Demande approuvée	Marque l’approbation finale de la demande d’achat, après validation de toutes les étapes du flux de travail. L’événement est enregistré lorsque le statut passe à « Approved ».
Pourquoi est-ce important ? Cette étape importante marque la fin de la phase d’approbation. Elle sert de point final au calcul du « délai moyen d’approbation des demandes » et indique que la demande peut donner lieu à la création d’un bon de commande. Où trouver ces données À déduire de l’historique du document Ariba, qui consigne le passage final de la demande au statut « Approved ». Données à recueillir Repérez l’horodatage auquel le champ de statut de la demande passe à « Approved ». Type d’événement inferred
	Demande clôturée	Clôture administrative définitive d’une demande d’achat, une fois toutes les opérations associées, comme la commande et la réception, terminées. Elle est enregistrée lors du passage final au statut « Closed ».
Pourquoi est-ce important ? Cet événement marque la fin définitive du cycle de vie de la demande. L’analyse du délai entre la création du bon de commande et la clôture peut révéler des goulots d’étranglement dans les processus ultérieurs de réception ou de facturation. Où trouver ces données À déduire de l’historique du document Ariba, qui consigne le passage de la demande au statut « Closed ». Données à recueillir Repérez l’horodatage auquel le champ de statut de la demande passe à « Closed ». Type d’événement inferred
	Demande créée	Indique la création initiale d’un document de demande d’achat par un utilisateur. L’événement est enregistré lors de la première sauvegarde de la demande, à l’état « Composing » ou en brouillon.
Pourquoi est-ce important ? C’est le point de départ du cycle de vie de la demande. L’analyse du délai entre sa création et son envoi permet de mesurer l’efficacité des utilisateurs et de repérer les besoins de formation. Où trouver ces données À partir de l’horodatage de création de l’objet de demande d’achat dans SAP Ariba. Cette information figure dans les données d’en-tête du document et correspond à un événement de création explicite. Données à recueillir Utilisez l’horodatage « CreateTime » ou son équivalent dans la table d’en-tête du document de demande. Type d’événement explicit
	Demande envoyée	Correspond à l’envoi officiel de la demande d’achat par son auteur dans le flux d’approbation. L’événement est enregistré lorsque le statut passe de « Composing » à « Submitted ».
Pourquoi est-ce important ? Cette étape importante déclenche le processus d’approbation. Elle est indispensable au calcul du « temps de cycle d’approbation des demandes » et du « délai entre la création et l’envoi des demandes ». Où trouver ces données À déduire de l’historique du document ou du journal d’audit Ariba, qui consigne le passage de la demande au statut « Submitted » ainsi que l’horodatage correspondant. Données à recueillir Repérez l’horodatage auquel le champ de statut de la demande passe pour la première fois à « Submitted ». Type d’événement inferred
	Demande refusée	Correspond au rejet définitif d’une demande d’achat après examen. Cet état final du processus est enregistré lorsque le statut passe à « Denied ».
Pourquoi est-ce important ? Il s’agit d’une issue défavorable importante. L’analyse des demandes refusées est essentielle au calcul de l’indicateur « taux de rejet des demandes », ainsi qu’à l’identification des tendances et à l’amélioration de la qualité des demandes. Où trouver ces données À déduire de l’historique du document Ariba, qui consigne le passage final de la demande au statut « Denied ». Données à recueillir Repérez l’horodatage auquel le champ de statut de la demande passe à « Denied ». Type d’événement inferred
	Demande modifiée	Cet événement se produit lorsqu’un utilisateur modifie une demande d’achat après son envoi, souvent à la suite d’un rejet ou d’une demande de précision. Il est enregistré lorsque le document est modifié puis envoyé à nouveau.
Pourquoi est-ce important ? Cet événement permet de suivre les reprises et les inefficacités du processus. Des modifications fréquentes peuvent révéler des exigences ou des règles peu claires et influer sur l’indicateur « Taux de modification des demandes ». Où trouver ces données À déduire des données de versionnement dans Ariba. Chaque modification crée une nouvelle version du document de demande. La création d’une version supérieure à 1 indique une modification. Données à recueillir Recherchez les nouvelles versions de la demande créées après son premier passage au statut « Submitted ». L’horodatage de la nouvelle version correspond à l’heure de l’événement. Type d’événement inferred
	Demande retirée	Cet événement se produit lorsque l’auteur initial retire une demande d’achat envoyée avant son approbation complète. Il est enregistré lorsque le statut passe à « Withdrawn » ou « Canceled ».
Pourquoi est-ce important ? Il marque l’arrêt du processus à l’initiative de l’utilisateur. L’analyse des motifs de retrait peut révéler des besoins métier qui ont évolué ou des délais d’approbation trop longs. Où trouver ces données À déduire de l’historique du document ou du journal d’audit Ariba, qui consigne le passage de la demande au statut « Withdrawn ». Données à recueillir Repérez l’horodatage auquel le champ de statut de la demande passe à « Withdrawn ». Type d’événement inferred
	Demande transmise aux achats stratégiques	Cet événement se produit lorsqu’une demande approuvée est transmise au service des achats stratégiques pour lancer une procédure, par exemple une demande de devis (RFQ), avant la création d’un bon de commande. Il est enregistré lors d’un changement de statut, par exemple vers « Sourcing ».
Pourquoi est-ce important ? Cet événement signale une étape importante du processus pour les articles de grande valeur ou non standard. Il permet d’analyser la contribution du service des achats stratégiques au délai global. Où trouver ces données À déduire du passage de la demande à un statut indiquant qu’elle a été transmise aux achats stratégiques. Ce cas est fréquent dans Ariba Buying intégré à Ariba Sourcing. Données à recueillir Repérez l’horodatage auquel le champ de statut de la demande passe à « Sourcing » ou à un statut personnalisé équivalent. Type d’événement inferred
	Étape d’approbation approuvée	Correspond à l’issue favorable d’une étape d’approbation : l’approbateur a approuvé la partie de la demande qui lui était attribuée. Cette action est consignée explicitement.
Pourquoi est-ce important ? Cet événement mesure le temps de traitement de chaque approbateur. Ces données sont essentielles pour calculer la « durée moyenne d’une étape d’approbation » et évaluer la charge des approbateurs. Où trouver ces données À partir des tables de flux d’approbation Ariba. L’événement est horodaté lorsque l’approbateur sélectionne l’action « Approve » pour la tâche qui lui est attribuée. Données à recueillir Utilisez l’horodatage de l’action « Approve » consigné dans l’historique d’approbation de l’étape concernée. Type d’événement explicit
	Étape d’approbation lancée	Indique qu’une demande d’achat a été transmise à un approbateur ou à une file d’approbation et qu’elle attend une décision. L’événement est enregistré lorsqu’une demande d’approbation est créée et attribuée.
Pourquoi est-ce important ? Cet événement fournit une vue détaillée du flux d’approbation. Il est essentiel pour calculer les temps d’attente dans les files et repérer les étapes qui constituent des goulots d’étranglement dans l’« analyse des goulots d’étranglement des circuits d’approbation ». Où trouver ces données À partir des tables de flux d’approbation Ariba, qui consignent la création et l’attribution des tâches d’approbation associées à la demande. Données à recueillir Utilisez l’horodatage de création de l’enregistrement de demande d’approbation associé à la demande et à l’étape d’approbation concernée. Type d’événement explicit
	Étape d’approbation rejetée	Correspond à l’issue défavorable d’une étape d’approbation : l’approbateur rejette la demande, généralement pour qu’elle soit modifiée. Cette action est consignée explicitement sous la forme « Deny ».
Pourquoi est-ce important ? Cet événement met en évidence une cause importante de reprises et de retards. Son analyse est essentielle pour comprendre le « taux de reprise des demandes » et les motifs de rejet. Où trouver ces données À partir des tables de flux d’approbation Ariba. L’événement est horodaté lorsque l’approbateur sélectionne l’action « Deny » ou « Reject » pour la tâche qui lui est attribuée. Données à recueillir Utilisez l’horodatage de l’action « Deny » consigné dans l’historique d’approbation de l’étape concernée. Type d’événement explicit
	Ligne de demande commandée	Correspond au passage au statut « Ordered » d’une ligne de demande après son ajout à un bon de commande. Cet événement permet un suivi plus détaillé que la seule création du bon de commande au niveau de l’en-tête.
Pourquoi est-ce important ? Cet événement permet d’analyser les commandes partielles et les retards au niveau des lignes, qui ne sont pas visibles si l’on examine uniquement l’en-tête. Il est utile pour les demandes comportant plusieurs lignes, traitées dans différents bons de commande. Où trouver ces données À déduire du changement de statut de l’objet correspondant à la ligne de demande. Le statut de la ligne passe à « Ordered » lorsqu’un bon de commande est créé pour celle-ci. Données à recueillir Repérez l’horodatage auquel le champ de statut de la ligne de demande passe à « Ordered ». Type d’événement inferred

Recommandé Facultatif

Guides d’extraction

Comment extraire vos données de SAP Ariba

Étapes

Connectez-vous à SAP Ariba : accédez à votre environnement SAP Ariba avec un compte utilisateur autorisé à créer et à exécuter des rapports analytiques, par exemple avec le rôle « Analyste des rapports ».
Accédez aux rapports analytiques : depuis le Dashboard principal, ouvrez la section des rapports. Elle se trouve généralement dans un menu tel que « Rapports », « Analyses » ou « Gérer » > « Rapports analytiques ».
Créez un rapport : lancez la création d’un rapport analytique. Vous devrez sélectionner la principale source de données, souvent appelée « fait ». Choisissez celle qui concerne les demandes, par exemple « [Requisition] » ou un nom similaire défini dans votre configuration Ariba.
Ajoutez les champs de données : dans l’interface de création du rapport, ajoutez les colonnes nécessaires. Vous devrez combiner plusieurs sources de données (faits) pour obtenir toutes les informations requises. Un rapport type associe « [Requisition Fact] », « [Approval History Fact] » et « [Purchase Order Fact] » à l’aide de l’ID de demande. Ajoutez tous les champs indiqués dans la configuration de la requête, notamment les horodatages pertinents, comme les dates de création et de soumission, la date d’approbation et les dates d’action de l’historique des approbations.
Configurez les filtres : définissez des filtres pour limiter le périmètre des données. Le plus important concerne la période. Filtrez le champ « Requisition Created Date » sur la période souhaitée, par exemple les 3 à 6 derniers mois. Ajoutez d’autres filtres si nécessaire, notamment sur certains codes société ou environnements.
Exécutez le rapport et exportez les données brutes : lancez le rapport. Une fois l’exécution terminée, exportez les résultats au format CSV ou Excel. Cet export initial est généralement au format « large » : une ligne par demande ou entrée d’approbation, avec de nombreuses colonnes correspondant à différentes dates et actions utilisateur.
Transformez les données au format du journal d’événements : cette étape hors ligne est essentielle. Utilisez un outil comme Microsoft Excel avec Power Query, un script Python ou un autre outil de préparation des données pour convertir le format large en format long. Pour chaque colonne d’horodatage exportée, par exemple « Created Date », « Submitted Date » ou « Approved Date », créez une ligne distincte dans le journal d’événements final. Cette opération est souvent appelée « dépivotage » ou « fusion ».
Associez les activités et les attributs : pendant la transformation, créez les colonnes ActivityName et EventTimestamp. Par exemple, lors du traitement de la colonne « Submitted Date », créez des lignes où ActivityName prend la valeur « Requisition Submitted » et EventTimestamp celle de la colonne « Submitted Date ».
Regroupez et nettoyez les données : rassemblez dans un seul fichier les données dépivotées de toutes les colonnes d’horodatage. Vérifiez que les colonnes PurchaseRequisitionId, ActivityName et EventTimestamp sont correctement renseignées pour chaque ligne. Supprimez les lignes vides et corrigez les problèmes de formatage.
Enregistrez le fichier CSV final : enregistrez le journal d’événements transformé au format CSV avec l’encodage UTF-8. Le fichier est prêt à être importé dans l’outil de Process Mining.

Configuration

Type de rapport : rapport analytique créé à l’aide de l’interface standard de création de rapports Ariba.
Sources de données principales : vous devrez combiner plusieurs sources, généralement « [Requisition Fact] », « [Approval History Fact] » et « [Purchase Order Fact] ». Leur nom exact peut varier selon votre modèle de données Ariba.
Période : il est recommandé de filtrer le champ « Requisition Created Date » sur une période raisonnable, par exemple de 3 à 6 mois. Pour les premiers essais, choisissez une période plus courte, comme une semaine.
Filtres clés : appliquez toujours un filtre sur une période précise. Vous pouvez également filtrer par « Company Code » ou « Purchasing Organization » afin de limiter les données au périmètre opérationnel concerné et d’améliorer les performances du rapport.
Prérequis : l’utilisateur qui exécute le rapport doit disposer d’un rôle l’autorisant à accéder au module de rapports analytiques et aux sources de données sous-jacentes concernant les demandes, les approbations et les commandes d’achat.

Exemple de requête config

REPORT CONFIGURATION for SAP Ariba Analytical Reporting

REPORT TYPE: Analytical Report

PRIMARY DATA SOURCE (FACT):
*   [Requisition Fact]

JOINED DATA SOURCES (FACTS):
*   [Approval History Fact] on Requisition ID
*   [Purchase Order Fact] on Requisition ID
*   [Requisition Line Item Fact] on Requisition ID

REPORT FIELDS (COLUMNS TO EXPORT for subsequent transformation):

// Case and General Attributes
*   Requisition.Requisition ID (as PurchaseRequisitionId)
*   Requisition.Status (as RequisitionStatus)
*   Requisition.Requester.Department (as RequesterDepartment)
*   Requisition.Total Cost.Amount (as TotalRequisitionAmount)
*   Requisition.Line Items.Category (as ItemCategory)
*   Requisition.Is Urgent (as UrgencyLevel)
*   Requisition.Approval Flow Name (as ApprovalWorkflowPath)

// Fields for 'Requisition Created'
*   Requisition.Created Date (Timestamp)
*   Requisition.Requester.User ID (User)

// Fields for 'Requisition Submitted'
*   Requisition.Submitted Date (Timestamp)
*   Requisition.Submitter.User ID (User)

// Fields for 'Requisition Amended'
*   Requisition.Last Modified Date (Timestamp) - Note: Requires logic to isolate true amendment events
*   Requisition.Last Modified By.User ID (User)

// Fields for 'Approval Step' activities
*   Approval History.Approval Request Date (Timestamp for 'Approval Step Started')
*   Approval History.Action Date (Timestamp for 'Approval Step Approved'/'Approval Step Rejected')
*   Approval History.Action (Value: 'Approve'/'Deny')
*   Approval History.Approver.User ID (User)
*   Approval History.Comments (for RejectionReason)

// Fields for final status activities
*   Requisition.Approved Date (Timestamp for 'Requisition Approved')
*   Requisition.Denied Date (Timestamp for 'Requisition Denied')
*   Requisition.Withdrawn Date (Timestamp for 'Requisition Withdrawn')
*   Requisition.Closed Date (Timestamp for 'Requisition Closed')

// Fields for downstream activities
*   Requisition.Sourcing Status Date (Timestamp for 'Requisition Sent To Sourcing')
*   Purchase Order.Created Date (Timestamp for 'Purchase Order Created')
*   Purchase Order.Creator.User ID (User for 'Purchase Order Created')
*   Requisition Line Item.Ordered Date (Timestamp for 'Requisition Line Item Ordered')

FILTERS:
*   Requisition.Created Date BETWEEN [Start Date] AND [End Date]
*   Company Code IN ([Your Company Codes])

Étapes

Configurez l’environnement Python : vérifiez que Python 3.6 ou une version ultérieure est installé. Installez les bibliothèques nécessaires avec pip : pip install requests pandas.
Configurez l’accès à l’API : dans le portail SAP Ariba Developer Portal, enregistrez une nouvelle application. Abonnez-vous à l’API Operational Reporting API for Requisitions et obtenez vos identifiants OAuth : Application Key (clé API), OAuth Client Secret et chaîne encodée en Base64 [your_api_key]:[your_client_secret].
Personnalisez le script Python : ouvrez le script Python fourni et renseignez les variables de remplacement en haut du fichier, notamment ARIBA_REALM, BASE_URL, API_KEY et BASE64_CREDS. Définissez également START_DATE et END_DATE pour la période d’extraction.
Définissez le contenu de la requête de rapport : examinez l’objet JSON report_payload dans le script. Il définit le rapport à exécuter. Le script est préconfiguré pour utiliser RequisitionFactSystemView et sélectionner les champs correspondant aux activités et attributs requis. Vous pouvez ajouter d’autres champs ou filtres au besoin.
Exécutez le script : lancez le script depuis votre terminal avec python your_script_name.py. Il commence par s’authentifier auprès d’Ariba pour obtenir un jeton d’accès.
Envoyez la demande de rapport et suivez son exécution : le script envoie automatiquement la demande à l’API Ariba. Comme le traitement est asynchrone, il interroge ensuite l’API toutes les 60 secondes pour vérifier l’état du traitement.
Téléchargez les données du rapport : lorsque l’API Ariba indique que le traitement est COMPLETED, le script télécharge les données produites, généralement dans un fichier ZIP contenant un seul fichier CSV.
Traitez et transformez les données : le script décompresse le fichier et charge les données brutes dans un DataFrame pandas. Il les transforme ensuite d’un format large (une ligne par demande d’achat et de nombreuses colonnes de dates) en un format long de journal d’événements (plusieurs lignes par demande d’achat, une par activité).
Générez le journal d’événements : le DataFrame transformé, structuré comme un journal d’événements avec des colonnes telles que PurchaseRequisitionId, ActivityName et EventTimestamp, est enregistré sous le nom ariba_requisition_event_log.csv dans le même répertoire que le script.
Préparez l’importation : le fichier CSV généré est prêt à être importé dans ProcessMind. Vérifiez que les en-têtes de colonnes correspondent aux associations configurées dans votre projet ProcessMind.

Configuration

URL du point de terminaison de l’API : le script nécessite l’URL de base de l’API de votre instance Ariba, généralement au format https://[your-realm].api.ariba.com/api/operationalreporting/v2/. Remplacez [your-realm] par le nom de l’environnement Ariba propre à votre entreprise.
Authentification : l’extraction utilise OAuth 2.0. Vous devez fournir une apiKey, un clientSecret et une chaîne base64EncodedCredentials valides, obtenus à partir de votre application enregistrée dans le portail Ariba Developer Portal.
Modèle de vue : le script est configuré pour utiliser RequisitionFactSystemView. Cette vue Ariba standard doit être activée dans votre environnement, et votre utilisateur d’API doit être autorisé à y accéder.
Filtre de période : le filtre creationDate dans le contenu du rapport est essentiel pour contrôler le volume de données. Pour les premières extractions, il est recommandé de choisir une période de 3 à 6 mois. Dans les grandes organisations, envisagez de procéder par lots mensuels plus petits.
Chargements incrémentiels : pour les extractions suivantes, modifiez START_DATE et END_DATE afin de récupérer uniquement les enregistrements nouveaux ou mis à jour. Le script ne gère pas automatiquement les chargements incrémentiels : vous devez donc définir manuellement la période à chaque exécution.
Prérequis : vous devez disposer d’un compte utilisateur SAP Ariba autorisé à accéder au portail développeur pour créer l’application et obtenir les identifiants. L’application API doit également disposer du rôle « Operational Reporting API User » pour exécuter les rapports.

Exemple de requête python

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

class=class="hl-string">"hl-comment"># --- Configuration --- 
class=class="hl-string">"hl-comment"># Replace with your SAP Ariba realm, datacenter-specific URL, and credentials
ARIBA_REALM = class="hl-string">"[Your Ariba Realm]"
BASE_URL = fclass="hl-string">"https://{ARIBA_REALM}.api.ariba.com/api/operationalreporting/v2/"
TOKEN_URL = class="hl-string">"https://api.ariba.com/v2/oauth/token"
API_KEY = class="hl-string">"[Your Application Key]"
BASE64_CREDS = class="hl-string">"[Your Base64-encoded ClientID:ClientSecret]"

class=class="hl-string">"hl-comment"># --- Report Parameters ---
class=class="hl-string">"hl-comment"># Set the date range for the extraction
START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
END_DATE = class="hl-string">"2023-06-30T23:59:59Z"

class=class="hl-string">"hl-comment"># The main function to orchestrate the extraction process
def main():
    print(class="hl-string">"1. Acquiring access token...")
    access_token = get_access_token()
    if not access_token:
        return

    print(class="hl-string">"2. Creating asynchronous report job...")
    job_id = create_report_job(access_token)
    if not job_id:
        return

    print(fclass="hl-string">"Job created with ID: {job_id}. Polling for completion...")
    status = poll_job_status(access_token, job_id)

    if status == class="hl-string">'COMPLETED':
        print(class="hl-string">"3. Job completed. Downloading report data...")
        raw_data = download_report(access_token, job_id)
        if raw_data:
            print(class="hl-string">"4. Processing raw data into event log...")
            event_log = process_data(raw_data)
            output_filename = class="hl-string">'ariba_requisition_event_log.csv'
            event_log.to_csv(output_filename, index=False)
            print(fclass="hl-string">"5. Success! Event log saved to {output_filename}")
    else:
        print(fclass="hl-string">"Job failed or timed out with status: {status}")

def get_access_token():
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Basic {BASE64_CREDS}',
        class="hl-string">'Content-Type': class="hl-string">'application/x-www-form-urlencoded',
    }
    data = {class="hl-string">'grant_type': class="hl-string">'client_credentials'}
    try:
        response = requests.post(TOKEN_URL, headers=headers, data=data)
        response.raise_for_status()
        return response.json().get(class="hl-string">'access_token')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error getting access token: {e}")
        return None

def create_report_job(token):
    headers = {
        class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}',
        class="hl-string">'apiKey': API_KEY,
        class="hl-string">'Content-Type': class="hl-string">'application/json'
    }
    report_payload = {
        class="hl-string">"name": class="hl-string">"ProcessMind Requisition Extraction",
        class="hl-string">"viewTemplateName": class="hl-string">"RequisitionFactSystemView",
        class="hl-string">"outputFormat": class="hl-string">"CSV",
        class="hl-string">"filters": {
            class="hl-string">"creationDate": {
                class="hl-string">"from": START_DATE,
                class="hl-string">"to": END_DATE
            }
        },
        class="hl-string">"select": [
            class="hl-string">"RequisitionId", class="hl-string">"StatusString", class="hl-string">"SubmitDate", class="hl-string">"ApprovedState.TimeUpdated",
            class="hl-string">"DeniedState.TimeUpdated", class="hl-string">"SourcingState.TimeUpdated", class="hl-string">"ClosedState.TimeUpdated",
            class="hl-string">"WithdrawnState.TimeUpdated", class="hl-string">"Requester.Name", class="hl-string">"Requester.Department",
            class="hl-string">"TotalCost.Amount", class="hl-string">"LineItems.Category.Name", class="hl-string">"IsUrgent", class="hl-string">"ApprovalFlow.Name",
            class="hl-string">"RequisitionVersion", class="hl-string">"TimeCreated", class="hl-string">"LineItems.OrderedState.TimeUpdated", class="hl-string">"POInfo.POId"
        ]
    }
    try:
        response = requests.post(fclass="hl-string">"{BASE_URL}jobs", headers=headers, json=report_payload)
        response.raise_for_status()
        return response.json().get(class="hl-string">'jobId')
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error creating report job: {e}")
        return None

def poll_job_status(token, job_id):
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}', class="hl-string">'apiKey': API_KEY}
    while True:
        try:
            response = requests.get(fclass="hl-string">"{BASE_URL}jobs('{job_id}')", headers=headers)
            response.raise_for_status()
            status = response.json().get(class="hl-string">'status')
            print(fclass="hl-string">"Current job status: {status}")
            if status in [class="hl-string">'COMPLETED', class="hl-string">'FAILED', class="hl-string">'CANCELLED']:
                return status
            time.sleep(60) class=class="hl-string">"hl-comment"># Wait 60 seconds before polling again
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error polling job status: {e}")
            return class="hl-string">'FAILED'

def download_report(token, job_id):
    headers = {class="hl-string">'Authorization': fclass="hl-string">'Bearer {token}', class="hl-string">'apiKey': API_KEY}
    try:
        response = requests.get(fclass="hl-string">"{BASE_URL}jobs('{job_id}')/result", headers=headers, stream=True)
        response.raise_for_status()
        return response.content
    except requests.exceptions.RequestException as e:
        print(fclass="hl-string">"Error downloading report: {e}")
        return None

def process_data(zip_content):
    try:
        with zipfile.ZipFile(io.BytesIO(zip_content)) as z:
            class=class="hl-string">"hl-comment"># Assuming the first file in the zip is the CSV we need
            csv_filename = z.namelist()[0]
            with z.open(csv_filename) as f:
                df = pd.read_csv(f)
    except Exception as e:
        print(fclass="hl-string">"Error reading zipped CSV: {e}")
        return pd.DataFrame()

    class=class="hl-string">"hl-comment"># Rename columns for clarity
    df.rename(columns={
        class="hl-string">'RequisitionId': class="hl-string">'PurchaseRequisitionId',
        class="hl-string">'TimeCreated': class="hl-string">'Timestamp_Created',
        class="hl-string">'SubmitDate': class="hl-string">'Timestamp_Submitted',
        class="hl-string">'ApprovedState.TimeUpdated': class="hl-string">'Timestamp_Approved',
        class="hl-string">'DeniedState.TimeUpdated': class="hl-string">'Timestamp_Denied',
        class="hl-string">'SourcingState.TimeUpdated': class="hl-string">'Timestamp_SentToSourcing',
        class="hl-string">'ClosedState.TimeUpdated': class="hl-string">'Timestamp_Closed',
        class="hl-string">'WithdrawnState.TimeUpdated': class="hl-string">'Timestamp_Withdrawn',
        class="hl-string">'LineItems.OrderedState.TimeUpdated': class="hl-string">'Timestamp_LineItemOrdered',
        class="hl-string">'POInfo.POId': class="hl-string">'POId',
        class="hl-string">'Requester.Name': class="hl-string">'EventUser',
        class="hl-string">'Requester.Department': class="hl-string">'RequesterDepartment',
        class="hl-string">'TotalCost.Amount': class="hl-string">'TotalRequisitionAmount',
        class="hl-string">'LineItems.Category.Name': class="hl-string">'ItemCategory',
        class="hl-string">'IsUrgent': class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalFlow.Name': class="hl-string">'ApprovalWorkflowPath',
        class="hl-string">'StatusString': class="hl-string">'RequisitionStatus'
    }, inplace=True)
    
    class=class="hl-string">"hl-comment"># Create a base dataframe for melting
    id_vars = [
        class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventUser', class="hl-string">'RequesterDepartment', class="hl-string">'TotalRequisitionAmount',
        class="hl-string">'ItemCategory', class="hl-string">'UrgencyLevel', class="hl-string">'ApprovalWorkflowPath', class="hl-string">'RequisitionStatus', class="hl-string">'RequisitionVersion', class="hl-string">'POId'
    ]
    
    timestamp_cols = [col for col in df.columns if col.startswith(class="hl-string">'Timestamp_')]
    
    class=class="hl-string">"hl-comment"># Melt the dataframe to turn timestamp columns into rows
    event_log = pd.melt(df, id_vars=id_vars, value_vars=timestamp_cols, var_name=class="hl-string">'ActivityName', value_name=class="hl-string">'EventTimestamp')
    
    class=class="hl-string">"hl-comment"># Clean up and format
    event_log.dropna(subset=[class="hl-string">'EventTimestamp'], inplace=True)
    event_log[class="hl-string">'ActivityName'] = event_log[class="hl-string">'ActivityName'].str.replace(class="hl-string">'Timestamp_', class="hl-string">'Requisition ')
    event_log[class="hl-string">'EventTimestamp'] = pd.to_datetime(event_log[class="hl-string">'EventTimestamp'])

    class=class="hl-string">"hl-comment"># --- Handle specific/derived activities ---
    class=class="hl-string">"hl-comment"># Requisition Amended
    amended_df = df[df[class="hl-string">'RequisitionVersion'] > 1].copy()
    if not amended_df.empty:
        amended_df[class="hl-string">'ActivityName'] = class="hl-string">'Requisition Amended'
        amended_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(amended_df[class="hl-string">'Timestamp_Submitted'])
        event_log = pd.concat([event_log, amended_df[event_log.columns]], ignore_index=True)

    class=class="hl-string">"hl-comment"># Purchase Order Created (use the timestamp of the first line item ordered as a proxy)
    po_created_df = df[df[class="hl-string">'POId'].notna() & df[class="hl-string">'Timestamp_LineItemOrdered'].notna()].copy()
    if not po_created_df.empty:
        po_created_df[class="hl-string">'ActivityName'] = class="hl-string">'Purchase Order Created'
        po_created_df[class="hl-string">'EventTimestamp'] = pd.to_datetime(po_created_df[class="hl-string">'Timestamp_LineItemOrdered'])
        event_log = pd.concat([event_log, po_created_df[event_log.columns]], ignore_index=True)
    
    class=class="hl-string">"hl-comment"># Placeholder for Approval Steps - requires parsing ApprovalRecords not included in this basic script
    class=class="hl-string">"hl-comment"># For now, we only have the final class="hl-string">'Approved' status. This logic can be expanded.
    class=class="hl-string">"hl-comment"># Creating dummy class="hl-string">'Approval Step Started/Approved' for demonstration.
    approval_df = df[df[class="hl-string">'Timestamp_Approved'].notna()].copy()
    if not approval_df.empty:
        approval_started = approval_df.copy()
        approval_started[class="hl-string">'ActivityName'] = class="hl-string">'Approval Step Started'
        class=class="hl-string">"hl-comment"># Approximate start time as submit time
        approval_started[class="hl-string">'EventTimestamp'] = pd.to_datetime(approval_started[class="hl-string">'Timestamp_Submitted'])
        
        approval_approved = approval_df.copy()
        approval_approved[class="hl-string">'ActivityName'] = class="hl-string">'Approval Step Approved'
        approval_approved[class="hl-string">'EventTimestamp'] = pd.to_datetime(approval_approved[class="hl-string">'Timestamp_Approved'])
        approval_approved[class="hl-string">'RejectionReason'] = None class=class="hl-string">"hl-comment"># Add column for consistency
        
        event_log = pd.concat([event_log, approval_started[event_log.columns], approval_approved[event_log.columns.tolist() + [class="hl-string">'RejectionReason']]], ignore_index=True)

    class=class="hl-string">"hl-comment"># Add placeholder for RejectionReason, as it's not directly in this view
    if class="hl-string">'RejectionReason' not in event_log.columns:
        event_log[class="hl-string">'RejectionReason'] = None

    class=class="hl-string">"hl-comment"># Final sorting and cleanup
    event_log = event_log.sort_values(by=[class="hl-string">'PurchaseRequisitionId', class="hl-string">'EventTimestamp']).reset_index(drop=True)
    
    class=class="hl-string">"hl-comment"># Rename class="hl-string">'Requisition LineItemOrdered' to class="hl-string">'Requisition Line Item Ordered'
    event_log[class="hl-string">'ActivityName'] = event_log[class="hl-string">'ActivityName'].replace({class="hl-string">'Requisition LineItemOrdered': class="hl-string">'Requisition Line Item Ordered'})

    class=class="hl-string">"hl-comment"># Final column selection
    final_columns = [
        class="hl-string">'PurchaseRequisitionId', class="hl-string">'ActivityName', class="hl-string">'EventTimestamp', class="hl-string">'EventUser',
        class="hl-string">'RequesterDepartment', class="hl-string">'TotalRequisitionAmount', class="hl-string">'ItemCategory', class="hl-string">'UrgencyLevel',
        class="hl-string">'ApprovalWorkflowPath', class="hl-string">'RejectionReason', class="hl-string">'RequisitionStatus'
    ]
    event_log = event_log[final_columns]

    return event_log

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

Prêt à commencer ?

Utilisez ce modèle pour préparer vos données plus efficacement et mieux comprendre votre processus Purchase to Pay - Demande d’achat. Commencez dès aujourd’hui à optimiser vos opérations.

Retour au guide d’amélioration

Télécharger le modèle

Mettez fin aux retards : optimisez le traitement des demandes Purchase to Pay

Repérez les inefficacités dans SAP Ariba et réduisez le temps de cycle de 30 %.

Démarrez l’essai gratuit

Aucune carte bancaire n’est requise. La configuration est rapide et simple.

Votre modèle de données Purchase to Pay - Demande d’achat

Votre modèle de données Purchase to Pay - Demande d’achat

Attributs Purchase to Pay - Demande d’achat

Activités Purchase to Pay - Demande d’achat

Guides d’extraction

Export CSV/Excel des rapports analytiques SAP Ariba

Étapes

Configuration

Exemple de requête config

Extraction par script Python via l’API Operational Reporting

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Mettez fin aux retards : optimisez le traitement des demandes Purchase to Pay

Votre modèle de données Purchase to Pay - Demande d’achat

Votre modèle de données Purchase to Pay - Demande d’achat

Attributs Purchase to Pay - Demande d’achat

Activités Purchase to Pay - Demande d’achat

Guides d’extraction

Export CSV/Excel des rapports analytiques SAP Ariba

Étapes

Configuration

Exemple de requête config

Extraction par script Python via l’API Operational Reporting

Étapes

Configuration

Exemple de requête python

Prêt à commencer ?

Mettez fin aux retards : optimisez le traitement des demandes Purchase to Pay

Prêt à commencer ?

Mettez fin aux retards : optimisez le traitement des demandes Purchase to Pay