Ihr Daten-Template für die Auftragsabwicklung im Vertrieb im Order-to-Cash-Prozess
Ihr Daten-Template für die Auftragsabwicklung im Vertrieb im Order-to-Cash-Prozess
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten für die Analyse
- Hinweise zur Datenextraktion
Attribute für die Auftragsabwicklung im Vertrieb im Order-to-Cash-Prozess
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivitätsname
ActivityName
|
Der Name eines bestimmten Geschäftsereignisses oder Prozessschritts im Lebenszyklus eines Kundenauftrags. | ||
|
Beschreibung
Dieses Attribut erfasst den Namen jeder Aktivität, die für einen Kundenauftrag ausgeführt wurde, zum Beispiel 'Auftrag gebucht', 'Ware versandt' oder 'Zahlung eingegangen'. Diese Aktivitäten markieren wichtige Meilensteine im Order-to-Cash-Prozess. Die Abfolge und Häufigkeit dieser Aktivitäten zu analysieren, ist der Kern des Process Mining. So lassen sich die tatsächlichen Prozessabläufe ermitteln, einschließlich typischer Pfade, Abweichungen und Engpässe. Auf Grundlage dieser Daten wird die Prozesslandkarte erstellt, die als zentrale Visualisierung für die Prozessanalyse dient.
Warum das wichtig ist
Legt die Schritte in der Prozesslandkarte fest und ist damit wesentlich für die Visualisierung und Analyse des Prozessflusses.
Woher beziehen
Dies ist ein konzeptionelles Feld, das aus verschiedenen Events, Statusangaben und Transaktionsdaten aus Quellsystemen abgeleitet wird, etwa aus den Modulen Order Management, Shipping Execution und Accounts Receivable.
Beispiele
Kundenauftrag erstelltWare versandtRechnung erstelltZahlung eingegangen
|
|||
|
Eventzeitpunkt
EventTime
|
Der Timestamp, der angibt, wann eine bestimmte Aktivität stattgefunden hat. | ||
|
Beschreibung
Der Eventzeitpunkt beziehungsweise Timestamp erfasst Datum und Uhrzeit, zu denen eine Aktivität ausgeführt wurde. Er hält beispielsweise fest, wann ein Auftrag erstellt, eine Rechnung versandt oder eine Zahlung empfangen wurde. Diese Zeitdaten sind eine wesentliche Grundlage für Process Mining. Mit diesem Attribut werden die Events für jeden Case chronologisch sortiert. Das ist notwendig, um den Prozessfluss korrekt zu rekonstruieren. Außerdem bildet es die Grundlage für alle Berechnungen von Dauer und Leistung, etwa für Zykluszeiten zwischen Aktivitäten, die Gesamtdauer eines Cases sowie die Ermittlung von Verzögerungen und Engpässen.
Warum das wichtig ist
Liefert die chronologische Abfolge der Events und bildet die Grundlage für alle zeitbezogenen Leistungsanalysen, einschließlich der Zykluszeit und der Ermittlung von Engpässen.
Woher beziehen
Stammt aus verschiedenen Datumsfeldern in Oracle-EBS-Tabellen, zum Beispiel CREATION_DATE in OE_ORDER_HEADERS_ALL, ACTUAL_SHIPMENT_DATE in WSH_DELIVERY_DETAILS oder TRX_DATE in RA_CUSTOMER_TRX_ALL.
Beispiele
2023-04-15T10:30:00Z2023-04-18T14:00:00Z2023-05-01T09:15:00Z
|
|||
|
Kundenauftrag
SalesOrder
|
Die eindeutige Kennung des Kundenauftrags. Sie dient als zentraler Case für den Order-to-Cash-Prozess. | ||
|
Beschreibung
Die Kundenauftragsnummer identifiziert jeden Kundenauftrag während seines gesamten Lebenszyklus eindeutig, von der Erstellung bis zum endgültigen Abschluss. Sie bildet den zentralen Bezugspunkt für alle zugehörigen Aktivitäten, etwa Buchung, Versand, Rechnungsstellung und Zahlung. Im Process Mining ist dieses Attribut unverzichtbar, um den durchgängigen Ablauf jedes Auftrags zu rekonstruieren. Wenn alle Events unter einer Kundenauftragsnummer zusammengefasst werden, können Analysten den vollständigen Prozessfluss visualisieren, Unterschiede zwischen Aufträgen erkennen und wichtige Kennzahlen wie Zykluszeit und termingerechte Lieferung für einzelne Cases messen.
Warum das wichtig ist
Dies ist die Case-ID, über die alle Prozess-Events miteinander verknüpft werden, um den gesamten Auftragslebenszyklus zu analysieren.
Woher beziehen
Der Primärschlüssel eines Kundenauftrags, üblicherweise in Oracle-Order-Management-Tabellen wie OE_ORDER_HEADERS_ALL.HEADER_ID zu finden.
Beispiele
685127103482459
|
|||
|
Auftragsstatus
OrderStatus
|
Der aktuelle oder historische Status des Kundenauftrags oder der Auftragsposition. | ||
|
Beschreibung
Dieses Attribut erfasst den Status eines Kundenauftrags zu verschiedenen Zeitpunkten, zum Beispiel 'Erfasst', 'Gebucht', 'Geschlossen' oder 'Storniert'. Statusangaben entsprechen häufig direkt den Prozessaktivitäten. Der Auftragsstatus ist wichtig für Dashboards, die den aktuellen Status aller offenen Aufträge anzeigen. So können Führungskräfte die Auftragspipeline überwachen, ins Stocken geratene Aufträge erkennen und Ausnahmen frühzeitig bearbeiten. Statusübergänge werden häufig verwendet, um Aktivitäten für die Prozesslandkarte zu definieren.
Warum das wichtig ist
Macht die Auftragspipeline transparent und hilft dabei, ins Stocken geratene Aufträge zu erkennen und Prozessausnahmen zu bearbeiten.
Woher beziehen
Üblicherweise in der Spalte FLOW_STATUS_CODE der Tabellen OE_ORDER_HEADERS_ALL und OE_ORDER_LINES_ALL zu finden.
Beispiele
GEBUCHTWARTET_AUF_VERSANDVERSANDTGESCHLOSSENSTORNIERT
|
|||
|
Benutzername
UserName
|
Der Benutzer, der die Aktivität ausgeführt hat. | ||
|
Beschreibung
Gibt an, welcher Benutzer für einen bestimmten Prozessschritt verantwortlich war. Das kann beispielsweise der Vertriebsmitarbeiter sein, der den Auftrag angelegt hat, der Kreditanalyst, der die Bonitätsprüfung durchgeführt hat, oder der Sachbearbeiter, der die Rechnung erstellt hat. Die Analyse von Aktivitäten nach Benutzer hilft dabei, Schulungsbedarf, besonders leistungsstarke Mitarbeitende oder Teams sowie die Arbeitsverteilung zu erkennen. Sie ist auch für Compliance-Prüfungen und die Analyse von Audit-Trails wichtig, etwa um nicht autorisierte Aktionen zu untersuchen oder Nacharbeitsmuster bestimmter Benutzer zu verstehen.
Warum das wichtig ist
Ermöglicht die Analyse der Benutzerleistung, der Arbeitsverteilung und der Einhaltung von Compliance-Vorgaben. Damit lässt sich die Frage beantworten, wer eine Aktion ausgeführt hat.
Woher beziehen
Stammt aus benutzerbezogenen Feldern wie CREATED_BY oder LAST_UPDATED_BY in verschiedenen Oracle-EBS-Tabellen. Häufig ist eine Verknüpfung mit FND_USER erforderlich, um den vollständigen Benutzernamen abzurufen.
Beispiele
JSMITHRWILLIAMSCDAVIS
|
|||
|
Bestätigter Liefertermin
ConfirmedDeliveryDate
|
Der zugesagte Termin, zu dem die Ware voraussichtlich beim Kunden eintrifft. | ||
|
Beschreibung
Dieses Attribut enthält den Liefertermin, der dem Kunden zugesagt oder bestätigt wurde. Er dient als Zielwert für die Messung der termingerechten Lieferung. Im Process Mining wird dieser Termin mit dem tatsächlichen Lieferzeitpunkt aus der Aktivität 'Ware geliefert' verglichen, um die KPI 'Quote termingerechter Lieferungen' zu berechnen. Abweichungen helfen, systematische Probleme in der Logistik, Bestandsverwaltung oder Produktionsplanung zu erkennen, die zu Lieferverzögerungen führen.
Warum das wichtig ist
Dient als Grundlage für die Messung termingerechter Lieferungen, einer wichtigen KPI für die Kundenzufriedenheit und die operative Leistung.
Woher beziehen
Dieser Termin ist üblicherweise in den Feldern LATEST_ACCEPTABLE_DATE oder REQUEST_DATE auf Positionsebene in der Tabelle OE_ORDER_LINES_ALL zu finden.
Beispiele
2023-05-102023-06-012023-07-20
|
|||
|
Fälligkeitsdatum der Zahlung
PaymentDueDate
|
Das berechnete Datum, bis zu dem der Kunde die Rechnung bezahlen muss. | ||
|
Beschreibung
Das Fälligkeitsdatum der Zahlung ist der konkrete Kalendertag, an dem eine Rechnung bezahlt werden muss. Es wird anhand des Rechnungsdatums und der vereinbarten Zahlungsbedingungen berechnet und ist der Zieltermin für die Aktivität 'Zahlung eingegangen'. Dieses Attribut ist unverzichtbar, um die KPI 'Einhaltungsquote der Zahlungsbedingungen' zu berechnen, indem es mit dem tatsächlichen Zahlungsdatum verglichen wird. Die Analyse von Abweichungen hilft dem Forderungsmanagement, Maßnahmen zu priorisieren, Kunden mit regelmäßig verspäteten Zahlungen zu erkennen und die Wirksamkeit des Mahnprozesses zu messen.
Warum das wichtig ist
Dient als Zieltermin für den Zahlungseingang und ermöglicht die Messung der Zahlungspünktlichkeit sowie der Einhaltung der vereinbarten Bedingungen durch den Kunden.
Woher beziehen
Befindet sich im Feld DUE_DATE der Tabelle AR_PAYMENT_SCHEDULES_ALL, die mit der Rechnungstransaktion verknüpft ist.
Beispiele
2023-06-152023-07-012023-08-30
|
|||
|
Gesamtauftragswert
TotalOrderAmount
|
Der Gesamtwert des Kundenauftrags. | ||
|
Beschreibung
Dieses Attribut gibt den Gesamtwert aller Positionen eines Kundenauftrags in der Transaktionswährung an. Es ist eine wichtige Finanzkennzahl für jeden Case. Die Analyse von Prozesskennzahlen nach Auftragswert hilft, Verbesserungsmaßnahmen zu priorisieren. Analysten können beispielsweise untersuchen, ob bei Aufträgen mit hohem Wert häufiger Verzögerungen oder Nacharbeiten auftreten als bei Aufträgen mit geringem Wert. Außerdem lässt sich die finanzielle Auswirkung bewerten, etwa indem der Wert der Aufträge ermittelt wird, die an einem bestimmten Engpass feststecken.
Warum das wichtig ist
Ermöglicht die finanzielle Analyse des Prozesses. So lassen sich Aufträge mit hohem Wert priorisieren und die finanziellen Auswirkungen von Ineffizienzen beziffern.
Woher beziehen
Dieser Wert wird üblicherweise berechnet, indem die Positionsbeträge eines Auftrags summiert werden. Die Positionsbeträge sind in Tabellen wie OE_ORDER_LINES_ALL zu finden.
Beispiele
5450.00125000.75980.50
|
|||
|
Kundenname
CustomerName
|
Der Name des Kunden, der den Kundenauftrag erteilt hat. | ||
|
Beschreibung
Dieses Attribut gibt den offiziellen Namen des Kunden an, der mit dem Kundenauftrag verknüpft ist. Es ist eine zentrale Dimension für die Segmentierung und Analyse der Prozessleistung. Wenn Analysten den Prozess nach Kunden filtern oder aufschlüsseln, können sie feststellen, bei welchen Kunden die Zykluszeiten am längsten sind, die meisten Nacharbeiten auftreten oder Zahlungsverzögerungen besonders häufig vorkommen. Diese Erkenntnisse helfen, Kundenbeziehungen zu verbessern, Servicelevel anzupassen und das Kundenverhalten besser zu verstehen.
Warum das wichtig ist
Ermöglicht eine kundenbezogene Analyse, mit der sich Leistungsunterschiede erkennen, der Service verbessern und Zahlungsverhalten verschiedener Kunden nachvollziehen lassen.
Woher beziehen
Wird abgeleitet, indem SOLD_TO_ORG_ID aus OE_ORDER_HEADERS_ALL mit den Tabellen HZ_CUST_ACCOUNTS und HZ_PARTIES verknüpft wird, um den Namen der Partei abzurufen.
Beispiele
Global Tech Inc.Innovate Solutions LLCPioneer Corp
|
|||
|
Zahlungsbedingungen
PaymentTerms
|
Die vereinbarten Bedingungen, die festlegen, wann der Kunde die Waren oder Dienstleistungen bezahlen soll. | ||
|
Beschreibung
Die Zahlungsbedingungen legen fest, wann eine Rechnung zu begleichen ist, zum Beispiel 'Netto 30', 'Netto 60' oder 'zahlbar bei Erhalt'. Dieses Attribut ist für die Verwaltung von Forderungen und des Cashflows wesentlich. Die Analyse der Prozessleistung nach Zahlungsbedingungen zeigt, ob Kunden mit bestimmten Bedingungen häufiger verspätet zahlen. Diese Informationen helfen, finanzielle Risiken einzuschätzen, das Forderungsmanagement zu optimieren und verschiedene Zahlungsangebote zu bewerten. Sie sind eine wichtige Dimension im Dashboard 'Überwachung der Einhaltung von Zahlungsbedingungen'.
Warum das wichtig ist
Wichtig für die Analyse des Zahlungsverhaltens, die Überwachung des Cashflows und die Bewertung der finanziellen Risiken, die mit verschiedenen Kundenvereinbarungen verbunden sind.
Woher beziehen
Zu finden in der Tabelle RA_TERMS, verknüpft über TERM_ID in Tabellen wie RA_CUSTOMER_TRX_ALL (für Rechnungen) oder OE_ORDER_HEADERS_ALL (für Aufträge).
Beispiele
Netto 30Netto 60Zahlbar bei Erhalt
|
|||
|
Bestellmenge
OrderQuantity
|
Die Menge des Produkts, die in einer bestimmten Auftragsposition bestellt wurde. | ||
|
Beschreibung
Dieses Attribut gibt an, wie viele Einheiten eines bestimmten Produkts der Kunde in einer Auftragsposition bestellt hat. Es beschreibt den Umfang der Transaktion auf Positionsebene. Die Bestellmenge kann als Analysedimension dienen, um festzustellen, ob sich der Prozessablauf je nach Auftragsgröße unterscheidet. Sehr große oder sehr kleine Aufträge können beispielsweise andere Prozesspfade durchlaufen oder von anderen Verzögerungen betroffen sein. Außerdem liefert die Menge Kontext für weitere Kennzahlen wie den Auftragswert.
Warum das wichtig ist
Zeigt den Umfang eines Auftrags und ermöglicht die Analyse, wie sich das Auftragsvolumen auf die Prozesseffizienz und die Abwicklung auswirkt.
Woher beziehen
Zu finden im Feld ORDERED_QUANTITY der Tabelle OE_ORDER_LINES_ALL.
Beispiele
102501
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp der letzten Aktualisierung der Daten aus dem Quellsystem. | ||
|
Beschreibung
Dieses Attribut gibt an, wann die Daten zuletzt aus Oracle E-Business Suite extrahiert und in das Process-Mining-Tool geladen wurden. Es zeigt, wie aktuell die analysierten Daten sind. So können Benutzer einschätzen, wie aktuell die angezeigten Erkenntnisse sind. Sie sehen, ob sie Echtzeitinformationen oder einen Datenstand von einem bestimmten Zeitpunkt betrachten. Das ist wichtig für operative Entscheidungen.
Warum das wichtig ist
Informiert Benutzer über die Aktualität der Daten. Das ist entscheidend, um den Analyseergebnissen zu vertrauen und rechtzeitig Entscheidungen zu treffen.
Woher beziehen
Dieser Timestamp wird während des ETL-Prozesses (Extraktion, Transformation und Laden) erzeugt und hinzugefügt.
Beispiele
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Nacharbeit
IsRework
|
Kennzeichnet, ob bei einem Kundenauftrag Nacharbeit angefallen ist, etwa durch wiederholte Bestätigungs- oder Aktualisierungsaktivitäten. | ||
|
Beschreibung
Dieses berechnete boolesche Attribut kennzeichnet Cases mit Mustern, die auf Nacharbeit hindeuten. Nacharbeit lässt sich anhand von Schleifen in der Prozesslandkarte erkennen, etwa wenn ein Auftrag mehrfach gebucht wird, oder anhand bestimmter im System protokollierter Änderungs-Events. Das Kennzeichen dient zur Berechnung der KPI 'Nacharbeitsquote bei Kundenaufträgen' und als Grundlage für das Dashboard 'Nacharbeitsanalyse bei Kundenaufträgen'. Analysten können damit Aufträge, die vom Standardprozess abweichen, gezielt untersuchen. So lassen sich die Auswirkungen der Nacharbeit auf Zykluszeiten und Kosten beziffern und die Ursachen ineffizienter Schleifen ermitteln.
Warum das wichtig ist
Hilft, Ineffizienzen zu beziffern, indem Aufträge mit erforderlichen manuellen Änderungen gekennzeichnet werden. So lassen sich Ursachen und Auswirkungen der Nacharbeit analysieren.
Woher beziehen
Wird während der Datentransformation berechnet, indem Aktivitätsfolgen erkannt werden, die eine Schleife bilden, zum Beispiel wenn 'Auftrag gebucht' für denselben Case mehrfach auftritt.
Beispiele
truefalse
|
|||
|
Produktnummer
ProductNumber
|
Die eindeutige Kennung des Produkts oder Artikels in der Auftragsposition. | ||
|
Beschreibung
Dieses Attribut identifiziert das verkaufte Material, den Artikel oder die Dienstleistung. Es ermöglicht Analysen auf einer detaillierteren Ebene als der Auftragskopf. Die Analyse nach Produkt hilft, produktspezifische Probleme aufzudecken. Bei bestimmten Produkten kann die Auftragsabwicklung beispielsweise wegen komplexer Fertigung oder Beschaffung länger dauern. Andere Produkte können häufiger mit Versandfehlern oder Kundenreklamationen verbunden sein. So lassen sich gezielte Verbesserungen in der Lieferkette und im Produktmanagement umsetzen.
Warum das wichtig ist
Ermöglicht Analysen auf Produktebene, um Artikel zu erkennen, die Prozessverzögerungen, Nacharbeit oder andere Ineffizienzen verursachen.
Woher beziehen
Wird aus INVENTORY_ITEM_ID in der Tabelle OE_ORDER_LINES_ALL abgeleitet. Über eine Verknüpfung mit MTL_SYSTEM_ITEMS_B lassen sich die Artikelnummer oder die Beschreibung abrufen.
Beispiele
AS54888CM15001SV20100
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem die Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut gibt an, aus welchem Informationssystem die Event-Daten stammen. Für diesen Prozess lautet der Wert immer 'Oracle E-Business Suite'. In Umgebungen mit mehreren Systemen ist dieses Feld für die Datenherkunft und die Fehlerbehebung entscheidend. Auch bei nur einem System liefert es wichtigen Kontext zum Datenmodell und unterstützt die Standardisierung der Datenübernahme.
Warum das wichtig ist
Liefert wichtigen Kontext zur Herkunft der Daten und gewährleistet ihre Rückverfolgbarkeit und korrekte Interpretation, insbesondere in Umgebungen mit mehreren Systemen.
Woher beziehen
In der Regel wird während des ETL-Prozesses (Extraktion, Transformation und Laden) ein statischer Wert hinzugefügt, der die Herkunft der Daten kennzeichnet.
Beispiele
Oracle E-Business SuiteOracle EBS R12
|
|||
|
Stornierungsgrund
CancellationReason
|
Der dokumentierte Grund für die Stornierung eines Kundenauftrags oder einer Auftragsposition. | ||
|
Beschreibung
Wird ein Kundenauftrag storniert, erfasst dieses Attribut den angegebenen Stornierungsgrund. Mögliche Gründe sind beispielsweise 'Kundenwunsch', 'Nicht auf Lager' oder 'Kreditsperre'. Diese Daten sind für die Ursachenanalyse von Auftragsstornierungen wichtig. Das Dashboard 'Stornierungsquote und -gründe für Kundenaufträge' verwendet dieses Attribut, um die Hauptursachen für Stornierungen zu ermitteln. So kann das Unternehmen gezielte Maßnahmen ergreifen, um Kundenabwanderung zu verringern, die Bestandsplanung zu verbessern oder Kreditrichtlinien anzupassen.
Warum das wichtig ist
Zeigt direkt, warum Aufträge storniert werden. Die Ursachenanalyse hilft, Umsatzverluste zu verringern und Kunden zu halten.
Woher beziehen
Diese Information wird häufig in einem Grundcodefeld wie CANCELLED_REASON gespeichert. Das Feld kann in OE_ORDER_LINES_ALL oder einer zugehörigen Tabelle für Auftragsänderungen verfügbar sein.
Beispiele
Artikel aus dem Sortiment genommenKunde hat storniertDoppelter Auftrag
|
|||
|
Termingerecht geliefert
IsOnTimeDelivery
|
Kennzeichnet, ob der Auftrag am bestätigten Liefertermin oder früher zugestellt wurde. | ||
|
Beschreibung
Dieses berechnete Attribut ist ein boolesches Kennzeichen (Wahr/Falsch), das angibt, ob ein Auftrag zum zugesagten Termin geliefert wurde. Es wird ermittelt, indem der Timestamp der Aktivität 'Ware geliefert' mit dem 'Bestätigten Liefertermin' verglichen wird. Dieses Attribut unterstützt direkt die KPI 'Quote termingerechter Lieferungen'. Es vereinfacht Analysen und die Erstellung von Dashboards, da es für jeden Auftrag ein eindeutiges Ergebnis liefert. So können verspätete Lieferungen einfach gefiltert und zusammengefasst werden, um typische Merkmale wie Produkte, Kunden oder Versandarten zu erkennen.
Warum das wichtig ist
Misst direkt den Kundenservice und die Zuverlässigkeit der Auftragsabwicklung. Zugleich vereinfacht es die Berechnung und Visualisierung der KPI für termingerechte Lieferungen.
Woher beziehen
Dies ist ein berechnetes Feld. Die Logik lautet: IF ('Ware geliefert' EventTime <= ConfirmedDeliveryDate) THEN True ELSE False.
Beispiele
truefalse
|
|||
|
Versandart
ShippingMethod
|
Die Versandart oder der Transportdienstleister, mit dem die Ware zum Kunden gebracht wird. | ||
|
Beschreibung
Dieses Attribut gibt die Transportart oder das Servicelevel für den Versand an, zum Beispiel 'Landfracht', 'Luftfracht Express' oder 'lokaler Kurierdienst'. Es beeinflusst sowohl die Lieferzeit als auch die Kosten. Anhand dieses Attributs können Unternehmen die Leistung verschiedener Versandarten bewerten. Das Dashboard 'Leistung nach Versandart' vergleicht beispielsweise für jede Versandart die Zykluszeit zwischen 'Ware versandt' und 'Ware geliefert'. So lässt sich die Logistik im Hinblick auf Geschwindigkeit, Kosten und Zuverlässigkeit optimieren.
Warum das wichtig ist
Ermöglicht den Leistungsvergleich verschiedener Transportdienstleister und Versandoptionen, um Kosten, Geschwindigkeit und Zuverlässigkeit zu optimieren.
Woher beziehen
Wird üblicherweise als SHIPPING_METHOD_CODE in Tabellen wie WSH_DELIVERY_DETAILS oder OE_ORDER_LINES_ALL gespeichert.
Beispiele
UPS GroundFedEx Priority OvernightDHL Express Worldwide
|
|||
|
Währung
Currency
|
Der Währungscode für die Geldbeträge des Kundenauftrags. | ||
|
Beschreibung
Das Währungsattribut gibt an, in welcher Währung die Auftragsbeträge ausgewiesen sind, zum Beispiel USD, EUR oder JPY. Es liefert den nötigen Kontext für die Interpretation aller Finanzdaten zum Auftrag. Das ist für Analysen in multinationalen Unternehmen wichtig, die in verschiedenen Währungen handeln. So lassen sich Finanzkennzahlen wie 'Gesamtauftragswert' korrekt einordnen und bei Bedarf für zusammengefasste Berichte in eine andere Währung umrechnen.
Warum das wichtig ist
Liefert den nötigen Kontext für alle Geldbeträge und ermöglicht eine korrekte Finanzanalyse, insbesondere in einem globalen Geschäftsumfeld.
Woher beziehen
Befindet sich im Feld TRANSACTIONAL_CURR_CODE der Tabelle OE_ORDER_HEADERS_ALL.
Beispiele
USDEURGBP
|
|||
|
Zahlung termingerecht eingegangen
IsPaymentOnTime
|
Kennzeichnet, ob die Zahlung am oder vor dem Fälligkeitsdatum der Rechnung eingegangen ist. | ||
|
Beschreibung
Dieses berechnete boolesche Attribut entsteht durch den Vergleich des Timestamps der Aktivität 'Zahlung eingegangen' mit dem 'Fälligkeitsdatum der Zahlung' für die zugehörige Rechnung. Es zeigt einfach und eindeutig an, ob die Zahlungsbedingungen eingehalten wurden. Dieses Kennzeichen bildet die Grundlage für die KPI 'Einhaltungsquote der Zahlungsbedingungen'. Es vereinfacht die Erstellung von Dashboards und Berichten, mit denen das Zahlungsverhalten der Kunden und die Wirksamkeit des Forderungsmanagements überwacht werden. Außerdem lassen sich pünktliche und verspätete Zahlungen schnell segmentieren, um Einflussfaktoren wie Kundentyp oder Zahlungsbedingungen zu analysieren.
Warum das wichtig ist
Misst direkt die Einhaltung der Zahlungsbedingungen. Das ist entscheidend für die Steuerung des Cashflows und die Einschätzung der finanziellen Zuverlässigkeit von Kunden.
Woher beziehen
Dies ist ein berechnetes Feld. Die Logik lautet: IF ('Zahlung eingegangen' EventTime <= PaymentDueDate) THEN True ELSE False.
Beispiele
truefalse
|
|||
Aktivitäten der Auftragsabwicklung im Vertrieb im Order-to-Cash-Prozess
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Auftrag bestätigt
|
Kennzeichnet die formelle Bestätigung des Kundenauftrags. Dadurch wird er aktiv und kann anschließend beispielsweise beschafft und versandt werden. In Oracle EBS ändert diese ausdrückliche Aktion den Auftragsstatus von „Entered“ zu „Booked“. | ||
|
Warum das wichtig ist
Die Auftragsbestätigung ist ein wichtiger Meilenstein, mit dem der Auftrag offiziell zur Abwicklung freigegeben wird. Verzögerungen zwischen Erstellung und Bestätigung können auf Probleme bei der Dateneingabe, Freigaben oder der ersten Prüfung hinweisen.
Woher beziehen
Das Ereignis wird in der Tabelle OE_ORDER_HEADERS_ALL erfasst, wenn BOOKED_FLAG auf „Y“ gesetzt wird. Der Timestamp steht in der Spalte BOOKED_DATE.
Erfassung
Verwenden Sie BOOKED_DATE aus der Tabelle OE_ORDER_HEADERS_ALL.
Ereignistyp
explicit
|
|||
|
Auftrag geschlossen
|
Diese Aktivität kennzeichnet den endgültigen Abschluss des Kundenauftrags, nachdem alle Positionen erfolgreich versandt, abgerechnet und geschlossen wurden. Sie wird durch eine ausdrückliche Statusänderung am Auftragskopf erfasst. | ||
|
Warum das wichtig ist
Dies ist der zentrale Endpunkt für einen erfolgreichen Order-to-Cash-Prozess. Der abschließende Timestamp ermöglicht die Berechnung der End-to-End-Durchlaufzeit erfolgreich abgewickelter Aufträge.
Woher beziehen
Dieses Ereignis wird in der Tabelle OE_ORDER_HEADERS_ALL erfasst, wenn FLOW_STATUS_CODE auf „CLOSED“ gesetzt wird. LAST_UPDATE_DATE dieser Statusänderung ist der Timestamp des Ereignisses.
Erfassung
Timestamp der Aktualisierung in OE_ORDER_HEADERS_ALL, bei der FLOW_STATUS_CODE den Wert „CLOSED“ erhält.
Ereignistyp
explicit
|
|||
|
Bestand zugewiesen
|
Diese Aktivität kennzeichnet die Reservierung von Bestand für die Auftragspositionen. Damit steht die benötigte Menge für die Kommissionierung bereit. Sie wird üblicherweise aus einer Statusänderung der Auftragsposition abgeleitet, die anzeigt, dass diese für die Freigabe an das Lager bereit ist. | ||
|
Warum das wichtig ist
Dieser Meilenstein ist wichtig, um die Bereitschaft zur Auftragsabwicklung zu beurteilen. Verzögerungen können auf Bestandsengpässe, Beschaffungsprobleme oder ineffiziente Zuweisungsprozesse hinweisen.
Woher beziehen
Abgeleitet aus Statusänderungen in der Tabelle WSH_DELIVERY_DETAILS. Die Aktivität tritt ein, wenn der Status einer Position auf „Ready to Release“ gesetzt wird. Der Timestamp wird aus der zugehörigen Statusänderung ermittelt.
Erfassung
Abgeleitet aus Statusänderungen der Positionen in WSH_DELIVERY_DETAILS auf „Ready to Release“.
Ereignistyp
inferred
|
|||
|
Kundenauftrag erstellt
|
Diese Aktivität kennzeichnet die erstmalige Erstellung eines Kundenauftrags im System. Das Ereignis wird ausdrücklich erfasst, wenn ein Benutzer einen neuen Auftragskopf speichert. Damit beginnt der Order-to-Cash-Prozess offiziell. | ||
|
Warum das wichtig ist
Dies ist das zentrale Start-Event des Prozesses. Die Zeitspanne bis zu den folgenden Aktivitäten ist entscheidend, um die gesamte Durchlaufzeit im Prozess Order to Cash zu messen.
Woher beziehen
Dieses Ereignis wird in der Tabelle OE_ORDER_HEADERS_ALL des Oracle-Order-Management-Moduls erfasst. Die Spalte CREATION_DATE enthält den genauen Timestamp der Aktivität.
Erfassung
Verwenden Sie CREATION_DATE aus der Tabelle OE_ORDER_HEADERS_ALL.
Ereignistyp
explicit
|
|||
|
Rechnung erstellt
|
Dieses Ereignis kennzeichnet die Erstellung der Forderungsrechnung für die versandte Ware. Es wird ausdrücklich durch den AutoInvoice-Prozess ausgelöst, der Daten aus Order Management und Shipping in das Receivables-Modul überträgt. | ||
|
Warum das wichtig ist
Diese Aktivität leitet den finanziellen Abwicklungsteil des Prozesses ein. Sie ist der Ausgangspunkt, um die Durchlaufzeit von der Rechnungsstellung bis zum Zahlungseingang zu messen und die Effizienz der Abrechnung zu überwachen.
Woher beziehen
Diese Transaktion wird ausdrücklich in der Tabelle RA_CUSTOMER_TRX_ALL in Oracle Receivables erfasst. TRX_DATE oder CREATION_DATE dient als Timestamp des Ereignisses.
Erfassung
Verwenden Sie TRX_DATE aus der Tabelle RA_CUSTOMER_TRX_ALL.
Ereignistyp
explicit
|
|||
|
Ware versandt
|
Kennzeichnet den Abschluss der Versandbestätigung, wenn die Ware das Lager tatsächlich verlässt. Dieses wichtige, ausdrücklich erfasste Ereignis im Versandmodul aktualisiert den Bestand und führt den Auftrag im Prozess weiter. | ||
|
Warum das wichtig ist
Dieser wichtige Meilenstein der Auftragsabwicklung dient zur Messung der Termintreue beim Versand. Außerdem löst er die Rechnungsstellung und Umsatzrealisierung aus.
Woher beziehen
Wird als ausdrückliche Transaktion in Oracle Shipping Execution erfasst. Der Timestamp steht in der Spalte INITIAL_PICKUP_DATE der Tabelle WSH_NEW_DELIVERIES oder lässt sich aus Statusänderungen in WSH_DELIVERY_DETAILS auf „Shipped“ ableiten.
Erfassung
Verwenden Sie das Datum der Versandbestätigung aus WSH_DELIVERY_DETAILS oder WSH_NEW_DELIVERIES.
Ereignistyp
explicit
|
|||
|
Zahlung eingegangen
|
Diese Aktivität tritt ein, wenn die Zahlung eines Kunden eingeht und im System der zugehörigen Rechnung zugeordnet wird. Sie wird als ausdrückliche Finanztransaktion im Modul Accounts Receivable erfasst. | ||
|
Warum das wichtig ist
Dieser Meilenstein ist entscheidend für die Überwachung des Cashflows, der Days Sales Outstanding (DSO) und der Einhaltung von Zahlungsbedingungen. Er bildet einen wichtigen Endpunkt für die Messung der finanziellen Durchlaufzeit.
Woher beziehen
Wird ausdrücklich in der Tabelle AR_RECEIVABLE_APPLICATIONS_ALL erfasst. Die Spalte APPLY_DATE enthält den Timestamp, zu dem der Zahlungseingang der Rechnung zugeordnet wurde.
Erfassung
Verwenden Sie APPLY_DATE aus AR_RECEIVABLE_APPLICATIONS_ALL für die jeweilige Rechnung.
Ereignistyp
explicit
|
|||
|
Auftrag storniert
|
Kennzeichnet die Stornierung eines gesamten Kundenauftrags vor Abschluss der Auftragsabwicklung. Dieses ausdrückliche Ereignis beendet den Workflow zur Auftragsbearbeitung. | ||
|
Warum das wichtig ist
Dies ist ein wichtiger Endpunkt für Ausnahmen. Die Häufigkeit, den Zeitpunkt und die Gründe für Stornierungen zu analysieren, ist entscheidend, um Umsatzverluste sowie Probleme mit Prozessen oder Produkten zu erkennen.
Woher beziehen
Wird in der Tabelle OE_ORDER_HEADERS_ALL erfasst, wenn FLOW_STATUS_CODE auf 'CANCELLED' und CANCELLED_FLAG auf 'Y' gesetzt ist. LAST_UPDATE_DATE kann als Timestamp verwendet werden.
Erfassung
Timestamp, zu dem CANCELLED_FLAG in OE_ORDER_HEADERS_ALL auf 'Y' gesetzt wird.
Ereignistyp
explicit
|
|||
|
Auftragsposition geschlossen
|
Zeigt an, dass die Bearbeitung einer einzelnen Kundenauftragsposition abgeschlossen ist, einschließlich Versand und Rechnungsstellung. Diese ausdrückliche Statusänderung wird durch den Workflow gesteuert. | ||
|
Warum das wichtig ist
Die Nachverfolgung abgeschlossener Auftragspositionen hilft, Teillieferungen zu analysieren und Probleme mit bestimmten Produkten oder Abläufen zu erkennen, bevor der gesamte Auftrag abgeschlossen ist.
Woher beziehen
Wird in der Tabelle OE_ORDER_LINES_ALL erfasst, wenn FLOW_STATUS_CODE auf „CLOSED“ gesetzt wird. LAST_UPDATE_DATE dieser Statusänderung kann als Timestamp dienen.
Erfassung
Timestamp der Aktualisierung in OE_ORDER_LINES_ALL, bei der FLOW_STATUS_CODE den Wert „CLOSED“ erhält.
Ereignistyp
explicit
|
|||
|
Bonitätsprüfung abgeschlossen
|
Diese Aktivität kennzeichnet den Abschluss der Bonitätsprüfung des Kunden für den Auftrag. Sie wird häufig erfasst, wenn eine gegebenenfalls gesetzte Bonitätssperre für den Kundenauftrag aufgehoben wird und der Auftrag weiterbearbeitet werden kann. | ||
|
Warum das wichtig ist
Verzögerungen bei der Bonitätsprüfung sind ein häufiger Engpass, der die gesamte Auftragsabwicklung aufhalten kann. Die Überwachung dieser Aktivität hilft, Ineffizienzen bei Finanzkontrollen und Freigaben zu erkennen.
Woher beziehen
Dieses Ereignis lässt sich aus der Tabelle OE_ORDER_HOLDS_ALL ableiten, indem der Timestamp ermittelt wird, zu dem eine „Credit Check Hold“ für einen bestimmten Auftragskopf aufgehoben wird.
Erfassung
Verwenden Sie den Timestamp der Aufhebung bonitätsbezogener Sperren aus OE_ORDER_HOLDS_ALL.
Ereignistyp
inferred
|
|||
|
Kommissionierung freigegeben
|
Dieses Ereignis kennzeichnet den Zeitpunkt, zu dem die Auftragspositionen für den Beginn der Kommissionierung an das Lager freigegeben werden. Durch diese ausdrückliche Aktion werden Kommissionierlisten erstellt und der Auftrag für das Lagerpersonal sichtbar. | ||
|
Warum das wichtig ist
Diese Aktivität leitet die physische Auftragsabwicklung ein. Die Zeitspanne bis zu „Ware versandt“ zeigt, wie effizient die Lagerabläufe sind und ob Engpässe bei der Kommissionierung auftreten.
Woher beziehen
Dieses Ereignis wird ausdrücklich im Oracle-Modul Shipping Execution erfasst. Es lässt sich daran erkennen, dass sich der Status der Lieferdetails in WSH_DELIVERY_DETAILS auf „Released to Warehouse“ oder „Transactable“ ändert.
Erfassung
Timestamp der Änderung von WSH_DELIVERY_DETAILS.RELEASED_STATUS auf „S“ (Submitted).
Ereignistyp
explicit
|
|||
|
Rechnung an Kunden gesendet
|
Diese Aktivität kennzeichnet den Zeitpunkt, zu dem die Rechnung gedruckt oder elektronisch an den Kunden übermittelt wird. Sie wird üblicherweise abgeleitet, da das Senden nicht immer als eigenes Ereignis getrennt von der Erstellung erfasst wird. | ||
|
Warum das wichtig ist
Damit beginnt offiziell die Zahlungsfrist des Kunden. Verzögerungen zwischen Rechnungserstellung und Versand können den Cashflow beeinträchtigen und zu verspäteten Zahlungen führen.
Woher beziehen
Das Ereignis lässt sich aus LAST_PRINTED_DATE in der Tabelle RA_CUSTOMER_TRX_ALL ableiten. Bei elektronischen Rechnungen müssen möglicherweise Protokolle eines externen Systems für den Dokumentenversand herangezogen werden.
Erfassung
Verwenden Sie LAST_PRINTED_DATE aus RA_CUSTOMER_TRX_ALL oder Protokolle von Drittanbieter-Tools.
Ereignistyp
inferred
|
|||
|
Ware geliefert
|
Diese Aktivität zeigt an, dass die Sendung beim Kunden eingetroffen ist. Oracle EBS erfasst dieses Ereignis standardmäßig nicht. Daher muss es üblicherweise abgeleitet oder aus externen Speditionssystemen importiert werden. | ||
|
Warum das wichtig ist
Dieses Ereignis ist wichtig, um Kennzahlen zur Termintreue bei der Lieferung zu messen und die Customer Experience vollständig zu beurteilen. Die Zeitspanne zwischen Versand und Lieferung zeigt die Leistung des Spediteurs.
Woher beziehen
Eine Systemanalyse ist erforderlich. Diese Daten sind in Oracle EBS nicht standardmäßig verfügbar und müssen aus externen Datenfeeds von Spediteuren oder aus integrierten Logistikplattformen stammen.
Erfassung
Abgeleitet aus externen Daten des Spediteurs oder anhand einer angenommenen Standardlaufzeit nach „Ware versandt“.
Ereignistyp
inferred
|
|||
Anleitungen zur Datenextraktion
Möchten Sie loslegen?
Mit diesem Template haben Sie alles, was Sie benötigen, um mit der Optimierung der Auftragsabwicklung im Vertrieb im Order-to-Cash-Prozess zu beginnen. Verbessern Sie Ihren Prozess noch heute und steigern Sie die Effizienz.
Optimieren Sie jetzt Ihre Auftragsabwicklung im Vertrieb im Order-to-Cash-Prozess!
Erkennen Sie Ineffizienzen und verkürzen Sie die Durchlaufzeit im Order-to-Cash-Prozess um 30 %.
Keine Kreditkarte erforderlich. 14 Tage kostenlos testen.