> Amélioration continue des processus > Purchase to Pay Demande d’achat > Coupa > Modèle de données

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

Coupa

Attributs Purchase to Pay - Demande d’achat(21) Activités Purchase to Pay - Demande d’achat(12) Guides d’extraction(3)

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

Ce modèle de données complet propose une méthode structurée pour recueillir les informations nécessaires à l’analyse du processus Purchase to Pay - Demande d’achat. Il présente les attributs et les activités essentiels à la création d’un journal d’événements fiable, ainsi que des conseils 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 ? 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 dans votre journal d’événements pour analyser en détail le processus Purchase to Pay - Demande d’achat.

5 Obligatoire 5 Recommandé 11 Facultatif

	Nom	Description
	Heure de l’événement EventTime	Date et heure précises auxquelles l’activité a eu lieu.
Description L’heure de l’événement, ou son horodatage, indique le moment exact où une activité liée à une demande d’achat a été enregistrée. Ces données permettent de remettre les événements dans l’ordre chronologique et de reconstituer le déroulement du processus. Elles servent de base à toutes les analyses temporelles : calcul des temps de cycle, repérage des goulots d’étranglement en mesurant la durée entre les activités et suivi des performances du processus au fil du temps. Des horodatages précis et détaillés sont indispensables à une analyse pertinente. Pourquoi est-ce important ? Cet horodatage permet de remettre les événements dans le bon ordre et de calculer les indicateurs de durée, notamment les temps de cycle et les goulots d’étranglement. Où trouver ces données Ces informations figurent dans la piste d’audit ou l’historique 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 cas 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 à sa création, qu’elle conserve tout au long de son cycle de vie. Il permet de suivre la demande de bout en bout, depuis sa création et sa soumission jusqu’aux étapes d’approbation ou de rejet, puis à son sourcing et à sa clôture. Dans le 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 cas. Pourquoi est-ce important ? Cet identifiant de cas essentiel relie toutes les étapes du processus et permet d’analyser le cycle de vie complet de la demande d’achat, du début à la fin. Où trouver ces données Il s’agit d’un champ de clé primaire du module Requisitions de Coupa et des exportations de données associées. Exemples PR-102934PR-102935PR-102936
	Nom de l’activité ActivityName	Nom de l’activité ou de l’événement métier précis survenu à un moment donné pour la demande d’achat.
Description Cet attribut consigne les différentes étapes du cycle de vie de la demande d’achat. Il peut s’agir, par exemple, de « Demande d’achat créée », « Étape d’approbation approuvée » ou « Demande d’achat transmise au sourcing ». Chaque activité correspond à une étape importante ou à une action effectuée sur la demande. L’analyse de leur séquence et de leur fréquence est fondamentale en Process Mining : elle permet de visualiser les cartes de processus, de repérer les parcours courants et de détecter les écarts par rapport à la procédure standard. Pourquoi est-ce important ? Il définit les étapes de la carte de processus et permet de visualiser et d’analyser le parcours des demandes d’achat. Où trouver ces données Cet attribut provient généralement des journaux d’événements, des enregistrements de changement de statut ou des pistes d’audit du système Coupa. Il peut être nécessaire d’établir une association à partir des champs de statut ou des codes d’action. Exemples Demande d’achat crééeDemande d’achat soumiseÉtape d’approbation approuvéeDemande d’achat rejetéeCommande créée
	Dernière mise à jour des données LastDataUpdate	Horodatage de la dernière actualisation des données depuis le système source.
Description Cet attribut indique la date et l’heure de la dernière extraction des données depuis Coupa. Il permet de savoir si les données analysées sont récentes. Cette information aide les utilisateurs à déterminer si les analyses reflètent la situation opérationnelle actuelle ou un état antérieur. Elle est particulièrement importante pour les Dashboards qui suivent les opérations en cours. Pourquoi est-ce important ? Il renseigne les utilisateurs sur la fraîcheur des données, leur permet de connaître la période couverte par l’analyse et les aide à prendre des décisions à partir d’informations à jour. Où trouver ces données 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	Indique le système source à partir duquel les données ont été extraites.
Description Cet attribut indique le système de référence d’où proviennent les données du processus. Pour cette analyse, sa valeur sera toujours « Coupa ». Il est recommandé d’inclure ce champ, en particulier lorsque les données proviennent de plusieurs systèmes. Il apporte un contexte essentiel sur leur provenance et contribue à la gestion de la gouvernance et de la qualité des données. Pourquoi est-ce important ? Il assure une traçabilité claire des données, essentielle à leur gouvernance et au rapprochement de données provenant de plusieurs systèmes d’entreprise. 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 Coupa
	Approbateur Approver	Utilisateur ou groupe chargé d’une activité d’approbation.
Description Cet attribut identifie la personne ou le groupe d’approbation affecté à une étape. Il est renseigné pour des activités telles que « Étape d’approbation lancée », « Étape d’approbation approuvée » et « Étape d’approbation rejetée ». L’analyse par approbateur est essentielle pour créer le Dashboard « Performances et charge des approbateurs ». Elle permet de mesurer les temps d’approbation individuels, de repérer les goulots d’étranglement liés à certains approbateurs et d’évaluer la répartition de la charge de travail. Pourquoi est-ce important ? Cet attribut est essentiel pour analyser les performances des approbateurs, équilibrer la charge de travail et repérer les goulots d’étranglement liés à certaines personnes ou à certains groupes d’approbation. Où trouver ces données Ces informations figurent dans les détails de la chaîne d’approbation associée à chaque demande d’achat dans Coupa. Il peut être nécessaire de les joindre aux données User. Exemples David MillerApprobateurs des finances, 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 de repérer des tendances propres à certains utilisateurs, comme des modifications fréquentes ou un taux élevé de rejets, qui peuvent indiquer un besoin de formation complémentaire. Elle permet également d’étudier le volume des demandes et le déroulement du processus selon les utilisateurs ou les groupes d’utilisateurs. Pourquoi est-ce important ? Il permet d’analyser le déroulement du processus par utilisateur, de repérer les besoins de formation et de comprendre comment chacun interagit avec le processus. Où trouver ces données Il s’agit d’un champ standard de l’objet Requisition dans Coupa, souvent associé à l’objet User et nommé « requester » ou « created_by ». Exemples Alice JohnsonBob SmithCharlie Brown
	Montant total TotalAmount	Valeur monétaire totale de la demande d’achat.
Description Cet attribut représente le coût total des biens et services demandés. Le montant est un facteur important dans l’analyse du processus, car il influe souvent sur 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 tranche de montant, par exemple moins de 1 000 $ ou de 1 000 $ à 10 000 $, permet de voir comment le processus traite les demandes selon leur importance financière. Pourquoi est-ce important ? Il permet d’analyser les différences de traitement selon le montant des demandes, les montants élevés entraînant souvent des flux de travail d’approbation plus complexes. Où trouver ces données 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
	Service Department	Service ou centre de coûts auquel la demande d’achat est imputée.
Description L’attribut Service associe chaque demande d’achat à une unité organisationnelle ou à un centre de coûts. Il constitue un critère important pour les analyses comparatives. Il permet de filtrer et de segmenter les Dashboards et les indicateurs clés de performance par service, afin que les responsables puissent comparer les temps de cycle d’approbation, les taux de rejet et le respect des règles dans les différentes entités de l’organisation. Ces comparaisons aident à repérer les problèmes propres à un service et les bonnes pratiques. Pourquoi est-ce important ? Il permet de comparer les indicateurs clés de performance du processus, comme le temps de cycle et le taux de rejet, entre les différentes unités opérationnelles et de repérer les points à améliorer. Où trouver ces données Il s’agit d’un champ standard de l’objet Requisition dans Coupa, souvent associé au profil utilisateur du demandeur ou renseigné sur les lignes de la demande. Exemples MarketingOpérations informatiquesServices générauxRecherche et développement
	Statut de la demande d’achat RequisitionStatus	Statut actuel ou final de la demande d’achat.
Description Cet attribut indique l’état général de la demande d’achat au moment de l’extraction des données ou son résultat final. Les statuts courants comprennent « En attente d’approbation », « Approuvée », « Rejetée », « Retirée » et « Clôturée ». Il s’agit d’un critère essentiel pour filtrer et analyser les demandes. Il sert à calculer les taux d’approbation et de rejet, à suivre la charge de travail liée aux demandes ouvertes et à comprendre l’issue des demandes. Pourquoi est-ce important ? Cet attribut permet de comprendre l’issue des demandes d’achat, de calculer les taux d’approbation et de rejet et de suivre l’état des demandes en cours. Où trouver ces données 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 qui prend la valeur vraie si la demande d’achat a été modifiée au moins une fois après sa soumission initiale.
Description Cet attribut calculé est un indicateur simple (vrai/faux) qui précise si l’activité « Demande d’achat modifiée » a eu lieu pour un cas donné. Il facilite l’analyse et le filtrage en permettant d’isoler les demandes qui ont nécessité des modifications. Il sert à calculer le taux de modification des demandes d’achat et à alimenter le Dashboard « Volume de modifications des demandes d’achat », afin de repérer les causes profondes des reprises et d’améliorer la qualité dès la première soumission. Pourquoi est-ce important ? Il simplifie le calcul du taux de modification et permet de distinguer facilement les cas qui ont nécessité des reprises des autres. Où trouver ces données Cet attribut est calculé dans l’outil de Process Mining en vérifiant si l’activité « Demande d’achat modifiée » figure dans le journal d’événements de chaque cas. Exemples truefalse
	Catégorie de produits ou services Commodity	Catégorie générale des biens ou services demandés.
Description L’attribut Catégorie de produits ou services 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 achetés. Certaines catégories peuvent nécessiter des approbations ou des stratégies de sourcing spécifiques. L’analyse du processus par catégorie aide à optimiser les achats selon les types de dépenses. Pourquoi est-ce important ? Il aide à analyser les catégories de dépenses et à déterminer si le déroulement du processus, notamment les temps d’approbation, varie selon le type de biens ou de services achetés. Où trouver ces données Il s’agit d’un champ standard de Coupa, généralement disponible au niveau des lignes 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 marketingVoyages
	Devise Currency	Code de la devise dans laquelle est exprimé le montant total de la demande d’achat.
Description Cet attribut indique la devise, par exemple USD, EUR ou GBP, dans laquelle est exprimé le montant total de la demande d’achat. Ce contexte est 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 de les convertir et de les agréger correctement dans les rapports financiers et les Dashboards. Pourquoi est-ce important ? Il apporte le contexte nécessaire à l’attribut « Montant total » et garantit la précision des analyses financières dans les environnements multidevises. Où trouver ces données Il s’agit d’un champ standard de l’objet Requisition dans Coupa, généralement nommé « currency_code » ou équivalent. Exemples USDEURGBP
	Durée de l’étape d’approbation ApprovalStepDuration	Temps d’attente d’une demande d’achat à une étape d’approbation donnée.
Description Cet indicateur calculé mesure le temps écoulé entre l’activité « Étape d’approbation lancée » et l’activité correspondante « Étape d’approbation approuvée » ou « Étape d’approbation rejetée ». Il isole le temps d’attente à chaque étape de la chaîne d’approbation. Il est essentiel au Dashboard « Goulots d’étranglement des étapes d’approbation critiques », car il indique précisément quels approbateurs ou quelles étapes entraînent les retards les plus importants dans le processus. Pourquoi est-ce important ? Repère les goulots d’étranglement dans le flux d’approbation en mesurant le temps d’attente à chaque étape, plutôt que le seul temps de cycle total. Où trouver ces données Dans l’outil de Process Mining, le calcul consiste à mesurer le temps écoulé entre « Approval Step Started » et l’événement final d’approbation suivant (« Approved » ou « Rejected »). Exemples 1,2 jour4 heures3,8 jours
	Identifiant de la commande PurchaseOrderId	Identifiant de la commande créée à partir de la demande d’achat approuvée.
Description Une fois la demande d’achat entièrement approuvée et transmise au sourcing, une commande est généralement créée. Cet attribut enregistre l’identifiant de la commande correspondante. Il relie le processus de demande d’achat en amont au processus de commande en aval. Il permet de calculer l’indicateur clé de performance « Temps entre l’approbation de la demande d’achat et la création de la commande » et d’analyser plus largement l’ensemble du cycle Purchase-to-Pay, de bout en bout. Pourquoi est-ce important ? Il relie la demande d’achat à la commande qui en découle, ce qui permet d’analyser le délai de transfert et d’étudier l’ensemble du cycle P2P. Où trouver ces données Il s’agit d’un champ standard de l’objet Requisition dans Coupa, renseigné après la création de la commande. Exemples PO-45000123PO-45000124PO-45000125
	Motif du rejet RejectionReason	Motif indiqué 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. L’analyse des motifs de rejet apporte un retour qualitatif direct sur les raisons de l’échec des demandes. Elle est précieuse pour rechercher les causes profondes, comme une imputation incorrecte, un budget insuffisant ou une justification incomplète, puis y remédier par la formation ou l’amélioration du processus. Pourquoi est-ce important ? Il renseigne directement sur les causes profondes des échecs du processus et aide à repérer les besoins de formation des utilisateurs ou les points à clarifier dans le processus. Où trouver ces données Ces informations figurent généralement dans le champ des commentaires ou des notes associé à un changement de statut vers « Rejetée » dans l’historique d’approbation de la demande d’achat. Exemples Centre de coûts incorrectDépassement du budget pour ce trimestreDemande en doubleJustification insuffisante
	Niveau d’urgence UrgencyLevel	Classification indiquant le degré d’urgence de la demande d’achat, par exemple « Élevé », « Moyen » ou « Faible ».
Description Le niveau d’urgence, souvent associé à un champ de priorité, permet aux demandeurs de signaler les demandes à traiter plus rapidement. Cet attribut est essentiel au Dashboard « Temps de traitement des demandes d’achat urgentes ». En comparant les temps de cycle des demandes urgentes à ceux des demandes standard, les organisations peuvent évaluer l’efficacité de leurs mécanismes de priorisation et vérifier si les besoins urgents sont satisfaits dans les délais. Pourquoi est-ce important ? Il permet de vérifier si les demandes urgentes sont traitées plus rapidement que les demandes standard et d’évaluer l’efficacité des règles de priorisation. Où trouver ces données 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éMoyenFaible
	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 demandeur peut le préciser, ou il peut être ajouté ultérieurement lors du processus de sourcing. L’analyse des indicateurs du processus par fournisseur aide à évaluer les performances des fournisseurs et à repérer ceux avec lesquels les échanges entraînent des temps de cycle plus longs ou d’autres inefficacités. Elle apporte un contexte utile à la stratégie d’approvisionnement et à la gestion des relations fournisseurs. Pourquoi est-ce important ? Il permet d’analyser les performances du processus selon le fournisseur sélectionné et d’éclairer les stratégies de sourcing et la gestion des fournisseurs. Où trouver ces données 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 suivies par une demande d’achat.
Description Cet attribut calculé compte, pour chaque demande d’achat, le nombre d’activités distinctes « Approval Step Approved ». Il permet d’évaluer la complexité du flux d’approbation de chaque cas. Il sert de base à l’indicateur « Nombre moyen d’étapes d’approbation » et aide à repérer les demandes qui suivent un parcours d’approbation particulièrement long ou complexe, signe qu’une simplification du flux de travail pourrait être nécessaire. Pourquoi est-ce important ? Mesure la complexité du flux d’approbation de chaque demande d’achat et aide à repérer les parcours trop complexes qui gagneraient à être simplifiés. Où trouver ces données Dans l’outil de Process Mining, cette métrique est calculée en comptant les occurrences de « Approval Step Approved » pour chaque ID de cas. 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 d’achat.
Description Cet attribut identifie la séquence d’approbateurs prédéfinie que la demande d’achat est censée suivre. Les règles métier la déterminent généralement en fonction de critères tels que le montant, le service et le type de demande. Cet attribut est au cœur du Dashboard « Conformité aux règles des demandes d’achat ». La comparaison entre la séquence réelle des approbateurs et le parcours de flux de travail prévu permet de détecter les écarts, de mesurer le taux de conformité et de repérer les exceptions non gérées. Pourquoi est-ce important ? Il permet d’analyser la conformité en comparant les étapes d’approbation prévues et celles réellement suivies, afin de repérer les écarts du processus. Où trouver ces données Consultez la documentation Coupa. Cet attribut peut être déduit du nom de la chaîne d’approbation ou de la règle de flux de travail déclenchée pour la demande d’achat. Exemples Approbation standard, moins de 5 000 $Approbation du matériel informatique, plus de 10 000 $Examen par la direction financière des dépenses d’investissement
	Type de demande d’achat RequisitionType	Catégorie ou type de demande d’achat, par exemple « Dépense d’investissement », « Dépense de fonctionnement » ou « Logiciels ».
Description Le type de demande d’achat permet de classer les demandes selon leur objectif métier ou la nature de l’achat. Cet attribut est utile pour l’analyse de la conformité et pour comprendre comment les demandes de différents types 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 de dépenses de fonctionnement courantes. L’analyse du processus par type de demande d’achat peut révéler des pistes d’amélioration. Pourquoi est-ce important ? Il permet de segmenter l’analyse selon l’objectif métier de la demande, car les différents types peuvent suivre des parcours et des règles distincts. Où trouver ces données Il s’agit probablement d’un champ de classification standard ou personnalisé de l’objet Requisition dans Coupa. Exemples Dépense d’investissementDépense de fonctionnementMatériel informatiqueServices professionnels

Obligatoire Recommandé Facultatif

Activités Purchase to Pay - Demande d’achat

Voici les principales étapes et les jalons à consigner dans votre journal d’événements pour découvrir avec précision le flux de travail Purchase to Pay - Demande d’achat.

6 Recommandé 6 Facultatif

	Activité	Description
	Commande créée	Une commande est créée à partir des informations de la demande d’achat approuvée. Cet événement est déduit de la création d’un enregistrement de commande faisant référence à l’identifiant de la demande d’origine.
Pourquoi est-ce important ? Il s’agit du principal résultat attendu du processus de demande d’achat et du passage à l’étape suivante du cycle Purchase-to-Pay. L’analyse du temps écoulé entre « Demande d’achat approuvée » et cet événement permet de repérer les retards d’exécution. Où trouver ces données Cette activité est déduite de la création d’un enregistrement dans la table « purchase_orders », qui contient une référence à l’identifiant d’origine de « requisition_headers » ou de « requisition_lines ». Données à recueillir Utilisez l’horodatage « created-at » de l’enregistrement de commande associé à l’identifiant de la demande d’achat. Type d’événement inferred
	Demande d’achat approuvée	La demande d’achat a franchi avec succès toutes les étapes requises du flux de travail d’approbation. Cette activité est déduite du passage du statut général de l’en-tête de la demande à « approved ».
Pourquoi est-ce important ? Cette étape marque une réussite importante et la fin du cycle d’approbation. Le temps nécessaire pour l’atteindre est un indicateur clé de performance. Elle déclenche également les étapes suivantes du processus d’approvisionnement. Où trouver ces données Cette activité est déduite du changement de statut dans la table « requisition_headers », lorsque le champ « status » prend la valeur « approved ». L’horodatage figure dans la piste d’audit associée. Données à recueillir Repérez l’horodatage auquel le statut général 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 : aucune autre action ne sera entreprise. Cela peut se produire après la création et l’exécution d’une commande, ou si la demande est annulée après approbation, mais avant la commande.
Pourquoi est-ce important ? Cette activité marque la fin définitive du cycle de vie de la demande d’achat. Elle garantit que chaque cas se termine clairement et évite que des demandes apparaissent indéfiniment comme « actives » dans l’analyse du processus. Où trouver ces données Cette activité est déduite du changement de statut dans la table « requisition_headers », lorsque le champ « status » prend la valeur « closed ». L’horodatage figure dans la piste d’audit associée. Données à recueillir Repérez l’horodatage auquel le statut général 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. C’est le 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 correspondant.
Pourquoi est-ce important ? Cette activité marque le début du cycle de vie de la demande d’achat. L’analyse du délai entre sa création et sa soumission peut révéler des retards dus aux hésitations de l’utilisateur ou à la complexité du système. Où trouver ces données Cet événement est extrait de l’horodatage « created-at » de la table « requisition_headers » pour un identifiant de demande d’achat donné. Données à recueillir 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 commande. Cette activité est déduite du passage du statut général de l’en-tête de la demande à « rejected ».
Pourquoi est-ce important ? Cette activité marque l’échec définitif du processus. L’analyse de ces événements est essentielle pour réduire le taux de rejet des demandes d’achat et repérer les causes profondes, comme le non-respect des règles ou les problèmes de budget. Où trouver ces données Cette activité est déduite du changement de statut dans la table « requisition_headers », lorsque le champ « status » prend la valeur « rejected ». L’horodatage figure dans la piste d’audit associée. Données à recueillir Repérez l’horodatage auquel le statut général de la demande d’achat passe à « rejected ». Type d’événement inferred
	Demande d’achat soumise	Le demandeur soumet officiellement la demande d’achat remplie pour approbation. Cet événement est déduit du changement d’état de la demande dans les journaux d’audit ou les tables d’historique du système, de « draft » à « pending_approval ».
Pourquoi est-ce important ? La soumission déclenche le processus d’approbation. Elle constitue donc une étape clé pour mesurer le KPI « Temps de cycle moyen d’approbation des demandes d’achat ». Les retards antérieurs sont liés à l’utilisateur, tandis que ceux qui surviennent ensuite relèvent du processus. Où trouver ces données Cet événement est déduit d’un changement d’état dans la table « requisition_headers », lorsque le champ « status » prend la valeur « pending_approval ». L’horodatage de ce changement figure dans la piste d’audit associée. Données à recueillir Repérez l’horodatage du premier passage de l’état de la demande d’achat à « pending_approval ». Type d’événement inferred
	Demande d’achat modifiée	Après la soumission de la demande d’achat, le demandeur ou un autre utilisateur autorisé la modifie. Coupa enregistre explicitement cette modification sous la forme d’une nouvelle version ou d’une entrée d’audit, ce qui réinitialise souvent une partie ou la totalité du circuit d’approbation.
Pourquoi est-ce important ? Le suivi des modifications est essentiel pour comprendre les reprises et les inefficacités du processus. Un nombre élevé de modifications peut révéler des exigences initiales peu claires ou des politiques d’achat complexes, et influer sur le KPI « Taux de modification des demandes d’achat ». Où trouver ces données Cet événement est extrait des tables de piste d’audit associées à la table « requisition_headers », qui enregistrent les changements de version ou les actions explicites de type « edit ». Données à recueillir Recherchez dans l’historique de la demande d’achat les événements explicites « edit » ou « update » survenus après sa soumission. Type d’événement explicit
	Demande d’achat retirée	Le demandeur initial annule la demande d’achat avant son approbation définitive. Cette action explicite, effectuée par l’utilisateur, met fin au processus pour cette demande.
Pourquoi est-ce important ? Un retrait peut signaler une évolution des besoins, une demande en double ou une tentative de contourner le processus. Le suivi de ces retraits permet de comprendre les variations de la demande et de repérer d’éventuels problèmes de respect du processus. Où trouver ces données Cette activité est déduite du passage du statut de la table « requisition_headers » à « withdrawn » ou à un état similaire, à la suite d’une action explicite de l’utilisateur consignée dans la piste d’audit. Données à recueillir Repérez l’horodatage auquel le statut de la demande d’achat passe à « withdrawn ». Type d’événement inferred
	Demande d’achat transmise au sourcing	La demande d’achat approuvée est intégrée à un processus de sourcing, par exemple un appel d’offres ou une enchère, au lieu d’être immédiatement convertie en commande. Cet événement est déduit de l’association entre la demande d’achat et un objet de sourcing.
Pourquoi est-ce important ? Cette activité met en évidence une autre voie importante du processus d’approvisionnement. Elle distingue les achats simples des opérations de sourcing plus complexes et stratégiques, ce qui permet d’analyser les temps de cycle avec davantage de précision. Où trouver ces données Cette activité est déduite du passage du statut à « sourcing » ou de la création d’un lien entre la table « requisition_lines » et une table d’événements de sourcing. Données à recueillir Vérifiez si le statut passe à « sourcing » ou si un lien vers un identifiant d’événement de sourcing est créé. Type d’événement inferred
	Étape d’approbation approuvée	Un approbateur donne son accord à la demande d’achat. Cette action explicite est enregistrée par le système avec un horodatage précis et les informations sur l’utilisateur.
Pourquoi est-ce important ? Cette activité permet d’examiner en détail le déroulement du processus d’approbation. Le regroupement de ces étapes permet de calculer le « temps d’attente moyen par étape d’approbation » et d’analyser les performances des approbateurs. Où trouver ces données Cette activité est identifié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. Données à recueillir Filtrez les événements « approve » dans l’historique d’approbation de la demande d’achat. Type d’événement explicit
	Étape d’approbation commencé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 de la création d’un enregistrement d’approbation associé à la demande et portant l’état « pending ».
Pourquoi est-ce important ? Cette étape marque le début du temps d’attente pour une approbation donnée. Mesurer le délai entre celle-ci et l’étape correspondante « Étape d’approbation approuvée/rejetée » permet de repérer les goulots d’étranglement dans le circuit d’approbation. Où trouver ces données Cet événement est déduit de l’horodatage de création d’un enregistrement dans la table « approvals » associé à la demande d’achat, lorsque l’état de l’action de l’approbateur est « pending » ou équivalent. Données à recueillir Utilisez l’horodatage de création de l’enregistrement d’approbation en attente d’un approbateur dans le circuit d’approbation. Type d’événement inferred
	Étape d’approbation rejetée	À son étape du flux de travail, un approbateur rejette la demande d’achat, généralement en la renvoyant au demandeur pour modification. Coupa enregistre explicitement cette action.
Pourquoi est-ce important ? Un rejet à n’importe quelle étape entraîne des reprises et allonge les temps de cycle. Analyser où et pourquoi les rejets surviennent est essentiel pour améliorer le processus et former les utilisateurs. Où trouver ces données Cette activité est identifié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. Données à recueillir Filtrez 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 extraire vos données de Coupa

Étapes

Connectez-vous à Coupa : accédez à votre instance Coupa avec un compte utilisateur autorisé à créer et à planifier des rapports.
Ouvrez le module de rapports : accédez à l’onglet « Configuration », puis à la section « Rapports ». Sélectionnez « Rapports » pour ouvrir le tableau de bord des rapports.
Créez un rapport personnalisé : cliquez sur « Créer » pour commencer à élaborer un rapport, puis sélectionnez « Rapport personnalisé » comme type.
Définissez les sources de données du rapport : dans le générateur de rapports, sélectionnez et reliez plusieurs sources de données afin de réunir toutes les informations nécessaires. Commencez par « En-têtes des demandes d’achat » comme source principale, puis ajoutez les objets associés suivants :
- « Approbations » : pour obtenir les détails de chaque étape d’approbation, notamment l’approbateur, l’état et les horodatages.
- « Lignes des demandes d’achat » : pour calculer les montants totaux et obtenir les détails de chaque article.
- « En-têtes des bons de commande » : pour repérer la conversion d’une demande d’achat en bon de commande.
- « Utilisateurs » : 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 particulièrement importante, car ces colonnes serviront à créer le journal d’événements. Incluez au minimum les champs suivants :
- Dans les en-têtes des demandes d’achat : Requisition #, Created At, Submitted At, Updated At, État, Created by (Login ID), Total, Sourced Externally?
- Dans les utilisateurs (pour le demandeur) : Nom complet, Department Name.
- Dans les approbations : Created At, Updated At, État, Approver (Login ID).
- Dans les en-têtes des bons de commande : PO Number, Created At.
Définissez les filtres du rapport : appliquez des filtres pour délimiter les données extraites. Un filtre courant et efficace porte sur « En-têtes des demandes d’achat - Created At » et utilise une période dynamique, par exemple « 90 derniers jours ». Vous pouvez également filtrer par code société, le cas échéant.
Planifiez le rapport : dans le générateur de rapports, ouvrez l’onglet « Planification ». Définissez la fréquence d’exécution, par exemple quotidienne ou hebdomadaire, et choisissez une heure où l’activité est faible.
Configurez la livraison : choisissez le mode de livraison. Pour automatiser l’opération, sélectionnez « SFTP », puis indiquez les identifiants du serveur et le répertoire de destination. Vous pouvez aussi envoyer le rapport à une adresse e-mail. Choisissez le format de fichier « CSV ».
Enregistrez et activez le rapport : enregistrez le rapport et vérifiez que sa planification est activée. Le premier rapport sera généré à la prochaine heure 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 le traiter à l’aide d’un script externe, par exemple en Python, ou d’un outil ETL. Le script doit réorganiser les données pour créer une ligne distincte par activité : par exemple, une ligne « Demande d’achat créée » à partir de la colonne Created At, une ligne pour chaque étape d’approbation à partir des colonnes « Approbations » et une ligne « Bon de commande créé » à partir de 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 et les autres attributs recommandés. Ce fichier est alors prêt à être importé.

Configuration

Sources de données principales : le rapport doit relier plusieurs objets Coupa. Les principales sources sont « En-têtes des demandes d’achat », « Approbations », « Lignes des demandes d’achat » et « En-têtes des bons de commande ».
Filtrage par période : appliquez un filtre de date pour limiter le volume de données. Pour commencer, il est recommandé d’utiliser une période glissante de 3 à 6 mois, basée sur « En-têtes des demandes d’achat - Created At ».
Chargements incrémentiels : pour assurer le suivi dans la durée, planifiez une exécution quotidienne du rapport et extrayez les données de la veille, par exemple avec le filtre « Hier », afin d’effectuer des chargements incrémentiels.
Configuration de la livraison : configurez l’envoi vers un serveur SFTP pour automatiser l’intégration à 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 création de rapports pour créer et planifier le rapport, et accéder à tous les objets de données nécessaires (demandes d’achat, bons de commande, approbations et utilisateurs).

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 à Configuration > Configuration de l’entreprise > Clés API. Créez une clé API disposant au minimum des 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 fichier Python, par exemple extract_coupa_reqs.py, puis copiez-y le script fourni. Remplacez la valeur fictive de COUPA_INSTANCE_URL par l’URL Coupa de votre entreprise, par exemple https://yourcompany.coupahost.com, et celle de API_KEY par la clé obtenue à l’étape précédente.
Définissez les paramètres d’extraction : dans la section main du script, modifiez les variables START_DATE et END_DATE pour définir la période d’extraction des données. Le filtre s’applique à la date de création des demandes d’achat.
Exécutez le script : lancez-le depuis votre terminal avec la commande python extract_coupa_reqs.py. Le script se connecte à l’API Coupa, récupère les données et affiche l’avancement dans la console.
Gérez la pagination de l’API : le script comprend une fonction qui gère automatiquement la pagination de l’API. Il récupère les données par lots de 50 enregistrements et poursuit jusqu’à avoir extrait toutes les demandes d’achat de la période définie.
Traitez les données des demandes d’achat : pour chaque en-tête récupéré, le script génère les événements « Demande d’achat créée » et « Demande d’achat soumise ». Il effectue ensuite des appels supplémentaires à l’API pour récupérer les données associées aux approbations et aux bons de commande.
Générez les événements d’activité : le script traite les enregistrements d’approbation pour créer les événements « Étape d’approbation commencée », « Étape d’approbation approuvée » et « Étape d’approbation rejetée ». Il vérifie également l’état final de la demande d’achat et les données associées afin de générer des événements tels que « Demande d’achat approuvée », « Bon de commande créé » et « Demande d’achat retirée ».
Repérez les modifications : le script vérifie l’attribut version de chaque demande d’achat. Si sa valeur est supérieure à 1, cela indique une modification. Un événement « Demande d’achat modifiée » est créé à partir de l’horodatage updated-at de la version la plus récente.
Assemblez le journal d’événements : tous les événements générés sont regroupés dans une liste structurée. Chaque événement comprend les attributs requis, comme PurchaseRequisitionId, ActivityName et EventTime, ainsi que des attributs recommandés, comme Requester et TotalAmount.
Exportez les données au format CSV : une fois le traitement de toutes les demandes d’achat terminé, le script convertit la liste finale des é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 filtre les données selon la date de création des demandes d’achat (created-at). Il est recommandé de procéder par périodes raisonnables, par exemple de 3 à 6 mois, afin d’éviter les exécutions trop longues et les délais d’attente de l’API. Modifiez les variables START_DATE et END_DATE en conséquence.
Filtrage par état : le script fourni récupère toutes les demandes d’achat, quel que soit leur état. Pour cibler certains états, vous pouvez ajouter un paramètre status au dictionnaire params du premier appel API, par exemple approved, pending_approval ou ordered.
Limite de pagination : le script est configuré pour récupérer 50 enregistrements par appel API (limit=50). Cette valeur standard convient généralement à l’API Coupa. L’augmenter n’améliorera pas nécessairement les performances et pourrait accroître le risque de dépassement du délai d’attente pour les requêtes complexes.
Performances : le script effectue plusieurs appels API pour chaque demande d’achat : un pour l’en-tête, un pour les approbations et un pour les bons de commande. 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.

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 tierce choisie propose un connecteur Coupa validé, donnant accès aux en-têtes des demandes d’achat, à leur historique ou aux données d’audit, aux enregistrements d’approbation, aux liens avec les opérations d’approvisionnement et les bons de commande, ainsi qu’aux informations de clôture. Les noms des connecteurs et des objets, ainsi que les champs disponibles, varient selon le fournisseur. Configurez-les en fonction de la documentation du connecteur et de votre environnement Coupa.
Créez une connexion au connecteur depuis l’interface de la plateforme. Indiquez l’URL de votre environnement Coupa, la méthode d’authentification, les identifiants, les paramètres OAuth et les périmètres requis. Tant que la connexion n’est pas configurée dans l’environnement cible, utilisez des valeurs fictives telles que [Your Coupa tenant URL] et [Your connector credentials].
Définissez le périmètre d’extraction. Commencez par une période glissante de trois à six mois, puis élargissez-la après rapprochement des données. Appliquez uniquement des filtres valides pour votre environnement, tels que [Your company filter] ou [Your document type filter]. N’excluez pas les demandes d’achat au seul motif que leur état actuel est « closed », « rejected », « withdrawn » ou « approved », car ces cas sont nécessaires à l’analyse du cycle de vie.
Associez les objets sources dans le connecteur. Sélectionnez l’objet d’en-tête des demandes d’achat, l’objet d’historique ou d’audit des demandes, l’objet d’approbation, l’objet de relation avec l’approvisionnement, l’objet de relation avec les bons de commande et tout objet d’historique de clôture ou d’état proposé par le connecteur. Si un objet requis n’est pas disponible, utilisez la représentation de l’historique ou de l’audit prise en charge par le connecteur, ou consignez cette limite avant de publier l’extraction.
Configurez les associations entre les cas et les événements. Associez l’identifiant de la demande d’achat à PurchaseRequisitionId, le libellé de l’événement à ActivityName, l’horodatage source à EventTime, la valeur constante Coupa à SourceSystem et l’horodatage d’actualisation du connecteur à LastDataUpdate. Associez également le demandeur, le service, le montant total, l’état 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 « Demande d’achat créée » à partir de l’horodatage de création de la demande, « Demande d’achat soumise » lors du passage de l’état brouillon à pending_approval, « Demande d’achat modifiée » à partir d’une version ou d’une entrée d’audit postérieure à la soumission, « Étape d’approbation commencée » à partir d’un enregistrement d’approbation en attente, « Étape d’approbation approuvée » à partir d’une action d’approbation, « Étape d’approbation rejetée » à partir d’une action de rejet, « Demande d’achat retirée » à partir d’une action explicite de retrait ou d’un changement d’état, « Demande d’achat approuvée » lors du passage de l’en-tête à l’état approuvé, « Demande d’achat rejetée » lors de son passage à l’état rejeté, « Demande d’achat transmise à l’approvisionnement » à partir d’un lien entre la demande et l’approvisionnement, « Bon de commande créé » à partir d’un bon de commande faisant référence à la demande et « Demande d’achat clôturée » à partir d’une action de clôture ou d’un changement d’état.
Normalisez les données extraites avant de réunir les flux d’événements. Convertissez tous les horodatages dans un même fuseau horaire, de préférence UTC, conservez la précision des horodatages sources, convertissez l’identifiant de la demande d’achat dans un type texte uniforme et préservez les valeurs sources des états et des utilisateurs. Supprimez uniquement les doublons strictement identiques sur le plan technique, en comparant l’identifiant de la demande, le nom de l’activité, l’horodatage de l’événement, l’identifiant de l’enregistrement source s’il est disponible et l’approbateur.
Publiez ou planifiez le flux du connecteur. Effectuez d’abord une extraction complète pour la période choisie, puis des actualisations incrémentielles fondées sur l’horodatage de mise à jour de la source ou sur le mécanisme de suivi des modifications pris en charge par le connecteur. Prévoyez une période de reprise afin d’inclure les entrées d’audit tardives et les enregistrements d’approbation modifiés.
Validez le journal d’événements obtenu à l’aide des rapports Coupa ou de l’aperçu du connecteur. Vérifiez que chaque demande d’achat comporte un événement de création, que l’ordre chronologique des changements d’état et des approbations est cohérent et que les événements liés aux relations sont présents lorsqu’il existe des opérations d’approvisionnement ou des bons de commande.
Exportez le résultat final au format CSV plat ou dans un autre format de journal d’événements pris en charge par ProcessMind. Incluez une ligne par événement, utilisez PurchaseRequisitionId comme identifiant de cas, 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 compter sur ProcessMind pour 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 choisie. Les autorisations Coupa, les périmètres API, les modules et les licences du connecteur nécessaires dépendent du fournisseur et de la configuration de votre environnement. Avant la mise en œuvre, vérifiez l’accès aux données des demandes d’achat, de leur historique ou audit, des approbations, de l’approvisionnement, des bons de commande et des clôtures.
Période : commencez par trois à six mois de données. Pour les actualisations planifiées, utilisez une période d’extraction glissante et prévoyez une période de reprise pour récupérer les mises à jour tardives, les actions d’approbation et les demandes d’achat modifiées.
Associations requises : associez l’identifiant de la demande d’achat à 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.
Associations recommandées : associez l’état de la demande d’achat, le demandeur, le service ou le centre de coûts, le montant total et l’approbateur. Lorsque le connecteur prend en charge les instantanés historiques, conservez les valeurs actuelles et celles propres à chaque événement.
Règles d’événement : configurez la création explicite des douze activités requises. ProcessMind lit le journal d’événements tel quel et ne déduit ni ne génère d’événements supplémentaires.
Filtres : appliquez uniquement les filtres pris en charge par le connecteur et valides pour votre environnement, tels que [Your company filter], [Your document type filter], [Your business unit filter] ou [Your requisition date range]. Évitez d’exclure les états terminaux, sauf si l’analyse le nécessite expressément.
Gestion des horodatages : convertissez les horodatages dans un fuseau horaire commun, conservez leur précision d’origine et définissez une règle de tri déterministe pour les événements ayant le même horodatage.
Actualisation incrémentielle : utilisez le champ updated-at ou le mécanisme de suivi des modifications pris en charge par le connecteur. Prévoyez une période de reprise, car l’historique des approbations, les liens avec l’approvisionnement et les bons de commande, ainsi que les informations de clôture peuvent être ajoutés après la création initiale.
Performances : limitez l’extraction initiale par période et à l’aide de filtres métier valides, ne récupérez que les champs nécessaires, paginez les objets volumineux et évitez de relier plusieurs fois l’intégralité des données historiques. Lorsque le connecteur le permet, extrayez progressivement les données de relation et d’audit.
Qualité des données : exigez une valeur non vide pour PurchaseRequisitionId, ActivityName, EventTime, SourceSystem et LastDataUpdate. Conservez les identifiants sources pour faciliter le dépannage et la déduplication, lorsque le connecteur les fournit.
Variabilité de la configuration : les noms d’objets et de champs, les valeurs d’état, 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é.

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 modèle. Repérez les possibilités d’amélioration et gagnez en efficacité dans vos achats.

Retour au guide d’amélioration

Télécharger le modèle

Optimisez les demandes d’achat P2P dans Coupa et réduisez le temps de cycle dès aujourd’hui

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

Démarrez l’essai gratuit

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

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

Rapports planifiés Coupa pour exporter les données des demandes d’achat

Étapes

Configuration

Exemple de requête config

Extraction par script Python via l’API REST de Coupa

Étapes

Configuration

Exemple de requête python

Extraction à l’aide d’un connecteur iPaaS tiers

Étapes

Configuration

Exemple de requête config

Prêt à commencer ?

Optimisez les demandes d’achat P2P dans Coupa et réduisez le temps de cycle dès aujourd’hui

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

Rapports planifiés Coupa pour exporter les données des demandes d’achat

Étapes

Configuration

Exemple de requête config

Extraction par script Python via l’API REST de Coupa

Étapes

Configuration

Exemple de requête python

Extraction à l’aide d’un connecteur iPaaS tiers

Étapes

Configuration

Exemple de requête config

Prêt à commencer ?

Optimisez les demandes d’achat P2P dans Coupa et réduisez le temps de cycle dès aujourd’hui

Prêt à commencer ?