Datentemplate: 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 | ||
|---|---|---|---|
|
Rechnung
Invoice
|
Der eindeutige Identifikator für jedes Dokument einer Lieferantenrechnung. | ||
|
Beschreibung
Die Rechnung dient als primärer Case-Identifikator, der alle Aktivitäten vom Rechnungseingang bis zur endgültigen Zahlung verbindet. Dies ermöglicht eine End-to-End-Analyse der gesamten Reise jeder einzelnen Rechnung durch den Kreditorenprozess. Bei der Analyse ist die Gruppierung von Events nach diesem Identifikator der erste Schritt zur Rekonstruktion des Prozessflusses für jede Rechnung. Sie ermöglicht die Berechnung von fallbezogenen KPIs wie der Gesamtzykluszeit und hilft, prozessspezifische Varianten und Engpässe im Verlauf jeder einzelnen Rechnung zu identifizieren.
Warum es wichtig ist
Dies ist der wesentliche Schlüssel, um den gesamten Lebenszyklus einer Rechnung zu verfolgen, und bildet somit die Grundlage für alle Process Mining-Analysen in der Kreditorenbuchhaltung.
Woher erhalten
Dies ist typischerweise die Lieferantenrechnungsnummer von der Seite 'Kreditorenrechnung' oder verwandten Datenentitäten in Dynamics 365 Finance.
Beispiele
INV-00125475000921DE-8832-2023
|
|||
|
Aktivität
ActivityName
|
Der Name des ausgeführten Geschäftsprozessschritts. | ||
|
Beschreibung
Dieses Attribut erfasst die spezifische Aktion oder das Event, das zu einem bestimmten Zeitpunkt für eine Rechnung aufgetreten ist, wie z. B. „Rechnung registriert“ oder „Rechnung genehmigt“. Diese Aktivitäten bilden die Knotenpunkte in der entdeckten Prozesslandkarte. Die Analyse der Reihenfolge und Häufigkeit von Aktivitäten ist fundamental für Process Mining. Sie hilft, den Prozessfluss zu visualisieren, häufige und seltene Pfade (Varianten) zu identifizieren und Aktivitäten zu lokalisieren, die Verzögerungen oder Nacharbeit verursachen.
Warum es wichtig ist
Aktivitäten definieren das „Was“ im Prozess. Sie ermöglichen die Erstellung einer Prozesslandkarte sowie die Analyse des Prozessflusses und seiner Varianten.
Woher erhalten
Dies wird oft aus Statusänderungen, Workflow-Verlaufsprotokollen oder Belegbuchungsaufzeichnungen innerhalb des Dynamics 365 AP-Moduls abgeleitet.
Beispiele
Rechnung registriertRechnung freigegebenAbweichung behobenZahlung ausgeführt
|
|||
|
Startzeit
EventTime
|
Der timestamp, der angibt, wann eine Aktivität oder ein Event stattgefunden hat. | ||
|
Beschreibung
Dieses Attribut liefert Datum und Uhrzeit für jede Aktivität, was essenziell ist, um Events chronologisch zu ordnen und Dauern zu berechnen. Es bildet das zeitliche Rückgrat des Event Logs. In der Analyse wird die Startzeit verwendet, um alle zeitbezogenen Metriken zu berechnen, einschließlich Durchlaufzeiten zwischen Aktivitäten, Wartezeiten und der gesamten Falldauer. Sie ist entscheidend für die Identifizierung von Engpässen und die Messung der Prozessperformance anhand von SLAs.
Warum es wichtig ist
Dieser Timestamp ist entscheidend für die korrekte Sequenzierung von Events und die Berechnung aller Performance-Metriken, wie Zykluszeiten und Engpässe.
Woher erhalten
Entnommen aus Erstellungs- oder Änderungsdatumsfeldern in Transaktionsdatensätzen, Workflow-Historienprotokollen 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
Identifiziert den spezifischen Benutzer, der für die Durchführung eines Prozessschritts verantwortlich ist, wie z.B. die Registrierung einer Rechnung oder deren Genehmigung. Dies ist oft mit der System-ID des Benutzers in Dynamics 365 verknüpft. Die Leistungsanalyse pro Benutzer hilft, Schulungsbedarfe, Top-Performer und die Arbeitslastverteilung zu identifizieren. Dies ist unerlässlich für Dashboards, die sich auf Genehmigungszeiten und Ressourceneffizienz konzentrieren, und ermöglicht es Managern zu erkennen, welche Benutzer oder Teams Engpässe verursachen.
Warum es wichtig ist
Weist Aufgaben bestimmten Personen zu und ermöglicht so die Analyse von Arbeitslast, Leistung sowie die Identifizierung von Schulungsmöglichkeiten.
Woher erhalten
Typischerweise zu finden in den Feldern 'Erstellt von' oder 'Geändert von' bei Transaktionen oder in den Workflow-Verlaufsprotokollen in Dynamics 365.
Beispiele
j.doea.smithr.williams
|
|||
|
Bestellnummer
PurchaseOrderNumber
|
Der eindeutige Identifikator für die Bestellung, die mit der Rechnung verknüpft ist. | ||
|
Beschreibung
Dieses Attribut verknüpft die Rechnung mit der entsprechenden Bestellung (PO). Rechnungen können bestellungsbezogen (PO-bezogen) oder nicht bestellungsbezogen sein. Die Analyse dieses Attributs hilft, zwischen bestellungsbezogener und nicht-bestellungsbezogener Rechnungsverarbeitung zu unterscheiden, die oft unterschiedliche Workflows durchlaufen. Sie ist essenziell für die Messung der Effizienz des PO-Abgleichs und die Identifizierung von Problemen, die entstehen, wenn Rechnungsdetails nicht mit der Bestellung übereinstimmen.
Warum es wichtig ist
Unterscheidet zwischen Rechnungen mit und ohne Bestellbezug, da diese unterschiedliche Prozesse durchlaufen. Dies ist unerlässlich für die Analyse der Abgleichseffizienz.
Woher erhalten
Findet sich im Kopf oder in den Positionen der Lieferantenrechnung, typischerweise in einem Feld namens 'PurchId' in der 'VendInvoiceInfoTable'.
Beispiele
PO-000432PO-000511
|
|||
|
Lieferant
VendorName
|
Der Name des Lieferanten oder Kreditors, der die Rechnung eingereicht hat. | ||
|
Beschreibung
Dieses Attribut identifiziert den Lieferanten, der mit der Rechnung verbunden ist. Lieferantendaten umfassen oft Details wie Name, ID und Kategorie. Eine Analyse des Kreditorenprozesses nach Lieferanten kann aufzeigen, welche Lieferanten regelmäßig problematische Rechnungen einreichen (z. B. solche mit häufigen Abweichungen), welche besondere Zahlungsbedingungen haben und welche mit langen Bearbeitungszyklen verbunden sind. Diese Erkenntnis kann genutzt werden, um Lieferantenbeziehungen und die Zusammenarbeit zu verbessern.
Warum es wichtig ist
Ermöglicht die Segmentierung des Prozesses, um anbieterspezifische Probleme wie häufige Abweichungen oder Zahlungsverzögerungen zu identifizieren.
Woher erhalten
Verknüpft aus dem Rechnungsbelegkopf des Kreditors, typischerweise aus der Datenentität 'VendTable' basierend auf der Kreditorenkontonummer.
Beispiele
Contoso LtdFabrikam IncNorthwind Traders
|
|||
|
Rechnungsbetrag
InvoiceAmount
|
Der monetäre Gesamtwert der Rechnung. | ||
|
Beschreibung
Repräsentiert den fälligen Gesamtbetrag der Kreditorenrechnung. Dies ist eine entscheidende Finanzkennzahl für jeden Case. Dieses Attribut ermöglicht eine Finanzanalyse des Kreditorenprozesses. Es kann verwendet werden, um Rechnungen mit hohem Wert zu priorisieren, Genehmigungszeiten basierend auf Betragsschwellen zu analysieren und die finanziellen Auswirkungen von Zahlungsverzögerungen oder Skonto zu verstehen.
Warum es wichtig ist
Bietet einen finanziellen Kontext, der die Analyse des Prozessverhaltens basierend auf monetärem Wert ermöglicht, z.B. um festzustellen, ob Rechnungen mit hohem Wert anders bearbeitet werden.
Woher erhalten
Im Rechnungsbelegkopf des Kreditors zu finden, oft in Feldern wie 'InvoiceAmount' in 'VendInvoiceInfoTable'.
Beispiele
1500.75250.0012345.50
|
|||
|
Rechnungsfälligkeitsdatum
InvoiceDueDate
|
Das Fälligkeitsdatum der Rechnungszahlung, berechnet auf Basis der Zahlungsbedingungen. | ||
|
Beschreibung
Dieses Datum gibt die Frist für die Begleichung der Rechnung an, um Strafen zu vermeiden und Lieferantenvereinbarungen einzuhalten. Es wird üblicherweise auf Basis des Rechnungsdatums und der festgelegten Zahlungsbedingungen berechnet. Dieses Attribut ist essenziell für die Analyse der „Einhaltung der Zahlungsbedingungen“. Durch den Vergleich des Datums der „Ausgeführten Zahlung“ mit dem „Rechnungsfälligkeitsdatum“ kann die Analyse automatisch verspätete Zahlungen markieren, Einhaltungsquoten berechnen und dabei helfen, Zahlungen zu priorisieren, um gute Lieferantenbeziehungen zu pflegen.
Warum es wichtig ist
Entscheidend für die Messung der Pünktlichkeit von Zahlungen, das Management von Lieferantenbeziehungen und die Vermeidung von Verzugszinsen.
Woher erhalten
Berechnetes Feld basierend auf Rechnungsdatum und Zahlungsbedingungen. Gespeichert in Feldern wie 'DueDate' in Kreditorentransaktionstabellen (z.B. 'VendTrans').
Beispiele
2023-05-152023-06-302023-07-01
|
|||
|
Zahlungsbedingungen
PaymentTerms
|
Die mit dem Lieferanten vereinbarten Zahlungsbedingungen für Rechnungen. | ||
|
Beschreibung
Dieses Attribut definiert die Zahlungsbedingungen, unter denen eine Lieferantenrechnung zu bezahlen ist, wie z. B. „Net 30“ (zahlbar innerhalb von 30 Tagen) oder „2/10 Net 30“ (2 % Skonto bei Zahlung innerhalb von 10 Tagen, andernfalls innerhalb von 30 Tagen fällig). Eine Analyse nach Zahlungsbedingungen hilft zu verstehen, wie unterschiedliche Vereinbarungen die Zahlungspünktlichkeit und den Cashflow beeinflussen. Sie bildet die Grundlage, um Skontopotenziale bei vorzeitiger Zahlung zu identifizieren und die Compliance-Analyse zu segmentieren, um zu erkennen, ob bestimmte Bedingungen schwerer einzuhalten sind.
Warum es wichtig ist
Definiert Zahlungsfristen und Skonto-Möglichkeiten, was sich direkt auf das Cashflow-Management und Kosteneinsparungen auswirkt.
Woher erhalten
Findet sich in den Lieferantenstammdaten oder ist im Kopf der Bestellung/Rechnung angegeben. Gespeichert in Feldern wie 'PaymTermId'.
Beispiele
Netto 30Netto 602/10 Net 30
|
|||
|
Buchungskreis
CompanyCode
|
Die Kennung der juristischen Person, die die Rechnung bearbeitet. | ||
|
Beschreibung
Dieses Attribut identifiziert das spezifische Unternehmen oder die juristische Einheit innerhalb der Organisation, das bzw. die für die Rechnung verantwortlich ist. In Multi-Company-Setups ist dies eine kritische organisatorische Dimension. Die Analyse des Kreditorenprozesses (AP-Prozess) nach Buchungskreis ermöglicht einen Leistungsvergleich zwischen verschiedenen Geschäftseinheiten oder juristischen Einheiten. Sie hilft zu erkennen, ob bestimmte Einheiten weniger effizient sind, höhere Nacharbeitsquoten aufweisen oder unterschiedlichen Prozessvarianten folgen, und zeigt so Möglichkeiten zur Standardisierung und zum Austausch von Best Practices auf.
Warum es wichtig ist
Ermöglicht Leistungs-Benchmarking und Prozessvergleiche zwischen verschiedenen Rechtseinheiten oder Geschäftsbereichen innerhalb des Unternehmens.
Woher erhalten
Ein Standardfeld in fast allen Transaktionstabellen in Dynamics 365, typischerweise 'DataAreaId' benannt.
Beispiele
USMFDEMFGBSI
|
|||
|
Genehmiger
ApproverName
|
Der Benutzer, der die Rechnung in einem bestimmten Schritt genehmigt oder abgelehnt hat. | ||
|
Beschreibung
Dieses Attribut identifiziert die Person, die für eine Genehmigungsentscheidung im Workflow verantwortlich ist. Bei Rechnungen mit mehrstufigen Genehmigungsprozessen kann es unterschiedliche Genehmigende für verschiedene Schritte geben. Es ist unerlässlich für das Dashboard „Analyse der Genehmigungsdurchlaufzeit von Rechnungen“. Die Analyse kann nach Genehmigenden aufgeschlüsselt werden, um Personen zu identifizieren, die potenzielle Engpässe im Prozess darstellen, sei es aufgrund von Arbeitsaufkommen oder anderen Faktoren. Dies ermöglicht gezielte Interventionen, um den Genehmigungszyklus zu beschleunigen.
Warum es wichtig ist
Ermöglicht eine detaillierte Analyse des Freigabeprozesses und hilft, Engpässe auf individueller oder Teamebene zu identifizieren.
Woher erhalten
Extrahiert aus den Workflow-Verlaufsprotokollen ('WorkflowTrackingStatusTable'), die den Benutzer aufzeichnen, der jeden Genehmigungsschritt abgeschlossen hat.
Beispiele
David ChenMaria GarciaAP_Manager_Group
|
|||
|
Grund der Abweichung
DiscrepancyReason
|
Der Grundcode oder die Beschreibung für eine Rechnungsdiskrepanz. | ||
|
Beschreibung
Wenn eine Rechnung zurückgehalten oder eine Abweichung festgestellt wird, erfasst dieses Attribut den Grund, wie z.B. „Preisabweichung“, „Mengenabweichung“ oder „Fehlender Wareneingang“. Dieses Attribut ist entscheidend für die „Analyse zur Behebung von Abweichungen und Nacharbeit“. Durch die Kategorisierung der Nacharbeit basierend auf dem Grund kann die Analyse die Grundursachen für Prozessineffizienzen identifizieren. Wenn beispielsweise „Preisabweichung“ der häufigste Grund ist, deutet dies auf die Notwendigkeit einer besseren Datenabstimmung zwischen Einkauf und Lieferanten hin.
Warum es wichtig ist
Liefert die Grundursache für Nacharbeit und ermöglicht so gezielte Prozessverbesserungen zur Reduzierung von Ausnahmen und manuellem Eingriff.
Woher erhalten
Kann in Rechnungs-Halte-Tabellen, Workflow-Kommentaren oder spezifischen Fehlerprotokollfeldern innerhalb des AP-Moduls gespeichert sein.
Beispiele
PreisabweichungMengenabweichungUngültige Bestellung
|
|||
|
Ist automatisiert
IsAutomated
|
Ein Kennzeichen, das angibt, ob die Aktivität automatisch vom System ausgeführt wurde. | ||
|
Beschreibung
Dieses boolesche Attribut unterscheidet zwischen Aktivitäten, die von menschlichen Nutzern ausgeführt werden, und solchen, die durch Systemautomatisierung erfolgen, wie z. B. die automatische Rechnungsbuchung oder der automatische Abgleich. Die Analyse dieses Attributs ist entscheidend, um den Grad der Automatisierung im Kreditorenprozess (AP-Prozess) zu messen. Es hilft bei der Berechnung der Straight-Through Processing (STP)-Rate und identifiziert, welche manuellen Aktivitäten ideale Kandidaten für zukünftige Automatisierungsinitiativen sind, wodurch letztlich Kosten und Bearbeitungszeit reduziert werden.
Warum es wichtig ist
Hilft bei der Messung der Direktverarbeitungsrate und identifiziert Möglichkeiten zur Steigerung von Automatisierung und Effizienz.
Woher erhalten
Abgeleitet durch die Prüfung, ob der einer Aktivität zugeordnete Benutzer ein System- oder Batch-Benutzer ist (z.B. „Admin“, „BatchUser“).
Beispiele
truefalse
|
|||
|
Ist Nacharbeit
IsRework
|
Ein berechnetes Kennzeichen, das anzeigt, ob eine Rechnung nachbearbeitet wurde. | ||
|
Beschreibung
Dieses boolesche Flag ist auf „true“ gesetzt, wenn der Prozessfluss einer Rechnung Nacharbeitsaktivitäten umfasst, wie z. B. „Abweichung behoben“ oder einen zweiten Schritt „Rechnungsdaten validiert“ nach einem anfänglichen Fehler. Es wird über den gesamten Fall hinweg berechnet. Dieses Attribut unterstützt direkt die KPI „Nacharbeitsquote bei Abweichungen“. Es vereinfacht die Analyse, indem es ein einfaches Filtern und Aggregieren aller Rechnungen ermöglicht, die zusätzlichen manuellen Aufwand erforderten, was hilft, die Auswirkungen schlechter Datenqualität oder Prozessausnahmen zu quantifizieren.
Warum es wichtig ist
Misst direkt die Nacharbeit und ermöglicht so eine einfache Quantifizierung und Analyse von Prozessausnahmen und Ineffizienzen.
Woher erhalten
Dies ist kein Quellsystemfeld. Es wird im Process Mining Tool berechnet, indem das Vorkommen spezifischer auf Nacharbeit hinweisender Aktivitäten innerhalb eines Case überprüft wird.
Beispiele
truefalse
|
|||
|
Ist verspätete Zahlung
IsLatePayment
|
Ein berechnetes Kennzeichen, das angibt, ob die Zahlung nach dem Fälligkeitsdatum erfolgte. | ||
|
Beschreibung
Dieses boolesche Attribut ist auf „true“ gesetzt, wenn die Aktivität „Zahlung ausgeführt“ nach dem „Rechnungsfälligkeitsdatum“ erfolgt. Es liefert einen klaren, fallbezogenen Indikator für die Nichteinhaltung der Zahlungsbedingungen. Dieses Attribut vereinfacht die Berechnung der KPI „Einhaltungsquote der Zahlungsbedingungen“. Es ermöglicht schnelles Filtern und Dashboarding, um das Volumen und den Wert verspäteter Zahlungen anzuzeigen, und ermöglicht eine Ursachenanalyse dieser spezifischen Fälle, um zu verstehen, warum sie verzögert wurden.
Warum es wichtig ist
Bietet eine klare und einfache Kennzeichnung zur Analyse nicht-konformer Zahlungen und zur Berechnung von KPIs für pünktliche Zahlungen.
Woher erhalten
Dies ist kein Quellsystemfeld. Es wird im Process Mining Tool berechnet, indem der Timestamp der Aktivität 'Zahlung ausgeführt' mit dem Attribut 'Rechnungsfälligkeitsdatum' verglichen wird.
Beispiele
truefalse
|
|||
|
Letzte Datenaktualisierung
LastDataUpdate
|
Der timestamp der letzten Datenaktualisierung aus dem Quellsystem. | ||
|
Beschreibung
Dieses Attribut gibt an, wann der Event Log zuletzt mit neuen Daten aus Microsoft Dynamics 365 aktualisiert wurde. Es liefert Kontext zur Aktualität der analysierten Daten. Für Dashboards und das fortlaufende Monitoring ist dieser Timestamp entscheidend, damit Nutzende verstehen, ob sie die aktuellsten Prozessdaten sehen. Es hilft, Erwartungen an die Datenfrische zu managen und die Integrität der Datenpipeline zu überwachen.
Warum es wichtig ist
Informiert Benutzer über die Aktualität der Daten, was entscheidend für zeitnahe und präzise Geschäftsentscheidungen auf Basis der Analyse ist.
Woher erhalten
Dies ist ein Metadatenfeld, das vom ETL-Tool (Datenextraktion und -ladung) zum Zeitpunkt der Datenaufnahme generiert und mit einem Zeitstempel versehen wird.
Beispiele
2023-06-01T02:00:00Z2023-06-02T02:00:00Z
|
|||
|
Quellsystem
SourceSystem
|
Das System, aus dem die Daten extrahiert wurden. | ||
|
Beschreibung
Dieses Attribut identifiziert die Herkunft der Event-Daten, die in diesem Kontext typischerweise „Microsoft Dynamics 365“ ist. Es wird besonders wichtig, wenn Daten aus mehreren Systemen (z. B. einem OCR-Scanning-Tool und D365) kombiniert werden. In einer Process Mining Analyse unterstützt dies bei der Datenherkunft (Data Lineage), der Fehlerbehebung (Troubleshooting) und dem Verständnis der technologischen Landschaft des Prozesses. Es ermöglicht, die Analyse auf Events aus einem bestimmten System zu filtern.
Warum es wichtig ist
Liefert wesentlichen Kontext zur Datenherkunft, was für die Datenvalidierung und in Multi-System-Prozessanalysen entscheidend ist.
Woher erhalten
Dies ist typischerweise ein statischer Wert ('Microsoft Dynamics 365'), der während des Datenextraktions- und Transformationsprozesses hinzugefügt wird.
Beispiele
Microsoft Dynamics 365 FinanceD365 F&OAX2012
|
|||
|
Rechnungsbearbeitungszeit
InvoiceProcessingTime
|
Die Gesamtzykluszeit für eine Rechnung vom Eingang bis zur Zahlung. | ||
|
Beschreibung
Diese Kennzahl repräsentiert die gesamte abgelaufene Zeit für einen Rechnungs-Case, typischerweise berechnet vom Timestamp der ersten Aktivität (z. B. 'Rechnung registriert') bis zum Timestamp einer abschließenden Aktivität (z. B. 'Zahlung ausgeführt'). Dies ist ein primärer KPI ('Durchschnittliche Rechnungszykluszeit') zur Messung der gesamten Prozesseffizienz. Die Analyse dieser Dauer hilft, systemische Verzögerungen zu identifizieren und bietet einen übergeordneten Benchmark für Prozessverbesserungsinitiativen. Sie kann nach Dimensionen wie Lieferant oder Buchungskreis aufgeteilt werden, um Bereiche mit den längsten Zykluszeiten zu finden.
Warum es wichtig ist
Misst direkt die End-to-End-Prozesseffizienz und dient als Schlüsselkennzahl zur Überwachung der Performance des gesamten AP-Prozesses.
Woher erhalten
Dies ist kein Quellsystemfeld. Es wird im Process Mining Tool berechnet, indem die Differenz zwischen den Timestamps des ersten und letzten Events eines Case ermittelt wird.
Beispiele
15 Tage 4 Stunden3 Tage 11 Stunden32 Tage 1 Stunde
|
|||
|
Rechnungsstatus
InvoiceStatus
|
Der aktuelle Bearbeitungsstatus der Rechnung. | ||
|
Beschreibung
Dieses Attribut spiegelt den letzten bekannten Status einer Rechnung im Prozess wider, wie z. B. „In Bearbeitung“, „Genehmigt“, „Bezahlt“ oder „Storniert“. Es bietet einen Überblick über die Position der Rechnung in ihrem Lebenszyklus. Während Process Mining den Fluss aus Aktivitäten ableitet, ist der endgültige Status nützlich für die Validierung und für die Erstellung von Dashboards auf Geschäftsebene, die den aktuellen Zustand aller offenen Rechnungen zusammenfassen. Es kann verwendet werden, um nach allen Rechnungen zu filtern, die aktuell „Genehmigt“, aber noch nicht „Bezahlt“ sind.
Warum es wichtig ist
Bietet eine übergeordnete Zusammenfassung des aktuellen Rechnungsstatus, nützlich für Filterungen und die Erstellung statusbasierter Dashboards.
Woher erhalten
Oft abgeleitet von Dokumentstatus- oder Workflow-Statusfeldern innerhalb des AP-Moduls.
Beispiele
In BearbeitungGenehmigtBezahltStorniert
|
|||
|
Skonto-Fälligkeitsdatum
EarlyPaymentDiscountDate
|
Die Frist für die Zahlung der Rechnung, um Skonto zu erhalten. | ||
|
Beschreibung
Dieses Attribut gibt den letzten Tag an, an dem eine Rechnung bezahlt werden kann, um den vom Lieferanten angebotenen Skonto zu erhalten. Er wird aus dem Rechnungsdatum und dem Skontoteil der Zahlungsbedingungen abgeleitet (z. B. der „10“ in „2/10 Net 30“). Dieses Datum ist der primäre Treiber für die Analyse „Status der Skontozahlungen“. Durch den Vergleich des Datums der „Geplanten Zahlung“ oder „Ausgeführten Zahlung“ mit dieser Frist kann das System feststellen, ob ein Skonto erfolgreich genutzt wurde, und liefert so klare Metriken zur finanziellen Optimierung.
Warum es wichtig ist
Definiert das Zieldatum für die Realisierung von Kosteneinsparungen und ist somit ein wichtiger Treiber für die Zahlungspriorisierung und Effizienzverbesserungen.
Woher erhalten
Vom System basierend auf Zahlungsbedingungen und Rechnungsdatum berechnet. Gespeichert in Feldern wie 'CashDiscDate' in 'VendTrans'.
Beispiele
2023-04-252023-05-102023-06-15
|
|||
|
Skontobetrag
EarlyPaymentDiscountAmount
|
Der potenzielle Skontobetrag bei frühzeitiger Zahlung der Rechnung. | ||
|
Beschreibung
Dieses Attribut zeigt den monetären Wert des Skontos, das vom Lieferanten für vorzeitige Zahlung angeboten wird, wie in den Zahlungsbedingungen definiert. Diese Finanzdaten sind entscheidend für das Dashboard „Status der Skontozahlungen“. Es ermöglicht dem Unternehmen, den Wert der genutzten Skonti im Vergleich zu den verpassten zu quantifizieren, und bietet einen klaren finanziellen Anreiz zur Verbesserung der Effizienz der Rechnungsfreigabe- und Zahlungsplanungsprozesse.
Warum es wichtig ist
Quantifiziert das finanzielle Potenzial der Prozesseffizienz und stellt eine direkte Verbindung zwischen Prozessleistung und Kosteneinsparungen her.
Woher erhalten
Berechnetes Feld basierend auf Rechnungsbetrag und Zahlungsbedingungen. Dieser Wert ist in Tabellen wie 'VendTrans' oder verwandten Skontofeldern verfügbar.
Beispiele
30.015.00246.91
|
|||
|
Wareneingangsnummer
GoodsReceiptNumber
|
Die Kennung des Wareneingangsbelegs, der zur Rechnung gehört. | ||
|
Beschreibung
Dieses Attribut verknüpft die Rechnung mit dem Wareneingang oder der Leistungserfassung, was für den Drei-Wege-Abgleich (Bestellung, Wareneingang und Rechnung) erforderlich ist. Dies ist essenziell für die Analyse der Abgleichseffizienz des Prozesses. Verzögerungen oder Fehler bei Aktivitäten wie „Wareneingang abgeglichen“ können mithilfe dieses Identifikators untersucht werden, um zum ursprünglichen Wareneingangsdokument zurückzuverfolgen, was hilft, Probleme in den Beschaffungs- oder Wareneingangsschritten zu identifizieren, die sich auf die Kreditorenbuchhaltung auswirken.
Warum es wichtig ist
Erleichtert die Analyse der Effizienz des Drei-Wege-Abgleichs und hilft, Probleme zu identifizieren, die im Wareneingangsprozess entstehen.
Woher erhalten
Verknüpft über die Bestellpositionen, oft in Lieferscheinjournalen ('VendPackingSlipJour') oder verwandten Tabellen zu finden.
Beispiele
GRN-00981GRN-01024
|
|||
Aktivitäten der Kreditoren-Rechnungsverarbeitung
| Aktivität | Beschreibung | ||
|---|---|---|---|
|
Rechnung freigegeben
|
Stellt die finale Genehmigung im Workflow dar, die die Buchung der Rechnung zur Zahlung autorisiert. Dies ist ein entscheidender Meilenstein, bevor die Rechnung in die Zahlungsphase übergeht. | ||
|
Warum es wichtig ist
Kennzeichnet das Ende des Genehmigungszyklus. Die Zeit zwischen 'Submitted for Approval' und dieser Aktivität ist ein Schlüssel-KPI zur Identifizierung von Genehmigungsengpässen und langlaufenden Workflows.
Woher erhalten
Ein explizites Ereignis, das in den Workflow-Historienprotokollen (WorkflowTrackingStatusTable) erfasst wird, wenn der Workflow-Status auf „Abgeschlossen“ oder „Genehmigt“ aktualisiert wird.
Erfassen
Extrahieren Sie das Ereignis 'Genehmigt' oder 'Abgeschlossen' für die Rechnung aus dem Workflow-Verlauf.
Ereignistyp
explicit
|
|||
|
Rechnung gebucht
|
Die genehmigte Rechnung wird offiziell im Hauptbuch verbucht, wodurch eine finanzielle Verbindlichkeit entsteht. Dies ist eine kritische, oft unumkehrbare Buchungstransaktion. | ||
|
Warum es wichtig ist
Die Buchung ist ein entscheidender Schritt, der die Rechnung zur Zahlung freigibt. Sie bestätigt, dass alle Prüf- und Genehmigungsschritte abgeschlossen sind und die Verbindlichkeit anerkannt ist.
Woher erhalten
Dies ist eine explizite Transaktion. Das Buchungsdatum und die Uhrzeit werden im Kreditorenrechnungsjournal (VendInvoiceJour) und den zugehörigen Hauptbucheinträgen (GeneralJournalEntry) erfasst.
Erfassen
Verwenden Sie den Buchungs-Timestamp aus den Tabellen VendInvoiceJour oder GeneralJournalEntry.
Ereignistyp
explicit
|
|||
|
Rechnung registriert
|
Kennzeichnet die erstmalige Erstellung eines Rechnungsdatensatzes im System, entweder durch manuelle Eingabe, OCR-Scanning oder elektronischen Datenaustausch (EDI). Dies ist der Ausgangspunkt des Rechnungsbearbeitungslebenszyklus. | ||
|
Warum es wichtig ist
Diese Aktivität ist das primäre Start-Event für den Prozess. Die Analyse der Zeitspanne von diesem Punkt bis zur Zahlung liefert die gesamte Rechnungszykluszeit, einen wichtigen Key Performance Indicator.
Woher erhalten
Abgeleitet vom Erstellungs-Zeitstempel (Feld CreatedDateTime) des Rechnungsheader-Datensatzes in den Tabellen der ausstehenden Lieferantenrechnungen oder Rechnungsjournale, wie z.B. VendInvoiceInfoTable.
Erfassen
Verwenden Sie den Erstellungs-Timestamp des Kopfdatensatzes der Rechnung.
Ereignistyp
inferred
|
|||
|
Rechnung zur Genehmigung eingereicht
|
Die Rechnung wird förmlich in einen Workflow zur Prüfung und Genehmigung durch autorisiertes Personal eingereicht. Dies markiert den Beginn des Genehmigungszyklus. | ||
|
Warum es wichtig ist
Dies ist ein wichtiger Meilenstein, der den Startpunkt für die Messung der Rechnungsfreigabe-Zykluszeit markiert. Er hilft, die Zeit für die Datenerfassung/den Abgleich von der Genehmigungslatenz zu unterscheiden.
Woher erhalten
Dies ist ein explizites Event, das in den D365 Workflow-Verlaufsprotokollen (WorkflowTrackingStatusTable) für das spezifische Rechnungsdokument erfasst wird. Der Übermittlungs-Timestamp wird aufgezeichnet.
Erfassen
Extrahieren Sie das Ereignis 'Eingereicht' für die Rechnung aus dem Workflow-Verlauf.
Ereignistyp
explicit
|
|||
|
Zahlung ausgeführt
|
Die Zahlung erfolgt offiziell durch die Buchung eines Zahlungsjournals. Diese Transaktion begleicht die Verbindlichkeit, die durch die gebuchte Rechnung entstanden ist. | ||
|
Warum es wichtig ist
Dies ist ein primäres End-Event für den Prozess. Es wird verwendet, um die Einhaltung der Zahlungsbedingungen zu berechnen, verspätete Zahlungen zu identifizieren und die endgültige End-to-End-Zykluszeit zu messen.
Woher erhalten
Ein explizites Ereignis, das erfasst wird, wenn das Zahlungsjournal gebucht wird. Die Abrechnungsdetails werden in der Kreditorentransaktionstabelle (VendTrans) gespeichert und verknüpfen so die Zahlung mit der Rechnung.
Erfassen
Verwenden Sie das Transaktionsdatum des Zahlungsausgleichsdatensatzes in VendTrans.
Ereignistyp
explicit
|
|||
|
Abweichung behoben
|
Die Maßnahme zur Aufhebung einer Sperre oder Korrektur einer Rechnung, nachdem eine Diskrepanz festgestellt wurde. Die Rechnung ist nun bereit, erneut für den Abgleich oder die Genehmigung eingereicht zu werden. | ||
|
Warum es wichtig ist
Diese Aktivität schließt einen Rework-Loop ab. Die Zeit, die zur Behebung von Diskrepanzen benötigt wird, ist ein Schlüsselindikator für die Effizienz des Ausnahmebehandlungsprozesses.
Woher erhalten
Abgeleitet vom Zeitstempel, zu dem eine Rechnung aus dem Sperrstatus entlassen oder nach einer Ablehnung erneut dem Workflow zugeführt wird.
Erfassen
Erfassen Sie den Zeitstempel, wenn eine Sperre aufgehoben oder die Rechnung nach Ablehnung erneut eingereicht wird.
Ereignistyp
inferred
|
|||
|
Bestellung abgeglichen
|
Der Prozess der Zuordnung einer Rechnung zu einer oder mehreren Bestellungen zur Überprüfung von Mengen, Preisen und Bedingungen. Dies ist ein kritischer Validierungsschritt für bestellbezogene Rechnungen. | ||
|
Warum es wichtig ist
Diese Aktivität ist essenziell für die Messung der First-Pass-Match-Raten und die Identifizierung von Engpässen im Abgleichsprozess. Fehler an dieser Stelle führen oft zu Diskrepanzbehebungs-Loops.
Woher erhalten
Kann abgeleitet werden, wenn der Abgleichstatus im Rechnungsdatensatz auf „Abgeglichen“ aktualisiert wird oder wenn die Abgleichdetails auf Positionsebene erfolgreich gespeichert werden. Diese Informationen werden typischerweise in Tabellen gespeichert, die mit Kreditorenrechnungspositionen zusammenhängen.
Erfassen
Statusänderungen im Rechnungsheader oder in den Positionen identifizieren, die sich auf den Erfolg des Bestellabgleichs beziehen.
Ereignistyp
inferred
|
|||
|
Rechnung abgelehnt
|
Ein Genehmiger lehnt die Rechnung innerhalb des Workflows ab und sendet sie typischerweise zur Korrektur oder Klärung an den ursprünglichen Ersteller zurück. Dies initiiert eine Nacharbeits-Schleife. | ||
|
Warum es wichtig ist
Die Verfolgung von Ablehnungen hilft, Gründe für Genehmigungsverzögerungen und Nacharbeiten zu identifizieren. Sie kann Probleme bei der Rechnungskodierung, Richtlinienverstöße oder unzureichende Dokumentation aufzeigen.
Woher erhalten
Dies ist ein explizites Event, das in der Workflow-Historie (WorkflowTrackingStatusTable) erfasst wird, wenn ein Genehmiger die Aktion 'Ablehnen' wählt.
Erfassen
Extrahieren Sie das Ereignis 'Abgelehnt' für die Rechnung aus dem Workflow-Verlauf.
Ereignistyp
explicit
|
|||
|
Rechnung storniert
|
Die Rechnung wird nach der Verbuchung storniert oder annulliert, üblicherweise zur Korrektur eines Fehlers. Dies ist ein alternativer, außergewöhnlicher Endpunkt für den Prozess. | ||
|
Warum es wichtig ist
Die Verfolgung von Stornierungen ist wichtig, um die Prozessqualität und Fehlerraten zu verstehen. Eine hohe Häufigkeit von Stornierungen kann auf systemische Probleme im vorgelagerten Prozess hinweisen.
Woher erhalten
Dies ist ein explizites Event. D365 erstellt eine Stornierungs- oder Gutschriftstransaktion, die mit dem ursprünglichen Rechnungsjournal verknüpft ist. Das Buchungsdatum dieser Stornierung markiert den Zeitpunkt der Stornierung.
Erfassen
Identifizieren Sie das Buchungsdatum der Stornobuchung, die mit der Originalrechnung verknüpft ist.
Ereignistyp
explicit
|
|||
|
Rechnungsdaten validiert
|
Beschreibt das System oder die Person, das/die erste Prüfungen der erfassten Rechnungsdaten auf Vollständigkeit und Korrektheit durchführt, noch vor dem Abgleich oder der Genehmigung. Dies kann eine automatisierte Systemvalidierung oder ein manueller Überprüfungsschritt sein. | ||
|
Warum es wichtig ist
Die Verfolgung dieser Aktivität hilft, Verzögerungen zu identifizieren, die durch schlechte Datenqualität verursacht werden. Eine hohe Fehlerquote oder eine lange Dauer dieser Aktivität weist auf Probleme bei Datenerfassungsprozessen hin, wie z. B. der OCR-Genauigkeit.
Woher erhalten
Dies ist oft ein abgeleitetes Event. Es kann vom Timestamp abgeleitet werden, wenn der Rechnungsstatus von 'Neu' oder 'Entwurf' in einen Zustand wie 'Validiert' oder 'Bereit für den Abgleich' wechselt, oder von der letzten Änderung vor der Übermittlung an den Workflow.
Erfassen
Erfassen Sie den Zeitstempel einer Statusänderung, die eine erfolgreiche Validierung anzeigt, oder des Aktualisierungsereignisses vor der Workflow-Einreichung.
Ereignistyp
inferred
|
|||
|
Unstimmigkeit festgestellt
|
Tritt auf, wenn die Rechnung die Validierung oder den Abgleich mit der Bestellung oder dem Wareneingang fehlschlägt, was eine manuelle Intervention erfordert. Häufig wird die Rechnung gesperrt oder erhält einen spezifischen Status. | ||
|
Warum es wichtig ist
Diese Aktivität initiiert einen Rework-Loop. Die Analyse ihrer Häufigkeit und Ursache ist entscheidend, um Prozessineffizienzen, Datenqualitätsprobleme oder Lieferantenprobleme zu identifizieren.
Woher erhalten
Dies kann explizit in der Rechnungshistorie protokolliert oder abgeleitet werden, wenn eine Rechnung mit einem Ursachencode, der sich auf eine Abweichung beim Abgleich bezieht, „auf Eis gelegt“ wird. Achten Sie auf Statusänderungen im Rechnungsheader.
Erfassen
Erfassen Sie den Zeitstempel, wenn der Rechnungsstatus auf „Gesperrt“ gesetzt oder ein Abweichungsflag gesetzt wird.
Ereignistyp
inferred
|
|||
|
Wareneingang abgeglichen
|
Für den Drei-Wege-Abgleich bestätigt diese Aktivität, dass die in Rechnung gestellten Waren oder Dienstleistungen empfangen wurden, indem sie mit Wareneingangsscheinen abgeglichen wird. Dieser Schritt überprüft die physische Lieferung anhand der Rechnung. | ||
|
Warum es wichtig ist
Die Verfolgung dieser Aktivität hilft, die Effizienz des Dreifachabgleichsprozesses zu analysieren und Verzögerungen zu identifizieren, die durch fehlende oder fehlerhafte Wareneingangsinformationen verursacht werden.
Woher erhalten
Ähnlich dem Bestellabgleich wird dies aus Statusaktualisierungen der Rechnung abgeleitet, die einen erfolgreichen Abgleich mit Wareneingangsjournalen (Lieferscheinen) anzeigen.
Erfassen
Achten Sie auf Statusänderungen oder Kennzeichnungen, die einen erfolgreichen Dreierabgleich anzeigen.
Ereignistyp
inferred
|
|||
|
Zahlung freigegeben
|
Die vom Unternehmen getätigte Zahlung ist von der Bank freigegeben, was durch den Bankabstimmungsprozess bestätigt wird. Dies ist die endgültige finanzielle Bestätigung des Zahlungsvollzugs. | ||
|
Warum es wichtig ist
Diese Aktivität liefert die endgültige Bestätigung des Geldabflusses. Die Analyse der Zeit zwischen Zahlungsabwicklung und Verrechnung ist wichtig für Treasury und Liquiditätsmanagement.
Woher erhalten
Diese Information wird aus den Bankabstimmungsmodulen abgeleitet. Sie wird abgeleitet, sobald eine der Zahlung entsprechende Bankkontozeile in D365 abgeglichen und gebucht wird.
Erfassen
Erfordert die Verknüpfung von Banktransaktionsdaten (BankStmtISOAccountStatement) mit der ursprünglichen Zahlung.
Ereignistyp
inferred
|
|||
|
Zahlung terminiert
|
Die gebuchte Rechnung wird ausgewählt und in einen Zahlungsvorschlag oder ein Zahlungsjournal aufgenommen, wodurch sie für einen zukünftigen Zahlungsdurchlauf eingeplant wird. Dies signalisiert die Absicht zur Zahlung. | ||
|
Warum es wichtig ist
Diese Aktivität ist entscheidend für die Cashflow-Prognose und die Analyse der Einhaltung von Zahlungszielen. Sie hilft zu erkennen, ob Skonti berücksichtigt und eingeplant werden.
Woher erhalten
Abgeleitet aus der Erstellung einer Zahlungsjournzeile (LedgerJournalTrans), die die Rechnung enthält. Das Transaktionsdatum auf der Journzeile gibt das geplante Zahlungsdatum an.
Erfassen
Verwenden Sie das Erstellungsdatum der Zahlungsjournalzeile, die sich auf die Rechnung bezieht.
Ereignistyp
inferred
|
|||