Ihr Daten-Template für die Kreditorenrechnungsverarbeitung
Ihr Daten-Template für die Kreditorenrechnungsverarbeitung
- Empfohlene Attribute für die Erfassung
- Wichtige Aktivitäten für die Nachverfolgung
- Hinweise zum Datenexport
Attribute der Kreditorenrechnungsverarbeitung
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivität
Activity
|
Die Bezeichnung eines bestimmten Geschäftsschritts oder Ereignisses im Lebenszyklus der Rechnungsverarbeitung. | ||
|
Beschreibung
Dieses Attribut beschreibt eine einzelne Aufgabe oder Statusänderung im Kreditorenprozess, etwa „Rechnung geparkt“, „Rechnung zur Freigabe weitergeleitet“ oder „Rechnung durch Zahlung ausgeglichen“. Diese Aktivitäten bilden die Bausteine der Prozesslandkarte. Sie werden üblicherweise aus Änderungsprotokollen, Statusfeldern oder Workflow-Protokollen in SAP extrahiert. Die Abfolge und Dauer dieser Aktivitäten zu analysieren, ist der Kern des Process Mining. So lässt sich der Prozessablauf visualisieren, Engpässe zwischen Schritten erkennen, die Häufigkeit von Nacharbeitsschleifen messen und die tatsächliche Prozessausführung mit Standardarbeitsanweisungen vergleichen. Wie detailliert die Aktivitäten definiert sind, bestimmt unmittelbar die Tiefe der möglichen Erkenntnisse.
Warum das wichtig ist
Aktivitäten bilden das Rückgrat der Prozesslandkarte. Sie ermöglichen die Visualisierung des Prozessablaufs, das Erkennen von Engpässen und die Analyse von Abweichungen.
Woher beziehen
Abgeleitet aus Transaktionscodes (BKPF-TCODE), Workflow-Protokollen (SWW_WI2OBJ) oder Änderungsprotokollen (Tabellen CDHDR/CDPOS), die Änderungen an Rechnungsbelegen erfassen.
Beispiele
Rechnungsbeleg erstelltRechnung freigegebenRechnung durch Zahlung ausgeglichenZahlungssperre gesetzt
|
|||
|
Ereigniszeit
EventTime
|
Das genaue Datum und die Uhrzeit, zu denen eine bestimmte Aktivität oder ein Ereignis stattgefunden hat. | ||
|
Beschreibung
Die Ereigniszeit ist der Timestamp jeder Aktivität im Prozess. Diese Daten sind entscheidend, um Ereignisse chronologisch zu ordnen und zeitbasierte Analysen durchzuführen. In SAP sind sie häufig in Erstellungsfeldern (z. B. BKPF-CPUDT) oder Änderungsprotokollen (CDHDR-UDATE und CDHDR-UTIME) gespeichert. Dieses Attribut ist wichtig, um zentrale Leistungskennzahlen wie Zyklus-, Verarbeitungs- und Wartezeiten zwischen Aktivitäten zu berechnen. Es ermöglicht die Analyse der Prozessleistung im Zeitverlauf, hilft dabei, den Zeitpunkt von Engpässen zu erkennen, und dient der Prüfung, ob Service Level Agreements (SLAs) und Zahlungsbedingungen eingehalten werden.
Warum das wichtig ist
Dieser Timestamp ist entscheidend für die Berechnung aller dauerbasierten Kennzahlen, einschließlich Zykluszeiten und Engpässen, und bildet die Grundlage für die Leistungsanalyse.
Woher beziehen
Aus SAP-Tabellen wie BKPF (CPUDT/CPUTM für die Erstellung) oder CDHDR (UDATE/UTIME für Änderungen).
Beispiele
2023-10-01T10:00:00Z2023-10-02T14:35:10Z2023-10-15T09:12:00Z
|
|||
|
Rechnung
InvoiceNumber
|
Der eindeutige Bezeichner jedes Rechnungsbelegs. Er dient als primäre Case-ID, um den Weg der Rechnung vom Eingang bis zur Zahlung nachzuverfolgen. | ||
|
Beschreibung
Die Rechnungsnummer ist ein zusammengesetzter Schlüssel, der in SAP üblicherweise aus Buchungskreis (BUKRS), Belegnummer (BELNR) und Geschäftsjahr (GJAHR) gebildet wird. Diese eindeutige Kombination stellt sicher, dass jede Rechnung im gesamten System eindeutig identifiziert wird. Im Process Mining ist dieses Attribut grundlegend. Es verknüpft alle zugehörigen Ereignisse und Aktivitäten, etwa Erstellung, Buchung, Freigabe und Zahlung, zu einer einzelnen Prozessinstanz. Eine Analyse nach Rechnung ermöglicht eine vollständige End-to-End-Sicht auf den Rechnungslebenszyklus. Das ist wichtig, um Zykluszeiten zu berechnen, Varianten zu erkennen und Nacharbeitsschleifen zu verstehen.
Warum das wichtig ist
Dies ist die zentrale Case-ID, die alle rechnungsbezogenen Aktivitäten verknüpft und eine vollständige End-to-End-Analyse des Kreditorenprozesses für jede Rechnung ermöglicht.
Woher beziehen
Aus den Feldern BUKRS, BELNR und GJAHR der SAP-Tabelle BKPF (Buchhaltungsbelegkopf) gebildet.
Beispiele
1000-1900000001-20232000-5100000055-20231000-1900000042-2024
|
|||
|
Bearbeitender Benutzer
ProcessorUser
|
Der SAP-Benutzername der Person, die eine Aktivität ausgeführt hat, etwa das Buchen oder Ändern der Rechnung. | ||
|
Beschreibung
Dieses Attribut gibt an, welcher Benutzer für einen bestimmten Prozessschritt verantwortlich war. In SAP kann dies der Benutzer sein, der den Beleg angelegt hat (z. B. BKPF-USNAM), oder der Benutzer, der eine bestimmte Änderung vorgenommen hat (z. B. CDHDR-USERNAME). Eine Analyse nach bearbeitendem Benutzer ist wichtig, um die Teamleistung und die Verteilung der Arbeitslast zu verstehen. Sie bildet die Grundlage für das Dashboard „Arbeitslastverteilung in der Kreditorenbuchhaltung“, in dem das Rechnungsvolumen und die durchschnittliche Bearbeitungszeit je Benutzer erfasst werden. So lassen sich Schulungsbedarf und besonders leistungsstarke Mitarbeitende erkennen und Aufgaben ausgewogen verteilen.
Warum das wichtig ist
Ermöglicht die Analyse der Arbeitslast, den Leistungsvergleich zwischen Benutzern sowie das Erkennen von Schulungsbedarf und einer unausgewogenen Ressourcenverteilung.
Woher beziehen
Aus dem Feld USERNAME der SAP-Tabelle CDHDR (für Änderungen) oder dem Feld USNAM der Tabelle BKPF (für die Belegerfassung).
Beispiele
AJONESSMITHBCWILLIAMS
|
|||
|
Bestellnummer
PurchaseOrderNumber
|
Der Bezeichner der Bestellung, auf die sich die Rechnung bezieht. | ||
|
Beschreibung
Die Bestellnummer verknüpft die Rechnung mit dem Beschaffungsprozess. Bei bestellbezogenen Rechnungen ist diese Verbindung entscheidend für den Drei-Wege-Abgleich zwischen Bestellung, Wareneingang und Rechnung. Dieses Attribut ist wichtig für das Dashboard „Leistung beim Bestell- und Wareneingangsabgleich“. Anhand der Bestellung und ihres Abgleichs lässt sich zwischen verschiedenen Rechnungstypen (mit und ohne Bestellung) unterscheiden und die Effizienz des Abgleichs messen. Verzögerungen in diesem Bereich sind eine häufige Ursache für Engpässe im Prozess.
Warum das wichtig ist
Verknüpft die Rechnung mit dem Beschaffungsprozess und ermöglicht die Analyse von Rechnungen mit und ohne Bestellung sowie der Effizienz des Drei-Wege-Abgleichs.
Woher beziehen
Aus dem Feld EBELN der SAP-Tabelle BSEG (für FI-Rechnungen) oder RSEG (für MM-Rechnungen).
Beispiele
450001712345000175894500018330
|
|||
|
Bruttobetrag der Rechnung
InvoiceGrossAmount
|
Der Bruttogesamtbetrag der Rechnung einschließlich Steuern und sonstiger Kosten in der ursprünglichen Belegwährung. | ||
|
Beschreibung
Dieses Attribut gibt den Gesamtbetrag einer Rechnung an. Es ist eine wichtige Datengrundlage, um die finanziellen Auswirkungen und Merkmale der bearbeiteten Rechnungen zu verstehen. In SAP ist der Betrag je nach Belegart in verschiedenen Tabellen zu finden, etwa in BSEG für Finanzbelege. In der Analyse dient der Rechnungsbetrag dazu, Rechnungen mit hohem Wert zu priorisieren, den finanziellen Durchsatz des Kreditorenprozesses zu verstehen und die Analyse nach Beträgen aufzuschlüsseln. So lässt sich beispielsweise untersuchen, ob Rechnungen mit hohem Wert längere Zykluszeiten haben oder andere Freigabewege durchlaufen. Auch für finanzielle Kennzahlen ist der Betrag grundlegend.
Warum das wichtig ist
Liefert den finanziellen Kontext für den Prozess und ermöglicht wertbasierte Analysen, die Priorisierung hochwertiger Rechnungen sowie die Berechnung finanzieller Kennzahlen.
Woher beziehen
Aus SAP-Positionstabellen wie dem Feld WRBTR in BSEG (Betrag in Belegwährung). Gegebenenfalls müssen die Positionen zum Belegkopf aggregiert werden.
Beispiele
1500.0012550.75980.50
|
|||
|
Buchungskreis
CompanyCode
|
Ein eindeutiger Schlüssel für eine rechtliche Einheit oder ein Unternehmen innerhalb der SAP-Organisation. | ||
|
Beschreibung
Der Buchungskreis ist eine grundlegende Organisationseinheit in SAP Financials und steht für eine eigenständige Buchhaltungseinheit. Alle Finanztransaktionen, einschließlich Rechnungen, werden einem bestimmten Buchungskreis zugeordnet. Dieses Attribut ist wichtig, um die Prozessanalyse nach rechtlicher Einheit aufzuschlüsseln. So können Sie Prozessleistung, Compliance-Quoten und Effizienz in verschiedenen Unternehmensbereichen vergleichen. Das ist besonders für große, international tätige Unternehmen mit mehreren Tochtergesellschaften relevant.
Warum das wichtig ist
Ermöglicht die Aufschlüsselung der Prozessanalyse nach rechtlicher Einheit und den Vergleich der Leistung verschiedener Geschäftseinheiten.
Woher beziehen
Aus dem Feld BUKRS der SAP-Tabelle BKPF (Buchhaltungsbelegkopf).
Beispiele
10002100US01
|
|||
|
Fälligkeitsdatum der Rechnung
InvoiceDueDate
|
Das berechnete Datum, bis zu dem die Rechnung gemäß den Zahlungsbedingungen bezahlt werden muss. | ||
|
Beschreibung
Das Fälligkeitsdatum der Rechnung gibt an, bis wann der Lieferant bezahlt werden muss, damit die vereinbarten Bedingungen eingehalten werden. In SAP ist es häufig nicht in einem einzelnen Feld gespeichert, sondern wird anhand des Basisdatums (BSEG-ZFBDT) und der Zahlungsbedingungen (BSEG-ZTERM) der Rechnung berechnet. Dieses Datum ist wichtig für das Dashboard „Zahlungskonformität und Skonti“. Es dient zur Berechnung von Kennzahlen wie der überfälligen Zahlungsquote und hilft, Rechnungen mit verspätetem Zahlungseingang zu erkennen. Eine Analyse anhand dieses Datums erleichtert die Priorisierung der Arbeit und verbessert die Lieferantenbeziehungen.
Warum das wichtig ist
Dieses Datum ist entscheidend, um die Einhaltung von Zahlungsbedingungen zu überwachen, Kennzahlen zu überfälligen Zahlungen zu berechnen und Skonti für frühzeitige Zahlungen zu nutzen.
Woher beziehen
Abgeleitet aus dem Basisdatum für die Fälligkeitsberechnung (BSEG-ZFBDT) und dem Zahlungsbedingungsschlüssel (BSEG-ZTERM).
Beispiele
2023-10-312023-11-152024-01-10
|
|||
|
Freigebender
Approver
|
Der Benutzer oder die Rolle, der bzw. die für die Freigabe der Rechnung zur Zahlung verantwortlich ist. | ||
|
Beschreibung
Dieses Attribut gibt an, wer die Aktivität „Rechnung freigegeben“ ausgeführt hat. In SAP wird dies häufig über das Workflow-System verwaltet; die ID des Freigebenden ist im Workflow-Verlauf protokolliert. Eine Analyse nach Freigebendem ist zentral für das Dashboard „Engpassanalyse bei der Rechnungsfreigabe“. Damit lassen sich Freigabezeiten je Person oder Gruppe messen, regelmäßig langsame Freigebende erkennen und die Arbeitslast innerhalb der Freigabehierarchie nachvollziehen. Diese Daten sind wichtig, um den Freigabe-Workflow zu verbessern, der häufig einen erheblichen Engpass darstellt.
Warum das wichtig ist
Gibt an, wer für Freigaben verantwortlich ist, und ermöglicht die Analyse von Freigabezyklen und Engpässen nach Person oder Team.
Woher beziehen
Üblicherweise in SAP-Business-Workflow-Tabellen (z. B. SWW_WI2OBJ, SWWLOG) zu finden. Dazu wird das Workflow-Element mit dem Rechnungsobjekt verknüpft und der Benutzer des Freigabeschritts ermittelt.
Beispiele
DMARTINLCHENFINMAN_ROLE
|
|||
|
Grund der Zahlungssperre
PaymentBlockReason
|
Ein Code, der angibt, warum eine Rechnung für die Zahlung gesperrt ist. | ||
|
Beschreibung
Bei einer Abweichung oder während einer Prüfung kann eine Zahlungssperre verhindern, dass eine Rechnung in einen Zahlungslauf aufgenommen wird. Dieses Attribut gibt den Grund für die Sperre an, etwa eine Mengenabweichung oder eine Preisabweichung. Diese Information ist für die Ausnahmeanalyse wichtig. Sie hilft, die Ursachen von Zahlungsverzögerungen und Nacharbeit zu kategorisieren, und unterstützt das Dashboard „Analyse von Ausnahmen und Abweichungen“. Wenn Sie die häufigsten Sperrgründe kennen, können Sie gezielte Prozessverbesserungen umsetzen und Ausnahmen reduzieren.
Warum das wichtig ist
Zeigt die Ursachen von Zahlungsverzögerungen und ermöglicht gezielte Analysen, um Ausnahmen, Nacharbeit und die Bearbeitungszeit von Rechnungen zu verringern.
Woher beziehen
Aus dem Feld ZLSPR der SAP-Tabelle BSEG (Buchhaltungsbelegsegment).
Beispiele
RIA
|
|||
|
Lieferantenname
VendorName
|
Der Name des Lieferanten, der die Rechnung eingereicht hat. | ||
|
Beschreibung
Dieses Attribut enthält den offiziellen Namen des Lieferanten. In SAP sind die Lieferantenstammdaten (Tabelle LFA1) über die Lieferantennummer (LIFNR) mit dem Rechnungsbeleg verknüpft. Die Lieferantennummer ist im Belegkopf oder in den Positionen gespeichert. Eine Analyse nach Lieferant ist wichtig für das Dashboard „Zahlungsleistung nach Lieferant“. Damit lassen sich Rechnungsbearbeitungszeiten, Pünktlichkeit der Zahlungen und Ausnahmequoten für einzelne Lieferanten nachverfolgen. Diese Erkenntnisse helfen, Lieferantenbeziehungen zu pflegen, Lieferanten mit wiederholt mangelhafter Rechnungsqualität zu erkennen und bessere Konditionen auszuhandeln.
Warum das wichtig ist
Ermöglicht die Analyse der Leistung einzelner Lieferanten, unterstützt die Pflege der Lieferantenbeziehungen und macht lieferantenspezifische Probleme sichtbar.
Woher beziehen
Aus dem Feld NAME1 der SAP-Tabelle LFA1, verknüpft über die Lieferantennummer (LIFNR) aus BKPF oder BSEG.
Beispiele
Global Office Supplies Inc.Tech Solutions LLCReliable Logistics Corp.
|
|||
|
Zahlungsbedingungen
PaymentTerms
|
Der Code, der Zahlungsbedingungen wie Fälligkeitstermine und mögliche Skonti festlegt. | ||
|
Beschreibung
Zahlungsbedingungen sind vordefinierte Regeln in SAP, nach denen Fälligkeitsdaten und Skonti berechnet werden. Sie werden den Lieferantenstammdaten zugeordnet und können auch für einzelne Rechnungen festgelegt werden. Dieses Attribut ist wichtig für das Dashboard „Zahlungskonformität und Skonti“ sowie die Kennzahl „Nutzungsquote für Skonti bei frühzeitiger Zahlung“. Durch die Analyse der Zahlungsbedingungen kann ein Unternehmen Möglichkeiten zur Nutzung von Skonti erkennen, die finanziellen Auswirkungen von Zahlungsplänen verstehen und die Einhaltung der Bedingungen sicherstellen.
Warum das wichtig ist
Legt die Regeln für Fälligkeitstermine und Skonti fest und ist damit wichtig für die finanzielle Optimierung und die Überwachung der Compliance.
Woher beziehen
Aus dem Feld ZTERM der SAP-Tabelle BSEG (Buchhaltungsbelegsegment).
Beispiele
Z0010001NT30
|
|||
|
Automatisiert
IsAutomated
|
Ein Kennzeichen, das angibt, ob eine Aktivität von einem System- oder Batch-Benutzer statt von einem Menschen ausgeführt wurde. | ||
|
Beschreibung
Dieses boolesche Attribut unterscheidet zwischen automatisch ausgeführten Aktivitäten (z. B. durch einen Batch-Job, EDI oder ein OCR-System) und manuellen Aktivitäten eines Benutzers. Die Zuordnung erfolgt üblicherweise anhand des Benutzernamens, der mit einer Aktivität verknüpft ist. Dieses Attribut ist grundlegend für das Dashboard „Manuelle und automatisierte Verarbeitung“. Es hilft, den Erfolg von Automatisierungsinitiativen zu messen, die Kennzahl zur manuellen Eingriffsquote zu berechnen und weitere Möglichkeiten zur Verringerung manueller Arbeit zu erkennen. Für Effizienzsteigerungen ist es wichtig, die Kontaktpunkte zwischen Menschen und Systemen zu verstehen.
Warum das wichtig ist
Hilft, den Automatisierungsgrad des Prozesses zu messen, manuelle Engpässe zu erkennen und die Auswirkungen von Automatisierungsinitiativen nachzuverfolgen.
Woher beziehen
Abgeleitet durch Prüfung, ob die Benutzer-ID (z. B. CDHDR-USERNAME) zu einer vordefinierten Liste von System-, Batch- oder Servicekonten gehört.
Beispiele
truefalse
|
|||
|
Belegart
DocumentType
|
Ein Code in SAP, der Buchhaltungsbelege klassifiziert und ihre Verarbeitung steuert. | ||
|
Beschreibung
Die Belegart unterscheidet verschiedene Geschäftsvorgänge, etwa Kreditorenrechnungen (KR), Gutschriften (KG) oder MM-Rechnungen (RE). Sie steuert unter anderem den Nummernkreis und die zulässigen Konten für Buchungen. Im Process Mining ermöglicht eine Filterung nach Belegart eine besser vergleichbare Analyse. Der Prozess für eine normale Kreditorenrechnung (KR) kann sich beispielsweise deutlich von dem für eine Gutschrift (KG) unterscheiden. Eine getrennte Analyse verhindert irreführende Zusammenfassungen und liefert genauere Erkenntnisse zu einzelnen Teilprozessen.
Warum das wichtig ist
Ermöglicht die Aufschlüsselung der Analyse nach Vorgangsart (z. B. Rechnung oder Gutschrift) und liefert dadurch genauere und relevantere Erkenntnisse zum Prozess.
Woher beziehen
Aus dem Feld BLART der SAP-Tabelle BKPF (Buchhaltungsbelegkopf).
Beispiele
KRREKG
|
|||
|
Belegwährung
DocumentCurrency
|
Der Währungscode (z. B. USD, EUR), in dem die Rechnung ausgestellt wurde. | ||
|
Beschreibung
Dieses Attribut gibt die Währung des Rechnungsbetrags an. In SAP ist sie auf Belegkopfebene gespeichert. Die Belegwährung ist für jede Finanzanalyse wichtig, damit Beträge korrekt interpretiert werden. Sie ermöglicht es, die Prozessanalyse nach Währung zu filtern, und ist Voraussetzung dafür, Beträge für standardisierte Berichte und Aggregationen in eine gemeinsame lokale Währung umzurechnen.
Warum das wichtig ist
Liefert den nötigen Kontext zur Interpretation finanzieller Beträge und ermöglicht währungsspezifische Analysen oder die Umrechnung in eine Standardwährung.
Woher beziehen
Aus dem Feld WAERS der SAP-Tabelle BKPF (Buchhaltungsbelegkopf).
Beispiele
USDEURGBP
|
|||
|
Entgangener Skonto
DiscountLost
|
Ein berechnetes Kennzeichen, das TRUE ist, wenn ein verfügbarer Skonto für frühzeitige Zahlung nicht in Anspruch genommen wurde. | ||
|
Beschreibung
Dieses Attribut kennzeichnet Rechnungen, bei denen die Zahlungsbedingungen einen Skonto für frühzeitige Zahlung vorsahen, die Zahlung jedoch erst nach Ablauf der Skontofrist erfolgte. Es wird berechnet, indem das Zahlungsdatum mit dem Skontofälligkeitsdatum verglichen wird, das sich aus den „Zahlungsbedingungen“ ergibt. Diese wichtige Finanzkennzahl fließt in die „Skonto-Nutzungsquote“ ein. Sie macht verpasste Einsparmöglichkeiten sichtbar. Eine Analyse der Gründe für entgangene Skonti, etwa lange Freigabezyklen oder Zahlungssperren, kann Prozessverbesserungsprojekte mit einem klaren Return on Investment begründen.
Warum das wichtig ist
Macht verpasste finanzielle Einsparmöglichkeiten sichtbar, unterstützt direkt die KPI „Skonto-Nutzungsquote“ und liefert einen klaren finanziellen Anreiz für Prozessverbesserungen.
Woher beziehen
Berechnetes Feld: TRUE, wenn (die Zahlungsbedingungen einen Skonto vorsahen) UND (Zahlungsdatum > Skontofälligkeitsdatum), andernfalls FALSE.
Beispiele
truefalse
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, der angibt, wann die Daten dieses Datensatzes zuletzt aus dem Quellsystem aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut gibt Datum und Uhrzeit der letzten Datenextraktion oder Aktualisierung aus SAP ECC an. Es gehört nicht zu den Transaktionsdaten selbst, sondern sind Metadaten, die bei der Datenübernahme hinzugefügt werden. In der Analyse zeigt es vor allem, wie aktuell die angezeigten Daten sind. Das ist für Dashboards und Berichte wichtig: Benutzer sehen, wie aktuell ihre Analyse ist, und können besser einschätzen, ob sehr neue Transaktionen bereits enthalten sind.
Warum das wichtig ist
Zeigt, wie aktuell der Datensatz ist. Das ist wichtig, um die Aktualität der Erkenntnisse zum Prozess und der Dashboards einzuschätzen.
Woher beziehen
Diese Metadaten werden während der Datenextraktion, -transformation und -ladung (ETL) erzeugt und hinzugefügt.
Beispiele
2024-05-21T02:00:00Z2024-05-22T02:00:00Z2024-05-23T02:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Gibt das SAP-ECC-System an, aus dem die Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut gibt das führende System an, etwa die SAP-System-ID (SID), aus dem die Daten zur Rechnungsverarbeitung stammen. Besonders wichtig ist es für Unternehmen mit mehreren ERP-Instanzen oder einer Mischung verschiedener Systeme. In einer Process-Mining-Analyse hilft es, Daten aus unterschiedlichen Systemen zu unterscheiden, die jeweils eigene Konfigurationen oder Prozessvarianten haben können. So lassen sich Systeme vergleichen und die Datenherkunft bleibt nachvollziehbar. Beides ist für Data Governance und Validierung wichtig.
Warum das wichtig ist
Sorgt für die Rückverfolgbarkeit der Daten und ermöglicht Prozessanalysen in Umgebungen mit mehreren SAP-Instanzen oder anderen Quellsystemen.
Woher beziehen
In der Regel ein statischer Wert, der die SAP-System-ID (SID) der ECC-Quellinstanz angibt und bei der Datenextraktion hinzugefügt wird.
Beispiele
ECC_PROD_EUSAP_US_01E5P
|
|||
|
Storniert
IsReversed
|
Ein boolesches Kennzeichen, das angibt, ob der Rechnungsbeleg storniert wurde. | ||
|
Beschreibung
Dieses Attribut kennzeichnet stornierte Rechnungen. Eine Stornierung ist ein wichtiges Ereignis, das auf einen schwerwiegenden Fehler oder ein Prozessversagen hinweist. In SAP ist ein stornierter Beleg mit einem Stornobeleg verknüpft. Stornierte Rechnungen zu erkennen, ist wichtig, um Prozessqualität und Fehlerquoten zu verstehen. So lassen sich diese abschließenden Ausnahmefälle vom regulären Prozessablauf trennen und gezielt ihre Ursachen analysieren, um künftige Stornierungen zu vermeiden.
Warum das wichtig ist
Kennzeichnet stornierte Rechnungen. Dies ist ein wichtiger Hinweis auf ein Prozessversagen und hilft, die Ursachen schwerwiegender Fehler zu analysieren.
Woher beziehen
Prüfen, ob die Belegnummer (BKPF-BELNR) bei einem anderen Beleg im Feld BKPF-STBLG (Stornobeleg) eingetragen ist.
Beispiele
truefalse
|
|||
|
Überfällig
IsOverdue
|
Ein berechnetes Kennzeichen, das gesetzt ist, wenn die Rechnung nach ihrem geplanten Fälligkeitsdatum bezahlt wurde. | ||
|
Beschreibung
Dieses boolesche Attribut wird berechnet, indem das Datum der Aktivität „Rechnung durch Zahlung ausgeglichen“ mit dem Fälligkeitsdatum der Rechnung verglichen wird. Liegt das Zahlungsdatum nach dem Fälligkeitsdatum, wird das Kennzeichen gesetzt. Dieses Attribut unterstützt direkt die Kennzahl zur überfälligen Zahlungsquote und das Dashboard „Zahlungskonformität und Skonti“. Es ermöglicht, verspätete Zahlungen einfach zu filtern und zu zählen und so das Ausmaß des Problems zu beziffern. Eine Analyse der Merkmale überfälliger Rechnungen, etwa nach Lieferant oder Buchungskreis, kann die Ursachen aufdecken.
Warum das wichtig ist
Misst die Einhaltung der Zahlungsbedingungen direkt und bildet die Grundlage für die KPI „Anteil überfälliger Zahlungen“. So lassen sich Lieferantenbeziehungen verbessern und Strafgebühren vermeiden.
Woher beziehen
Berechnetes Feld: TRUE, wenn (Zahlungsdatum > Rechnungsfälligkeitsdatum), andernfalls FALSE.
Beispiele
truefalse
|
|||
|
Wareneingangsnummer
GoodsReceiptNumber
|
Der Bezeichner des Wareneingangsbelegs zu einer bestellbezogenen Rechnung. | ||
|
Beschreibung
Bei Rechnungen für physische Waren bestätigt der Wareneingangsbeleg die Lieferung durch einen Lieferanten. Diese Nummer verknüpft die Rechnung mit dem jeweiligen Liefervorgang. Dieses Attribut wird im Dashboard „Leistung beim Bestell- und Wareneingangsabgleich“ verwendet. Die Zeit zwischen der Buchung des Wareneingangs und der Rechnungsbuchung ist eine wichtige Kennzahl. Anhand dieser Verknüpfung lässt sich der gesamte Drei-Wege-Abgleich nachvollziehen und erkennen, wo es zwischen der Warenlieferung und dem finanziellen Ausgleich zu Verzögerungen kommt.
Warum das wichtig ist
Vervollständigt den Drei-Wege-Abgleich zwischen Bestellung, Wareneingang und Rechnung und ermöglicht die Analyse von Verzögerungen zwischen Warenlieferung und Rechnungsverarbeitung.
Woher beziehen
Aus dem Feld LFBNR der SAP-Tabelle RSEG (Belegposition, Eingangsrechnung; Nummer eines Referenzbelegs).
Beispiele
500000123450000015675000002100
|
|||
Aktivitäten der Kreditorenrechnungsverarbeitung
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Rechnung durch Zahlung ausgeglichen
|
Die Rechnung wurde vollständig bezahlt und die offene Position mit einem Zahlungsbeleg ausgeglichen. Damit ist der Kreditorenprozess für diese Rechnung erfolgreich abgeschlossen. Das Ereignis wird anhand der Ausgleichsbeleginformationen erfasst. | ||
|
Warum das wichtig ist
Dies ist das abschließende Ereignis des regulären Prozessverlaufs. Die Zeit bis zu dieser Aktivität ist eine wichtige Kennzahl für die Gesamteffizienz des Prozesses. Sie ist außerdem entscheidend, um die Pünktlichkeit von Zahlungen und die Nutzung von Skonti zu berechnen.
Woher beziehen
Das Ereignis wird ermittelt, wenn für die Kreditorenposition die Ausgleichsbelegnummer (BSEG-AUGBL) und das Ausgleichsdatum (BSEG-AUGDT) eingetragen sind. Das Ausgleichsdatum ist der Timestamp des Ereignisses.
Erfassung
Das Ausgleichsdatum (BSEG.AUGDT) verwenden, wenn der Ausgleichsbeleg (BSEG.AUGBL) eingetragen ist.
Ereignistyp
explicit
|
|||
|
Rechnung freigegeben
|
Ein zuständiger Freigebender hat bestätigt, dass die Rechnung korrekt und zahlungsbereit ist. Dies kann als ausdrückliches Ereignis aus einem Workflow-System erfasst oder aus der Aufhebung einer Zahlungssperre abgeleitet werden. Vor der Zahlung ist dies ein wichtiger Meilenstein. | ||
|
Warum das wichtig ist
Dieser wichtige Meilenstein hebt die Zahlungssperre für die Rechnung auf. Verzögerungen vor oder nach diesem Schritt weisen auf unterschiedliche Probleme hin, etwa auf die Verfügbarkeit der Freigebenden oder die Planung des Zahlungslaufs.
Woher beziehen
In einem Workflow-System wird dieses Ereignis ausdrücklich erfasst. Andernfalls wird es üblicherweise aus der Aufhebung einer Zahlungssperre abgeleitet, die über die Änderungsprotokolle (CDHDR/CDPOS) für das Feld BSEG-ZLSPR erfasst wird.
Erfassung
Ereignis aus dem Workflow-System oder Änderungsprotokoll zur Aufhebung der Zahlungssperre.
Ereignistyp
explicit
|
|||
|
Rechnung gebucht
|
Die Rechnung wird offiziell im Hauptbuch erfasst und begründet damit eine finanzielle Verbindlichkeit. Dabei wird ein geparkter Beleg in einen gebuchten Beleg umgewandelt oder von Anfang an als gebucht angelegt. Dies ist ein grundlegender Schritt der Finanzbuchhaltung. | ||
|
Warum das wichtig ist
Die Buchung ist ein wichtiger Meilenstein, durch den die Rechnung zu einer offiziellen Verbindlichkeit wird. Sie trennt die Datenerfassung von der anschließenden aktiven Zahlungsabwicklung.
Woher beziehen
Das Ereignis wird anhand der Belegkopftabelle BKPF ermittelt. Bei einem gebuchten Beleg ist der Belegstatus (BKPF-BSTAT) leer und ein gültiges Buchungsdatum (BKPF-BUDAT) vorhanden. Das Buchungsdatum dient als Timestamp des Ereignisses.
Erfassung
BKPF.BUDAT für Belege verwenden, bei denen BKPF.BSTAT nicht „V“ (geparkt) ist oder der Status „V“ geändert wurde.
Ereignistyp
explicit
|
|||
|
Rechnung storniert
|
Der gebuchte Rechnungsbeleg wurde durch die Erstellung eines Stornobelegs storniert. Dadurch wird die finanzielle Wirkung der ursprünglichen Rechnung aufgehoben. Dies ist ein alternativer, häufig unerwünschter Prozessabschluss. | ||
|
Warum das wichtig ist
Stornierungen weisen auf Fehler hin, etwa falsche Dateneingaben oder doppelte Rechnungen. Wenn Sie Häufigkeit und Gründe für Stornierungen nachverfolgen, erkennen Sie Möglichkeiten, die Datenqualität und die korrekte Bearbeitung beim ersten Durchlauf zu verbessern.
Woher beziehen
Dieses Ereignis wird anhand der Belegkopftabelle (BKPF) ermittelt. Im ursprünglichen Beleg ist die Stornobelegnummer (BKPF-STBLG) eingetragen. Als Ereigniszeit dient das Buchungsdatum des Stornobelegs.
Erfassung
Stornobeleg in BKPF.STBLG suchen; Timestamp anhand des Buchungsdatums des Stornobelegs ermitteln.
Ereignistyp
explicit
|
|||
|
Rechnungsbeleg erstellt
|
Kennzeichnet die erstmalige Erstellung eines Rechnungsbelegs in SAP, entweder als geparkter oder vollständig gebuchter Beleg. Dies ist in der Regel das erste mit einem Timestamp versehene Ereignis einer Rechnung und dient als Ausgangspunkt für die Prozessanalyse. Erfasst wird es anhand von Datum und Uhrzeit der Belegerfassung in der Tabelle BKPF. | ||
|
Warum das wichtig ist
Diese Aktivität ist das primäre Start-Event für den Ablauf der Rechnungsbearbeitung. Die Zeit ab diesem Punkt zeigt die gesamte End-to-End-Durchlaufzeit und hilft, Verzögerungen bei der ersten Dateneingabe zu erkennen.
Woher beziehen
Dieses Ereignis wird aus dem Erstellungs-Timestamp des Buchhaltungsbelegkopfs abgeleitet. Der Timestamp ergibt sich aus der Kombination von Erfassungsdatum (BKPF-CPUDT) und Erfassungszeit (BKPF-CPUTM).
Erfassung
Verwenden Sie den Erstellungs-Timestamp aus der Belegkopftabelle BKPF (CPUDT, CPUTM).
Ereignistyp
inferred
|
|||
|
Zahlungsvorschlag erstellt
|
Die Rechnung wurde im Rahmen eines Zahlungslaufs (Transaktionscode F110) in einen Zahlungsvorschlag aufgenommen. Dies ist noch keine endgültige Zahlung, zeigt aber die Zahlungsabsicht an. Die Rechnung wird anhand ihres Fälligkeitsdatums und der Zahlungsbedingungen ausgewählt. | ||
|
Warum das wichtig ist
Dies ist der erste Schritt des automatisierten Zahlungsprozesses. Verzögerungen zwischen dem Zahlungsvorschlag und der endgültigen Zahlung können auf Probleme bei der Freigabe oder Planung des Zahlungslaufs hinweisen.
Woher beziehen
Das Ereignis wird ermittelt, indem der Rechnungsbeleg in den Tabellen für Zahlungsvorschläge gesucht wird, etwa in REGUP (bearbeitete Positionen des Zahlungsprogramms). Das Laufdatum (REGUP-LAUFD) kann als Ereigniszeit verwendet werden.
Erfassung
Rechnung in der Tabelle REGUP suchen und das Datum des Zahlungslaufs (LAUFD) verwenden.
Ereignistyp
explicit
|
|||
|
Bestellung abgeglichen
|
Diese Aktivität kennzeichnet, dass die Rechnungsposition erfolgreich einer Bestellung zugeordnet wurde. Sie ist ein wichtiger Prüfschritt beim Dreifachabgleich. Das Ereignis wird anhand einer Bestellnummer in den Details der Rechnungsposition abgeleitet. | ||
|
Warum das wichtig ist
Verzögerungen beim Bestellabgleich können einen erheblichen Engpass darstellen. Die Analyse dieser Aktivität hilft, die Effizienz des Abgleichs zu messen und Rechnungen zu erkennen, die vom üblichen bestellungsbasierten Workflow abweichen.
Woher beziehen
Abgeleitet aus der Kreditorenposition in der Tabelle BSEG. Wenn das Feld für die Bestellnummer (BSEG-EBELN) ausgefüllt ist, gilt der Abgleich zum Zeitpunkt der Belegerstellung als erfolgt.
Erfassung
Prüfen Sie, ob BSEG.EBELN für die Rechnung einen Wert enthält.
Ereignistyp
inferred
|
|||
|
Fälligkeitsdatum überschritten, Zahlung ausstehend
|
Dieses berechnete Ereignis tritt ein, wenn das aktuelle Datum nach dem Nettofälligkeitsdatum der Rechnung liegt, die Rechnung aber noch nicht ausgeglichen wurde. Es macht Rechnungen sichtbar, bei denen das Risiko einer Überfälligkeit besteht oder die bereits überfällig sind. Es handelt sich nicht um ein direktes Systemereignis. | ||
|
Warum das wichtig ist
Diese Aktivität ist wichtig, um die Kennzahl zur überfälligen Zahlungsquote zu überwachen. Sie weist frühzeitig auf Rechnungen hin, die sofortige Aufmerksamkeit erfordern, damit keine Verzugsgebühren entstehen und die Lieferantenbeziehungen nicht leiden.
Woher beziehen
Dies ist ein berechnetes Ereignis. Es wird ermittelt, indem das aktuelle Datum mit dem Nettofälligkeitsdatum (BSEG-ZFBDT) aller offenen, nicht ausgeglichenen Rechnungspositionen verglichen wird. Das Fälligkeitsdatum selbst dient als Timestamp des Ereignisses.
Erfassung
Für offene Positionen durch Vergleich des aktuellen Datums mit BSEG.ZFBDT ableiten.
Ereignistyp
calculated
|
|||
|
Rechnung geparkt
|
Die Rechnung wurde in SAP erfasst, aber noch nicht im Hauptbuch gebucht. Durch das Parken kann der Beleg später vervollständigt oder freigegeben werden. Das Statusfeld in der Belegkopftabelle zeigt an, ob eine Rechnung geparkt ist. | ||
|
Warum das wichtig ist
Das Parken kennzeichnet eine bewusste Unterbrechung des Prozesses, häufig zur Prüfung oder weil Angaben fehlen. Wenn Sie diesen Schritt verfolgen, lassen sich Ursachen für Verzögerungen vor der endgültigen Buchung einer Rechnung erkennen.
Woher beziehen
Ermittelt anhand der Belegkopftabelle BKPF, wenn der Belegstatus (BKPF-BSTAT) den Wert 'V' (geparkt) hat. Als Ereigniszeit gilt der Erstellungszeitpunkt des Belegs (BKPF-CPUDT, BKPF-CPUTM).
Erfassung
Filtern Sie nach Belegen mit BKPF.BSTAT = 'V'.
Ereignistyp
explicit
|
|||
|
Rechnung zur Freigabe weitergeleitet
|
Die Rechnung wurde offiziell in einen Freigabe-Workflow übergeben. Diese Aktivität wird häufig in einem externen Workflow-System oder anhand einer bestimmten Statusänderung in SAP erfasst. Sie markiert oft den Beginn des Freigabe-Teilprozesses. | ||
|
Warum das wichtig ist
Damit beginnt der Freigabezyklus. Die Zeit zwischen diesem Ereignis und „Rechnung freigegeben“ ist eine wichtige Kennzahl für die Zykluszeit der Rechnungsfreigabe und hilft, Engpässe bei den Freigebenden zu erkennen.
Woher beziehen
Wenn SAP Business Workflow verwendet wird, lässt sich dieses Ereignis aus Workflow-Protokollen (z. B. SWWLOG) extrahieren. Andernfalls handelt es sich um einen konzeptionellen Schritt, der häufig daraus abgeleitet wird, dass aus Freigabegründen eine Zahlungssperre gesetzt wurde.
Erfassung
Aus Workflow-Protokollen extrahieren oder aus dem Setzen einer bestimmten Zahlungssperre ableiten.
Ereignistyp
explicit
|
|||
|
Wareneingang abgeglichen
|
Kennzeichnet die Prüfung, dass die in Rechnung gestellten Waren oder Dienstleistungen eingegangen sind. Dazu wird die Rechnung einem Wareneingangsbeleg zugeordnet. Dies ist die dritte Komponente des Dreifachabgleichs. Das Ereignis wird anhand von Referenzen in der Rechnungsposition abgeleitet. | ||
|
Warum das wichtig ist
Der Abgleich mit einem Wareneingang bestätigt, dass das Unternehmen die bezahlten Waren oder Dienstleistungen erhalten hat. Die Erfassung dieses Schritts hilft, die KPI für die Abgleichzeit von Bestellung, Wareneingang und Rechnung zu analysieren und die Prüfung zu vereinfachen.
Woher beziehen
Abgeleitet aus der Kreditorenposition in der Tabelle BSEG. Dazu wird geprüft, ob eine Wareneingangsbelegnummer (BSEG-LFBNR) eingetragen ist, oder der Verlauf der zugehörigen Bestellung in der Tabelle EKBE nachvollzogen.
Erfassung
Prüfen Sie auf einen Wareneingangsbelegverweis in BSEG.LFBNR oder anhand des Bestellverlaufs in EKBE.
Ereignistyp
inferred
|
|||
|
Zahlungssperre aufgehoben
|
Eine zuvor gesetzte Zahlungssperre wurde für die Rechnung aufgehoben, sodass sie nun bezahlt werden kann. Dies bedeutet häufig, dass eine Abweichung geklärt oder die Freigabe erteilt wurde. Das Ereignis wird aus den Änderungstabellen erfasst. | ||
|
Warum das wichtig ist
Diese Aktivität kennzeichnet die Behebung eines Ausnahmefalls oder den Abschluss einer Freigabe. Die Dauer der aktiven Sperre entspricht Nacharbeit oder Wartezeit und ist damit ein wichtiger Ansatzpunkt für Prozessverbesserungen.
Woher beziehen
Dieses Ereignis wird erfasst, indem Änderungen am Feld Payment Block Key (BSEG-ZLSPR) nachverfolgt werden. Änderungsprotokolle in den Tabellen CDHDR und CDPOS halten fest, wann dieses Feld geleert wird.
Erfassung
Aktualisierungseinträge in CDHDR/CDPOS nachverfolgen, bei denen das Feld BSEG-ZLSPR geleert wird.
Ereignistyp
explicit
|
|||
|
Zahlungssperre gesetzt
|
Eine Rechnung ist für die Zahlung gesperrt, meist aufgrund einer Abweichung, einer ausstehenden Freigabe oder eines anderen Problems. Dieser Status wird ausdrücklich auf der Rechnungsposition gesetzt. Das Ereignis lässt sich aus den Änderungstabellen erfassen. | ||
|
Warum das wichtig ist
Diese Aktivität markiert den Beginn eines Ausnahme- oder Freigabezeitraums. Die Häufigkeit und Dauer von Zahlungssperren zu analysieren, ist entscheidend, um Engpässe und Streitfälle im Prozess zu erkennen und zu beheben.
Woher beziehen
Das Ereignis wird erfasst, indem Änderungen am Feld Payment Block Key (BSEG-ZLSPR) nachverfolgt werden. Änderungsprotokolle in den Tabellen CDHDR und CDPOS halten fest, wann dieses Feld befüllt wird.
Erfassung
Erstellung von Einträgen in CDHDR/CDPOS für das Feld BSEG-ZLSPR nachverfolgen.
Ereignistyp
explicit
|
|||
Anleitungen zum Datenexport
Möchten Sie loslegen?
Nutzen Sie dieses Template als Ausgangspunkt für Ihr Process-Mining-Projekt. Beginnen Sie noch heute damit, Ihre Kreditorenrechnungsverarbeitung mithilfe datengetriebener Erkenntnisse zu verbessern.
Vermeiden Sie Verzugsgebühren: Optimieren Sie jetzt Ihre Kreditorenprozesse und sparen Sie 60 %
Vermeiden Sie doppelte Zahlungen, automatisieren Sie die Verarbeitung und senken Sie mit unserer Plattform die Kosten um 60 %.
Keine Kreditkarte erforderlich. In wenigen Minuten eingerichtet.