Daten-Template: Order to Cash - Auftragsbearbeitung
Ihr Order-to-Cash – Daten-Template für die Vertriebsauftragsabwicklung
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten für die Analyse
- Anleitung zur Datenextraktion
Auftragseingang bis Zahlungseingang – Kundenauftragsbearbeitung Attribute
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivitätsname
ActivityName
|
Der Name eines spezifischen Geschäftsereignisses oder Schrittes, der innerhalb des Verkaufsauftragslebenszyklus aufgetreten ist. | ||
|
Beschreibung
Dieses Attribut erfasst den Namen jeder auf einem Verkaufsauftrag durchgeführten Aktivität, wie zum Beispiel 'Auftrag gebucht', 'Waren versandt' oder 'Zahlung erhalten'. Diese Aktivitäten stellen die entscheidenden Meilensteine im Auftrag-zu-Kasse-Prozess dar. Die Analyse der Abfolge und Häufigkeit dieser Aktivitäten ist der Kern des Process Mining. Sie ermöglicht die Entdeckung der tatsächlichen Prozessabläufe, einschließlich gängiger Pfade, Abweichungen und Engpässe. Diese Daten werden verwendet, um die Prozesslandkarte zu erstellen, welche die primäre Visualisierung für die Prozessanalyse darstellt.
Warum es wichtig ist
Definiert die Schritte in der Prozesskarte, was für die Visualisierung und Analyse des Prozessflusses unerlässlich ist.
Woher erhalten
Dies ist ein konzeptuelles Feld, das aus verschiedenen Quellsystem-Ereignissen, Status und Transaktionsdaten aus Modulen wie Auftragsmanagement, Versandabwicklung und Debitorenbuchhaltung abgeleitet wird.
Beispiele
Verkaufsauftrag erstelltWaren verschicktRechnung erstelltZahlung eingegangen
|
|||
|
Ereigniszeit
EventTime
|
Der Timestamp, der angibt, wann eine spezifische Aktivität aufgetreten ist. | ||
|
Beschreibung
Event Time oder timestamp erfasst das genaue Datum und die Uhrzeit, zu der eine Aktivität ausgeführt wurde. Zum Beispiel wird aufgezeichnet, wann ein Auftrag erstellt, wann eine Rechnung gesendet oder wann eine Zahlung eingegangen ist. Diese temporären Daten sind grundlegend für Process Mining. Dieses Attribut wird verwendet, um Events für jeden Case chronologisch zu ordnen, was für die genaue Rekonstruktion des Prozessflusses erforderlich ist. Es ist auch die Basis für alle Dauer- und Performance-Berechnungen, wie cycle times zwischen Aktivitäten, die gesamte Case-Dauer und die Identifizierung von Verzögerungen oder Bottlenecks.
Warum es wichtig ist
Bietet die chronologische Abfolge von Ereignissen und ist die Grundlage für alle zeitbasierten Performance-Analysen, einschließlich der cycle time und der Engpassidentifizierung.
Woher erhalten
Bezogen aus verschiedenen Datumsfeldern in Oracle EBS Tabellen, wie z.B. 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
|
|||
|
Verkaufsauftrag
SalesOrder
|
Die eindeutige Kennung für den Verkaufsauftrag eines Kunden, der als primärer Case für den Order-to-Cash-Prozess dient. | ||
|
Beschreibung
Die Verkaufsauftragsnummer identifiziert jeden Kundenauftrag während seines gesamten Lebenszyklus, von der Erstellung bis zum endgültigen Abschluss, eindeutig. Sie fungiert als zentraler Faden, der alle zugehörigen Aktivitäten wie Buchung, Versand, Rechnungsstellung und Zahlung verbindet. Im Process Mining ist dieses Attribut unerlässlich, um die End-to-End-Journey jedes Auftrags zu rekonstruieren. Durch das Gruppieren aller Events unter einem einzigen Verkaufsauftrag können Analysten den vollständigen Prozessfluss visualisieren, Variationen zwischen Aufträgen identifizieren und Schlüsselleistungsindikatoren wie cycle time und on-time delivery für einzelne Cases messen.
Warum es wichtig ist
Dies ist die Case ID, die grundlegend ist, um alle Prozessereignisse miteinander zu verknüpfen und den End-to-End-Auftragslebenszyklus zu analysieren.
Woher erhalten
Der Primärschlüssel für einen Verkaufsauftrag, typischerweise zu finden in Oracle Order Management Tabellen wie OE_ORDER_HEADERS_ALL.HEADER_ID.
Beispiele
685127103482459
|
|||
|
Auftragsstatus
OrderStatus
|
Der aktuelle oder historische Status des Verkaufsauftrags oder der Auftragsposition. | ||
|
Beschreibung
Dieses Attribut erfasst den Status eines Verkaufsauftrags zu verschiedenen Zeitpunkten, wie 'Eingetragen', 'Gebucht', 'Geschlossen' oder 'Storniert'. Status entsprechen oft direkt den Prozessaktivitäten. Die Verfolgung des Auftragsstatus ist entscheidend für den Aufbau von Dashboards, die den aktuellen Zustand aller aktiven Aufträge zeigen. Es ermöglicht Managern, die Auftragspipeline zu überwachen, steckengebliebene Aufträge zu identifizieren und Ausnahmen proaktiv zu verwalten. Die Analyse von Statusübergängen ist eine gängige Methode, um Aktivitäten für die Prozesslandkarte zu definieren.
Warum es wichtig ist
Bietet Transparenz über die Verkaufsauftragspipeline und hilft dabei, festgefahrene Aufträge zu identifizieren und Prozessausnahmen zu verwalten.
Woher erhalten
Typischerweise zu finden in der FLOW_STATUS_CODE-Spalte in den OE_ORDER_HEADERS_ALL- und OE_ORDER_LINES_ALL-Tabellen.
Beispiele
GEBUCHTVERSAND_WARTENDSHIPPEDABGESCHLOSSENSTORNIERT
|
|||
|
Benutzername
UserName
|
Der Benutzer, der die Aktivität durchgeführt hat. | ||
|
Beschreibung
Identifiziert den spezifischen Benutzer, der für die Ausführung eines bestimmten Prozessschritts verantwortlich ist. Dies kann der Vertriebsmitarbeiter sein, der den Auftrag erstellt hat, der Kreditanalyst, der die Prüfung durchgeführt hat, oder der Sachbearbeiter, der die Rechnung erstellt hat. Die Analyse von Aktivitäten nach Benutzer hilft, den Schulungsbedarf, leistungsstarke Mitarbeiter oder Teams sowie die Arbeitslastverteilung zu identifizieren. Sie ist auch entscheidend für die Compliance und die Audit-Trail-Analyse, z.B. bei der Untersuchung nicht autorisierter Aktionen oder dem Verständnis von Nacharbeitsmustern, die mit spezifischen Benutzern verbunden sind.
Warum es wichtig ist
Ermöglicht die Analyse der Benutzerperformance, der Arbeitslastverteilung und der Einhaltung von Compliance-Protokollen. Es hilft, die Frage zu beantworten, 'wer' eine Aktion ausgeführt hat.
Woher erhalten
Bezogen aus benutzerbezogenen Feldern wie CREATED_BY oder LAST_UPDATED_BY in verschiedenen Oracle EBS Tabellen. Dies erfordert oft eine Verknüpfung mit FND_USER, um den vollständigen Benutzernamen zu erhalten.
Beispiele
JSMITHRWILLIAMSCDAVIS
|
|||
|
Bestätigtes Lieferdatum
ConfirmedDeliveryDate
|
Das zugesagte Datum, bis zu dem die Waren an den Kunden geliefert werden sollen. | ||
|
Beschreibung
Dieses Attribut speichert das Lieferdatum, das dem Kunden zugesagt oder bestätigt wurde. Es dient als Ziel oder Referenzwert zur Messung der Lieferpünktlichkeit. Im Process Mining wird dieses Datum mit dem tatsächlichen Lieferzeitpunkt (aus der Aktivität 'Waren geliefert') verglichen, um die KPI 'Lieferpünktlichkeitsrate' zu berechnen. Die Analyse von Abweichungen von diesem Datum hilft, systemische Probleme in der Logistik, im Bestandsmanagement oder in der Produktionsplanung zu identifizieren, die zu Lieferverzögerungen führen.
Warum es wichtig ist
Dies ist die Grundlage für die Messung der Lieferpünktlichkeit, eine kritische KPI für die Kundenzufriedenheit und operative Exzellenz.
Woher erhalten
Dieses Datum ist typischerweise in den Feldern LATEST_ACCEPTABLE_DATE oder REQUEST_DATE auf der Auftragspositionsebene in der OE_ORDER_LINES_ALL Tabelle zu finden.
Beispiele
2023-05-102023-06-012023-07-20
|
|||
|
Gesamtbestellwert
TotalOrderAmount
|
Der gesamte Geldwert des Verkaufsauftrags. | ||
|
Beschreibung
Dieses Attribut repräsentiert den Gesamtwert aller Positionen eines Verkaufsauftrags, ausgedrückt in der Transaktionswährung. Es ist eine entscheidende Finanzkennzahl, die mit jedem Case verknüpft ist. Die Analyse von Prozesskennzahlen nach Auftragswert hilft, Verbesserungsbemühungen zu priorisieren. Zum Beispiel können Analysten untersuchen, ob hochwertige Aufträge mehr Verzögerungen oder Nacharbeit erfahren als geringwertige Aufträge. Sie ermöglicht auch die Bewertung finanzieller Auswirkungen, etwa die Quantifizierung des Werts von Aufträgen, die in einem bestimmten Engpass festhängen.
Warum es wichtig ist
Ermöglicht eine Finanzanalyse des Prozesses, die hilft, hochwertige Aufträge zu priorisieren und die monetären Auswirkungen von Ineffizienzen zu quantifizieren.
Woher erhalten
Dieser Wert wird typischerweise berechnet, indem die Zeilenbeträge einer bestimmten Bestellung summiert werden. Zeilenbeträge finden Sie in Tabellen wie OE_ORDER_LINES_ALL.
Beispiele
5450.00125000.75980.50
|
|||
|
Kundenname
CustomerName
|
Der Name des Kunden, der den Verkaufsauftrag platziert hat. | ||
|
Beschreibung
Dieses Attribut identifiziert den rechtlichen Namen des Kunden, der mit dem Verkaufsauftrag verbunden ist. Es ist eine primäre Dimension für die Segmentierung und Analyse der Prozessleistung. Durch das Filtern oder Aufschlüsseln des Prozesses nach Kunde können Analysten identifizieren, welche Kunden die längsten cycle times aufweisen, die höchsten Rework-Raten haben oder am häufigsten mit Zahlungsverzögerungen in Verbindung gebracht werden. Diese Erkenntnis ist von unschätzbarem Wert für die Verbesserung der Kundenbeziehungen, die Anpassung der Service-Level und das Verständnis des Kundenverhaltens.
Warum es wichtig ist
Ermöglicht eine kundenorientierte Analyse, um Leistungsabweichungen zu identifizieren, den Service zu verbessern und das Zahlungsverhalten über verschiedene Kunden hinweg zu verstehen.
Woher erhalten
Abgeleitet durch Verknüpfen der SOLD_TO_ORG_ID aus OE_ORDER_HEADERS_ALL mit den Tabellen HZ_CUST_ACCOUNTS und HZ_PARTIES, um den Parteinamen abzurufen.
Beispiele
Global Tech Inc.Innovate Solutions LLCPioneer Corp
|
|||
|
Zahlungsbedingungen
PaymentTerms
|
Die vereinbarten Bedingungen, die festlegen, wann der Kunde die Waren oder Dienstleistungen voraussichtlich bezahlen muss. | ||
|
Beschreibung
Die Zahlungsbedingungen legen die Zahlungsmodalitäten für eine Rechnung fest, z.B. 'Netto 30', 'Netto 60' oder 'Sofort fällig'. Dieses Attribut ist grundlegend für die Verwaltung von Debitoren und den Cashflow. Die Analyse der Prozessleistung nach Zahlungsbedingungen hilft zu erkennen, ob Kunden mit bestimmten Konditionen eher zu spät zahlen. Diese Informationen werden genutzt, um finanzielle Risiken zu bewerten, Inkassostrategien zu optimieren und die Wirksamkeit verschiedener Zahlungsbedingungen zu beurteilen. Es ist eine wichtige Dimension für das Dashboard 'Überwachung der Zahlungsbedingungen-Compliance'.
Warum es wichtig ist
Entscheidend für die Analyse des Zahlungsverhaltens, das Monitoring des Cashflows und die Bewertung des finanziellen Risikos im Zusammenhang mit verschiedenen Kundenvereinbarungen.
Woher erhalten
In der Tabelle RA_TERMS gefunden, 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
|
|||
|
Zahlungsfälligkeitsdatum
PaymentDueDate
|
Das berechnete Datum, bis zu dem die Rechnungszahlung vom Kunden fällig ist. | ||
|
Beschreibung
Das Zahlungsfälligkeitsdatum ist der spezifische Kalendertag, an dem eine Rechnung beglichen werden muss, berechnet basierend auf dem Rechnungsdatum und den vereinbarten Zahlungsbedingungen. Es ist das Zieldatum für die Aktivität 'Zahlung erhalten'. Dieses Attribut ist unerlässlich für die Berechnung des KPI 'Zahlungsbedingungen-Compliance-Rate' durch den Vergleich mit dem tatsächlichen Zahlungsdatum. Die Analyse von Abweichungen hilft dem Inkasso-Team, seine Anstrengungen zu priorisieren, chronisch spätzahlende Kunden zu identifizieren und die Effektivität des Mahnwesens zu messen.
Warum es wichtig ist
Dient als Zieldatum für den Zahlungseinzug und ermöglicht so die Messung der Pünktlichkeit von Zahlungen sowie der Compliance des Kunden mit den Bedingungen.
Woher erhalten
Befindet sich im DUE_DATE-Feld der Tabelle AR_PAYMENT_SCHEDULES_ALL, das mit der Rechnungsbuchung verknüpft ist.
Beispiele
2023-06-152023-07-012023-08-30
|
|||
|
Auftragsmenge
OrderQuantity
|
Die Menge des Produkts, das auf einer spezifischen Verkaufsauftragsposition bestellt wurde. | ||
|
Beschreibung
Dieses Attribut gibt die Anzahl der Einheiten eines bestimmten Produkts an, die vom Kunden auf einer Verkaufsauftragsposition angefordert wurden. Es repräsentiert das Transaktionsvolumen auf Positionsebene. Die Bestellmenge kann als Analysekriterium verwendet werden, um festzustellen, ob sich das Prozessverhalten mit der Auftragsgröße ändert. Zum Beispiel könnten sehr große oder sehr kleine Aufträge unterschiedliche Prozesspfade durchlaufen oder verschiedene Arten von Verzögerungen erfahren. Es liefert auch Kontext für andere Kennzahlen, wie den Auftragswert.
Warum es wichtig ist
Bietet Kontext zum Umfang eines Auftrags, was die Analyse ermöglicht, wie das Auftragsvolumen die Prozesseffizienz und die Abwicklungspfade beeinflusst.
Woher erhalten
Im Feld ORDERED_QUANTITY der Tabelle OE_ORDER_LINES_ALL zu finden.
Beispiele
102501
|
|||
|
Ist Nacharbeit
IsRework
|
Ein Flag, das anzeigt, ob ein Kundenauftrag überarbeitet wurde, z. B. durch wiederholte Bestätigungs- oder Aktualisierungsaktivitäten. | ||
|
Beschreibung
Dies ist ein berechnetes Boolesches Attribut, das Fälle markiert, die Muster von Nacharbeit aufweisen. Nacharbeit kann durch das Erkennen von Schleifen in der Prozesslandkarte identifiziert werden, zum Beispiel wenn ein Auftrag mehrfach gebucht wird, oder durch spezifische Änderungsereignisse, die im System protokolliert sind. Dieses Flag wird verwendet, um die KPI 'Nacharbeitsrate für Verkaufsaufträge' zu berechnen und das Dashboard 'Analyse der Nacharbeit von Verkaufsaufträgen' zu unterstützen. Es ermöglicht Analysten, Aufträge, die vom Standardprozess abweichen, leicht zu isolieren und zu untersuchen, um die Auswirkungen von Nacharbeit auf Durchlaufzeiten und Kosten zu quantifizieren und die Grundursachen dieser ineffizienten Schleifen zu identifizieren.
Warum es wichtig ist
Hilft, Prozessineffizienz zu quantifizieren, indem es Aufträge kennzeichnet, die manuelle Änderungen erforderten, und ermöglicht so die Analyse der Ursachen und Auswirkungen von Nacharbeit.
Woher erhalten
Wird während der Data Transformation berechnet, indem Aktivitätssequenzen identifiziert werden, die eine Schleife darstellen (z. B. wenn 'Order Booked' mehr als einmal für denselben Case auftritt).
Beispiele
truefalsch
|
|||
|
Ist pünktliche Lieferung
IsOnTimeDelivery
|
Ein Flag, das anzeigt, ob die Bestellung am oder vor dem bestätigten Lieferdatum geliefert wurde. | ||
|
Beschreibung
Dieses berechnete Attribut ist ein Boolesches Flag (Wahr/Falsch), das angibt, ob ein Auftrag seine Lieferzusage erfüllt hat. Es wird durch den Vergleich des Timestamp der Aktivität 'Waren geliefert' mit dem Bestätigten Lieferdatum abgeleitet. Dieses Attribut unterstützt direkt die KPI 'Lieferpünktlichkeitsrate'. Es vereinfacht die Analyse und Dashboard-Erstellung, indem es ein klares, binäres Ergebnis für jeden Auftrag liefert. Dies ermöglicht eine einfache Filterung und Aggregation, um die Merkmale verspäteter Lieferungen zu identifizieren, wie z. B. häufige Produkte, Kunden oder Versandmethoden.
Warum es wichtig ist
Misst direkt das Kundenservice-Niveau und die Lieferzuverlässigkeit und vereinfacht die Berechnung und Visualisierung des On-Time-Delivery-KPIs.
Woher erhalten
Dies ist ein berechnetes Feld. Die Logik lautet: WENN (EventTime von 'Waren geliefert' <= ConfirmedDeliveryDate) DANN Wahr, ANSONSTEN Falsch.
Beispiele
truefalsch
|
|||
|
Ist pünktliche Zahlung
IsPaymentOnTime
|
Ein Flag, das anzeigt, ob die Zahlung am oder vor dem Fälligkeitsdatum der Rechnung eingegangen ist. | ||
|
Beschreibung
Dies ist ein berechnetes Boolesches Attribut, das durch den Vergleich des Timestamp der Aktivität 'Zahlung erhalten' mit dem Fälligkeitsdatum der Zahlung für die entsprechende Rechnung abgeleitet wird. Es liefert einen einfachen Wahr/Falsch-Indikator für die Zahlungs-Compliance. Dieses Flag ist die Grundlage für die KPI zur 'Einhaltung der Zahlungsbedingungen'. Es vereinfacht die Erstellung von Dashboards und Berichten, die das Kunden-Zahlungsverhalten und die Effektivität des Debitorenbuchhaltungsprozesses überwachen. Dies ermöglicht eine schnelle Segmentierung von pünktlichen und verspäteten Zahlungen, um beitragende Faktoren wie Kundentyp oder Zahlungsbedingungen zu analysieren.
Warum es wichtig ist
Misst direkt die Einhaltung der Zahlungsbedingungen, was entscheidend für das Cashflow-Management und die Bewertung der finanziellen Zuverlässigkeit von Kunden ist.
Woher erhalten
Dies ist ein berechnetes Feld. Die Logik lautet: WENN (EventTime von 'Zahlung erhalten' <= PaymentDueDate) DANN Wahr, ANSONSTEN Falsch.
Beispiele
truefalsch
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Zeitstempel der aktuellsten Datenaktualisierung aus dem Quellsystem. | ||
|
Beschreibung
Dieses Attribut gibt den letzten Zeitpunkt an, zu dem die Daten aus der Oracle E-Business Suite extrahiert und in das Process Mining Tool geladen wurden. Es spiegelt die Aktualität der analysierten Daten wider. Dies ist entscheidend für Benutzer, um die Rechtzeitigkeit der von ihnen angezeigten Insights zu verstehen. Es hilft ihnen zu erkennen, ob sie Echtzeitinformationen oder einen Snapshot von einem bestimmten Zeitpunkt betrachten, was für das Treffen von operativen Entscheidungen wichtig ist.
Warum es wichtig ist
Informiert Benutzer über die Aktualität der Daten, was entscheidend ist, um der Analyse zu vertrauen und zeitnahe Entscheidungen zu treffen.
Woher erhalten
Dieser Timestamp wird während des Daten-Extraktions-, Transformations- und Ladevorgangs (ETL-Prozess) generiert und hinzugefügt.
Beispiele
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Produktnummer
ProductNumber
|
Die eindeutige Kennung für das Produkt oder den Artikel auf der Verkaufsauftragsposition. | ||
|
Beschreibung
Dieses Attribut identifiziert, welches Material, welcher Artikel oder welche Dienstleistung verkauft wird. So können Analysen auf einer detaillierteren Ebene erfolgen als auf der Kopfebene des Verkaufsauftrags. Die Prozessanalyse nach Produkt hilft, produktspezifische Probleme aufzudecken. Manche Produkte haben zum Beispiel längere Durchlaufzeiten, etwa wegen aufwendiger Fertigung oder Beschaffung, während bei anderen häufiger Versandfehler oder Kundenreklamationen auftreten. Dadurch sind gezielte Verbesserungen in der Lieferkette und im Produktmanagement möglich.
Warum es wichtig ist
Ermöglicht eine produktbezogene Analyse, um Artikel zu identifizieren, die Prozessverzögerungen, Nacharbeiten oder andere Ineffizienzen verursachen.
Woher erhalten
Abgeleitet aus INVENTORY_ITEM_ID in der Tabelle OE_ORDER_LINES_ALL, die mit MTL_SYSTEM_ITEMS_B verknüpft werden kann, um die Artikelnummer oder Beschreibung zu erhalten.
Beispiele
AS54888CM15001SV20100
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem die Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut identifiziert das Quellinformationssystem, in dem die Event Data entstanden sind. Für diesen Prozess wird es konsistent die 'Oracle E-Business Suite' sein. In Umgebungen mit mehreren Systemen ist dieses Feld entscheidend für die Datenherkunft und die Fehlerbehebung. Selbst in einem Einzelsystem-Kontext liefert es wichtigen Kontext für das Datenmodell und hilft bei der Standardisierung von Data Ingestion Prozessen.
Warum es wichtig ist
Bietet wesentlichen Kontext zur Datenherkunft, was die Rückverfolgbarkeit und korrekte Interpretation der Daten gewährleistet, insbesondere in Multi-System-Landschaften.
Woher erhalten
Dies ist typischerweise ein statischer Wert, der während des Datenextraktions-, Transformations- und Ladeprozesses (ETL) hinzugefügt wird, um den Ursprung der Daten zu kennzeichnen.
Beispiele
Oracle E-Business SuiteOracle EBS R12
|
|||
|
Stornierungsgrund
CancellationReason
|
Der dokumentierte Grund für die Stornierung eines Verkaufsauftrags oder einer Auftragsposition. | ||
|
Beschreibung
Wenn eine Bestellung storniert wird, erfasst dieses Attribut den angegebenen Grund für die Stornierung. Beispielgründe könnten 'Kundenwunsch', 'Nicht auf Lager' oder 'Kreditstopp' sein.\n\nDiese Daten sind entscheidend für die Ursachenanalyse von Bestellstornierungen. Das Dashboard 'Sales Order Cancellation Rate & Reasons' verwendet dieses Attribut, um die Hauptursachen für Stornierungen zu identifizieren, wodurch das Unternehmen zielgerichtete Strategien implementieren kann, um die Abwanderung zu reduzieren, die Bestandsplanung zu verbessern oder die Kreditrichtlinien zu verfeinern.
Warum es wichtig ist
Bietet direkten Einblick, warum Aufträge storniert werden, was eine Ursachenanalyse ermöglicht, um Umsatzverluste zu reduzieren und die Kundenbindung zu verbessern.
Woher erhalten
Diese Information wird oft in einem Grundcode-Feld, wie z. B. CANCELLED_REASON, gespeichert, das in der OE_ORDER_LINES_ALL Tabelle oder einer verwandten Tabelle für Auftragsänderungen verfügbar sein kann.
Beispiele
Artikel eingestelltKunde storniertDoppelter Auftrag
|
|||
|
Versandart
ShippingMethod
|
Die Methode oder der Spediteur, der für den Warentransport zum Kunden verwendet wird. | ||
|
Beschreibung
Dieses Attribut gibt die für den Versand verwendete Transportart oder das Servicelevel an, wie zum Beispiel 'Landfracht', 'Luft-Express' oder 'Lokaler Kurierdienst'. Es ist ein Schlüsselfaktor, der sowohl die Lieferzeit als auch die Kosten beeinflusst. Durch die Analyse des Prozesses mithilfe dieses Attributs können Unternehmen die Leistung verschiedener Versandmethoden bewerten. Zum Beispiel vergleicht das Dashboard 'Versandmethoden-Leistung' die Durchlaufzeit von 'Waren versandt' bis 'Waren geliefert' für jede Methode und hilft so, die Logistik für ein ausgewogenes Verhältnis von Geschwindigkeit, Kosten und Zuverlässigkeit zu optimieren.
Warum es wichtig ist
Ermöglicht die Performance-Bewertung verschiedener Spediteure und Versandoptionen zur Optimierung von Kosten, Geschwindigkeit und Zuverlässigkeit.
Woher erhalten
Wird in der Regel 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 Geldwerte des Verkaufsauftrags. | ||
|
Beschreibung
Das Attribut Währung gibt die Währung an, in der die Auftragsbeträge, wie USD, EUR oder JPY, ausgewiesen sind. Es liefert den notwendigen Kontext für die Interpretation aller Finanzdaten, die mit dem Auftrag in Verbindung stehen. Dies ist unerlässlich für Analysen in multinationalen Organisationen, die in verschiedenen Währungen Transaktionen tätigen. Es stellt sicher, dass Finanzkennzahlen wie der 'Gesamtauftragswert' korrekt verstanden werden und ermöglicht bei Bedarf eine ordnungsgemäße Währungsumrechnung für aggregierte Berichte.
Warum es wichtig ist
Bietet wesentlichen Kontext für alle monetären Werte, was eine genaue Finanzanalyse gewährleistet, insbesondere in einem globalen Geschäftsumfeld.
Woher erhalten
Befindet sich im TRANSACTIONAL_CURR_CODE-Feld der Tabelle OE_ORDER_HEADERS_ALL.
Beispiele
USDEURGBP
|
|||
Auftragseingang bis Zahlungseingang – Kundenauftragsbearbeitung Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Auftrag abgeschlossen
|
Diese Aktivität markiert den endgültigen Abschluss des Verkaufsauftrags, nachdem alle seine Positionen erfolgreich versandt, fakturiert und geschlossen wurden. Dies ist eine explizite Statusaktualisierung auf dem Auftragsheader. | ||
|
Warum es wichtig ist
Dies ist der primäre Erfolgsendpunkt für den Auftrag-zu-Kasse-Prozess. Er liefert den endgültigen Timestamp, der benötigt wird, um die End-to-End-Durchlaufzeit für erfolgreich erfüllte Aufträge zu berechnen.
Woher erhalten
Dieses Ereignis wird in der OE_ORDER_HEADERS_ALL Tabelle aufgezeichnet, wenn der FLOW_STATUS_CODE auf 'CLOSED' aktualisiert wird. Das LAST_UPDATE_DATE für diese Statusänderung ist der Ereignis-Timestamp.
Erfassen
Timestamp der Aktualisierung von OE_ORDER_HEADERS_ALL, wenn der FLOW_STATUS_CODE 'CLOSED' wird.
Ereignistyp
explicit
|
|||
|
Auftrag erfasst
|
Stellt die formelle Bestätigung des Verkaufsauftrags dar, wodurch er aktiv und für nachfolgende Prozesse wie Beschaffung und Versand berechtigt wird. Dies ist eine explizite Aktion in Oracle EBS, die den Status des Auftrags von 'Entered' zu 'Booked' ändert. | ||
|
Warum es wichtig ist
Die Buchung ist ein kritischer Meilenstein, der die Bestellung offiziell zur Erfüllung verpflichtet. Verzögerungen zwischen Erstellung und Buchung können auf Probleme bei der Dateneingabe, Genehmigungen oder der anfänglichen Validierung hinweisen.
Woher erhalten
Erfasst aus der Tabelle OE_ORDER_HEADERS_ALL. Das Event tritt auf, wenn der BOOKED_FLAG auf 'Y' gesetzt ist, und der timestamp wird in der Spalte BOOKED_DATE aufgezeichnet.
Erfassen
Verwenden Sie BOOKED_DATE aus der OE_ORDER_HEADERS_ALL-Tabelle.
Ereignistyp
explicit
|
|||
|
Bestand zugewiesen
|
Diese Aktivität repräsentiert die Bestandsreservierung für die Auftragspositionen, um sicherzustellen, dass die benötigte Menge für die Kommissionierung verfügbar ist. Dies wird typischerweise aus einer Statusänderung der Verkaufsauftragsposition abgeleitet, die anzeigt, dass sie zur Freigabe an das Lager bereit ist. | ||
|
Warum es wichtig ist
Dieser Meilenstein ist entscheidend für das Verständnis der Lieferbereitschaft. Verzögerungen an diesem Punkt können auf Bestandsengpässe, Beschaffungsprobleme oder Ineffizienzen im Zuteilungsprozess hindeuten.
Woher erhalten
Abgeleitet von Statusänderungen in der Tabelle WSH_DELIVERY_DETAILS. Die Aktivität tritt auf, wenn der Status einer Position auf 'Bereit zur Freigabe' aktualisiert wird, wobei der Timestamp von der zugehörigen Statusaktualisierung abgeleitet wird.
Erfassen
Abgeleitet von Positionsstatusaktualisierungen in WSH_DELIVERY_DETAILS zu 'Bereit zur Freigabe'.
Ereignistyp
inferred
|
|||
|
Rechnung erstellt
|
Dieses Ereignis markiert die Erstellung der Debitorenrechnung für die versandten Waren. Es ist ein explizites Ereignis, das durch den AutoInvoice-Prozess ausgelöst wird, welcher Daten aus dem Auftragsmanagement und Versand in das Debitorenmodul zieht. | ||
|
Warum es wichtig ist
Diese Aktivität initiiert den finanziellen Abwicklungsteil des Prozesses. Sie ist der Startpunkt für die Messung der Invoice-to-Payment-Cycle Time und die Überwachung der Rechnungseffizienz.
Woher erhalten
Dies ist eine explizite Transaktion, die in der RA_CUSTOMER_TRX_ALL Tabelle in Oracle Receivables aufgezeichnet wird. Das TRX_DATE oder CREATION_DATE dient als Ereignis-Timestamp.
Erfassen
Verwenden Sie TRX_DATE aus der RA_CUSTOMER_TRX_ALL-Tabelle.
Ereignistyp
explicit
|
|||
|
Verkaufsauftrag erstellt
|
Diese Aktivität markiert die initiale Erstellung eines Verkaufsauftrags im System. Es ist ein expliziter Event, der erfasst wird, wenn ein Benutzer einen neuen Verkaufsauftragsheader speichert, was den formellen Start des Order-to-Cash-Prozesses darstellt. | ||
|
Warum es wichtig ist
Dies ist das primäre Startereignis für den Prozess. Die Analyse der Zeitspanne von diesem Punkt bis zu nachfolgenden Aktivitäten ist essenziell, um die Gesamtdurchlaufzeit des Auftrag-zu-Kasse-Prozesses zu messen.
Woher erhalten
Dieses Ereignis wird aus der OE_ORDER_HEADERS_ALL Tabelle im Oracle Order Management Modul erfasst. Die Spalte CREATION_DATE liefert den expliziten Timestamp für diese Aktivität.
Erfassen
Verwenden Sie CREATION_DATE aus der OE_ORDER_HEADERS_ALL-Tabelle.
Ereignistyp
explicit
|
|||
|
Waren verschickt
|
Stellt den Abschluss des Versandbestätigungsprozesses dar, bei dem die Waren physisch das Lager verlassen. Dies ist ein wichtiges explizites Event im Versandmodul, das den Lagerbestand aktualisiert und den Auftragsstatus vorantreibt. | ||
|
Warum es wichtig ist
Dies ist ein kritischer Erfüllungsmeilenstein, der zur Messung der Lieferpünktlichkeit verwendet wird. Er dient auch als Auslöser für Fakturierungs- und Umsatzerkennungsprozesse.
Woher erhalten
Erfasst als explizite Transaktion in Oracle Shipping Execution. Der timestamp ist in der Tabelle WSH_NEW_DELIVERIES unter INITIAL_PICKUP_DATE zu finden oder kann aus Statusaktualisierungen in WSH_DELIVERY_DETAILS auf 'Shipped' abgeleitet werden.
Erfassen
Verwenden Sie das Versandbestätigungsdatum aus WSH_DELIVERY_DETAILS oder WSH_NEW_DELIVERIES.
Ereignistyp
explicit
|
|||
|
Zahlung eingegangen
|
Diese Aktivität tritt auf, wenn eine Kundenzahlung empfangen und der entsprechenden Rechnung im System zugeordnet wird. Es handelt sich um eine explizite Finanztransaktion, die im Debitorenmodul erfasst wird. | ||
|
Warum es wichtig ist
Dieser Meilenstein ist entscheidend für die Verfolgung des Cashflows, der Days Sales Outstanding (DSO) und der Einhaltung der Zahlungsbedingungen. Er ist ein Schlüsselendpunkt für die Messung der finanziellen Durchlaufzeit.
Woher erhalten
Explizit in der Tabelle AR_RECEIVABLE_APPLICATIONS_ALL erfasst. Die Spalte APPLY_DATE liefert den Timestamp für die Verbuchung des Zahlungseingangs auf die Rechnung.
Erfassen
Verwenden Sie APPLY_DATE aus AR_RECEIVABLE_APPLICATIONS_ALL für die spezifische Rechnung.
Ereignistyp
explicit
|
|||
|
Auftrag storniert
|
Stellt die Stornierung eines gesamten Verkaufsauftrags dar, bevor die Abwicklung abgeschlossen ist. Dies ist ein explizites Event, das den Workflow der Auftragsbearbeitung beendet. | ||
|
Warum es wichtig ist
Dies ist ein wichtiger Ausnahme-Endpunkt. Die Analyse der Häufigkeit, des Zeitpunkts und der Gründe für Stornierungen ist entscheidend für die Identifizierung von Umsatzverlusten sowie Prozess- oder Produktproblemen.
Woher erhalten
Erfasst in der Tabelle OE_ORDER_HEADERS_ALL, wenn der FLOW_STATUS_CODE auf 'CANCELLED' und der CANCELLED_FLAG auf 'Y' gesetzt ist. Das LAST_UPDATE_DATE kann als Timestamp verwendet werden.
Erfassen
Timestamp, wenn das CANCELLED_FLAG in OE_ORDER_HEADERS_ALL auf 'Y' gesetzt wird.
Ereignistyp
explicit
|
|||
|
Auftragsposition abgeschlossen
|
Zeigt an, dass die gesamte Bearbeitung einer einzelnen Position eines Auftrags abgeschlossen ist, einschließlich Versand und Rechnungsstellung. Dies ist eine explizite Statusänderung, die durch den Workflow-Prozess verwaltet wird. | ||
|
Warum es wichtig ist
Das Nachverfolgen von Positionspostenabschlüssen hilft bei der Analyse von Teillieferungen und der Identifizierung von Problemen bei spezifischen Produkten oder Lieferwegen, bevor die gesamte Bestellung abgeschlossen ist.
Woher erhalten
Dies wird in der OE_ORDER_LINES_ALL Tabelle aufgezeichnet, wenn der FLOW_STATUS_CODE auf 'CLOSED' aktualisiert wird. Das LAST_UPDATE_DATE für diese Statusänderung kann als Timestamp dienen.
Erfassen
Timestamp der Aktualisierung von OE_ORDER_LINES_ALL, wenn der FLOW_STATUS_CODE 'CLOSED' wird.
Ereignistyp
explicit
|
|||
|
Bonitätsprüfung durchgeführt
|
Diese Aktivität signalisiert den Abschluss des Kundenkreditprüfungsprozesses für den Auftrag. Sie wird oft erfasst, wenn eine Kreditprüfungssperre, falls angewendet, vom Verkaufsauftrag freigegeben wird, wodurch dieser fortfahren kann. | ||
|
Warum es wichtig ist
Verzögerungen bei der Bonitätsprüfung sind ein häufiger Bottleneck, der den gesamten Fulfillment-Prozess zum Stillstand bringen kann. Das Monitoring dieser Aktivität hilft, Ineffizienzen bei Finanzkontrollen und Genehmigungen zu identifizieren.
Woher erhalten
Dieses Ereignis kann aus der OE_ORDER_HOLDS_ALL Tabelle abgeleitet werden, indem der Timestamp identifiziert wird, zu dem eine Kreditprüfungssperre für einen bestimmten Auftragskopf freigegeben wird.
Erfassen
Verwenden Sie den Freigabe-Timestamp für kreditbezogene Sperren aus OE_ORDER_HOLDS_ALL.
Ereignistyp
inferred
|
|||
|
Kommissionierung freigegeben
|
Dieses Ereignis markiert den Zeitpunkt, an dem die Verkaufsauftragspositionen für das Lager freigegeben werden, damit die Kommissionieraktivitäten beginnen können. Es ist eine explizite Aktion, die Kommissionierscheine erstellt und den Auftrag für die Lagerarbeiter sichtbar macht. | ||
|
Warum es wichtig ist
Diese Aktivität initiiert den physischen Fulfillment-Prozess. Die Analyse der Zeit von diesem Punkt bis 'Waren versandt' offenbart die Effizienz der Lagerabläufe und potenzielle Picking-Engpässe.
Woher erhalten
Dies ist ein explizites Ereignis, das im Oracle Shipping Execution Modul erfasst wird. Es kann identifiziert werden, wenn sich der Status der Lieferdetails in WSH_DELIVERY_DETAILS auf 'Released to Warehouse' oder 'Transactable' ändert.
Erfassen
Timestamp, wenn sich WSH_DELIVERY_DETAILS.RELEASED_STATUS auf 'S' (Submitted) ändert.
Ereignistyp
explicit
|
|||
|
Rechnung an Kunden gesendet
|
Diese Aktivität repräsentiert den Zeitpunkt, an dem die Rechnung an den Kunden übermittelt wird, entweder durch Druck oder auf elektronischem Wege. Dies wird typischerweise abgeleitet, da es nicht immer ein expliziter, separater Event von der Erstellung ist. | ||
|
Warum es wichtig ist
Markiert den offiziellen Beginn der Zahlungsfrist des Kunden. Verzögerungen zwischen Rechnungsstellung und Versand können den Cashflow negativ beeinflussen und zu verspäteten Zahlungen führen.
Woher erhalten
Dies kann aus dem LAST_PRINTED_DATE der RA_CUSTOMER_TRX_ALL Tabelle abgeleitet werden. Bei elektronischen Rechnungen kann es erforderlich sein, die Protokolle eines externen Dokumentenversandsystems zu prüfen.
Erfassen
Verwenden Sie die LAST_PRINTED_DATE aus RA_CUSTOMER_TRX_ALL oder Logs von Drittanbieter-Tools.
Ereignistyp
inferred
|
|||
|
Waren geliefert
|
Diese Aktivität signalisiert, dass die Sendung den Kunden erreicht hat. Die standardmäßige Oracle EBS erfasst diesen Event nicht, daher muss er typischerweise abgeleitet oder von externen Spediteursystemen importiert werden. | ||
|
Warum es wichtig ist
Unerlässlich für die Messung von On-Time-Delivery-KPIs und das Verständnis der gesamten Customer Experience. Die Lücke zwischen Versand und Zustellung hebt die Performance des Spediteurs hervor.
Woher erhalten
Erfordert Systemanalyse. Diese Daten sind in Oracle EBS nicht nativ verfügbar und müssen von externen Spediteur-Datenfeeds oder in das System integrierten Logistikplattformen bezogen werden.
Erfassen
Abgeleitet aus externen Spediteurdaten oder angenommen auf der Grundlage einer standardmäßigen Transitzeit nach 'Waren verschickt'.
Ereignistyp
inferred
|
|||