Ihr Daten-Template für die Rechnungsverarbeitung im Purchase-to-Pay-Prozess
Ihr Daten-Template für die Rechnungsverarbeitung im Purchase-to-Pay-Prozess
- Empfohlene Attribute für eine detaillierte Analyse
- Wichtige Aktivitäten im Verlauf der Rechnungsverarbeitung
- Hinweise zur Datenextraktion aus Microsoft Dynamics 365
Attribute der Rechnungsverarbeitung im Purchase-to-Pay-Prozess
| Name | Beschreibung | ||
|---|---|---|---|
|
Aktivitätsname
ActivityName
|
Der Name des konkreten Geschäftsvorgangs oder der Aufgabe, die zu einem bestimmten Zeitpunkt im Rechnungsverarbeitungsprozess stattgefunden hat. | ||
|
Beschreibung
Der Aktivitätsname bezeichnet einen bestimmten Schritt oder eine Statusänderung im Rechnungsprozess, etwa „Rechnung registriert“, „Rechnung zur Freigabe eingereicht“ oder „Zahlung ausgeführt“. Diese Daten sind entscheidend, um die Prozesslandkarte zu erstellen und die Reihenfolge der Ereignisse nachzuvollziehen. Die Analyse dieses Attributs zeigt den Prozessablauf, macht häufige Pfade sichtbar und weist auf Abweichungen oder Engpässe hin. Anhand der Aktivitätsnamen lassen sich Zykluszeiten zwischen einzelnen Aktivitäten berechnen, etwa die Dauer vom Freigabe- bis zum Buchungsschritt. Außerdem können Sie die Häufigkeit bestimmter Ereignisse wie Ablehnungen oder Zahlungssperren messen.
Warum das wichtig ist
Dieses Attribut definiert die Schritte in der Prozesslandkarte. So lässt sich der Prozessablauf visualisieren und der Übergang zwischen verschiedenen Aktivitäten analysieren.
Woher beziehen
Dieses Attribut wird üblicherweise aus einer Kombination von Statusfeldern, Transaktionstypen oder Änderungsprotokolleinträgen in verschiedenen Dynamics-365-Tabellen zur Rechnungsverarbeitung abgeleitet.
Beispiele
Rechnung zur Freigabe eingereichtAbweichung beim Abgleich festgestelltZahlung ausgeführt
|
|||
|
Ereigniszeit
EventTime
|
Der genaue Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat. | ||
|
Beschreibung
Die Ereigniszeit, also der Timestamp, erfasst das genaue Datum und die Uhrzeit einer Aktivität. Sie ist ein wichtiger Bestandteil des Event Logs: Mit ihr lassen sich Aktivitäten zeitlich korrekt ordnen und Zeiträume berechnen. In der Analyse bildet dieser Timestamp die Grundlage für alle zeitbezogenen Kennzahlen. Er dient dazu, die Dauer einzelner Aktivitäten, die Zykluszeit zwischen verschiedenen Schritten (z. B. die Freigabezeit) und die gesamte Verarbeitungszeit jeder Rechnung zu berechnen. Außerdem ermöglicht er die Trendanalyse im Zeitverlauf.
Warum das wichtig ist
Dieser Timestamp ist entscheidend, um Ereignisse zu ordnen, Zykluszeiten und Zeiträume zu berechnen und Prozessengpässe zu erkennen.
Woher beziehen
Dieser Wert stammt aus Datums- und Zeitfeldern in verschiedenen Tabellen, etwa aus den Feldern createdDateTime oder modifiedDateTime in Tabellen wie VendInvoiceInfoTable, VendTrans oder Workflow-Verlaufstabellen.
Beispiele
2023-04-15T09:00:12Z2023-05-20T14:30:00Z2023-06-01T11:05:45Z
|
|||
|
Rechnungsnummer
InvoiceNumber
|
Die eindeutige Kennung jeder Lieferantenrechnung. Sie dient als primäre Case-ID, um den gesamten Prozessverlauf nachzuverfolgen. | ||
|
Beschreibung
Die Rechnungsnummer ist der eindeutige Schlüssel, der alle Aktivitäten zu einer einzelnen Lieferantenrechnung miteinander verknüpft. Damit lässt sich der gesamte Weg der Rechnung nachvollziehen, vom Eingang und der Registrierung über den Abgleich und die Freigabe bis zur abschließenden Zahlung. In der Process-Mining-Analyse ist dieses Attribut grundlegend. Es definiert den Case und ermöglicht die Rekonstruktion des Ablaufs jeder Rechnung. So lassen sich die gesamten Zykluszeiten berechnen, Prozessvarianten erkennen und rechnungsspezifische Merkmale sowie Ergebnisse analysieren.
Warum das wichtig ist
Diese wichtige Case-ID verknüpft alle zugehörigen Ereignisse und ermöglicht die Analyse des gesamten Verlaufs jeder einzelnen Rechnung.
Woher beziehen
Dieses Feld befindet sich üblicherweise in der Haupttabelle für Lieferantenrechnungen, etwa in VendInvoiceInfoTable im Feld Num.
Beispiele
INV-10056773245-AUS-001-98432
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der Timestamp, der angibt, wann die Daten für diesen Prozess zuletzt aus dem Quellsystem aktualisiert wurden. | ||
|
Beschreibung
Dieses Attribut erfasst, wann der Datensatz zuletzt aus Microsoft Dynamics 365 exportiert und aktualisiert wurde. Innerhalb eines einzelnen Datenimports ist der Wert üblicherweise für alle Datensätze gleich. Anhand dieser Information können Benutzer beurteilen, wie aktuell die analysierten Daten sind. Sie zeigt, wie aktuell die Prozesserkenntnisse sind, und ist wichtig für die Planung regelmäßiger Datenaktualisierungen und die Validierung von Datenpipelines.
Warum das wichtig ist
Das Attribut informiert Benutzer über die Aktualität der Daten. So wissen sie, wie aktuell die Analyse ist und wann die nächste Datenaktualisierung erwartet wird.
Woher beziehen
Dieser Timestamp wird bei der Ausführung vom Datenexport- oder ETL-Prozess generiert und dem Datensatz hinzugefügt.
Beispiele
2023-10-27T02:00:00Z2023-10-28T02:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Das führende System, aus dem die Ereignisdaten exportiert wurden. | ||
|
Beschreibung
Dieses Attribut gibt an, aus welcher Quellanwendung die Aktivitätsdaten stammen. Für diesen Prozess ist das üblicherweise „Microsoft Dynamics 365“. In Umgebungen mit mehreren Systemen, etwa einer externen OCR- oder Erfassungslösung, zeigt dieses Feld, in welchem System die einzelnen Prozessschritte stattfinden. So bleibt die Herkunft der Daten nachvollziehbar und Probleme beim Datenexport lassen sich leichter untersuchen.
Warum das wichtig ist
Das Attribut liefert wichtige Informationen zur Herkunft der Daten. Diese sind für die Datenvalidierung und das Verständnis der Systemlandschaft des Prozesses relevant.
Woher beziehen
Dies ist ein statischer Wert, „Microsoft Dynamics 365“, der bei der Datentransformation hinzugefügt wird, um die Herkunft des Datensatzes zu kennzeichnen.
Beispiele
Microsoft Dynamics 365
|
|||
|
Benutzer
User
|
Benutzer-ID oder Name der Person, die die Aktivität ausgeführt hat. | ||
|
Beschreibung
Dieses Attribut gibt an, welcher Mitarbeitende oder Systembenutzer für einen bestimmten Prozessschritt verantwortlich war. Bei automatisierten Schritten kann es sich um ein System- oder Dienstkonto handeln. Die Analyse nach Benutzer hilft, die Arbeitsverteilung zu verstehen, Schulungsbedarf zu erkennen und die Leistung einzelner Personen oder Teams zu vergleichen. Sie ist wichtig, um Nacharbeitsschleifen zu untersuchen, bei denen Aufgaben zwischen Benutzern hin- und hergegeben werden, und um Unterschiede darin zu erkennen, wie verschiedene Benutzer dieselbe Aufgabe erledigen.
Warum das wichtig ist
Ermöglicht die Analyse von Leistung und Arbeitsaufkommen nach Benutzer oder Team und hilft, den Automatisierungsgrad sowie Ursachen für Nacharbeit zu erkennen.
Woher beziehen
Stammt aus Benutzer-ID-Feldern in Transaktions- oder Workflow-Verlaufstabellen, zum Beispiel aus den Feldern createdby oder modifiedby. Die Informationen können auch in den Workflow-Trackingtabellen stehen.
Beispiele
j.doea.smithAX_Admin
|
|||
|
Bestellnummer
PurchaseOrderNumber
|
Kennung der Bestellung (PO), auf die sich die Rechnung bezieht. | ||
|
Beschreibung
Die Bestellnummer verknüpft eine Rechnung mit dem ursprünglichen Beschaffungsbeleg. Sie ist entscheidend für Prozesse, bei denen ein 2-Wege- oder 3-Wege-Abgleich zwischen Rechnung, Bestellung und Wareneingang erfolgt. Mit diesem Attribut lassen sich Rechnungen mit und ohne Bestellbezug getrennt analysieren, da sie häufig unterschiedliche Prozesspfade durchlaufen. Es ist wichtig, um die Wirksamkeit des Abgleichs zu beurteilen, Abweichungen zu untersuchen und die Quote der automatischen Verarbeitung von Rechnungen mit Bestellbezug zu messen.
Warum das wichtig ist
Damit lassen sich Rechnungen mit Bestellbezug von Rechnungen ohne Bestellbezug unterscheiden. Das ist ein wesentlicher Grund für Prozessabweichungen und entscheidend für die Analyse des Abgleichs.
Woher beziehen
Befindet sich in der Rechnungskopftabelle, zum Beispiel in VendInvoiceInfoTable, häufig in einem Feld wie PurchId.
Beispiele
PO-001234PO-005678PO-009101
|
|||
|
Endzeit
EndTime
|
Der genaue Timestamp, zu dem eine bestimmte Aktivität oder ein Ereignis abgeschlossen wurde. | ||
|
Beschreibung
Die Endzeit gibt an, wann eine Aktivität abgeschlossen wurde. Zusammen mit der Startzeit (EventTime) ermöglicht sie eine genaue Berechnung der Dauer jedes einzelnen Prozessschritts. Dieses Attribut ist wichtig, um die „Verarbeitungszeit“ für jede Aktivität zu berechnen, eine zentrale Kennzahl für die Leistungsanalyse. Es zeigt genau, welche Prozessschritte am meisten Zeit beanspruchen, und ermöglicht gezielte Verbesserungsmaßnahmen. So lässt sich beispielsweise die genaue Dauer eines manuellen Kontierungs- oder Freigabeschritts ermitteln.
Warum das wichtig ist
Ermöglicht die direkte Berechnung der Verarbeitungszeiten einzelner Aktivitäten. Das ist grundlegend, um die zeitaufwendigsten Prozessschritte zu erkennen.
Woher beziehen
Wie StartTime stammt dieser Wert aus verschiedenen Datums- und Zeitfeldern. Bei manchen Aktivitäten kann es sich um die StartTime der nächsten Aktivität handeln, in anderen Fällen um einen eigenen Timestamp für den Abschluss.
Beispiele
2023-04-15T09:15:20Z2023-05-20T18:00:00Z2023-06-01T11:05:45Z
|
|||
|
Lieferantennummer
VendorNumber
|
Eindeutige Kennung des Lieferanten, der die Rechnung eingereicht hat. | ||
|
Beschreibung
Die Lieferantennummer ist der eindeutige Code, der einen Lieferanten in den Stammdaten identifiziert. Sie ordnet den Rechnungsvorgang einem bestimmten Lieferanten zu und ermöglicht so lieferantenbezogene Analysen. Dieses Attribut ist wichtig, um die Prozessdaten nach Lieferanten aufzuschlüsseln. Damit lassen sich Fragen beantworten wie: „Bei welchen Lieferanten dauern Freigaben am längsten?“ oder „Treten bei bestimmten Lieferanten häufiger Abweichungen beim Abgleich auf?“ Die Analyse der Leistung nach Lieferant kann Ansatzpunkte für die Zusammenarbeit mit Lieferanten und für Prozessverbesserungen aufzeigen.
Warum das wichtig ist
Ermöglicht Filterung und Ursachenanalyse nach Lieferant, um Leistungsprobleme oder Muster bei bestimmten Lieferanten zu erkennen.
Woher beziehen
Dieses Feld befindet sich üblicherweise im Kopf der Lieferantenrechnungstabelle, zum Beispiel in VendInvoiceInfoTable, und ist mit den zentralen Lieferantenstammdaten in VendTable verknüpft.
Beispiele
V-1001V-2050V-8342
|
|||
|
Rechnungsbetrag
InvoiceAmount
|
Der Gesamtbetrag der Rechnung. | ||
|
Beschreibung
Dieses Attribut enthält den auf der Lieferantenrechnung ausgewiesenen Gesamtbetrag. Es ist eine zentrale Finanzkennzahl für jeden Case. Der Rechnungsbetrag wird häufig für Segmentierungen und Analysen verwendet. So lässt sich feststellen, ob Rechnungen mit hohem Wert ein strengeres Freigabeverfahren durchlaufen oder länger bearbeitet werden. In Dashboards kann das Rechnungsvolumen nach Wert ausgewertet werden. Außerdem lässt sich der Betrag aggregieren, um die gesamten analysierten Ausgaben zu ermitteln.
Warum das wichtig ist
Ermöglicht Analysen nach Rechnungswert. So können Verbesserungsmaßnahmen auf Rechnungen mit hohem Wert ausgerichtet und Kostentreiber untersucht werden.
Woher beziehen
Zu finden in der Rechnungskopftabelle, zum Beispiel in VendInvoiceInfoTable, in einem Feld wie InvoiceAmount oder Amount.
Beispiele
1500.00250.7512500.50
|
|||
|
Rechnungsstatus
InvoiceStatus
|
Aktueller Status der Rechnung zum Zeitpunkt der Datenextraktion. | ||
|
Beschreibung
Der Rechnungsstatus zeigt den aktuellen Stand einer Rechnung in ihrem Lebenszyklus an, zum Beispiel „Ausstehende Freigabe“, „Genehmigt“, „Gebucht“ oder „Bezahlt“. Er gibt einen Überblick über den Fortschritt der Rechnung. Dieses Attribut wird vor allem für operative Dashboards verwendet, die das aktuelle Arbeitsaufkommen und den Rückstand anzeigen. Es hilft Führungskräften zu erkennen, wie viele Rechnungen sich in den einzelnen Prozessphasen befinden, und unterstützt so die Ressourcenplanung und die operative Überwachung. Es ist zentral für das Dashboard „Rechnungsverarbeitung: Durchsatz und Status“.
Warum das wichtig ist
Zeigt den aktuellen Status aller Rechnungen an und ist damit wichtig für die operative Überwachung, die Steuerung des Arbeitsaufkommens und das Erkennen aktueller Engpässe.
Woher beziehen
Wird üblicherweise aus Statusfeldern der zentralen Rechnungstabelle abgeleitet, zum Beispiel aus VendInvoiceInfoTable.
Beispiele
Ausstehende FreigabeGebuchtBezahlt
|
|||
|
Zahlungsziel
PaymentDueDate
|
Datum, bis zu dem die Rechnung gemäß den vereinbarten Zahlungsbedingungen bezahlt werden soll. | ||
|
Beschreibung
Das Zahlungsziel wird anhand des Rechnungsdatums und der Zahlungsbedingungen des Lieferanten berechnet. Es bezeichnet die vertraglich vereinbarte Zahlungsfrist. Dieses Datum ist wichtig, um die finanzielle Leistung und die Lieferantenbeziehungen zu beurteilen. Es dient als Grundlage für die KPI „Pünktliche Zahlungsquote“, die durch einen Vergleich mit dem tatsächlichen Datum der Aktivität „Zahlung ausgeführt“ berechnet wird. Die Analyse hilft, systematische Ursachen für verspätete Zahlungen zu erkennen. Diese können Lieferantenbeziehungen belasten oder dazu führen, dass Skonti nicht genutzt werden.
Warum das wichtig ist
Dient als Maßstab für die Pünktlichkeit von Zahlungen und ist eine wichtige KPI für die finanzielle Gesundheit und die Lieferantenbeziehungen.
Woher beziehen
Dieses Datum wird häufig vom System anhand des Rechnungsdatums und der Zahlungsbedingungen berechnet und in der Lieferantentransaktionstabelle, zum Beispiel VendTrans, gespeichert.
Beispiele
2023-05-152023-06-302023-07-20
|
|||
|
Ablehnungsgrund
RejectionReason
|
Vom Freigebenden angegebener Grund für die Ablehnung einer Rechnung. | ||
|
Beschreibung
Wird eine Rechnung im Freigabe-Workflow abgelehnt, gibt der Freigebende üblicherweise einen Grund an. Dieses Attribut erfasst die Begründung, die als vordefinierter Code oder Freitext vorliegen kann. Das Attribut ist wichtig für das Dashboard „Analyse abgelehnter Rechnungen“. Es liefert die qualitativen Informationen, die nötig sind, um die Ursachen für Ablehnungen zu verstehen, zum Beispiel „Falsche Bestellnummer“, „Doppelte Rechnung“ oder „Preisabweichung“. Die Analyse dieser Gründe hilft, Maßnahmen zur Senkung der Ablehnungsquote zu priorisieren.
Warum das wichtig ist
Zeigt direkt, warum Rechnungen abgelehnt werden, und ermöglicht gezielte Maßnahmen, um Nacharbeit zu verringern und die Quote der fehlerfreien Bearbeitung im ersten Durchlauf zu verbessern.
Woher beziehen
Üblicherweise in den Kommentaren oder Verlaufsprotokollen der Workflow-Verarbeitungstabellen zu finden.
Beispiele
Falsche MengeDoppelte RechnungFreigabelimit überschritten
|
|||
|
Abteilung
Department
|
Kostenstelle oder Abteilung, der die Rechnungskosten zugeordnet werden. | ||
|
Beschreibung
Die Abteilung bezeichnet die Geschäftseinheit oder Kostenstelle, die für die auf der Rechnung ausgewiesenen Ausgaben verantwortlich ist. Die Zuordnung erfolgt üblicherweise bei der Kontierung der Rechnung. Die Analyse nach Abteilung ist wichtig, um Unterschiede bei Ausgaben, Freigabezeiten und Compliance zu verstehen. Sie zeigt, in welchen Abteilungen die meisten Rechnungen Ausnahmen aufweisen oder die Freigabe am längsten dauert. Daraus lassen sich gezielte Informationen und Schulungen ableiten.
Warum das wichtig ist
Ermöglicht Kosten- und Prozessanalysen nach Abteilung und macht Unterschiede bei Leistung und Compliance innerhalb der Organisation sichtbar.
Woher beziehen
Stammt aus den Finanzdimensionen, die mit den Rechnungspositionen oder dem Rechnungskopf verknüpft sind. Dafür müssen die zugehörigen Datenstrukturen abgefragt werden.
Beispiele
VertriebMarketingIT-Betrieb
|
|||
|
Abweichungstyp
MatchingDiscrepancyType
|
Ordnet die beim Abgleich von Rechnung und Bestellung festgestellte Abweichung einer Kategorie zu. | ||
|
Beschreibung
Tritt beim 2-Wege- oder 3-Wege-Abgleich eine Abweichung auf, gibt dieses Attribut deren Art an, zum Beispiel „Preisabweichung“, „Mengenabweichung“ oder „Fehlender Wareneingang“. Diese Daten sind zentral für das Dashboard „Bearbeitungszeit von Abweichungen beim Abgleich“. Die Analyse der Häufigkeit verschiedener Abweichungstypen hilft dem Unternehmen, die Ursachen für fehlgeschlagene Abgleiche zu erkennen. Häufige Preisabweichungen können beispielsweise auf veraltete Stammdaten hindeuten, während Mengenabweichungen auf Probleme beim Versand hinweisen können.
Warum das wichtig ist
Kategorisiert fehlgeschlagene Abgleiche und ermöglicht eine Ursachenanalyse, um Abweichungen zu verringern und die automatische Verarbeitung zu verbessern.
Woher beziehen
Diese Information kann in einer eigenen Tabelle für Abgleiche oder Ausnahmen gespeichert sein. Möglicherweise muss sie auch aus Statusmeldungen oder Workflow-Kommentaren abgeleitet werden.
Beispiele
PreisabweichungMengenabweichungFehlender Wareneingang
|
|||
|
Automatisiert
IsAutomated
|
Kennzeichen dafür, ob eine Aktivität automatisch vom System oder manuell von einem Benutzer ausgeführt wurde. | ||
|
Beschreibung
Dieses boolesche Attribut (true/false) unterscheidet zwischen vom System ausgeführten Ereignissen und manuellen Benutzeraufgaben. So kann der Rechnungsabgleich automatisiert sein, während die Bearbeitung von Abweichungen manuell erfolgt. Die Analyse dieses Attributs ist wichtig, um den Automatisierungsgrad des Prozesses zu verstehen. Sie zeigt, wie erfolgreich Automatisierungsinitiativen sind, macht verbleibende manuelle Engpässe sichtbar und weist auf weitere Automatisierungsmöglichkeiten hin, mit denen sich die Effizienz steigern und Fehler verringern lassen.
Warum das wichtig ist
Hilft, den Automatisierungsgrad des Prozesses zu messen, manuelle Engpässe zu erkennen und Möglichkeiten zur Effizienzsteigerung aufzuzeigen.
Woher beziehen
Wird üblicherweise aus dem Attribut „Benutzer“ abgeleitet. Handelt es sich beim Benutzer um ein bekanntes System- oder Dienstkonto, wird dieses Kennzeichen auf true gesetzt.
Beispiele
truefalse
|
|||
|
Gesamtdurchlaufzeit
TotalCycleTime
|
Gesamtdauer der Verarbeitung einer einzelnen Rechnung vom Eingang bis zur Zahlung. | ||
|
Beschreibung
Die Gesamtdurchlaufzeit misst die gesamte Zeit, die eine Rechnung im Prozess verbringt. Sie wird für jede Rechnungsnummer als Zeitdifferenz zwischen der ersten Aktivität (zum Beispiel „Rechnung erfasst“) und der letzten Aktivität (zum Beispiel „Zahlung ausgeführt“) berechnet. Diese zentrale KPI misst die Gesamteffizienz des Prozesses. Sie bietet einen Überblick über die Leistung und wird im Dashboard „Durchlaufzeit der Rechnungsverarbeitung“ verwendet. Die Analyse von Trends und die Aufschlüsselung dieser Kennzahl nach Attributen wie Lieferant oder Betrag helfen, übergreifende Verbesserungsmöglichkeiten zu erkennen.
Warum das wichtig ist
Ist die zentrale übergeordnete KPI für Geschwindigkeit und Effizienz des Gesamtprozesses und fasst die Leistung für jede Rechnung zusammen.
Woher beziehen
Wird auf Case-Ebene im Process-Mining-Tool oder bei der Datenaufbereitung berechnet. Sie entspricht der Zeitdifferenz zwischen dem Timestamp des ersten und des letzten Ereignisses für jede CaseId.
Beispiele
P15DP22DT5H30MP7D
|
|||
|
Grund für Zahlungssperre
PaymentBlockReason
|
Ursachencode, der erklärt, warum eine Rechnung für die Zahlung gesperrt wurde. | ||
|
Beschreibung
Eine Zahlungssperre verhindert, dass eine Rechnung bezahlt wird. Dieses Attribut erfasst den Grund für die Sperre. Meist handelt es sich um einen standardisierten Code, den ein Benutzer auswählt, zum Beispiel „Strittige Gebühren“ oder „Warten auf Wareneingang“. Dieses Attribut ist wichtig für das Dashboard „Häufigkeit und Dauer von Zahlungssperren“. Die Analyse der häufigsten Gründe für Zahlungssperren hilft, grundlegende Probleme im P2P-Prozess zu erkennen. Werden diese Ursachen behoben, lassen sich Zahlungsverzögerungen deutlich verringern und Lieferantenbeziehungen verbessern.
Warum das wichtig ist
Erklärt, warum Zahlungen bewusst zurückgehalten werden, und hilft, vorgelagerte Probleme zu erkennen und zu beheben, die Zahlungssperren verursachen.
Woher beziehen
Dieses Feld befindet sich üblicherweise in der Lieferantentransaktion oder im Rechnungssatz und steht oft mit dem Status der Zahlungssperre in Verbindung. Prüfen Sie Tabellen wie VendTrans.
Beispiele
QualitätsbeanstandungWarten auf GutschriftManuelle Sperre
|
|||
|
Pünktliche Zahlung
IsOnTimePayment
|
Berechnetes Kennzeichen dafür, ob eine Rechnung am oder vor dem Zahlungsziel bezahlt wurde. | ||
|
Beschreibung
Dieses boolesche Attribut wird berechnet, indem der Timestamp der Aktivität „Zahlung ausgeführt“ mit dem Zahlungsziel verglichen wird. Liegt das Zahlungsdatum am oder vor dem Zahlungsziel, ist der Wert true, andernfalls false. Das Attribut unterstützt direkt die KPI „Pünktliche Zahlungsquote“ und das Dashboard „Einhaltung der Zahlungsbedingungen“. Es vereinfacht die Analyse, indem es für jede Rechnung ein eindeutiges Ja-Nein-Ergebnis liefert. So lassen sich verspätete Zahlungen einfach filtern und ihre Ursachen nach Lieferant, Abteilung oder Land untersuchen.
Warum das wichtig ist
Misst direkt die Einhaltung der Zahlungsbedingungen und vereinfacht die Berechnung der KPI „Pünktliche Zahlungsquote“ sowie zugehörige Analysen.
Woher beziehen
Dieses Attribut wird in der Datentransformationsschicht berechnet. Die Logik lautet: (Timestamp der Aktivität „Zahlung ausgeführt“) <= (Zahlungsziel).
Beispiele
truefalse
|
|||
|
Rechnungswährung
InvoiceCurrency
|
Währungscode des Rechnungsbetrags, zum Beispiel USD oder EUR. | ||
|
Beschreibung
Die Rechnungswährung gibt an, in welcher Währung der Rechnungsbetrag ausgewiesen ist. Das ist für international tätige Organisationen wichtig, die mit Lieferanten aus verschiedenen Ländern zusammenarbeiten. Dieses Attribut liefert den nötigen Kontext zum Rechnungsbetrag und dient als Filter- und Berichtsmerkmal, insbesondere im internationalen Geschäft. Es stellt sicher, dass Finanzwerte korrekt interpretiert werden, und ermöglicht Analysen nach Währung oder die Umrechnung in eine einheitliche Berichtswährung.
Warum das wichtig ist
Liefert den nötigen Kontext zu Finanzbeträgen und ermöglicht die korrekte Interpretation und Analyse von Rechnungswerten in verschiedenen Regionen.
Woher beziehen
Befindet sich in der Rechnungskopftabelle neben dem Rechnungsbetrag, zum Beispiel im Feld CurrencyCode von VendInvoiceInfoTable.
Beispiele
USDEURGBP
|
|||
|
Unternehmenscode
CompanyCode
|
Kennung der juristischen Person oder des Unternehmens innerhalb der Organisation, das die Rechnung verarbeitet. | ||
|
Beschreibung
Der Unternehmenscode bezeichnet die juristische Person, die finanziell für die Rechnung verantwortlich ist. In Organisationen mit mehreren Unternehmen ist dies eine wichtige Kennzahl für die finanzielle Segmentierung. Mit diesem Attribut lässt sich die Prozessanalyse nach juristischen Personen filtern oder vergleichen. So kann sichtbar werden, ob Prozessleistung, Richtlinien oder Engpässe bestimmte Unternehmen innerhalb der Gruppe betreffen. Das unterstützt gezielte Verbesserungsmaßnahmen vor Ort.
Warum das wichtig ist
Ermöglicht die Segmentierung der Prozessanalyse nach juristischer Person. Das ist für große Organisationen mit mehreren Unternehmen besonders wichtig.
Woher beziehen
Dies ist ein Standardfeld in den meisten Finanztabellen von Dynamics 365 und heißt häufig DataAreaId.
Beispiele
USMFDEMFGBSI
|
|||
|
Zahlungsbedingungen
PaymentTerms
|
Mit dem Lieferanten vereinbarte Zahlungsbedingungen, zum Beispiel „Netto 30“ oder „2 % 10, netto 30“. | ||
|
Beschreibung
Die Zahlungsbedingungen legen die vereinbarten Konditionen für die Zahlung an den Lieferanten fest, einschließlich Zahlungsfrist und möglicher Rabatte. Die Informationen stammen üblicherweise aus den Lieferantenstammdaten oder der Bestellung. Dieses Attribut liefert wichtigen Kontext zum Zahlungsziel und zur KPI „Pünktliche Zahlungsquote“. Eine Analyse des Zusammenhangs zwischen bestimmten Zahlungsbedingungen und verspäteten Zahlungen kann operative Probleme aufdecken. Außerdem unterstützt sie die Finanzplanung und ein wirksames Working-Capital-Management.
Warum das wichtig ist
Liefert Kontext zu Zahlungszielen und hilft, die finanziellen Auswirkungen des Zahlungszeitpunkts sowie die Nutzung von Skonti zu analysieren.
Woher beziehen
Diese Informationen sind in den Lieferantenstammdaten (VendTable) gespeichert und werden in Transaktionstabellen wie VendInvoiceInfoTable übernommen.
Beispiele
Netto 30Netto 602 % 10, netto 30
|
|||
Aktivitäten der Rechnungsverarbeitung im Purchase-to-Pay-Prozess
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Rechnung freigegeben
|
Diese Aktivität bezeichnet die endgültige, erfolgreiche Freigabe der Rechnung im Workflow. Damit ist sie zur Buchung und Zahlung berechtigt. Die Workflow-Engine protokolliert dieses Ereignis ausdrücklich nach Abschluss des Workflows. | ||
|
Warum das wichtig ist
Dieser wichtige Meilenstein schließt den Freigabeprozess ab. Die Zeit zwischen „Rechnung zur Freigabe eingereicht“ und diesem Ereignis ist eine wichtige Kennzahl für die Effizienz der Freigabe und hilft, Engpässe zu erkennen.
Woher beziehen
Dieses explizite Ereignis wird in den Workflow-Verlaufstabellen (z. B. WorkflowTrackingStatusTable) protokolliert, wenn sich der Workflow-Status auf „Genehmigt“ ändert.
Erfassung
Timestamp des Statuseintrags „Genehmigt“ im Workflow-Verlauf.
Ereignistyp
explicit
|
|||
|
Rechnung gebucht
|
Bei diesem formellen Buchungsvorgang wird die freigegebene Rechnung im Hauptbuch erfasst und eine Verbindlichkeit angelegt. Das System protokolliert dieses Transaktionsereignis ausdrücklich. | ||
|
Warum das wichtig ist
Die Buchung ist der letzte Schritt vor der Zahlung und ein wichtiger Kontrollpunkt im Finanzwesen. Die Zeit zwischen „Rechnung freigegeben“ und „Rechnung gebucht“ zeigt, wie effizient die abschließenden Buchungsschritte ablaufen.
Woher beziehen
Dieses explizite Ereignis wird erfasst, wenn der gebuchte Lieferantenvorgang in Tabellen wie VendTrans sowie den zugehörigen Tabellen GeneralJournalEntry und LedgerEntry angelegt wird.
Erfassung
Erstellungs-Timestamp des Datensatzes in der Tabelle für Lieferantenvorgänge (VendTrans).
Ereignistyp
explicit
|
|||
|
Rechnung mit Bestellung abgeglichen
|
Diese Aktivität bezeichnet den erfolgreichen Abschluss des Abgleichs, bei dem die Rechnungsdaten mit der Bestellung und dem Wareneingang übereinstimmen. Das Ereignis wird abgeleitet, wenn der Abgleichsstatus der Rechnung auf „Bestanden“ gesetzt wird. | ||
|
Warum das wichtig ist
Ein erfolgreicher Abgleich ist ein wichtiger Meilenstein bei Rechnungen mit Bestellbezug. Er bestätigt die Richtigkeit der Forderung vor der Zahlung und ist entscheidend, um die Effizienz und den Automatisierungsgrad des Abgleichs zu verfolgen.
Woher beziehen
Abgeleitet aus der Änderung des Abgleichsstatusfelds im Kopf oder in den Positionen der Lieferantenrechnung (z. B. VendInvoiceInfoTable) auf „Bestanden“ oder „Erfolgreich abgeglichen“.
Erfassung
Timestamp der Statusänderung auf „Bestanden“ in den Validierungsdetails des Rechnungsabgleichs.
Ereignistyp
inferred
|
|||
|
Rechnung registriert
|
Zu Beginn wird eine Rechnung im System erfasst. Dabei entsteht ein Platzhalterdatensatz, bevor die vollständigen Angaben verarbeitet werden. Die Aktivität wird erfasst, wenn ein neuer Datensatz im Journal für das Lieferantenrechnungsregister angelegt wird. | ||
|
Warum das wichtig ist
Diese Aktivität markiert den offiziellen Beginn der Rechnungsverarbeitung. Die Zeit ab diesem Punkt zeigt die gesamte Verarbeitungsdauer und macht Verzögerungen in frühen Prozessphasen sichtbar.
Woher beziehen
Dieses explizite Ereignis wird erfasst, wenn ein Datensatz im Lieferantenrechnungsregister angelegt wird, üblicherweise in der VendInvoiceRegisterJournalTable oder einer ähnlichen Tabelle für ausstehende Rechnungen.
Erfassung
Erstellungs-Timestamp des Datensatzes im Journal für das Lieferantenrechnungsregister.
Ereignistyp
explicit
|
|||
|
Rechnung zur Freigabe eingereicht
|
Diese Aktivität markiert die formelle Einreichung einer Rechnung in einen Workflow zur Prüfung und Freigabe. Die Workflow-Engine von Dynamics 365 protokolliert dieses Einreichungsereignis ausdrücklich. | ||
|
Warum das wichtig ist
Dieser Zeitpunkt bildet den Ausgangspunkt für die Messung des gesamten Freigabezyklus. Er zeigt, wie lange Rechnungen warten, bevor die Freigabe überhaupt beginnt, und dient als Auslöser für Kennzahlen zur Freigabe.
Woher beziehen
Dieses explizite Ereignis wird in den Workflow-Verlaufstabellen (z. B. WorkflowTrackingStatusTable) protokolliert, wenn eine Rechnung in einen Workflow eingereicht wird.
Erfassung
Erstellungs-Timestamp des Einreichungsdatensatzes im Workflow-Verlauf.
Ereignistyp
explicit
|
|||
|
Zahlung ausgeführt
|
Dies ist die letzte Aktivität. Sie bezeichnet die Buchung des Zahlungsjournals, durch die die Zahlung erstellt und die Rechnung ausgeglichen wird. Dieses explizite Transaktionsereignis schließt den Rechnungsprozess ab. | ||
|
Warum das wichtig ist
Diese Aktivität markiert den erfolgreichen Abschluss des Rechnungszahlungsprozesses. Sie bildet die Grundlage für die Messung der „Pünktlichkeitsquote bei Zahlungen“ und der gesamten Durchlaufzeit.
Woher beziehen
Dieses explizite Ereignis wird bei der Buchung des Zahlungsjournals erfasst. Der Ausgleich wird in Tabellen wie VendSettlement protokolliert, die die Zahlung mit der Rechnung verknüpfen.
Erfassung
Buchungs-Timestamp des Zahlungsjournals, das den Lieferantenvorgang ausgleicht.
Ereignistyp
explicit
|
|||
|
Abweichung beim Abgleich behoben
|
Diese Aktivität markiert die Behebung einer zuvor festgestellten Abweichung beim Abgleich, sodass die Rechnung weiterverarbeitet werden kann. Sie wird abgeleitet, wenn eine Rechnung mit dem Abgleichsstatus „Fehlgeschlagen“ erfolgreich erneut abgeglichen oder manuell übersteuert wird. | ||
|
Warum das wichtig ist
Diese Aktivität schließt den Teilprozess zur Klärung der Abweichung ab. Die Zeit zwischen „Abweichung beim Abgleich festgestellt“ und diesem Ereignis ist eine wichtige Kennzahl für die Effizienz der Klärung.
Woher beziehen
Abgeleitet aus einem erfolgreichen Abgleichsereignis („Rechnung mit Bestellung abgeglichen“), das nach einem Ereignis „Abweichung beim Abgleich festgestellt“ für dieselbe Rechnung auftritt.
Erfassung
Ermitteln Sie einen Timestamp mit dem Abgleichsstatus „Bestanden“, der auf einen Timestamp mit dem Status „Fehlgeschlagen“ folgt.
Ereignistyp
inferred
|
|||
|
Abweichung beim Abgleich festgestellt
|
Diese Aktivität tritt ein, wenn der Rechnungsabgleich aufgrund von Abweichungen zwischen Rechnung, Bestellung oder Wareneingang fehlschlägt. Sie wird erfasst, wenn der Abgleichsstatus der Rechnung auf „Fehlgeschlagen“ oder „Abweichung“ gesetzt wird. | ||
|
Warum das wichtig ist
Für die Kennzahl „Abweichungsquote beim Abgleich“ ist es entscheidend, festzustellen, wann und warum Abweichungen auftreten. Diese Aktivität markiert den Beginn der Klärung, die häufig erhebliche Verzögerungen verursacht.
Woher beziehen
Abgeleitet aus der Änderung des Abgleichsstatusfelds der Lieferantenrechnung (z. B. VendInvoiceInfoTable) auf „Fehlgeschlagen“. Der Grund für das Scheitern wird häufig ebenfalls protokolliert.
Erfassung
Timestamp der Statusänderung auf „Fehlgeschlagen“ oder „Abweichung“ während des Abgleichs.
Ereignistyp
inferred
|
|||
|
Rechnung abgelehnt
|
Diese Aktivität zeigt an, dass eine freigabeberechtigte Person die Rechnung abgelehnt hat. Der Prozess wird angehalten und die Rechnung in der Regel zur Korrektur zurückgesendet. Die Workflow-Engine protokolliert die Ablehnung ausdrücklich. | ||
|
Warum das wichtig ist
Die Erfassung von Ablehnungen hilft, Nacharbeit zu quantifizieren und häufige Fehlerursachen wie falsche Kontierungen oder Richtlinienverstöße zu erkennen. Sie unterstützt direkt die Kennzahl „Ablehnungsquote von Rechnungen“.
Woher beziehen
Dieses explizite Ereignis wird in den Workflow-Verlaufstabellen (z. B. WorkflowTrackingStatusTable) protokolliert, wenn sich der Workflow-Status auf „Abgelehnt“ oder „Abgebrochen“ ändert.
Erfassung
Timestamp des Statuseintrags „Abgelehnt“ im Workflow-Verlauf.
Ereignistyp
explicit
|
|||
|
Rechnung kontiert
|
Diese Aktivität zeigt an, dass den Rechnungspositionen Sachkonten zugeordnet wurden. Sie wird üblicherweise anhand der Erstellung oder Fertigstellung der mit der Rechnung verknüpften Sachkontenzuordnungen abgeleitet. | ||
|
Warum das wichtig ist
Die Kontierung ist ein wichtiger Schritt für die finanzielle Genauigkeit. Wenn Sie die Dauer der Rechnungskontierung messen, erkennen Sie Engpässe bei der Buchhaltungsprüfung und erhalten eine Grundlage für die Kennzahl „Durchschnittliche Zeit von der Datenerfassung bis zur Kontierung“.
Woher beziehen
Abgeleitet aus der Erstellung und Validierung von Datensätzen in Tabellen zur Kontierungsverteilung (z. B. AccountingDistribution), die mit der ausstehenden Lieferantenrechnung verknüpft sind.
Erfassung
Timestamp, zu dem die Kontierungsverteilungen für die Rechnung gespeichert und validiert werden.
Ereignistyp
inferred
|
|||
|
Rechnungsdaten erfasst
|
Diese Aktivität bezeichnet den Abschluss der Dateneingabe für die Rechnung, einschließlich Kopf- und Positionsdaten, bevor sie zum Abgleich oder zur Freigabe eingereicht wird. Häufig lässt sie sich daran erkennen, dass der Rechnungsdatensatz vom Status „Neu“ oder „Registriert“ in den Status „Zur Verarbeitung bereit“ wechselt. | ||
|
Warum das wichtig ist
Mit dieser Aktivität lässt sich die Effizienz der manuellen oder automatisierten Dateneingabe (OCR) messen. Verzögerungen an dieser Stelle können sich auf den gesamten Prozess auswirken.
Woher beziehen
Abgeleitet aus Statusänderungen des Datensatzes für die ausstehende Lieferantenrechnung (z. B. VendInvoiceInfoTable). Das Ereignis tritt ein, wenn alle erforderlichen Felder ausgefüllt sind und die Rechnung für den nächsten Schritt bereitsteht.
Erfassung
Erkennen Sie eine Statusänderung in der Tabelle für ausstehende Rechnungen, die den Abschluss der Dateneingabe anzeigt.
Ereignistyp
inferred
|
|||
|
Zahlung geplant
|
Diese Aktivität tritt ein, wenn eine gebuchte Rechnung in einen Zahlungsvorschlag oder ein Zahlungsjournal aufgenommen wird, bevor die Zahlung ausgeführt wird. Dabei wird ausdrücklich eine Zahlungsjournalzeile angelegt. | ||
|
Warum das wichtig ist
Damit wechselt der Prozess von der Kreditorenbuchhaltung in den Bereich Treasury. Die Analyse dieses Schritts kann Verzögerungen zwischen der Rechnungsbuchung und dem Zahlungsbeginn aufdecken.
Woher beziehen
Dieses explizite Ereignis wird erfasst, wenn eine Zeile in einem Zahlungsjournal (LedgerJournalTrans) angelegt wird, die den gebuchten Lieferantenvorgang ausgleicht.
Erfassung
Erstellungs-Timestamp der Zahlungsjournalzeile, die auf die Rechnung verweist.
Ereignistyp
explicit
|
|||
|
Zahlungssperre aufgehoben
|
Diese Aktivität bezeichnet die Aufhebung einer Zahlungssperre, sodass die Rechnung für die Zahlungsplanung weiterverarbeitet werden kann. Sie wird erfasst, wenn das Feld für die Zahlungssperre geleert oder auf einen nicht gesperrten Status gesetzt wird. | ||
|
Warum das wichtig ist
Misst, wie lange es dauert, Probleme zu beheben, die zu Zahlungssperren führen. Lange Zeiträume zwischen dem Setzen und Aufheben einer Sperre weisen auf ineffiziente Problemlösungsprozesse hin.
Woher beziehen
Abgeleitet aus einer Änderung, durch die das Feld für die Zahlungssperre oder den Zahlungsstopp im gebuchten Lieferantenvorgang (VendTrans) geleert wird. Das Änderungsprotokoll kann den Timestamp liefern.
Erfassung
Timestamp der Aktualisierung, durch die das Feld für die Zahlungssperre im Lieferantenvorgang geleert wird.
Ereignistyp
inferred
|
|||
|
Zahlungssperre gesetzt
|
Diese Aktivität tritt ein, wenn eine Rechnung gesperrt und dadurch von der Zahlung ausgeschlossen wird. Sie wird anhand einer Änderung des Felds für die Zahlungssperre oder den Sperrstatus im gebuchten Rechnungsdatensatz erfasst. | ||
|
Warum das wichtig ist
Zahlungssperren sind eine häufige Ursache für verspätete Zahlungen. Um die Pünktlichkeit der Zahlungen und die Beziehungen zu Lieferanten zu verbessern, ist es entscheidend zu analysieren, wann und warum Sperren gesetzt werden.
Woher beziehen
Abgeleitet aus einer Änderung des Felds für die Zahlungssperre oder den Zahlungsstopp im gebuchten Lieferantenvorgang (VendTrans). Das Änderungsprotokoll kann zur Erfassung des Timestamps verwendet werden.
Erfassung
Timestamp der Aktualisierung, durch die das Feld für die Zahlungssperre im Lieferantenvorgang gesetzt wird.
Ereignistyp
inferred
|
|||
Anleitungen zur Datenextraktion
Möchten Sie loslegen?
Mit diesem Template können Sie Ihre Process-Mining-Analyse starten und Erkenntnisse gewinnen, um Rechnungen schneller und genauer zu bearbeiten. Beginnen Sie noch heute damit, Ihre Abläufe zu verbessern.
Optimieren Sie noch heute Ihre Rechnungsverarbeitung im Purchase-to-Pay-Prozess
Decken Sie Ineffizienzen auf und verkürzen Sie die Durchlaufzeit von Rechnungen um mindestens 30 %.
Keine Kreditkarte erforderlich. In wenigen Minuten startklar.