Ihr Daten-Template für den Purchase-to-Pay-Prozess bei Bestellungen

Microsoft Dynamics 365
Ihr Daten-Template für den Purchase-to-Pay-Prozess bei Bestellungen

Ihr Daten-Template für den Purchase-to-Pay-Prozess bei Bestellungen

Dieses Template bietet einen klaren Leitfaden zur Erfassung der wichtigsten Daten für die Optimierung Ihres Purchase-to-Pay-Prozesses bei Bestellungen. Es beschreibt die erforderlichen Attribute und Aktivitäten und enthält praktische Hinweise dazu, wie Sie diese Informationen aus Ihrem Quellsystem extrahieren. So stellen Sie sicher, dass Ihre Daten für eine umfassende Prozessanalyse bereitstehen.
  • Empfohlene Attribute für die Datenerfassung
  • Wichtige Aktivitäten für die Prozessabbildung
  • Praktische Hinweise zur Datenextraktion
Neu bei Event Logs? Erfahren Sie, wie Sie ein Event Log für Process Mining erstellen.

Attribute für den Purchase-to-Pay-Prozess bei Bestellungen

Diese Datenfelder sollten Sie in Ihr Event Log aufnehmen, um den Purchase-to-Pay-Prozess bei Bestellungen umfassend zu analysieren.
5 Erforderlich 5 Empfohlen 9 Optional
Name Beschreibung
Aktivitätsname
ActivityName
Name des konkreten Geschäftsereignisses oder Prozessschritts im Bestellablauf.
Beschreibung

Dieses Attribut beschreibt einen einzelnen Schritt im Bestellprozess, zum Beispiel „Bestellung erstellt“, „Bestellung genehmigt“ oder „Wareneingang gebucht“. Die Abfolge dieser Aktivitäten bildet den Prozessablauf jeder Bestellung.

Die Analyse der Aktivitäten ist ein Kernbestandteil des Process Mining. Sie ermöglicht die Visualisierung des Prozessmodells, das Erkennen von Prozessvarianten und das Auffinden häufig wiederholter oder verzögernder Aktivitäten. Um den Prozess zu optimieren, müssen die Reihenfolge und Häufigkeit der Aktivitäten bekannt sein.

Warum das wichtig ist

Dieses Attribut ist unverzichtbar, um das Prozessmodell zu erstellen und die Abfolge der Ereignisse im Bestellprozess zu verstehen.

Woher beziehen

Abgeleitet aus der Geschäftslogik anhand von Statusänderungen in Tabellen wie PurchTable und PurchReqTable sowie zugehörigen Buchungsjournalen wie VendPackingSlipJour oder VendInvoiceJour.

Beispiele
Bestellung erstelltBestellung genehmigtWareneingang gebuchtBestellung fakturiert
Bestellung
PurchaseOrderNumber
Eindeutige Kennung der Bestellung, die als zentraler Case für die Prozessanalyse dient.
Beschreibung

Die Bestellnummer ist die zentrale Kennung, über die alle zugehörigen Aktivitäten verknüpft werden, vom ersten Entwurf bis zum endgültigen Abschluss oder zur Stornierung. Jede eindeutige Nummer steht für einen einzelnen Bestellprozess.

Beim Process Mining dient dieses Attribut dazu, den gesamten Ablauf jeder Bestellung zu rekonstruieren. Die Analyse anhand dieser Kennung zeigt den vollständigen Prozessverlauf und hilft, typische Abläufe, Abweichungen und Engpässe einzelner Bestellungen zu erkennen.

Warum das wichtig ist

Diese grundlegende Kennung ermöglicht es, den Prozessablauf zu rekonstruieren und den Weg jeder Bestellung von Anfang bis Ende zu analysieren.

Woher beziehen

Dies ist der Primärschlüssel in der Bestellkopftabelle, in Microsoft Dynamics 365 üblicherweise PurchTable mit dem Feldnamen PurchId.

Beispiele
PO-001245PO-001246PO-001247
Ereigniszeitpunkt
EventTime
Genaues Datum und genaue Uhrzeit, zu denen eine bestimmte Aktivität oder ein Ereignis stattgefunden hat.
Beschreibung

Dieser Zeitstempel hält fest, wann die einzelnen Aktivitäten im Bestellprozess stattgefunden haben. Er bildet die zeitliche Grundlage des Prozesses und ermöglicht es, die Ereignisse korrekt zu ordnen.

Bei der Prozessanalyse sind Ereigniszeitstempel unverzichtbar, um Durchlaufzeiten, Zeitspannen zwischen Aktivitäten und die Gesamtdauer eines Cases zu berechnen. Sie helfen, Engpässe zu erkennen, die Leistung anhand von SLAs zu messen und den zeitlichen Verlauf des Prozesses zu verstehen. So lässt sich beispielsweise die Zeit zwischen „Bestellung erstellt“ und „Bestellung genehmigt“ berechnen.

Warum das wichtig ist

Zeitstempel sind entscheidend für die Berechnung aller zeitbasierten Leistungskennzahlen, etwa Durchlaufzeiten und Zeitspannen. Diese Kennzahlen helfen, Engpässe im Prozess zu erkennen.

Woher beziehen

Extrahiert aus verschiedenen Datums- und Zeitfeldern in mehreren Tabellen, zum Beispiel aus CreatedDateTime in der PurchTable oder aus Buchungsdaten zugehöriger Journale.

Beispiele
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-11-05T09:12:00Z
Letzte Datenaktualisierung
LastDataUpdate
Zeitstempel der letzten Aktualisierung der Daten zu diesem Prozess.
Beschreibung

Dieses Attribut enthält Datum und Uhrzeit der letzten Datenextraktion aus dem Quellsystem. Es gibt Aufschluss darüber, wie aktuell die analysierten Daten sind.

Anhand des Zeitpunkts der letzten Aktualisierung können Benutzer beurteilen, ob sie mit den neuesten Prozessdaten arbeiten. Das hilft, die Aussagekraft der Analyse einzuschätzen und regelmäßige Datenaktualisierungen zu planen.

Warum das wichtig ist

Macht transparent, wie aktuell die Daten sind, damit Benutzer den Aktualitätsstand ihrer Prozessanalyse einschätzen können.

Woher beziehen

Dieses Metadatenattribut wird bei der Datenübernahme erzeugt und gespeichert.

Beispiele
2024-05-21T05:00:00Z
Quellsystem
SourceSystem
Gibt an, aus welchem System die Daten extrahiert wurden.
Beschreibung

Dieses Attribut bezeichnet die Quellanwendung der Bestelldaten. In diesem Datenmodell lautet der Wert in der Regel „Microsoft Dynamics 365“.

In größeren Unternehmen können Beschaffungsprozesse mehrere Systeme umfassen. Dieses Attribut unterstützt die Datenverwaltung und macht die Herkunft der Daten nachvollziehbar. Das ist besonders wichtig, wenn Daten aus verschiedenen Quellen zusammengeführt werden.

Warum das wichtig ist

Gibt wichtigen Aufschluss über die Herkunft der Daten. Das ist für die Datenverwaltung und Validierung sowie für das Verständnis der technischen Systemlandschaft des Prozesses entscheidend.

Woher beziehen

Dieser statische Wert wird bei der Datenextraktion und -transformation hinzugefügt, um den Datensatz zu kennzeichnen.

Beispiele
Microsoft Dynamics 365 F&OD365
Bestellstatus
PurchaseOrderStatus
Aktueller Status der Bestellung im Prozessverlauf.
Beschreibung

Dieses Attribut gibt den Gesamtstatus der Bestellung zu einem bestimmten Zeitpunkt an, zum Beispiel „Offene Bestellung“, „Eingegangen“, „Fakturiert“ oder „Storniert“. Er entspricht dem Ergebnis der letzten Aktivität.

Der Status zeigt, welche Bestellungen derzeit noch offen sind. Beim Process Mining lässt er sich zur Analyse der Ergebnisse von Cases verwenden. So können Sie beispielsweise alle stornierten Bestellungen filtern und die Gründe dafür untersuchen.

Warum das wichtig ist

Zeigt den aktuellen Status der Bestellung. Das ist hilfreich, um Cases zu filtern und Prozessergebnisse wie Abschluss- oder Stornierungsquoten zu analysieren.

Woher beziehen

In der PurchTable zu finden. Die wichtigsten Statusfelder sind DocumentState und PurchStatus.

Beispiele
Offene BestellungEingegangenFakturiertStorniert
Gesamtbetrag der Bestellung
PurchaseOrderTotalAmount
Gesamtwert der Bestellung in Geld.
Beschreibung

Dieses Attribut gibt die Gesamtkosten aller in der Bestellung enthaltenen Waren und Dienstleistungen an. Es ist eine wichtige finanzielle Kennzahl für den Beschaffungsprozess.

Die Analyse nach Bestellwert kann wichtige Erkenntnisse liefern. Bestellungen mit höherem Wert durchlaufen beispielsweise möglicherweise einen anderen, strengeren Genehmigungsprozess oder haben längere Durchlaufzeiten. Der Gesamtbetrag wird auch für die Finanzberichterstattung und zur Einteilung von Bestellungen in Wertklassen für die Analyse verwendet.

Warum das wichtig ist

Ermöglicht die finanzielle Analyse des Beschaffungsprozesses und zeigt, wie sich der Bestellwert auf den Prozess auswirkt, etwa auf Genehmigungszeiten und -wege.

Woher beziehen

Der Wert lässt sich aus der PurchLine berechnen, indem die LineAmount-Werte für eine PurchId summiert werden. Alternativ ist er in Betragsfeldern auf Kopfebene in der PurchTable zu finden.

Beispiele
5250.00120.50150000.00
Gewünschtes Lieferdatum
RequestedDeliveryDate
Datum, zu dem das Unternehmen die Lieferung der Waren oder Dienstleistungen vom Lieferanten angefordert hat.
Beschreibung

Dieses Datum wird in der Bestellung angegeben und teilt dem Lieferanten den gewünschten Liefertermin mit. Es dient als Grundlage für die Messung der Lieferantenleistung.

Dieses Attribut ist wichtig für das Dashboard „Liefertermintreue der Lieferanten“ und die KPI „Termingerechte Lieferung“. Durch den Vergleich von RequestedDeliveryDate mit dem tatsächlichen Wareneingangsdatum lässt sich die Zuverlässigkeit der Lieferanten messen und wiederkehrende Verzögerungen in der Lieferkette erkennen.

Warum das wichtig ist

Dient als Grundlage für die Messung der Termintreue, einer wichtigen KPI zur Bewertung der Zuverlässigkeit von Lieferanten und der Effizienz der Lieferkette.

Woher beziehen

Typischerweise als DeliveryDate in PurchTable (Kopfebene) oder PurchLine (Positionsebene) zu finden.

Beispiele
2023-11-152023-12-012024-01-20
Lieferantenname
VendorName
Name des Lieferanten, für den die Bestellung erstellt wird.
Beschreibung

Dieses Attribut enthält den Namen des externen Lieferanten, der Waren oder Dienstleistungen bereitstellt. Es ist eine wichtige Dimension für die Analyse der Beschaffung.

Die Aufschlüsselung des Prozesses nach Lieferantenname ist entscheidend für die Bewertung der Lieferantenleistung. So lassen sich für jeden Lieferanten die Termintreue, Rücksendequoten und Ergebnisse von Qualitätsprüfungen analysieren. Das hilft, zuverlässige Partner und Lieferanten mit Verzögerungen oder Qualitätsproblemen zu erkennen.

Warum das wichtig ist

Dieses Attribut ist wichtig für das Lieferantenmanagement. Es ermöglicht, Lieferzeiten, Rücksendequoten und die Zuverlässigkeit der einzelnen Lieferanten zu analysieren.

Woher beziehen

Das Lieferantenkonto ist in der PurchTable im Feld OrderAccount gespeichert. Der Name wird durch Verknüpfung mit der VendTable abgerufen.

Beispiele
Contoso-BürobedarfFabrikam-RobotikNorthwind-Handel
Name
UserName
Name des Benutzers, der eine bestimmte Aktivität ausgeführt hat.
Beschreibung

Dieses Attribut bezeichnet die Person, die für ein Ereignis verantwortlich war, etwa für das Erstellen, Genehmigen oder Ändern einer Bestellung. Es kann sich um eine Benutzer-ID oder einen vollständigen Namen handeln.

Die Analyse der Benutzeraktivitäten zeigt, wie die Arbeitslast verteilt ist, wo Schulungsbedarf besteht und welche Personen oder Teams an Prozessabweichungen beteiligt sind. Sie ist für Dashboards zur Leistung von Genehmigenden wichtig und ermöglicht es, den Prozess nach Aktivitäten bestimmter Benutzer zu filtern.

Warum das wichtig ist

Ermöglicht die Leistungsanalyse nach Benutzern, hilft bei der Erkennung personenbezogener Engpässe und schafft Verantwortlichkeit für einzelne Prozessschritte.

Woher beziehen

Das Attribut ist in Feldern wie CreatedBy oder ModifiedBy in Tabellen wie der PurchTable zu finden. Benutzerdetails sind üblicherweise in der Tabelle UserInfo gespeichert.

Beispiele
Alice JohnsonBob WilliamsSystemadministrator
Abteilung
DepartmentName
Name der Abteilung, die die Bedarfsmeldung oder Bestellung veranlasst hat.
Beschreibung

Dieses Attribut bezeichnet die interne Geschäftseinheit oder Abteilung, die für die Beschaffung verantwortlich ist. Es wird häufig aus den Angaben zur Person abgeleitet, die die Bedarfsmeldung erstellt hat.

Die Analyse nach Abteilungen zeigt, wie die verschiedenen Bereiche des Unternehmens den Beschaffungsprozess nutzen. Sie kann Abteilungen mit längeren Genehmigungszyklen, häufigeren Bestelländerungen oder bestimmten Beschaffungsmustern aufdecken. So lassen sich gezielte Verbesserungen anstoßen.

Warum das wichtig ist

Ermöglicht den Vergleich der Prozessleistung zwischen Geschäftseinheiten und hilft, abteilungsspezifische Verhaltensweisen, Engpässe und Ineffizienzen zu erkennen.

Woher beziehen

Diese Information wird häufig über den Anfordernden oder Ersteller der Bedarfsmeldung (PurchReqTable) beziehungsweise der Bestellung (PurchTable) und die zugehörige Abteilung im HR-Modul verknüpft.

Beispiele
FinanzenITFertigungMarketing
Bedarfsmeldung
PurchaseRequisitionNumber
Kennung der Bedarfsmeldung, die der Bestellung vorausging.
Beschreibung

Dieses Attribut verknüpft eine Bestellung mit der ursprünglichen internen Anforderung, der Bedarfsmeldung. Nicht alle Bestellungen gehen auf eine Bedarfsmeldung zurück.

Diese Verknüpfung ist wichtig für die Analyse des gesamten Prozesses von der Bedarfsmeldung bis zur Bestellung. Sie ermöglicht die Messung der KPI „Umwandlungszeit von der Bedarfsmeldung zur Bestellung“ und zeigt, wie schnell ein interner Bedarf in eine externe Bestellung überführt wird. Außerdem unterstützt sie die Compliance-Analyse, etwa indem Bestellungen ohne formelle Bedarfsmeldung erkannt werden.

Warum das wichtig ist

Verknüpft die Bestellung mit der ursprünglichen Anforderung. So lassen sich die Durchlaufzeit von der Bedarfsmeldung bis zur Bestellung analysieren und die Einhaltung des Prozesses prüfen.

Woher beziehen

In der PurchLine im Feld PurchReqId zu finden, das auf die PurchReqTable verweist.

Beispiele
PR-000871PR-000872PR-000873
Einkaufskategorie
PurchaseCategory
Die Klassifizierung des gekauften Artikels oder der Dienstleistung, zum Beispiel „IT-Hardware“ oder „Bürobedarf“.
Beschreibung

Mit diesem Attribut lassen sich Bestellpositionen in sinnvolle Kategorien einteilen. Die Klassifizierung hilft dabei, Ausgabenmuster und Prozessabweichungen bei verschiedenen Beschaffungsarten zu analysieren.

In der Prozessanalyse können Sie nach Einkaufskategorie filtern, um unterschiedliche Abläufe sichtbar zu machen. So kann die Beschaffung von Investitionsgütern länger und komplexer sein als die von Betriebsmitteln. Dashboards verwenden diese Angabe, um Änderungen und Rücksendungen nach Kategorie auszuwerten.

Warum das wichtig ist

Ermöglicht die Aufschlüsselung des Prozesses nach Art der gekauften Waren oder Dienstleistungen. So werden unterschiedliche Prozessabläufe je Ausgabenkategorie sichtbar.

Woher beziehen

Artikelkategorien sind den freigegebenen Produkten (InventTable) zugeordnet, die anschließend in PurchLine verwendet werden. Die Kategorieinformationen selbst sind in den Tabellen der Kategorienverwaltung gespeichert.

Beispiele
IT-HardwareBürobedarfProfessionelle DienstleistungenRohstoffe
Lieferort
DeliveryLocation
Der konkrete Standort, das Lager oder die Adresse, an die die Waren geliefert werden sollen.
Beschreibung

Dieses Attribut gibt den physischen Lieferort der Bestellpositionen an. Dabei kann es sich um ein Lager, ein bestimmtes Büro oder einen Projektstandort handeln.

Die Analyse nach Lieferort kann regionale oder standortspezifische Engpässe aufdecken, insbesondere beim Wareneingang. Das Dashboard „Bearbeitungszeit des Wareneingangs“ kann diese Angabe verwenden, um die Effizienz an verschiedenen Standorten zu vergleichen.

Warum das wichtig ist

Hilft, standortspezifische Prozessabweichungen oder Verzögerungen zu erkennen, insbesondere beim Wareneingang und bei der Qualitätsprüfung.

Woher beziehen

Lieferadresse und Standortinformationen sind in PurchTable gespeichert und können aus den Unternehmens- oder Lieferanteneinstellungen übernommen werden.

Beispiele
Hauptlager ABüro, Gebäude CVerteilzentrum Westküste
Name der genehmigenden Person
ApproverName
Der Name des Benutzers, der die Bestellung oder einen Schritt im Genehmigungs-Workflow genehmigt hat.
Beschreibung

Dieses Attribut bezeichnet die Führungskraft oder den Benutzer, der die Bestellung formell genehmigt und damit zur weiteren Bearbeitung freigegeben hat. Bei mehrstufigen Genehmigungs-Workflows kann es für eine Bestellung mehrere genehmigende Personen geben.

Die Erfassung der genehmigenden Person ist eine wichtige Grundlage für die Dashboards „Analyse der Genehmigungsdauer von Bestellungen“ und „Kennzahlen zur Leistung genehmigender Personen“. Damit lässt sich messen, wie lange die einzelnen Personen für eine Genehmigung benötigen. Außerdem werden Engpässe in der Genehmigungskette sichtbar und Sie können Arbeitslast und Effizienz beurteilen.

Warum das wichtig ist

Ermöglicht die Analyse des Genehmigungsprozesses. So lassen sich Engpässe erkennen und Leistung sowie Arbeitslast der verschiedenen genehmigenden Personen messen.

Woher beziehen

Genehmigungsinformationen werden in der Regel in Tabellen zur Workflow-Nachverfolgung gespeichert, nicht direkt in PurchTable. Dafür muss der mit der Bestellung verknüpfte Workflow-Verlauf abgefragt werden.

Beispiele
Charles GreenDiana PrinceEdward Nigma
Pünktliche Lieferung?
IsOnTimeDelivery
Ein boolesches Kennzeichen, das angibt, ob die Waren am angeforderten Liefertermin oder früher eingegangen sind.
Beschreibung

Dieses berechnete Attribut vergleicht den Timestamp der Aktivität „Wareneingang gebucht“ mit RequestedDeliveryDate. Es erhält den Wert „true“, wenn der Wareneingang am angeforderten Termin oder früher erfolgt ist.

Das Kennzeichen fließt direkt in die Berechnung des KPI „Pünktliche Lieferquote“ ein. Es vereinfacht die Analyse der Lieferantenleistung und ermöglicht es, pünktliche und verspätete Lieferungen einfach zu filtern und darzustellen. Das ist eine zentrale Grundlage für das Dashboard „Einhaltung der Liefertermine durch Lieferanten“.

Warum das wichtig ist

Liefert ein eindeutiges Ergebnis zur Lieferleistung und vereinfacht so die Berechnung von KPIs zur Pünktlichkeit und von Lieferantenbewertungen.

Woher beziehen

Dieses berechnete Attribut ergibt sich aus dem Vergleich von RequestedDeliveryDate mit EventTime der Aktivität „Wareneingang gebucht“.

Beispiele
truefalse
Rücksendegrund
ReturnReason
Der Grund, der angegeben wird, wenn Waren aus einer Bestellung an den Lieferanten zurückgesendet werden.
Beschreibung

Wenn die Aktivität „Waren an Lieferanten zurückgesendet“ auftritt, erfasst dieses Attribut die Begründung für die Rücksendung, zum Beispiel „Transportschaden“, „Falscher Artikel“ oder „Mangelhafte Qualität“.

Diese Daten sind für das Dashboard „Rücksendungsquote bei Bestellungen“ besonders wertvoll. Die Analyse der Rücksendegründe hilft, Ursachen zu ermitteln, etwa die Qualität des Lieferanten, interne Bestellfehler oder Probleme beim Versand. Auf dieser Grundlage können Sie gezielte Maßnahmen ergreifen, um die Rücksendequote zu senken.

Warum das wichtig ist

Zeigt, warum Waren zurückgesendet werden, und hilft dabei, Probleme mit der Lieferantenqualität, der Bestellgenauigkeit oder der Logistik zu erkennen.

Woher beziehen

Rücksendegründe werden üblicherweise in Rücksendeaufträgen oder über Ursachencodes zu negativen Wareneingangsbuchungen erfasst.

Beispiele
Während des Transports beschädigtFalscher Artikel geliefertQualitätsprüfung nicht bestanden
Unternehmenscode
CompanyCode
Die Kennung der juristischen Person oder des Unternehmens, das die Bestellung aufgibt.
Beschreibung

In einer Umgebung mit mehreren Unternehmen gibt dieses Attribut an, welche juristische Person den Einkauf tätigt. Es handelt sich um eine zentrale Organisationsangabe.

Damit können Sie den P2P-Prozess verschiedener juristischer Personen innerhalb derselben Organisation vergleichen. So werden Unterschiede bei Prozesseffizienz, Compliance und Lieferantenmanagement sichtbar, was die Standardisierung unterstützt.

Warum das wichtig ist

Für Organisationen mit mehreren juristischen Personen unverzichtbar, um den Beschaffungsprozess zwischen diesen zu vergleichen und zu standardisieren.

Woher beziehen

Dies ist das Feld DataAreaId, das in Dynamics 365 in nahezu jeder Tabelle vorhanden ist, auch in PurchTable.

Beispiele
USMFDEMFGBSI
Wurde die Bestellung geändert?
IsPurchaseOrderChanged
Ein boolesches Kennzeichen, das angibt, ob die Bestellung nach ihrer ersten Genehmigung geändert wurde.
Beschreibung

Dieses berechnete Attribut erhält den Wert „true“, wenn bei einem Case nach der Aktivität „Bestellung genehmigt“ die Aktivität „Bestellung geändert“ auftritt. Damit lässt sich Nacharbeit und Änderungen einfacher analysieren.

Das Kennzeichen ist entscheidend für die Berechnung des KPI „Änderungsquote von Bestellungen nach der Genehmigung“ und für das Dashboard „Trends bei Bestelländerungen“. Es ermöglicht, Bestellungen mit Nacharbeit gezielt herauszufiltern und zu analysieren, um die Ursachen solcher Änderungen zu ermitteln.

Warum das wichtig ist

Vereinfacht die Messung von Nacharbeit und Änderungshäufigkeit, wichtigen Indikatoren für Prozessinstabilität und Ineffizienz.

Woher beziehen

Dieses berechnete Attribut wird aus der Abfolge der Aktivitäten im Event Log abgeleitet.

Beispiele
truefalse
Erforderlich Empfohlen Optional

Aktivitäten im Purchase-to-Pay-Prozess bei Bestellungen

Diese wichtigen Prozessschritte und Meilensteine sollten Sie in Ihrem Event Log erfassen, damit Sie den Prozess präzise entdecken und optimieren können.
6 Empfohlen 8 Optional
Aktivität Beschreibung
Bedarfsmeldung erstellt
Diese Aktivität kennzeichnet die Erstellung einer Bedarfsmeldung, also der formellen Anforderung von Waren oder Dienstleistungen. Sie wird erfasst, wenn ein neuer Datensatz in der Tabelle für Bedarfsmeldungen angelegt wird. Damit beginnt der Beschaffungsbedarf.
Warum das wichtig ist

Dies ist der erste Auslöser des Bestellprozesses. Die Zeitspanne zwischen diesem Ereignis und der Erstellung der Bestellung zeigt, wie effizient der interne Prozess ist und wie schnell er auf den Bedarf reagiert.

Woher beziehen

Dieses Ereignis entspricht der Erstellung eines Datensatzes in der PurchReqTable. Der Erstellungszeitstempel (createdDateTime) des Datensatzes gibt den Ereigniszeitpunkt an.

Erfassung

Extrahieren Sie für jede Bedarfsmeldung den Erstellungszeitstempel aus der PurchReqTable.

Ereignistyp explicit
Bestellung abgeschlossen
Dieses Ereignis kennzeichnet den erfolgreichen Abschluss des Bestellprozesses, wenn alle Waren eingegangen und fakturiert sind. Es wird in der Regel abgeleitet, wenn der Bestellstatus auf einen endgültigen, abgeschlossenen Status gesetzt wird.
Warum das wichtig ist

Diese Aktivität markiert das Ende eines erfolgreich abgeschlossenen Prozessfalls. Die Messung der „Gesamtdurchlaufzeit der Bestellung“ von der Erstellung bis zum Abschluss gibt Aufschluss über die Prozesseffizienz.

Woher beziehen

Das Ereignis lässt sich aus den Statusfeldern in der PurchTable ableiten, etwa wenn DocumentState den Status „Fakturiert“ hat und die Statusangaben der Positionen den vollständigen Wareneingang und die vollständige Fakturierung anzeigen.

Erfassung

Ermitteln Sie den Zeitstempel, zu dem die Statusangaben im Bestellkopf und in den Positionen auf einen endgültigen, abgeschlossenen Status gesetzt werden, zum Beispiel „Fakturiert“.

Ereignistyp inferred
Bestellung an Lieferanten gesendet
Diese Aktivität zeigt an, dass die genehmigte Bestellung an den Lieferanten übermittelt wurde. Sie wird erfasst, wenn die Bestellung bestätigt wird. Dabei wird ein Bestätigungsjournal erstellt und das Dokument in der Regel versendet.
Warum das wichtig ist

Dies ist der erste Schritt mit Außenwirkung und der Beginn der Lieferzeit des Lieferanten. Der Zeitpunkt ist wichtig, um die Lieferantenleistung und die KPI „Termingerechte Lieferung“ zu verfolgen.

Woher beziehen

Das Ereignis wird durch die Erstellung eines Datensatzes in der Tabelle PurchPurchaseOrderJour (Bestellbestätigungsjournal) gekennzeichnet. Das Erstellungsdatum dieses Journals dient als Zeitstempel der Aktivität.

Erfassung

Verwenden Sie den Erstellungszeitstempel des ersten PurchPurchaseOrderJour-Datensatzes zur Bestellung.

Ereignistyp explicit
Bestellung erstellt
Diese Aktivität kennzeichnet die Erstellung eines Bestellentwurfs im System. Sie wird anhand des Erstellungszeitstempels des Bestellkopfs erfasst und folgt häufig auf eine genehmigte Bedarfsmeldung.
Warum das wichtig ist

Damit wird aus einer internen Anforderung ein formelles Beschaffungsdokument. Dieser Zeitpunkt ist ein wichtiger Ausgangspunkt für die Messung der Bearbeitungs- und Freigabezeiten von Bestellungen.

Woher beziehen

Dieses Ereignis entspricht der Erstellung eines Datensatzes in der PurchTable. Das Feld createdDateTime dieser Tabelle enthält den Zeitstempel der Aktivität.

Erfassung

Extrahieren Sie für jede Bestellung den Erstellungszeitstempel aus der PurchTable.

Ereignistyp explicit
Bestellung genehmigt
Dieses Ereignis kennzeichnet die endgültige Genehmigung der Bestellung. Danach darf sie an den Lieferanten gesendet werden. Es wird in der Regel aus einer Statusänderung der Bestellung abgeleitet oder direkt im Workflow-Verlauf erfasst.
Warum das wichtig ist

Dies ist ein wichtiger Meilenstein, denn vor der Genehmigung sind keine weiteren Schritte möglich. Er ist entscheidend, um Engpässe bei der Freigabe zu analysieren und die KPI „Freigabezeit der Bestellung“ zu messen.

Woher beziehen

Das Ereignis lässt sich aus einer Änderung des Felds DocumentState in der PurchTable in den Status „Genehmigt“ ableiten. Alternativ kann der Abschlusszeitstempel des letzten Genehmigungsschritts in der WorkflowTrackingStatusTable verwendet werden.

Erfassung

Ermitteln Sie den Zeitstempel, zu dem DocumentState in der PurchTable in den Status „Genehmigt“ wechselt.

Ereignistyp inferred
Wareneingang gebucht
Dieses Ereignis kennzeichnet die offizielle Erfassung der zur Bestellung eingegangenen Waren im System. Es wird erfasst, wenn ein Produktzugangsjournal gebucht wird.
Warum das wichtig ist

Dieser wichtige Meilenstein aktualisiert den Bestand und markiert den Beginn des Rechnungsabgleichs. Er ist der Endpunkt für die Messung der „Termingerechten Lieferung“ und der Lieferzeit des Lieferanten.

Woher beziehen

Das Ereignis wird bei der Erstellung des Produktzugangsjournals in VendPackingSlipJour erfasst. createdDateTime oder PackingSlipDate in dieser Tabelle gibt an, wann der Wareneingang offiziell verbucht wurde.

Erfassung

Verwenden Sie den Erstellungs- oder Buchungszeitstempel des mit der Bestellung verknüpften VendPackingSlipJour-Datensatzes.

Ereignistyp explicit
Bedarfsmeldung genehmigt
Dieses Ereignis steht für die formelle Genehmigung einer Bedarfsmeldung durch eine dazu berechtigte Führungskraft. Es wird in der Regel anhand der Workflow-Verlaufsprotokolle oder einer Statusänderung des Bedarfsmeldungsdatensatzes erfasst.
Warum das wichtig ist

Die Genehmigung ist ein wichtiger Meilenstein, denn erst danach kann die Bedarfsmeldung in eine Bestellung umgewandelt werden. Verzögerungen an dieser Stelle wirken sich direkt auf den gesamten Beschaffungszeitplan aus.

Woher beziehen

Das Ereignis lässt sich aus der WorkflowTrackingStatusTable zur Bedarfsmeldung erfassen. Alternativ kann es aus einer Änderung des Statusfelds in der PurchReqTable in den Status „Genehmigt“ abgeleitet werden.

Erfassung

Verwenden Sie den Abschlusszeitstempel des letzten Genehmigungsschritts im Workflow-Verlauf der Bedarfsmeldung.

Ereignistyp explicit
Bestellung fakturiert
Diese Aktivität kennzeichnet den Zeitpunkt, an dem eine Lieferantenrechnung eingeht und der Bestellung zugeordnet gebucht wird. Damit sind Beschaffungs- und Zahlungsprozess miteinander verknüpft.
Warum das wichtig ist

Dies ist der letzte Schritt vor der Zahlung und entscheidend für die Berechnung der endgültigen Beschaffungskosten. Zugleich bildet er den Endpunkt für die Analyse des Drei-Wege-Abgleichs.

Woher beziehen

Das Ereignis wird bei der Buchung eines Lieferantenrechnungsjournals (VendInvoiceJour) erfasst, das der Bestellung zugeordnet ist. InvoiceDate oder das Buchungsdatum dieses Datensatzes dient als Zeitstempel.

Erfassung

Verwenden Sie den Buchungszeitstempel aus der VendInvoiceJour-Tabelle, die mit dem PurchTable-Datensatz verknüpft ist.

Ereignistyp explicit
Bestellung geändert
Diese Aktivität erfasst alle Änderungen an einer Bestellung nach ihrer Genehmigung. Dynamics 365 kann Versionen der Bestellung nachverfolgen, sodass sich Änderungen erkennen lassen.
Warum das wichtig ist

Änderungen zu verfolgen ist wichtig, um Nacharbeit zu erkennen, die Prozessstabilität zu beurteilen und die „Änderungsrate bei Bestellungen“ zu messen. Änderungen können zu Verzögerungen und Kostenabweichungen führen.

Woher beziehen

Das Ereignis lässt sich durch den Vergleich verschiedener Versionen der Bestellung in Archiv- oder Versionsverwaltungstabellen ableiten, zum Beispiel in PurchTableHistory. Eine höhere Versionsnummer weist auf eine Änderung hin.

Erfassung

Ermitteln Sie Datensätze, bei denen die Versionsnummer in der PurchTable nach der Genehmigung erhöht wurde.

Ereignistyp inferred
Bestellung storniert
Dieses Ereignis steht für die Beendigung einer Bestellung, bevor sie vollständig abgewickelt wurde. Es wird durch eine bestimmte Statusänderung im Bestelldokument erfasst.
Warum das wichtig ist

Stornierungen sind ein wichtiger Ausnahmefall. Ihre Häufigkeit und Gründe können auf Probleme bei der Planung oder der Zuverlässigkeit von Lieferanten hinweisen.

Woher beziehen

Das Ereignis lässt sich aus einer Änderung des Felds DocumentState in der PurchTable in den Status „Storniert“ ableiten. Der Zeitstempel dieser Statusänderung kennzeichnet das Ereignis.

Erfassung

Ermitteln Sie den Zeitstempel, zu dem DocumentState in der PurchTable auf „Storniert“ gesetzt wird.

Ereignistyp inferred
Bestellung vom Lieferanten bestätigt
Dieses Ereignis steht für die Bestätigung der Bestelldetails durch den Lieferanten. Häufig werden die Angaben manuell erfasst, nachdem der Lieferant die Bestellung bestätigt hat.
Warum das wichtig ist

Die Bestätigung des Lieferanten zeigt, dass die Bestellung bearbeitet wird. Verzögerungen oder Abweichungen in dieser Phase können auf Probleme bei der Lieferung hindeuten.

Woher beziehen

Das Ereignis lässt sich in der Regel aus dem Befüllen von Datums- oder Statusfeldern zur Bestätigung in der PurchTable ableiten, etwa aus Lieferbestätigungsdaten. Es liegt möglicherweise kein einzelnes, klar abgegrenztes Ereignis vor.

Erfassung

Leiten Sie das Ereignis aus dem Befüllen eines bestimmten Bestätigungsdatumsfelds in der PurchTable oder PurchLine ab.

Ereignistyp inferred
Bestellung zur Genehmigung eingereicht
Dieses Ereignis kennzeichnet den Zeitpunkt, an dem ein Bestellentwurf formell in den Genehmigungs-Workflow eingereicht wird. In der Regel löst der Benutzer diesen Schritt ausdrücklich aus; er wird über Workflow-Protokolle erfasst.
Warum das wichtig ist

Mit dieser Aktivität beginnt offiziell der Genehmigungszyklus der Bestellung. Anhand des Zeitpunkts lässt sich genau messen, wie lange Bestellungen auf die Genehmigung warten und wie lange der gesamte Genehmigungsprozess dauert.

Woher beziehen

Das Ereignis wird in der WorkflowTrackingStatusTable zur Bestellung erfasst. Dort sind die Einreichung und der zugehörige Zeitstempel protokolliert.

Erfassung

Ermitteln Sie das Ereignis „Eingereicht“ im Workflow-Verlauf zum PurchTable-Datensatz.

Ereignistyp explicit
Qualitätsprüfung durchgeführt
Dieses Ereignis steht für den Abschluss einer Qualitätsprüfung der eingegangenen Waren. Die Prüfung wird häufig über das Modul Qualitätsmanagement oder eine Statusaktualisierung verwaltet.
Warum das wichtig ist

Zwischen Wareneingang und Bereitstellung der Waren kann diese Aktivität einen erheblichen Engpass darstellen. Die Analyse ihrer Dauer hilft, die KPI „Durchlaufzeit der Prüfung“ zu verbessern.

Woher beziehen

Das Ereignis lässt sich aus dem Abschluss eines mit dem Wareneingang zur Bestellung verknüpften Qualitätsauftrags (InventQualityOrderTable) ableiten. Der Zeitstempel der Statusänderung in „Bestanden“ oder „Nicht bestanden“ kennzeichnet das Ereignis.

Erfassung

Erfassen Sie den Zeitstempel des Statusabschlusses in der InventQualityOrderTable zur Bestellposition.

Ereignistyp inferred
Waren an Lieferanten zurückgesendet
Dieses Ereignis zeigt an, dass bereits eingegangene Waren wegen Schäden, falscher Artikel oder anderer Probleme an den Lieferanten zurückgesendet wurden. Es wird durch die Buchung einer Rücksendetransaktion erfasst.
Warum das wichtig ist

Rücksendungen weisen auf Prozessprobleme und zusätzliche Kosten hin. Mit dieser Aktivität lässt sich die „Rücksendequote bei Bestellungen“ berechnen und Probleme mit Lieferanten oder Produkten erkennen.

Woher beziehen

Das Ereignis lässt sich aus der Erstellung einer Bestellung mit negativer Menge oder eines speziellen Rücksendedokuments ableiten, das auf die ursprüngliche Bestellung verweist. Der Buchungstag der Rücksendung ist der Ereigniszeitpunkt.

Erfassung

Ermitteln Sie die Buchung einer Rücksendebestellung oder einer Belastungsanzeige zur ursprünglichen Bestellung.

Ereignistyp explicit
Empfohlen Optional

Anleitungen zur Datenextraktion

So exportieren Sie Ihre Daten aus Microsoft Dynamics 365

Möchten Sie loslegen?

Mit diesem Template erhalten Sie alles, was Sie für den Einstieg in die Optimierung Ihres Purchase-to-Pay-Prozesses bei Bestellungen benötigen. Verbessern Sie noch heute Ihre Beschaffungsabläufe.

Steigern Sie jetzt die Effizienz Ihres Purchase-to-Pay-Prozesses bei Bestellungen

Erkennen Sie Ineffizienzen und verkürzen Sie die P2P-Durchlaufzeit um bis zu 30 %.

Starten Sie Ihre kostenlose Testphase

Keine Kreditkarte erforderlich, in wenigen Minuten eingerichtet