Ihr Daten-Template für die Auftragsabwicklung vom Auftrag bis zum Zahlungseingang
Ihr Daten-Template für die Auftragsabwicklung vom Auftrag bis zum Zahlungseingang
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten zur Nachverfolgung
- Praktische Hinweise zum Datenexport
Attribute für die Auftragsabwicklung vom Auftrag bis zum Zahlungseingang
| Name | Beschreibung | ||
|---|---|---|---|
| Kundenauftrag SalesOrder | Die eindeutige Kennung eines Kundenauftrags, der als zentraler Case für den Order-to-Cash-Prozess dient. | ||
| Beschreibung Die Kundenauftragsnummer identifiziert jeden Kundenauftrag während seines gesamten Lebenszyklus eindeutig. Sie bildet den zentralen Bezugspunkt für alle zugehörigen Aktivitäten, von der Erstellung und Bestätigung bis hin zu Erfüllung, Rechnungsstellung und Zahlung. Im Process Mining ist dieses Attribut unverzichtbar, um alle zugehörigen Ereignisse zu einem einzelnen Case zusammenzufassen. Die Analyse nach Kundenauftrag ermöglicht eine durchgängige Sicht. So lassen sich die gesamte Durchlaufzeit berechnen, Prozessvarianten einzelner Aufträge erkennen und der Weg eines Auftrags durch verschiedene Abteilungen und Systeme verfolgen. Warum das wichtig ist Dies ist die Case-ID. Sie verknüpft alle Prozessereignisse und ermöglicht es, den gesamten Ablauf eines einzelnen Kundenauftrags nachzuverfolgen. Woher beziehen Diese Kennung findet sich üblicherweise in der Kopftabelle für Kundenaufträge in Oracle Fusion, zum Beispiel DOO_HEADERS_ALL. Weitere Informationen finden Sie in der Dokumentation zu Oracle Fusion Financials. Beispiele SO-100567SO-100568SO-100569 | |||
| Aktivitätsname ActivityName | Der Name des konkreten Geschäftsereignisses oder der Aufgabe, die im Kundenauftragsprozess stattgefunden hat. | ||
| Beschreibung Dieses Attribut bezeichnet den Schritt, der zu einem bestimmten Zeitpunkt für einen Kundenauftrag ausgeführt wurde, zum Beispiel „Kundenauftrag erstellt“, „Waren versandt“ oder „Zahlung eingegangen“. Die Abfolge dieser Aktivitäten bildet den Prozessfluss für jeden Case. Die Analyse von ActivityName ist eine Grundlage des Process Mining. Sie ermöglicht die Visualisierung der Prozesslandkarte, das Erkennen verschiedener Prozessvarianten und das Auffinden von Engpässen, an denen sich Cases ansammeln. Außerdem bildet sie die Grundlage für die Berechnung der Übergangszeiten zwischen Schritten und für das Verständnis der Abläufe im Order-to-Cash-Prozess. Warum das wichtig ist Dieses Attribut legt die Schritte in der Prozesslandkarte fest und ermöglicht die Visualisierung und Analyse des Prozessflusses. Woher beziehen Dieses abgeleitete Attribut entsteht, indem Transaktionsstatus oder Ereignistypen aus verschiedenen Oracle-Fusion-Tabellen, etwa Auftrags-, Versand- und Rechnungsstatus, einer standardisierten Liste von Aktivitätsnamen zugeordnet werden. Beispiele Vertriebsauftrag erstelltWaren versandtRechnung erstelltZahlung eingegangen | |||
| Ereigniszeitpunkt EventTime | Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis für einen Kundenauftrag stattgefunden hat. | ||
| Beschreibung Dieses Attribut enthält Datum und Uhrzeit jeder Aktivität im Prozess und legt damit die chronologische Abfolge der Ereignisse fest. Es bildet die zeitliche Grundlage der Prozessanalyse und hält genau fest, wann jeder Schritt stattgefunden hat. Im Process Mining ist EventTime entscheidend für die Berechnung von Durchlaufzeiten, Zeitspannen zwischen Aktivitäten und der gesamten Bearbeitungszeit eines Cases. Damit lassen sich die Prozessleistung analysieren, Engpässe anhand von Wartezeiten erkennen und die Einhaltung zeitbezogener Service Level Agreements (SLAs) überwachen. Alle zeitbasierten Kennzahlen und Dashboards hängen von der Genauigkeit dieses Attributs ab. Warum das wichtig ist Dieser Timestamp ist unverzichtbar, um Ereignisse chronologisch zu ordnen und alle zeitbasierten Kennzahlen wie Durchlaufzeiten und Zeitspannen zu berechnen. Woher beziehen Dieses abgeleitete Attribut wird aus verschiedenen Timestamp-Feldern in unterschiedlichen Oracle-Fusion-Tabellen bezogen, etwa aus Erstellungsdatum des Auftrags, Versanddatum, Rechnungsdatum und Zahlungsdatum. Beispiele 2023-04-15T09:00:00Z2023-04-18T14:30:00Z2023-04-20T11:25:00Z | |||
| Automatisiert IsAutomated | Ein Kennzeichen dafür, ob eine Aktivität automatisch vom System oder manuell von einem Benutzer ausgeführt wurde. | ||
| Beschreibung Dieses boolesche Attribut unterscheidet systemgesteuerte Ereignisse, etwa eine automatisierte Bonitätsprüfung oder eine systemgenerierte Rechnung, von manuellen Benutzeraktionen. Es wird üblicherweise anhand des mit einer Aktivität verknüpften Benutzernamens abgeleitet. Eine generische System-ID weist dabei auf eine Automatisierung hin. Die Analyse dieses Attributs hilft, den Automatisierungsgrad des Prozesses zu messen. Es fließt direkt in die Kennzahl „Anteil manuell nachbearbeiteter Aufträge“ ein. Außerdem zeigt es, welche manuellen Schritte am zeitaufwendigsten oder fehleranfälligsten sind und sich daher für eine weitergehende Automatisierung eignen. Warum das wichtig ist Hilft, den Automatisierungsgrad des Prozesses zu messen und Möglichkeiten zur Verringerung kostspieliger manueller Eingriffe zu erkennen. Woher beziehen Dieses abgeleitete Feld basiert häufig auf einer Regel für das Attribut UserName. Lautet der Benutzer beispielsweise „SYSTEM“ oder „BATCH“, wird dieses Kennzeichen auf true gesetzt. Beispiele truefalse | |||
| Benutzername UserName | Der Name oder die ID des Benutzers, der die Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut gibt an, welcher Mitarbeitende oder Systembenutzer für die Ausführung eines bestimmten Prozessschritts verantwortlich war. Es lässt sich verwenden, um die Leistung einzelner Benutzer, die Arbeitslastverteilung und die Einhaltung standardisierter Vorgehensweisen zu analysieren. Die Analyse nach Benutzer hilft, Schulungsbedarf zu erkennen, leistungsstarke Mitarbeitende oder Teams zu identifizieren und Abweichungen zu untersuchen, die durch bestimmte Benutzer verursacht wurden. Außerdem ist sie für Compliance und Audits wertvoll, da sich nachvollziehen lässt, wer welche Aktionen ausgeführt hat. Warum das wichtig ist Ermöglicht die Analyse der Benutzerleistung und der Arbeitslastverteilung sowie das Erkennen manueller Nacharbeitsmuster einzelner Personen. Woher beziehen Wird üblicherweise aus Feldern wie CREATED_BY oder LAST_UPDATED_BY in Oracle-Fusion-Transaktionstabellen bezogen und häufig mit einer Benutzertabelle wie FND_USER verknüpft. Beispiele john.smithjane.doesystem_batch_user | |||
| Gesamtbetrag des Kundenauftrags SalesOrderTotalAmount | Der Gesamtwert des Kundenauftrags in Geld. | ||
| Beschreibung Dieses Attribut gibt den Gesamtbetrag an, der dem Kunden für den gesamten Auftrag berechnet wird. Er umfasst die Summe aller Positionen, Steuern und sonstigen Gebühren vor Abzug von Rabatten. In der Prozessanalyse ist dieses Attribut für wertbasiertes Process Mining entscheidend. Aufträge lassen sich nach ihrem Wert segmentieren, etwa in Aufträge mit hohem und niedrigem Wert, um unterschiedliche Prozesspfade oder Durchlaufzeiten zu erkennen. Außerdem hilft es, Verbesserungsmaßnahmen auf die finanziell bedeutendsten Cases zu konzentrieren. Warum das wichtig ist Ermöglicht die Analyse finanzieller Auswirkungen. So lassen sich Verbesserungen bei Aufträgen mit hohem Wert priorisieren und Kostentreiber erkennen. Woher beziehen In der Regel in Kopftabellen für Kundenaufträge in Oracle Fusion zu finden. Weitere Informationen finden Sie in der Dokumentation zu Oracle Fusion Financials. Beispiele 5250.00125000.75980.50 | |||
| Gewünschtes Lieferdatum RequestedDeliveryDate | Das vom Kunden gewünschte Lieferdatum des Auftrags. | ||
| Beschreibung Dieses Attribut erfasst das Datum, an dem der Kunde die Waren erhalten möchte. Es dient als wichtige Zielgröße für den Erfüllungsteil des Order-to-Cash-Prozesses. Das Datum ist unverzichtbar, um die Kennzahl „Quote termingerechter Lieferungen“ zu berechnen und das Dashboard „Service Level Agreement (SLA) für Lieferungen“ zu unterstützen. Durch den Vergleich mit dem tatsächlichen Lieferdatum kann das Unternehmen messen, ob es die Kundenerwartungen erfüllt, und die Ursachen für Lieferverzögerungen ermitteln. Warum das wichtig ist Dient als Grundlage für die Messung der termingerechten Lieferleistung und der Einhaltung des Service Level Agreements (SLA) mit dem Kunden. Woher beziehen In der Regel in den Tabellen zu Kundenauftragspositionen in Oracle Fusion zu finden. Weitere Informationen finden Sie in der Dokumentation zu Oracle Fusion Financials. Beispiele 2023-05-202023-06-012023-05-25 | |||
| Kundenname CustomerName | Der Name des Kunden, der den Auftrag erteilt hat. | ||
| Beschreibung Dieses Attribut gibt den offiziellen Namen des Kundenkontos an, das dem Kundenauftrag zugeordnet ist. Es ist eine wichtige Dimension, um den Prozess aus Kundensicht zu segmentieren und zu analysieren. Die Analyse nach Kunde zeigt, ob bestimmte Kunden längere Durchlaufzeiten, mehr Nacharbeit oder bestimmte Prozessabweichungen erleben. Diese Erkenntnisse können dazu beitragen, den Kundenservice zu verbessern, Prozesse auf wichtige Kunden abzustimmen und Probleme zu untersuchen, die die Kundenzufriedenheit beeinträchtigen. Warum das wichtig ist Ermöglicht eine kundenzentrierte Analyse, um Prozessprobleme bei bestimmten Kunden zu erkennen und die Kundenzufriedenheit zu verbessern. Woher beziehen Stammt aus Kundenstammdatentabellen, zum Beispiel HZ_PARTIES, und ist über eine Kunden-ID mit dem Kundenauftrag verknüpft. Beispiele Global Corp Inc.Innovate Solutions Ltd.Tech Services LLC | |||
| Tatsächliches Lieferdatum ActualDeliveryDate | Das Datum, an dem die Waren tatsächlich an den Kunden geliefert wurden. | ||
| Beschreibung Dieses Attribut erfasst das endgültige Lieferdatum und markiert damit den Abschluss des Erfüllungsteils des Prozesses. Es bildet das tatsächliche Ergebnis, an dem geplante oder gewünschte Termine gemessen werden. Der Vergleich mit dem gewünschten Lieferdatum zeigt, ob die Lieferung termingerecht erfolgte. Das Datum ist eine wichtige Eingabe für die Kennzahl „Quote termingerechter Lieferungen“ und das Dashboard „Liefer-SLA“. Es ermöglicht eine klare Bewertung der Logistik- und Lieferkettenleistung. Warum das wichtig ist Dieses tatsächliche Lieferdatum dient zur Berechnung der Quote termingerechter Lieferungen und zur Bewertung der Erfüllungsleistung im Vergleich zu den Kundenwünschen. Woher beziehen Stammt aus Versand- und Liefertransaktionstabellen in Oracle Fusion. Weitere Informationen finden Sie in der Dokumentation zu Oracle Fusion Financials. Beispiele 2023-05-202023-06-032023-05-25 | |||
| Vertriebskanal SalesChannel | Der Kanal, über den der Kundenauftrag eingegangen ist. | ||
| Beschreibung Dieses Attribut kategorisiert die Herkunft des Kundenauftrags, zum Beispiel „Web“, „Direktvertrieb“, „Partner“ oder „EDI“. Es zeigt, auf welchem Weg der Auftrag in das Unternehmen gelangt ist. Die Segmentierung nach Vertriebskanal ist entscheidend für das Dashboard „Leistungsübersicht nach Vertriebskanal“. Damit lassen sich Effizienz, Durchlaufzeiten und Fehlerquoten verschiedener Kanäle vergleichen. So wird sichtbar, welche Kanäle am effektivsten sind und wo Prozessverbesserungen oder eine weitergehende Automatisierung sinnvoll sein könnten. Warum das wichtig ist Unterstützt die Leistungsanalyse nach Vertriebskanal und hilft, die effizientesten und am wenigsten effizienten Kanäle für die Auftragsbearbeitung zu erkennen. Woher beziehen Diese Information kann in einem eigenen Feld im Kundenauftragskopf gespeichert sein. Weitere Informationen finden Sie in der Dokumentation zu Oracle Fusion Financials. Beispiele DirektvertriebWebportalEDIWiederverkäufer | |||
| Zahlungsziel PaymentDueDate | Das Datum, bis zu dem der Kunde die Rechnung bezahlen muss. | ||
| Beschreibung Das Zahlungsziel wird anhand des Rechnungsdatums und der mit dem Kunden vereinbarten Zahlungsbedingungen berechnet. Es legt die Frist für den rechtzeitigen Zahlungseingang fest. Dieses Attribut ist entscheidend für die Kennzahl „Quote pünktlicher Zahlungseingänge“. Durch den Vergleich des Zahlungsziels mit dem tatsächlichen Zahlungseingang lässt sich feststellen, ob eine Zahlung pünktlich oder verspätet eingegangen ist. So können Unternehmen die Leistung der Debitorenbuchhaltung überwachen und ihren Cashflow steuern. Warum das wichtig ist Dient als Frist für die Berechnung der Quote pünktlicher Zahlungen, einer wichtigen Kennzahl für die Effizienz des Cashflows. Woher beziehen In Oracle Fusion in Tabellen der Debitorenbuchhaltung oder in Rechnungstabellen zu finden, zum Beispiel AR_PAYMENT_SCHEDULES_ALL. Beispiele 2023-06-192023-07-012023-06-25 | |||
| Auftragsart OrderType | Eine Klassifizierung des Kundenauftrags, zum Beispiel „Standardauftrag“ oder „Retourenauftrag“. | ||
| Beschreibung Mit der Auftragsart werden Kundenaufträge nach ihrem Geschäftszweck kategorisiert. Gängige Arten sind Standardverkäufe, Serviceaufträge, Retourenautorisierungen (RMAs) und interne Aufträge. Die Analyse nach Auftragsart ist wichtig, weil sich Prozessabläufe und Leistungsziele je nach Art unterscheiden können. Durch diese Segmentierung lassen sich beabsichtigte und erwartete Prozessvarianten erkennen, damit sie nicht fälschlich als Abweichungen eingestuft werden. Warum das wichtig ist Ermöglicht die Segmentierung unterschiedlicher, legitimer Prozessabläufe, etwa Standardaufträge und Retouren, und sorgt so für eine faire und genaue Analyse. Woher beziehen In der Regel als Feld in der Kundenauftragskopftabelle in Oracle Fusion verfügbar. Weitere Informationen finden Sie in der Dokumentation zu Oracle Fusion Financials. Beispiele StandardkundenauftragRetourenautorisierungServiceauftrag | |||
| Geschäftseinheit BusinessUnitName | Der Name der internen Geschäftseinheit, die für den Kundenauftrag verantwortlich ist. | ||
| Beschreibung Dieses Attribut bezeichnet den Geschäftsbereich oder die operative Einheit des Unternehmens, der die Transaktion zugeordnet ist. Es ermöglicht den Leistungsvergleich zwischen verschiedenen Unternehmensteilen. Die Segmentierung des Prozesses nach Geschäftseinheit zeigt Unterschiede bei Effizienz, Kosten und Compliance im Unternehmen. Sie kann bewährte Vorgehensweisen leistungsstarker Einheiten aufzeigen, die sich weitergeben lassen, oder auf Einheiten mit Verbesserungsbedarf hinweisen. Warum das wichtig ist Ermöglicht Leistungsvergleiche und Analysen zur Prozesskonsistenz zwischen verschiedenen Organisationseinheiten. Woher beziehen In der Regel im Kundenauftragskopf verfügbar und mit der in Oracle Fusion definierten Organisationsstruktur verknüpft. Beispiele GE-NordamerikaGE-EMEAGlobal Services | |||
| 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 wichtige Dimension für geografische Analysen. Die Segmentierung nach Land kann regionale Unterschiede bei Prozessleistung, Durchlaufzeiten oder Zahlungsverhalten aufzeigen. So lässt sich nachvollziehen, wie sich lokale Vorschriften, logistische Herausforderungen und Marktbedingungen auf den Order-to-Cash-Prozess auswirken. Warum das wichtig ist Ermöglicht geografische Analysen, um regionale Unterschiede bei Prozesseffizienz, Compliance und Kundenverhalten zu erkennen. Woher beziehen Stammt aus Kundenstammdatentabellen (HZ_LOCATIONS, HZ_PARTY_SITES), die mit dem Kundenauftrag verknüpft sind. Beispiele USADeutschlandJapan | |||
| Letzte Datenaktualisierung LastUpdateDate | Der Timestamp, der angibt, wann die Daten zu diesem Ereignis zuletzt aus dem Quellsystem aktualisiert wurden. | ||
| Beschreibung Dieses Attribut erfasst, wann die Daten zuletzt extrahiert oder im Process-Mining-Datensatz aktualisiert wurden. So ist nachvollziehbar, wie aktuell die analysierten Daten sind. Diese Information hilft Benutzern einzuschätzen, wie aktuell die Prozessanalyse ist. Sie schafft Klarheit über den Datenstand und ist wichtig für die Einrichtung und Überwachung von Datenaktualisierungen. Warum das wichtig ist Zeigt an, wie aktuell die Daten sind, damit Benutzer den Aktualitätsstand ihrer Prozessanalyse einschätzen können. Woher beziehen Dieser Wert wird bei jedem Datenextraktions- und Transformationszyklus erzeugt und dem Datensatz hinzugefügt. Beispiele 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Produktname ProductName | Der Name des verkauften Produkts oder der verkauften Dienstleistung. | ||
| Beschreibung Dieses Attribut bezeichnet den Artikel in einer Kundenauftragsposition. Bei Aufträgen mit mehreren Positionen kann der Case auf Positionsebene analysiert oder das Attribut auf Kopfebene zusammengefasst werden. Die Analyse nach Produkt zeigt, ob bestimmte Produkte mit komplexeren oder problematischeren Prozessabläufen verbunden sind, etwa mit häufigen Lieferverzögerungen oder Zahlungsproblemen. Diese Erkenntnisse können in die Produktplanung und Lieferkettenstrategie einfließen. Warum das wichtig ist Ermöglicht die Analyse der Prozessleistung für verschiedene Produkte und zeigt Artikel mit möglicherweise komplexen Erfüllungs- oder Rechnungsstellungsabläufen auf. Woher beziehen Stammt aus den Tabellen zu Kundenauftragspositionen und wird mit einer Produktstammdatentabelle verknüpft. Weitere Informationen finden Sie in der Dokumentation zu Oracle Fusion Financials. Beispiele Standard Widget X1Premium-ServicepaketKomponente Y2-B | |||
| Quellsystem SourceSystemIdentifier | Gibt an, aus welchem Quellsystem die Ereignisdaten extrahiert wurden. | ||
| Beschreibung Dieses Attribut gibt die Herkunft der Daten an. Das ist besonders hilfreich, wenn mehrere Systeme am Order-to-Cash-Prozess beteiligt sind. Beispielsweise können Auftragsdaten aus Oracle Fusion stammen, während Versanddaten aus einem Logistiksystem eines Drittanbieters kommen. In der Analyse hilft dieses Attribut, die Datenherkunft nachzuvollziehen und die Prozessansicht auf Ereignisse aus bestimmten Systemen zu filtern. Es ist wichtig für die Datenvalidierung und hilft, Prozessfragmentierung über verschiedene IT-Landschaften hinweg zu erkennen. Warum das wichtig ist Gibt Aufschluss über die Datenherkunft und ist wichtig für Data Governance und die Fehlerbehebung in Umgebungen mit mehreren Systemen. Woher beziehen In der Regel handelt es sich um einen statischen Wert, der bei der Datenextraktion und -transformation hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen. Beispiele Oracle Fusion Cloud FinancialsOracle SCM CloudOracle ERP | |||
| Rechnung korrigiert IsInvoiceCorrected | Kennzeichen dafür, ob eine Rechnung nach ihrer erstmaligen Erstellung korrigiert oder überarbeitet wurde. | ||
| Beschreibung Dieses boolesche Attribut ist wahr, wenn eine Rechnung eine Korrekturschleife durchlaufen hat. Dies wird durch die Aktivität „Rechnung korrigiert“ im Event Log angezeigt. Das Attribut kennzeichnet Cases, bei denen in der Rechnungsstellung Nacharbeit erforderlich war. Es ist eine wichtige Eingangsgröße für das Dashboard „Rechnungsgenauigkeit und Nacharbeitsanalyse“ sowie die KPI „Rechnungsnacharbeitsquote“. Damit lässt sich das Ausmaß von Rechnungsfehlern quantifizieren und anhand einer Ursachenanalyse ermitteln, warum Korrekturen erforderlich sind. Ziel ist es, manuelle Arbeit und Zahlungsverzögerungen zu verringern. Warum das wichtig ist Erkennt Nacharbeit bei Rechnungen. Sie ist ein wichtiger Hinweis auf ineffiziente Prozesse, Probleme mit der Datenqualität und mögliche Zahlungsverzögerungen. Woher beziehen Dies ist ein berechnetes Feld. Für einen Case wird es in der Regel auf „wahr“ gesetzt, wenn sein Event Log die Aktivität „Rechnung korrigiert“ enthält. Beispiele falsetrue | |||
| Rechnungsnummer InvoiceNumber | Die eindeutige Kennung der Kundenrechnung. | ||
| Beschreibung Dieses Attribut ist die eindeutige Nummer der Rechnung, die für den Kundenauftrag erstellt wurde. Sie verknüpft Vertriebs- und Erfüllungsaktivitäten mit dem finanziellen Ausgleich im Prozess. Der Kundenauftrag ist zwar die primäre Case-ID, doch die Rechnungsnummer ist für die Analyse der Rechnungsstellung und der zugehörigen Zahlungsprozesse entscheidend. Sie ist unverzichtbar, um Rechnungskorrekturen, Reklamationen und Zahlungsstatus nachzuverfolgen, und unterstützt Dashboards wie „Rechnungsgenauigkeit und Nacharbeitsanalyse“. Warum das wichtig ist Stellt eine wichtige Verbindung zur Debitorenbuchhaltung her und ist für die Analyse von Rechnungsnacharbeit und Zahlungszyklen erforderlich. Woher beziehen In den Debitorentransaktionstabellen in Oracle Fusion verfügbar, zum Beispiel RA_CUSTOMER_TRX_ALL. Beispiele INV-93485INV-93486INV-93487 | |||
| Termingerechte Lieferung IsOnTimeDelivery | Ein berechnetes Kennzeichen, das true ist, wenn die tatsächliche Lieferung am gewünschten Lieferdatum oder früher erfolgte. | ||
| Beschreibung Dieses boolesche Attribut wird durch den Vergleich des tatsächlichen mit dem gewünschten Lieferdatum abgeleitet. Es zeigt auf Case-Ebene an, ob die Lieferung termingerecht erfolgte. Das Kennzeichen bildet die Grundlage für die Berechnung der Gesamtkennzahl „Quote termingerechter Lieferungen“. Es vereinfacht Filterung und Analyse, sodass Benutzer verspätete Aufträge schnell eingrenzen und die Ursachen der Verzögerungen untersuchen können. Warum das wichtig ist Misst direkt die Erfüllungsleistung im Vergleich zu den Kundenerwartungen und vereinfacht die Analyse verspäteter Aufträge. Woher beziehen Dies ist ein berechnetes Feld. Die Logik lautet: ActualDeliveryDate <= RequestedDeliveryDate. Beispiele truefalse | |||
| Versandart ShippingMethod | Die Versandart oder der Frachtführer, mit dem die Waren an den Kunden geliefert werden. | ||
| Beschreibung Dieses Attribut gibt den Logistikdienstleister oder das Serviceniveau für die Lieferung an, zum Beispiel „Landfracht“, „Luftfracht Express“ oder „Kurierdienst vor Ort“. Diese Information ist wichtig für das Dashboard „Einhaltung der Liefertermine nach Versandart“. Damit lassen sich die termingerechte Lieferleistung und die Versandkosten verschiedener Versandarten und Frachtführer vergleichen. Das unterstützt die Optimierung der Logistikstrategie und die Auswahl von Dienstleistern. Warum das wichtig ist Unterstützt die Logistikanalyse direkt, indem sich die Leistung verschiedener Frachtführer und Versandarten vergleichen lässt. Woher beziehen In den Versand- und Erfüllungstabellen in Oracle Fusion verfügbar. Weitere Informationen finden Sie in der Dokumentation zu Oracle Fusion Financials. Beispiele FedEx GroundUPS Next Day AirDHL International | |||
| Zahlung verspätet IsLatePayment | Ein berechnetes Kennzeichen, das true ist, wenn die Zahlung nach dem Zahlungsziel eingegangen ist. | ||
| Beschreibung Dieses boolesche Attribut wird durch den Vergleich des tatsächlichen Zahlungseingangsdatums mit dem Zahlungsziel abgeleitet. Es zeigt eindeutig an, ob eine Rechnung pünktlich bezahlt wurde. Dieses Attribut dient zur Berechnung der Kennzahl „Quote pünktlicher Zahlungen“. Es ermöglicht eine einfache Segmentierung pünktlicher und verspäteter Zahlungen, um Merkmale von Kunden mit verspäteten Zahlungen, häufige Verzögerungsursachen und die finanziellen Auswirkungen auf das Betriebskapital zu analysieren. Warum das wichtig ist Misst die Effektivität des Zahlungseingangs direkt und erleichtert die Analyse überfälliger Zahlungen. Woher beziehen Dies ist ein berechnetes Feld. Die Logik lautet: PaymentReceivedDate > PaymentDueDate. Beispiele falsetrue | |||
| Zahlungsbedingungen PaymentTerms | Die vereinbarten Bedingungen für die Zahlung durch den Kunden. | ||
| Beschreibung Dieses Attribut gibt an, unter welchen Bedingungen der Kunde die Rechnung bezahlen soll, zum Beispiel „Netto 30 Tage“ oder „Netto 60 Tage“. Anhand dieser Bedingungen wird das Zahlungsziel berechnet. Die Segmentierung nach Zahlungsbedingungen hilft, Unterschiede bei den Zahlungszyklen zu erklären. Sie liefert Kontext für die Kennzahl „Quote pünktlicher Zahlungen“, da unterschiedliche Bedingungen zu unterschiedlichem Zahlungsverhalten führen. Diese Erkenntnisse können in die Kreditrichtlinien und die Cashflow-Prognose einfließen. Warum das wichtig ist Liefert wichtigen Kontext für die Analyse des Zahlungsverhaltens und hilft, Unterschiede bei den Zeitspannen zwischen Rechnungsstellung und Zahlung zu erklären. Woher beziehen In Oracle Fusion auf Ebene des Kundenauftrags oder des Kundenkontos verfügbar. Weitere Informationen finden Sie in der Dokumentation zu Oracle Fusion Financials. Beispiele Netto 30 TageNetto 60 TageFällig bei Erhalt | |||
Aktivitäten der Auftragsabwicklung vom Auftrag bis zum Zahlungseingang
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Auftrag bestätigt | Dieser wichtige Meilenstein zeigt, dass der Vertriebsauftrag alle ersten Prüfungen einschließlich der Kreditfreigabe bestanden hat und nun zur Erfüllung eingeplant ist. Er lässt sich üblicherweise daran erkennen, dass der Auftragsstatus in einen Status wie „Versand ausstehend“ oder „Eingeplant“ wechselt. | ||
| Warum das wichtig ist Diese Aktivität ist ein wichtiger Meilenstein für die Berechnung der „durchschnittlichen Auftragsbestätigungszeit“. Sie markiert den Übergang von der Auftragserfassung zur Auftragserfüllung. Woher beziehen Wird anhand einer Änderung des Status im Vertriebsauftragskopf oder in der Auftragsposition abgeleitet, die anzeigt, dass der Auftrag zur Erfüllung bereit ist, zum Beispiel „Versand ausstehend“. Prüfen Sie die Statusspalten in DOO_HEADERS_ALL oder DOO_FULFILL_LINES_ALL. Erfassung Wird anhand des Timestamps abgeleitet, zu dem der Auftragsstatus in einen bestätigten oder eingeplanten Status wechselt. Ereignistyp inferred | |||
| Auftrag geschlossen | Die letzte Aktivität im Prozess. Sie zeigt an, dass alle Positionen des Kundenauftrags erfüllt, fakturiert und geschlossen wurden. Der Status des Auftragskopfs wird auf „Geschlossen“ gesetzt. | ||
| Warum das wichtig ist Diese Aktivität markiert den erfolgreichen Abschluss des Lebenszyklus eines Kundenauftrags. Sie ist wichtig, um die durchgängige Prozessdauer zu berechnen und Aufträge zu erkennen, die nie geschlossen werden. Woher beziehen Abgeleitet aus der Änderung des Status des Kundenauftragskopfs auf „Geschlossen“ in der Tabelle DOO_HEADERS_ALL. Der Timestamp dieser letzten Statusänderung dient als Ereigniszeitpunkt. Erfassung Abgeleitet aus dem Timestamp der Statusänderung des Kundenauftragskopfs auf „Geschlossen“. Ereignistyp inferred | |||
| Rechnung erstellt | Diese Aktivität bezeichnet die Erstellung der Kundenrechnung im Modul Accounts Receivable. Sie wird üblicherweise durch die Versandbestätigung ausgelöst. Dabei wird ein Rechnungseintrag mit eindeutiger Nummer und Erstellungsdatum angelegt. | ||
| Warum das wichtig ist Markiert den offiziellen Beginn des Zahlungseinzugs. Die Aktivität bildet die Grundlage für die Messung der „Zeit von der Rechnung bis zur Zahlung“ und der gesamten Cashflow-Effizienz. Woher beziehen Dieses Ereignis wird explizit in Oracle Accounts Receivable (AR) erfasst. In der Tabelle RA_CUSTOMER_TRX_ALL wird ein Rechnungseintrag mit einem Transaktionsdatum angelegt. Erfassung Wird anhand des Erstellungsdatums der Rechnungstransaktion im AR-Modul erfasst. Ereignistyp explicit | |||
| Vertriebsauftrag erstellt | Diese Aktivität markiert den Beginn der Auftragsbearbeitung. Sie erfasst den Zeitpunkt, an dem ein neuer Vertriebsauftrag in Oracle Fusion angelegt wird. Üblicherweise wird das Ereignis protokolliert, wenn ein Benutzer im Modul Order Management einen neuen Auftrag speichert. | ||
| Warum das wichtig ist Als Startpunkt des Prozesses ist diese Aktivität wichtig, um die gesamte Durchlaufzeit im Order-to-Cash-Prozess zu messen und das Auftragsvolumen zu analysieren. Woher beziehen Wird beim Anlegen eines Vertriebsauftrags in Order Management Cloud explizit erfasst. Suchen Sie in der Tabelle DOO_HEADERS_ALL nach Erstellungs-Timestamps. Erfassung Wird anhand des Erstellungs-Timestamps des Vertriebsauftragskopfs erfasst. Ereignistyp explicit | |||
| Waren versandt | Diese Aktivität markiert den Zeitpunkt, an dem die Waren das Lager verlassen und zum Kunden unterwegs sind. Sie wird erfasst, wenn in Oracle Shipping eine Versandbestätigung verarbeitet wird. | ||
| Warum das wichtig ist Dieser wichtige Meilenstein zeigt den Abschluss der Auftragserfüllung an und löst die Rechnungsstellung aus. Er ist entscheidend für die Messung der Versandtermintreue und der Lieferzeiten. Woher beziehen Dieses Ereignis wird explizit in Oracle Shipping Execution erfasst. Bei der Versandbestätigung wird ein Eintrag in Versandtabellen wie WSH_DELIVERY_DETAILS mit einem Versanddatum angelegt. Erfassung Wird anhand des Timestamps für das tatsächliche Versanddatum im Lieferdetaildatensatz der Auftragsposition erfasst. Ereignistyp explicit | |||
| Zahlung eingegangen | Diese Aktivität zeigt an, dass die Zahlung des Kunden eingegangen und in der Debitorenbuchhaltung mit der Rechnung verrechnet wurde. Erfasst wird sie, wenn die Zuordnung des Zahlungseingangs gebucht wird. | ||
| Warum das wichtig ist Dieser Meilenstein ist entscheidend für die Messung der „Gesamtdurchlaufzeit von der Bestellung bis zum Zahlungseingang“ und der „Quote pünktlicher Zahlungen“. Er steht für die Umwandlung des Umsatzes in liquide Mittel. Woher beziehen Dies ist ein explizites Ereignis in Oracle Accounts Receivable. Es wird in Tabellen für Zahlungseingänge wie AR_RECEIVABLE_APPLICATIONS_ALL erfasst, sobald ein Zahlungseingang einer Rechnung zugeordnet wird. Erfassung Erfasst anhand des Timestamp-Felds „apply date“ des Datensatzes zur Zuordnung des Zahlungseingangs in AR. Ereignistyp explicit | |||
| Auftrag storniert | Kennzeichnet die Stornierung eines Kundenauftrags, bevor er vollständig versandt wurde. Sie kann verschiedene Gründe haben und führt zum Endstatus „Storniert“. | ||
| Warum das wichtig ist Dies ist ein wichtiger Ausnahmefall. Die Analyse stornierter Aufträge hilft, Ursachen wie fehlende Lagerbestände, Preisprobleme oder eine Meinungsänderung des Kunden zu erkennen und daraus Verbesserungen für den Prozess abzuleiten. Woher beziehen Abgeleitet aus der Änderung des Status des Kundenauftragskopfs oder einer Auftragsposition in den Zustand „Storniert“. Der Timestamp dieser Statusänderung wird als Ereigniszeitpunkt verwendet. Erfassung Abgeleitet aus dem Timestamp der Statusänderung des Auftragskopfs oder der Auftragsposition auf „Storniert“. Ereignistyp inferred | |||
| Auftragsposition geschlossen | Kennzeichnet den endgültigen Abschluss einer einzelnen Auftragsposition. Sie wurde vollständig versandt und fakturiert, weitere Transaktionen sind nicht zu erwarten. Das System setzt den Positionsstatus auf „Geschlossen“. | ||
| Warum das wichtig ist Mit dem Schließen einer Auftragsposition sind alle vertraglichen Verpflichtungen für diesen Artikel erfüllt. Eine Analyse zeigt, welche Aufträge lange nach Erfüllung und Zahlung noch offen sind. Woher beziehen Abgeleitet aus der Änderung des Status der Erfüllungsposition auf „Geschlossen“ in der Tabelle DOO_FULFILL_LINES_ALL. Der Timestamp dieser Statusänderung kennzeichnet das Ereignis. Erfassung Abgeleitet aus dem Timestamp der Statusänderung der Erfüllungsposition auf „Geschlossen“. Ereignistyp inferred | |||
| Bestand reserviert | Diese Aktivität bezeichnet die Zuweisung oder Reservierung von physischem Bestand für eine Vertriebsauftragsposition. Das System reserviert bestimmte Bestände, damit sie beim Kommissionieren des Auftrags verfügbar sind. | ||
| Warum das wichtig ist Die Erfassung dieser Aktivität hilft bei der Analyse der KPI „Durchlaufzeit der Bestandszuweisung“ und zeigt Verzögerungen zwischen der Auftragsbestätigung und der Reservierung der Waren auf. Woher beziehen Dieses Ereignis wird häufig in Modulen für Bestandsverwaltung oder Supply-Chain-Ausführung erfasst. Es lässt sich aus Statusmeldungen zur Auftragsposition ableiten, die anzeigen, dass der Bestand konkret zugewiesen oder reserviert wurde. Erfassung Wird aus Statusänderungen der Auftragsposition im Zusammenhang mit der Bestandsreservierung oder der Einplanung abgeleitet. Ereignistyp inferred | |||
| Kreditprüfung durchgeführt | Diese Aktivität bezeichnet die Prüfung der Kreditwürdigkeit des Kunden anhand seines Kontos. Sie erfolgt häufig automatisiert oder manuell im Workflow der Auftragsbearbeitung. Der Abschluss wird in der Regel als Statusänderung oder erledigte Aufgabe protokolliert. | ||
| Warum das wichtig ist Die Analyse der Dauer von Kreditprüfungen hilft, Engpässe bei der Auftragsfreigabe zu erkennen. Sie ist entscheidend für die KPI „Zeit von der Kreditprüfung bis zur Bestätigung“. Woher beziehen Lässt sich aus Statusänderungen des Vertriebsauftrags ableiten, etwa aus dem Wechsel in den Status „Kreditfreigabe ausstehend“, oder anhand eines expliziten Event Logs in der Kreditmanagement-Funktion. Erfassung Wird aus Statusänderungen des Auftrags oder den Timestamps von Aufgaben zur Kreditprüfung abgeleitet. Ereignistyp inferred | |||
| Kreditstopp gesetzt | Diese Aktivität tritt ein, wenn ein Vertriebsauftrag aufgrund einer nicht bestandenen Kreditprüfung oder eines anderen kreditbezogenen Problems automatisch oder manuell gesperrt wird. Im System wird dies in der Regel durch eine Änderung des Sperrstatus des Auftrags erfasst. | ||
| Warum das wichtig ist Die Erfassung von Kreditstopps ist wichtig, um Ursachen für Verzögerungen bei der Auftragsbearbeitung zu ermitteln und die Effizienz des Prozesses zur Aufhebung von Kreditstopps zu messen. Woher beziehen Wird anhand der Sperrung des Vertriebsauftrags abgeleitet. Die Sperre wird üblicherweise in Tabellen zu Auftragssperren wie DOO_HOLDS_ALL erfasst und mit dem Vertriebsauftrag verknüpft. Erfassung Wird anhand eines neuen Eintrags in der Tabelle für Auftragssperren mit dem Sperrtyp „Kredit“ abgeleitet. Ereignistyp inferred | |||
| Rechnung korrigiert | Tritt auf, wenn eine zuvor erstellte Rechnung aufgrund von Fehlern oder Kundenreklamationen geändert, erneut ausgestellt oder gutgeschrieben wird. Dies wird in der Regel durch eine Gutschrift oder eine neue Rechnungsversion erfasst. | ||
| Warum das wichtig ist Die Nachverfolgung von Rechnungskorrekturen ist entscheidend für die Kennzahl „Rechnungsnacharbeitsquote“. Sie macht Probleme im Abrechnungsprozess sichtbar, die Zahlungen verzögern und Verwaltungskosten erhöhen können. Woher beziehen Abgeleitet aus der Erstellung einer Gutschrift, die mit der ursprünglichen Rechnung verknüpft ist, oder einer späteren Version derselben Rechnung in der Tabelle RA_CUSTOMER_TRX_ALL. Erfassung Ermittelt anhand von Gutschriften oder Rechnungen, die auf eine frühere Rechnungstransaktion verweisen. Ereignistyp inferred | |||
| Waren geliefert | Zeigt an, dass der Kunde die Lieferung erhalten hat. Diese Information stammt häufig von einem externen Spediteur und wird an Oracle Fusion zurückgemeldet. Alternativ lässt sie sich anhand einer üblichen Transportdauer ab dem Versanddatum ableiten. | ||
| Warum das wichtig ist Diese Aktivität ist entscheidend für die Berechnung der KPI „Termintreue bei Lieferungen“ und die genaue Messung des Kundenservice. Woher beziehen Dieses Ereignis ist in Oracle häufig nicht standardmäßig verfügbar. Es kann erfasst werden, wenn eine Spediteur-Integration eingerichtet ist, oder anhand des Versanddatums zuzüglich einer üblichen Transportdauer berechnet werden. Eine Systemanalyse ist erforderlich. Erfassung Wird aus Daten des Spediteurs abgeleitet oder anhand des Versanddatums zuzüglich einer durchschnittlichen Transportdauer berechnet. Ereignistyp inferred | |||
| Waren kommissioniert | Diese Aktivität bezeichnet die physische Entnahme der Waren aus dem Lager zur Erfüllung des Auftrags. Sie ist ein wichtiger Schritt in der Logistik und wird üblicherweise im Lagerverwaltungs- oder Versandmodul erfasst. | ||
| Warum das wichtig ist Diese Aktivität macht die Lagerabläufe nachvollziehbar. Verzögerungen zwischen der Bestandsreservierung und der Kommissionierung können auf Ressourcenengpässe oder Prozessprobleme im Lager hinweisen. Woher beziehen Wird in den Modulen von Oracle Fusion Cloud SCM (Supply Chain Management) erfasst. Sie lässt sich aus der Statusänderung einer Kommissionierwelle oder eines Kommissionierbelegs ableiten, die mit der Vertriebsauftragsposition verknüpft ist. Erfassung Wird anhand des Abschluss-Timestamps des Kommissioniervorgangs in den SCM-Modulen abgeleitet. Ereignistyp inferred | |||
Anleitungen zum Datenexport
Schritte
- Oracle BI Publisher öffnen: Melden Sie sich mit einem Benutzerkonto mit BI-Administrator- oder BI-Autor-Berechtigungen bei Ihrer Oracle-Fusion-Umgebung an. Öffnen Sie im Navigator-Menü den Bereich Tools > Reports and Analytics. Klicken Sie auf „Browse Catalog“, um den Business Intelligence Catalog zu öffnen.
- Neues Datenmodell erstellen: Öffnen Sie im BI Catalog einen geeigneten Ordner, zum Beispiel Shared Folders > Custom. Klicken Sie auf das Dropdown-Menü „New“ und wählen Sie „Data Model“ aus.
- SQL-Query-Dataset definieren: Klicken Sie im Editor des Datenmodells auf das Symbol „+“, um ein neues Dataset zu erstellen, und wählen Sie „SQL Query“ aus. Ein Dialogfeld wird geöffnet. Geben Sie dem Dataset einen Namen, zum Beispiel „OrderToCash_EventLog“, wählen Sie „Oracle BI EE“ als Datenquelle und „Standard SQL“ als SQL-Typ aus.
- SQL-Query eingeben: Kopieren Sie die vollständige SQL-Query aus dem Abschnitt „query“ dieses Dokuments und fügen Sie sie in das SQL-Query-Textfeld ein. Die Query enthält Parameter für das Start- und Enddatum (:p_start_date und :p_end_date), die BI Publisher automatisch erkennt.
- Eigenschaften des Datenmodells konfigurieren: Klicken Sie nach dem Einfügen der Query auf „OK“. Öffnen Sie im linken Bereich des Datenmodell-Editors den Abschnitt „Properties“. Vergewissern Sie sich, dass „Include Parameter Tags“ ausgewählt ist. Bei Bedarf können Sie auch Standardwerte für die Datumsparameter festlegen.
- Datenmodell anzeigen und speichern: Klicken Sie auf die Registerkarte „Data“. Möglicherweise werden Sie aufgefordert, Werte für die Datumsparameter einzugeben. Geben Sie zum Testen einen kurzen Zeitraum ein. Klicken Sie auf „View“, um eine Datenstichprobe anzuzeigen. Wenn die Daten korrekt dargestellt werden, speichern Sie das Datenmodell über das Speichersymbol und vergeben Sie einen aussagekräftigen Namen, zum Beispiel „OrderToCash_EventLog_DM“.
- Bericht aus dem Datenmodell erstellen: Klicken Sie nach dem Speichern des Datenmodells oben rechts auf „Create Report“. Der Assistent zur Berichtserstellung wird geöffnet.
- Bericht konfigurieren: Wählen Sie im Assistenten die Option „Use Data Model“ aus. Der Assistent führt Sie durch die Layouteinstellungen. Für einen einfachen CSV-Export können Sie das Layout „Table“ auswählen. Ziehen Sie alle Spalten per Drag-and-drop in die Tabelle. Klicken Sie auf „Next“ und deaktivieren Sie anschließend „Show Grand Totals Row“. Klicken Sie auf „Finish“, um den Bericht zu speichern. Vergeben Sie einen Namen, zum Beispiel „OrderToCash_EventLog_Report“.
- Bericht ausführen: Öffnen Sie den neu erstellten Bericht. Sie werden aufgefordert, Start- und Enddatum für den Datenexport einzugeben. Geben Sie den gewünschten Zeitraum an.
- Daten exportieren: Klicken Sie nach der Ausführung des Berichts auf das Dropdown-Menü „View“ und wählen Sie eine andere Ansichtsoption, zum Beispiel „View Report“. Suchen Sie anschließend den Link oder das Symbol „Export“ und wählen Sie „CSV“ als Exportformat aus. Dadurch wird die Event-Log-Datei heruntergeladen.
- Upload vorbereiten: Öffnen Sie die heruntergeladene CSV-Datei. Prüfen Sie, ob die Spaltenüberschriften den erforderlichen Attributen entsprechen: SalesOrder, ActivityName, EventTime, UserName, SalesOrderTotalAmount, CustomerName, SalesChannel, RequestedDeliveryDate, ActualDeliveryDate, PaymentDueDate und IsAutomated. Die Datei kann nun in das Process-Mining-Tool hochgeladen werden.
Konfiguration
- Benutzerberechtigungen: Sie benötigen eine Rolle mit Berechtigungen zum Erstellen von BI-Publisher-Datenmodellen und Berichten, zum Beispiel „BI Administrator“ oder „BI Author“.
- Datenquelle: Die Query ist für die standardmäßige Anwendungsdatenquelle „Oracle BI EE“ ausgelegt, die eine Verbindung zur Transaktionsdatenbank (Fusion Apps) herstellt. Eine besondere Konfiguration ist in der Regel nicht erforderlich.
- Parameter für den Zeitraum: Die Query verwendet die Parameter :p_start_date und :p_end_date, um die Daten zu filtern. Es empfiehlt sich dringend, die Daten in überschaubaren Abschnitten zu exportieren, zum Beispiel jeweils für 3 bis 6 Monate. So lassen sich Zeitüberschreitungen und Leistungsprobleme beim Bericht vermeiden.
- Filter für Geschäftseinheiten: Um den Umfang des Exports einzugrenzen, können Sie der CTE BaseOrders in der Query eine WHERE-Klausel hinzufügen und nach einer bestimmten Geschäftseinheiten-ID filtern, zum Beispiel AND dhead.SUBMITTING_BU_ID IN ([Your Business Unit ID]).
- Filter für Auftragstypen: Sie können auch bestimmte Verkaufsauftragstypen filtern, indem Sie der CTE BaseOrders eine Bedingung für dhead.SOURCE_ORDER_TYPE_CODE hinzufügen.
- Leistung: Bei sehr großen Datensätzen, die mehrere Jahre umfassen, kann dieser Ansatz mit einer einzelnen Query langsam sein. Führen Sie die Query möglichst außerhalb der Spitzenzeiten aus oder teilen Sie den Export in kleinere Monatsabschnitte auf. Vergewissern Sie sich, dass die Eigenschaft „Enable SQL Pruning“ im Datenmodell nicht ausgewählt ist, da sie komplexe UNION-Queries 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
- BICC-Konsole öffnen: Melden Sie sich mit einem Benutzerkonto mit der Rolle BICC_ADMINISTRATOR bei Ihrer Oracle-Fusion-Applications-Instanz an. Öffnen Sie den Bereich Tools und wählen Sie im Menü Business Intelligence Cloud Connector aus.
- Neues Angebot erstellen: Klicken Sie in der BICC-Konsole auf „Configure External Storage“, um das Ziel einzurichten. Als Ziel können Oracle Universal Content Management (UCM) oder ein OCI-Object-Storage-Bucket dienen. Prüfen Sie, ob Verbindungsdaten und Anmeldedaten korrekt sind.
- Neuen Exportauftrag anlegen: Öffnen Sie den Bereich „Manage Extract Jobs“. Klicken Sie auf das Symbol „+“, um einen neuen Auftrag anzulegen. Geben Sie einen aussagekräftigen Namen ein, zum Beispiel ProcessMind_O2C_SalesOrder_Extract.
- Data Stores (PVOs) auswählen: Suchen Sie in der Auftragskonfiguration nach den Public View Objects (PVOs), die für die Abbildung des Lebenszyklus eines Verkaufsauftrags erforderlich sind, und fügen Sie sie hinzu. Dazu gehören mehrere PVOs: FscmTopModelAM.DooTopAM.Header, FscmTopModelAM.DooTopAM.FulfillLine, FscmTopModelAM.DooTopAM.HoldInstance, FscmTopModelAM.ScmTopAM.ShipmentLine, FscmTopModelAM.ArTopAM.ReceivableInvoice und FscmTopModelAM.ArTopAM.CashReceiptApplication.
- Spalten für jedes PVO konfigurieren: Klicken Sie für jedes ausgewählte PVO auf das Menü „Actions“ und wählen Sie „Select Columns“. Wählen Sie sorgfältig die Spalten aus, die für das Event Log benötigt werden, zum Beispiel HeaderId, CreationDate, ShippedDate, TrxDate, ApplyDate und Benutzerkennungen. Eine vollständige Liste der erforderlichen Spalten für jedes PVO finden Sie im Query-Manifest.
- Filter für inkrementelle Ladevorgänge festlegen: Um das Datenvolumen zu begrenzen, filtern Sie jedes PVO anhand der Spalte LastUpdateDate. Für den ersten Lauf können Sie einen längeren Zeitraum auswählen. Bei späteren geplanten Läufen sollte der Filter so eingestellt sein, dass nur Datensätze exportiert werden, die seit der letzten Ausführung des Auftrags aktualisiert wurden.
- Exportauftrag planen: Öffnen Sie den Bereich „Manage Schedule“ und erstellen Sie einen neuen Zeitplan für den Auftrag. Führen Sie den Auftrag möglichst außerhalb der Spitzenzeiten aus, zum Beispiel jede Nacht, um die Systemleistung möglichst wenig zu beeinträchtigen.
- Auftrag übermitteln und überwachen: Übermitteln Sie den Auftrag nach der Konfiguration. Den Fortschritt können Sie auf der Seite „Manage Extract Jobs“ verfolgen. Nach erfolgreichem Abschluss stehen die Dateien im konfigurierten Cloud-Speicher als komprimierte CSV-Dateien bereit.
- Rohdaten in ein Event Log umwandeln: Laden Sie die exportierten CSV-Dateien herunter. BICC liefert Rohdaten aus Tabellen, kein fertig formatiertes Event Log. Verarbeiten Sie die Dateien daher mit einem externen Tool, zum Beispiel Python, einem Datenbankskript oder einer ETL-Plattform. Dazu gehört:
- Daten aus verschiedenen Dateien zusammenzuführen, zum Beispiel Rechnungsdaten mit dem Verkaufsauftragskopf zu verknüpfen.
- Datumsspalten in einzelne Aktivitätszeilen umzuwandeln. Erstellen Sie zum Beispiel aus der Datei FscmTopModelAM.DooTopAM.Header eine Zeile für „Verkaufsauftrag erstellt“ anhand von CreationDate und eine weitere für „Auftrag abgeschlossen“ anhand von ClosedDate.
- Statuscodes oder Kennzeichen bestimmten Aktivitäten wie „Auftrag bestätigt“ oder „Auftrag storniert“ zuzuordnen.
- Alle umgewandelten Daten in einer Datei mit den erforderlichen Spalten SalesOrder, ActivityName und EventTime zusammenzuführen.
- Datei für den Upload formatieren: Speichern Sie die umgewandelten Daten in einer einzelnen CSV-Datei. Die Spalten müssen den erforderlichen und empfohlenen Attributen entsprechen. Die Datei kann nun in ProcessMind hochgeladen werden.
Konfiguration
- PVO-Auswahl: Die Genauigkeit des Event Logs hängt vollständig davon ab, ob Sie die richtigen PVOs auswählen. Zu den wichtigsten PVOs gehören FscmTopModelAM.DooTopAM.Header (für Auftragserstellung und -abschluss), FscmTopModelAM.ScmTopAM.ShipmentLine (für Versandereignisse) und FscmTopModelAM.ArTopAM.ReceivableInvoice (für die Rechnungsstellung).
- Inkrementeller Export: Verwenden Sie bei wiederkehrenden Exporten immer den Filter LastUpdateDate. Das ist entscheidend für die Leistung und verhindert, dass derselbe mehrere Gigabyte große Datensatz wiederholt exportiert wird. Der erste vollständige Ladevorgang bildet die Ausgangsbasis. Bei späteren Läufen werden nur Änderungen erfasst.
- Zeitraum: Exportieren Sie beim ersten historischen Ladevorgang einen repräsentativen Zeitraum, zum Beispiel die letzten 3 bis 6 Monate. So bleibt das Datenvolumen überschaubar, ohne dass die Aussagekraft leidet. Spätere Läufe erfolgen inkrementell.
- Speicherkonfiguration: BICC kann Daten nach Oracle UCM oder OCI Object Storage exportieren. Für große Datenmengen und eine einfachere Anbindung nachgelagerter ETL-Tools empfiehlt sich in der Regel OCI Object Storage.
- Auftragsplanung: Planen Sie Exportaufträge außerhalb der Geschäftszeiten, um mögliche Leistungseinbußen im Oracle-Fusion-Financials-Transaktionssystem zu vermeiden.
- Voraussetzungen: Benutzer, die den Auftrag konfigurieren, benötigen die Rolle BICC_ADMINISTRATOR. Außerdem müssen die Anmeldedaten für den Cloud-Speicher bereits eingerichtet sein und die erforderliche Datenumwandlung nach dem Export klar definiert sein.
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 filteringMöchten Sie starten?
Verwenden Sie dieses Template, um die Datenerfassung zu vereinfachen und mit Process Mining zu beginnen. Optimieren Sie noch heute Ihre Auftragsabwicklung vom Auftrag bis zum Zahlungseingang.
Optimieren Sie noch heute Ihre Auftragsabwicklung vom Auftrag bis zum Zahlungseingang
Erkennen Sie Engpässe und verkürzen Sie die Durchlaufzeit vom Auftrag bis zum Zahlungseingang ganz einfach um 30 %.
Keine Kreditkarte erforderlich. 14 Tage kostenlos testen.