Ihr Order-to-Cash-Daten-Template für die Kundenauftragsbearbeitung
Ihr Order-to-Cash-Daten-Template für die Kundenauftragsbearbeitung
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten für das Tracking
- Praktische Anleitung zur Datenextraktion
Order-to-Cash – Auftragsmanagement Attribute
| Name | Beschreibung | ||
|---|---|---|---|
| `Verkaufsauftrag` SalesOrder | Der eindeutige Identifikator für einen Kundenauftrag, der als primärer Case für den Order-to-Cash-Prozess dient. | ||
| Beschreibung Die Kundenauftragsnummer identifiziert jeden Kundenauftrag über seinen gesamten Lebenszyklus hinweg eindeutig. Sie fungiert als roter Faden, der alle damit verbundenen Aktivitäten verbindet, von der ersten Erstellung und Bestätigung über die Erfüllung, Rechnungsstellung bis hin zur endgültigen Zahlung. Im Process Mining ist dieses Attribut unerlässlich, um alle zusammengehörigen Ereignisse zu einem einzigen Case zusammenzufassen. Die Analyse des Prozesses nach Sales Order ermöglicht eine vollständige End-to-End-Sicht, was die Berechnung der gesamten Durchlaufzeiten, die Identifizierung von Prozessvarianten für einzelne Aufträge und die Verfolgung des Weges eines Auftrags durch verschiedene Abteilungen und Systeme ermöglicht. Bedeutung Dies ist die Case-ID. Sie verknüpft alle Prozess-Ereignisse miteinander, was es ermöglicht, den End-to-End-Verlauf eines einzelnen Kundenauftrags zu verfolgen. Datenquelle Dieser Identifikator findet sich in der Regel in der Header-Tabelle für Kundenaufträge in Oracle Fusion, wie z.B. DOO_HEADERS_ALL. Konsultieren Sie die Oracle Fusion Financials Dokumentation. Beispiele SO-100567SO-100568SO-100569 | |||
| Aktivitätsname ActivityName | Der Name des spezifischen Geschäftsereignisses oder den Antrag bearbeitet.er Aufgabe, die innerhalb des Kundenauftragsprozesses aufgetreten ist. | ||
| Beschreibung Dieses Attribut beschreibt den Schritt, der zu einem bestimmten Zeitpunkt für einen Kundenauftrag ausgeführt wurde, wie z.B. „Sales Order Created“, „Goods Shipped“ oder „Payment Received“. Die Abfolge dieser Aktivitäten bildet den Prozessfluss für jeden Case. Die Analyse des ActivityName ist die Basis für Process Mining. Sie ermöglicht die Visualisierung der Prozessdarstellung (Process Map), die Erkennung verschiedener Prozessvarianten und die Identifizierung von Engpässen, an denen sich Fälle ansammeln. Sie ist die Grundlage für die Berechnung von Übergangszeiten zwischen Schritten und das Verständnis der operativen Abfolge des Order-to-Cash-Prozesses. Bedeutung Dieses Attribut definiert die Schritte in der Prozesskarte, was die Visualisierung und Analyse des Prozessflusses ermöglicht. Datenquelle Dies ist ein abgeleitetes Attribut, konstruiert durch die Zuordnung von Transaktionsstatus oder Event-Typn aus verschiedenen Oracle Fusion Tabellen (z.B. Auftragsstatus, Versandstatus, Rechnungsstatus) zu einer standardisierten Listee von Aktivitätsnamen. Beispiele `Verkaufsauftrag` erstelltWaren versandtRechnung erstellt`Zahlung erhalten` | |||
| Ereigniszeit EventTime | Der Zeitstempel, der anzeigt, wann eine bestimmte Aktivität oder ein Event für einen Kundenauftrag stattfand. | ||
| Beschreibung Dieses Attribut liefert Datum und Uhrzeit für jede Aktivität im Prozess und definiert so die chronologische Abfolge der Ereignisse. Als zeitliches Basis der Prozessanalyse dokumentiert es exakt, wann jeder Schritt stattgefunden hat. Im Process Mining ist die Ereigniszeitpunkt (Event Time) wichtig für die Berechnung von Durchlaufzeiten, der Zeitspanne zwischen Aktivitäten und der gesamten Case-Laufzeit. Sie ermöglicht Leistungsfähigkeit-Analysen, die Identifizierung von Engpässen anhand von Wartezeiten sowie die Überwachung der Einhaltung von Service Level Agreements (SLAs). Alle zeitbasierten KPIs und Dashboards hängen von der Präzision dieses Attributs ab. Bedeutung Dieser Zeitstempel ist unerlässlich für die chronologische Reihenfolge der Ereignisse und die Berechnung aller zeitbasierten Metriken, wie Durchlaufzeiten und Dauern. Datenquelle Dies ist ein abgeleitetes Attribut, das aus verschiedenen Zeitstempel-Feldern über unterschiedliche Oracle Fusion Tabellen bezogen wird, wie z.B. Auftrags-, Versand-, Rechnungs- und Zahlungsdatum. Beispiele 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| Aktuelles Lieferdatum ActualDeliveryDate | Das Datum, an dem die Waren tatsächlich an den Kunden geliefert wurden. | ||
| Beschreibung Dieses Attribut erfasst das endgültige Lieferdatum, welches den Abschluss des Fulfillment-Teils des Prozesses markiert. Es ist das tatsächliche Ergebnis, an dem geplante oder angeforderte Daten gemessen werden. Dieses Datum wird mit dem RequestedDeliveryDate verglichen, um die pünktliche Lieferleistung zu berechnen. Es ist eine kritische Eingabe für den KPI 'Pünktlichkeitsrate der Lieferung' und das Dashboard 'Liefer-SLA' und liefert ein klares Maß für die Effektivität von Logistik und Lieferkettenmanagement. Bedeutung Dies ist das tatsächliche Ergebnisdatum, das zur Berechnung der Pünktlichkeitsraten der Lieferung verwendet wird und zur Bewertung der Fulfillment-Leistung im Vergleich zu Kundenanfragen dient. Datenquelle Stammt aus Versand- und Liefertransaktionstabellen in Oracle Fusion. Konsultieren Sie die Oracle Fusion Financials Dokumentation. Beispiele 2023-05-202023-06-032023-05-25 | |||
| Angefordertes Lieferdatum RequestedDeliveryDate | Das Lieferdatum für den Auftrag, wie vom Kunden angefordert. | ||
| Beschreibung Dieses Attribut erfasst das Datum, an dem der Kunde die Waren erhalten möchte. Es dient als wichtiges Leistungsziel für den Fulfillment-Teil des Order-to-Cash-Prozesses. Dieses Datum ist unerlässlich für die Berechnung des KPIs 'Pünktlichkeitsrate der Lieferung' und zur Unterstützung des Dashboards 'Liefer-Service-Level-Agreement (SLA)'. Durch den Vergleich dieses Datums mit dem ActualDeliveryDate kann die Organisation ihre Fähigkeit messen, Kundenerwartungen zu erfüllen, und die Ursachen für Lieferverzögerungen identifizieren. Bedeutung Dient als Baseline zur Messung der Leistungsfähigkeit bei pünktlicher Lieferung und der Einhaltung von Service Level Agreements (SLA). Datenquelle Typischerweise in den Kundenauftragspositionstabellen in Oracle Fusion zu finden. Konsultieren Sie die Oracle Fusion Financials Dokumentation. Beispiele 2023-05-202023-06-012023-05-25 | |||
| Benutzername UserName | Der Name oder den Antrag bearbeitet.ie ID des Benutzers, der den Antrag bearbeitet.ie `Activity` ausgeführt hat. | ||
| Beschreibung Dieses Attribut identifiziert den Mitarbeiter oder Systembenutzer, der für die Ausführung eines bestimmten Prozessschritts verantwortlich ist. Es kann verwendet werden, um die Leistung auf Benutzerebene, die Arbeitslastverteilung und die Einhaltung von Standardverfahren zu analysierenn. Die Analyse nach Benutzer hilft bei der Identifizierung von Schulungsbedarf, der Anerkennung von leistungsstarken Einzelpersonen oder Teams und der Untersuchung von Abweichungen, die durch spezifische Benutzer verursacht wurden. Es ist auch wertvoll für Compliance- und Audit-Zwecke, um zu verfolgen, wer welche Aktionen durchgeführt hat. Bedeutung Ermöglicht die Analyse der Leistungsfähigkeit nach Benutzer, Arbeitslastverteilung und die Identifizierung manueller Rework-Muster, die an Einzelpersonen gebunden sind. Datenquelle Typischerweise aus Feldern wie CREATED_BY oder LAST_UPDATED_BY in Oracle Fusion Transaktionstabellen bezogen, oft verknüpft mit einer Benutzerstammtabelle wie FND_USER. Beispiele john.smithjane.doesystem_batch_user | |||
| Gesamtbetrag des Kundenauftrags SalesOrderTotalAmount | Der Gesamtbetrag des Kundenauftrags. | ||
| Beschreibung Dieses Attribut repräsentiert den Gesamtbetrag, der den Antrag bearbeitet.em Kunden für den gesamten Kundenauftrag berechnet wird. Er umfasst die Summe aller Positionen, Steuern und sonstigen Gebühren, bevor Rabatte angewendet werden. In der Prozessanalyse ist dieses Attribut wichtig für wertbasiertes Process Mining. Es ermöglicht die Segmentierung von Aufträgen nach Wert (z.B. hochwertige vs. geringwertige Aufträge), um zu sehen, ob sie unterschiedlichen Prozesspfaden folgen oder unterschiedliche Durchlaufzeiten haben. Es hilft auch, Prozessoptimierungsbemühungen auf die finanziell bedeutendsten Fälle zu priorisieren. Bedeutung Ermöglicht eine Analyse der finanziellen Auswirkungen, die hilft, Prozessoptimierungen bei hochwertigen Aufträgen zu priorisieren und Kostentreiber zu verstehen. Datenquelle Typischerweise in Kundenauftragsheader-Tabellen in Oracle Fusion zu finden. Konsultieren Sie die Oracle Fusion Financials Dokumentation. Beispiele 5250.00125000.75980.50 | |||
| Ist automatisiert IsAutomated | Ein `Indikator`, der anzeigt, ob eine `Aktivität` automatisch vom `System` oder manuell von einem `Benutzer` durchgeführt wurde. | ||
| Beschreibung Dieses boolesche Attribut unterscheidet zwischen systemgesteuerten Ereignisse (z.B. automatisierte Kreditprüfung, systemgenerierte Rechnung) und manuellen Benutzeraktionen. Es wird in der Regel basierend auf dem Benutzernamen abgeleitet, der mit einer Aktivität verknüpft ist, wobei eine generische System-ID auf Automatisierung hinweist. Die Analyse dieses Attributs hilft bei der Messung des Automatisierungsgrades im Prozess und ist eine direkte Eingabe für den KPI 'Anteil manuell nachbearbeiteter Aufträge'. Es kann Möglichkeiten für weitere Automatisierung aufzeigen, indem es darstellt, welche manuellen Schritte am zeitaufwendigsten oder fehleranfälligsten sind. Bedeutung Hilft, den Automatisierungsgrad im Prozess zu quantifizieren und Möglichkeiten zur Reduzierung kostspieliger manueller Eingriffe zu identifizieren. Datenquelle Dies ist ein abgeleitetes Feld, oft basierend auf einer Regel, die auf das Attribut BenutzerName angewendet wird. Zum Beispiel, wenn der Benutzer 'SYSTEM' oder 'BATCH' ist, wird dieses Flag auf 'wahr' gesetzt. Beispiele JaNein | |||
| Kundenname CustomerName | Der Name des Kunden, der den Antrag bearbeitet.en Vertriebsauftrag aufgegeben hat. | ||
| Beschreibung Dieses Attribut identifiziert den rechtlichen Namen des Kundenkontos, das mit dem Kundenauftrag verknüpft ist. Es ist eine Schlüsseldimension für die Segmentierung und Analyse des Prozesses aus einer kundenorientierten Sichtweise. Die Analyse nach Kunde hilft zu identifizieren, ob bestimmte Kunden längere Durchlaufzeiten, mehr Nacharbeit oder spezifische Prozessabweichungen aufweisen. Diese Erkenntnis kann geverwendet werden, um den Kundenservice zu verbessern, Prozesse für Schlüsselkunden anzupassen und Probleme zu untersuchen, die die Kundenzufriedenheit beeinflussen. Bedeutung Ermöglicht eine kundenzentrierte Analyse, um Prozessprobleme zu identifizieren, die spezifische Kunden betreffen, und die Kundenzufriedenheit zu verbessern. Datenquelle Stammt aus den KundenstammDatentabellen (z.B. HZ_PARTIES) und ist über eine Kunden-ID mit dem Kundenauftrag verknüpft. Beispiele Global Corp Inc.Innovate Solutions Ltd.Tech Dienste LLC | |||
| Vertriebskanal SalesChannel | Der Kanal, über den der Kundenauftrag eingegangen ist. | ||
| Beschreibung Dieses Attribut kategorisiert den Ursprung des Kundenauftrags, wie z.B. 'Web', 'Direktverkauf', 'Partner' oder 'EDI'. Es liefert Kontext darüber, wie der Auftrag in die Organisation gelangt ist. Die Segmentierung des Prozesses nach Vertriebskanal ist maßgeblich für das Dashboard 'Vertriebskanal-Leistungsfähigkeit-Übersicht'. Sie hilft, die Effizienz, Durchlaufzeiten und Fehlerraten verschiedener Kanäle zu vergleichen, um zu identifizieren, welche am effektivsten sind und welche Prozessoptimierungen oder weitere Automatisierung erfordern könnten. Bedeutung Unterstützt die Leistungsanalyse nach Kanal und hilft, die effizientesten und am wenigsten effizienten Kanäle für die Auftragsabwicklung zu identifizieren. Datenquelle Diese Informationen können in einem dedizierten Feld im Kundenauftragsheader gespeichert sein. Konsultieren Sie die Oracle Fusion Financials Dokumentation. Beispiele DirektvertriebWeb-PortalEDIReseller | |||
| Zahlungsfälligkeitsdatum PaymentDueDate | Das Datum, bis zu dem der Kunde die Rechnung begleichen muss. | ||
| Beschreibung Das Zahlungsfälligkeitsdatum wird basierend auf dem Rechnungsdatum und den mit dem Kunden vereinbarten Zahlungsbedingungen berechnet. Es legt die Frist für den pünktlichen Zahlungseingang fest. Dieses Attribut ist maßgeblich für den KPI 'Pünktlichkeitsrate des Zahlungseingangs'. Durch den Vergleich des PaymentDueDate mit dem tatsächlichen Zahlungseingangsdatum kann das System feststellen, ob eine Zahlung pünktlich oder verspätet erfolgte, was die Überwachung der Debitorenbuchhaltung (Accounts Receivable)sleistung und das Cashflow-Management unterstützt. Bedeutung Dient als Stichtag für die Berechnung der Pünktlichkeitsrate von Zahlungen, was ein Schlüsselindikator für die Effizienz des Cashflows ist. Datenquelle In den Tabellen der Debitorenbuchhaltung (Accounts Receivable) oder den Antrag bearbeitet.en Rechnungstabellen innerhalb von Oracle Fusion zu finden, wie z. B. AR_PAYMENT_SCHEDULES_ALL. Beispiele 2023-06-192023-07-012023-06-25 | |||
| `Versandart` ShippingMethod | Die Methode oder den Antrag bearbeitet.er Spediteur, der für den Versand der Waren an den Kunden verwendet wurde. | ||
| Beschreibung Dieses Attribut beschreibt den Logistikdienstleister oder den Antrag bearbeitet.as Servicelevel, das für die Lieferung verwendet wurde, wie z.B. 'Landfracht', 'Air Express' oder 'Lokaler Kurierdienst'. Diese Informationen sind wichtig für das Dashboard 'Compliance der Versandmethoden'. Sie ermöglicht den Vergleich der pünktlichen Lieferleistung und der Versandkosten über verschiedene Methoden und Spediteure hinweg und hilft so, die Logistikstrategie und die Auswahl von Anbietern zu optimieren. Bedeutung Unterstützt direkt die Logistikanalyse, indem es den Leistungsfähigkeit-Vergleich verschiedener Versanddienstleister und -methoden ermöglicht. Datenquelle Verfügbar in den Versand- und Erfüllungstabellen innerhalb von Oracle Fusion. Konsultieren Sie die Oracle Fusion Financials Dokumentation. Beispiele FedEx GroundUPS Next Day AirDHL International | |||
| Auftragsart OrderType | Eine Klassifizierung für den Verkaufsauftrag, z. B. 'Standardauftrag' oder 'Rücksendung'. | ||
| Beschreibung Die Auftragsart wird verwendet, um Kundenaufträge nach ihrem Geschäftszweck zu kategorisieren. Gängige Typn umfassen Standardverkäufe, Serviceaufträge, Retouren-Autorisierungen (RMAs) und interne Aufträge. Die Analyse des Prozesses nach Auftragsart ist wichtig, da verschiedene Typn oft unterschiedliche Prozessabläufe und Leistungsziele aufweisen. Diese Segmentierung hilft, beabsichtigte und erwartete Prozessvariationen zu verstehen und verhindert, dass diese als Abweichungen fehlinterpretiert werden. Bedeutung Ermöglicht die Segmentierung verschiedener, legitimer Prozessflüsse (z. B. Standard vs. Retouren), um eine faire und genaue Analyse zu sicherstellen. Datenquelle Typischerweise als Feld in der Kundenauftragsheader-Tabelle in Oracle Fusion verfügbar. Konsultieren Sie die Oracle Fusion Financials Dokumentation. Beispiele Standard-KundenauftragRetouren-AutorisierungServiceauftrag | |||
| Geschäftseinheit BusinessUnitName | Der Name der internen Geschäftseinheit, die für den Kundenauftrag verantwortlich ist. | ||
| Beschreibung Dieses Attribut repräsentiert die spezifische Abteilung oder operative Einheit innerhalb des Unternehmens, die die Transaktion besitzt. Es ermöglicht Leistungsvergleiche zwischen verschiedenen Teilen der Organisation. Die Segmentierung des Prozesses nach Geschäftseinheit hilft, Variationen in Effizienz, Kosten und Compliance im gesamten Unternehmen zu identifizieren. Diese Analyse kann Best Practices in leistungsstarken Einheiten aufzeigen, die geteilt werden können, oder leistungsschwache Einheiten hervorheben, die gezielte Prozessoptimierungen benötigen. Bedeutung Ermöglicht Leistungsfähigkeit-Benchmarking und Prozesskonsistenzanalyse über verschiedene Organisationseinheiten hinweg. Datenquelle Typischerweise im Kundenauftragsheader verfügbar und mit der in Oracle Fusion definierten Organisationsstruktur verknüpft. Beispiele BU-NordamerikaBU-EMEAGlobal Dienste | |||
| Ist Liefertreue IsOnTimeDelivery | Ein berechnetes Flag, das "wahr" ist, wenn die tatsächliche Lieferung am oder vor dem angeforderten Lieferdatum erfolgte. | ||
| Beschreibung Dieses boolesche Attribut wird durch den Vergleich des ActualDeliveryDate mit dem RequestedDeliveryDate abgeleitet. Es liefert einen einfachen, Case-bezogenen Indikator für die Lieferleistung. Dieses Flag ist die Grundlage für die Berechnung des aggregierten KPIs 'Pünktlichkeitsrate der Lieferung'. Es vereinfacht Filterung und Analyse und ermöglicht Benutzern, schnell alle verspäteten Aufträge zu isolieren, um eine Ursachenanalyse der zu Verzögerungen beitragenden Faktoren durchzuführen. Bedeutung Misst direkt die Erfüllungs-Leistungsfähigkeit im Vergleich zu Kundenerwartungen und vereinfacht die Analyse verspäteter Aufträge. Datenquelle Dies ist ein berechnetes Feld. Die Logik ist: ActualDeliveryDate <= RequestedDeliveryDate. Beispiele JaNein | |||
| Ist Rechnung korrigiert IsInvoiceCorrected | Ein Flag, das anzeigt, ob eine Rechnung nach ihrer ursprünglichen Erstellung korrigiert oder überarbeitet wurde. | ||
| Beschreibung Dieses boolesche Attribut ist 'wahr', wenn eine Rechnung einen Korrekturprozess durchlief, angezeigt durch das Vorhandensein einer Aktivität 'Rechnung korrigiert'. Es kennzeichnet Fälle, die Nacharbeit in der Rechnungsstellungsphase beinhalteten. Dies ist eine wichtige Eingabe für das Dashboard 'Rechnungsgenauigkeits- & Nacharbeitsanalyse' und den KPI 'Rechnungs-Nacharbeitsrate'. Es hilft, das Ausmaß von Rechnungsfehlern zu quantifizieren und ermöglicht eine Ursachenanalyse, um zu identifizieren, warum Korrekturen erforderlich sind, mit dem Ziel, manuelle Arbeit und Zahlungsverzögerungen zu reduzieren. Bedeutung Identifiziert Rechnungs-Rework, der ein Schlüsselindikator für Prozesseffizienz, Datenqualitätsprobleme und potenzielle Zahlungsverzögerungen ist. Datenquelle Dies ist ein berechnetes Feld, das in der Regel für einen Case auf 'wahr' gesetzt wird, wenn eine Aktivität 'Rechnung korrigiert' in seinem Event Log existiert. Beispiele NeinJa | |||
| Ist verspätete Zahlung IsLatePayment | Ein berechnetes Flag, das "wahr" ist, wenn die Zahlung nach dem Fälligkeitsdatum eingegangen ist. | ||
| Beschreibung Dieses boolesche Attribut wird durch den Vergleich des tatsächlichen Zahlungseingangsdatums mit dem PaymentDueDate abgeleitet. Es liefert einen klaren Indikator dafür, ob eine Rechnung pünktlich bezahlt wurde. Dieses Attribut wird zur Berechnung des KPIs 'Pünktlichkeitsrate der Zahlung' verwendet. Es ermöglicht eine einfache Segmentierung von pünktlichen gegenüber verspäteten Zahlungen, um die Merkmale säumiger Kunden, häufige Gründe für Verzögerungen und die finanziellen Auswirkungen auf das Working CAPItal zu analysierenn. Bedeutung Misst direkt die Effektivität der Zahlungseintreibung und vereinfacht die Analyse überfälliger Zahlungen. Datenquelle Dies ist ein berechnetes Feld. Die Logik ist: PaymentReceivedDate > PaymentDueDate. Beispiele NeinJa | |||
| Kundenland CustomerCountry | Das Land, in dem sich der Kunde befindet. | ||
| Beschreibung Dieses Attribut gibt das Land aus der Liefer- oder Rechnungsadresse des Kunden an. Es ist eine Schlüsseldimension für die geografische Analyse. Die Segmentierung des Prozesses nach Land kann regionale Unterschiede in der Prozess-Performance, den Durchlaufzeiten oder den Antrag bearbeitet.em Zahlungsverhalten aufzeigen. Dies ist wertvoll, um den Einfluss lokaler Vorschriften, logistischer Herausforderungen und Marktbedingungen auf den Order-to-Cash-Prozess zu verstehen. Bedeutung Ermöglicht eine geografische Analyse, um regionale Variationen in Prozesseffizienz, Compliance und Kundenverhalten zu identifizieren. Datenquelle Stammt aus KundenstammDatentabellen (HZ_LOCATIONS, HZ_PARTY_SITES), die mit dem Kundenauftrag verknüpft sind. Beispiele USADeutschlandJapan | |||
| Letzte Datenaktualisierung LastUpdateDate | Der Zeitstempel, der den Antrag bearbeitet.en Zeitpunkt der letzten Aktualisierung der Daten dieses Ereignisse aus dem Quellsystem angibt. | ||
| Beschreibung Dieses Attribut erfasst, wann die Daten zuletzt aus dem Process Mining Datenset extrahiert oder aktualisiert wurden. Es bietet Transparenz über die Aktualität der analysierten Daten. Diese Information ist für Benutzer wichtig, um zu verstehen, wie aktuell die Prozessanalyse ist. Sie hilft, Erwartungen bezüglich der Aktualität der Daten zu managen und ist wichtig für die Einrichtung und Überwachung von Datenaktualisierungszeitplänen. Bedeutung Kennzeichnet die Aktualität der Daten, damit Anwender:innen sehen, wie aktuell ihre Prozessanalyse ist. Datenquelle Dieser Wert wird während jedes Datenextraktions- und Transformationszyklus generiert und in den Datensatz integriert. Beispiele 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Produktname ProductName | Der Name des Produkts oder den Antrag bearbeitet.er Dienstleistung, die verkauft wird. | ||
| Beschreibung Dieses Attribut spezifiziert den Artikel auf der Kundenauftragsposition. Wenn ein Auftrag mehrere Positionen hat, kann der Case auf Positionsebene analysiert werden, oder den Antrag bearbeitet.ieses Attribut könnte auf Headerebene aggregiert werden. Die Analyse nach Produkt hilft zu verstehen, ob bestimmte Produkte mit komplexeren oder problematischeren Prozessabläufen verbunden sind, wie häufige Lieferverzögerungen oder Zahlungsprobleme. Dies kann Produktmanagement- und Lieferkettenmanagementnstrategien beeinflussen. Bedeutung Ermöglicht die Analyse der Prozess-Leistungsfähigkeit für verschiedene Produkte und hebt Artikel hervor, die komplexe Erfüllungs- oder Rechnungsstellungspfade aufweisen können. Datenquelle Stammt aus den Kundenauftragspositionstabellen und ist mit einer Produktstammtabelle verknüpft. Konsultieren Sie die Oracle Fusion Financials Dokumentation. Beispiele Standard Widget X1Premium-ServicepaketKomponente Y2-B | |||
| Quellsystem SourceSystemIdentifier | Identifiziert das Quellsystem, aus dem die Event-Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut spezifiziert den Ursprung der Daten, was besonders nützlich in Umgebungen ist, in denen mehrere Systeme am Order-to-Cash-Prozess beteiligt sind. Zum Beispiel könnten AuftragsDaten aus Oracle Fusion stammen, während VersandDaten aus einem Drittanbieter-Logistiksystem stammen könnten. In der Analyse hilft dies beim Verständnis der Datenherkunft und kann verwendet werden, um die Prozessansicht nach Ereignisse aus spezifischen Systemen zu filtern. Es ist wesentlich für die Datenvalidierung und die Identifizierung von Prozessfragmentierung über verschiedene IT-Infrastrukturen hinweg. Bedeutung Bietet Kontext zur Datenherkunft, was für die Daten Governance und Fehlerbehebung in Multi-System-Umgebungen wichtig ist. Datenquelle Dies ist in der Regel ein statischer Wert, der während der Datenextraktion und -transformation hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Rechnungsnummer InvoiceNumber | Die eindeutige Kennung für die Kundenrechnung. | ||
| Beschreibung Dieses Attribut ist die eindeutige Nummer, die der aus dem Kundenauftrag generierten Rechnung zugewiesen wird. Sie verknüpft die Verkaufs- und Fulfillment-Aktivitäten mit dem finanziellen Abwicklungsteil des Prozesses. Während der Sales Order den Antrag bearbeitet.ie primäre Case-ID ist, ist die Rechnungsnummer wichtig für die Analyse der Rechnungsstellungs- und Zahlungs-Subprozesse. Sie ist unerlässlich für die Verfolgung von Rechnungskorrekturen, Streitigkeiten und den Zahlungsstatus und unterstützt Dashboards wie 'Rechnungsgenauigkeits- & Nacharbeitsanalyse'. Bedeutung Bietet eine wichtige Verbindung zum Debitorenbuchhaltung (Accounts Receivable)sprozess und ist für die Analyse von Rechnungsnachbearbeitung und Zahlungszyklen unerlässlich. Datenquelle Verfügbar in den Transaktionstabellen der Debitorenbuchhaltung (Accounts Receivable) in Oracle Fusion, wie z. B. RA_CUSTOMER_TRX_ALL. Beispiele INV-93485INV-93486INV-93487 | |||
| Zahlungsbedingungen PaymentTerms | Die vereinbarten Konditionen für die Kundenzahlung. | ||
| Beschreibung Dieses Attribut spezifiziert die Bedingungen, unter denen ein Kunde seine Rechnung bezahlen soll, zum Beispiel 'Netto 30' oder 'Netto 60'. Diese Bedingungen sind die Grundlage für die Berechnung des PaymentDueDate. In der Analyse kann die Segmentierung nach Zahlungsbedingungen helfen, Variationen in den Zahlungsdurchlaufzeiten zu erklären. Es liefert Kontext für den KPI 'Pünktlichkeitsrate der Zahlung', da unterschiedliche Bedingungen naturgemäß zu unterschiedlichem Zahlungsverhalten führen. Dies kann die Kreditpolitik und die Cashflow-Prognose beeinflussen. Bedeutung Liefert wichtigen Kontext für die Analyse des Zahlungsverhaltens und hilft, Abweichungen in den Rechnung-zu-Zahlungs-Durchlaufzeiten zu erklären. Datenquelle Verfügbar auf der Ebene des Verkaufsauftrags oder Kundenkontos innerhalb von Oracle Fusion. Konsultieren Sie die Oracle Fusion Financials Dokumentation. Beispiele Netto 30Netto 60Zahlbar bei Erhalt | |||
Order-to-Cash – Auftragsmanagement Aktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
| `Verkaufsauftrag` erstellt | Diese Aktivität markiert den Beginn des Kundenauftragsprozesses und repräsentiert den Moment, in dem ein neuer Kundenauftrag in Oracle Fusion eingegeben wird. Dieses Event wird in der Regel explizit erfasst, wenn ein Benutzer einen neuen AuftragsDatensatz im Auftragsmanagement Modul speichert. | ||
| Bedeutung Als Prozessstart ist diese Aktivität wesentlich für die Messung der gesamten Order-to-Cash-Zykluszeit und die Analyse des Auftragseingangsvolumens. Datenquelle Explizit bei der Erstellung eines KundenauftragsDatensatzes in der Auftragsmanagement Cloud erfasst. Suchen Sie nach Erstellungs-Zeitstempels in der Tabelle DOO_HEADERS_ALL. Erfassen Erfasst vom Erstellungs-Zeitstempel des Verkaufsauftrags-Header-Datensatzes. Ereignistyp explicit | |||
| `Zahlung erhalten` | Diese Aktivität bedeutet, dass die Zahlung des Kunden eingegangen und in der Debitorenbuchhaltung (Accounts Receivable) auf die Rechnung angewendet wurde. Dies wird erfasst, wenn eine Kassenbelegbuchung erfolgt. | ||
| Bedeutung Dies ist ein wichtiger Meilenstein für die Messung der 'Overall Order-to-Cash Durchlaufzeit' und 'On-Time Payment Rate'. Es repräsentiert die Umwandlung des Verkaufs in Bargeld. Datenquelle Dies ist ein explizites Event in Oracle Accounts Receivable. Es wird in Kassenbelegtabellen wie AR_RECEIVABLE_APPLICATIONS_ALL erfasst, wenn ein Beleg auf eine Rechnung angewendet wird. Erfassen Erfasst vom 'apply date'-Zeitstempel des ZahlungseingangsanwendungsDatensatzes in AR. Ereignistyp explicit | |||
| Auftrag abgeschlossen | Die letzte Aktivität im Prozess, die anzeigt, dass alle Positionen des Kundenauftrags erfüllt, fakturiert und abgeschlossen wurden. Der Status des Auftragsheaders wird auf 'Geschlossen' aktualisiert. | ||
| Bedeutung Diese Aktivität markiert das erfolgreiche Ende des KundenauftragsLebenszyklus. Sie ist unerlässlich für die Berechnung von End-to-End-Prozessdauern und die Identifizierung von Zombie-Aufträgen, die nie abgeschlossen werden. Datenquelle Abgeleitet vom Wechsel des Verkaufsauftrags-Header-Status zu 'Closed' in der Tabelle DOO_HEADERS_ALL. Der Zeitstempel dieser letzten Statusänderung dient als Event-Zeit. Erfassen Abgeleitet vom Zeitstempel der Statusänderung zu 'Closed' im Verkaufsauftrags-Header. Ereignistyp inferred | |||
| Auftrag bestätigt | Dieser wichtige Meilenstein bedeutet, dass der Kundenauftrag alle anfänglichen Prüfungen, einschließlich der Kreditgenehmigung, bestanden hat und nun zur Erfüllung freigegeben ist. Dies wird in der Regel abgeleitet, wenn der Auftragsstatus in einen Zustand wie 'Warten auf Versand' oder 'Eingeplant' übergeht. | ||
| Bedeutung Diese Aktivität ist ein wichtiger Meilenstein für die Berechnung der 'Durchschnittlichen Auftragsbestätigungszeit' und kennzeichnet die Übergabe von der Auftragserfassung an den Fulfillment-Prozess. Datenquelle Abgeleitet von einer Änderung des Verkaufsauftrags-Header- oder Positionsstatus zu einem Wert, der den Antrag bearbeitet.ie Bereitstellung zur Erfüllung anzeigt (z. B. 'Awaiting Shipping'). Überprüfen Sie die Statusspalten in DOO_HEADERS_ALL oder DOO_FULFILL_LINES_ALL. Erfassen Abgeleitet vom Zeitstempel, wenn der Auftragsstatus in einen bestätigten oder geplanten Zustand wechselt. Ereignistyp inferred | |||
| Rechnung erstellt | Diese Aktivität stellt die Erstellung der Kundenrechnung im Debitorenbuchhaltung (Accounts Receivable)smodul dar, die in der Regel durch das Versandbestätigungsereignis ausgelöst wird. Ein RechnungsDatensatz wird mit einer eindeutigen Nummer und einem Erstellungsdatum generiert. | ||
| Bedeutung Markiert den offiziellen Beginn des Zahlungseinzug-Zyklus. Es ist die Basis für die Messung der 'Invoice to Payment Time' und der gesamten Cashflow-Effizienz. Datenquelle Dies ist ein explizites Event in Oracle Accounts Receivable (AR). Ein RechnungsDatensatz wird in der Tabelle RA_CUSTOMER_TRX_ALL mit einem Transaktionsdatum erstellt. Erfassen Erfasst vom Erstellungsdatum der Rechnungstransaktion im AR-Modul. Ereignistyp explicit | |||
| Waren versandt | Diese Aktivität markiert den Zeitpunkt, an dem die Waren aus dem Lager versandt wurden und sich auf dem Weg zum Kunden befinden. Sie wird erfasst, wenn eine Versandbestätigungstransaktion in Oracle Shipping verarbeitet wird. | ||
| Bedeutung Dies ist ein wichtiger Meilenstein, der den Antrag bearbeitet.en Abschluss des Fulfillment-Teils des Prozesses signalisiert und die Rechnungsstellung auslöst. Er ist unerlässlich für die Messung von pünktlichen Versand- und Lieferzeiten. Datenquelle Dies ist ein explizites Event, das in Oracle Shipping Execution erfasst wird. Die Versandbestätigungstransaktion erstellt einen Datensatz in Versandtabellen wie WSH_DELIVERY_DETAILS mit einem Versanddatum. Erfassen Erfasst vom 'actual ship date'-Zeitstempel im LieferdetailDatensatz, der den Antrag bearbeitet.er Auftragsposition zugeordnet ist. Ereignistyp explicit | |||
| Auftrag storniert | Stellt die Stornierung eines Kundenauftrags dar, bevor dieser vollständig versandt wurde. Dies kann aus verschiedenen Gründen geschehen und führt zu einem Endstatus von 'Storniert'. | ||
| Bedeutung Dies ist ein kritischer Ausnahme-Pfad. Die Analyse stornierter Aufträge hilft, Ursachen zu identifizieren, wie z.B. Bestandsmängel, Preisprobleme oder Kundenumdenken, was zu Prozessoptimierungen führen kann. Datenquelle Abgeleitet von der Änderung des Verkaufsauftrags-Header- oder Positionsstatus in den Zustand 'Abbrechenled'. Der Zeitstempel dieser Statusänderung wird verwendet, um das Event zu erfassen. Erfassen Abgeleitet vom Zeitstempel der Statusänderung zu 'Abbrechenled' im Auftrags-Header oder in der Position. Ereignistyp inferred | |||
| Auftragsposition abgeschlossen | Stellt den endgültigen Abschluss einer einzelnen Kundenauftragsposition dar, was bedeutet, dass sie vollständig versandt, fakturiert wurde und keine weiteren Transaktionen erwartet werden. Das System aktualisiert den Positionsstatus auf 'Geschlossen'. | ||
| Bedeutung Das Abschließen von Auftragspositionen signalisiert die Erfüllung aller vertraglichen Verpflichtungen für diesen Artikel. Die Analyse hilft, Aufträge zu identifizieren, die lange nach der Erfüllung und Zahlung noch offen bleiben. Datenquelle Abgeleitet vom Wechsel des Erfüllungslinienstatus zu 'Closed' in der Tabelle DOO_FULFILL_LINES_ALL. Der Zeitstempel dieser Statusänderung markiert das Event. Erfassen Abgeleitet vom Zeitstempel der Statusänderung zu 'Closed' in der Erfüllungslinie. Ereignistyp inferred | |||
| Bestand reserviert | Diese Aktivität stellt die Zuweisung oder Reservierung physischen Inventars zur Erfüllung der Kundenauftragsposition dar. Das System reserviert spezifischen Bestand und stellt so sicher, dass dieser verfügbar ist, wenn der Auftrag kommissioniert werden soll. | ||
| Bedeutung Diese Verfolgung hilft, den KPI 'Inventory Allocation Lead Time' zu analysierenn und identifiziert Verzögerungen zwischen Auftragsbestätigung und der Sicherung von Waren. Datenquelle Dieses Event wird oft in Bestands- oder Supply Chain Execution Modulen erfasst. Es kann aus Statusaktualisierungen auf der Fulfillment-Position abgeleitet werden, die anzeigen, dass der Bestand detailliert oder reserviert wurde. Erfassen Abgeleitet von Statusänderungen der Erfüllungslinie im Zusammenhang mit Bestandsreservierung oder -planung. Ereignistyp inferred | |||
| Kreditprüfung durchgeführt | Stellt die Durchführung einer Kreditprüfung für das Kundenkonto dar, um die Kreditwürdigkeit zu beurteilen. Dies ist oft ein automatischer oder manueller Schritt innerhalb des Auftragsbearbeitungs-Workflows, und seine Fertigstellung wird in der Regel als Statusaktualisierung oder abgeschlossene Aufgabe protokolliert. | ||
| Bedeutung Die Analyse der für Kreditprüfungen benötigten Zeit hilft, Engpässe bei der Auftragsgenehmigung zu identifizieren. Dies ist maßgeblich für den KPI 'Credit Check to Confirmed Time'. Datenquelle Kann aus Statusänderungen am Verkaufsauftrag abgeleitet werden, z. B. der Übergang zu einem Status 'Pending Credit Approval', oder aus einem expliziten Event Log in der Kreditmanagementfunktionalität. Erfassen Abgeleitet von Auftragsstatusänderungen oder Zeitstempels, die mit Kreditprüfungsaufgaben verbunden sind. Ereignistyp inferred | |||
| Kreditsperre verhängt | Diese Aktivität tritt auf, wenn ein Kundenauftrag automatisch oder manuell auf Hold gesetzt wird, aufgrund einer fehlgeschlagenen Kreditprüfung oder eines anderen kreditbezogenen Problems. Dies wird in der Regel durch eine Änderung des Hold-Status des Auftrags innerhalb des Systems erfasst. | ||
| Bedeutung Die Verfolgung von Kreditprüfungen ist maßgeblich, um Gründe für Verzögerungen in der Auftragsabwicklung zu identifizieren und um die Effizienz des Freigabeprozesses für Kreditprüfungen zu messen. Datenquelle Abgeleitet von der Anwendung einer Sperre auf den Verkaufsauftrag. Dies wird in der Regel in sperrbezogenen Tabellen wie DOO_HOLDS_ALL, verknüpft mit dem Verkaufsauftrag, erfasst. Erfassen Abgeleitet von einer Datensatzanlage in der Auftrags-Sperrtabelle mit dem Sperrtyp 'Credit'. Ereignistyp inferred | |||
| Rechnung korrigiert | Tritt auf, wenn eine zuvor erstellte Rechnung aufgrund von Fehlern oder Kundenreklamationen geändert, neu ausgestellt oder gutgeschrieben wird. Dies wird in der Regel durch die Erstellung einer Gutschrift oder einer neuen Rechnungsversion erfasst. | ||
| Bedeutung Die Verfolgung von Rechnungskorrekturen ist maßgeblich für den KPI 'Rechnungs-Nacharbeitsrate', der Probleme im Abrechnungsprozess aufzeigt, die Zahlungen verzögern und Verwaltungskosten erhöhen können. Datenquelle Abgeleitet durch die Erstellung einer Gutschrift (verknüpft mit der Originalrechnung) oder einer nachfolgenden Version derselben Rechnung in der Tabelle RA_CUSTOMER_TRX_ALL. Erfassen Abgeleitet durch die Identifizierung von Gutschriften oder Rechnungen, die auf eine vorherige Rechnungstransaktion verweisen. Ereignistyp inferred | |||
| Waren geliefert | Zeigt an, dass der Kunde die Sendung erhalten hat. Diese Information stammt oft von einem externen Spediteur und wird zurück in Oracle Fusion aktualisiert, oder sie kann basierend auf einer Standard-Transitzeit ab dem Versanddatum abgeleitet werden. | ||
| Bedeutung Diese Aktivität ist maßgeblich für die Berechnung des KPIs 'Pünktlichkeitsrate der Lieferung' und die genaue Messung des Kundenservice-Levels. Datenquelle Dies ist oft kein natives Oracle-Event. Es kann erfasst werden, wenn eine Spediteurintegration vorhanden ist, oder berechnet werden, indem eine Standard-Transitzeit zum Datum 'Goods Shipped' hinzugefügt wird. Erfordert Systemanalyse. Erfassen Abgeleitet aus Spediteur-Datenfeeds oder berechnet basierend auf dem Versanddatum plus einer durchschnittlichen Transitzeit. Ereignistyp inferred | |||
| Waren kommissioniert | Stellt die physische Kommissionierung von Waren aus dem Lager zur Auftragserfüllung dar. Dies ist ein wichtiger Schritt im Logistikprozess und wird in der Regel im Lagerverwaltungs- oder Versandmodul erfasst. | ||
| Bedeutung Diese Aktivität bietet Einblick in Lagerabläufe. Verzögerungen zwischen Bestandsreservierung und Kommissionierung können auf Ressourcen- oder Prozessengpässe im Lager hinweisen. Datenquelle Erfasst innerhalb der Oracle Fusion Cloud SCM (Lieferkettenmanagement) Module. Es kann aus der Statusänderung einer Pick-Welle oder eines Pick-Scheins abgeleitet werden, die der Verkaufsauftragsposition zugeordnet sind. Erfassen Abgeleitet vom Abschluss-Zeitstempel der Kommissioniertransaktion in den SCM-Modulen. Ereignistyp inferred | |||
Extraktionsanleitungen
Schritte
- Navigate to Oracle BI Publisher: Melden Sie sich in Ihrer Oracle Fusion Umgebung mit einem Benutzer an, der BI Administrator- oder BI Author-Berechtigungen besitzt. Verwenden Sie das Navigationsmenü, um zu Tools > Reports and Analysen zu gelangen. Klicken Sie auf die Schaltfläche 'Browse Catalog', um den Business Intelligence Katalog zu öffnen.
- Create a New Daten Model: Im BI Katalog bewältigen Sie zu einem geeigneten Ordner (z. B. Shared Folders > Custom). Klicken Sie auf das 'New'-Dropdown-Menü und wählen Sie 'Daten Model'.
- Define the SQL Query Datenset: Im Datenmodell-Editor klicken Sie auf das '+'-Symbol, um einen neuen Datensatz zu erstellen und wählen 'SQL Query'. Ein Dialogfeld wird angezeigt. Benennen Sie den Datensatz (z. B. 'OrderToCash_EventLog'), wählen Sie 'Oracle BI EE' als Datenquelle und 'Standard SQL' als SQL-Typ.
- Enter the SQL Query: Kopieren Sie die vollständige SQL-Abfrage, die im Abschnitt 'query' dieses Dokuments bereitgestellt wird, und fügen Sie sie in das Textfeld der SQL-Abfrage ein. Die Abfrage enthält Parameter für das Start- und Enddatum (:p_start_date und :p_end_date), die von BI Publisher automatisch erkannt werden.
- Configure Daten Model Properties: Nach dem Einfügen der Abfrage klicken Sie auf 'OK'. Navigieren Sie zum Abschnitt 'Properties' im linken Bereich des Datenmodell-Editors. Stellen Sie sicher, dass 'Include Parameter Tags' aktiviert ist. Sie können bei Bedarf auch Standardwerte für die Datumsparameter festlegen.
- View and Save the Daten Model: Klicken Sie auf die Registerkarte 'Daten'. Sie werden möglicherweise aufgefordert, Werte für die Datumsparameter einzugeben. Geben Sie einen kleinen Datumsbereich zum Testen ein. Klicken Sie auf 'View', um eine Datenprobe anzuzeigen. Wenn die Daten korrekt erscheinen, speichern Sie das Datenmodell, indem Sie auf das Speichersymbol klicken und ihm einen aussagekräftigen Namen geben (z. B. 'OrderToCash_EventLog_DM').
- Create a Report from the Daten Model: Nach dem Speichern des Datenmodells klicken Sie auf die Schaltfläche 'Create Report' in der oberen rechten Ecke. Dies öffnet den Berichterstellungsassistenten.
- Configure the Report: Im Assistenten wählen Sie die Option 'Use Daten Model'. Der Assistent führt Sie durch die Layout-Einstellungen. Für einen einfachen CSV-Export können Sie das 'Table'-Layout wählen. Ziehen Sie alle Spalten per Drag & Drop in die Tabelle. Klicken Sie auf 'Next' und deaktivieren Sie dann 'Show Grand Totals Row'. Klicken Sie auf 'Finish', um den Bericht zu speichern. Geben Sie ihm einen Namen wie 'OrderToCash_EventLog_Report'.
- Run the Report: Öffnen Sie den neu erstellten Bericht. Sie werden aufgefordert, die Start- und EndDaten für die Extraktion einzugeben. Geben Sie den gewünschten Datumsbereich an.
- Export the Daten: Sobald der Bericht ausgeführt wird, klicken Sie auf das 'View'-Dropdown-Menü und wählen Sie eine andere Ansichtsoption, z. B. 'View Report'. Suchen Sie dann den Link oder den Antrag bearbeitet.as Symbol 'Export' und wählen Sie 'CSV' als Exportformat. Dadurch wird die Event Log-Datei heruntergeladen.
- Prepare for Upload: Öffnen Sie die heruntergeladene CSV-Datei. Überprüfen Sie, ob die Spaltenüberschriften mit den erforderlichen Attributen übereinstimmen: SalesOrder, ActivityName, Ereigniszeitpunkt (Event Time), BenutzerName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate und IsAutomated. Die Datei ist nun bereit, in das Process-Mining-Tool hochgeladen zu werden.
Konfiguration
- Benutzer Privileges: Sie müssen eine Rolle mit BI Publisher Datenmodell- und Berichterstellungsberechtigungen besitzen, wie z. B. 'BI Administrator' oder 'BI Author'.
- Datenquelle: Die Abfrage ist für die Standard-AnwendungsDatenquelle 'Oracle BI EE' konzipiert, die sich mit der TransaktionsDatenbank (Fusion Apps) verbindet. Eine spezielle Konfiguration ist in der Regel nicht erforderlich.
- Date Range Parameters: Die Abfrage verwendet zwei Parameter, :p_start_date und :p_end_date, um die Daten zu filtern. Es wird dringend empfohlen, Daten in überschaubaren Batches, z. B. 3 bis 6 Monate auf einmal, zu extrahieren, um Berichtstimeouts und Leistungsfähigkeit-Probleme zu vermeiden.
- Business Unit Filterung: Um den Umfang der Extraktion zu begrenzen, können Sie der BaseOrders CTE in der Abfrage eine WHERE-Klausel hinzufügen, um nach einer bestimmten Business Unit ID zu filtern (z. B. AND dhead.SUBMITTING_BU_ID IN ([Ihre Business Unit ID])).
- Order Typ Filterung: Sie können auch nach spezifischen Verkaufsauftragstypen filtern, indem Sie eine Bedingung für dhead.SOURCE_ORDER_TYPE_CODE in der BaseOrders CTE hinzufügen.
- Leistungsfähigkeit: Bei sehr großen Datensätzen über mehrere Jahre kann dieser Single-Query-Ansatz langsam sein. Ziehen Sie in Betracht, ihn außerhalb der Spitzenzeiten auszuführen oder den Antrag bearbeitet.ie Extraktion in kleinere, monatliche Batches aufzuteilen. Stellen Sie sicher, dass die Eigenschaft 'Enable SQL Pruning' im Datenmodell nicht ausgewählt ist, da sie komplexe UNION-Abfragen beeinträchtigen kann.
a Beispielabfrage sql
WITH BaseOrders AS (
SELECT
dhead.HEADER_ID,
dhead.ORDER_NUMBER AS SalesOrder,
dhead.CREATION_DATE,
dhead.CREATED_BY,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.CREATED_BY AND ROWNUM = 1) AS UserName,
dhead.SUBMITTING_BU_ID,
dhead.AMOUNT AS SalesOrderTotalAmount,
hp_sold.PARTY_NAME AS CustomerName,
dhead.SALES_CHANNEL_CODE AS SalesChannel,
dfl.REQUEST_SHIP_DATE AS RequestedDeliveryDate
FROM
DOO_HEADERS_ALL dhead
JOIN
DOO_FULFILL_LINES_ALL dfl ON dhead.HEADER_ID = dfl.HEADER_ID
JOIN
HZ_CUST_ACCOUNTS hc_sold ON dhead.SOLD_TO_CUSTOMER_ID = hc_sold.CUST_ACCOUNT_ID
JOIN
HZ_PARTIES hp_sold ON hc_sold.PARTY_ID = hp_sold.PARTY_ID
WHERE
dhead.OBJECT_VERSION_NUMBER = 1
AND dfl.LINE_NUMBER = 1 -- To avoid duplicating header-level events for each line
AND dhead.CREATION_DATE BETWEEN TO_DATE(:p_start_date, 'YYYY-MM-DD') AND TO_DATE(:p_end_date, 'YYYY-MM-DD')
)
-- 1. Sales Order Created
SELECT
bo.SalesOrder,
'Sales Order Created' AS ActivityName,
bo.CREATION_DATE AS EventTime,
bo.UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN bo.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM BaseOrders bo
UNION ALL
-- 2. Credit Check Performed (inferred from Credit Hold Release)
SELECT
bo.SalesOrder,
'Credit Check Performed' AS ActivityName,
dha.RELEASED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.RELEASED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.RELEASED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.RELEASED_FLAG = 'Y' AND dha.RELEASED_DATE IS NOT NULL
UNION ALL
-- 3. Credit Hold Applied
SELECT
bo.SalesOrder,
'Credit Hold Applied' AS ActivityName,
dha.APPLIED_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dha.APPLIED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dha.APPLIED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HOLDS_ALL dha
JOIN BaseOrders bo ON dha.HEADER_ID = bo.HEADER_ID
WHERE dha.HOLD_CODE = '[Your Credit Check Hold Code]' AND dha.APPLIED_DATE IS NOT NULL
UNION ALL
-- 4. Order Confirmed (inferred from status 'Awaiting Shipping')
SELECT
bo.SalesOrder,
'Order Confirmed' AS ActivityName,
dfl.STATUS_CHANGE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'AWAIT_SHIP'
UNION ALL
-- 5. Inventory Reserved
SELECT
bo.SalesOrder,
'Inventory Reserved' AS ActivityName,
irl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = irl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN irl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM INV_RESERVATIONS irl
JOIN DOO_FULFILL_LINES_ALL dfl ON irl.DEMAND_SOURCE_LINE_ID = dfl.FULFILL_LINE_ID
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE irl.DEMAND_SOURCE_TYPE_ID = 2 -- Order Entry
UNION ALL
-- 6. Goods Picked (inferred from delivery detail status 'Staged')
SELECT
bo.SalesOrder,
'Goods Picked' AS ActivityName,
wdd.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wdd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wdd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_DELIVERY_DETAILS wdd
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wdd.RELEASED_STATUS = 'S' -- 'S' typically means Staged/Picked
UNION ALL
-- 7. Goods Shipped
SELECT
bo.SalesOrder,
'Goods Shipped' AS ActivityName,
wnd.INITIAL_PICKUP_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.STATUS_CODE = 'CL' -- Closed/Shipped
UNION ALL
-- 8. Goods Delivered
SELECT
bo.SalesOrder,
'Goods Delivered' AS ActivityName,
wnd.ULTIMATE_DROPOFF_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = wnd.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
wnd.ULTIMATE_DROPOFF_DATE AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN wnd.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM WSH_NEW_DELIVERIES wnd
JOIN WSH_DELIVERY_ASSIGNMENTS wda ON wnd.DELIVERY_ID = wda.DELIVERY_ID
JOIN WSH_DELIVERY_DETAILS wdd ON wda.DELIVERY_DETAIL_ID = wdd.DELIVERY_DETAIL_ID
JOIN BaseOrders bo ON wdd.SOURCE_HEADER_NUMBER = bo.SalesOrder
WHERE wnd.ULTIMATE_DROPOFF_DATE IS NOT NULL
UNION ALL
-- 9. Invoice Created
SELECT
bo.SalesOrder,
'Invoice Created' AS ActivityName,
rct.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
aps.DUE_DATE AS PaymentDueDate,
CASE WHEN rct.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN AR_PAYMENT_SCHEDULES_ALL aps ON rct.CUSTOMER_TRX_ID = aps.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 10. Invoice Corrected (Credit Memo)
SELECT
bo.SalesOrder,
'Invoice Corrected' AS ActivityName,
rct_cm.TRX_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = rct_cm.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN rct_cm.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM RA_CUSTOMER_TRX_ALL rct_cm
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_cm ON rct_cm.CUSTOMER_TRX_ID = rctl_cm.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_ALL rct_orig ON rct_cm.PREVIOUS_CUSTOMER_TRX_ID = rct_orig.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl_orig ON rct_orig.CUSTOMER_TRX_ID = rctl_orig.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl_orig.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE rctl_orig.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl_cm.LINE_TYPE = 'LINE'
UNION ALL
-- 11. Payment Received
SELECT
bo.SalesOrder,
'Payment Received' AS ActivityName,
araa.APPLY_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = araa.CREATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN araa.CREATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM AR_RECEIVABLE_APPLICATIONS_ALL araa
JOIN RA_CUSTOMER_TRX_ALL rct ON araa.APPLIED_CUSTOMER_TRX_ID = rct.CUSTOMER_TRX_ID
JOIN RA_CUSTOMER_TRX_LINES_ALL rctl ON rct.CUSTOMER_TRX_ID = rctl.CUSTOMER_TRX_ID
JOIN BaseOrders bo ON rctl.INTERFACE_LINE_ATTRIBUTE1 = bo.SalesOrder
WHERE araa.STATUS = 'APP' AND rctl.INTERFACE_LINE_CONTEXT = 'ORDER ENTRY' AND rctl.LINE_TYPE = 'LINE'
UNION ALL
-- 12. Order Line Closed
SELECT
bo.SalesOrder,
'Order Line Closed' AS ActivityName,
dfl.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dfl.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dfl.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_FULFILL_LINES_ALL dfl
JOIN BaseOrders bo ON dfl.HEADER_ID = bo.HEADER_ID
WHERE dfl.STATUS_CODE = 'CLOSED'
UNION ALL
-- 13. Order Closed
SELECT
bo.SalesOrder,
'Order Closed' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CLOSED'
UNION ALL
-- 14. Order Cancelled
SELECT
bo.SalesOrder,
'Order Cancelled' AS ActivityName,
dhead.LAST_UPDATE_DATE AS EventTime,
(SELECT u.USERNAME FROM PER_USERS u WHERE u.USER_GUID = dhead.LAST_UPDATED_BY AND ROWNUM = 1) AS UserName,
bo.SalesOrderTotalAmount,
bo.CustomerName,
bo.SalesChannel,
bo.RequestedDeliveryDate,
NULL AS ActualDeliveryDate,
NULL AS PaymentDueDate,
CASE WHEN dhead.LAST_UPDATED_BY LIKE 'FUSION_APPS%' THEN 'true' ELSE 'false' END AS IsAutomated
FROM DOO_HEADERS_ALL dhead
JOIN BaseOrders bo ON dhead.HEADER_ID = bo.HEADER_ID
WHERE dhead.STATUS_CODE = 'CANCELED'Schritte
- Access the BICC Console: Melden Sie sich bei Ihrer Oracle Fusion Applications Instanz mit einem Benutzer an, der den Antrag bearbeitet.ie Rolle BICC_ADMINISTRATOR besitzt. Navigieren Sie zu Tools und wählen Sie Business Intelligence Cloud Connector aus dem Menü.
- Create a New Offering: Innerhalb der BICC Konsole klicken Sie auf Configure External Storage, um Ihr Ziel zu konfigurieren, welches Oracle Universal Content Management (UCM) oder ein OCI Object Storage Bucket sein kann. Stellen Sie sicher, dass Ihre Verbindungsdetails und AnmeldeHinweisrmationen korrekt sind.
- Initiate a New Extract Job: Navigieren Sie zum Bereich Manage Extract Jobs. Klicken Sie auf das +-Symbol, um einen neuen Job zu erstellen. Geben Sie ihm einen aussagekräftigen Namen, zum Beispiel ProcessMind_O2C_SalesOrder_Extract.
- Select Daten Stores (PVOs): Suchen und fügen Sie in der JobKonfiguration die Public View Objects (PVOs) hinzu, die zur Erfassung des VerkaufsauftragsLebenszyklus erforderlich sind. Sie müssen mehrere PVOs hinzufügen, darunter FscmTopModelAM.DooTopAM.Header, FscmTopModelAM.DooTopAM.FulfillLine, FscmTopModelAM.DooTopAM.HoldInstance, FscmTopModelAM.ScmTopAM.ShipmentLine, FscmTopModelAM.ArTopAM.ReceivableInvoice und FscmTopModelAM.ArTopAM.CashReceiptApplication.
- Configure Columns for Each PVO: Klicken Sie für jedes ausgewählte PVO auf das Actions-Menü und wählen Sie Select Columns. Wählen Sie sorgfältig die Spalten aus, die zur Generierung des Event-Logs benötigt werden, wie HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate und Benutzerkennungen. Eine detaillierte Listee der benötigten Spalten aus jedem PVO finden Sie im Query Manifest.
- Apply Filters for Incremental Loads: Um das Datenvolumen zu verwalten, wenden Sie für jedes PVO einen Filter basierend auf der Spalte LastUpdateDate an. Für den ersten Lauf können Sie einen breiten Datumsbereich auswählen. Für nachfolgende geplante Läufe sollte dieser Filter so konfiguriert werden, dass nur Datensätze extrahiert werden, die seit der letzten Jobausführung aktualisiert wurden.
- Schedule the Extraktion Job: Navigieren Sie zum Bereich Manage Schedule. Erstellen Sie einen neuen Zeitplan für Ihren Job. Es wird empfohlen, den Job außerhalb der Spitzenzeiten auszuführen, z. B. täglich über Nacht, um die Auswirkungen auf die Systemperformance zu minimieren.
- Submit and Monitor the Job: Sobald konfiguriert, reichen Sie den Job ein. Sie können seinen Fortschritt über den Bildschirm Manage Extract Jobs überwachen. Nach erfolgreichem Abschluss sind die Datendateien in Ihrem konfigurierten Cloud-Speicherort im komprimierten CSV-Format verfügbar.
- Transform Raw Daten into an Event Log: Laden Sie die extrahierten CSV-Dateien herunter. BICC liefert RohDaten im Tabellenformat, keinen formatierten Event Log. Sie müssen ein externes Tool (wie Python, ein Datenbankskript oder eine ETL-Plattform) verwenden, um diese Dateien zu verarbeiten. Dies beinhaltet:
- Das Verknüpfen von Daten aus verschiedenen Dateien (z. B. Verknüpfen von RechnungsDaten zurück zum Verkaufsauftrags-Header).
- Das Pivotieren von Datumsspalten in einzelne Aktivitätszeilen. Erstellen Sie beispielsweise aus der Datei FscmTopModelAM.DooTopAM.Header eine Zeile für Sales Order Created mit CreationDate und eine weitere für Order Closed mit ClosedDate.
- Das Mapping von Statuscodes oder Flags zu spezifischen Aktivitäten wie Order Confirmed oder Order Abbrechenled.
- Das Kombinieren aller transformierten Daten in eine einzige Datei mit den erforderlichen Spalten: SalesOrder, ActivityName und Ereigniszeitpunkt (Event Time).
- Format for Upload: Stellen Sie sicher, dass die endgültig transformierte Datei eine einzelne CSV ist, deren Spalten den erforderlichen und empfohlenen Attributen entsprechen. Die Datei ist nun bereit, zu ProcessMind hochgeladen zu werden.
Konfiguration
- PVO Selection: Die Genauigkeit des Event-Logs hängt vollständig von der Auswahl der korrekten PVOs ab. Zu den wichtigsten PVOs gehören FscmTopModelAM.DooTopAM.Header (für Auftragserstellung, Abschluss), FscmTopModelAM.ScmTopAM.ShipmentLine (für Versandereignisse) und FscmTopModelAM.ArTopAM.ReceivableInvoice (für die Rechnungsstellung).
- Incremental Extraktion: Verwenden Sie für wiederkehrende Extraktionen immer den LastUpdateDate-Filter. Dies ist maßgeblich für die Leistungsfähigkeit und vermeidet, denselben Multi-Gigabyte-Datensatz wiederholt zu extrahieren. Der anfängliche vollständige Ladevorgang sollte eine Baseline etablieren, wobei nachfolgende Läufe nur Änderungen erfassen.
- Date Range: Für den ersten historischen Ladevorgang extrahieren Sie einen repräsentativen Zeitraum, z. B. die Daten der letzten 3 bis 6 Monate, um Vollständigkeit mit einem überschaubaren Datenvolumen in Einklang zu bringen. Nachfolgende Läufe erfolgen inkrementell.
- Storage Configuration: BICC kann nach Oracle UCM oder OCI Object Storage exportieren. Die Verwendung von OCI Object Storage wird im Allgemeinen für MassenDaten-Szenarien und eine einfachere Integration mit nachgeschalteten ETL-Tools empfohlen.
- Job Scheduling: Planen Sie Extraktionsjobs außerhalb der Geschäftszeiten, um potenzielle Leistungsfähigkeit-Einbußen im transaktionalen Oracle Fusion Financials System zu vermeiden.
- Prerequisites: Benutzer, die den Job konfigurieren, benötigen die Rolle BICC_ADMINISTRATOR. Sie müssen vorkonfigurierte Cloud-SpeicheranmeldeHinweisrmationen und ein klares Verständnis der nach der Extraktion erforderlichen Datentransformationslogik haben.
a Beispielabfrage config
# BICC Data Store (PVO) and Column Selection Manifest
# This manifest outlines the PVOs and columns to select in the BICC UI for the extract job.
# PVO for Sales Order Header information (Created, Confirmed, Closed, Cancelled events)
PVO: FscmTopModelAM.DooTopAM.Header
Columns:
- HeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Sales Order Created')
- CreatedBy -> UserName (for 'Sales Order Created')
- LastUpdateDate # For incremental filtering
- StatusCode
- SubmittedDate -> EventTime (for 'Order Confirmed')
- SubmittedBy -> UserName (for 'Order Confirmed')
- OrderedTotal -> SalesOrderTotalAmount
- SoldToPartyName -> CustomerName
- SourceSalesChannelCode -> SalesChannel
- RequestShipDate -> RequestedDeliveryDate
- ClosedDate -> EventTime (for 'Order Closed')
- CanceledFlag
- CanceledDate -> EventTime (for 'Order Cancelled')
# PVO for Sales Order Lines (Line Closed event)
PVO: FscmTopModelAM.DooTopAM.FulfillLine
Columns:
- HeaderId -> SalesOrder
- ActualCompletionDate -> EventTime (for 'Order Line Closed')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
- StatusName # To confirm closed status
# PVO for Holds (Credit Hold Applied event)
PVO: FscmTopModelAM.DooTopAM.HoldInstance
Columns:
- SourceHeaderId -> SalesOrder
- CreationDate -> EventTime (for 'Credit Hold Applied')
- CreatedBy -> UserName
- HoldName # To filter for credit-related holds
# PVO for Shipments (Picked, Shipped, Delivered events)
PVO: FscmTopModelAM.ScmTopAM.ShipmentLine
Columns:
- SourceHeaderNumber -> SalesOrder
- PickedDate -> EventTime (for 'Goods Picked')
- ShippedDate -> EventTime (for 'Goods Shipped')
- ActualDeliveryDate -> ActualDeliveryDate & EventTime (for 'Goods Delivered')
- LastUpdateDate # For incremental filtering
- LastUpdatedBy -> UserName
# PVO for Invoices (Invoice Created, Invoice Corrected events)
PVO: FscmTopModelAM.ArTopAM.ReceivableInvoice
Columns:
- InterfaceHeaderAttribute1 -> SalesOrder # Link to SO via reference field
- TrxDate -> EventTime (for 'Invoice Created')
- CreatedBy -> UserName
- DueDate -> PaymentDueDate
- PreviousTrxNumber # If populated, indicates a correction
- CreationDate # Can be used for 'Invoice Corrected' if a new record is made
- LastUpdateDate # For incremental filtering
# PVO for Payments (Payment Received event)
PVO: FscmTopModelAM.ArTopAM.CashReceiptApplication
Columns:
- AppliedCustomerTrxId # ID to link back to the invoice
- ApplyDate -> EventTime (for 'Payment Received')
- CreatedBy -> UserName
- LastUpdateDate # For incremental filtering