Ihr Daten-Template für Purchase to Pay, Purchase Order
Ihr Daten-Template für Purchase to Pay, Purchase Order
- Empfohlene Attribute für eine umfassende Datenerfassung
- Wichtige Prozessaktivitäten zur Erfassung und Analyse
- Schrittweise Anleitung zur Datenextraktion aus Oracle Fusion Financials
Purchase to Pay - Purchase Order: Attribute
| 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
|
|||
Purchase to Pay - Purchase Order: Aktivitäten
| 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
|
|||
Anleitungen zur Datenextraktion
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 %.
Keine Kreditkarte erforderlich. Starten Sie noch heute mit der Optimierung.