> Amélioration continue des processus > Purchase to Pay Requisition > Coupa > Modèle de données

Votre template de données Purchase to Pay, demande d’achat

Coupa

Purchase to Pay - Requisition : attributs (21) Purchase to Pay - Requisition : activités (12) Guides d’extraction (3)

Votre template de données Purchase to Pay, demande d’achat

Ce template complet fournit une méthode structurée pour recueillir 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 Event Log fiable. Vous y trouverez également des indications pour extraire efficacement ces données de votre système Coupa.

Attributs recommandés pour une analyse complète
Activités clés du processus à suivre
Conseils pratiques pour l’extraction des données

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 - Requisition : 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 - Requisition.

5 Obligatoire 5 Recommandé 11 Facultatif

	Nom	Description
	Heure de l’événement EventTime	Date et heure précises auxquelles l’activité s’est produite.
Description L’heure de l’événement, ou horodatage, enregistre le moment exact où une activité a été enregistrée pour une demande d’achat. Ces données sont essentielles pour classer les événements dans l’ordre chronologique et construire le déroulement du processus. Elles servent de base à toutes les analyses temporelles, notamment au calcul des délais de traitement, à l’identification des goulots d’étranglement par la mesure de la durée entre les activités et à l’évaluation de la performance du processus sur différentes périodes. Des horodatages précis et détaillés sont indispensables à une analyse pertinente des processus. Pourquoi c’est important Cet horodatage est essentiel pour classer correctement les événements et calculer toutes les métriques fondées sur la durée, notamment les délais de traitement et les goulots d’étranglement. Où les obtenir Ces informations sont enregistrées dans la piste d’audit ou les historiques de chaque demande d’achat dans Coupa, souvent dans un champ « created_at » ou « updated_at » associé à chaque action. Exemples 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:22:05Z
	Identifiant de la demande d’achat PurchaseRequisitionId	Identifiant unique de chaque demande d’achat, utilisé comme identifiant principal du dossier dans le processus.
Description L’identifiant 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 reçoit un identifiant unique lors de sa création, qui reste inchangé pendant tout son cycle de vie. Il permet de suivre la demande de bout en bout, depuis sa création et sa soumission initiales, à travers toutes les étapes d’approbation ou de rejet, jusqu’à son sourcing final et sa clôture. En Process Mining, chaque entrée du journal d’événements est associée à cet identifiant, ce qui permet de reconstituer le parcours complet de chaque dossier. Pourquoi c’est important Il s’agit du Case ID essentiel qui relie toutes les étapes du processus et permet d’analyser intégralement le cycle de vie de la demande d’achat, du début à la fin. Où les obtenir Il s’agit d’un champ de clé primaire présent dans le module Requisitions de Coupa et dans les exports de données associés. Exemples PR-102934PR-102935PR-102936
	Nom de l’activité ActivityName	Nom de l’activité métier ou de l’événement précis survenu à un moment donné pour la demande d’achat.
Description Cet attribut enregistre les différentes étapes du cycle de vie de la demande d’achat. Il peut notamment s’agir de « Demande d’achat créée », « Étape d’approbation approuvée » ou « Demande d’achat orientée vers le sourcing ». Chaque activité représente une étape importante ou une action précise effectuée sur la demande d’achat. L’analyse de la séquence et de la fréquence de ces activités est fondamentale en Process Mining, car elle permet de visualiser les cartes de processus, d’identifier les parcours courants et de détecter les écarts par rapport à la procédure standard. Pourquoi c’est important Il définit les étapes de la carte de processus et permet ainsi de visualiser et d’analyser le déroulement des demandes d’achat. Où les obtenir Il est généralement dérivé des journaux d’événements, des enregistrements de changement de statut ou des pistes d’audit du système Coupa. Une mise en correspondance à partir des champs de statut ou des codes d’action peut être nécessaire. Exemples Demande d’achat crééeDemande d’achat soumiseÉtape d’approbation approuvéeDemande d’achat rejetéeBon de commande créé
	Dernière mise à jour des données LastDataUpdate	Horodatage indiquant la dernière actualisation des données depuis le système source.
Description Cet attribut enregistre la date et l’heure de l’extraction de données la plus récente depuis Coupa. Il apporte de la transparence sur l’actualité des données analysées. Il est essentiel de connaître leur ancienneté pour déterminer si les analyses reflètent l’état opérationnel actuel ou une situation antérieure. Cela est particulièrement important pour les Dashboards qui suivent les opérations en cours. Pourquoi c’est important Informe les utilisateurs sur l’actualité des données afin qu’ils comprennent la période couverte par l’analyse et prennent leurs décisions à partir d’informations à jour. Où les obtenir Cet horodatage est généré et ajouté par le pipeline de données ou l’outil ETL à la fin d’une extraction réussie. Exemples 2024-05-21T02:00:00Z
	Système source SourceSystem	Identifie le système source depuis lequel les données ont été extraites.
Description Cet attribut précise le système de référence à l’origine des données du processus. Pour cette analyse, sa valeur sera toujours « Coupa ». L’inclusion de ce champ constitue une bonne pratique, notamment lorsque les données proviennent de plusieurs systèmes. Il fournit un contexte essentiel sur la traçabilité des données et contribue à la gestion des règles de gouvernance et de qualité des données. Pourquoi c’est important Fournit une traçabilité claire des données, essentielle à leur gouvernance et à la combinaison de données provenant de plusieurs systèmes d’entreprise. Où les obtenir Il s’agit généralement d’une valeur statique ajoutée lors de l’extraction et de la transformation des données afin d’indiquer l’origine du jeu de données. Exemples Coupa
	Approbateur Approver	Utilisateur ou groupe responsable d’une activité d’approbation.
Description Cet attribut identifie la personne ou le groupe d’approbation affecté à une étape d’approbation. Il est renseigné pour des activités telles que « Étape d’approbation démarrée », « Étape d’approbation approuvée » et « Étape d’approbation rejetée ». L’analyse des données par approbateur est essentielle à la création du Dashboard « Performance et charge des approbateurs ». Elle permet de mesurer les délais d’approbation individuels, d’identifier les goulots d’étranglement liés à certains approbateurs et d’évaluer la répartition de la charge de travail. Pourquoi c’est important Essentiel pour analyser la performance des approbateurs, équilibrer la charge de travail et identifier les goulots d’étranglement liés à certaines personnes ou à certains groupes d’approbation. Où les obtenir Ces informations figurent dans les détails de la chaîne d’approbation associée à chaque demande d’achat dans Coupa. Une jointure avec les données User peut être nécessaire. Exemples David MillerApprobateurs Finance, niveau 2Susan Chen
	Demandeur Requester	Employé qui a créé et soumis la demande d’achat.
Description Cet attribut identifie la personne à l’origine de la demande. L’analyse des données par demandeur permet d’identifier des tendances propres à certains utilisateurs, comme des taux élevés de modification ou des rejets fréquents, qui peuvent signaler un besoin de formation complémentaire. Il sert également à analyser les volumes de demandes d’achat et le comportement dans le processus pour différents utilisateurs ou groupes d’utilisateurs. Pourquoi c’est important Permet d’analyser le comportement dans le processus par utilisateur, d’identifier les besoins de formation et de comprendre la manière dont les différentes personnes interagissent avec le processus. Où les obtenir Disponible comme champ standard de l’objet Requisition dans Coupa, souvent associé à l’objet User et nommé « requester » ou « created_by ». Exemples Alice JohnsonBob SmithCharlie Brown
	Département Department	Département métier ou centre de coûts auquel la demande d’achat est imputée.
Description L’attribut Département associe chaque demande d’achat à une unité organisationnelle ou à un centre de coûts précis. Il s’agit d’une dimension importante pour les analyses comparatives. Les Dashboards et les KPI peuvent être filtrés et segmentés par département, ce qui permet aux responsables de comparer les délais d’approbation, les taux de rejet et la conformité entre les différentes entités de l’organisation. Cette approche aide à repérer les problèmes ou les bonnes pratiques propres à chaque département. Pourquoi c’est important Permet de comparer des KPI de processus, tels que les délais de traitement et les taux de rejet, entre différentes unités métier et de mettre en évidence les domaines à améliorer. Où les obtenir Il s’agit d’un champ standard de l’objet Requisition dans Coupa, souvent associé au profil utilisateur du demandeur ou renseigné au niveau des postes de la demande d’achat. Exemples MarketingOpérations informatiquesServices générauxRecherche et développement
	Montant total TotalAmount	Valeur monétaire totale de la demande d’achat.
Description Cet attribut représente le coût total de tous les biens et services demandés dans la demande. Ce montant constitue un facteur important pour l’analyse du processus, car il influence souvent la complexité du flux de travail d’approbation. Les demandes de montant élevé nécessitent généralement davantage d’étapes d’approbation. L’analyse des indicateurs du processus par paliers de valeur, par exemple < 1 000 $ ou de 1 000 $ à 10 000 $, peut révéler comment le processus traite les demandes selon leur importance financière. Pourquoi c’est important Permet d’analyser les variations du processus selon la valeur des demandes, les montants élevés déclenchant souvent des flux de travail d’approbation plus complexes. Où les obtenir Il s’agit d’un champ standard de l’en-tête de l’objet Requisition dans Coupa, généralement nommé « total » ou « total_amount ». Exemples 500.0012550.7599.99
	Statut de la demande d’achat RequisitionStatus	Statut actuel ou final de la demande d’achat.
Description Cet attribut indique l’état global de la demande d’achat au moment de l’extraction des données ou son résultat final. Les statuts courants comprennent « Pending Approval », « Approved », « Rejected », « Withdrawn » et « Closed ». Il s’agit d’une dimension essentielle pour le filtrage et l’analyse. Elle sert à calculer les taux d’approbation et de rejet, à suivre la charge de travail actuelle des demandes d’achat ouvertes et à comprendre le devenir final des demandes. Pourquoi c’est important Essentiel pour comprendre les résultats des demandes d’achat, calculer les taux d’approbation et de rejet et suivre l’état actuel des demandes en cours. Où les obtenir Il s’agit d’un champ standard de l’objet Purchase Requisition dans Coupa, souvent nommé « status » ou « state ». Exemples En attente d'approbationApprouvéeRejetéeRetiréeClôturée
	A été modifiée IsAmended	Indicateur booléen égal à true si la demande d’achat a été modifiée une ou plusieurs fois après sa soumission initiale.
Description Cet attribut calculé est un indicateur simple (True/False) qui précise si une activité « Demande d’achat modifiée » s’est produite pour un dossier donné. Il simplifie l’analyse et le filtrage en permettant d’isoler facilement les demandes d’achat ayant nécessité des modifications. Il sert à calculer le KPI de taux de modification des demandes d’achat et à alimenter le Dashboard « Volume de modifications des demandes d’achat », afin d’identifier les causes profondes des reprises et d’améliorer la qualité dès la première soumission. Pourquoi c’est important Simplifie le calcul du KPI de taux de modification et permet de segmenter facilement les dossiers ayant nécessité une reprise par rapport à ceux qui n’en ont pas nécessité. Où les obtenir Calculé dans l’outil de Process Mining en vérifiant l’existence d’une activité « Demande d’achat modifiée » dans le journal d’événements de chaque dossier. Exemples truefalse
	Catégorie d’achat Commodity	Catégorie générale des biens ou services demandés.
Description L’attribut Catégorie d’achat fournit une classification standardisée des articles d’une demande d’achat, par exemple « fournitures de bureau », « matériel informatique » ou « services marketing ». Il permet d’analyser les habitudes d’achat et les variations du processus selon les biens ou services acquis. Certaines catégories peuvent nécessiter des approbations ou des stratégies de sourcing spécifiques. L’analyse du processus par catégorie d’achat peut donc contribuer à optimiser les achats selon les catégories de dépenses. Pourquoi c’est important Aide à analyser les catégories de dépenses et à déterminer si le comportement du processus, notamment les délais d’approbation, varie selon le type de biens ou de services achetés. Où les obtenir Il s’agit d’un champ standard de Coupa, généralement disponible au niveau du poste de la demande d’achat. Il peut être nécessaire de l’agréger au niveau de l’en-tête. Exemples Fournitures de bureauMatériel informatiqueServices marketingDéplacements
	Devise Currency	Code devise du montant total de la demande d’achat.
Description Cet attribut précise la devise, par exemple USD, EUR ou GBP, dans laquelle est exprimé le montant total de la demande d’achat. Il fournit un contexte indispensable à toute analyse financière, en particulier pour les organisations internationales qui utilisent plusieurs devises. Il garantit une interprétation correcte des montants et permet leur conversion et leur agrégation dans les rapports financiers et les Dashboards. Pourquoi c’est important Fournit le contexte nécessaire à l’attribut « Montant total » et garantit la fiabilité des analyses financières dans les environnements multidevises. Où les obtenir Il s’agit d’un champ standard de l’objet Requisition dans Coupa, généralement nommé « currency_code » ou de manière similaire. Exemples USDEURGBP
	Durée de l’étape d’approbation ApprovalStepDuration	Temps pendant lequel une demande d’achat est restée en attente à une étape d’approbation donnée.
Description Cette métrique calculée mesure la durée entre une activité « Étape d’approbation démarrée » et l’activité correspondante « Étape d’approbation approuvée » ou « Étape d’approbation rejetée ». Elle isole le temps d’attente à chaque étape distincte de la chaîne d’approbation. Elle est essentielle au Dashboard « Goulots d’étranglement des étapes d’approbation prioritaires », car elle permet d’identifier précisément les approbateurs ou les étapes d’approbation responsables des retards les plus importants du processus global. Pourquoi c’est important Identifie précisément les goulots d’étranglement du flux de travail d’approbation en mesurant le temps d’attente à chaque étape, plutôt que le seul temps de cycle total. Où les obtenir Calculée dans l’outil de Process Mining en déterminant la différence entre « Étape d’approbation démarrée » et l’événement d’approbation terminal suivant (Approved/Rejected). Exemples 1,2 jour4 heures3,8 jours
	Identifiant du bon de commande PurchaseOrderId	Identifiant du bon de commande créé à partir de la demande d’achat approuvée.
Description Une fois la demande d’achat entièrement approuvée et orientée vers le sourcing, un bon de commande est généralement créé. Cet attribut contient l’identifiant du PO ainsi généré. Il constitue un lien essentiel entre le processus de demande d’achat en amont et le processus de bon de commande en aval. Il permet de calculer le KPI « délai entre l’approbation de la demande d’achat et la création du PO » et d’analyser de bout en bout l’ensemble du cycle Purchase-to-Pay. Pourquoi c’est important Relie la demande d’achat au bon de commande suivant, ce qui permet d’analyser le délai de transmission et d’obtenir une vue P2P plus complète, de bout en bout. Où les obtenir Il s’agit d’un champ standard de l’objet Requisition dans Coupa, renseigné après la création du PO. Exemples PO-45000123PO-45000124PO-45000125
	Motif du rejet RejectionReason	Motif fourni par un approbateur lorsqu’une demande d’achat ou une étape d’approbation est rejetée.
Description Lorsqu’un approbateur rejette une demande d’achat, il indique souvent le motif de sa décision. Cet attribut enregistre cette explication textuelle. L’analyse des motifs de rejet fournit un retour qualitatif direct sur les raisons des échecs des demandes d’achat. Elle est particulièrement utile pour l’analyse des causes profondes et permet d’identifier des problèmes récurrents, tels qu’un codage incorrect, l’absence de budget ou une justification insuffisante, qui peuvent ensuite être traités par la formation ou l’amélioration du processus. Pourquoi c’est important Fournit une analyse directe des causes profondes des échecs du processus et aide à identifier les besoins de formation des utilisateurs ou de clarification du processus. Où les obtenir Ces informations sont généralement enregistrées dans le champ des commentaires ou des notes associé à un changement de statut vers « Rejected » dans l’historique d’approbation de la demande d’achat. Exemples Centre de coûts incorrectDépassement du budget du trimestreDemande en doubleJustification insuffisante fournie
	Niveau d’urgence UrgencyLevel	Classification indiquant le niveau d’urgence de la demande d’achat, par exemple « High », « Medium » ou « Low ».
Description Le niveau d’urgence, souvent associé à un champ de priorité, permet aux demandeurs de signaler les demandes nécessitant un traitement accéléré. Cet attribut est essentiel au Dashboard « Délai de traitement des demandes d’achat urgentes ». En comparant les délais des demandes d’achat hautement urgentes à ceux des demandes standard, les organisations peuvent évaluer l’efficacité de leurs mécanismes de priorisation et vérifier que les besoins urgents sont traités dans les délais. Pourquoi c’est important Permet de déterminer si les demandes urgentes sont traitées plus rapidement que les demandes standard et de vérifier l’efficacité des politiques de priorisation. Où les obtenir Il peut s’agir d’un champ standard ou personnalisé de l’objet Requisition dans Coupa. Consultez la documentation Coupa ou la configuration du système. Exemples ÉlevéeMoyenneFaible
	Nom du fournisseur SupplierName	Nom du fournisseur sélectionné pour la demande d’achat.
Description Cet attribut identifie le fournisseur prévu pour les biens ou services demandés. Le fournisseur peut être indiqué par le demandeur ou ajouté ultérieurement au cours du processus de sourcing. L’analyse des métriques du processus par fournisseur peut aider à évaluer la performance des fournisseurs et à déterminer si les échanges avec certains d’entre eux entraînent des délais plus longs ou d’autres inefficacités. Elle fournit un contexte important pour la stratégie d’approvisionnement et la gestion des relations fournisseurs. Pourquoi c’est important Permet d’analyser la performance du processus selon le fournisseur sélectionné et d’éclairer les stratégies de sourcing ainsi que la gestion des fournisseurs. Où les obtenir Ces informations sont disponibles dans l’objet Requisition Line de Coupa, souvent dans un champ « supplier » ou « vendor ». Exemples StaplesDell TechnologiesAccentureCDW
	Nombre d’étapes d’approbation ApprovalStepCount	Nombre total d’étapes d’approbation franchies par une demande d’achat.
Description Cet attribut calculé compte le nombre d’activités distinctes « Approval Step Approved » pour chaque demande. Il permet de quantifier la complexité du flux de travail d’approbation de chaque cas. Il constitue la base de l’indicateur « Nombre moyen d’étapes d’approbation » et aide à identifier les demandes qui suivent des parcours exceptionnellement longs ou complexes, ce qui peut indiquer la nécessité de simplifier le flux de travail. Pourquoi c’est important Quantifie la complexité du flux de travail d’approbation de chaque demande et aide à identifier les parcours trop complexes qui doivent être simplifiés. Où les obtenir Cette métrique est calculée dans l’outil de Process Mining en comptant les occurrences de « Étape d’approbation approuvée » pour chaque Case ID. Exemples 253
	Parcours du flux de travail d’approbation ApprovalWorkflowPath	Identifiant de la chaîne d’approbation ou du modèle de flux de travail appliqué à la demande.
Description Cet attribut identifie la séquence prédéfinie des approbateurs que la demande est censée suivre. Elle est déterminée par des règles métier, souvent selon le montant, le service et le type de demande. L’analyse de cet attribut est au cœur du Dashboard « Conformité de la politique relative aux demandes ». En comparant la séquence réelle des approbateurs au parcours de flux de travail attribué, il devient possible de détecter les écarts, de mesurer les taux de conformité et d’identifier les exceptions non gérées. Pourquoi c’est important Permet d’analyser la conformité en comparant les étapes d’approbation attendues et réelles et en mettant en évidence les écarts du processus. Où les obtenir Consultez la documentation Coupa. Cette information peut être déduite du nom de la chaîne d’approbation ou de la règle de flux de travail déclenchée pour la demande. Exemples Approbation standard < 5 k$Approbation du matériel informatique > 10 k$Examen par le directeur financier des dépenses d'investissement
	Type de demande d’achat RequisitionType	Catégorie ou type de la demande d’achat, par exemple « dépense d’investissement », « dépense opérationnelle » ou « logiciel ».
Description Le type de demande d’achat est une classification qui permet de catégoriser les demandes selon leur objectif métier ou la nature de l’achat. Cet attribut est utile pour les analyses de conformité et pour comprendre comment les différents types de demandes suivent le processus. Par exemple, les demandes de dépenses d’investissement peuvent suivre un parcours d’approbation plus strict et plus long que les demandes opérationnelles standard. L’analyse du processus par type de demande d’achat peut révéler des possibilités d’optimisation. Pourquoi c’est important Permet de segmenter l’analyse selon l’objectif métier de la demande, car les différents types peuvent suivre des parcours et être soumis à des politiques distincts. Où les obtenir Il s’agit probablement d’un champ de classification standard ou personnalisé de l’objet Requisition dans Coupa. Exemples Dépense d'investissementDépense opérationnelleMatériel informatiqueServices professionnels

Obligatoire Recommandé Facultatif

Purchase to Pay - Requisition : activités

Voici les principales étapes et les principaux jalons à capturer dans votre journal d’événements pour découvrir précisément votre flux de travail Purchase to Pay, Requisition.

6 Recommandé 6 Facultatif

	Activité	Description
	Bon de commande créé	Un bon de commande (PO) est généré avec succès à partir des informations de la demande d’achat approuvée. Cet événement est déduit lorsqu’un enregistrement de PO faisant référence à l’identifiant de la demande d’achat source est créé.
Pourquoi c’est important Il s’agit du principal résultat positif du processus de demande d’achat et du passage à l’étape suivante du processus Purchase-to-Pay. L’analyse du délai entre « Demande d’achat approuvée » et cet événement met en évidence les éventuels retards d’exécution. Où les obtenir Déduite de la création d’un enregistrement dans la table « purchase_orders » contenant une référence vers l’identifiant d’origine de la table « requisition_headers » ou « requisition_lines ». Collecte Utiliser l’horodatage « created-at » de l’enregistrement du PO associé à l’identifiant de la demande d’achat. Type d’événement inferred
	Demande d’achat approuvée	La demande a franchi avec succès toutes les étapes requises du flux de travail d’approbation. Cet événement est déduit du changement d’état global de l’en-tête de la demande, qui passe à « approved ».
Pourquoi c’est important Il s’agit d’une étape de réussite importante, qui marque la fin du cycle d’approbation. Le délai nécessaire pour atteindre cette activité constitue un KPI principal et déclenche les actions d’approvisionnement en aval. Où les obtenir Déduite d’un changement de statut de la table « requisition_headers » lorsque le champ « status » est mis à jour avec la valeur « approved ». L’horodatage est enregistré dans la piste d’audit associée. Collecte Identifier l’horodatage auquel le statut global de la demande d’achat passe à « approved ». Type d’événement inferred
	Demande d’achat clôturée	La demande d’achat est officiellement clôturée, ce qui signifie qu’aucune autre action ne sera effectuée. Cela peut se produire après la création et l’exécution d’un PO, ou si la demande d’achat est annulée après son approbation, mais avant la commande.
Pourquoi c’est important Cette activité marque définitivement la fin du cycle de vie de la demande d’achat. Elle garantit une clôture claire des dossiers et évite qu’ils apparaissent indéfiniment comme « actifs » dans l’analyse des processus. Où les obtenir Déduite d’un changement de statut de la table « requisition_headers » lorsque le champ « status » est mis à jour avec la valeur « closed ». L’horodatage est enregistré dans la piste d’audit associée. Collecte Identifier l’horodatage auquel le statut global de la demande d’achat passe à « closed ». Type d’événement inferred
	Demande d’achat créée	Un utilisateur crée une nouvelle demande d’achat et l’enregistre comme brouillon. Il s’agit du point de départ de chaque cas de demande d’achat, généralement déduit de l’horodatage de création de l’enregistrement de la demande.
Pourquoi c’est important Cette activité marque le début du cycle de vie de la demande d’achat. L’analyse du délai entre la création et la soumission peut révéler des retards dus à l’hésitation de l’utilisateur ou à la complexité du système. Où les obtenir Cet événement est capturé à partir de l’horodatage « created-at » de la table « requisition_headers » pour un identifiant de demande d’achat donné. Collecte Utilisez l’horodatage de création de l’enregistrement d’en-tête de la demande d’achat. Type d’événement inferred
	Demande d’achat rejetée	La demande d’achat est définitivement rejetée au cours du processus d’approbation et ne sera pas convertie en bon de commande. Cette situation est déduite du passage du statut global de l’en-tête de la demande d’achat à « rejected ».
Pourquoi c’est important Cette activité représente un échec définitif du processus. L’analyse de ces événements est essentielle pour améliorer le « taux de rejet des demandes d’achat » et identifier les causes profondes, telles que le non-respect des politiques ou les problèmes budgétaires. Où les obtenir Déduite d’un changement de statut de la table « requisition_headers » lorsque le champ « status » est mis à jour avec la valeur « rejected ». L’horodatage est enregistré dans la piste d’audit associée. Collecte Identifier l’horodatage auquel le statut global de la demande d’achat passe à « rejected ». Type d’événement inferred
	Demande d’achat soumise	Le demandeur soumet officiellement la demande complétée dans le flux de travail d’approbation. Cet événement est déduit du changement d’état de la demande, qui passe de « draft » à « pending_approval » dans les journaux d’audit ou les tables d’historique du système.
Pourquoi c’est important La soumission déclenche le processus d’approbation et constitue donc une étape essentielle pour mesurer le KPI « Average Requisition Approval Cycle Time ». Les retards antérieurs à cette étape sont liés à l’utilisateur, tandis que ceux qui surviennent ensuite sont liés au processus. Où les obtenir Cet événement est déduit d’un changement de statut dans la table « requisition_headers », plus précisément lorsque le champ « status » prend la valeur « pending_approval ». L’horodatage de cette modification figure dans la piste d’audit associée. Collecte Identifiez l’horodatage auquel le statut de la demande d’achat passe pour la première fois à « pending_approval ». Type d’événement inferred
	Demande d’achat modifiée	Le demandeur ou un autre utilisateur autorisé modifie la demande après sa soumission. Coupa enregistre explicitement cette modification comme une nouvelle version ou une entrée d’audit, ce qui réinitialise souvent tout ou partie du flux de travail d’approbation.
Pourquoi c’est important Le suivi des modifications est essentiel pour comprendre les reprises et les inefficacités du processus. Un volume élevé de modifications peut révéler des exigences initiales peu claires ou des politiques d’achat complexes, ce qui affecte le KPI « Requisition Amendment Rate ». Où les obtenir Cet événement est capturé dans les tables de piste d’audit associées à la table « requisition_headers », qui consignent les changements de version ou les actions « edit » spécifiques. Collecte Recherchez les événements explicites « edit » ou « update » dans le journal d’historique de la demande d’achat après sa soumission. Type d’événement explicit
	Demande d’achat orientée vers le sourcing	La demande d’achat approuvée est envoyée vers un événement de sourcing, tel qu’un RFQ ou une enchère, au lieu d’être immédiatement convertie en bon de commande. Cet événement est déduit lorsque la demande d’achat est associée à un objet d’événement de sourcing.
Pourquoi c’est important Cette activité révèle une voie alternative importante du processus d’approvisionnement. Elle distingue les achats simples des activités de sourcing plus complexes et stratégiques, ce qui permet une analyse plus précise des délais de traitement. Où les obtenir Déduite de la détection d’un changement de statut vers « sourcing » ou de la création d’un lien entre la table « requisition_lines » et une table d’événements de sourcing. Collecte Vérifier le changement de statut vers « sourcing » ou la création d’un lien vers un identifiant d’événement de sourcing. Type d’événement inferred
	Demande d’achat retirée	Le demandeur initial annule la demande d’achat avant son approbation finale. Il s’agit d’une action explicite effectuée par l’utilisateur, qui met fin au processus pour cette demande.
Pourquoi c’est important Les retraits peuvent signaler une évolution des besoins de l’entreprise, des demandes en double ou un contournement du processus par les utilisateurs. Leur suivi permet de mieux comprendre la volatilité de la demande et les éventuels problèmes de respect du processus. Où les obtenir Déduite d’un changement de statut de la table « requisition_headers » vers « withdrawn » ou vers un état similaire, à partir d’une action explicite de l’utilisateur enregistrée dans la piste d’audit. Collecte Identifier l’horodatage auquel le statut de la demande d’achat passe à « withdrawn ». Type d’événement inferred
	Étape d’approbation approuvée	Un approbateur donne son accord pour la demande à l’étape qui lui est attribuée dans le flux de travail. Il s’agit d’une action explicite enregistrée par le système, avec un horodatage précis et les informations relatives à l’utilisateur.
Pourquoi c’est important Cette activité fournit une analyse détaillée du déroulement du processus d’approbation. L’agrégation de ces étapes permet de calculer le « temps d’attente moyen par étape d’approbation » et d’analyser la performance des approbateurs. Où les obtenir Capturée à partir d’une action explicite « approve » enregistrée dans la table « approvals » ou dans sa piste d’audit, et associée à la demande d’achat et à l’approbateur concernés. Collecte Filtrer les événements « approve » dans l’historique d’approbation de la demande d’achat. Type d’événement explicit
	Étape d’approbation démarrée	Une tâche d’approbation est attribuée à un approbateur ou à un groupe d’approbation précis, et la demande d’achat attend désormais son intervention. Cet événement est déduit lorsqu’un enregistrement d’approbation associé à la demande est créé avec le statut « pending ».
Pourquoi c’est important Cette étape marque le début du temps d’attente pour une approbation donnée. La mesure de la durée entre cet événement et l’événement correspondant « Approval Step Approved/Rejected » permet d’identifier les goulots d’étranglement du circuit d’approbation. Où les obtenir Cet événement est déduit de l’horodatage de création d’un enregistrement de la table « approvals » associé à la demande d’achat, lorsque le statut de l’action de l’approbateur est « pending » ou équivalent. Collecte Utilisez l’horodatage de création de l’enregistrement d’approbation en attente d’un utilisateur dans le circuit d’approbation. Type d’événement inferred
	Étape d’approbation rejetée	Un approbateur rejette la demande à l’étape qui lui est attribuée dans le flux de travail, ce qui la renvoie généralement au demandeur pour modification. Coupa enregistre explicitement cette action.
Pourquoi c’est important Les rejets à n’importe quelle étape entraînent des reprises et allongent les délais de traitement. L’analyse des lieux et des causes de ces rejets est essentielle pour améliorer le processus et former les utilisateurs. Où les obtenir Capturée à partir d’une action explicite « reject » enregistrée dans la table « approvals » ou dans sa piste d’audit, et associée à la demande d’achat et à l’approbateur concernés. Collecte Filtrer les événements « reject » dans l’historique d’approbation de la demande d’achat. Type d’événement explicit

Recommandé Facultatif

Guides d’extraction

Comment récupérer vos données depuis Coupa

Étapes

Connectez-vous à Coupa : accédez à votre instance Coupa avec un compte utilisateur disposant des autorisations nécessaires pour créer et planifier des rapports.
Accédez au module Reporting : ouvrez l’onglet « Setup » et repérez la section « Reporting ». Sélectionnez « Reports » pour ouvrir le Dashboard de reporting.
Créez un rapport personnalisé : cliquez sur le bouton « Create » pour commencer un nouveau rapport. Sélectionnez « Custom Report » comme type de rapport.
Définissez les sources de données du rapport : dans le générateur de rapports, sélectionnez et joignez plusieurs sources de données afin de réunir toutes les informations nécessaires. Commencez par « Requisition Headers » comme source principale. Ajoutez ensuite les objets associés suivants :
- « Approvals » : pour obtenir les détails de chaque étape d’approbation, notamment l’approbateur, l’état et les horodatages.
- « Requisition Lines » : pour agréger les montants totaux et obtenir les détails au niveau des articles.
- « Purchase Order Headers » : pour identifier le moment où une demande est convertie en bon de commande.
- « Users » : pour récupérer les noms complets et les informations de service des demandeurs et des approbateurs.
Configurez les colonnes du rapport : faites glisser les champs nécessaires depuis les sources de données disponibles vers la mise en page du rapport. Cette étape est la plus importante, car ces colonnes serviront à générer le journal d’événements. Incluez au moins les champs suivants :
- Depuis Requisition Headers : Requisition #, Created At, Submitted At, Updated At, État, Created by (Login ID), Total, Sourced Externally?
- Depuis Users, pour le demandeur : Nom complet, Department Name.
- Depuis Approvals : Created At, Updated At, État, Approver (Login ID).
- Depuis Purchase Order Headers : PO Number, Created At.
Définissez les filtres du rapport : appliquez des filtres pour limiter l’extraction. Un filtre courant et efficace consiste à utiliser « Requisition Headers - Created At » et à définir une période dynamique, par exemple « Last 90 days ». Vous pouvez également filtrer selon certains codes société, si nécessaire.
Planifiez le rapport : ouvrez l’onglet « Schedule » dans le générateur de rapports. Définissez la fréquence d’exécution, par exemple quotidienne ou hebdomadaire, puis choisissez une période de faible activité.
Configurez la diffusion : indiquez le mode de diffusion. Pour automatiser le processus, sélectionnez « SFTP » et renseignez les identifiants du serveur ainsi que le répertoire cible. Vous pouvez également envoyer le fichier à une adresse e-mail. Choisissez « CSV » comme format de fichier.
Enregistrez et activez : enregistrez le rapport et vérifiez que la planification est activée. Le premier rapport sera exécuté à la prochaine échéance prévue.
Transformez les données : le fichier CSV généré est un fichier plat, et non un journal d’événements. Vous devez utiliser un script externe, par exemple en Python, ou un outil ETL pour le traiter. Le script doit faire pivoter les données afin de créer une ligne distincte pour chaque activité, par exemple une ligne « Requisition Created » utilisant la colonne Created At, une ligne pour chaque étape d’approbation utilisant les colonnes « Approvals », et une ligne « Purchase Order Created » utilisant la colonne Created At du bon de commande.
Générez le journal d’événements final : le script de transformation doit produire un fichier CSV final contenant les colonnes requises : PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, ainsi que les autres attributs recommandés. Ce fichier est alors prêt à être importé.

Configuration

Sources de données principales : le rapport doit être construit en reliant plusieurs objets Coupa. Les sources clés sont « Requisition Headers », « Approvals », « Requisition Lines » et « Purchase Order Headers ».
Filtrage par période : il est essentiel d’appliquer un filtre de date pour limiter le volume de données. Une période glissante couvrant les 3 à 6 derniers mois, fondée sur « Requisition Headers - Created At », constitue un bon point de départ.
Chargements incrémentiels : pour assurer une analyse continue, planifiez une exécution quotidienne du rapport et extrayez les données de la veille, par exemple « Yesterday », afin de créer des chargements incrémentiels.
Configuration de la livraison : configurez la livraison vers un serveur SFTP pour une intégration automatisée avec votre pipeline de données. Vérifiez que la destination est sécurisée et dispose d’un espace de stockage suffisant.
Autorisations requises : le compte utilisateur qui configure le rapport doit disposer d’autorisations d’administration ou de reporting lui permettant de créer, planifier et consulter tous les objets nécessaires, notamment les demandes, les commandes d’achat, les approbations et les utilisateurs.

a Exemple de requête config

This extraction is configured within the Coupa UI and does not use a direct script. The following outlines the objects and fields required to build the report, which is then transformed into an event log.

**Data Sources (Objects to Join):**
1.  `Requisition Headers` (Primary)
2.  `Approvals` (Joined on Requisition Header ID)
3.  `Users` (Joined from `Requisition Headers` for Requester details)
4.  `Users` (Joined from `Approvals` for Approver details)
5.  `Purchase Order Headers` (Joined on Requisition Header ID)

**Report Columns Configuration (Fields to Select):**

*   **For 'Requisition Created' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Requisition #` -> Maps to `PurchaseRequisitionId`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Requisition Submitted' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Submitted At` -> Maps to `EventTime`

*   **For 'Requisition Amended' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime` (Logic must be applied to identify updates after submission)

*   **For 'Approval Step Started' event:**
    *   Source Object: `Approvals`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For 'Approval Step Approved' / 'Approval Step Rejected' events:**
    *   Source Object: `Approvals`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName` ('Approved' or 'Rejected')

*   **For 'Requisition Withdrawn' / 'Requisition Approved' / 'Requisition Rejected' / 'Requisition Closed' events:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Status` -> Used to determine `ActivityName`

*   **For 'Requisition Sourced' event:**
    *   Source Object: `Requisition Headers`
    *   Source Field: `Updated At` -> Maps to `EventTime`
    *   Source Field: `Sourced Externally?` -> Used in logic to identify this event

*   **For 'Purchase Order Created' event:**
    *   Source Object: `Purchase Order Headers`
    *   Source Field: `Created At` -> Maps to `EventTime`

*   **For General Attributes:**
    *   `Requisition Headers | Requisition #` -> `PurchaseRequisitionId`
    *   `Requisition Headers | Status` -> `RequisitionStatus`
    *   `Requisition Headers | Created By (Full Name)` -> `Requester`
    *   `Requisition Headers | Account Department` -> `Department`
    *   `Requisition Headers | Total` -> `TotalAmount`
    *   `Approvals | Approver (Full Name)` -> `Approver`

Étapes

Prérequis : vérifiez qu’un environnement Python 3 est installé. Installez les bibliothèques nécessaires, pandas et requests, en exécutant pip install pandas requests dans votre terminal ou votre invite de commandes.
Obtenez une clé API Coupa : connectez-vous à votre instance Coupa en tant qu’administrateur. Accédez à Setup > Company Setup > API Keys. Créez une clé API disposant au minimum d’autorisations de lecture pour les périmètres suivants : core.purchase_order.read, core.requisition.read et core.user.read.
Configurez le script : créez un nouveau fichier Python, par exemple extract_coupa_reqs.py. Copiez-y le script Python fourni. Remplacez les valeurs fictives de COUPA_INSTANCE_URL par l’URL Coupa de votre entreprise, par exemple https://yourcompany.coupahost.com, et renseignez dans API_KEY la clé obtenue à l’étape précédente.
Définissez les paramètres d’extraction : dans la section main du script, ajustez les variables START_DATE et END_DATE pour définir la période d’extraction. Ce filtre s’applique à la date de création des demandes.
Exécutez le script : lancez-le depuis votre terminal avec la commande python extract_coupa_reqs.py. Le script se connectera à l’API Coupa, récupérera les données et affichera l’avancement dans la console.
Gérez la pagination de l’API : le script comprend une fonction qui gère automatiquement la pagination. Il récupère les données par lots de 50 enregistrements et poursuit jusqu’à l’extraction de toutes les demandes comprises dans la période définie.
Traitez les données des demandes : pour chaque en-tête de demande récupéré, le script génère les événements « Requisition Created » et « Requisition Submitted ». Il effectue ensuite des appels API supplémentaires pour récupérer les données associées aux approbations et aux commandes d’achat.
Générez les événements d’activité : le script traite les enregistrements d’approbation pour créer les événements « Approval Step Started », « Approval Step Approved » et « Approval Step Rejected ». Il vérifie également le statut final de la demande et les données associées afin de générer des événements tels que « Requisition Approved », « Purchase Order Created » et « Requisition Withdrawn ».
Détectez les modifications : le script vérifie l’attribut version de chaque demande. Si la version est supérieure à 1, cela indique une modification. Un événement « Requisition Amended » est créé à partir de l’horodatage updated-at de la nouvelle version.
Assemblez l’Event Log : tous les événements générés sont regroupés dans une liste structurée. Chaque événement comprend les attributs requis, tels que PurchaseRequisitionId, ActivityName et EventTime, ainsi que les attributs recommandés, comme Requester et TotalAmount.
Exportez au format CSV : une fois toutes les demandes traitées, le script convertit la liste finale d’événements en DataFrame pandas et l’enregistre dans un fichier CSV nommé coupa_requisition_event_log.csv, dans le même répertoire. Ce fichier est formaté pour être importé directement dans ProcessMind.

Configuration

Autorisations de la clé API : la clé API utilisée pour l’extraction doit disposer d’un accès en lecture aux objets requisition_headers, requisition_lines, approvals, purchase_orders et users dans Coupa. Sans ces autorisations, le script échouera ou renverra des données incomplètes.
Période : le script utilise un filtre fondé sur la date de création de la demande (created-at). Il est recommandé d’extraire les données par périodes gérables, par exemple 3 à 6 mois à la fois, afin d’éviter des temps d’exécution trop longs et d’éventuels dépassements de délai de l’API. Ajustez les variables START_DATE et END_DATE en conséquence.
Filtrage par statut : le script fourni récupère toutes les demandes, quel que soit leur statut. Pour cibler une analyse, vous pouvez ajouter un paramètre status au dictionnaire params du premier appel API afin de sélectionner des statuts précis, tels que approved, pending_approval ou ordered.
Limite de pagination : le script est configuré pour récupérer 50 enregistrements par appel API (limit=50). Il s’agit d’une valeur standard qui fonctionne bien avec l’API Coupa. L’augmenter n’améliorera pas nécessairement les performances et pourrait accroître le risque de dépassement de délai pour les requêtes complexes.
Performances : le script effectue plusieurs appels API pour chaque demande, un pour l’en-tête, un pour les approbations et un pour les commandes d’achat. L’extraction de milliers de demandes peut prendre du temps et être soumise aux limites de débit de l’API Coupa. Il est préférable d’exécuter le script en dehors des heures de pointe.

a Exemple de requête python

import requests
import pandas as pd
from datetime import datetime, timezone

class=class="hl-string">"hl-comment"># --- Configuration ---
class=class="hl-string">"hl-comment"># Replace with your Coupa instance URL and API Key
COUPA_INSTANCE_URL = class="hl-string">"https://[your_instance].coupahost.com"
API_KEY = class="hl-string">"[your_api_key]"

class=class="hl-string">"hl-comment"># --- Main Extraction Logic ---

def get_coupa_data(endpoint, params={}):
    class="hl-string">"""Fetches paginated data from a Coupa API endpoint."""
    headers = {
        class="hl-string">"Accept": class="hl-string">"application/json",
        class="hl-string">"X-COUPA-API-KEY": API_KEY
    }
    
    all_records = []
    offset = 0
    limit = 50
    
    while True:
        paginated_params = params.copy()
        paginated_params[class="hl-string">'offset'] = offset
        paginated_params[class="hl-string">'limit'] = limit
        
        try:
            response = requests.get(fclass="hl-string">"{COUPA_INSTANCE_URL}{endpoint}", headers=headers, params=paginated_params)
            response.raise_for_status() class=class="hl-string">"hl-comment"># Raises an exception for 4xx/5xx errors
            data = response.json()
            
            if not data:
                break
                
            all_records.extend(data)
            offset += limit
        except requests.exceptions.RequestException as e:
            print(fclass="hl-string">"Error fetching data from {endpoint}: {e}")
            break
            
    return all_records

def main(start_date, end_date):
    class="hl-string">"""Main function to extract, transform, and save the event log.""" 
    print(class="hl-string">"Starting Coupa Requisition data extraction...")
    
    event_log = []
    current_time_utc = datetime.now(timezone.utc).isoformat()

    class=class="hl-string">"hl-comment"># 1. Fetch Requisition Headers within the date range
    req_params = {
        class="hl-string">"created-at[gt]": start_date,
        class="hl-string">"created-at[lt]": end_date,
        class="hl-string">"fields": class="hl-string">'["id", "created-at", "submitted-at", "updated-at", "version", "status", "total", "requester", "currency", "sourcing-event-id"]'
    }
    requisition_headers = get_coupa_data(class="hl-string">"/api/requisition_headers", req_params)
    print(fclass="hl-string">"Found {len(requisition_headers)} requisitions to process.")

    for i, header in enumerate(requisition_headers):
        print(fclass="hl-string">"Processing requisition {i+1}/{len(requisition_headers)}: ID {header['id']}")
        
        class=class="hl-string">"hl-comment"># Common attributes for all events of this case
        case_id = str(header[class="hl-string">'id'])
        total_amount = header.get(class="hl-string">'total', {}).get(class="hl-string">'total')
        requester_name = fclass="hl-string">"{header.get('requester', {}).get('firstname', '')} {header.get('requester', {}).get('lastname', '')}".strip()
        department_name = header.get(class="hl-string">'requester', {}).get(class="hl-string">'department', {}).get(class="hl-string">'name')

        base_event = {
            class="hl-string">"PurchaseRequisitionId": case_id,
            class="hl-string">"TotalAmount": total_amount,
            class="hl-string">"Requester": requester_name,
            class="hl-string">"Department": department_name,
            class="hl-string">"Approver": None,
            class="hl-string">"SourceSystem": class="hl-string">"Coupa",
            class="hl-string">"LastDataUpdate": current_time_utc
        }

        class=class="hl-string">"hl-comment"># Activity: Requisition Created
        event_log.append({
            **base_event,
            class="hl-string">"ActivityName": class="hl-string">"Requisition Created",
            class="hl-string">"EventTime": header[class="hl-string">'created-at'],
            class="hl-string">"RequisitionStatus": class="hl-string">"draft"
        })

        class=class="hl-string">"hl-comment"># Activity: Requisition Submitted
        if header.get(class="hl-string">'submitted-at'):
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Submitted",
                class="hl-string">"EventTime": header[class="hl-string">'submitted-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval"
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Amended
        if header.get(class="hl-string">'version') and int(header[class="hl-string">'version']) > 1:
             event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Amended",
                class="hl-string">"EventTime": header[class="hl-string">'updated-at'], class=class="hl-string">"hl-comment"># Timestamp of the new version
                class="hl-string">"RequisitionStatus": header[class="hl-string">'status']
            })

        class=class="hl-string">"hl-comment"># 2. Fetch Approvals for this requisition
        approval_params = {
            class="hl-string">"approvable-id": header[class="hl-string">'id'],
            class="hl-string">"approvable-type": class="hl-string">"RequisitionHeader"
        }
        approvals = get_coupa_data(class="hl-string">"/api/approvals", approval_params)

        for approval in approvals:
            approver = approval.get(class="hl-string">'approver', {}).get(class="hl-string">'fullname')
            approval_status = approval[class="hl-string">'status']

            class=class="hl-string">"hl-comment"># Activity: Approval Step Started
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Approval Step Started",
                class="hl-string">"EventTime": approval[class="hl-string">'created-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                class="hl-string">"Approver": approver
            })

            if approval_status == class="hl-string">'approved':
                class=class="hl-string">"hl-comment"># Activity: Approval Step Approved
                event_log.append({
                    **base_event,
                    class="hl-string">"ActivityName": class="hl-string">"Approval Step Approved",
                    class="hl-string">"EventTime": approval[class="hl-string">'updated-at'],
                    class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                    class="hl-string">"Approver": approver
                })
            elif approval_status == class="hl-string">'rejected':
                class=class="hl-string">"hl-comment"># Activity: Approval Step Rejected
                event_log.append({
                    **base_event,
                    class="hl-string">"ActivityName": class="hl-string">"Approval Step Rejected",
                    class="hl-string">"EventTime": approval[class="hl-string">'updated-at'],
                    class="hl-string">"RequisitionStatus": class="hl-string">"pending_approval",
                    class="hl-string">"Approver": approver
                })
        
        class=class="hl-string">"hl-comment"># 3. Handle final status and related events
        final_status_event_time = header[class="hl-string">'updated-at']
        final_status = header[class="hl-string">'status']

        if final_status == class="hl-string">'approved':
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Approved",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        elif final_status == class="hl-string">'rejected':
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Rejected",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        elif final_status == class="hl-string">'withdrawn':
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Withdrawn",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })
        elif final_status == class="hl-string">'closed':
             event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Closed",
                class="hl-string">"EventTime": final_status_event_time,
                class="hl-string">"RequisitionStatus": final_status
            })

        class=class="hl-string">"hl-comment"># Activity: Requisition Sourced
        if header.get(class="hl-string">'sourcing-event-id'):
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Requisition Sourced",
                class="hl-string">"EventTime": final_status_event_time, class=class="hl-string">"hl-comment"># Assumes status update time reflects sourcing
                class="hl-string">"RequisitionStatus": final_status
            })

        class=class="hl-string">"hl-comment"># 4. Fetch Purchase Orders to detect PO Creation
        po_params = {class="hl-string">"requisition-header-id": header[class="hl-string">'id']}
        purchase_orders = get_coupa_data(class="hl-string">"/api/purchase_orders", po_params)

        for po in purchase_orders:
            event_log.append({
                **base_event,
                class="hl-string">"ActivityName": class="hl-string">"Purchase Order Created",
                class="hl-string">"EventTime": po[class="hl-string">'created-at'],
                class="hl-string">"RequisitionStatus": class="hl-string">"ordered" 
            })

    class=class="hl-string">"hl-comment"># 5. Create and save the DataFrame
    if not event_log:
        print(class="hl-string">"No events were generated. The output file will be empty.")
        return

    df = pd.DataFrame(event_log)
    df = df.sort_values(by=[class="hl-string">"PurchaseRequisitionId", class="hl-string">"EventTime"])
    df.to_csv(class="hl-string">"coupa_requisition_event_log.csv", index=False)
    print(class="hl-string">"\nExtraction complete. Event log saved to coupa_requisition_event_log.csv")

if __name__ == class="hl-string">"__main__":
    class=class="hl-string">"hl-comment"># Define the extraction period. Format: YYYY-MM-DDTHH:MM:SSZ
    START_DATE = class="hl-string">"2023-01-01T00:00:00Z"
    END_DATE = class="hl-string">"2023-06-30T23:59:59Z"
    main(START_DATE, END_DATE)

Étapes

Vérifiez que la plateforme iPaaS ou de Process Mining sélectionnée fournit un connecteur Coupa validé, avec accès aux en-têtes des demandes, à l’historique ou aux données d’audit des demandes, aux enregistrements d’approbation, aux relations de sourcing, aux relations avec les commandes d’achat et aux informations de clôture. Les noms des connecteurs et des objets ainsi que les champs disponibles varient selon le fournisseur. Configurez-les conformément à la documentation du connecteur et à votre environnement Coupa.
Créez une connexion au connecteur depuis l’interface de connexion de la plateforme. Renseignez l’URL de votre environnement Coupa, le mode d’authentification, les identifiants, les paramètres OAuth et les périmètres requis. Utilisez des valeurs fictives telles que [Your Coupa tenant URL] et [Your connector credentials] jusqu’à la configuration de la connexion dans l’environnement cible.
Définissez le périmètre d’extraction. Sélectionnez d’abord une période glissante de trois à six mois, puis élargissez-la après rapprochement. Appliquez uniquement les filtres valides pour votre environnement, tels que [Your company filter] ou [Your document type filter]. N’excluez pas les demandes uniquement parce que leur statut actuel est closed, rejected, withdrawn ou approved, car ces cas sont nécessaires à l’analyse du cycle de vie.
Mappez les objets sources dans le connecteur. Sélectionnez l’objet d’en-tête de demande, l’objet d’historique ou d’audit de demande, l’objet d’approbation, l’objet de relation de sourcing, l’objet de relation avec la commande d’achat et tout objet d’historique de clôture ou de statut exposé par le connecteur. Si un objet requis n’est pas disponible, utilisez la représentation d’historique ou d’audit prise en charge par le connecteur, ou documentez cette limitation avant de publier l’extraction.
Configurez les correspondances des dossiers et des événements. Associez l’identifiant de la demande à PurchaseRequisitionId, le libellé de l’événement à ActivityName, l’horodatage source à EventTime, la valeur source constante Coupa à SourceSystem et l’horodatage d’actualisation du connecteur à LastDataUpdate. Associez également le demandeur, le département, le montant total, le statut de la demande et l’approbateur lorsque ces champs sont disponibles.
Configurez des règles d’événement qui créent explicitement des lignes pour les douze activités. Créez Requisition Created à partir de l’horodatage de création de la demande, Requisition Submitted lors du passage de draft à pending_approval, Requisition Amended à partir d’une version ou d’une entrée d’audit postérieure à la soumission, Approval Step Started à partir d’un enregistrement d’approbation en attente, Approval Step Approved à partir d’une action d’approbation, Approval Step Rejected à partir d’une action de rejet, Requisition Withdrawn à partir d’une action de retrait explicite ou d’un changement de statut, Requisition Approved à partir du passage de l’en-tête au statut approved, Requisition Rejected à partir du passage de l’en-tête au statut rejected, Requisition Sourced à partir d’une relation entre la demande et le sourcing, Purchase Order Created à partir d’une commande d’achat faisant référence à la demande et Requisition Closed à partir d’une action ou d’un changement de statut de clôture.
Normalisez les données extraites avant de réunir les flux d’événements. Convertissez tous les horodatages dans un même fuseau, de préférence UTC, conservez la précision des horodatages sources, convertissez l’identifiant de la demande dans un type texte cohérent et conservez les valeurs sources des statuts et des utilisateurs. Dédupliquez uniquement les enregistrements sources techniquement identiques, en utilisant comme clé de comparaison l’identifiant de la demande, le nom de l’activité, l’horodatage de l’événement, l’identifiant de l’enregistrement source lorsqu’il est disponible et l’approbateur.
Publiez ou planifiez le flux du connecteur. Effectuez une première extraction complète pour la période sélectionnée, puis des actualisations incrémentielles fondées sur l’horodatage de mise à jour de la source ou sur le mécanisme de suivi des changements pris en charge par le connecteur. Configurez une période de reprise afin d’inclure les entrées d’audit tardives et les enregistrements d’approbation modifiés.
Validez l’Event Log obtenu par rapport aux rapports Coupa ou à l’aperçu du connecteur. Vérifiez que chaque demande possède un événement de création, que les transitions de statut et d’approbation suivent la chronologie attendue et que les événements liés aux relations sont présents lorsqu’un sourcing ou une commande d’achat existe.
Exportez le résultat final au format CSV ou dans un autre format d’Event Log pris en charge par ProcessMind. Incluez une ligne par événement, utilisez PurchaseRequisitionId comme identifiant de dossier, ActivityName comme activité et EventTime comme horodatage de l’événement. Importez le fichier ou publiez le jeu de données du connecteur dans ProcessMind sans demander à ProcessMind de déduire les événements manquants.

Configuration

Connecteur et accès : utilisez un connecteur Coupa validé, fourni par la plateforme iPaaS ou de Process Mining sélectionnée. Les autorisations Coupa, les périmètres API, les modules et les licences du connecteur requis dépendent du fournisseur et de la configuration de l’environnement. Vérifiez l’accès aux données des demandes, de l’historique ou de l’audit, des approbations, du sourcing, des commandes d’achat et de la clôture avant la mise en œuvre.
Période : commencez par trois à six mois de données. Utilisez une fenêtre d’extraction glissante pour les actualisations planifiées et prévoyez une période de reprise afin de récupérer les mises à jour tardives, les actions d’approbation et les demandes modifiées.
Correspondances requises : associez l’identifiant de la demande à PurchaseRequisitionId, le libellé de l’événement à ActivityName, l’horodatage de l’événement à EventTime, la valeur source à SourceSystem et l’horodatage d’actualisation à LastDataUpdate.
Correspondances recommandées : associez le statut de la demande, le demandeur, le département ou le centre de coûts, le montant total et l’approbateur. Conservez les valeurs actuelles et les valeurs au niveau de l’événement lorsque le connecteur prend en charge les instantanés historiques.
Règles d’événement : configurez explicitement la création des douze activités requises. ProcessMind lit l’Event Log tel quel et ne dérive ni ne déduit d’événements supplémentaires.
Filtres : appliquez uniquement les filtres pris en charge par le connecteur et valides pour l’environnement, tels que [Your company filter], [Your document type filter], [Your business unit filter] ou [Your requisition date range]. Évitez d’exclure les statuts finaux, sauf si l’analyse l’exige précisément.
Gestion des horodatages : convertissez les horodatages dans un même fuseau, conservez la précision source et définissez une règle d’ordonnancement déterministe pour les événements ayant des horodatages identiques.
Actualisation incrémentielle : utilisez le champ updated-at ou le mécanisme de suivi des changements pris en charge par le connecteur. Configurez une période de reprise, car l’historique des approbations, les liens de sourcing, les liens vers les commandes d’achat et les informations de clôture peuvent être ajoutés après la création initiale.
Performances : limitez l’extraction initiale par date et par filtres métier valides, récupérez uniquement les champs nécessaires, paginez les objets volumineux et évitez de relier à répétition des jeux de données historiques complets. Lorsque cela est possible, extrayez progressivement les données de relation et d’audit.
Qualité des données : exigez des valeurs non vides pour PurchaseRequisitionId, ActivityName, EventTime, SourceSystem et LastDataUpdate. Conservez les identifiants sources à des fins de diagnostic et de déduplication lorsque le connecteur les expose.
Variabilité de la configuration : les noms d’objets et de champs, les valeurs de statut, les représentations d’audit et les données de relation disponibles varient selon l’environnement Coupa et le connecteur. Utilisez [Configure based on your system] lorsque le connecteur ne propose pas d’équivalent documenté.

a Exemple de requête config

WITH
requisition_created AS (
    SELECT
        CAST(r.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Created' AS ActivityName,
        CAST(r.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(r.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your requisition header object] r
    WHERE r.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND r.created_at < CAST('[Your end date]' AS TIMESTAMP)
      AND [Your company filter]
),
requisition_submitted AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Submitted' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.previous_status AS VARCHAR(255))) = 'draft'
      AND LOWER(CAST(h.new_status AS VARCHAR(255))) = 'pending_approval'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_amended AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Amended' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('amended', 'updated', 'version_created')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_started AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Started' AS ActivityName,
        CAST(a.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.status AS VARCHAR(255))) = 'pending'
      AND a.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_approved AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Approved' AS ActivityName,
        CAST(a.action_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.action AS VARCHAR(255))) = 'approved'
      AND a.action_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.action_time < CAST('[Your end date]' AS TIMESTAMP)
),
approval_step_rejected AS (
    SELECT
        CAST(a.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Approval Step Rejected' AS ActivityName,
        CAST(a.action_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(a.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(a.approver AS VARCHAR(255)) AS Approver
    FROM [Your approval object] a
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(a.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(a.action AS VARCHAR(255))) = 'rejected'
      AND a.action_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND a.action_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_withdrawn AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Withdrawn' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('withdrawn', 'withdrawal', 'cancelled_before_approval')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_approved AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Approved' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.new_status AS VARCHAR(255))) = 'approved'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_rejected AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Rejected' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.new_status AS VARCHAR(255))) = 'rejected'
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_sourced AS (
    SELECT
        CAST(s.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Sourced' AS ActivityName,
        CAST(s.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(s.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your sourcing relationship object] s
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(s.requisition_id AS VARCHAR(255))
    WHERE s.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND s.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
purchase_order_created AS (
    SELECT
        CAST(p.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Purchase Order Created' AS ActivityName,
        CAST(p.created_at AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(p.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(NULL AS VARCHAR(255)) AS Approver
    FROM [Your purchase order relationship object] p
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(p.requisition_id AS VARCHAR(255))
    WHERE p.created_at >= CAST('[Your start date]' AS TIMESTAMP)
      AND p.created_at < CAST('[Your end date]' AS TIMESTAMP)
),
requisition_closed AS (
    SELECT
        CAST(h.requisition_id AS VARCHAR(255)) AS PurchaseRequisitionId,
        'Requisition Closed' AS ActivityName,
        CAST(h.event_time AS TIMESTAMP) AS EventTime,
        'Coupa' AS SourceSystem,
        CAST(h.last_data_update AS TIMESTAMP) AS LastDataUpdate,
        CAST(r.status AS VARCHAR(255)) AS RequisitionStatus,
        CAST(r.requester AS VARCHAR(255)) AS Requester,
        CAST(r.department AS VARCHAR(255)) AS Department,
        CAST(r.total_amount AS DECIMAL(38, 10)) AS TotalAmount,
        CAST(h.user_name AS VARCHAR(255)) AS Approver
    FROM [Your requisition history or audit object] h
    LEFT JOIN [Your requisition header object] r ON CAST(r.requisition_id AS VARCHAR(255)) = CAST(h.requisition_id AS VARCHAR(255))
    WHERE LOWER(CAST(h.event_type AS VARCHAR(255))) IN ('closed', 'closure', 'cancelled_after_approval')
      AND h.event_time >= CAST('[Your start date]' AS TIMESTAMP)
      AND h.event_time < CAST('[Your end date]' AS TIMESTAMP)
)
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_created
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_submitted
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_amended
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_started
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_approved
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM approval_step_rejected
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_withdrawn
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_approved
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_rejected
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_sourced
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM purchase_order_created
UNION ALL
SELECT PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate, RequisitionStatus, Requester, Department, TotalAmount, Approver FROM requisition_closed
ORDER BY PurchaseRequisitionId, EventTime, ActivityName;

Prêt à commencer ?

Commencez dès aujourd’hui à optimiser votre processus Coupa Purchase to Pay, demande d’achat grâce à ce template. Obtenez des analyses utiles et améliorez l’efficacité de vos achats.

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

Optimisez vos demandes Coupa P2P et réduisez dès aujourd’hui les délais de cycle

Repérez les inefficacités et réduisez de 30 % le délai de cycle de vos demandes P2P.

Démarrer l’essai gratuit

Aucune carte bancaire requise. Optimisez vos processus en quelques minutes.

Votre template de données Purchase to Pay, demande d’achat

Votre template de données Purchase to Pay, demande d’achat

Purchase to Pay - Requisition : attributs

Purchase to Pay - Requisition : activités

Guides d’extraction

Rapports planifiés Coupa pour l’export des données de demandes

Étapes

Configuration

a Exemple de requête config

Extraction par script Python via l’API REST Coupa

Étapes

Configuration

a Exemple de requête python

Extraction à l’aide d’un connecteur iPaaS tiers

Étapes

Configuration

a Exemple de requête config

Prêt à commencer ?

Optimisez vos demandes Coupa P2P et réduisez dès aujourd’hui les délais de cycle

Votre template de données Purchase to Pay, demande d’achat

Votre template de données Purchase to Pay, demande d’achat

Purchase to Pay - Requisition : attributs

Purchase to Pay - Requisition : activités

Guides d’extraction

Rapports planifiés Coupa pour l’export des données de demandes

Étapes

Configuration

a Exemple de requête config

Extraction par script Python via l’API REST Coupa

Étapes

Configuration

a Exemple de requête python

Extraction à l’aide d’un connecteur iPaaS tiers

Étapes

Configuration

a Exemple de requête config

Prêt à commencer ?

Optimisez vos demandes Coupa P2P et réduisez dès aujourd’hui les délais de cycle

Nous attachons de l’importance à votre confidentialité

Purchase to Pay - Requisition : attributs

Purchase to Pay - Requisition : activités