Ihr Daten-Template für Purchase to Pay, Purchase Order

Oracle Fusion Financials
Ihr Daten-Template für Purchase to Pay, Purchase Order

Ihr Daten-Template für Purchase to Pay, Purchase Order

Dieses Template bietet einen klaren Leitfaden für die Erfassung der Daten, die Sie zur Analyse Ihres Purchase-to-Pay-Prozesses für Purchase Orders benötigen. Es beschreibt die wichtigsten Datenattribute, die zu erfassenden Aktivitäten und praktische Hinweise zum Extrahieren dieser Informationen. So stellen Sie sicher, dass alle relevanten Details für ein effektives Process Mining enthalten sind.
  • Empfohlene Attribute für eine umfassende Datenerfassung
  • Wichtige Prozessaktivitäten zur Erfassung und Analyse
  • Schrittweise Anleitung zur Datenextraktion aus Oracle Fusion Financials
Neu bei Event Logs? Lernen Sie, wie Sie ein Process-Mining-Event-Log erstellen.

Purchase to Pay - Purchase Order: Attribute

Dies sind die empfohlenen Datenfelder, die Sie für eine umfassende Analyse Ihres Purchase-to-Pay-Prozesses für Bestellungen in das Event Log aufnehmen sollten.
3 Erforderlich 7 Empfohlen 11 Optional
Name Beschreibung
Aktivität
ActivityName
Der Name eines bestimmten Geschäftsereignisses oder Prozessschritts, der innerhalb des Lebenszyklus einer Bestellung stattgefunden hat.
Beschreibung

Dieses Attribut beschreibt eine bestimmte Aufgabe oder Statusänderung im Prozess, beispielsweise „Bestellung erstellt“ oder „Waren eingegangen“. Diese Aktivitäten bilden die Abfolge der Ereignisse, aus denen der Prozessablauf besteht.

Die Analyse der Reihenfolge und des Zeitpunkts dieser Aktivitäten bildet den Kern von Process Mining. Sie hilft, die Prozesskarte zu visualisieren, Engpässe zu erkennen, Abweichungen vom Standardverfahren aufzudecken und die Dauer einzelner Schritte zu messen.

Warum das wichtig ist

Aktivitäten bilden die Bausteine der Prozesskarte. Ihre Nachverfolgung ermöglicht die Visualisierung und Analyse des Prozessablaufs, von Engpässen und von Abweichungen.

Bezugsquelle

Abgeleitet aus Statusänderungen in Tabellen wie PO_HEADERS_ALL und PO_ACTION_HISTORY oder aus speziellen Transaktionstabellen wie RCV_TRANSACTIONS für Wareneingänge.

Beispiele
Bestellung erstelltBestellung genehmigtWaren eingegangen
Bestellung
PurchaseOrder
Die eindeutige Kennung des Bestelldokuments, die als primäre Case-ID zur Nachverfolgung des Beschaffungslebenszyklus dient.
Beschreibung

Die Bestellnummer ist die zentrale Kennung, die alle zugehörigen Aktivitäten von der Erstellung bis zum endgültigen Abschluss verknüpft. Sie ermöglicht die durchgängige Analyse eines einzelnen Beschaffungs-Cases.

Im Process Mining steht jede eindeutige Bestellnummer für eine einzelne Prozessinstanz. Die Analyse von Daten, die nach dieser Kennung gruppiert sind, hilft dabei, Prozessvarianten, Durchlaufzeiten und Compliance für einzelne Bestellungen zu verstehen.

Warum das wichtig ist

Dies ist die zentrale Case-ID, die alle zugehörigen Ereignisse verbindet und dadurch die Rekonstruktion und Analyse des gesamten Lebenszyklus der Bestellung ermöglicht.

Bezugsquelle

Oracle Fusion Cloud SCM, Procurement Module, Tabelle PO_HEADERS_ALL, Spalte SEGMENT1.

Beispiele
100234510023461002347
Startzeit
EventTime
Der Zeitstempel, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung

Dieses Attribut erfasst das genaue Datum und die genaue Uhrzeit jeder Aktivität im Prozess. Es ist grundlegend für die chronologische Sortierung von Ereignissen und für alle zeitbasierten Analysen.

Im Process Mining wird die Startzeit verwendet, um das Event Log zu erstellen, Durchlaufzeiten zwischen Aktivitäten zu berechnen, Wartezeiten zu messen und die Prozessleistung über verschiedene Zeiträume zu analysieren. Sie ist für Dashboards zu Durchlaufzeiten und Leistung unverzichtbar.

Warum das wichtig ist

Dieser Zeitstempel ist entscheidend, um Ereignisse korrekt zu ordnen und alle dauerbasierten Kennzahlen wie Durchlaufzeiten und Engpässe zu berechnen.

Bezugsquelle

Timestamp-Felder wie CREATION_DATE und LAST_UPDATE_DATE aus verschiedenen Tabellen, darunter PO_HEADERS_ALL, PO_ACTION_HISTORY und RCV_SHIPMENT_LINES.

Beispiele
2023-04-15T10:05:00Z2023-04-16T14:30:00Z2023-05-01T09:00:00Z
Abteilung
DepartmentName
Der Name der Abteilung, die die Bestellung initiiert hat oder für sie verantwortlich ist.
Beschreibung

Dieses Attribut bezeichnet die zugehörige Organisationseinheit, beispielsweise „Finance“, „IT“ oder „Manufacturing“. Es wird für die Kostenverteilung und das Organisationsreporting verwendet.

Im Process Mining ist die Segmentierung des Prozesses nach Abteilungen entscheidend, um Leistungen zu vergleichen, abteilungsspezifische Engpässe zu erkennen und Unterschiede in der Prozessausführung innerhalb des Unternehmens zu verstehen. Sie unterstützt direkt Dashboards wie „PO Approval Cycle Time Analysis“ und „Purchase Order Modification Trends“.

Warum das wichtig ist

Ermöglicht die Filterung und den Vergleich der Prozessleistung über verschiedene Geschäftsbereiche hinweg. So werden abteilungsspezifische Probleme oder bewährte Vorgehensweisen sichtbar.

Bezugsquelle

Abgeleitet aus Kostenstelleninformationen in Tabellen wie PO_DISTRIBUTIONS_ALL, die mit den Stammdaten der Abteilungen verknüpft sind.

Beispiele
IT-BetriebMarketingForschung und Entwicklung
Benutzer
UserName
Die Benutzer-ID oder der Name der Person, die die Aktivität ausgeführt hat.
Beschreibung

Dieses Attribut identifiziert die für ein bestimmtes Ereignis verantwortliche Person oder den zuständigen Systembenutzer, beispielsweise für die Erstellung einer Bestellanforderung, die Genehmigung einer Bestellung oder die Buchung eines Wareneingangs. Die Daten stammen typischerweise aus Feldern wie „Created By“ oder „Last Updated By“.

Die Analyse des Prozesses nach Benutzern hilft, die Arbeitslastverteilung und die individuelle Leistung zu verstehen sowie Schulungsbedarf zu erkennen. Sie ist eine wichtige Grundlage für das Dashboard „Approval Resource Workload“ und für die Untersuchung von Compliance-Problemen im Zusammenhang mit Benutzeraktionen.

Warum das wichtig ist

Ordnet Benutzeraktionen bestimmten Personen zu und ermöglicht dadurch die Analyse der Arbeitslast, die Leistungsbewertung und die Ermittlung von Schulungsbedarf.

Bezugsquelle

Verknüpfen Sie die Daten anhand der IDs in Feldern wie CREATED_BY oder LAST_UPDATED_BY mit Benutzertabellen, beispielsweise in PO_HEADERS_ALL und PO_ACTION_HISTORY.

Beispiele
john.doejane.smithsystem.batch
Endzeit
EndTime
Der Zeitstempel, zu dem eine Aktivität abgeschlossen wurde. Bei atomaren Ereignissen entspricht er häufig der Startzeit.
Beschreibung

Bei Aktivitäten mit einer bestimmten Dauer kennzeichnet dieser Wert den Abschlusszeitpunkt. Bei sofortigen Ereignissen entspricht er in der Regel der Startzeit. Er ist entscheidend, um die Bearbeitungszeit einzelner Aktivitäten zu berechnen.

Eine separate Endzeit ermöglicht eine präzisere Analyse der Aktivitätsdauer, die sich von der Wartezeit zwischen Aktivitäten unterscheiden kann. So lässt sich aktive Arbeitszeit von Leerlaufzeit abgrenzen. Das unterstützt die Analyse von Ressourcenauslastung und Effizienz.

Warum das wichtig ist

Ermöglicht die präzise Berechnung von Bearbeitungszeiten einzelner Aktivitäten. Das ist entscheidend für die Analyse der Ressourceneffizienz und die Erkennung zeitaufwendiger Aufgaben.

Bezugsquelle

Bei atomaren Ereignissen kann die Endzeit der Startzeit entsprechen oder aus den Zeitstempeln nachfolgender Ereignisse abgeleitet werden. Für einige Aktivitäten ist ein separater Abschlusszeitstempel vorhanden.

Beispiele
2023-04-15T10:05:00Z2023-04-16T14:45:00Z2023-05-01T09:15:00Z
Gesamtbetrag der Bestellung
PurchaseOrderTotalAmount
Der gesamte Geldwert der Bestellung.
Beschreibung

Dieses Attribut bezeichnet die Gesamtkosten aller Positionen der Bestellung in der angegebenen Währung. Es ist eine wichtige Finanzkennzahl, um den Wert der durch den Prozess laufenden Transaktionen zu verstehen.

Die Analyse des Gesamtbetrags der Bestellung hilft dabei, Verbesserungsmaßnahmen zu priorisieren. Bestellungen mit hohem Wert können beispielsweise einen strengeren Genehmigungsprozess durchlaufen. Außerdem ermöglicht das Attribut eine Analyse der finanziellen Auswirkungen, etwa des Werts häufig geänderter oder verzögerter Bestellungen.

Warum das wichtig ist

Liefert den finanziellen Kontext des Prozesses und ermöglicht Analysen nach Geldwert, beispielsweise die Fokussierung auf Bestellungen mit hohem Wert oder die Bewertung finanzieller Auswirkungen von Verzögerungen.

Bezugsquelle

Berechnet durch Summierung der Beträge aus PO_LINES_ALL für eine bestimmte Bestellüberschrift oder aus einer verfügbaren Gesamtsumme auf Überschriftsebene.

Beispiele
5250.00120000.50750.99
Gewünschtes Lieferdatum
RequestedDeliveryDate
Das Datum, bis zu dem die anfordernde Stelle die Lieferung der Waren oder Dienstleistungen erwartet.
Beschreibung

Dieses Datum wird auf der Purchase-Order-Position angegeben und teilt dem Vendor den gewünschten Lieferzeitraum mit. Es dient als Referenz für die Messung der termingerechten Lieferleistung.

Das Attribut ist für die Berechnung des KPIs „On-Time Delivery Rate“ entscheidend. Durch den Vergleich des tatsächlichen Wareneingangsdatums mit dem angeforderten Lieferdatum können Unternehmen die Zuverlässigkeit von Vendoren quantitativ messen und verfolgen sowie systematische Verzögerungen in der Lieferkette erkennen.

Warum das wichtig ist

Dient als Referenz für die Messung der termingerechten Lieferleistung und ist ein wichtiger KPI zur Bewertung der Zuverlässigkeit von Vendoren und der Effizienz der Lieferkette.

Bezugsquelle

Auf Ebene des Positionsstandorts in der Tabelle PO_LINE_LOCATIONS_ALL, Spalte NEED_BY_DATE.

Beispiele
2023-05-202023-06-152023-07-01
Lieferantenname
VendorName
Der Name des Lieferanten, von dem Waren oder Dienstleistungen bezogen werden.
Beschreibung

Dieses Attribut identifiziert den externen Lieferanten der Bestellung. Es handelt sich um zentrale Stammdaten, die mit der Bestellüberschrift verknüpft sind.

Die Lieferantenanalyse ist ein wichtiger Bestandteil des Process Mining im P2P-Prozess. Durch die Filterung oder Segmentierung nach Lieferanten können Unternehmen die Lieferantenleistung bei Lieferungen analysieren, Termintreuequoten vergleichen und die Rücksendequote von Waren untersuchen, um leistungsstarke und leistungsschwache Lieferanten zu erkennen. Diese Daten sind für das Lieferantenmanagement und die strategische Beschaffung unverzichtbar.

Warum das wichtig ist

Unverzichtbar für die Analyse der Lieferantenleistung. Ermöglicht den Vergleich von Lieferzeiten, Rücksendequoten und der allgemeinen Zuverlässigkeit verschiedener Lieferanten.

Bezugsquelle

Verknüpft von PO_HEADERS_ALL.VENDOR_ID mit POZ_SUPPLIERS.VENDOR_NAME.

Beispiele
Globaler BürobedarfTech Solutions Inc.Advanced Logistics Co.
Name des Genehmigenden
ApproverName
Der Name des Benutzers, der eine Genehmigungs- oder Ablehnungsaktion für den Purchase Order ausgeführt hat.
Beschreibung

Dieses Attribut erfasst die für einen Genehmigungsschritt im Workflow verantwortliche Person. Die Information wird in der Regel in einer Aktionshistorie oder Workflow-Log-Tabelle zum Purchase Order gespeichert.

Die Analyse nach Genehmigendem ist für die Dashboards „PO Approval Cycle Time Analysis“ und „Approval Resource Workload“ entscheidend. Sie zeigt, welche Genehmigenden oder Genehmigungsgruppen Engpässe verursachen, ermöglicht eine faire Bewertung der Arbeitslast und kann Ansatzpunkte für Delegation oder eine Neugestaltung des Prozesses liefern.

Warum das wichtig ist

Identifiziert die Personen in der Genehmigungskette und ermöglicht die Analyse von Genehmigungsengpässen, Arbeitslast und Durchlaufzeiten nach Genehmigendem.

Bezugsquelle

Der Benutzer, der die Aktion ausgeführt hat. Zu finden in PO_ACTION_HISTORY.ACTION_PERFORMED_BY, verknüpft mit einer Benutzertabelle, die den vollständigen Namen enthält.

Beispiele
susan.managerdavid.directoremily.finance
Bestellanforderung
PurchaseRequisitionNumber
Die Kennung der Purchase Requisition, die dem Purchase Order vorausging und ihn autorisierte.
Beschreibung

Die Purchase Requisition ist das interne Dokument zur Anforderung der Beschaffung von Waren oder Dienstleistungen. Dieses Attribut verknüpft den Purchase Order mit der ursprünglichen Anforderung.

Die Einbindung der Requisitionsnummer ermöglicht eine umfassendere Analyse des Beschaffungsprozesses, die bereits bei der ursprünglichen Anforderung statt erst beim PO beginnt. So lässt sich die Durchlaufzeit von der Anforderung bis zur Bestellung analysieren und nachvollziehen, wie sich die Details der Requisition auf den nachgelagerten PO-Prozess auswirken.

Warum das wichtig ist

Verknüpft den PO mit der ursprünglichen Anforderung und ermöglicht eine umfassendere End-to-End-Sicht auf den Prozess von der Requisition bis zur Zahlung.

Bezugsquelle

Verknüpft über die Tabelle PO_DISTRIBUTIONS_ALL, die REQ_DISTRIBUTION_ID enthält und auf die Tabelle POR_REQUISITION_LINES_ALL zurückverweist.

Beispiele
PR-2023-05-001PR-2023-05-002PR-2023-05-003
Bestellstatus
PurchaseOrderStatus
Der aktuelle Status des Bestelldokuments.
Beschreibung

Dieses Attribut zeigt den aktuellen Status der Bestellung in ihrem Lebenszyklus an, beispielsweise „Open“, „Approved“, „Finally Closed“ oder „Canceled“. Es liefert eine Momentaufnahme des Fortschritts der Bestellung.

Während sich Process Mining auf die Abfolge der Aktivitäten konzentriert, ist der aktuelle Status für die Filterung von Cases wertvoll. So kann sich eine Analyse beispielsweise auf offene Bestellungen konzentrieren, um die aktuelle Pipeline zu verstehen, oder auf geschlossene Bestellungen, um abgeschlossene Prozessinstanzen zu untersuchen. Das Attribut ist eine wichtige Grundlage für das Dashboard „Purchase Order Flow & Status“.

Warum das wichtig ist

Liefert eine aktuelle Momentaufnahme des Bestellstatus und ermöglicht die Filterung der Analyse nach aktiven, abgeschlossenen oder stornierten Bestellungen.

Bezugsquelle

Oracle Fusion Cloud SCM, Tabelle PO_HEADERS_ALL, Spalten AUTHORIZATION_STATUS oder DOCUMENT_STATUS.

Beispiele
OPENAPPROVEDFINALLY_CLOSEDCANCELED
Einkaufskategorie
PurchaseCategory
Die Klassifizierung der eingekauften Waren oder Dienstleistungen, beispielsweise „IT Hardware“ oder „Office Supplies“.
Beschreibung

Dieses Attribut ordnet die Positionen des Purchase Orders einer Beschaffungshierarchie zu. Die Klassifizierung wird für Ausgabenanalysen und das Lieferantenmanagement verwendet.

Im Process Mining kann die Segmentierung des Prozesses nach Einkaufskategorie unterschiedliche Verhaltensweisen oder Leistungsniveaus sichtbar machen. So kann der Genehmigungsprozess für Investitionsausgaben länger dauern als für operative Verbrauchsgüter. Das Attribut unterstützt direkt das Dashboard „Goods Return Rate & Reasons“, da sich analysieren lässt, welche Kategorien am häufigsten zurückgegeben werden.

Warum das wichtig ist

Ermöglicht die Prozessanalyse nach Ausgabenart und kann unterschiedliche Prozesspfade, Engpässe oder Rückgabequoten für verschiedene Warenkategorien sichtbar machen.

Bezugsquelle

Verknüpft von PO_LINES_ALL.CATEGORY_ID mit der Ansicht EGP_CATEGORIES_VL.

Beispiele
IT.Hardware.LaptopsOffice.Supplies.StationeryProfessional.Services.Consulting
Geschäftseinheit
BusinessUnitName
Die konkrete Geschäftseinheit innerhalb der Organisation, die den Einkauf tätigt.
Beschreibung

Die Business Unit stellt eine eigenständige Geschäftseinheit innerhalb des Unternehmens dar, häufig mit eigenem Ledger und eigener Finanzberichterstattung. In Oracle Fusion dient sie als zentrale Möglichkeit zur Datentrennung.

Die Analyse der Prozessleistung nach Business Unit ist für große, international tätige Unternehmen entscheidend. Sie ermöglicht den Vergleich von Beschaffungseffizienz, Compliance und Kosten in verschiedenen Organisationsteilen und macht sowohl Best Practices als auch Verbesserungsbereiche sichtbar.

Warum das wichtig ist

Für große Organisationen entscheidend, um Prozesseffizienz und Compliance zwischen verschiedenen operativen Bereichen zu vergleichen.

Bezugsquelle

Der Kontext der Business Unit befindet sich in der Regel im PO-Kopf, in PO_HEADERS_ALL.PRC_BU_ID. Dieses Feld verweist auf die Ansicht FUN_ALL_BUSINESS_UNITS_V.

Beispiele
US-GeschäftseinheitEMEA VisionAPAC Services
Ist genehmigungskonform
IsApprovalCompliant
Ein Kennzeichen dafür, dass der PO genehmigt wurde, bevor er an den Vendor gesendet wurde.
Beschreibung

Dieses berechnete boolesche Attribut prüft die Einhaltung einer zentralen internen Kontrolle: Ein Purchase Order muss genehmigt sein, bevor er an einen Lieferanten versendet wird. Der Wert ist true, wenn die Aktivität „Purchase Order Approved“ vor der Aktivität „Purchase Order Sent to Vendor“ erfolgt.

Das Attribut ist für das Dashboard „PO Process Compliance Audit“ und den KPI „PO Approval Compliance Rate“ entscheidend. Es bietet eine direkte Möglichkeit, Compliance-Verstöße zu erkennen und zu quantifizieren. Dadurch lassen sich Beschaffungsrichtlinien durchsetzen und Risiken durch nicht autorisierte Ausgaben verringern.

Warum das wichtig ist

Misst den KPI „PO Approval Compliance Rate“ direkt und macht kritische Verstöße gegen interne Kontrollen sichtbar, bei denen Bestellungen vor der Genehmigung an Vendoren gesendet werden.

Bezugsquelle

Berechnetes Feld. Wird auf „true“ gesetzt, wenn der Timestamp von „Purchase Order Approved“ kleiner oder gleich dem Timestamp von „Purchase Order Sent to Vendor“ ist.

Beispiele
truefalse
Ist Nacharbeit
IsRework
Ein Kennzeichen dafür, dass der Purchase Order nach seiner ursprünglichen Erstellung geändert wurde.
Beschreibung

Dieses berechnete boolesche Attribut wird auf true gesetzt, wenn ein Purchase-Order-Case die Aktivität „Purchase Order Changed“ enthält. So lassen sich Bestellungen, die Korrekturen oder Änderungen erforderten, schnell identifizieren.

Das Kennzeichen vereinfacht die Berechnung des KPIs „PO Modification Rate“ und ermöglicht die einfache Filterung und Analyse nachbearbeiteter Bestellungen. Die Merkmale dieser Bestellungen, etwa die beteiligten Vendoren oder Abteilungen, können Aufschluss über die Ursachen ungenauer Daten oder veränderter Anforderungen geben.

Warum das wichtig ist

Unterstützt den KPI „PO Modification Rate“ direkt und vereinfacht die Analyse instabiler Prozesse, indem alle geänderten Bestellungen gekennzeichnet werden.

Bezugsquelle

Berechnetes Feld. Wird auf „true“ gesetzt, wenn das Event Log eines Cases die Aktivität „Purchase Order Changed“ enthält, andernfalls auf „false“.

Beispiele
truefalse
Ist verspätete Lieferung
IsLateDelivery
Ein Kennzeichen dafür, dass der abschließende Wareneingang nach dem angeforderten Lieferdatum erfolgt ist.
Beschreibung

Dieses berechnete boolesche Attribut ist true, wenn der Timestamp der Aktivität „Goods Received“ nach dem Wert des Attributs „Requested Delivery Date“ für einen bestimmten Purchase Order liegt.

Das Kennzeichen bildet die Grundlage für den KPI „On-Time Delivery Rate“. Es ermöglicht die einfache Segmentierung und Analyse verspäteter und termingerechter Bestellungen. So lassen sich die Ursachen von Verzögerungen untersuchen, etwa im Zusammenhang mit bestimmten Vendoren, Standorten oder Produktkategorien.

Warum das wichtig ist

Unterstützt den KPI „On-Time Delivery Rate“ direkt und ermöglicht eine klare Analyse der Vendor-Leistung und Lieferzuverlässigkeit.

Bezugsquelle

Berechnetes Feld. Wird auf „true“ gesetzt, wenn der Timestamp der Aktivität „Goods Received“ nach dem Attribut „RequestedDeliveryDate“ liegt.

Beispiele
truefalse
Letzte Datenaktualisierung
LastDataUpdate
Der Zeitstempel, zu dem die Daten zuletzt aus dem Quellsystem extrahiert oder aktualisiert wurden.
Beschreibung

Dieses Attribut zeigt, wie aktuell die analysierten Daten sind. Es erfasst Datum und Uhrzeit des letzten Datenabrufs aus Oracle Fusion Financials.

Diese Information ist wichtig, damit Sie die Aktualität der Analyse und der Dashboards einschätzen können. Sie macht transparent, wie aktuell die Prozesserkenntnisse sind, und verdeutlicht, ob sehr neue Transaktionen bereits enthalten sind.

Warum das wichtig ist

Schafft Transparenz über die Aktualität der Daten und zeigt, wie aktuell die Prozessanalyse ist.

Bezugsquelle

Dieser Zeitstempel wird während des Datenextraktions- und Transformationsprozesses (ETL) erzeugt und hinzugefügt.

Beispiele
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
Lieferort
DeliveryLocation
Der physische Ort oder die Adresse, an den beziehungsweise an die die Waren geliefert werden sollen.
Beschreibung

Dieses Attribut gibt die Lieferadresse für die Positionen des Purchase Orders an. Es ist eine zentrale logistische Information.

Für Process Mining unterstützt die Analyse nach Lieferort das Dashboard „Goods Receipt Processing Efficiency“. Sie zeigt, ob bestimmte Lager oder Standorte ihren Wareneingang langsamer bearbeiten, und weist auf mögliche Ressourcen- oder Prozessprobleme an einzelnen Standorten hin.

Warum das wichtig ist

Ermöglicht die Leistungsanalyse nach geografischem Standort und hilft dabei, regionale oder standortspezifische Engpässe im Wareneingangsprozess zu erkennen.

Bezugsquelle

Verknüpft von PO_LINE_LOCATIONS_ALL.SHIP_TO_LOCATION_ID mit der Ansicht HR_LOCATIONS_ALL.

Beispiele
Hauptlager, Rampe AGebäude 3, EmpfangBüro San Francisco, 10. Stock
PO-Typ
PurchaseOrderType
Der Typ des Purchase Orders, beispielsweise „Standard“, „Blanket“ oder „Contract“.
Beschreibung

Dieses Attribut klassifiziert den Purchase Order nach seinem Beschaffungszweck. Für unterschiedliche PO-Typen gelten häufig verschiedene Prozessregeln und Lebenszyklen.

Ein „Standard“-PO ist ein einmaliger Einkauf, während ein „Blanket“-PO eine längerfristige Vereinbarung mit einem Lieferanten darstellt. Die Analyse nach PO-Typ ermöglicht eine präzisere Bewertung der Prozessleistung, da ein Vergleich der Durchlaufzeit eines Standard-PO mit einer Blanket-Vereinbarung irreführend wäre. So werden vergleichbare Vorgänge einander gegenübergestellt.

Warum das wichtig ist

Unterscheidet verschiedene Beschaffungsszenarien und ermöglicht präzisere Vergleiche der Prozessleistung zwischen gleichartigen Bestellungen.

Bezugsquelle

Oracle Fusion Cloud SCM, Tabelle PO_HEADERS_ALL, Spalte TYPE_LOOKUP_CODE.

Beispiele
STANDARDBLANKETCONTRACT
Quellsystem
SourceSystem
Das Informationssystem, aus dem diese Daten extrahiert wurden.
Beschreibung

Dieses Attribut identifiziert die Herkunft der Daten. Das ist besonders in Umgebungen mit mehreren integrierten Systemen hilfreich. Für diesen Prozess lautet der Wert typischerweise „Oracle Fusion Financials“.

Auch wenn es sich für einen bestimmten Datensatz häufig um einen statischen Wert handelt, ist das Attribut für Data Governance, Fehleranalyse und die Sicherstellung der Datenherkunft entscheidend. Bei Analysen, die Daten aus mehreren Quellen kombinieren, ermöglicht es die Filterung und Segmentierung nach dem Ursprungssystem.

Warum das wichtig ist

Identifiziert die Herkunft der Daten und ist damit entscheidend für Data Governance, Kontext und die Integration mit anderen Systemen.

Bezugsquelle

In der Regel handelt es sich um einen konstanten Wert, der während des Datenextraktions- und Transformationsprozesses (ETL) definiert und hinzugefügt wird.

Beispiele
Oracle Fusion FinancialsOracle Cloud SCMOracle Fusion P2P
Erforderlich Empfohlen Optional

Purchase to Pay - Purchase Order: Aktivitäten

Dies sind die wichtigsten Prozessschritte und Meilensteine, die Sie für eine präzise Ermittlung Ihres Purchase-to-Pay-Prozesses für Bestellungen im Event Log erfassen sollten.
6 Empfohlen 10 Optional
Aktivität Beschreibung
Bestellung an Lieferanten gesendet
Die genehmigte Bestellung wird dem Lieferanten offiziell übermittelt, beispielsweise per E-Mail oder EDI. Dieses Ereignis wird häufig aus einer Statusänderung oder einem Zeitstempel im Datensatz der Bestellkommunikation abgeleitet.
Warum das wichtig ist

Damit beginnt die Lieferzeit des Lieferanten. Dieser Zeitpunkt ist entscheidend, um die Lieferantenleistung von der Bestätigung bis zur endgültigen Lieferung zu messen.

Bezugsquelle

Das Ereignis lässt sich aus der Änderung des Bestelldokumentstatus in „Open“ und dem Eintragen eines Kommunikationsdatums ableiten. Das entsprechende Feld ist häufig PO_HEADERS_ALL.communicated_date oder ein verwandter Status.

Erfassen

Leiten Sie das Ereignis aus dem Zeitstempel ab, zu dem der Kommunikationsstatus der Bestellung auf „Communicated“ aktualisiert wird.

Ereignistyp inferred
Bestellung endgültig geschlossen
Die Bestellung gilt als abgeschlossen. Das bedeutet, dass sie vollständig empfangen und/oder fakturiert wurde und keine weiteren Aktivitäten erwartet werden. Diese explizite Aktion setzt einen Endstatus für die Bestellung.
Warum das wichtig ist

Diese Aktivität markiert den erfolgreichen Abschluss des Lebenszyklus einer Bestellung. Sie stellt den wichtigsten positiven Endstatus dar. Ihre Überwachung ist entscheidend, um den gesamten Prozessdurchsatz und die Abschlussquoten zu messen.

Bezugsquelle

Dieses Ereignis wird in der Tabelle PO_ACTION_HISTORY mit dem ACTION_CODE „FINALLY CLOSE“ aufgezeichnet. Der Bestellstatus in PO_HEADERS_ALL wird ebenfalls auf „Finally Closed“ aktualisiert.

Erfassen

Filtern Sie PO_ACTION_HISTORY nach ACTION_CODE = „FINALLY CLOSE“.

Ereignistyp explicit
Bestellung erstellt
Dies ist der offizielle Beginn des Lebenszyklus einer Bestellung. Dabei wird ein Bestelldokument mit dem Status „Entwurf“ oder „Unvollständig“ erzeugt. Das System erfasst dieses Ereignis über den Erstellungszeitstempel des neuen Datensatzes in der Bestellüberschrift.
Warum das wichtig ist

Als primäres Start-Ereignis des Bestellungs-Cases bildet diese Aktivität die Grundlage für alle Berechnungen der Durchlaufzeit. Sie dient als Ausgangspunkt, um die Effizienz nachfolgender Schritte wie Genehmigung und Lieferantenkommunikation zu messen.

Bezugsquelle

Dies ist ein explizites Ereignis auf Grundlage des Feldes CREATION_DATE in der Tabelle PO_HEADERS_ALL für eine bestimmte Bestell-ID (PO_HEADER_ID).

Erfassen

Verwenden Sie den Erstellungszeitstempel aus der Tabelle PO_HEADERS_ALL.

Ereignistyp explicit
Bestellung genehmigt
Die Bestellung hat alle erforderlichen Genehmigungen erhalten und ist nun zur Übermittlung an den Lieferanten freigegeben. Dieser wichtige Meilenstein wird ausdrücklich in der Aktionshistorie des Dokuments protokolliert.
Warum das wichtig ist

Dies ist ein entscheidender Meilenstein, der bestimmt, ob die Bestellung an den Lieferanten gesendet werden darf. Er ist wichtig, um Genehmigungszeiten zu messen und die Einhaltung von Ausgabenrichtlinien sicherzustellen.

Bezugsquelle

Dieses Ereignis wird in der Tabelle PO_ACTION_HISTORY aufgezeichnet, in der Regel mit einem ACTION_CODE von „APPROVE“ oder wenn sich der Dokumentstatus in PO_HEADERS_ALL in einen genehmigten Status ändert.

Erfassen

Filtern Sie PO_ACTION_HISTORY nach der abschließenden Aktion „APPROVE“.

Ereignistyp explicit
Bestellung storniert
Die Bestellung wurde endgültig storniert, weitere Transaktionen werden nicht erwartet. Diese explizite Aktion ändert den Endstatus des Dokuments.
Warum das wichtig ist

Diese Aktivität stellt einen negativen Endstatus des Prozesses dar. Die Analyse von Stornierungen kann Probleme wie doppelte Bestellungen, Budgetänderungen oder veränderte Projektanforderungen sichtbar machen.

Bezugsquelle

Diese Aktion wird in der Tabelle PO_ACTION_HISTORY mit dem ACTION_CODE „CANCEL“ aufgezeichnet. Der Bestellstatus in PO_HEADERS_ALL wird entsprechend aktualisiert.

Erfassen

Filtern Sie PO_ACTION_HISTORY nach ACTION_CODE = „CANCEL“.

Ereignistyp explicit
Waren eingegangen
Die Waren wurden physisch empfangen, gezählt und gegen die Bestellung gebucht. Dieses Transaktionsereignis aktualisiert den Bestand und den Status der Bestellung.
Warum das wichtig ist

Dies ist ein wichtiger Meilenstein zur Messung der Liefertermintreue und der gesamten Lieferzeit. Außerdem löst er nachfolgende Aktivitäten wie Qualitätsprüfung und Rechnungsabgleich aus.

Bezugsquelle

Dies ist ein explizites Ereignis in der Tabelle RCV_TRANSACTIONS. Die entsprechende Transaktion lässt sich über TRANSACTION_TYPE = „RECEIVE“ ermitteln.

Erfassen

Verwenden Sie TRANSACTION_DATE aus RCV_TRANSACTIONS, wenn TRANSACTION_TYPE „RECEIVE“ lautet.

Ereignistyp explicit
Bestellanforderung erstellt
Diese Aktivität kennzeichnet die Erstellung einer Bestellanforderung. Dabei handelt es sich um die formelle Anforderung von Waren oder Dienstleistungen, die einer Bestellung vorausgeht. Das Ereignis wird erfasst, sobald in Oracle Fusion ein neuer Eintrag in der Tabelle für die Anforderungsüberschrift erstellt wird.
Warum das wichtig ist

Die Analyse dieser Aktivität hilft dabei, die Entstehung des Bedarfs zu verstehen. Die Messung der Zeit von der Bestellanforderung bis zur Erstellung der Bestellung zeigt mögliche Verzögerungen bei der Umwandlung des internen Bedarfs in umsetzbare Beschaffungsaufträge.

Bezugsquelle

Dies ist ein explizites Ereignis, das beim Speichern einer neuen Bestellanforderung aufgezeichnet wird. Es lässt sich über den Erstellungszeitstempel in der Tabelle POR_REQUISITION_HEADERS_ALL ermitteln.

Erfassen

Das Ereignis basiert auf dem Erstellungsdatum des Datensatzes in der Tabelle POR_REQUISITION_HEADERS_ALL.

Ereignistyp explicit
Bestellanforderung genehmigt
Die zuständige Stelle hat die Bestellanforderung genehmigt und damit die Beschaffungsabteilung zur Erstellung einer Bestellung autorisiert. Dieses Ereignis wird ausdrücklich in der Aktionshistorie der Bestellanforderung protokolliert.
Warum das wichtig ist

Dieser Meilenstein markiert das Ende des internen Genehmigungsprozesses für die Anforderung. Verzögerungen an dieser Stelle können sich direkt auf den gesamten Beschaffungszeitplan auswirken. Deshalb ist die Überwachung der Dauer besonders wichtig.

Bezugsquelle

Dieses Ereignis wird in der mit der Bestellanforderung verknüpften Aktionshistorie aufgezeichnet, in der Regel über Workflow-Tabellen oder spezielle Genehmigungsstatusfelder im Anforderungsdokument.

Erfassen

Als Genehmigungsaktion im Workflow-Verlauf des jeweiligen Anforderungsdokuments protokolliert.

Ereignistyp explicit
Bestellung abgelehnt
Eine genehmigende Person hat die Bestellung abgelehnt und zur Überarbeitung an die erstellende Person zurückgesendet. Dieses explizite Ereignis wird in der Aktionshistorie protokolliert und zeigt eine Unterbrechung des standardmäßigen Prozessablaufs an.
Warum das wichtig ist

Ablehnungen führen zu Nacharbeit und Verzögerungen. Die Analyse dieser Aktivität hilft dabei, häufige Ablehnungsgründe, Schulungsbedarf oder unklare Genehmigungsanforderungen zu erkennen.

Bezugsquelle

Diese Aktion wird in der Tabelle PO_ACTION_HISTORY mit dem ACTION_CODE „REJECT“ für die entsprechende PO_HEADER_ID aufgezeichnet.

Erfassen

Filtern Sie PO_ACTION_HISTORY nach ACTION_CODE = „REJECT“.

Ereignistyp explicit
Bestellung bestätigt
Der Lieferant hat den Erhalt und die Annahme der Bestellbedingungen bestätigt. Dieses Ereignis wird häufig manuell durch Mitarbeitende im Einkauf auf Grundlage der Lieferantenkommunikation oder über eine elektronische Bestätigung erfasst.
Warum das wichtig ist

Die Bestätigung des Lieferanten schafft Sicherheit darüber, dass die Bestellung eingegangen ist und bearbeitet wird. Die Überwachung dieses Ereignisses unterstützt die Lieferantenkommunikation und hilft, mögliche Probleme bei der Auftragserfüllung frühzeitig zu erkennen.

Bezugsquelle

Das Ereignis wird in der Regel aus einer Änderung der Bestätigungsstatusfelder in der Bestellüberschrift oder den Bestellpositionen abgeleitet, beispielsweise wenn sich PO_HEADERS_ALL.acceptance_status in „Accepted“ ändert.

Erfassen

Leiten Sie das Ereignis aus Aktualisierungen der Statusfelder für die Bestellbestätigung ab.

Ereignistyp inferred
Bestellung eingereicht
Die erstellte Bestellung wird in den Genehmigungs-Workflow übermittelt. Oracle Fusion protokolliert diese Aktion ausdrücklich und erfasst den Benutzer sowie den Zeitstempel des Übermittlungsereignisses.
Warum das wichtig ist

Diese Aktivität markiert den Beginn des Genehmigungszyklus. Die Analyse der Zeit zwischen Übermittlung und Genehmigung ist entscheidend, um Engpässe im internen Freigabeprozess zu erkennen.

Bezugsquelle

Diese Aktion wird in der Tabelle PO_ACTION_HISTORY mit dem ACTION_CODE „SUBMIT“ für die entsprechende PO_HEADER_ID aufgezeichnet.

Erfassen

Filtern Sie PO_ACTION_HISTORY nach ACTION_CODE = „SUBMIT“.

Ereignistyp explicit
Bestellung geändert
Nach der ursprünglichen Genehmigung wurde die Bestellung geändert, beispielsweise hinsichtlich Menge, Preis oder Lieferdatum. Oracle Fusion erfasst dies durch die Erstellung einer neuen Dokumentrevision.
Warum das wichtig ist

Änderungen an Bestellungen stellen Nacharbeit dar und können auf Probleme bei der ursprünglichen Bestellgenauigkeit oder auf veränderte Geschäftsanforderungen hinweisen. Die Analyse von Häufigkeit und Art dieser Änderungen zeigt Möglichkeiten zur Verbesserung der Prozesseffizienz auf.

Bezugsquelle

Dieses Ereignis wird ausdrücklich erfasst, sobald eine neue Dokumentrevision erstellt wird. Es lässt sich an einer Erhöhung des Feldes REVISION_NUM in der Tabelle PO_HEADERS_ALL erkennen.

Erfassen

Ermitteln Sie jede Instanz, in der sich REVISION_NUM für eine PO_HEADER_ID erhöht.

Ereignistyp explicit
Erbrachte Dienstleistungen bestätigt
Bei dienstleistungsbezogenen Bestellungen bestätigt diese Aktivität, dass die vereinbarten Leistungen erbracht wurden. Die Bestätigung wird häufig manuell oder über einen Leistungserfassungsschein erfasst.
Warum das wichtig ist

Dies entspricht einem Wareneingang bei Dienstleistungen und ist ein entscheidender Schritt, bevor eine Rechnung bezahlt werden kann. Verzögerungen bei der Leistungsbestätigung können zu verspäteten Zahlungen und belasteten Lieferantenbeziehungen führen.

Bezugsquelle

Das Ereignis wird in der Regel als Wareneingang zu einer Dienstleistungsposition der Bestellung erfasst. Dabei können spezielle Felder oder komplexe Wareneingänge zum Einsatz kommen, die den Fortschritt oder den Abschluss der Leistungen dokumentieren.

Erfassen

Ermitteln Sie Wareneingangstransaktionen (RCV_TRANSACTIONS), die mit dienstleistungsbezogenen Bestellpositionen verknüpft sind.

Ereignistyp explicit
Qualitätsprüfung durchgeführt
Waren, für die eine Qualitätskontrolle erforderlich ist, wurden geprüft und entweder angenommen oder abgelehnt. Diese Aktivität findet nach dem ersten Wareneingang statt und wird als separate Transaktion erfasst.
Warum das wichtig ist

Diese Aktivität ist für das Qualitätsmanagement entscheidend. Die Analyse der Prüfungsdauer hilft, den Qualitätskontrollprozess zu optimieren und Verzögerungen bei der Bereitstellung der Waren zu verringern.

Bezugsquelle

Das Ereignis wird in der Tabelle RCV_TRANSACTIONS erfasst. Es wird durch Transaktionen mit TRANSACTION_TYPE „ACCEPT“ oder „REJECT“ identifiziert, die auf eine Wareneingangstransaktion folgen.

Erfassen

Verwenden Sie TRANSACTION_DATE aus RCV_TRANSACTIONS, wenn TRANSACTION_TYPE „ACCEPT“ oder „REJECT“ lautet.

Ereignistyp explicit
Waren an Lieferanten zurückgesendet
Zuvor eingegangene Waren werden an den Lieferanten zurückgesendet, meist aufgrund von Mängeln, Beschädigungen oder einer falschen Lieferung. Dies wird als spezielle Rücksendetransaktion im Wareneingangsmodul erfasst.
Warum das wichtig ist

Die Überwachung von Rücksendungen ist entscheidend, um Lieferantenqualität und Bestellgenauigkeit zu bewerten. Hohe Rücksendequoten bei einem Lieferanten können auf systematische Probleme hinweisen, die behoben werden müssen.

Bezugsquelle

Dies ist ein explizites Ereignis in der Tabelle RCV_TRANSACTIONS mit TRANSACTION_TYPE „RETURN TO VENDOR“.

Erfassen

Verwenden Sie TRANSACTION_DATE aus RCV_TRANSACTIONS, wenn TRANSACTION_TYPE „RETURN TO VENDOR“ lautet.

Ereignistyp explicit
Wareneingang erstellt
Im System wird ein Wareneingangsdokument zur Vorbereitung auf die physische Ankunft der Waren angelegt. Diese Aktivität kennzeichnet den Beginn des internen Wareneingangsprozesses.
Warum das wichtig ist

Damit wechselt der Prozess von der Beschaffung in die Logistik. Die Analyse der Zeit von diesem Zeitpunkt bis zur endgültigen Buchung des Wareneingangs hilft, Ineffizienzen im Lager oder im Wareneingang zu erkennen.

Bezugsquelle

Dies ist ein explizites Ereignis, das über den Erstellungszeitstempel eines neuen, mit der Bestellung verknüpften Datensatzes in der Tabelle RCV_SHIPMENT_HEADERS erfasst wird.

Erfassen

Verwenden Sie das Erstellungsdatum des entsprechenden Datensatzes in RCV_SHIPMENT_HEADERS.

Ereignistyp explicit
Empfohlen Optional

Anleitungen zur Datenextraktion

So erhalten Sie Ihre Daten aus Oracle Fusion Financials

Möchten Sie jetzt starten?

Verwenden Sie dieses Template, um Ihre Datenerfassung zu vereinfachen und Erkenntnisse über Ihren Purchase-to-Pay-Prozess für Purchase Orders zu gewinnen. Beginnen Sie noch heute mit der Optimierung Ihrer Abläufe.

Optimieren Sie Ihren Purchase-to-Pay-Prozess für Purchase Orders noch heute

Erkennen Sie kostspielige Engpässe und verkürzen Sie die Durchlaufzeit einfach um 30 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich. Starten Sie noch heute mit der Optimierung.