> Kontinuierliche Prozessverbesserung > Purchase to Pay: Bestellanforderung > Coupa > Daten Template

Ihr Daten-Template für Purchase-to-Pay-Bestellanforderungen

Coupa

← Zurück zum Leitfaden zur Prozessverbesserung

Attribute für Purchase-to-Pay-Bestellanforderungen(21) Aktivitäten für Purchase-to-Pay-Bestellanforderungen(12) Anleitungen zur Datenextraktion(3)

Ihr Daten-Template für Purchase-to-Pay-Bestellanforderungen

Dieses umfassende Daten-Template bietet eine strukturierte Grundlage, um die für die Analyse Ihres Purchase-to-Pay-Prozesses für Bestellanforderungen erforderlichen Informationen zu erfassen. Es beschreibt die wesentlichen Attribute und Aktivitäten für ein aussagekräftiges Event Log. Außerdem erfahren Sie, wie Sie diese Daten effizient aus Ihrem Coupa-System extrahieren.

Empfohlene Attribute für eine umfassende Analyse
Wichtige Prozessaktivitäten für die Nachverfolgung
Praktische Anleitung zur Datenextraktion

Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Template herunterladen

Attribute für Purchase-to-Pay-Bestellanforderungen

Dies sind die empfohlenen Datenfelder für Ihr Event Log, damit Sie Ihren Purchase-to-Pay-Prozess für Bestellanforderungen umfassend analysieren können.

5 Erforderlich 5 Empfohlen 11 Optional

	Name	Beschreibung
	Aktivitätsname ActivityName	Der Name der konkreten geschäftlichen Aktivität oder des Ereignisses, das zu einem bestimmten Zeitpunkt für die Anforderung eingetreten ist.
Beschreibung Dieses Attribut erfasst die einzelnen Schritte im Lebenszyklus einer Bestellanforderung. Beispiele sind „Anforderung erstellt“, „Genehmigungsschritt genehmigt“ und „Anforderung an Beschaffung weitergeleitet“. Jede Aktivität steht für einen konkreten Meilenstein oder eine Aktion im Zusammenhang mit der Anforderung. Die Abfolge und Häufigkeit dieser Aktivitäten zu analysieren, ist eine Grundlage des Process Mining. So lassen sich Prozessmodelle visualisieren, häufige Abläufe erkennen und Abweichungen von der Standardvorgehensweise aufdecken. Warum das wichtig ist Das Attribut definiert die Schritte im Prozessmodell und ermöglicht es, den Ablauf der Anforderungen zu visualisieren und zu analysieren. Woher beziehen Dieses Attribut wird in der Regel aus Event Logs, Statusänderungsdatensätzen oder Audit-Trails im Coupa-System abgeleitet. Dazu müssen möglicherweise Statusfelder oder Aktionscodes zugeordnet werden. Beispiele Bestellanforderung erstelltBestellanforderung eingereichtFreigabeschritt genehmigtAnforderung abgelehntBestellung erstellt
	Ereigniszeitpunkt EventTime	Das genaue Datum und die Uhrzeit, zu der die Aktivität stattgefunden hat.
Beschreibung Der Ereigniszeitpunkt, also der Timestamp, gibt den genauen Zeitpunkt an, zu dem eine Aktivität für eine Bestellanforderung erfasst wurde. Diese Daten sind wichtig, um Ereignisse chronologisch zu ordnen und den Prozessablauf abzubilden. Sie bilden die Grundlage für alle zeitbezogenen Analysen, etwa für die Berechnung von Zykluszeiten, das Ermitteln von Engpässen anhand der Dauer zwischen Aktivitäten und die Bewertung der Prozessleistung über verschiedene Zeiträume. Aussagekräftige Prozessanalysen setzen genaue Timestamps mit ausreichender Granularität voraus. Warum das wichtig ist Dieser Timestamp ist entscheidend, um Ereignisse korrekt zu ordnen und alle zeitbezogenen Kennzahlen wie Zykluszeiten und Engpässe zu berechnen. Woher beziehen Diese Informationen werden im Audit-Trail oder in den Verlaufsdatensätzen jeder Anforderung in Coupa erfasst, häufig in einem Feld wie „created_at“ oder „updated_at“ für die jeweilige Aktion. Beispiele 2023-10-26T10:00:00Z2023-10-26T11:35:10Z2023-10-27T14:22:05Z
	ID der Bestellanforderung PurchaseRequisitionId	Der eindeutige Bezeichner jeder Bestellanforderung. Er dient als primäre Case-ID des Prozesses.
Beschreibung Die ID der Bestellanforderung ist der zentrale Schlüssel, der alle Aktivitäten zu einer einzelnen Anfrage für Waren oder Dienstleistungen verknüpft. Bei der Erstellung erhält jede Anforderung eine eindeutige ID, die während des gesamten Lebenszyklus unverändert bleibt. So lässt sich die Anforderung durchgängig verfolgen: von der Erstellung und Einreichung über alle Genehmigungs- oder Ablehnungsschritte bis zur abschließenden Weiterleitung an die Beschaffung und zum Abschluss. Beim Process Mining ist jeder Eintrag im Event Log mit dieser ID verknüpft. Dadurch lässt sich der vollständige Ablauf jedes Case rekonstruieren. Warum das wichtig ist Diese zentrale Case-ID verknüpft alle Prozessschritte und ermöglicht eine vollständige Analyse des Lebenszyklus der Anforderung von Anfang bis Ende. Woher beziehen Dieses Primärschlüsselfeld ist im Requisitions-Modul von Coupa und in zugehörigen Datenexporten enthalten. Beispiele PR-102934PR-102935PR-102936
	Letzte Datenaktualisierung LastDataUpdate	Der Timestamp der letzten Aktualisierung der Daten aus dem Quellsystem.
Beschreibung Dieses Attribut erfasst Datum und Uhrzeit der letzten Datenextraktion aus Coupa. So ist nachvollziehbar, wie aktuell die analysierten Daten sind. Anhand des Aktualisierungszeitpunkts können Benutzer beurteilen, ob die Erkenntnisse den aktuellen Betriebszustand oder einen früheren Zeitpunkt abbilden. Das ist besonders wichtig bei Dashboards zur Überwachung laufender Abläufe. Warum das wichtig ist Informiert Benutzer über die Aktualität der Daten. So können sie den Zeitraum der Analyse einordnen und Entscheidungen auf Grundlage aktueller Informationen treffen. Woher beziehen Dieser Timestamp wird von der Datenpipeline oder dem ETL-Tool nach einer erfolgreichen Datenextraktion generiert und hinzugefügt. Beispiele 2024-05-21T02:00:00Z
	Quellsystem SourceSystem	Gibt an, aus welchem Quellsystem die Daten extrahiert wurden.
Beschreibung Dieses Attribut gibt das führende System an, aus dem die Prozessdaten stammen. Für diese Analyse lautet der Wert immer „Coupa“. Dieses Feld sollte insbesondere dann enthalten sein, wenn Daten aus mehreren Systemen zusammengeführt werden. Es liefert wichtige Informationen zur Datenherkunft und unterstützt die Verwaltung von Data Governance und Qualitätsregeln. Warum das wichtig ist Macht die Datenherkunft nachvollziehbar. Das ist wichtig für die Data Governance und für die Zusammenführung von Daten aus mehreren Unternehmenssystemen. Woher beziehen In der Regel wird während der Datenextraktion und -transformation ein statischer Wert hinzugefügt, der die Herkunft des Datensatzes kennzeichnet. Beispiele Coupa
	Abteilung Department	Die Fachabteilung oder Kostenstelle, der die Anforderung zugeordnet wird.
Beschreibung Das Attribut „Abteilung“ ordnet jede Anforderung einer bestimmten Organisationseinheit oder Kostenstelle zu. Es ist eine wichtige Dimension für Vergleichsanalysen. Dashboards und KPIs lassen sich nach Abteilung filtern und aufschlüsseln. So können Führungskräfte Genehmigungszykluszeiten, Ablehnungsquoten und Compliance in verschiedenen Bereichen der Organisation vergleichen und abteilungsspezifische Probleme oder bewährte Vorgehensweisen erkennen. Warum das wichtig ist Ermöglicht den Vergleich von Prozess-KPIs wie Zykluszeit und Ablehnungsquote zwischen verschiedenen Geschäftseinheiten und zeigt Verbesserungsmöglichkeiten auf. Woher beziehen Dies ist ein Standardfeld des Objekts „Requisition“ in Coupa. Es ist häufig mit dem Benutzerprofil des Anfordernden verknüpft oder wird auf Positionsebene der Anforderung angegeben. Beispiele MarketingIT-BetriebGebäudemanagementForschung und Entwicklung
	Anfordernder Requester	Der Mitarbeitende, der die Bestellanforderung erstellt und eingereicht hat.
Beschreibung Dieses Attribut gibt an, wer die Anfrage gestellt hat. Die Analyse nach Anfordernden macht Muster bei einzelnen Benutzern sichtbar, etwa häufige Änderungen oder Ablehnungen, die auf zusätzlichen Schulungsbedarf hindeuten können. Außerdem lassen sich damit das Anforderungsvolumen und das Prozessverhalten verschiedener Benutzer oder Benutzergruppen untersuchen. Warum das wichtig ist Ermöglicht die Analyse des Prozessverhaltens nach Benutzer. So lassen sich Schulungsbedarfe erkennen und Unterschiede im Umgang mit dem Prozess nachvollziehen. Woher beziehen In Coupa als Standardfeld des Objekts „Requisition“ verfügbar, häufig mit dem Objekt „User“ verknüpft und als „requester“ oder „created_by“ bezeichnet. Beispiele Alice JohnsonBob SmithCharlie Brown
	Genehmigender Approver	Der Benutzer oder die Gruppe, der beziehungsweise die für eine Genehmigungsaktivität verantwortlich ist.
Beschreibung Dieses Attribut gibt die Person oder Genehmigungsgruppe an, der ein Genehmigungsschritt zugewiesen ist. Es wird für Aktivitäten wie „Genehmigungsschritt gestartet“, „Genehmigungsschritt genehmigt“ und „Genehmigungsschritt abgelehnt“ ausgefüllt. Die Analyse nach Genehmigenden ist wichtig für das Dashboard „Leistung und Auslastung der Genehmigenden“. Damit lassen sich individuelle Genehmigungszeiten messen, durch bestimmte Genehmigende verursachte Engpässe erkennen und die Arbeitslastverteilung bewerten. Warum das wichtig ist Wichtig für die Analyse der Leistung und Auslastung der Genehmigenden sowie für das Erkennen von Engpässen, die mit bestimmten Personen oder Genehmigungsgruppen zusammenhängen. Woher beziehen Diese Informationen finden Sie in Coupa in den Details zur Genehmigungskette der jeweiligen Anforderung. Möglicherweise müssen Sie dazu Daten aus dem Objekt „User“ verknüpfen. Beispiele David MillerGenehmigende der Finanzabteilung, Ebene 2Susan Chen
	Gesamtbetrag TotalAmount	Der Gesamtwert der Bestellanforderung.
Beschreibung Dieses Attribut gibt die Gesamtkosten aller in der Anforderung angefragten Waren und Dienstleistungen an. Der Betrag ist für die Prozessanalyse wichtig, da er häufig die Komplexität des Genehmigungs-Workflows beeinflusst. Bei Anforderungen mit höheren Beträgen sind in der Regel mehr Genehmigungsschritte erforderlich. Eine Analyse der Prozesskennzahlen nach Wertbereichen, etwa unter 1.000 $ oder zwischen 1.000 $ und 10.000 $, zeigt, wie der Prozess Anforderungen mit unterschiedlichem finanziellen Umfang behandelt. Warum das wichtig ist Zeigt, wie sich der Prozess bei Anforderungen mit unterschiedlichen Beträgen unterscheidet, da höhere Beträge häufig komplexere Genehmigungs-Workflows auslösen. Woher beziehen Dies ist ein Standardfeld im Kopf des Objekts „Requisition“ in Coupa, das üblicherweise „total“ oder „total_amount“ heißt. Beispiele 500.0012550.7599.99
	Status der Anforderung RequisitionStatus	Der aktuelle oder endgültige Status der Bestellanforderung.
Beschreibung Dieses Attribut gibt den Gesamtstatus der Anforderung zum Zeitpunkt der Datenextraktion oder ihr endgültiges Ergebnis an. Häufige Statuswerte sind „Genehmigung ausstehend“, „Genehmigt“, „Abgelehnt“, „Zurückgezogen“ und „Geschlossen“. Der Status ist eine wichtige Dimension für Filter und Analysen. Er dient dazu, Genehmigungs- und Ablehnungsquoten zu berechnen, die aktuelle Auslastung durch offene Anforderungen zu überwachen und den endgültigen Ausgang von Anfragen nachzuvollziehen. Warum das wichtig ist Wichtig, um die Ergebnisse von Anforderungen zu verstehen, Genehmigungs- und Ablehnungsquoten zu berechnen und den aktuellen Stand laufender Anforderungen zu überwachen. Woher beziehen Dies ist ein Standardfeld des Objekts „Purchase Requisition“ in Coupa, das häufig „status“ oder „state“ heißt. Beispiele Genehmigung ausstehendGenehmigtAbgelehntZurückgezogenGeschlossen
	Ablehnungsgrund RejectionReason	Der Grund, den ein Genehmigender für die Ablehnung einer Anforderung oder eines Genehmigungsschritts angibt.
Beschreibung Wenn ein Genehmigender eine Anforderung ablehnt, gibt er häufig einen Grund für die Entscheidung an. Dieses Attribut erfasst die entsprechende Erläuterung. Die Analyse der Ablehnungsgründe liefert direkte qualitative Hinweise darauf, warum Anforderungen scheitern. Diese Erkenntnisse sind für die Ursachenanalyse wertvoll: Sie helfen, häufige Probleme wie falsche Kontierung, fehlendes Budget oder unzureichende Begründungen zu erkennen und durch Schulungen oder Prozessverbesserungen anzugehen. Warum das wichtig ist Liefert direkte Hinweise auf die Ursachen von Prozessfehlern und hilft, Schulungsbedarf oder Klärungsbedarf bei Prozessen zu erkennen. Woher beziehen Diese Informationen werden üblicherweise im Kommentarfeld oder Notizfeld erfasst, das mit einer Statusänderung zu „Abgelehnt“ in der Genehmigungshistorie der Anforderung verknüpft ist. Beispiele Falsche KostenstelleBudget für dieses Quartal überschrittenDoppelte AnfrageBegründung unzureichend
	Anforderungstyp RequisitionType	Die Kategorie oder Art der Anforderung, zum Beispiel „Investitionsausgabe“, „Betriebsausgabe“ oder „Software“.
Beschreibung Der Anforderungstyp ordnet Anforderungen nach ihrem geschäftlichen Zweck oder der Art des Einkaufs ein. Dieses Attribut ist für Compliance-Analysen und zum Verständnis der Abläufe verschiedener Anfragetypen hilfreich. Anforderungen für Investitionsausgaben können beispielsweise einen strengeren und längeren Genehmigungsweg durchlaufen als reguläre Betriebsausgaben. Die Analyse nach Anforderungstyp kann wertvolle Erkenntnisse für die Prozessoptimierung liefern. Warum das wichtig ist Ermöglicht die Aufschlüsselung der Analyse nach dem geschäftlichen Zweck der Anfrage, da unterschiedliche Typen eigene Prozessabläufe und Richtlinien haben können. Woher beziehen Dies ist wahrscheinlich ein benutzerdefiniertes oder standardmäßiges Klassifizierungsfeld des Objekts „Requisition“ in Coupa. Beispiele InvestitionsausgabeBetriebsausgabeIT-HardwareProfessionelle Dienstleistungen
	Anzahl der Genehmigungsschritte ApprovalStepCount	Gesamtzahl der Genehmigungsschritte, die eine Bestellanforderung durchlaufen hat.
Beschreibung Dieses berechnete Attribut zählt für jede Bestellanforderung die unterschiedlichen Aktivitäten „Genehmigungsschritt genehmigt“. So lässt sich die Komplexität des Genehmigungs-Workflows für jeden Case quantifizieren. Der Wert bildet die Grundlage für die KPI „Durchschnittliche Anzahl der Genehmigungsschritte“ und hilft dabei, Bestellanforderungen mit ungewöhnlich langen oder komplexen Genehmigungswegen zu erkennen. Das kann auf Vereinfachungsbedarf im Workflow hinweisen. Warum das wichtig ist Quantifiziert die Komplexität des Genehmigungs-Workflows für jede Bestellanforderung und hilft dabei, unnötig komplexe Genehmigungswege zu erkennen, die vereinfacht werden sollten. Woher beziehen Diese Kennzahl wird im Process-Mining-Tool berechnet, indem für jede Case-ID gezählt wird, wie oft „Genehmigungsschritt genehmigt“ auftritt. Beispiele 253
	Bestellnummer PurchaseOrderId	Der Bezeichner der Bestellung, die aus der genehmigten Anforderung erstellt wurde.
Beschreibung Sobald eine Anforderung vollständig genehmigt und an die Beschaffung weitergeleitet wurde, wird in der Regel eine Bestellung erstellt. Dieses Attribut speichert die ID der daraus entstandenen Bestellung. Es verknüpft den vorgelagerten Anforderungsprozess mit dem nachgelagerten Bestellprozess. So lässt sich die KPI „Zeit von der Genehmigung der Anforderung bis zur Erstellung der Bestellung“ berechnen und der gesamte Purchase-to-Pay-Zyklus durchgängig analysieren. Warum das wichtig ist Verknüpft die Anforderung mit der nachfolgenden Bestellung. So lässt sich die Dauer der Übergabe analysieren und der gesamte P2P-Prozess durchgängig betrachten. Woher beziehen Dies ist ein Standardfeld des Objekts „Requisition“ in Coupa, das nach der Erstellung der Bestellung ausgefüllt wird. Beispiele PO-45000123PO-45000124PO-45000125
	Dauer des Genehmigungsschritts ApprovalStepDuration	Die Zeit, die eine Anforderung in einem einzelnen Genehmigungsschritt wartet.
Beschreibung Diese berechnete Kennzahl misst die Zeit zwischen der Aktivität „Genehmigungsschritt gestartet“ und der zugehörigen Aktivität „Genehmigungsschritt genehmigt“ oder „Genehmigungsschritt abgelehnt“. Sie erfasst die Wartezeit in jeder einzelnen Phase der Genehmigungskette. Das ist wichtig für das Dashboard „Kritische Engpässe bei Genehmigungsschritten“, denn damit lässt sich genau feststellen, welche Genehmigenden oder Genehmigungsphasen die größten Verzögerungen im Gesamtprozess verursachen. Warum das wichtig ist Ermittelt gezielt Engpässe im Genehmigungs-Workflow, indem die Wartezeit für jeden einzelnen Schritt gemessen wird, statt nur die gesamte Durchlaufzeit zu betrachten. Woher beziehen Wird im Process-Mining-Tool berechnet, indem die Zeit zwischen „Genehmigungsschritt gestartet“ und dem anschließenden abschließenden Genehmigungsereignis (Genehmigt/Abgelehnt) ermittelt wird. Beispiele 1,2 Tage4 Stunden3,8 Tage
	Dringlichkeitsstufe UrgencyLevel	Eine Einstufung der Dringlichkeit einer Anforderung, zum Beispiel „Hoch“, „Mittel“ oder „Niedrig“.
Beschreibung Die Dringlichkeitsstufe ist häufig einem Prioritätsfeld zugeordnet und ermöglicht Anfordernden, Anfragen für eine beschleunigte Bearbeitung zu kennzeichnen. Dieses Attribut ist wichtig für das Dashboard „Bearbeitungszeit dringender Anforderungen“. Durch den Vergleich der Zykluszeiten dringender und regulärer Anforderungen können Organisationen beurteilen, ob ihre Priorisierungsregeln greifen und dringende Geschäftsanforderungen rechtzeitig erfüllt werden. Warum das wichtig ist Ermöglicht die Analyse, ob dringende Anfragen schneller als reguläre bearbeitet werden, und zeigt, wie wirksam die Priorisierungsregeln sind. Woher beziehen Dies kann ein Standardfeld oder ein benutzerdefiniertes Feld des Objekts „Requisition“ in Coupa sein. Prüfen Sie die Coupa-Dokumentation oder die Systemkonfiguration. Beispiele HochMittelNiedrig
	Geändert IsAmended	Ein boolesches Kennzeichen, das den Wert „true“ hat, wenn die Anforderung nach ihrer erstmaligen Einreichung mindestens einmal geändert wurde.
Beschreibung Dieses berechnete Attribut ist ein einfaches Kennzeichen (Wahr/Falsch), das angibt, ob es für einen Case eine Aktivität „Anforderung geändert“ gab. Es erleichtert Analysen und Filter, da Benutzer Anforderungen mit Änderungsbedarf gezielt auswählen können. Das Kennzeichen dient zur Berechnung der KPI „Änderungsquote von Anforderungen“ und für das Dashboard „Änderungsvolumen bei Anforderungen“. So lassen sich Ursachen für Nacharbeit erkennen und die Qualität beim ersten Durchlauf verbessern. Warum das wichtig ist Vereinfacht die Berechnung der KPI zur Änderungsquote und ermöglicht eine einfache Aufteilung in Cases mit und ohne Nacharbeit. Woher beziehen Dieses Attribut wird im Process-Mining-Tool berechnet, indem für jeden Case im Event Log geprüft wird, ob eine Aktivität „Anforderung geändert“ vorhanden ist. Beispiele truefalse
	Genehmigungs-Workflow-Pfad ApprovalWorkflowPath	Ein Bezeichner für die konkrete Genehmigungskette oder das Workflow-Template, das auf die Anforderung angewendet wird.
Beschreibung Dieses Attribut gibt die vordefinierte Reihenfolge der Genehmigenden an, die eine Anforderung durchlaufen soll. Sie wird anhand von Geschäftsregeln festgelegt, häufig abhängig von Faktoren wie Betrag, Abteilung und Anforderungstyp. Das Attribut ist zentral für das Dashboard „Richtlinienkonformität bei Anforderungen“. Durch den Vergleich der tatsächlichen Reihenfolge der Genehmigenden mit dem zugewiesenen Workflow-Pfad lassen sich Abweichungen erkennen, Konformitätsquoten messen und nicht verwaltete Ausnahmen identifizieren. Warum das wichtig ist Ermöglicht die Konformitätsprüfung, indem die erwarteten mit den tatsächlichen Genehmigungsschritten verglichen und Prozessabweichungen sichtbar gemacht werden. Woher beziehen Prüfen Sie die Coupa-Dokumentation. Dieses Attribut lässt sich möglicherweise aus dem Namen der Genehmigungskette oder der Workflow-Regel ableiten, die für die Anforderung ausgelöst wurde. Beispiele Standardgenehmigung unter 5.000 $Genehmigung von IT-Hardware über 10.000 $Prüfung durch den CFO bei Investitionsausgaben
	Lieferantenname SupplierName	Der Name des Lieferanten, der für die Anforderung ausgewählt wurde.
Beschreibung Dieses Attribut gibt den vorgesehenen Lieferanten der angefragten Waren oder Dienstleistungen an. Der Anfordernde kann den Lieferanten angeben oder er wird später im Beschaffungsprozess hinzugefügt. Die Analyse von Prozesskennzahlen nach Lieferant hilft, die Lieferantenleistung zu bewerten und festzustellen, ob die Zusammenarbeit mit bestimmten Lieferanten zu längeren Zykluszeiten oder anderen Ineffizienzen führt. Das Attribut liefert wichtigen Kontext für die Beschaffungsstrategie und das Lieferantenmanagement. Warum das wichtig ist Ermöglicht die Analyse der Prozessleistung nach ausgewähltem Lieferanten und liefert eine Grundlage für Beschaffungsstrategien und das Lieferantenmanagement. Woher beziehen Diese Informationen sind in Coupa im Objekt „Requisition Line“ verfügbar, häufig in einem Feld namens „supplier“ oder „vendor“. Beispiele StaplesDell TechnologiesAccentureCDW
	Währung Currency	Der Währungscode des Gesamtbetrags der Anforderung.
Beschreibung Dieses Attribut gibt an, in welcher Währung, zum Beispiel USD, EUR oder GBP, der Gesamtbetrag der Anforderung ausgewiesen ist. Diese Information ist für jede Finanzanalyse wichtig, insbesondere in multinationalen Organisationen mit mehreren Währungen. Sie stellt sicher, dass Geldbeträge korrekt interpretiert werden, und ermöglicht eine korrekte Umrechnung und Aggregation in Finanzberichten und Dashboards. Warum das wichtig ist Liefert den nötigen Kontext zum Attribut „Gesamtbetrag“ und ermöglicht so genaue Finanzanalysen in Umgebungen mit mehreren Währungen. Woher beziehen Dies ist ein Standardfeld des Objekts „Requisition“ in Coupa, das üblicherweise „currency_code“ oder ähnlich heißt. Beispiele USDEURGBP
	Warengruppe Commodity	Die übergeordnete Kategorie der angefragten Waren oder Dienstleistungen.
Beschreibung Das Attribut „Warengruppe“ ermöglicht eine einheitliche Klassifizierung der Positionen einer Anforderung, zum Beispiel als „Bürobedarf“, „Computerhardware“ oder „Marketingdienstleistungen“. So lassen sich Einkaufsverhalten und Prozessabweichungen danach analysieren, was beschafft wird. Für bestimmte Warengruppen können besondere Genehmigungsanforderungen oder Beschaffungsstrategien gelten. Eine Analyse nach Warengruppe kann helfen, die Beschaffung für verschiedene Ausgabenkategorien zu optimieren. Warum das wichtig ist Unterstützt die Analyse von Ausgabenkategorien und zeigt, ob sich das Prozessverhalten, etwa die Genehmigungsdauer, je nach Art der gekauften Waren oder Dienstleistungen unterscheidet. Woher beziehen Dies ist ein Standardfeld in Coupa, das üblicherweise auf Positionsebene der Anforderung verfügbar ist. Möglicherweise muss es auf Kopfebene aggregiert werden. Beispiele BürobedarfComputerhardwareMarketingdienstleistungenReisen

Erforderlich Empfohlen Optional

Aktivitäten für Purchase-to-Pay-Bestellanforderungen

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, um den Workflow für Purchase-to-Pay-Bestellanforderungen präzise zu erkennen.

6 Empfohlen 6 Optional

	Aktivität	Beschreibung
	Anforderung abgelehnt	Die Anforderung wird im Genehmigungsprozess endgültig abgelehnt und nicht in eine Bestellung umgewandelt. Dies wird aus der Änderung des Gesamtstatus im Anforderungskopf zu „rejected“ abgeleitet.
Warum das wichtig ist Diese Aktivität kennzeichnet das endgültige Scheitern des Prozesses. Die Analyse dieser Ereignisse ist entscheidend, um die „Ablehnungsquote von Anforderungen“ zu senken und Ursachen wie Richtlinienverstöße oder Budgetprobleme zu ermitteln. Woher beziehen Abgeleitet aus einer Statusänderung in der Tabelle „requisition_headers“, wenn das Feld „status“ auf „rejected“ gesetzt wird. Der Timestamp wird im zugehörigen Audit-Trail erfasst. Erfassung Ermitteln Sie den Timestamp, zu dem sich der Gesamtstatus der Anforderung in „rejected“ ändert. Ereignistyp inferred
	Anforderung genehmigt	Die Anforderung hat alle erforderlichen Schritte im Genehmigungs-Workflow erfolgreich durchlaufen. Dies wird aus der Änderung des Gesamtstatus im Anforderungskopf zu „approved“ abgeleitet.
Warum das wichtig ist Dieser wichtige Meilenstein markiert den Abschluss des Genehmigungszyklus. Die Zeit bis zu dieser Aktivität ist eine zentrale KPI und löst die nachfolgenden Beschaffungsschritte aus. Woher beziehen Abgeleitet aus einer Statusänderung in der Tabelle „requisition_headers“, wenn das Feld „status“ auf „approved“ gesetzt wird. Der Timestamp wird im zugehörigen Audit-Trail erfasst. Erfassung Ermitteln Sie den Timestamp, zu dem sich der Gesamtstatus der Anforderung in „approved“ ändert. Ereignistyp inferred
	Anforderung geschlossen	Die Anforderung wird offiziell geschlossen. Damit sind keine weiteren Schritte vorgesehen. Dies kann geschehen, nachdem eine Bestellung erstellt und erfüllt wurde, oder wenn die Anforderung nach der Genehmigung, aber vor der Bestellung storniert wird.
Warum das wichtig ist Diese Aktivität markiert das eindeutige Ende des Lebenszyklus einer Anforderung. So wird sichergestellt, dass jeder Case abgeschlossen ist und in der Prozessanalyse nicht unbegrenzt als „aktiv“ erscheint. Woher beziehen Abgeleitet aus einer Statusänderung in der Tabelle „requisition_headers“, wenn das Feld „status“ auf „closed“ gesetzt wird. Der Timestamp wird im zugehörigen Audit-Trail erfasst. Erfassung Ermitteln Sie den Timestamp, zu dem sich der Gesamtstatus der Anforderung in „closed“ ändert. Ereignistyp inferred
	Bestellanforderung eingereicht	Der Antragstellende reicht die ausgefüllte Bestellanforderung offiziell zur Freigabe ein. Dieses Ereignis lässt sich anhand der Statusänderung von „draft“ zu „pending_approval“ in den Audit-Logs oder Verlaufstabellen des Systems ableiten.
Warum das wichtig ist Mit der Einreichung beginnt der Freigabeprozess. Sie ist daher ein wichtiger Meilenstein für die Kennzahl „Durchschnittliche Freigabezeit für Bestellanforderungen“. Verzögerungen davor hängen mit der Antragstellung zusammen, Verzögerungen danach mit dem Prozess. Woher beziehen Das Ereignis lässt sich aus einer Statusänderung in der Tabelle „requisition_headers“ ableiten, insbesondere wenn das Feld „status“ den Wert „pending_approval“ annimmt. Der Timestamp dieser Änderung ist im zugehörigen Audit-Trail zu finden. Erfassung Ermitteln Sie den Timestamp, zu dem sich der Status der Bestellanforderung erstmals in „pending_approval“ ändert. Ereignistyp inferred
	Bestellanforderung erstellt	Ein Benutzer legt eine neue Bestellanforderung an und speichert sie als Entwurf. Damit beginnt jeder Case einer Bestellanforderung. Der Zeitpunkt lässt sich üblicherweise aus dem Erstellungs-Timestamp des Anforderungsdatensatzes ableiten.
Warum das wichtig ist Diese Aktivität markiert den Beginn des Lebenszyklus einer Bestellanforderung. Die Zeit zwischen Erstellung und Einreichung kann Verzögerungen durch Unsicherheit bei Benutzern oder eine komplexe Systembedienung sichtbar machen. Woher beziehen Dieses Ereignis wird anhand des Timestamps „created-at“ in der Tabelle „requisition_headers“ für eine bestimmte Purchase Requisition ID erfasst. Erfassung Verwenden Sie den Erstellungs-Timestamp des Datensatzes für den Anforderungskopf. Ereignistyp inferred
	Bestellung erstellt	Auf Grundlage der Angaben in der genehmigten Anforderung wird eine Bestellung (PO) erstellt. Dieses Ereignis wird abgeleitet, wenn ein PO-Datensatz mit Verweis auf die ID der ursprünglichen Anforderung angelegt wird.
Warum das wichtig ist Dies ist das wichtigste erfolgreiche Ergebnis des Anforderungsprozesses und markiert die Übergabe an die nächste Phase des Purchase-to-Pay-Prozesses. Die Analyse der Zeit zwischen „Anforderung genehmigt“ und diesem Ereignis macht Verzögerungen bei der Ausführung sichtbar. Woher beziehen Abgeleitet aus der Erstellung eines Datensatzes in der Tabelle „purchase_orders“, der auf die ID des ursprünglichen Datensatzes in „requisition_headers“ oder „requisition_lines“ verweist. Erfassung Verwenden Sie den Timestamp „created-at“ des PO-Datensatzes, der mit der ID der Anforderung verknüpft ist. Ereignistyp inferred
	Anforderung an Beschaffung weitergeleitet	Die genehmigte Anforderung wird an ein Beschaffungsverfahren wie eine RFQ oder Auktion weitergeleitet, statt direkt in eine Bestellung umgewandelt zu werden. Dieses Ereignis wird abgeleitet, wenn die Anforderung mit einem Beschaffungsvorgang verknüpft wird.
Warum das wichtig ist Diese Aktivität macht einen wichtigen alternativen Pfad im Beschaffungsprozess sichtbar. Sie unterscheidet einfache Einkäufe von komplexeren, strategischen Beschaffungsvorgängen und ermöglicht eine differenziertere Analyse der Zykluszeiten. Woher beziehen Abgeleitet durch Erkennung einer Statusänderung zu „sourcing“ oder durch Feststellung, dass eine Verknüpfung zwischen der Tabelle „requisition_lines“ und einer Tabelle für Beschaffungsvorgänge angelegt wurde. Erfassung Prüfen Sie, ob sich der Status zu „sourcing“ ändert oder eine Verknüpfung zu einer ID eines Beschaffungsvorgangs angelegt wird. Ereignistyp inferred
	Anforderung zurückgezogen	Der ursprüngliche Anfordernde storniert die Anforderung, bevor sie endgültig genehmigt wird. Diese ausdrückliche, vom Benutzer ausgelöste Aktion beendet den Prozess für diese Anforderung.
Warum das wichtig ist Zurückgezogene Anforderungen können auf veränderte Geschäftsanforderungen, doppelte Anfragen oder eine Umgehung des Prozesses durch Benutzer hindeuten. Ihre Erfassung hilft, Schwankungen im Bedarf und mögliche Probleme bei der Prozesseinhaltung zu verstehen. Woher beziehen Abgeleitet aus einer Statusänderung in der Tabelle „requisition_headers“ zu „withdrawn“ oder einem ähnlichen Status, die auf einer im Audit-Trail protokollierten ausdrücklichen Benutzeraktion beruht. Erfassung Ermitteln Sie den Timestamp, zu dem sich der Status der Anforderung in „withdrawn“ ändert. Ereignistyp inferred
	Bestellanforderung geändert	Der Antragstellende oder ein anderer autorisierter Benutzer bearbeitet die Bestellanforderung, nachdem sie bereits eingereicht wurde. Coupa protokolliert dies ausdrücklich als neue Version oder als Audit-Eintrag. Dabei wird häufig ein Teil oder der gesamte Freigabe-Workflow zurückgesetzt.
Warum das wichtig ist Änderungen zu erfassen, ist wichtig, um Nacharbeit und Ineffizienzen im Prozess zu verstehen. Viele Änderungen können auf unklare ursprüngliche Anforderungen oder komplexe Einkaufsrichtlinien hinweisen und sich auf die Kennzahl „Änderungsrate bei Bestellanforderungen“ auswirken. Woher beziehen Dieses Ereignis wird anhand der Audit-Trail-Tabellen zur Tabelle „requisition_headers“ erfasst. Dort werden Versionsänderungen oder bestimmte Aktionen wie „edit“ protokolliert. Erfassung Suchen Sie nach ausdrücklichen Ereignissen wie „edit“ oder „update“ im Verlaufsprotokoll der Bestellanforderung, die nach der Einreichung aufgetreten sind. Ereignistyp explicit
	Freigabeschritt genehmigt	Ein einzelner Genehmigender im Workflow genehmigt die Anforderung. Das System protokolliert diese ausdrückliche Aktion mit einem konkreten Timestamp und den Benutzerinformationen.
Warum das wichtig ist Diese Aktivität ermöglicht eine detaillierte Analyse des Genehmigungsablaufs. Durch die Zusammenfassung dieser Schritte lässt sich die „durchschnittliche Wartezeit pro Genehmigungsschritt“ berechnen und die Leistung der Genehmigenden analysieren. Woher beziehen Erfasst anhand einer ausdrücklichen Aktion „approve“, die in der Tabelle „approvals“ oder im zugehörigen Audit-Trail protokolliert und der jeweiligen Anforderung sowie dem Genehmigenden zugeordnet ist. Erfassung Filtern Sie in der Genehmigungshistorie der Anforderung nach Ereignissen vom Typ „approve“. Ereignistyp explicit
	Freigabeschritt gestartet	Eine Freigabeaufgabe wird einer bestimmten genehmigenden Person oder einer Freigabegruppe zugewiesen. Die Bestellanforderung wartet nun auf deren Bearbeitung. Das Ereignis lässt sich daran erkennen, dass ein zugehöriger Freigabedatensatz mit dem Status „pending“ erstellt wird.
Warum das wichtig ist Damit beginnt die Wartezeit für eine bestimmte Freigabe. Die Dauer zwischen diesem Ereignis und der entsprechenden Aktivität „Freigabeschritt genehmigt/abgelehnt“ zeigt, wo in der Freigabekette Engpässe auftreten. Woher beziehen Das Ereignis lässt sich aus dem Erstellungs-Timestamp eines mit der Bestellanforderung verknüpften Datensatzes in der Tabelle „approvals“ ableiten. Der Status der Aktion der genehmigenden Person lautet dabei „pending“ oder entsprechend. Erfassung Verwenden Sie den Erstellungs-Timestamp eines ausstehenden Freigabedatensatzes für eine einzelne Person in der Freigabekette. Ereignistyp inferred
	Genehmigungsschritt abgelehnt	Ein einzelner Genehmigender lehnt die Anforderung in seinem Workflow-Schritt ab und sendet sie in der Regel zur Überarbeitung an den Anfordernden zurück. Coupa protokolliert diese ausdrückliche Aktion.
Warum das wichtig ist Ablehnungen in einzelnen Schritten führen zu Nacharbeit und verlängern die Zykluszeiten. Für Verbesserungen am Prozess und gezielte Benutzerschulungen ist es entscheidend zu analysieren, wo und warum Ablehnungen erfolgen. Woher beziehen Erfasst anhand einer ausdrücklichen Aktion „reject“, die in der Tabelle „approvals“ oder im zugehörigen Audit-Trail protokolliert und der jeweiligen Anforderung sowie dem Genehmigenden zugeordnet ist. Erfassung Filtern Sie in der Genehmigungshistorie der Anforderung nach Ereignissen vom Typ „reject“. Ereignistyp explicit

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Coupa

Schritte

Bei Coupa anmelden: Melden Sie sich mit einem Benutzerkonto bei Ihrer Coupa-Instanz an, das Berichte erstellen und planen darf.
Zum Berichtsmodul wechseln: Öffnen Sie die Registerkarte „Setup“ und suchen Sie den Bereich „Reporting“. Wählen Sie „Reports“, um das Berichtsdashboard zu öffnen.
Neuen benutzerdefinierten Bericht erstellen: Klicken Sie auf „Create“, um einen neuen Bericht anzulegen. Wählen Sie als Typ „Custom Report“.
Datenquellen für den Bericht festlegen: Wählen Sie im Berichtseditor mehrere Datenquellen aus und verknüpfen Sie sie, um alle benötigten Informationen zusammenzuführen. Beginnen Sie mit „Requisition Headers“ als Hauptquelle. Fügen Sie anschließend folgende verknüpfte Objekte hinzu:
- „Approvals“: Enthält Details zu jedem Genehmigungsschritt, darunter genehmigende Person, Status und Zeitstempel.
- „Requisition Lines“: Dient dazu, Gesamtbeträge zusammenzufassen und Details auf Positionsebene abzurufen.
- „Purchase Order Headers“: Zeigt, wann eine Bestellanforderung in eine Bestellung umgewandelt wird.
- „Users“: Enthält vollständige Namen und Abteilungsangaben der anfordernden und genehmigenden Personen.
Berichtsspalten konfigurieren: Ziehen Sie die benötigten Felder aus den verfügbaren Datenquellen per Drag-and-drop in das Berichtslayout. Dieser Schritt ist besonders wichtig, da diese Spalten zur Erstellung des Event Logs dienen. Nehmen Sie mindestens folgende Felder auf:
- Aus „Requisition Headers“: Requisition #, Created At, Submitted At, Updated At, Status, Created by (Login ID), Gesamt, Sourced Externally?
- Aus „Users“ (für die anfordernde Person): Vollständiger Name, Department Name.
- Aus „Approvals“: Created At, Updated At, Status, Approver (Login ID).
- Aus „Purchase Order Headers“: PO Number, Created At.
Berichtsfilter festlegen: Wenden Sie Filter an, um den Datenexport einzugrenzen. Ein gängiger und wirksamer Filter basiert auf „Requisition Headers - Created At“ mit einem dynamischen Zeitraum, zum Beispiel „Last 90 days“. Bei Bedarf können Sie auch nach bestimmten Unternehmenskennungen filtern.
Bericht planen: Öffnen Sie im Berichtseditor die Registerkarte „Schedule“. Legen Sie fest, wie oft der Bericht ausgeführt werden soll, zum Beispiel täglich oder wöchentlich. Wählen Sie eine Uhrzeit mit geringer Systemauslastung.
Bereitstellung konfigurieren: Legen Sie die Bereitstellungsmethode fest. Für eine automatisierte Übertragung wählen Sie „SFTP“ und geben Serverzugangsdaten sowie Zielverzeichnis an. Alternativ können Sie den Bericht an eine E-Mail-Adresse senden. Wählen Sie als Dateiformat „CSV“.
Speichern und aktivieren: Speichern Sie den Bericht und prüfen Sie, ob der Zeitplan aktiviert ist. Der erste Bericht wird zum nächsten geplanten Zeitpunkt erstellt.
Daten umwandeln: Die erzeugte CSV-Datei ist eine flache Datei und kein Event Log. Sie müssen sie mit einem externen Skript, etwa in Python, oder einem ETL-Tool verarbeiten. Das Skript muss die Daten umstrukturieren und für jede Aktivität eine eigene Zeile erstellen. Dazu gehört beispielsweise eine Zeile für „Bestellanforderung erstellt“ mit der Spalte Created At, eine Zeile für jeden Genehmigungsschritt mit den Spalten aus „Approvals“ und eine Zeile für „Bestellung erstellt“ mit der Spalte Created At aus den Bestelldaten.
Abschließendes Event Log erstellen: Das Transformationsskript sollte eine finale CSV-Datei mit den erforderlichen Spalten ausgeben: PurchaseRequisitionId, ActivityName, EventTime, SourceSystem, LastDataUpdate und weitere empfohlene Attribute. Diese Datei ist nun bereit für den Upload.

Konfiguration

Primäre Datenquellen: Der Bericht muss mehrere Coupa-Objekte verknüpfen. Zu den wichtigsten Quellen gehören „Requisition Headers“, „Approvals“, „Requisition Lines“ und „Purchase Order Headers“.
Filter für den Datumsbereich: Ein Datumsfilter ist entscheidend, um das Datenvolumen zu begrenzen. Als Ausgangspunkt empfiehlt sich ein rollierender Zeitraum der letzten 3 bis 6 Monate, basierend auf „Requisition Headers - Created At“.
Inkrementelle Ladevorgänge: Planen Sie für die laufende Analyse eine tägliche Berichtsausführung und exportieren Sie die Daten des Vortags, zum Beispiel „Yesterday“, um inkrementelle Ladevorgänge zu erstellen.
Bereitstellung konfigurieren: Richten Sie die Bereitstellung auf einem SFTP-Server ein, um Ihre Datenpipeline zuverlässig und automatisiert anzubinden. Achten Sie auf ein sicheres Ziel und ausreichend Speicherplatz.
Erforderliche Berechtigungen: Das Benutzerkonto für die Berichtskonfiguration benötigt administrative oder berichtsspezifische Berechtigungen, um alle erforderlichen Datenobjekte (Bestellanforderungen, Bestellungen, Genehmigungen und Benutzer) zu erstellen, zu planen und darauf zuzugreifen.

Beispielabfrage 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`

Schritte

Voraussetzungen: Stellen Sie sicher, dass Python 3 installiert ist. Installieren Sie die erforderlichen Bibliotheken pandas und requests, indem Sie im Terminal oder in der Eingabeaufforderung pip install pandas requests ausführen.
Coupa-API-Schlüssel abrufen: Melden Sie sich als Administrator bei Ihrer Coupa-Instanz an. Navigieren Sie zu Setup > Company Setup > API Keys. Erstellen Sie einen API-Schlüssel mit mindestens Leseberechtigungen für folgende Bereiche: core.purchase_order.read, core.requisition.read und core.user.read.
Skript konfigurieren: Erstellen Sie eine Python-Datei, zum Beispiel extract_coupa_reqs.py. Kopieren Sie das bereitgestellte Python-Skript in diese Datei. Ersetzen Sie den Platzhalter COUPA_INSTANCE_URL durch die Coupa-URL Ihres Unternehmens, zum Beispiel https://yourcompany.coupahost.com, und API_KEY durch den im vorherigen Schritt erstellten Schlüssel.
Extraktionsparameter festlegen: Passen Sie im Abschnitt main des Skripts die Variablen START_DATE und END_DATE an, um den Zeitraum für die Datenextraktion festzulegen. Dadurch werden Bestellanforderungen nach ihrem Erstellungsdatum gefiltert.
Skript ausführen: Starten Sie das Skript im Terminal mit dem Befehl python extract_coupa_reqs.py. Das Skript verbindet sich mit der Coupa-API, ruft die Daten ab und zeigt den Fortschritt in der Konsole an.
API-Paginierung verarbeiten: Das Skript enthält eine Funktion, die die API-Paginierung automatisch verarbeitet. Es ruft die Daten in Seiten mit jeweils 50 Datensätzen ab, bis alle Bestellanforderungen im angegebenen Zeitraum geladen sind.
Daten zu Bestellanforderungen verarbeiten: Für jeden abgerufenen Kopfdatensatz erstellt das Skript die Ereignisse „Bestellanforderung erstellt“ und „Bestellanforderung eingereicht“. Anschließend ruft es über weitere API-Aufrufe die zugehörigen Genehmigungs- und Bestelldaten ab.
Aktivitätsereignisse erstellen: Das Skript verarbeitet die Genehmigungsdatensätze und erstellt die Ereignisse „Genehmigungsschritt gestartet“, „Genehmigungsschritt genehmigt“ und „Genehmigungsschritt abgelehnt“. Außerdem prüft es den endgültigen Status der Bestellanforderung und die zugehörigen Daten, um Ereignisse wie „Bestellanforderung genehmigt“, „Bestellung erstellt“ und „Bestellanforderung zurückgezogen“ zu erzeugen.
Änderungen erkennen: Das Skript prüft das Attribut version jeder Bestellanforderung. Ein Wert über 1 weist auf eine Änderung hin. Für die neuere Version wird anhand des Zeitstempels updated-at das Ereignis „Bestellanforderung geändert“ erstellt.
Event Log zusammenstellen: Alle erstellten Ereignisse werden in einer strukturierten Liste gesammelt. Jedes Ereignis enthält erforderliche Attribute wie PurchaseRequisitionId, ActivityName und EventTime sowie empfohlene Attribute wie anfordernde Person und Gesamtbetrag.
Als CSV exportieren: Nachdem alle Bestellanforderungen verarbeitet wurden, wandelt das Skript die Ereignisliste in einen pandas DataFrame um und speichert sie im selben Verzeichnis als coupa_requisition_event_log.csv. Diese Datei ist für den direkten Upload in ProcessMind formatiert.

Konfiguration

Berechtigungen für den API-Schlüssel: Der für die Extraktion verwendete API-Schlüssel benötigt Lesezugriff auf die Coupa-Objekte requisition_headers, requisition_lines, approvals, purchase_orders und users. Ohne diese Berechtigungen schlägt das Skript fehl oder liefert unvollständige Daten.
Datumsbereich: Das Skript filtert anhand des Erstellungsdatums der Bestellanforderung (created-at). Um lange Laufzeiten und mögliche API-Zeitüberschreitungen zu vermeiden, empfiehlt es sich, die Daten in überschaubaren Abschnitten von jeweils 3 bis 6 Monaten zu extrahieren. Passen Sie START_DATE und END_DATE entsprechend an.
Filter für den Status: Das bereitgestellte Skript ruft Bestellanforderungen unabhängig von ihrem Status ab. Für eine gezieltere Analyse können Sie dem Wörterbuch params im ersten API-Aufruf einen Parameter status hinzufügen, um bestimmte Statuswerte wie approved, pending_approval oder ordered auszuwählen.
Seitengröße: Das Skript ist fest auf 50 Datensätze pro API-Aufruf eingestellt (limit=50). Dieser Standardwert eignet sich gut für die Coupa-API. Eine Erhöhung verbessert die Leistung nicht unbedingt und kann bei komplexen Abfragen das Risiko von Zeitüberschreitungen erhöhen.
Leistungsaspekte: Für jede Bestellanforderung führt das Skript mehrere API-Aufrufe aus: einen für den Kopfdatensatz, einen für Genehmigungen und einen für Bestellungen. Die Extraktion von Tausenden Bestellanforderungen kann zeitaufwendig sein und den API-Ratenbegrenzungen von Coupa unterliegen. Führen Sie das Skript möglichst außerhalb der Hauptgeschäftszeiten aus.

Beispielabfrage 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)

Schritte

Prüfen Sie, ob die ausgewählte iPaaS- oder Process-Mining-Plattform eines Drittanbieters einen verifizierten Coupa-Konnektor bereitstellt, der auf Kopfdatensätze von Bestellanforderungen, deren Verlauf oder Audit-Daten, Genehmigungsdatensätze, Beschaffungsbeziehungen, Bestellbeziehungen und Abschlussinformationen zugreifen kann. Namen von Konnektoren und Objekten sowie verfügbare Felder unterscheiden sich je nach Anbieter. Richten Sie den Konnektor daher anhand der Dokumentation und Ihres Coupa-Mandanten ein.
Richten Sie über die Verbindungsoberfläche der Plattform eine Konnektorverbindung ein. Geben Sie die erforderliche Coupa-Mandanten-URL, Authentifizierungsmethode, Zugangsdaten, OAuth-Details und gegebenenfalls erforderliche Berechtigungsbereiche an. Verwenden Sie Platzhalter wie [Your Coupa tenant URL] und [Your connector credentials], bis die Verbindung in der Zielumgebung eingerichtet ist.
Legen Sie den Umfang der Extraktion fest. Wählen Sie zunächst einen rollierenden Zeitraum von drei bis sechs Monaten und erweitern Sie ihn nach dem Abgleich. Verwenden Sie nur Filter, die für Ihren Mandanten gültig sind, etwa [Your company filter] oder [Your document type filter]. Schließen Sie Bestellanforderungen nicht allein deshalb aus, weil ihr aktueller Status „geschlossen“, „abgelehnt“, „zurückgezogen“ oder „genehmigt“ ist. Diese Cases werden für die Analyse des Prozesslebenszyklus benötigt.
Ordnen Sie die Quellobjekte im Konnektor zu. Wählen Sie das Objekt für Bestellanforderungsköpfe, den Verlauf oder Audit-Datensatz der Bestellanforderung, das Genehmigungsobjekt, das Beschaffungsbeziehungsobjekt, das Bestellbeziehungsobjekt sowie alle verfügbaren Objekte für Abschluss- oder Statusverläufe aus. Ist ein erforderliches Objekt nicht verfügbar, verwenden Sie die vom Konnektor unterstützte Verlaufs- oder Audit-Darstellung oder dokumentieren Sie die Einschränkung vor der Veröffentlichung der Extraktion.
Konfigurieren Sie die Zuordnung von Cases und Ereignissen. Ordnen Sie die Kennung der Bestellanforderung PurchaseRequisitionId, die Ereignisbezeichnung ActivityName, den Quellzeitstempel EventTime, den konstanten Quellwert Coupa SourceSystem und den Aktualisierungszeitstempel des Konnektors LastDataUpdate zu. Ordnen Sie außerdem anfordernde Person, Abteilung, Gesamtbetrag, Status der Bestellanforderung und genehmigende Person zu, sofern diese Felder verfügbar sind.
Richten Sie Ereignisregeln ein, die ausdrücklich Zeilen für alle zwölf Aktivitäten erstellen. Erstellen Sie „Bestellanforderung erstellt“ anhand des Erstellungszeitstempels der Bestellanforderung, „Bestellanforderung eingereicht“ anhand eines Statuswechsels von Entwurf zu pending_approval, „Bestellanforderung geändert“ anhand einer Versions- oder Audit-Aufzeichnung nach dem Einreichen, „Genehmigungsschritt gestartet“ anhand eines ausstehenden Genehmigungsdatensatzes, „Genehmigungsschritt genehmigt“ anhand einer Genehmigungsaktion, „Genehmigungsschritt abgelehnt“ anhand einer Ablehnungsaktion, „Bestellanforderung zurückgezogen“ anhand einer ausdrücklichen Rücknahmeaktion oder eines entsprechenden Statuswechsels, „Bestellanforderung genehmigt“ anhand eines Statuswechsels im Kopfdatensatz zu „genehmigt“, „Bestellanforderung abgelehnt“ anhand eines Statuswechsels im Kopfdatensatz zu „abgelehnt“, „Bestellanforderung zur Beschaffung übergeben“ anhand einer Beschaffungsbeziehung, „Bestellung erstellt“ anhand einer Bestellung, die auf die Bestellanforderung verweist, und „Bestellanforderung geschlossen“ anhand einer Abschlussaktion oder eines entsprechenden Statuswechsels.
Vereinheitlichen Sie die extrahierten Daten, bevor Sie die Ereignisströme zusammenführen. Konvertieren Sie alle Zeitstempel in dieselbe Zeitzone, vorzugsweise UTC, behalten Sie die Genauigkeit der Quellzeitstempel bei, wandeln Sie die Kennung der Bestellanforderung in einen einheitlichen Textdatentyp um und übernehmen Sie die Quellwerte für Status und Benutzer. Entfernen Sie Duplikate nur dann, wenn Quelldatensätze technisch identisch sind. Verwenden Sie dafür, sofern verfügbar, die Kennung der Bestellanforderung, den Aktivitätsnamen, den Ereigniszeitstempel, die Kennung des Quelldatensatzes und die genehmigende Person als Vergleichsschlüssel.
Veröffentlichen oder planen Sie den Konnektor-Workflow. Führen Sie für den ausgewählten Zeitraum zunächst eine vollständige Extraktion durch. Richten Sie anschließend inkrementelle Aktualisierungen anhand des Quell-Aktualisierungszeitstempels oder der vom Konnektor unterstützten Änderungsverfolgung ein. Legen Sie einen Rückblickzeitraum fest, damit später eingehende Audit-Einträge und geänderte Genehmigungsdatensätze berücksichtigt werden.
Prüfen Sie das resultierende Event Log anhand von Coupa-Berichten oder der Konnektorvorschau. Vergewissern Sie sich, dass jede Bestellanforderung ein Erstellungsereignis enthält, Status- und Genehmigungswechsel in der erwarteten Reihenfolge auftreten und beziehungsbasierte Ereignisse vorhanden sind, wenn Beschaffungsbeziehungen oder Bestellungen bestehen.
Exportieren Sie das Endergebnis als flache CSV-Datei oder in einem anderen von ProcessMind unterstützten Event-Log-Format. Verwenden Sie eine Zeile pro Ereignis, PurchaseRequisitionId als Case-ID, ActivityName als Aktivität und EventTime als Ereigniszeitstempel. Laden Sie die Datei hoch oder veröffentlichen Sie den Konnektor-Datensatz in ProcessMind. Verlassen Sie sich dabei nicht darauf, dass ProcessMind fehlende Ereignisse ableitet.

Konfiguration

Konnektor und Zugriff: Verwenden Sie einen verifizierten Coupa-Konnektor des ausgewählten iPaaS- oder Process-Mining-Anbieters. Die erforderlichen Coupa-Berechtigungen, API-Bereiche, Module und Konnektorlizenzen hängen vom Anbieter und der Mandantenkonfiguration ab. Prüfen Sie vor der Implementierung den Zugriff auf Daten zu Bestellanforderungen, Verlauf oder Audit, Genehmigungen, Beschaffung, Bestellungen und Abschlüssen.
Datumsbereich: Beginnen Sie mit Daten aus drei bis sechs Monaten. Verwenden Sie für geplante Aktualisierungen ein rollierendes Extraktionsfenster und berücksichtigen Sie einen Rückblickzeitraum, um verspätete Aktualisierungen, Genehmigungsaktionen und geänderte Bestellanforderungen zu erfassen.
Erforderliche Zuordnungen: Ordnen Sie die Kennung der Bestellanforderung PurchaseRequisitionId, die Ereignisbezeichnung ActivityName, den Ereigniszeitstempel EventTime, den Quellwert SourceSystem und den Aktualisierungszeitstempel LastDataUpdate zu.
Empfohlene Zuordnungen: Ordnen Sie Status der Bestellanforderung, anfordernde Person, Abteilung oder Kostenstelle, Gesamtbetrag und genehmigende Person zu. Wenn der Konnektor historische Snapshots unterstützt, behalten Sie sowohl aktuelle Werte als auch Werte auf Ereignisebene bei.
Ereignisregeln: Richten Sie die Erstellung aller zwölf erforderlichen Aktivitäten ausdrücklich ein. ProcessMind übernimmt das Event Log unverändert und leitet keine zusätzlichen Ereignisse ab.
Filter: Verwenden Sie nur Filter, die vom Konnektor unterstützt werden und für den Mandanten gültig sind, etwa [Your company filter], [Your document type filter], [Your business unit filter] oder [Your requisition date range]. Schließen Sie keine Endstatus aus, sofern dies nicht für die Analyse erforderlich ist.
Umgang mit Zeitstempeln: Konvertieren Sie Zeitstempel in eine gemeinsame Zeitzone, behalten Sie die Genauigkeit der Quelldaten bei und legen Sie eine eindeutige Sortierregel für Ereignisse mit identischen Zeitstempeln fest.
Inkrementelle Aktualisierung: Verwenden Sie das vom Konnektor unterstützte Feld updated-at oder die Änderungsverfolgung. Richten Sie einen Rückblickzeitraum ein, da Genehmigungsverläufe, Beschaffungs- und Bestellverknüpfungen sowie Abschlussinformationen nach der ursprünglichen Erstellung hinzukommen können.
Leistung: Begrenzen Sie die erste Extraktion nach Datum und gültigen Geschäftsfiltern, rufen Sie nur erforderliche Felder ab, paginieren Sie große Objekte und vermeiden Sie wiederholte Verknüpfungen vollständiger historischer Datensätze. Extrahieren Sie Beziehungs- und Audit-Daten, sofern unterstützt, inkrementell.
Datenqualität: Stellen Sie sicher, dass PurchaseRequisitionId, ActivityName, EventTime, SourceSystem und LastDataUpdate nicht leer sind. Bewahren Sie Quellkennungen für die Fehlerbehebung und Deduplizierung auf, sofern der Konnektor sie bereitstellt.
Unterschiede bei der Konfiguration: Objektnamen, Feldnamen, Statuswerte, Audit-Darstellungen und verfügbare Beziehungsdaten unterscheiden sich je nach Coupa-Mandant und Konnektor. Verwenden Sie [Configure based on your system], wenn der Konnektor keine dokumentierte Entsprechung bereitstellt.

Beispielabfrage 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;

Möchten Sie loslegen?

Optimieren Sie noch heute Ihren Coupa-Purchase-to-Pay-Prozess für Bestellanforderungen mit diesem Template. Gewinnen Sie wertvolle Erkenntnisse und verbessern Sie die Effizienz Ihrer Beschaffung.

Zurück zum Leitfaden zur Prozessverbesserung

Template herunterladen

Optimieren Sie Coupa-P2P-Bestellanforderungen und verkürzen Sie noch heute die Durchlaufzeit

Erkennen Sie Ineffizienzen und verkürzen Sie die Durchlaufzeit Ihrer P2P-Bestellanforderungen um 30 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Optimieren Sie Ihre Abläufe in wenigen Minuten.

Ihr Daten-Template für Purchase-to-Pay-Bestellanforderungen

Ihr Daten-Template für Purchase-to-Pay-Bestellanforderungen

Attribute für Purchase-to-Pay-Bestellanforderungen

Aktivitäten für Purchase-to-Pay-Bestellanforderungen

Anleitungen zur Datenextraktion

Geplante Coupa-Berichte für den Datenexport von Bestellanforderungen

Schritte

Konfiguration

Beispielabfrage config

Datenextraktion mit einem Python-Skript über die Coupa-REST-API

Schritte

Konfiguration

Beispielabfrage python

Datenextraktion mit einem iPaaS-Konnektor eines Drittanbieters

Schritte

Konfiguration

Beispielabfrage config

Möchten Sie loslegen?

Optimieren Sie Coupa-P2P-Bestellanforderungen und verkürzen Sie noch heute die Durchlaufzeit