Ihr Daten-Template für die Kreditorenrechnungsverarbeitung
Ihr Daten-Template für die Kreditorenrechnungsverarbeitung
- Empfohlene Attribute für die Datenerfassung
- Wichtige Aktivitäten für die Nachverfolgung
- Hinweise zur Datenextraktion
Attribute der Kreditorenrechnungsverarbeitung
| Name | Beschreibung | ||
|---|---|---|---|
|
Rechnung
Invoice
|
Die eindeutige Kennung für jedes Lieferantenrechnungsdokument. | ||
|
Beschreibung
Die Rechnung dient als primäre Case-Kennung und verknüpft alle Aktivitäten vom Rechnungseingang bis zur endgültigen Zahlung. So lässt sich der gesamte Weg jeder einzelnen Rechnung durch den Kreditorenprozess analysieren. Bei der Analyse werden Ereignisse zunächst anhand dieser Kennung gruppiert, um den Prozessablauf für jede Rechnung zu rekonstruieren. Damit lassen sich KPIs auf Case-Ebene berechnen, etwa die gesamte Durchlaufzeit, und Varianten sowie Engpässe erkennen, die einzelne Rechnungsverläufe betreffen.
Warum das wichtig ist
Diese Kennung ist unerlässlich, um den gesamten Lebenszyklus einer Rechnung nachzuverfolgen. Sie bildet die Grundlage für alle Process-Mining-Analysen in der Kreditorenbuchhaltung.
Woher beziehen
In der Regel handelt es sich um die Lieferantenrechnungsnummer auf der Seite „Lieferantenrechnung“ oder in zugehörigen Datenentitäten in Dynamics 365 Finance.
Beispiele
INV-00125475000921DE-8832-2023
|
|||
|
Aktivität
ActivityName
|
Der Name des ausgeführten Prozessschritts. | ||
|
Beschreibung
Dieses Attribut erfasst die konkrete Aktion oder das Ereignis, das zu einem bestimmten Zeitpunkt für eine Rechnung stattgefunden hat, etwa „Rechnung erfasst“ oder „Rechnung freigegeben“. Diese Aktivitäten bilden die Knoten der ermittelten Prozesskarte. Die Abfolge und Häufigkeit der Aktivitäten zu analysieren, ist eine Grundlage für Process Mining. So lässt sich der Prozessablauf visualisieren, häufige und seltene Pfade (Varianten) lassen sich erkennen und Aktivitäten, die Verzögerungen oder Nacharbeit verursachen, können ermittelt werden.
Warum das wichtig ist
Aktivitäten beschreiben, was im Prozess geschieht. Sie ermöglichen den Aufbau einer Prozesskarte und die Analyse des Prozessablaufs und seiner Varianten.
Woher beziehen
Diese Angaben werden häufig aus Statusänderungen, Workflow-Verlaufsprotokollen oder Buchungsdatensätzen im Kreditorenmodul von Dynamics 365 abgeleitet.
Beispiele
Rechnung erfasstRechnung freigegebenAbweichung behobenZahlung ausgeführt
|
|||
|
Startzeit
EventTime
|
Der Timestamp, der angibt, wann eine Aktivität oder ein Ereignis stattgefunden hat. | ||
|
Beschreibung
Dieses Attribut enthält Datum und Uhrzeit jeder Aktivität. Es ist erforderlich, um Ereignisse chronologisch zu ordnen und Zeitspannen zu berechnen. Damit bildet es das zeitliche Rückgrat des Event Logs. Bei der Analyse dient die Startzeit zur Berechnung aller zeitbezogenen Kennzahlen, darunter Durchlaufzeiten zwischen Aktivitäten, Wartezeiten und die gesamte Dauer eines Cases. Sie ist entscheidend, um Engpässe zu erkennen und die Prozessleistung anhand von SLAs zu messen.
Warum das wichtig ist
Dieser Timestamp ist entscheidend, um Ereignisse korrekt zu ordnen und Leistungskennzahlen wie Durchlaufzeiten zu berechnen sowie Engpässe zu erkennen.
Woher beziehen
Abgerufen aus Erstellungs- oder Änderungsdatumsfeldern in Transaktionsdatensätzen, Workflow-Verlaufsprotokollen oder Buchungsdatumsfeldern in Dynamics 365.
Beispiele
2023-04-15T09:00:12Z2023-04-18T14:35:00Z2023-05-02T11:21:45Z
|
|||
|
Benutzer
UserName
|
Der Benutzer, der die Aktivität ausgeführt hat. | ||
|
Beschreibung
Gibt an, welcher Benutzer für einen bestimmten Prozessschritt verantwortlich war, etwa für die Erfassung oder Freigabe einer Rechnung. Häufig ist das Attribut mit der System-ID des Benutzers in Dynamics 365 verknüpft. Die Auswertung nach Benutzern zeigt, wo Schulungsbedarf besteht, wer besonders leistungsstark ist und wie sich die Arbeitslast verteilt. Für Dashboards zu Freigabezeiten und Ressourceneffizienz ist diese Analyse besonders wichtig. Führungskräfte erkennen damit, bei welchen Benutzern oder Teams Engpässe entstehen.
Warum das wichtig ist
Ordnet die Arbeit einzelnen Personen zu und ermöglicht so die Analyse von Arbeitslast und Leistung sowie die Ermittlung von Schulungsbedarf.
Woher beziehen
In der Regel in den Feldern „Erstellt von“ oder „Geändert von“ bei Transaktionen oder in den Workflow-Verlaufsprotokollen von Dynamics 365 zu finden.
Beispiele
j.doea.smithr.williams
|
|||
|
Bestellnummer
PurchaseOrderNumber
|
Die eindeutige Kennung der Bestellung, die der Rechnung zugeordnet ist. | ||
|
Beschreibung
Dieses Attribut verknüpft die Rechnung mit der zugehörigen Bestellung (PO). Rechnungen können sich auf eine Bestellung beziehen oder ohne Bestellbezug eingehen. Die Analyse dieses Attributs unterscheidet zwischen der Rechnungsverarbeitung mit und ohne Bestellbezug. Diese Abläufe folgen häufig unterschiedlichen Workflows. Das Attribut ist wichtig, um die Effizienz des Bestellabgleichs zu messen und Probleme zu erkennen, wenn Rechnungsangaben nicht mit der Bestellung übereinstimmen.
Warum das wichtig ist
Unterscheidet Rechnungen mit und ohne Bestellbezug, die unterschiedlichen Prozessen folgen, und ist wichtig für die Analyse der Abgleichseffizienz.
Woher beziehen
Im Kopf oder in den Positionen der Lieferantenrechnung zu finden, üblicherweise im Feld „PurchId“ in „VendInvoiceInfoTable“.
Beispiele
PO-000432PO-000511
|
|||
|
Fälligkeitsdatum der Rechnung
InvoiceDueDate
|
Das Datum, bis zu dem die Rechnung gemäß den Zahlungsbedingungen bezahlt werden muss. | ||
|
Beschreibung
Dieses Datum gibt die Zahlungsfrist an. Wird sie eingehalten, lassen sich Vertragsstrafen vermeiden und die Vereinbarungen mit dem Lieferanten erfüllen. Das Fälligkeitsdatum wird üblicherweise anhand des Rechnungsdatums und der festgelegten Zahlungsbedingungen berechnet. Dieses Attribut ist für die Analyse der Einhaltung von Zahlungsbedingungen unverzichtbar. Durch den Vergleich des Datums „Zahlung ausgeführt“ mit dem Fälligkeitsdatum der Rechnung lassen sich verspätete Zahlungen automatisch kennzeichnen, Einhaltungsquoten berechnen und Zahlungen priorisieren, um gute Lieferantenbeziehungen zu pflegen.
Warum das wichtig ist
Entscheidend für die Messung pünktlicher Zahlungen, die Pflege von Lieferantenbeziehungen und die Vermeidung von Verzugsgebühren.
Woher beziehen
Berechnetes Feld auf Grundlage des Rechnungsdatums und der Zahlungsbedingungen. Wird in Feldern wie „DueDate“ in Lieferantentransaktionstabellen, etwa „VendTrans“, gespeichert.
Beispiele
2023-05-152023-06-302023-07-01
|
|||
|
Lieferant
VendorName
|
Name des Lieferanten, der die Rechnung eingereicht hat. | ||
|
Beschreibung
Dieses Attribut bezeichnet den Lieferanten, der mit der Rechnung verknüpft ist. Zu den Lieferantendaten gehören häufig Angaben wie Name, ID und Kategorie. Die Analyse des Kreditorenprozesses nach Lieferant zeigt, welche Lieferanten regelmäßig problematische Rechnungen einreichen, etwa mit häufigen Abweichungen, für welche besondere Zahlungsbedingungen gelten und bei welchen die Bearbeitung lange dauert. Diese Erkenntnisse können die Zusammenarbeit mit Lieferanten verbessern.
Warum das wichtig ist
Ermöglicht die Aufschlüsselung des Prozesses nach Lieferanten, um lieferantenspezifische Probleme wie häufige Abweichungen oder Zahlungsverzögerungen zu erkennen.
Woher beziehen
Über den Rechnungskopf mit dem Lieferanten verknüpft, in der Regel anhand der Lieferantenkontonummer mit der Datenentität „VendTable“.
Beispiele
Contoso LtdFabrikam IncNorthwind Traders
|
|||
|
Rechnungsbetrag
InvoiceAmount
|
Der Gesamtbetrag der Rechnung. | ||
|
Beschreibung
Gibt den insgesamt fälligen Betrag der Lieferantenrechnung an. Diese Kennzahl ist für jeden Case von zentraler Bedeutung. Das Attribut ermöglicht die finanzielle Analyse des Kreditorenprozesses. Damit lassen sich Rechnungen mit hohen Beträgen priorisieren, Freigabezeiten anhand von Betragsgrenzen untersuchen und die finanziellen Auswirkungen verspäteter Zahlungen oder Skonti bei frühzeitiger Zahlung ermitteln.
Warum das wichtig ist
Liefert den finanziellen Kontext für die Analyse des Prozessverhaltens nach Rechnungsbetrag, etwa um festzustellen, ob Rechnungen mit hohen Beträgen anders bearbeitet werden.
Woher beziehen
Im Rechnungskopf des Lieferanten zu finden, häufig in Feldern wie „InvoiceAmount“ in „VendInvoiceInfoTable“.
Beispiele
1500.75250.0012345.50
|
|||
|
Zahlungsbedingungen
PaymentTerms
|
Die mit dem Lieferanten vereinbarten Bedingungen für die Rechnungszahlung. | ||
|
Beschreibung
Dieses Attribut legt fest, unter welchen Bedingungen eine Lieferantenrechnung zu bezahlen ist, etwa „Net 30“ (fällig in 30 Tagen) oder „2/10 Net 30“ (2 % Skonto bei Zahlung innerhalb von 10 Tagen, andernfalls fällig in 30 Tagen). Die Analyse nach Zahlungsbedingungen zeigt, wie sich unterschiedliche Vereinbarungen auf die Pünktlichkeit von Zahlungen und den Cashflow auswirken. Sie bildet die Grundlage, um Skontomöglichkeiten zu ermitteln und die Konformitätsprüfung danach aufzuschlüsseln, ob bestimmte Zahlungsbedingungen schwerer einzuhalten sind.
Warum das wichtig ist
Legt Zahlungsfristen und Skontomöglichkeiten fest und wirkt sich damit direkt auf das Cashflow-Management und mögliche Kosteneinsparungen aus.
Woher beziehen
In den Lieferantenstammdaten zu finden oder im Kopf der Bestellung beziehungsweise Rechnung angegeben. Wird in Feldern wie „PaymTermId“ gespeichert.
Beispiele
Net 30Net 602/10 Net 30
|
|||
|
Automatisiert
IsAutomated
|
Kennzeichnet, ob das System die Aktivität automatisch ausgeführt hat. | ||
|
Beschreibung
Dieses boolesche Attribut unterscheidet zwischen Aktivitäten, die Benutzer ausgeführt haben, und solchen, die automatisiert vom System ausgeführt wurden, etwa die automatische Buchung oder der Abgleich von Rechnungen. Die Analyse dieses Attributs ist wichtig, um den Automatisierungsgrad des Kreditorenprozesses zu messen. Sie hilft, die Quote der durchgängigen Verarbeitung (STP) zu berechnen und manuelle Aktivitäten zu ermitteln, die sich für künftige Automatisierungsvorhaben eignen. Das kann Kosten und Bearbeitungszeit senken.
Warum das wichtig ist
Hilft, die Quote der durchgängigen Verarbeitung zu messen und Möglichkeiten für mehr Automatisierung und Effizienz zu erkennen.
Woher beziehen
Wird daraus abgeleitet, ob der einer Aktivität zugeordnete Benutzer ein System- oder Batch-Benutzer ist, etwa „Admin“ oder „BatchUser“.
Beispiele
truefalse
|
|||
|
Buchungskreis
CompanyCode
|
Die Kennung der juristischen Person, die die Rechnung bearbeitet. | ||
|
Beschreibung
Dieses Attribut bezeichnet das Unternehmen oder die juristische Person innerhalb der Organisation, die für die Rechnung verantwortlich ist. Bei Organisationen mit mehreren Unternehmen ist es eine wichtige organisatorische Dimension. Die Analyse des Kreditorenprozesses nach Buchungskreis ermöglicht den Leistungsvergleich zwischen verschiedenen Geschäftseinheiten oder juristischen Personen. Sie zeigt, ob einzelne Einheiten weniger effizient arbeiten, häufiger Nacharbeit verursachen oder andere Prozessvarianten verwenden. So werden Möglichkeiten zur Standardisierung und zum Austausch bewährter Verfahren sichtbar.
Warum das wichtig ist
Ermöglicht den Leistungsvergleich und die Analyse von Prozessen über verschiedene juristische Personen und Geschäftseinheiten hinweg.
Woher beziehen
Ein Standardfeld in fast allen Transaktionstabellen von Dynamics 365, üblicherweise mit dem Namen „DataAreaId“.
Beispiele
USMFDEMFGBSI
|
|||
|
Freigebender Benutzer
ApproverName
|
Der Benutzer, der die Rechnung in einem bestimmten Schritt freigegeben oder abgelehnt hat. | ||
|
Beschreibung
Dieses Attribut bezeichnet die Person, die im Workflow für eine Freigabeentscheidung verantwortlich ist. Bei Rechnungen mit mehreren Freigabestufen können für die einzelnen Schritte unterschiedliche Personen zuständig sein. Das Attribut ist für das Dashboard zur Analyse der Rechnungsfreigabe-Zykluszeit unverzichtbar. Die Auswertung nach freigebendem Benutzer zeigt, bei welchen Personen Engpässe entstehen, etwa aufgrund hoher Arbeitslast oder anderer Faktoren. So können gezielte Maßnahmen die Freigabe beschleunigen.
Warum das wichtig ist
Ermöglicht eine detaillierte Analyse des Freigabeprozesses und hilft, Engpässe bei einzelnen Personen oder Teams zu erkennen.
Woher beziehen
Aus den Workflow-Verlaufsprotokollen („WorkflowTrackingStatusTable“) übernommen, in denen der Benutzer erfasst wird, der den jeweiligen Freigabeschritt abgeschlossen hat.
Beispiele
David ChenMaria GarciaAP_Manager_Group
|
|||
|
Grund für Abweichung
DiscrepancyReason
|
Der Ursachencode oder die Beschreibung einer Rechnungsabweichung. | ||
|
Beschreibung
Wird eine Rechnung zurückgestellt oder eine Abweichung festgestellt, erfasst dieses Attribut den Grund, etwa „Preisabweichung“, „Mengenabweichung“ oder „Wareneingang fehlt“. Dieses Attribut ist zentral für die Analyse von Abweichungsbehebung und Nacharbeit. Werden Nacharbeiten nach Ursache kategorisiert, lassen sich die Ursachen für ineffiziente Abläufe ermitteln. Ist beispielsweise „Preisabweichung“ der häufigste Grund, deutet das auf einen Bedarf an besser abgestimmten Daten zwischen Einkauf und Lieferanten hin.
Warum das wichtig ist
Zeigt die Ursache für Nacharbeit und ermöglicht gezielte Prozessverbesserungen, um Ausnahmen und manuelle Eingriffe zu reduzieren.
Woher beziehen
Kann in Tabellen zu Rechnungssperren, Workflow-Kommentaren oder speziellen Feldern zur Erfassung von Abweichungen im Kreditorenmodul gespeichert sein.
Beispiele
PreisabweichungMengenabweichungUngültige Bestellung
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Zeitpunkt der letzten Datenaktualisierung aus dem Quellsystem. | ||
|
Beschreibung
Dieses Attribut gibt an, wann das Event Log zuletzt mit aktuellen Daten aus Microsoft Dynamics 365 aktualisiert wurde. So lässt sich einschätzen, wie aktuell die analysierten Daten sind. Bei Dashboards und der laufenden Überwachung ist dieser Timestamp entscheidend: Benutzer sehen daran, ob sie mit den neuesten Prozessdaten arbeiten. Er hilft, die Aktualität der Daten richtig einzuschätzen und den Zustand der Datenpipeline zu überwachen.
Warum das wichtig ist
Informiert Benutzer über die Aktualität der Daten. Das ist entscheidend, um auf Grundlage der Analyse rechtzeitig fundierte Geschäftsentscheidungen zu treffen.
Woher beziehen
Dieses Metadatenfeld wird beim Einlesen der Daten vom Tool zur Datenextraktion und -ladung (ETL) erzeugt und mit einem Timestamp versehen.
Beispiele
2023-06-01T02:00:00Z2023-06-02T02:00:00Z
|
|||
|
Nacharbeit
IsRework
|
Ein berechnetes Kennzeichen, das angibt, ob bei einer Rechnung Nacharbeit erforderlich war. | ||
|
Beschreibung
Dieses boolesche Kennzeichen wird auf „true“ gesetzt, wenn der Prozessablauf einer Rechnung Aktivitäten zur Nacharbeit enthält, etwa „Abweichung behoben“ oder einen zweiten Schritt „Rechnungsdaten validiert“ nach einem ersten Fehlversuch. Die Berechnung erfolgt für den gesamten Case. Das Attribut unterstützt direkt die KPI zur Nacharbeitsquote bei Abweichungen. Es erleichtert das Filtern und Zusammenfassen aller Rechnungen, die zusätzlichen manuellen Aufwand erforderten. So lässt sich der Einfluss schlechter Datenqualität oder von Prozessausnahmen beziffern.
Warum das wichtig ist
Misst Nacharbeit direkt und ermöglicht eine einfache Quantifizierung und Analyse von Prozessausnahmen und Ineffizienzen.
Woher beziehen
Dieses Feld stammt nicht aus dem Quellsystem. Es wird im Process-Mining-Tool berechnet, indem geprüft wird, ob in einem Case bestimmte Aktivitäten auftreten, die auf Nacharbeit hinweisen.
Beispiele
truefalse
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem die Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut gibt die Herkunft der Ereignisdaten an. In diesem Zusammenhang ist das in der Regel „Microsoft Dynamics 365“. Es ist besonders wichtig, wenn Daten aus mehreren Systemen zusammengeführt werden, zum Beispiel aus einem OCR-Scanprogramm und D365. Bei einer Process-Mining-Analyse unterstützt dieses Attribut die Datenherkunftsnachverfolgung und die Fehlerbehebung. Außerdem hilft es, die Systemlandschaft des Prozesses zu verstehen und die Analyse auf Ereignisse aus einem bestimmten System zu beschränken.
Warum das wichtig ist
Gibt wichtigen Kontext zur Datenherkunft und ist für die Datenvalidierung sowie für Prozessanalysen über mehrere Systeme hinweg entscheidend.
Woher beziehen
Dies ist in der Regel ein statischer Wert („Microsoft Dynamics 365“), der während der Datenextraktion und -transformation hinzugefügt wird.
Beispiele
Microsoft Dynamics 365 FinanceD365 F&OAX2012
|
|||
|
Rechnungsstatus
InvoiceStatus
|
Der aktuelle Bearbeitungsstatus der Rechnung. | ||
|
Beschreibung
Dieses Attribut gibt den zuletzt bekannten Status einer Rechnung im Prozess an, etwa „In Bearbeitung“, „Genehmigt“, „Bezahlt“ oder „Storniert“. Es zeigt, an welcher Stelle des Lebenszyklus sich die Rechnung befindet. Process Mining leitet den Ablauf aus den Aktivitäten ab. Der Endstatus ist dennoch hilfreich, um die Ergebnisse zu validieren und Dashboards für den Geschäftsbereich zu erstellen, die den aktuellen Status aller offenen Rechnungen zusammenfassen. So lassen sich beispielsweise alle Rechnungen herausfiltern, die bereits „Genehmigt“, aber noch nicht „Bezahlt“ sind.
Warum das wichtig ist
Fasst den aktuellen Status der Rechnungen zusammen und eignet sich zum Filtern sowie für statusbasierte Dashboards.
Woher beziehen
Wird häufig aus Dokumentstatus- oder Workflow-Statusfeldern im Kreditorenmodul abgeleitet.
Beispiele
In BearbeitungGenehmigtBezahltStorniert
|
|||
|
Skontobetrag bei frühzeitiger Zahlung
EarlyPaymentDiscountAmount
|
Der mögliche Skontobetrag bei frühzeitiger Zahlung der Rechnung. | ||
|
Beschreibung
Dieses Attribut gibt den Geldwert des Skontos an, das der Lieferant bei frühzeitiger Zahlung gemäß den Zahlungsbedingungen gewährt. Diese Finanzdaten sind für das Dashboard zum Status von Skonti bei frühzeitiger Zahlung entscheidend. Das Unternehmen kann damit den Wert tatsächlich genutzter und verpasster Skonti beziffern. So wird der finanzielle Anreiz deutlich, die Rechnungsfreigabe und Zahlungsplanung effizienter zu gestalten.
Warum das wichtig ist
Beziffert das finanzielle Potenzial effizienter Prozesse und stellt den direkten Zusammenhang zwischen Prozessleistung und Kosteneinsparungen her.
Woher beziehen
Berechnetes Feld auf Grundlage des Rechnungsbetrags und der Zahlungsbedingungen. Der Wert ist in Tabellen wie „VendTrans“ oder in zugehörigen Feldern für Skonti verfügbar.
Beispiele
30.015.00246.91
|
|||
|
Skontofrist
EarlyPaymentDiscountDate
|
Die Frist, bis zu der die Rechnung bezahlt werden muss, damit ein Skonto für frühzeitige Zahlung gewährt wird. | ||
|
Beschreibung
Dieses Attribut gibt den letzten Tag an, an dem eine Rechnung bezahlt werden kann, um das vom Lieferanten angebotene Skonto zu erhalten. Es wird anhand des Rechnungsdatums und des Skontoanteils der Zahlungsbedingungen berechnet, zum Beispiel anhand der „10“ in „2/10 Net 30“. Dieses Datum ist ausschlaggebend für die Analyse des Status von Skonti bei frühzeitiger Zahlung. Durch den Vergleich des Datums „Zahlung geplant“ oder „Zahlung ausgeführt“ mit dieser Frist lässt sich feststellen, ob das Skonto tatsächlich genutzt wurde. So entstehen klare Kennzahlen zur finanziellen Optimierung.
Warum das wichtig ist
Legt den Stichtag für mögliche Kosteneinsparungen fest und ist damit entscheidend für die Priorisierung von Zahlungen und Effizienzverbesserungen.
Woher beziehen
Wird vom System anhand der Zahlungsbedingungen und des Rechnungsdatums berechnet. In Feldern wie „CashDiscDate“ in „VendTrans“ gespeichert.
Beispiele
2023-04-252023-05-102023-06-15
|
|||
|
Verspätete Zahlung
IsLatePayment
|
Ein berechnetes Kennzeichen, das angibt, ob die Zahlung nach dem Fälligkeitsdatum erfolgte. | ||
|
Beschreibung
Dieses boolesche Attribut wird auf „true“ gesetzt, wenn die Aktivität „Zahlung ausgeführt“ nach dem Fälligkeitsdatum der Rechnung erfolgt. Es zeigt für jeden Case eindeutig an, ob die Zahlungsbedingungen nicht eingehalten wurden. Das Attribut vereinfacht die Berechnung der KPI zur Einhaltung von Zahlungsbedingungen. Es ermöglicht das schnelle Filtern und Erstellen von Dashboards zum Umfang und Wert verspäteter Zahlungen. Außerdem können diese Fälle gezielt auf ihre Ursachen untersucht werden.
Warum das wichtig ist
Liefert ein eindeutiges, einfaches Kennzeichen für die Analyse nicht konformer Zahlungen und die Berechnung von KPIs zu pünktlichen Zahlungen.
Woher beziehen
Dieses Feld stammt nicht aus dem Quellsystem. Es wird im Process-Mining-Tool berechnet, indem der Timestamp der Aktivität „Zahlung ausgeführt“ mit dem Attribut „InvoiceDueDate“ verglichen wird.
Beispiele
truefalse
|
|||
|
Wareneingangsnummer
GoodsReceiptNumber
|
Die Kennung des zur Rechnung gehörenden Wareneingangsbelegs. | ||
|
Beschreibung
Dieses Attribut verknüpft die Rechnung mit dem Beleg über den Erhalt von Waren oder Dienstleistungen. Das ist für den Drei-Wege-Abgleich zwischen Bestellung, Wareneingang und Rechnung erforderlich. Das Attribut ist wichtig, um die Effizienz des Abgleichs zu analysieren. Verzögerungen oder Fehler bei Aktivitäten wie „Wareneingang abgeglichen“ lassen sich anhand dieser Kennung bis zum ursprünglichen Wareneingangsbeleg zurückverfolgen. So können Probleme bei der Beschaffung oder beim Wareneingang ermittelt werden, die sich auf die Kreditorenbuchhaltung auswirken.
Warum das wichtig ist
Erleichtert die Analyse der Effizienz des Drei-Wege-Abgleichs und hilft, Probleme im Wareneingangsprozess zu lokalisieren.
Woher beziehen
Über die Bestellpositionen verknüpft, häufig in Wareneingangsjournalen („VendPackingSlipJour“) oder zugehörigen Tabellen zu finden.
Beispiele
GRN-00981GRN-01024
|
|||
Aktivitäten der Kreditorenrechnungsverarbeitung
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Rechnung erfasst
|
Kennzeichnet die erstmalige Anlage eines Rechnungsdatensatzes im System, etwa durch manuelle Eingabe, OCR-Erfassung oder elektronischen Datenaustausch (EDI). Dies ist der Startpunkt der Rechnungsverarbeitung. | ||
|
Warum das wichtig ist
Diese Aktivität ist das primäre Start-Event des Prozesses. Die Zeitspanne von diesem Zeitpunkt bis zur Zahlung ergibt die gesamte Rechnungsdurchlaufzeit und ist eine wichtige Leistungskennzahl.
Woher beziehen
Abgeleitet aus dem Erstellungs-Timestamp (Feld CreatedDateTime) des Rechnungskopfs in den Tabellen für ausstehende Lieferantenrechnungen oder Rechnungsjournale, zum Beispiel VendInvoiceInfoTable.
Erfassung
Verwenden Sie den Erstellungs-Timestamp des Rechnungskopfs.
Ereignistyp
inferred
|
|||
|
Rechnung freigegeben
|
Bezeichnet die abschließende Freigabe im Workflow. Damit wird die Rechnung zur Buchung und Zahlung autorisiert. Dies ist ein wichtiger Meilenstein, bevor die Rechnung in die Zahlungsphase übergeht. | ||
|
Warum das wichtig ist
Damit endet der Freigabezyklus. Die Zeit zwischen „Zur Freigabe eingereicht“ und dieser Aktivität ist eine wichtige Kennzahl, um Engpässe bei Freigaben und lang laufende Workflows zu erkennen.
Woher beziehen
Ein ausdrücklich erfasstes Ereignis in den Workflow-Verlaufsprotokollen (WorkflowTrackingStatusTable), wenn der Workflow-Status auf „Abgeschlossen“ oder „Freigegeben“ gesetzt wird.
Erfassung
Extrahieren Sie das Ereignis „Freigegeben“ oder „Abgeschlossen“ für die Rechnung aus dem Workflow-Verlauf.
Ereignistyp
explicit
|
|||
|
Rechnung gebucht
|
Die freigegebene Rechnung wird offiziell im Hauptbuch erfasst und begründet eine finanzielle Verbindlichkeit. Dies ist ein wichtiger, oft nicht rückgängig zu machender Buchungsvorgang. | ||
|
Warum das wichtig ist
Die Buchung ist ein wichtiger Meilenstein, durch den die Rechnung zahlungsfähig wird. Sie bestätigt, dass alle Prüfungs- und Freigabeschritte abgeschlossen sind und die Verbindlichkeit erfasst wurde.
Woher beziehen
Dies ist ein ausdrücklich erfasster Geschäftsvorfall. Buchungsdatum und -zeit werden im Lieferantenrechnungsjournal (VendInvoiceJour) und in den zugehörigen Hauptbucheinträgen (GeneralJournalEntry) gespeichert.
Erfassung
Verwenden Sie den Buchungs-Timestamp aus den Tabellen VendInvoiceJour oder GeneralJournalEntry.
Ereignistyp
explicit
|
|||
|
Rechnung zur Freigabe eingereicht
|
Die Rechnung wird offiziell einem Workflow zur Prüfung und Freigabe durch autorisierte Personen übermittelt. Damit beginnt der Freigabezyklus. | ||
|
Warum das wichtig ist
Dieser wichtige Meilenstein markiert den Beginn der Messung der Rechnungsfreigabezeit. So lässt sich die Zeit für Dateneingabe und Abgleich von Verzögerungen bei der Freigabe unterscheiden.
Woher beziehen
Dieses Ereignis wird für das jeweilige Rechnungsdokument ausdrücklich in den D365-Workflow-Verlaufsprotokollen (WorkflowTrackingStatusTable) erfasst. Der Timestamp der Übermittlung wird gespeichert.
Erfassung
Extrahieren Sie das Ereignis „Eingereicht“ für die Rechnung aus dem Workflow-Verlauf.
Ereignistyp
explicit
|
|||
|
Zahlung ausgeführt
|
Die Zahlung wird durch die Buchung eines Zahlungsjournals offiziell ausgeführt. Dieser Vorgang begleicht die Verbindlichkeit aus der gebuchten Rechnung. | ||
|
Warum das wichtig ist
Dies ist ein primäres End-Event des Prozesses. Es dient dazu, die Einhaltung von Zahlungsbedingungen zu berechnen, verspätete Zahlungen zu erkennen und die gesamte Durchlaufzeit zu messen.
Woher beziehen
Ein ausdrücklich erfasstes Ereignis, das bei der Buchung des Zahlungsjournals entsteht. Die Ausgleichsdaten werden in der Tabelle der Lieferantentransaktionen (VendTrans) gespeichert und verknüpfen die Zahlung mit der Rechnung.
Erfassung
Verwenden Sie das Transaktionsdatum des Zahlungsausgleichsdatensatzes in VendTrans.
Ereignistyp
explicit
|
|||
|
Abweichung behoben
|
Die Sperre wird aufgehoben oder die Rechnung korrigiert, nachdem eine Abweichung festgestellt wurde. Anschließend kann die Rechnung erneut zum Abgleich oder zur Freigabe eingereicht werden. | ||
|
Warum das wichtig ist
Diese Aktivität schließt eine Nacharbeitsschleife ab. Die Dauer der Klärung von Abweichungen ist ein wichtiger Indikator für die Effizienz der Ausnahmebearbeitung.
Woher beziehen
Abgeleitet aus dem Timestamp, zu dem der Status „Gesperrt“ für die Rechnung aufgehoben oder die Rechnung nach einer Ablehnung erneut an den Workflow übermittelt wird.
Erfassung
Erfassen Sie den Timestamp der Aufhebung der Sperre oder der erneuten Übermittlung der Rechnung nach einer Ablehnung.
Ereignistyp
inferred
|
|||
|
Abweichung festgestellt
|
Dieses Ereignis tritt ein, wenn die Rechnung die Prüfung oder den Abgleich mit der Bestellung oder dem Wareneingang nicht besteht und manuell bearbeitet werden muss. Häufig wird die Rechnung gesperrt oder mit einem bestimmten Status versehen. | ||
|
Warum das wichtig ist
Diese Aktivität leitet eine Nacharbeitsschleife ein. Ihre Häufigkeit und Ursachen zu analysieren, ist entscheidend, um Ineffizienzen im Prozess, Probleme mit der Datenqualität oder Schwierigkeiten mit Lieferanten zu erkennen.
Woher beziehen
Das Ereignis kann ausdrücklich im Rechnungsverlauf erfasst oder daraus abgeleitet werden, dass eine Rechnung mit einem Grundcode für eine Abweichung beim Abgleich auf „Gesperrt“ gesetzt wird. Prüfen Sie die Statusänderungen im Rechnungskopf.
Erfassung
Erfassen Sie den Timestamp, zu dem der Rechnungsstatus auf „Gesperrt“ gesetzt oder eine Abweichung gekennzeichnet wird.
Ereignistyp
inferred
|
|||
|
Bestellung abgeglichen
|
Dabei wird eine Rechnung einer oder mehreren Bestellungen zugeordnet, um Mengen, Preise und Bedingungen zu prüfen. Bei Rechnungen mit Bestellbezug ist dies ein entscheidender Prüfschritt. | ||
|
Warum das wichtig ist
Diese Aktivität ist wichtig, um die Quote erfolgreicher Abgleiche beim ersten Durchlauf zu messen und Engpässe im Abgleich zu erkennen. Fehlgeschlagene Abgleiche führen häufig zu Schleifen zur Klärung von Abweichungen.
Woher beziehen
Das Ereignis lässt sich ableiten, wenn der Abgleichsstatus der Rechnung auf „Abgeglichen“ gesetzt oder die Zuordnung auf Positionsebene erfolgreich gespeichert wird. Diese Informationen sind üblicherweise in Tabellen zu Lieferantenrechnungspositionen gespeichert.
Erfassung
Ermitteln Sie Statusänderungen im Rechnungskopf oder in den Rechnungspositionen, die einen erfolgreichen Bestellabgleich anzeigen.
Ereignistyp
inferred
|
|||
|
Rechnung abgelehnt
|
Eine freigebende Person lehnt die Rechnung im Workflow ab. In der Regel wird sie zur Korrektur oder Klärung an die einreichende Person zurückgesendet. Dadurch beginnt eine Nacharbeitsschleife. | ||
|
Warum das wichtig ist
Die Nachverfolgung von Ablehnungen hilft, Ursachen für Verzögerungen und Nacharbeit zu erkennen. Sie kann auf Probleme bei der Kontierung, Richtlinienverstöße oder unvollständige Dokumentation hinweisen.
Woher beziehen
Dieses Ereignis wird ausdrücklich im Workflow-Verlauf (WorkflowTrackingStatusTable) erfasst, wenn eine freigebende Person die Aktion „Ablehnen“ auswählt.
Erfassung
Extrahieren Sie das Ereignis „Abgelehnt“ für die Rechnung aus dem Workflow-Verlauf.
Ereignistyp
explicit
|
|||
|
Rechnung storniert
|
Die Rechnung wird nach der Buchung aufgehoben oder storniert, meist um einen Fehler zu korrigieren. Dies ist ein alternativer Ausnahme-Endpunkt des Prozesses. | ||
|
Warum das wichtig ist
Die Nachverfolgung von Stornierungen ist wichtig, um Prozessqualität und Fehlerquoten zu verstehen. Häufige Stornierungen können auf systematische Probleme in vorgelagerten Prozessschritten hinweisen.
Woher beziehen
Dieses Ereignis wird ausdrücklich erfasst. D365 erstellt eine Gegen- oder Gutschriftbuchung, die mit dem ursprünglichen Rechnungsjournal verknüpft ist. Das Buchungsdatum dieser Gegenbuchung kennzeichnet die Stornierung.
Erfassung
Ermitteln Sie das Buchungsdatum der Gegenbuchung, die mit der ursprünglichen Rechnung verknüpft ist.
Ereignistyp
explicit
|
|||
|
Rechnungsdaten geprüft
|
Bezeichnet die ersten Prüfungen durch das System oder einen Benutzer auf Vollständigkeit und Richtigkeit der erfassten Rechnungsdaten, bevor der Abgleich oder die Freigabe beginnt. Dabei kann es sich um eine automatische Systemprüfung oder eine manuelle Kontrolle handeln. | ||
|
Warum das wichtig ist
Die Nachverfolgung dieser Aktivität hilft, Verzögerungen aufgrund mangelhafter Datenqualität zu erkennen. Viele fehlgeschlagene Prüfungen oder eine lange Dauer weisen auf Probleme bei der Datenerfassung hin, etwa auf eine geringe OCR-Erkennungsgenauigkeit.
Woher beziehen
Dieses Ereignis wird häufig abgeleitet. Grundlage kann der Timestamp sein, zu dem sich der Rechnungsstatus von „Neu“ oder „Entwurf“ in „Geprüft“ oder „Bereit für den Abgleich“ ändert, oder die letzte Änderung vor der Übermittlung an den Workflow.
Erfassung
Erfassen Sie den Timestamp einer Statusänderung, die eine erfolgreiche Prüfung anzeigt, oder den Zeitpunkt der letzten Aktualisierung vor der Übermittlung an den Workflow.
Ereignistyp
inferred
|
|||
|
Wareneingang abgeglichen
|
Beim Drei-Wege-Abgleich bestätigt diese Aktivität, dass die berechneten Waren oder Dienstleistungen eingegangen sind. Dazu werden die Angaben mit den Wareneingangsbelegen abgeglichen. So wird die tatsächliche Lieferung mit der Rechnung verglichen. | ||
|
Warum das wichtig ist
Die Nachverfolgung dieser Aktivität hilft, die Effizienz des Drei-Wege-Abgleichs zu analysieren und Verzögerungen durch fehlende oder falsche Wareneingangsdaten zu erkennen.
Woher beziehen
Wie beim Bestellabgleich lässt sich dieses Ereignis aus Statusaktualisierungen der Rechnung ableiten, die einen erfolgreichen Abgleich mit den Produktzugangsjournalen (Packing Slips) anzeigen.
Erfassung
Achten Sie auf Statusänderungen oder Kennzeichen, die einen erfolgreichen Drei-Wege-Abgleich anzeigen.
Ereignistyp
inferred
|
|||
|
Zahlung bankseitig abgewickelt
|
Die vom Unternehmen ausgeführte Zahlung wurde von der Bank abgewickelt. Dies wird durch den Bankabgleich bestätigt und stellt die abschließende finanzielle Bestätigung des Zahlungseingangs dar. | ||
|
Warum das wichtig ist
Diese Aktivität bestätigt den tatsächlichen Mittelabfluss. Die Zeit zwischen der Ausführung und der bankseitigen Abwicklung ist für Treasury und Cash-Management wichtig.
Woher beziehen
Diese Informationen stammen aus den Modulen für den Bankabgleich. Das Ereignis wird abgeleitet, wenn eine passende Kontoauszugszeile in D365 zugeordnet und gebucht wird.
Erfassung
Dazu müssen Banktransaktionsdaten (BankStmtISOAccountStatement) mit der ursprünglichen Zahlung verknüpft werden.
Ereignistyp
inferred
|
|||
|
Zahlung eingeplant
|
Die gebuchte Rechnung wird einem Zahlungsvorschlag oder Zahlungsjournal hinzugefügt und für einen künftigen Zahlungslauf eingeplant. Damit wird die Zahlungsabsicht erfasst. | ||
|
Warum das wichtig ist
Diese Aktivität ist wichtig für die Cashflow-Prognose und die Analyse der Einhaltung von Zahlungsbedingungen. Sie zeigt, ob Skonti für frühzeitige Zahlungen berücksichtigt und eingeplant werden.
Woher beziehen
Abgeleitet aus der Anlage einer Zahlungsjournalzeile (LedgerJournalTrans), die die Rechnung enthält. Das Buchungsdatum der Journalzeile gibt den geplanten Zahlungstermin an.
Erfassung
Verwenden Sie das Erstellungsdatum der Zahlungsjournalzeile, die auf die Rechnung verweist.
Ereignistyp
inferred
|
|||
Anleitungen zur Datenextraktion
Möchten Sie beginnen?
Nutzen Sie dieses Daten-Template als Ausgangspunkt für eine effizientere Kreditorenrechnungsverarbeitung. Erschließen Sie das Potenzial Ihrer Prozessdaten und erzielen Sie spürbare Verbesserungen.
Doppelte Zahlungen vermeiden. Kreditorenrechnungen effizienter verarbeiten.
Erkennen Sie Ineffizienzen, vermeiden Sie Verzugsgebühren und senken Sie die Verarbeitungskosten um 60 %.
14 Tage kostenlos testen, keine Kreditkarte erforderlich.