Daten-Template: Kreditorenrechnungsverarbeitung
Ihre Datenvorlage für die Rechnungsbearbeitung der Kreditorenbuchhaltung
- Empfohlene Attribute zur Erfassung
- Wichtige Aktivitäten zur Verfolgung
- Extraktionsanleitung
Attribute der Kreditoren-Rechnungsverarbeitung
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivität
Activity
|
Der Name eines konkreten Prozessschritts bzw. Ereignisses innerhalb des Lebenszyklus der Rechnungsbearbeitung. | ||
|
Beschreibung
Dieses Attribut beschreibt einen einzelnen Vorgang bzw. Statuswechsel im Kreditorenprozess, z. B. 'Invoice Parked', 'Invoice Routed For Approval' oder 'Invoice Cleared By Payment'. Diese Aktivitäten sind die Bausteine der Process Map und werden in SAP typischerweise aus Änderungsprotokollen, Statusfeldern oder Workflow-Logs gewonnen. Die Reihenfolge und Dauer dieser Aktivitäten zu analysieren, ist der Kern von Process Mining. So werden Prozessflüsse sichtbar, Engpässe zwischen Schritten erkennbar, die Häufigkeit von Nacharbeitsschleifen messbar und die tatsächliche Ausführung mit Standardprozessen vergleichbar. Die gewählte Granularität der Aktivitäten bestimmt unmittelbar, wie tief die Erkenntnisse gehen.
Warum es wichtig ist
Aktivitäten bilden das Rückgrat der Prozesslandkarte. Sie machen den Ablauf sichtbar, zeigen Engpässe auf und ermöglichen die Analyse von Abweichungen.
Woher erhalten
Abgeleitet aus Transaktionscodes (BKPF‑TCODE), Workflow‑Logs (SWW_WI2OBJ) oder Änderungsprotokollen (Tabellen CDHDR/CDPOS) auf Basis von Änderungen an Rechnungsbelegen.
Beispiele
Rechnungsbeleg angelegtRechnung freigegebenRechnung durch Zahlung ausgeglichenZahlungssperre gesetzt
|
|||
|
Ereigniszeit
EventTime
|
Das genaue Datum und die Uhrzeit, zu der eine Aktivität bzw. ein Ereignis stattgefunden hat. | ||
|
Beschreibung
Event Time ist der Zeitstempel, der jeder Aktivität im Prozess zugeordnet ist. Diese Information ist entscheidend für die chronologische Reihenfolge der Ereignisse und für alle zeitbasierten Analysen. In SAP wird sie häufig in Anlegefeldern (z. B. BKPF-CPUDT) oder in Änderungsprotokollen (CDHDR-UDATE und CDHDR-UTIME) gespeichert. Dieses Attribut ist unerlässlich, um KPIs wie Durchlauf-, Bearbeitungs- und Wartezeiten zwischen Aktivitäten zu berechnen. Es ermöglicht die Analyse der Prozessleistung über die Zeit, hilft, Engpässe zu erkennen, und dient zur Prüfung der Einhaltung von SLAs oder Zahlungsbedingungen.
Warum es wichtig ist
Dieser Zeitstempel ist die Grundlage für alle dauerbasierten Kennzahlen – einschließlich Durchlaufzeiten und Engpässen – und damit die Basis der Performance‑Analyse.
Woher erhalten
Aus SAP-Tabellen wie BKPF (CPUDT/CPUTM für Erstellung) oder CDHDR (UDATE/UTIME für Änderungen).
Beispiele
2023-10-01T10:00:00Z2023-10-02T14:35:10Z2023-10-15T09:12:00Z
|
|||
|
Rechnung
InvoiceNumber
|
Die eindeutige Kennung jedes Rechnungsbelegs; sie dient als primäre Case ID, um den Weg vom Eingang bis zur Zahlung nachzuverfolgen. | ||
|
Beschreibung
Die Rechnungsnummer ist ein zusammengesetzter Schlüssel, der in SAP typischerweise aus Buchungskreis (BUKRS), Belegnummer (BELNR) und Geschäftsjahr (GJAHR) besteht. Diese Kombination stellt sicher, dass jede Rechnung systemweit eindeutig identifiziert ist. Im Process Mining ist dieses Attribut grundlegend. Es verknüpft alle zugehörigen Ereignisse und Aktivitäten – von Anlage über Buchung und Freigabe bis zur Zahlung – zu einer konsistenten Prozessinstanz. Eine Analyse auf Rechnungsebene ermöglicht die vollständige End‑to‑End‑Sicht auf den Rechnungslebenszyklus und ist Basis für die Berechnung von Durchlaufzeiten, die Variantenermittlung und das Erkennen von Nacharbeitsschleifen.
Warum es wichtig ist
Dies ist die zentrale Case ID, die alle rechnungsbezogenen Aktivitäten verbindet und eine vollständige End-to-End-Analyse des Kreditorenprozesses je Rechnung ermöglicht.
Woher erhalten
Gebildet aus den Feldern BUKRS, BELNR und GJAHR der SAP‑Tabelle BKPF (Buchhaltungsbelegkopf).
Beispiele
1000-1900000001-20232000-5100000055-20231000-1900000042-2024
|
|||
|
Bearbeiter
ProcessorUser
|
Der SAP‑Benutzername der Person, die die Aktivität ausgeführt hat – z. B. die Rechnung gebucht oder geändert hat. | ||
|
Beschreibung
Dieses Attribut benennt die Person, die einen bestimmten Prozessschritt ausgeführt hat. In SAP kann dies der Benutzer sein, der den Beleg angelegt hat (z. B. BKPF‑USNAM), oder der Benutzer, der eine Änderung vorgenommen hat (z. B. CDHDR‑USERNAME). Auswertungen nach "Processor User" sind zentral, um Teamleistung und Workload-Verteilung zu verstehen. So entsteht das Dashboard 'Workload-Verteilung im AP‑Team': Es zeigt Rechnungsvolumen und durchschnittliche Aktivitätszeiten je Benutzer. Dadurch werden Trainingsbedarfe sichtbar, Top‑Performer identifiziert und eine faire Aufgabenverteilung unterstützt.
Warum es wichtig ist
Ermöglicht Auslastungsanalysen, Leistungsvergleiche zwischen Benutzern und das Erkennen von Schulungsbedarfen oder Ressourcenungleichgewichten.
Woher erhalten
Aus SAP-Tabelle CDHDR, Feld USERNAME (für Änderungen), oder aus BKPF, Feld USNAM (für Belegerfassung).
Beispiele
AJONESSMITHBCWILLIAMS
|
|||
|
Bestellnummer
PurchaseOrderNumber
|
Die Kennung der Bestellung, auf die sich die Rechnung bezieht. | ||
|
Beschreibung
Die Bestellnummer (PO) verknüpft die Rechnung mit dem Beschaffungsprozess. Bei bestellgestützten Rechnungen ist diese Verbindung für den 3‑Wege‑Abgleich zwischen Bestellung, Wareneingang und Rechnung entscheidend. Dieses Attribut ist zentral für das Dashboard „PO/GR Matching Performance“. Die Analyse der vorhandenen Bestellung und ihres Abgleichs hilft, unterschiedliche Rechnungstypen (mit vs. ohne Bestellung) zu unterscheiden und die Effizienz des Abgleichs zu messen. Verzögerungen in diesem Bereich sind eine häufige Ursache für Prozessengpässe.
Warum es wichtig ist
Verknüpft die Rechnung mit dem Einkaufsprozess und ermöglicht Analysen zu PO- vs. Non-PO-Rechnungen sowie zur Effizienz des Drei-Wege-Abgleichs.
Woher erhalten
Aus SAP-Tabelle BSEG (für FI-Rechnungen) bzw. RSEG (für MM-Rechnungen), Feld EBELN.
Beispiele
450001712345000175894500018330
|
|||
|
Buchungskreis
CompanyCode
|
Ein eindeutiger Schlüssel, der innerhalb der SAP-Organisation eine juristische Einheit bzw. Gesellschaft kennzeichnet. | ||
|
Beschreibung
Der Buchungskreis ist eine zentrale Organisationseinheit in SAP Financials und steht für eine eigenständige buchhalterische Einheit. Alle Finanztransaktionen – einschließlich Rechnungen – werden einem bestimmten Buchungskreis zugeordnet. Dieses Attribut ist essenziell, um die Prozessanalyse nach Rechtseinheiten zu segmentieren. So lassen sich Prozessleistung, Compliance‑Quoten und Effizienz über verschiedene Unternehmensbereiche hinweg vergleichen – besonders wichtig für große, internationale Konzerne mit mehreren Tochtergesellschaften.
Warum es wichtig ist
Ermöglicht die Segmentierung der Prozessanalyse nach Rechtseinheit/Buchungskreis und damit Leistungsvergleiche zwischen verschiedenen Organisationseinheiten.
Woher erhalten
Aus SAP-Tabelle BKPF (Belegkopf Finanzbuchhaltung), Feld BUKRS.
Beispiele
10002100US01
|
|||
|
Genehmiger
Approver
|
Der Benutzer bzw. die Rolle, die die Rechnung zur Zahlung freigibt. | ||
|
Beschreibung
Dieses Attribut identifiziert die Person, die die Aktivität 'Invoice Approved' durchgeführt hat. In SAP wird dies häufig über das Workflow-System gesteuert; die ID des Freigebers ist in der Workflow-Historie protokolliert. Auswertungen nach Freigebern sind Kern des Dashboards 'Engpassanalyse Rechnungsfreigabe'. Damit lassen sich Freigabezeiten je Person oder Gruppe messen, wiederholt langsame Freigeber erkennen und die Workload-Verteilung in der Freigabehierarchie verstehen. Diese Daten sind entscheidend, um den Freigabe-Workflow zu optimieren – oft einer der größten Engpässe.
Warum es wichtig ist
Kennzeichnet die verantwortliche Person für Freigaben und ermöglicht Analysen zu Durchlaufzeiten und Engpässen in der Freigabe nach Person oder Team.
Woher erhalten
Typischerweise in SAP Business Workflow‑Tabellen zu finden (z. B. SWW_WI2OBJ, SWWLOG), indem das Workflow‑Item mit dem Rechnungsobjekt verknüpft und der Benutzer des Freigabeschritts identifiziert wird.
Beispiele
DMARTINLCHENFINMAN_ROLE
|
|||
|
Grund der Zahlungssperre
PaymentBlockReason
|
Ein Code, der angibt, warum eine Rechnung für die Zahlung gesperrt ist. | ||
|
Beschreibung
Wenn eine Rechnung Abweichungen aufweist oder geprüft wird, kann ein Zahlungsblock gesetzt werden, damit sie nicht in einen Zahlungslauf aufgenommen wird. Dieses Attribut gibt den Grund für den Block an, etwa eine Mengenabweichung oder Preisdifferenz. Diese Information ist für die Ausnahmenanalyse entscheidend. Sie hilft, die Ursachen von Zahlungsverzögerungen und Nacharbeit zu kategorisieren und unterstützt das Dashboard 'Ausnahme- und Abweichungsanalyse'. Wer die häufigsten Blockgründe kennt, kann gezielt Verbesserungen umsetzen und Ausnahmen reduzieren.
Warum es wichtig ist
Liefert die Ursache für Zahlungsverzögerungen und ermöglicht gezielte Analysen, um Ausnahmen, Nacharbeit und die Rechnungsdurchlaufzeit zu reduzieren.
Woher erhalten
Aus SAP-Tabelle BSEG (Belegposition Finanzbuchhaltung), Feld ZLSPR.
Beispiele
RIA
|
|||
|
Lieferantenname
VendorName
|
Der Name des Kreditoren oder Lieferanten, der die Rechnung eingereicht hat. | ||
|
Beschreibung
Dieses Attribut enthält den offiziellen Namen des Lieferanten. In SAP wird der Kreditorenstammsatz (Tabelle LFA1) über die Kreditorennummer (LIFNR) verknüpft, die im Belegkopf oder in den Positionen der Rechnung gespeichert ist. Auswertungen nach Lieferanten sind zentral für das Dashboard 'Zahlungsperformance je Lieferant'. Damit lassen sich Durchlaufzeiten, Zahlungstermintreue und Ausnahmequoten je Lieferant verfolgen. Diese Erkenntnisse helfen, Lieferantenbeziehungen zu steuern, auffällige Lieferanten mit dauerhaft schlechter Belegqualität zu identifizieren und bessere Konditionen zu verhandeln.
Warum es wichtig ist
Ermöglicht lieferantenspezifische Leistungsanalysen, unterstützt das Lieferantenmanagement und deckt Probleme auf, die bei bestimmten Lieferanten auftreten.
Woher erhalten
Aus SAP-Tabelle LFA1, Feld NAME1, verknüpft über die Kreditorennummer (LIFNR) aus BKPF oder BSEG.
Beispiele
Global Office Supplies Inc.Tech Solutions LLCReliable Logistics Corp.
|
|||
|
Rechnungsbruttobetrag
InvoiceGrossAmount
|
Der gesamte Bruttobetrag der Rechnung einschließlich Steuern und weiterer Gebühren – in der ursprünglichen Belegwährung. | ||
|
Beschreibung
Dieses Attribut gibt den gesamten finanziellen Wert einer Rechnung an. Es ist ein zentrales Datenfeld, um die finanzielle Bedeutung und die Eigenschaften der bearbeiteten Rechnungen zu verstehen. In SAP findet sich der Betrag je nach Belegart in unterschiedlichen Tabellen, z. B. in BSEG für Buchungsbelege. In der Analyse dient der Rechnungsbetrag dazu, Rechnungen mit hohem Betrag zu priorisieren, den finanziellen Durchsatz des AP‑Prozesses zu verstehen und Analysen zu segmentieren. Beispielsweise lässt sich prüfen, ob hohe Beträge längere Durchlaufzeiten haben oder abweichenden Freigabepfaden unterliegen. Zudem ist er grundlegend für finanzielle KPIs.
Warum es wichtig ist
Stellt den finanziellen Kontext zum Prozess her – für wertbasierte Analysen, die Priorisierung von Rechnungen mit hohem Betrag und die Berechnung finanzieller KPIs.
Woher erhalten
Aus SAP-Positionstabellen wie BSEG, Feld WRBTR (Betrag in Belegwährung). Ggf. Aggregation der Positionen auf Kopfebene erforderlich.
Beispiele
1500.0012550.75980.50
|
|||
|
Rechnungsfälligkeitsdatum
InvoiceDueDate
|
Das berechnete Datum, an dem die Rechnung gemäß den Zahlungsbedingungen fällig ist. | ||
|
Beschreibung
Das Fälligkeitsdatum einer Rechnung gibt an, bis wann der Lieferant gemäß den vereinbarten Zahlungsbedingungen zu bezahlen ist. In SAP ist dies oft kein einzelnes gespeichertes Feld, sondern wird aus dem Basisdatum des Belegs (BSEG‑ZFBDT) und den Zahlungsbedingungen (BSEG‑ZTERM) berechnet. Dieses Datum ist zentral für das Dashboard „Payment Compliance & Discounts“. Es dient zur Berechnung von KPIs wie der Quote überfälliger Zahlungen und zur Identifikation von Rechnungen mit Risiko verspäteter Zahlung. Die Analyse entlang dieses Datums hilft, Prioritäten zu setzen und die Lieferantenbeziehungen zu verbessern.
Warum es wichtig ist
Dies ist ein kritisches Datum zur Überwachung der Zahlungstreue, zur Berechnung von Überfälligkeits‑KPIs und für die Skontonutzung.
Woher erhalten
Abgeleitet auf Basis des Stichtags für die Fälligkeitsberechnung (BSEG‑ZFBDT) und des Schlüssels der Zahlungsbedingungen (BSEG‑ZTERM).
Beispiele
2023-10-312023-11-152024-01-10
|
|||
|
Zahlungsbedingungen
PaymentTerms
|
Der Schlüssel, der die Zahlungsbedingungen definiert – z. B. Fälligkeiten und mögliche Skonti. | ||
|
Beschreibung
Zahlungsbedingungen sind vordefinierte Regeln in SAP, die bestimmen, wie Fälligkeiten und Skonti berechnet werden. Sie sind im Kreditorenstamm hinterlegt und können auf einzelnen Rechnungen abweichend festgelegt werden. Dieses Attribut ist essenziell für das Dashboard „Payment Compliance & Discounts“ und den KPI „Early Payment Discount Capture Rate“. Durch die Analyse der Zahlungsbedingungen lassen sich Skontopotenziale erkennen, finanzielle Auswirkungen von Zahlungsplänen verstehen und Compliance sicherstellen.
Warum es wichtig ist
Definiert die Regeln für Fälligkeiten und Skonti – entscheidend für finanzielle Optimierung und Compliance‑Monitoring.
Woher erhalten
Aus SAP-Tabelle BSEG (Belegposition Finanzbuchhaltung), Feld ZTERM.
Beispiele
Z0010001NT30
|
|||
|
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 im Belegkopf gespeichert. Die Belegwährung ist für jede finanzielle Analyse essenziell, damit Beträge korrekt interpretiert werden. Sie ermöglicht, die Prozessanalyse nach Währung zu filtern, und ist Voraussetzung, um Beträge für standardisierte Berichte und Aggregationen in eine einheitliche Landeswährung umzurechnen.
Warum es wichtig ist
Liefert den nötigen Kontext zur Interpretation von Beträgen und ermöglicht währungsbezogene Analysen bzw. die Umrechnung in eine Standardwährung.
Woher erhalten
Aus SAP-Tabelle BKPF (Belegkopf Finanzbuchhaltung), Feld WAERS.
Beispiele
USDEURGBP
|
|||
|
Dokumententyp
DocumentType
|
Ein Code in SAP, der Buchhaltungsbelege klassifiziert und deren Verarbeitung steuert. | ||
|
Beschreibung
Die Belegart unterscheidet verschiedene Geschäftsvorfälle, z. B. Kreditorenrechnungen (KR), Gutschriften (KG) oder MM‑Rechnungen (RE). Diese Klassifizierung steuert u. a. Nummernkreise und zulässige Kontenarten. Im Process Mining ermöglicht das Filtern nach Belegart eine homogenere Analyse. Der Ablauf für eine Standard‑Kreditorenrechnung (KR) kann sich deutlich von dem einer Gutschrift (KG) unterscheiden. Eine getrennte Betrachtung verhindert irreführende Aggregationen und liefert präzisere Einblicke in spezifische Teilprozesse.
Warum es wichtig ist
Ermöglicht die Segmentierung der Analyse nach Transaktionstyp (z. B. Rechnung vs. Gutschrift) und liefert präzisere und relevantere Einblicke in den Prozess.
Woher erhalten
Aus SAP-Tabelle BKPF (Belegkopf Finanzbuchhaltung), Feld BLART.
Beispiele
KRREKG
|
|||
|
Ist automatisiert
IsAutomated
|
Flag, das angibt, ob eine Aktivität von einem System- oder Batch-User oder von einer Person ausgeführt wurde. | ||
|
Beschreibung
Dieses boolesche Attribut unterscheidet zwischen Aktivitäten, die automatisch ausgeführt wurden (z. B. durch Batch-Job, EDI oder ein OCR‑System), und solchen, die manuell von einem Benutzer vorgenommen wurden. Dies wird typischerweise ermittelt, indem der mit der Aktivität verknüpfte Benutzername ausgewertet wird. Das ist die Grundlage für das Dashboard 'Manuelle vs. automatisierte Verarbeitung'. Es hilft, den Erfolg von Automatisierungsinitiativen zu messen, die KPI 'Quote manueller Eingriffe' zu berechnen und verbleibende Potenziale zur Reduktion manueller Arbeit zu identifizieren. Das Verständnis von manuellen vs. systemseitigen Touchpoints ist zentral, um Effizienz zu steigern.
Warum es wichtig ist
Hilft, den Automatisierungsgrad im Prozess zu messen, manuelle Engpässe zu identifizieren und die Wirkung von Automatisierungsinitiativen zu verfolgen.
Woher erhalten
Abgeleitet, indem geprüft wird, ob die User‑ID (z. B. CDHDR‑USERNAME) zu einer vordefinierten Liste von System‑, Batch‑ oder Service‑Accounts gehört.
Beispiele
truefalsch
|
|||
|
Ist storniert
IsReversed
|
Boolean-Flag, das anzeigt, ob der Rechnungsbeleg storniert wurde. | ||
|
Beschreibung
Dieses Attribut kennzeichnet Rechnungen, die storniert bzw. rückgängig gemacht wurden – ein gravierendes Ereignis, das auf einen Fehler oder Prozessausfall hinweist. In SAP ist ein stornierter Beleg mit einem Stornobeleg verknüpft. Stornierte Rechnungen zu identifizieren, ist wichtig, um Prozessqualität und Ausfallquoten zu verstehen. So lassen sich diese finalen Ausnahmen vom Hauptprozess abgrenzen und eine gezielte Ursachenanalyse durchführen: Warum treten Stornos auf und wie lassen sie sich vermeiden?
Warum es wichtig ist
Kennzeichnet stornierte Rechnungen – ein wichtiger Indikator für Prozessfehler, der hilft, die Ursachen schwerwiegender Fehler zu analysieren.
Woher erhalten
Prüfen, ob die Belegnummer (BKPF‑BELNR) im Feld BKPF‑STBLG (Stornobeleg) eines anderen Belegs vorkommt.
Beispiele
truefalsch
|
|||
|
Ist überfällig
IsOverdue
|
Berechnetes Flag, das wahr ist, wenn die Rechnung nach dem Fälligkeitstermin bezahlt wurde. | ||
|
Beschreibung
Dieses boolesche Attribut wird abgeleitet, indem das Datum der Aktivität 'Invoice Cleared By Payment' mit dem 'Invoice Due Date' verglichen wird. Liegt das Zahlungsdatum nach dem Fälligkeitsdatum, wird das Flag auf 'true' gesetzt. Dieses Attribut unterstützt direkt den KPI 'Overdue Payment Rate' sowie das Dashboard 'Payment Compliance & Discounts'. So lassen sich verspätete Zahlungen leicht filtern und zählen – und das Ausmaß des Problems wird messbar. Die Analyse der Merkmale überfälliger Rechnungen (z. B. nach Lieferant, Buchungskreis) hilft, Ursachen aufzudecken.
Warum es wichtig ist
Misst die Einhaltung der Zahlungsbedingungen direkt und bildet die Grundlage für den KPI Overdue Payment Rate – fördert bessere Lieferantenbeziehungen und hilft, Strafgebühren zu vermeiden.
Woher erhalten
Berechnetes Feld: TRUE, wenn (Zahlungsdatum > Fälligkeitsdatum der Rechnung), sonst FALSE.
Beispiele
truefalsch
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Zeitstempel, der angibt, wann die Daten für diesen Datensatz zuletzt aus dem Quellsystem aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut kennzeichnet Datum und Uhrzeit der letzten Datenextraktion bzw. Aktualisierung aus SAP ECC. Es gehört nicht zu den Transaktionsdaten, sondern es handelt sich um Metadaten, die beim Datenimport hinzugefügt werden. In der Analyse liefert es Kontext zur Aktualität der betrachteten Daten. Das ist für Dashboards und Berichte wichtig, weil Nutzer so sehen, wie aktuell ihre Auswertung ist, und besser einschätzen können, ob sehr aktuelle Transaktionen bereits enthalten sind.
Warum es wichtig ist
Zeigt die Aktualität des Datensatzes an – entscheidend, um die Aktualität der Process-Insights und Dashboards zu bewerten.
Woher erhalten
Dies sind Metadaten, die während des ETL‑Prozesses (Extract, Transform, Load) erzeugt und hinzugefügt werden.
Beispiele
2024-05-21T02:00:00Z2024-05-22T02:00:00Z2024-05-23T02:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Kennzeichnet das SAP-ECC-Quellsystem, aus dem die Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut bezeichnet das führende System, z. B. die SAP System ID (SID), aus dem die Daten zur Rechnungsverarbeitung stammen. Besonders wichtig ist dies in Unternehmen mit mehreren ERP-Instanzen oder einem Systemmix. In der Process Mining-Analyse hilft es, Daten unterschiedlicher Systeme zu unterscheiden, die eigene Konfigurationen oder Prozessvarianten aufweisen. So werden Systemvergleiche möglich und die Datenherkunft bleibt transparent – zentral für Data Governance und Validierung.
Warum es wichtig ist
Gewährleistet die Nachverfolgbarkeit der Daten und ermöglicht Prozessanalysen in Umgebungen mit mehreren SAP-Instanzen oder weiteren Quellsystemen.
Woher erhalten
In der Regel ein statischer Wert, der die SAP‑System‑ID (SID) der Quell‑ECC‑Instanz angibt und während der Datenextraktion hinzugefügt wird.
Beispiele
ECC_PROD_EUSAP_US_01E5P
|
|||
|
Rechnungsbearbeitungszeit
InvoiceProcessingTime
|
Die Gesamtzeit vom ersten Schritt (z. B. Rechnungserfassung) bis zur letzten Aktivität (z. B. Zahlung). | ||
|
Beschreibung
Dies ist eine berechnete Kennzahl, die die End‑to‑End‑Durchlaufzeit je einzelner Rechnung misst. Sie wird gebildet, indem bei einem Vorgang (Rechnungsnummer) vom Zeitstempel des letzten Events der des ersten Events abgezogen wird. Diese Kennzahl ist der zentrale KPI des Dashboards 'End‑to‑End Invoice Cycle Time'. Sie liefert ein übergeordnetes Maß für die Gesamteffizienz des Prozesses. Die Analyse von Durchschnitt, Median und Verteilung zeigt Trends, misst den Effekt von Verbesserungen und hilft, Zielwerte festzulegen.
Warum es wichtig ist
Dies ist ein zentraler KPI zur Messung der gesamten Prozesseffizienz. Die Verfolgung im Zeitverlauf zeigt den Einfluss von Verbesserungsmaßnahmen auf den End‑to‑End‑Lebenszyklus.
Woher erhalten
Berechnetes Feld: (Zeitstempel des letzten Ereignisses des Vorgangs) - (Zeitstempel des ersten Ereignisses des Vorgangs).
Beispiele
10 Tage 2 Stunden 15 Minuten5 Tage 0 Stunden 0 Minuten22 Tage 8 Stunden 30 Minuten
|
|||
|
Skonto verloren
DiscountLost
|
Berechnetes Flag, das wahr ist, wenn ein möglicher Skonto nicht gezogen wurde. | ||
|
Beschreibung
Dieses Attribut markiert Rechnungen, bei denen die Zahlungsbedingungen Skonto bieten, die Zahlung aber nach Ablauf der Skontofrist erfolgte. Die Ermittlung erfolgt durch den Vergleich des Zahlungsdatums mit dem aus den 'Zahlungsbedingungen' abgeleiteten Skontofälligkeitsdatum. Das ist eine zentrale finanzielle KPI für die 'Skonto‑Nutzungsquote'. Sie macht verpasste Einsparpotenziale sichtbar. Die Analyse der Ursachen für verlorene Skonti (z. B. lange Freigabezyklen, Zahlungssperren) kann Verbesserungsprojekte mit klarem ROI begründen.
Warum es wichtig ist
Macht verpasste finanzielle Chancen sichtbar, unterstützt direkt den KPI „Skonto-Nutzungsquote“ und liefert einen klaren monetären Anreiz für Prozessverbesserungen.
Woher erhalten
Berechnetes Feld: TRUE, wenn (Zahlungsbedingungen Skonto vorsehen) UND (Zahlungsdatum > Skontofrist), sonst FALSE.
Beispiele
truefalsch
|
|||
|
Wareneingangsnummer
GoodsReceiptNumber
|
Die Kennung des Wareneingangsbelegs zu einer PO‑basierten Rechnung. | ||
|
Beschreibung
Bei Rechnungen zu physischen Gütern bestätigt der Wareneingangsbeleg (GR) die Lieferung durch den Lieferanten. Diese Nummer verknüpft die Rechnung mit dem konkreten Lieferereignis. Dieses Attribut wird im Dashboard „PO/GR Matching Performance“ genutzt. Die Zeit zwischen GR-Buchung und Rechnungsbuchung ist eine Schlüsselkennzahl. Die Analyse dieser Verknüpfung hilft, den vollständigen 3‑Wege-Abgleich zu verstehen und Verzögerungen zwischen physischer Lieferung und finanzieller Abrechnung aufzudecken.
Warum es wichtig ist
Vervollständigt den 3‑Wege‑Abgleich (Bestellung–Wareneingang–Rechnung) und ermöglicht die Analyse von Verzögerungen zwischen Wareneingang und Rechnungsverarbeitung.
Woher erhalten
Aus SAP-Tabelle RSEG (Belegposition, Eingangsrechnung), Feld LFBNR (Belegnummer eines Referenzbelegs).
Beispiele
500000123450000015675000002100
|
|||
Aktivitäten der Kreditoren-Rechnungsverarbeitung
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Rechnung durch Zahlung ausgeglichen
|
Die Rechnung ist vollständig bezahlt, und der offene Posten wird mit einem Zahlungsbeleg ausgeglichen. Damit ist die Verarbeitung der Rechnung in der Kreditorenbuchhaltung erfolgreich abgeschlossen. Dies wird über die Informationen zum Ausgleichsbeleg erfasst. | ||
|
Warum es wichtig ist
Dies ist das End‑Event des primären Erfolgswegs. Die Zeit bis zu dieser Aktivität ist ein wesentlicher Indikator für die Prozesseffizienz. Zudem ist sie grundlegend für die Berechnung der Einhaltung von Zahlungsterminen und der Skontonutzung.
Woher erhalten
Dieses Event wird erkannt, wenn für die Kreditorenzeile die Ausgleichsbelegnummer (BSEG‑AUGBL) und das Ausgleichsdatum (BSEG‑AUGDT) gefüllt sind. Das Ausgleichsdatum ist der Zeitstempel des Events.
Erfassen
Verwenden Sie das Ausgleichsdatum (BSEG.AUGDT), wenn der Ausgleichsbeleg (BSEG.AUGBL) vorhanden ist.
Ereignistyp
explicit
|
|||
|
Rechnung freigegeben
|
Eine zuständige Person hat bestätigt, dass die Rechnung korrekt ist und zur Zahlung freigegeben werden kann. Das kann ein explizites Event aus einem Workflow-System sein oder sich aus dem Entfernen einer Zahlungssperre ergeben. Ein zentraler Meilenstein vor der Zahlung. | ||
|
Warum es wichtig ist
Dies ist ein wichtiger Meilenstein, der die Rechnung für die Zahlung freigibt. Verzögerungen vor oder nach diesem Schritt deuten auf unterschiedliche Probleme hin, etwa die Verfügbarkeit der Genehmiger oder die Terminierung des Zahllaufs.
Woher erhalten
In einem Workflow-System ist dies ein explizites Ereignis. Andernfalls wird es üblicherweise aus dem Entfernen eines Zahlungsblocks abgeleitet, erfasst über Änderungsbelege (CDHDR/CDPOS) für das Feld BSEG-ZLSPR.
Erfassen
Event aus dem Workflow-System oder dem Änderungsprotokoll zur Aufhebung der Zahlungssperre.
Ereignistyp
explicit
|
|||
|
Rechnung gebucht
|
Die Rechnung wird offiziell in der Hauptbuchhaltung erfasst und begründet eine Verbindlichkeit. Ein geparkter Beleg wird in einen gebuchten Beleg überführt – oder der Beleg wird direkt gebucht. Das ist ein grundlegender Schritt in der Finanzbuchhaltung. | ||
|
Warum es wichtig ist
Die Buchung ist ein zentraler Meilenstein: Sie macht die Rechnung zur offiziellen Verbindlichkeit. Damit endet die Datenerfassung und es beginnt die aktive Zahlungssteuerung.
Woher erhalten
Ermittelt aus der Belegkopftabelle BKPF. Ein gebuchter Beleg hat einen leeren Belegstatus (BKPF-BSTAT) und ein gültiges Buchungsdatum (BKPF-BUDAT). Der Zeitstempel des Ereignisses ist das Buchungsdatum.
Erfassen
Verwenden Sie BKPF.BUDAT für Belege, bei denen BKPF.BSTAT nicht 'V' (geparkt) ist oder 'V' geändert wurde.
Ereignistyp
explicit
|
|||
|
Rechnung storniert
|
Der gebuchte Rechnungsbeleg wurde storniert, indem ein Stornobeleg angelegt wurde. Damit wird die finanzielle Wirkung der ursprünglichen Rechnung neutralisiert. Dies stellt ein alternatives, häufig unerwünschtes Prozessende dar. | ||
|
Warum es wichtig ist
Stornos deuten meist auf Fehler hin, z. B. durch falsche Eingaben oder Dubletten. Die Verfolgung von Häufigkeit und Gründen für Stornos zeigt Hebel für bessere Datenqualität und eine First‑Time‑Right‑Verarbeitung.
Woher erhalten
Dieses Event wird aus der Belegkopftabelle (BKPF) ermittelt. Im Originalbeleg ist die Stornobelegnummer (BKPF‑STBLG) gefüllt. Der Zeitpunkt des Events ist das Buchungsdatum des Stornobelegs.
Erfassen
Suchen Sie den Stornobeleg in BKPF.STBLG; ermitteln Sie den Zeitstempel aus dem Buchungsdatum des Stornobelegs.
Ereignistyp
explicit
|
|||
|
Rechnungsbeleg angelegt
|
Kennzeichnet die erstmalige Anlage eines Rechnungsbelegs in SAP – entweder geparkt oder vollständig gebucht. Das ist in der Regel das erste Ereignis mit Zeitstempel für eine Rechnung und dient als Startpunkt der Prozessanalyse. Erfasst über Belegerfassungsdatum und -zeit in der Tabelle BKPF. | ||
|
Warum es wichtig ist
Diese Aktivität ist das zentrale Startevent der Rechnungsverarbeitung. Die Zeitmessung ab diesem Punkt ermöglicht es, die End-to-End-Durchlaufzeit zu bestimmen und Verzögerungen bei der ersten Datenerfassung aufzudecken.
Woher erhalten
Dieses Event wird aus dem Erstellungszeitstempel des Buchungsbelegkopfs abgeleitet. Konkret liefert die Kombination aus Erfassungsdatum (BKPF‑CPUDT) und Erfassungszeit (BKPF‑CPUTM) den Zeitstempel.
Erfassen
Verwenden Sie den Erstellungszeitstempel aus der Belegkopftabelle BKPF (CPUDT, CPUTM).
Ereignistyp
inferred
|
|||
|
Zahlungsvorschlag erstellt
|
Die Rechnung wurde im Rahmen eines Zahlungslaufs (T‑Code F110) in einen Zahlungsvorschlag aufgenommen. Das ist noch keine endgültige Zahlung, signalisiert aber die Zahlungsabsicht. Die Auswahl erfolgt anhand der Fälligkeit und der Zahlungsbedingungen. | ||
|
Warum es wichtig ist
Dies ist der erste Schritt im automatisierten Zahlungsprozess. Verzögerungen zwischen Vorschlag und endgültiger Zahlungsausführung können auf Probleme bei Freigabe oder Terminierung des Zahllaufs hinweisen.
Woher erhalten
Dieses Event wird erkannt, indem das Rechnungsdokument in Vorschlagstabellen des Zahllaufs gefunden wird, z. B. REGUP (verarbeitete Positionen des Zahlungsprogramms). Das Laufdatum (REGUP‑LAUFD) kann als Zeitpunkt des Events dienen.
Erfassen
Suchen Sie die Rechnung in der Tabelle REGUP und verwenden Sie das Zahllaufdatum (LAUFD).
Ereignistyp
explicit
|
|||
|
Bestellung abgeglichen
|
Diese Aktivität zeigt an, dass die Rechnungsposition erfolgreich mit einer Bestellung verknüpft wurde. Das ist ein zentraler Prüfschritt im 3‑Way Match (Dreifachabgleich). Abgeleitet wird dies aus der vorhandenen Bestellnummer in den Positionsdetails der Rechnung. | ||
|
Warum es wichtig ist
Verzögerungen beim PO‑Abgleich sind oft ein wesentlicher Engpass. Die Analyse dieser Aktivität misst die Effizienz des Matchings und erkennt Rechnungen, die vom standardmäßigen PO‑basierten Workflow abweichen.
Woher erhalten
Abgeleitet aus dem Kreditoreneinzelposten in der Tabelle BSEG. Ist das Feld Bestellnummer (BSEG-EBELN) vorhanden, gilt der Abgleich als zum Zeitpunkt der Belegerstellung erfolgt.
Erfassen
Prüfen, ob in BSEG.EBELN für die Rechnung ein Wert ungleich NULL vorhanden ist.
Ereignistyp
inferred
|
|||
|
Fälligkeit verstrichen – keine Zahlung
|
Dieses berechnete Event tritt ein, wenn das aktuelle Datum die Nettofälligkeit der Rechnung überschreitet, die Rechnung aber noch nicht ausgeglichen ist. Es markiert Rechnungen, bei denen Verzug droht oder die bereits überfällig sind. Dies ist kein direktes System‑Event. | ||
|
Warum es wichtig ist
Diese Aktivität ist entscheidend, um die KPI für den Anteil überfälliger Zahlungen zu überwachen. Sie kennzeichnet proaktiv Rechnungen, die sofortige Aufmerksamkeit benötigen – um Mahngebühren zu vermeiden und die Lieferantenbeziehungen nicht zu belasten.
Woher erhalten
Dies ist ein berechnetes Event. Es wird ermittelt, indem das aktuelle Datum mit dem Netto‑Fälligkeitsdatum (BSEG‑ZFBDT) aller offenen (nicht ausgeglichenen) Rechnungspositionen verglichen wird. Der Zeitstempel des Events ist das Fälligkeitsdatum selbst.
Erfassen
Ermitteln durch Vergleich des aktuellen Datums mit BSEG.ZFBDT für offene Posten.
Ereignistyp
calculated
|
|||
|
Rechnung geparkt
|
Bezeichnet eine Rechnung, die in SAP erfasst, aber noch nicht ins Hauptbuch gebucht wurde. Dies ist eine bewusste Aktion, die eine spätere Vervollständigung oder Freigabe ermöglicht. Das Belegstatusfeld im Belegkopf zeigt an, ob eine Rechnung geparkt ist. | ||
|
Warum es wichtig ist
Das Parken eines Belegs ist eine bewusste Prozesspause – häufig zur Prüfung oder wegen fehlender Informationen. Die Nachverfolgung zeigt Ursachen für Verzögerungen auf, bevor eine Rechnung offiziell gebucht wird.
Woher erhalten
Erkennbar in der Kopftabelle BKPF, wenn der Belegstatus (BKPF-BSTAT) „V“ (geparkt) ist. Die Event Time ist die Belegerstellungszeit (BKPF-CPUDT, BKPF-CPUTM).
Erfassen
Filter für Belege, bei denen BKPF.BSTAT = 'V' ist.
Ereignistyp
explicit
|
|||
|
Rechnung zur Freigabe weitergeleitet
|
Die Rechnung wurde offiziell in einen Freigabe‑Workflow eingereicht. Diese Aktivität basiert häufig auf einem externen Workflow‑System oder einem bestimmten Statuswechsel in SAP. Dies markiert meist den Start des Freigabe‑Teilprozesses. | ||
|
Warum es wichtig ist
Dies markiert den Beginn des Freigabezyklus. Die Zeitspanne von diesem Event bis 'Invoice Approved' ist entscheidend für den KPI zur Freigabe‑Durchlaufzeit und zur Identifikation genehmigerbezogener Engpässe.
Woher erhalten
Wenn SAP Business Workflow verwendet wird, lässt sich dieses Ereignis aus den Workflow-Logs (z. B. SWWLOG) extrahieren. Andernfalls ist es ein konzeptioneller Schritt, der häufig daraus abgeleitet wird, dass aus Freigabegründen ein Zahlungsblock gesetzt wurde.
Erfassen
Aus Workflow-Logs extrahieren oder aus dem Setzen einer spezifischen Zahlungssperre ableiten.
Ereignistyp
explicit
|
|||
|
Wareneingang abgeglichen
|
Bezeichnet die Bestätigung, dass die auf der Rechnung ausgewiesenen Waren oder Leistungen eingegangen sind – durch Verknüpfung mit einem Wareneingangsbeleg. Das ist die dritte Komponente des Three‑Way‑Match (Drei‑Wege‑Abgleichs). Sie wird aus Verweisen auf Positionsebene der Rechnung abgeleitet. | ||
|
Warum es wichtig ist
Der Abgleich mit dem Wareneingang bestätigt, dass das Unternehmen erhält, wofür es bezahlt. Die Nachverfolgung unterstützt die Analyse der Matching-Dauer (PO–GR–Invoice) und verschlankt die Validierung.
Woher erhalten
Abgeleitet aus dem Kreditoreneinzelposten in der Tabelle BSEG: Es wird geprüft, ob eine Wareneingangsbelegnummer (BSEG-LFBNR) vorhanden ist, oder die Historie der verknüpften Bestellung (Tabelle EKBE) wird nachverfolgt.
Erfassen
Prüfen, ob ein WE‑Bezug in BSEG.LFBNR vorhanden ist oder über die Bestellhistorie in EKBE.
Ereignistyp
inferred
|
|||
|
Zahlungssperre entfernt
|
Eine zuvor gesetzte Zahlungssperre wurde von der Rechnung entfernt; die Rechnung ist damit wieder zur Zahlung freigegeben. Das weist häufig darauf hin, dass eine Unstimmigkeit geklärt oder eine Freigabe erteilt wurde. Das Event wird aus den Änderungsbelegtabellen ermittelt. | ||
|
Warum es wichtig ist
Diese Aktivität steht für die Auflösung einer Ausnahme bzw. den Abschluss einer Freigabe. Die Dauer, in der die Sperre aktiv war, entspricht Nacharbeit oder Wartezeit – ein zentraler Hebel für Prozessverbesserungen.
Woher erhalten
Dieses Event wird erfasst, indem Änderungen am Feld Payment Block Key (BSEG‑ZLSPR) nachverfolgt werden. Änderungsprotokolle in den Tabellen CDHDR und CDPOS zeigen, wann dieses Feld zurückgesetzt wurde.
Erfassen
Erfassen Sie Änderungseinträge in CDHDR/CDPOS, bei denen das Feld BSEG‑ZLSPR auf leer gesetzt wurde.
Ereignistyp
explicit
|
|||
|
Zahlungssperre gesetzt
|
Eine Rechnung ist aktiv für die Zahlung gesperrt, meist aufgrund einer Abweichung, ausstehender Freigabe oder eines anderen Problems. Es handelt sich um einen expliziten Status auf der Rechnungsposition. Das Ereignis lässt sich über Änderungsbelegtabellen erfassen. | ||
|
Warum es wichtig ist
Diese Aktivität markiert den Beginn einer Ausnahme- oder Freigabephase. Die Analyse von Häufigkeit und Dauer von Zahlungssperren ist entscheidend, um Prozessengpässe und Klärfälle zu erkennen und zu beheben.
Woher erhalten
Das Ereignis wird erfasst, indem Änderungen am Feld „Zahlungssperre“ (BSEG‑ZLSPR) nachverfolgt werden. Änderungsprotokolle in den Tabellen CDHDR und CDPOS dokumentieren, wann dieses Feld befüllt wurde.
Erfassen
Erfassen Sie die Anlage von Einträgen in CDHDR/CDPOS für das Feld BSEG‑ZLSPR.
Ereignistyp
explicit
|
|||