Data Template: Einkauf-bis-Zahlung - Bestellung

Microsoft Dynamics 365
Data Template: Einkauf-bis-Zahlung - Bestellung

Ihr Procure-to-Pay-Bestelldaten-Template

Dieses Template bietet einen klaren Fahrplan für die Erfassung der wesentlichen Daten, die zur Optimierung Ihres Purchase-to-Pay- und Bestellprozesses erforderlich sind. Es beschreibt die entscheidenden zu sammelnden Attribute und die wichtigsten zu verfolgenden Aktivitäten und bietet praktische Anleitungen zur Extraktion dieser Informationen aus Ihrem Quellsystem. Nutzen Sie diese Ressource, um sicherzustellen, dass Ihre Daten für eine umfassende Prozessanalyse bereit sind.
  • Empfohlene Attribute zur Erfassung
  • Wichtige Aktivitäten zur Verfolgung für die Prozesskartierung
  • Praktische Anleitung zur Datenextraktion
Neu bei Event Logs? Erfahren Sie wie man ein Process Mining Event Log erstellt.

Beschaffungsprozess - Bestellattribute

Dies sind die empfohlenen Datenfelder, die Sie in Ihr Event Log aufnehmen sollten, um eine umfassende Analyse Ihres Purchase-to-Pay-Prozesses und Bestellprozesses zu ermöglichen.
5 Erforderlich 5 Empfohlen 10 Optional
Name Beschreibung
Aktivitätsname
ActivityName
Der Name des spezifischen Geschäfts-Event oder Schrittes, der innerhalb des Bestelllebenszyklus aufgetreten ist.
Beschreibung

Dieses Attribut beschreibt einen einzelnen Schritt im Bestellprozess, wie z. B. „Bestellung erstellt“, „Bestellung genehmigt“ oder „Wareneingang gebucht“. Die Abfolge dieser Aktivitäten bildet den Prozessfluss für jede Bestellung.

Die Analyse von Aktivitäten ist der Kern des Process Mining. Sie ermöglicht die Visualisierung der Prozesslandkarte, die Entdeckung von Prozessvarianten sowie die Identifizierung von Aktivitäten, die sich häufig wiederholen oder Verzögerungen verursachen. Das Verständnis der Abfolge und Häufigkeit von Aktivitäten ist essenziell für die Prozessoptimierung.

Warum es wichtig ist

Dieses Attribut ist essenziell für den Aufbau der Prozesslandkarte und das Verständnis der Abfolge von Events, die den Bestellprozess-Lebenszyklus bilden.

Woher erhalten

Abgeleitet aus der Geschäftslogik basierend auf Statusänderungen in Tabellen wie PurchTable, PurchReqTable und zugehörigen Buchungsjournalen wie VendPackingSlipJour oder VendInvoiceJour.

Beispiele
Bestellung erstelltBestellung genehmigtWareneingang gebuchtBestellung fakturiert
Bestellung
PurchaseOrderNumber
Die eindeutige Kennung für die Bestellung, die als primärer Case für die Prozessanalyse dient.
Beschreibung

Die Bestellnummer ist der zentrale Identifikator, der alle zugehörigen Aktivitäten verknüpft, vom ersten Entwurf bis zum endgültigen Abschluss oder zur Stornierung. Jede eindeutige Nummer repräsentiert eine einzelne Instanz des Bestellprozesses.

Im Process Mining wird dieses Attribut verwendet, um den End-to-End-Verlauf jeder Bestellung zu rekonstruieren. Die Analyse des Prozesses basierend auf diesem Identifikator ermöglicht eine detaillierte Ansicht des gesamten Lebenszyklus, wodurch gängige Pfade, Abweichungen und Engpässe für einzelne Bestellungen identifiziert werden können.

Warum es wichtig ist

Es ist der grundlegende Schlüssel zur Rekonstruktion des Prozessflusses, der die Analyse des Weges jeder Bestellung von Anfang bis Ende ermöglicht.

Woher erhalten

Dies ist der Primärschlüssel in der Bestellkopf-Tabelle, typischerweise die PurchTable mit dem Feldnamen PurchId in Microsoft Dynamics 365.

Beispiele
PO-001245PO-001246PO-001247
Ereigniszeit
EventTime
Das genaue Datum und die Uhrzeit, zu der eine Aktivität bzw. ein Ereignis stattgefunden hat.
Beschreibung

Dieser Timestamp erfasst, wann jede Aktivität im Bestellprozess stattfand. Er ist das chronologische Rückgrat des Prozesses und ermöglicht die korrekte Reihenfolge der Events.

In der Prozessanalyse sind Event-Timestamps grundlegend für die Berechnung von Durchlaufzeiten, Dauern zwischen Aktivitäten und der gesamten Case-Dauer. Sie werden verwendet, um Engpässe zu identifizieren, die Leistung anhand von SLAs zu messen und die zeitlichen Dynamiken des Prozesses zu verstehen. Zum Beispiel wird er verwendet, um die Zeit zwischen 'Bestellung erstellt' und 'Bestellung genehmigt' zu berechnen.

Warum es wichtig ist

Timestamps sind entscheidend für die Berechnung aller zeitbasierten Leistungs-Kennzahlen, wie Durchlaufzeiten und Dauern, die unerlässlich zur Identifizierung von Prozess-Engpässen sind.

Woher erhalten

Extrahiert aus verschiedenen Datums-/Zeitfeldern über mehrere Tabellen hinweg, wie z.B. CreatedDateTime in PurchTable, oder Buchungsdaten aus zugehörigen Journaltabellen.

Beispiele
2023-10-26T10:00:00Z2023-10-26T14:35:10Z2023-11-05T09:12:00Z
Letzte Datenaktualisierung
LastDataUpdate
Der Timestamp, der angibt, wann die Daten für diesen Prozess zuletzt aktualisiert wurden.
Beschreibung

Dieses Attribut zeichnet das Datum und die Uhrzeit der letzten Datenextraktion aus dem Quellsystem auf. Es liefert Kontext zur Aktualität der analysierten Daten.

Die Kenntnis des letzten Aktualisierungszeitpunkts ist wichtig für Benutzer, um zu verstehen, ob sie die aktuellsten Prozessdaten sehen. Es hilft bei der Bewertung der Relevanz der Analyse und bei der Planung regelmäßiger Datenaktualisierungen.

Warum es wichtig ist

Sorgt für Transparenz über die Aktualität der Daten und ermöglicht es Benutzern, den aktuellen Stand ihrer Prozessanalyse zu kennen.

Woher erhalten

Dies ist ein Metadaten-Attribut, das während des Dateningestionsprozesses generiert und gespeichert wird.

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

Dieses Attribut identifiziert die Quellanwendung, aus der die Bestelldaten stammen. Für dieses Datenmodell ist der Wert typischerweise „Microsoft Dynamics 365“.

In größeren Organisationen können Beschaffungsprozesse mehrere Systeme umfassen. Dieses Attribut unterstützt die Datengovernance und stellt sicher, dass die Herkunft der Daten klar ist, was besonders wichtig ist, wenn Daten aus verschiedenen Quellen zusammengeführt werden.

Warum es wichtig ist

Liefert wesentlichen Kontext zum Ursprung der Daten, was entscheidend für die Data Governance, Validierung und das Verständnis der technologischen Landschaft des Prozesses ist.

Woher erhalten

Dies ist ein statischer Wert, der während des Datenextraktions- und Transformationsprozesses hinzugefügt wird, um den Datensatz zu kennzeichnen.

Beispiele
Microsoft Dynamics 365 F&OD365
Angefordertes Lieferdatum
RequestedDeliveryDate
Das Datum, an dem das Unternehmen den Lieferanten um Lieferung der Waren oder Dienstleistungen gebeten hat.
Beschreibung

Dieses Datum ist auf der Bestellung angegeben und kommuniziert den gewünschten Lieferzeitplan an den Lieferanten. Es dient als Grundlage zur Messung der Lieferantenlieferleistung.

Dieses Attribut ist unerlässlich für das Dashboard 'Lieferantenliefertreue' und den KPI 'Pünktliche Lieferrate'. Durch den Vergleich des RequestedDeliveryDate mit dem tatsächlichen Wareneingangsdatum können Unternehmen die Zuverlässigkeit der Lieferanten quantifizieren und chronische Verzögerungen in der Lieferkette identifizieren.

Warum es wichtig ist

Es ist die Grundlage zur Messung der Liefertermintreue, einer kritischen KPI zur Bewertung der Lieferantenverlässlichkeit und der Effizienz der Lieferkette.

Woher erhalten

Findet sich üblicherweise auf der PurchTable (Kopfebene) oder PurchLine (Positionsebene) als DeliveryDate.

Beispiele
2023-11-152023-12-012024-01-20
Benutzername
UserName
Der Name des Benutzers, der eine spezifische Aktivität durchgeführt hat.
Beschreibung

Dieses Attribut identifiziert die für die Ausführung eines Events verantwortliche Person, wie z. B. die Erstellung, Genehmigung oder Änderung einer Bestellung. Es kann sich um eine System-Benutzer-ID oder einen vollständigen Namen handeln.

Die Analyse der Benutzeraktivität hilft, die Arbeitslastverteilung zu verstehen, Schulungsbedarfe zu identifizieren und Personen oder Teams zu lokalisieren, die an Prozessabweichungen beteiligt sind. Es ist essenziell für Dashboards zur Leistungsanalyse von Genehmigern und kann dazu verwendet werden, den Prozess nach Aktivitäten bestimmter Benutzer zu filtern.

Warum es wichtig ist

Es ermöglicht Leistungsanalysen nach Benutzer, hilft, Bottlenecks im Zusammenhang mit spezifischen Personen zu identifizieren und bietet Verantwortlichkeit für Prozessschritte.

Woher erhalten

Kann in Feldern wie CreatedBy oder ModifiedBy in Tabellen wie PurchTable gefunden werden. Benutzerdetails werden typischerweise in der UserInfo-Tabelle gespeichert.

Beispiele
Alice JohnsonBob WilliamsSysAdmin
Bestellstatus
PurchaseOrderStatus
Der aktuelle Status der Bestellung in ihrem Lebenszyklus.
Beschreibung

Dieses Attribut gibt den Gesamtzustand der Bestellung zu einem bestimmten Zeitpunkt an, z. B. „Offene Bestellung“, „Eingegangen“, „Fakturiert“ oder „Storniert“. Es repräsentiert das Ergebnis der letzten Aktivität.

Die Statusverfolgung ist nützlich, um den aktuellen Zustand aller offenen Bestellungen zu verstehen. Im Process Mining kann sie verwendet werden, um die Ergebnisse von Cases zu analysieren, beispielsweise durch das Filtern nach allen Bestellungen, die im Status „Storniert“ endeten, um die Gründe dafür zu untersuchen.

Warum es wichtig ist

Bietet einen Überblick über den aktuellen Status der Bestellung, was nützlich ist, um Cases zu filtern und Prozessergebnisse zu analysieren, wie z.B. Abschluss- oder Stornierungsraten.

Woher erhalten

Gefunden in der PurchTable. Die primären Statusfelder sind DocumentState und PurchStatus.

Beispiele
Offene BestellungWare erhaltenFakturiertStorniert
Gesamtbestellwert
PurchaseOrderTotalAmount
Der monetäre Gesamtwert der Bestellung.
Beschreibung

Dieses Attribut repräsentiert die Gesamtkosten aller in der Bestellung enthaltenen Artikel und Dienstleistungen. Es ist eine wichtige Finanzkennzahl für den Beschaffungsprozess.

Die Analyse des Prozesses nach dem Gesamtbetrag kann wichtige Erkenntnisse liefern. So können Bestellungen mit höherem Wert einem anderen, strengeren Genehmigungspfad folgen oder längere Durchlaufzeiten aufweisen. Es wird auch in der Finanzberichterstattung und zur Kategorisierung von Bestellungen in Wertbereiche für die Analyse verwendet.

Warum es wichtig ist

Ermöglicht eine Finanzanalyse des Beschaffungsprozesses und hilft dabei zu identifizieren, wie der Auftragswert das Prozessverhalten, wie z.B. Genehmigungszeiten und Pfade, beeinflusst.

Woher erhalten

Dieser Wert kann aus der PurchLine-Tabelle durch Summieren des LineAmount für eine gegebene PurchId berechnet oder in Betragsfeldern auf Kopfebene der PurchTable gefunden werden.

Beispiele
5250.00120.50150000.00
Lieferantenname
VendorName
Der Name des Lieferanten oder Verkäufers, für den die Bestellung erstellt wird.
Beschreibung

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

Die Segmentierung des Prozesses nach Lieferantennamen ist entscheidend für die Bewertung der Lieferantenleistung. Sie ermöglicht die Analyse von Pünktlichkeitsraten, Warenrücksendequoten und Ergebnissen der Qualitätsprüfung für jeden Lieferanten. Dies hilft, zuverlässige Partner und diejenigen zu identifizieren, die Verzögerungen oder Qualitätsprobleme verursachen.

Warum es wichtig ist

Dieses Attribut ist essenziell für das Lieferantenleistungsmanagement, da es die Analyse von Lieferzeiten, Rücksendequoten und der Gesamtzuverlässigkeit pro Lieferant ermöglicht.

Woher erhalten

Das Lieferantenkonto ist in PurchTable (Feld OrderAccount) gespeichert. Der Name wird durch die Verknüpfung mit der VendTable ermittelt.

Beispiele
Contoso Office SuppliesFabrikam RoboticsNorthwind Traders
Abteilung
DepartmentName
Der Name der Abteilung, die die Bestellanforderung oder Bestellung initiiert hat.
Beschreibung

Dieses Attribut identifiziert die interne Geschäftseinheit oder Abteilung, die für den Einkauf verantwortlich ist. Es wird oft von der Person abgeleitet, die die Bestellanforderung erstellt hat.

Die Analyse des Prozesses nach Abteilung ist entscheidend, um zu verstehen, wie verschiedene Organisationseinheiten den Beschaffungsprozess nutzen. Sie kann helfen, Abteilungen mit längeren Genehmigungszyklen, höheren Raten von Bestelländerungen oder spezifischen Einkaufsmustern zu identifizieren. Dies ermöglicht gezielte Prozessverbesserungsinitiativen.

Warum es wichtig ist

Ermöglicht den Vergleich der Prozess-Performance über verschiedene Geschäftsbereiche hinweg und hilft, abteilungsspezifische Verhaltensweisen, Bottlenecks oder Ineffizienzen zu identifizieren.

Woher erhalten

Diese Information ist oft über den Anforderer oder Ersteller der Bestellanforderung (PurchReqTable) oder Bestellung (PurchTable) und deren zugehörige Abteilung im HR-Modul verknüpft.

Beispiele
FinanzenITProduktionMarketing
Bestellanforderung
PurchaseRequisitionNumber
Der Identifikator der Bestellanforderung, die der Bestellung vorausging.
Beschreibung

Dieses Attribut verknüpft eine Bestellung mit der ursprünglichen internen Anfrage, der Bestellanforderung. Nicht alle Bestellungen stammen aus einer Bestellanforderung.

Diese Verknüpfung ist entscheidend für die Analyse des gesamten „Bestellanforderung-zu-Bestellung-Prozesses“. Sie ermöglicht die Messung des KPI „Geschwindigkeit der Bestellanforderung-zu-Bestellung-Konvertierung“ und das Verständnis, wie schnell interne Nachfrage in eine externe Bestellung umgewandelt wird. Sie hilft auch bei der Compliance-Analyse, zum Beispiel durch die Identifizierung von Bestellungen, die ohne formelle Bestellanforderung erstellt wurden.

Warum es wichtig ist

Verknüpft die Bestellung mit der ursprünglichen Anforderung, ermöglicht die Analyse der Durchlaufzeit von der Anforderung bis zur Bestellung und gewährleistet die Compliance des Prozesses.

Woher erhalten

Gefunden in der PurchLine Tabelle, im Feld PurchReqId, das auf die PurchReqTable zurückverweist.

Beispiele
PR-000871PR-000872PR-000873
Buchungskreis
CompanyCode
Der Identifikator für die juristische Person oder das Unternehmen, das die Bestellung aufgibt.
Beschreibung

In einer Mehrmandantenumgebung gibt dieses Attribut an, welche juristische Person den Einkauf tätigt. Dies ist ein grundlegender organisatorischer Datenpunkt.

Dieses Attribut ermöglicht eine vergleichende Analyse des P2P-Prozesses über verschiedene juristische Personen innerhalb derselben Organisation. Es kann Unterschiede in der Prozesseffizienz, Compliance und im Lieferantenmanagement von einem Unternehmen zum anderen aufzeigen und somit Standardisierungsbemühungen unterstützen.

Warum es wichtig ist

Unerlässlich für Multi-Entity-Organisationen, um den Beschaffungsprozess über verschiedene Rechtseinheiten hinweg zu vergleichen und zu standardisieren.

Woher erhalten

Dies ist das DataAreaId-Feld, das auf fast jeder Tabelle in Dynamics 365 vorhanden ist, einschließlich der PurchTable.

Beispiele
USMFDEMFGBSI
Einkaufskategorie
PurchaseCategory
Die Klassifizierung des gekauften Artikels oder der Dienstleistung, wie z.B. 'IT-Hardware' oder 'Büromaterial'.
Beschreibung

Dieses Attribut bietet eine Möglichkeit, Bestellpositionen in logische Kategorien zu gruppieren. Diese Klassifizierung hilft bei der Analyse von Ausgabenmustern und Prozessvariationen über verschiedene Beschaffungsarten hinweg.

In der Prozessanalyse kann das Filtern nach Einkaufskategorie unterschiedliche Verhaltensweisen aufzeigen. So kann der Beschaffungsprozess für Investitionsausgaben länger und komplexer sein als für Betriebsbedarf. Es wird in Dashboards verwendet, um Änderungstrends und Rücksendequoten nach Kategorie zu analysieren.

Warum es wichtig ist

Ermöglicht die Segmentierung des Prozesses nach der Art der gekauften Waren oder Dienstleistungen, wodurch unterschiedliche Prozessverhaltensweisen für verschiedene Ausgabenkategorien aufgedeckt werden.

Woher erhalten

Artikelkategorien sind mit den freigegebenen Produkten (InventTable) verknüpft, die dann in der PurchLine verwendet werden. Die Kategorieinformationen selbst sind in den Kategorieverwaltungstabellen gespeichert.

Beispiele
IT HardwareBürobedarfProfessionelle DienstleistungenRohmaterialien
Freigabe-Durchlaufzeit
ApprovalCycleTime
Die Dauer zwischen der Erstellung einer Bestellung und ihrer endgültigen Genehmigung.
Beschreibung

Diese berechnete Kennzahl misst die verstrichene Zeit von der Aktivität 'Bestellung erstellt' bis zur Aktivität 'Bestellung genehmigt'. Sie ist ein direktes Maß für die Effizienz des Genehmigungs-Workflows.

Dieses Attribut ist die primäre Kennzahl für den KPI 'Durchschnittliche Genehmigungszeit für Bestellungen' und das Dashboard 'Analyse der Genehmigungsdurchlaufzeiten von Bestellungen'. Die Analyse dieser Dauer hilft, Engpässe in der Genehmigungskette zu identifizieren und zu bewerten, ob Genehmigungsprozesse interne Service Level Agreements (SLAs) erfüllen.

Warum es wichtig ist

Misst direkt die Effizienz des Genehmigungs-Workflows, einem häufigen Bereich für Verzögerungen im Beschaffungsprozess.

Woher erhalten

Berechnet durch Ermittlung der Zeitdifferenz zwischen dem EventTime der Aktivitäten 'Bestellung genehmigt' und 'Bestellung erstellt' für jeden Case.

Beispiele
P2DT12H30MPT8HP7D
Genehmigername
ApproverName
Der Name des Benutzers, der die Bestellung oder einen Schritt im Genehmigungs-Workflow genehmigt hat.
Beschreibung

Dieses Attribut identifiziert den Manager oder Benutzer, der die formelle Genehmigung für die Bestellung erteilt hat und somit die Weiterverarbeitung ermöglichte. In mehrstufigen Genehmigungs-Workflows kann es mehrere Genehmiger für eine einzelne Bestellung geben.

Die Verfolgung des Genehmigers ist grundlegend für die Dashboards „Analyse der Durchlaufzeit der Bestellfreigabe“ und „Leistungskennzahlen der Genehmiger“. Sie ermöglicht die Messung, wie lange jeder Genehmiger benötigt, identifiziert Engpässe in der Genehmigungskette und hilft bei der Bewertung der Arbeitslastverteilung und Effizienz.

Warum es wichtig ist

Ermöglicht die Analyse des Genehmigungsprozesses und hilft, Genehmigungs-Bottlenecks zu identifizieren sowie die Performance und Arbeitslast verschiedener Genehmiger zu messen.

Woher erhalten

Genehmigungsinformationen werden typischerweise in Workflow-Tracking-Tabellen gespeichert, nicht direkt in PurchTable. Dies erfordert das Abfragen der Workflow-Historie, die mit der Bestellung verbunden ist.

Beispiele
Charles GreenDiana PrinceEdward Nigma
Ist Bestellung geändert
IsPurchaseOrderChanged
Ein Boolesches Flag, das anzeigt, ob die Bestellung nach ihrer ursprünglichen Genehmigung geändert wurde.
Beschreibung

Dieses berechnete Attribut wird auf 'true' gesetzt, wenn nach der Aktivität 'Bestellung genehmigt' eine Aktivität 'Bestellung geändert' für einen bestimmten Case auftritt. Es vereinfacht die Analyse von Nacharbeit und Änderungen.

Dieser Indikator ist entscheidend für die Berechnung des KPI 'Änderungsrate von Bestellungen nach Genehmigung' und für das Dashboard 'Trends bei Bestellungsänderungen'. Er bietet eine unkomplizierte Möglichkeit, Bestellungen, die Nacharbeit erforderten, zu isolieren und zu analysieren, wodurch die Grundursachen solcher Änderungen identifiziert werden können.

Warum es wichtig ist

Vereinfacht die Messung von Nacharbeit und Änderungsfrequenz, die Schlüsselindikatoren für Prozessinstabilität und Ineffizienz sind.

Woher erhalten

Dies ist ein berechnetes Attribut, das aus der Abfolge der Aktivitäten im Event Log abgeleitet wird.

Beispiele
truefalsch
Ist pünktliche Lieferung
IsOnTimeDelivery
Ein Boolesches Flag, das anzeigt, ob die Waren am oder vor dem angeforderten Lieferdatum eingegangen sind.
Beschreibung

Dieses berechnete Attribut vergleicht den Timestamp der Aktivität 'Wareneingang gebucht' mit dem RequestedDeliveryDate. Es wird auf 'true' gesetzt, wenn das Eingangsdatum am oder vor dem angeforderten Datum liegt.

Dieser Indikator unterstützt direkt die Berechnung des KPI 'Pünktliche Lieferrate'. Er vereinfacht die Analyse der Lieferantenleistung und ermöglicht ein einfaches Filtern und Visualisieren von pünktlichen gegenüber verspäteten Lieferungen, was für das Dashboard 'Lieferantenliefertreue' zentral ist.

Warum es wichtig ist

Liefert ein klares, binäres Ergebnis für die Lieferleistung, was die Berechnung von KPIs zur pünktlichen Lieferung und Lieferanten-Scorecards vereinfacht.

Woher erhalten

Dies ist ein berechnetes Attribut, das durch den Vergleich des RequestedDeliveryDate mit dem EventTime der Aktivität 'Wareneingang gebucht' abgeleitet wird.

Beispiele
truefalsch
Lieferort
DeliveryLocation
Der spezifische Standort, das Lager oder die Adresse, an die die Waren geliefert werden sollen.
Beschreibung

Dieses Attribut gibt den physischen Lieferort für die Artikel der Bestellung an. Dies könnte ein Lager, ein bestimmtes Büro oder eine Projektstätte sein.

Die Analyse des Prozesses nach Lieferort kann helfen, regionale oder standortspezifische Engpässe zu identifizieren, insbesondere im Wareneingangsprozess. Das Dashboard 'Wareneingangs-Bearbeitungszeit' kann dieses Attribut nutzen, um die Effizienz an verschiedenen Standorten zu vergleichen.

Warum es wichtig ist

Hilft, standortspezifische Prozessabweichungen oder Verzögerungen zu identifizieren, insbesondere in den Phasen Wareneingang und Qualitätsprüfung.

Woher erhalten

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

Beispiele
Hauptlager ABürogebäude CDistributionszentrum Westküste
Rückgabegrund
ReturnReason
Der Grund, der angegeben wird, wenn Waren einer Bestellung an den Lieferanten zurückgesendet werden.
Beschreibung

Wenn eine Aktivität 'Waren an Lieferanten zurückgesendet' auftritt, erfasst dieses Attribut die Begründung für die Rücksendung, wie 'Beschädigte Ware', 'Falscher Artikel' oder 'Mangelhafte Qualität'.

Diese Daten sind für das Dashboard zur 'Retourenquote von Bestellungen' von unschätzbarem Wert. Die Analyse der Rücksendegründe hilft, die Ursachen für Retouren zu identifizieren – sei es aufgrund von Lieferantenqualität, internen Bestellfehlern oder Versandproblemen. Dies ermöglicht gezielte Maßnahmen zur Reduzierung der Retourenquote.

Warum es wichtig ist

Gibt Aufschluss darüber, warum Waren zurückgesendet werden, und hilft, Probleme bezüglich Lieferantenqualität, Bestellgenauigkeit oder Logistik zu diagnostizieren.

Woher erhalten

Rückgabegründe werden typischerweise bei Retourenauftragstransaktionen oder über Grundcodes erfasst, die mit negativen Wareneingangsbuchungen verknüpft sind.

Beispiele
TransportschadenFalscher Artikel geliefertFehlgeschlagene Qualitätsprüfung
Erforderlich Empfohlen Optional

Beschaffungsprozess - Bestellaktivitäten

Dies sind die wesentlichen Prozessschritte und Meilensteine, die in Ihrem Event Log zu erfassen sind, um eine präzise Prozessanalyse und Optimierung zu gewährleisten.
6 Empfohlen 8 Optional
Aktivität Beschreibung
Bestellanforderung erstellt
Diese Aktivität kennzeichnet die Erstellung einer Bestellanforderung, also der formellen Anfrage für Waren oder Dienstleistungen. Sie wird erfasst, sobald ein neuer Datensatz in der Bestellanforderungstabelle angelegt wird, was den Beginn der Beschaffungsnachfrage signalisiert.
Warum es wichtig ist

Dies ist der initiale Auslöser für den Bestellprozess. Die Analyse der Zeit von diesem Event bis zur Bestellerstellung hilft, die interne Prozesseffizienz und die Reaktionsfähigkeit auf die Nachfrage zu messen.

Woher erhalten

Dieses Event entspricht der Erstellung eines Datensatzes in der PurchReqTable. Der Erstellungs-Timestamp (createdDateTime) des Datensatzes markiert den Event-Zeitpunkt.

Erfassen

Extrahieren Sie den Erstellungs-Timestamp aus der PurchReqTable für jede Bestellanforderung.

Ereignistyp explicit
Bestellung abgeschlossen
Zeigt den erfolgreichen Abschluss des Bestellprozess-Lebenszyklus an, bei dem alle Waren empfangen und fakturiert wurden. Dies wird typischerweise abgeleitet, wenn der Bestellstatus auf einen finalen, geschlossenen Zustand aktualisiert wird.
Warum es wichtig ist

Diese Aktivität definiert das Ende einer erfolgreichen Prozessinstanz. Die Messung der „Gesamtdurchlaufzeit der Bestellung“ von der Erstellung bis zum Abschluss bietet eine ganzheitliche Sicht auf die Prozesseffizienz.

Woher erhalten

Abgeleitet von den Statusfeldern in der PurchTable, z.B. wenn sowohl der DocumentState 'Invoiced' ist als auch die Positionsstatus den vollständigen Wareneingang und die Rechnungsstellung anzeigen.

Erfassen

Identifizieren Sie den Timestamp, wenn die Kopf- und Zeilenstatus der Bestellung auf einen finalen, geschlossenen Zustand aktualisiert werden (z.B. 'Invoiced').

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, wodurch ein Bestätigungsjournal generiert und typischerweise der Versand des Dokuments ausgelöst wird.
Warum es wichtig ist

Dies ist der erste externe Schritt und beginnt die Messung der Lieferantendurchlaufzeit. Er ist entscheidend für die Verfolgung der Lieferantenleistung und des KPI 'Pünktliche Lieferrate'.

Woher erhalten

Das Event wird durch die Erstellung eines Datensatzes in der PurchPurchaseOrderJour-Tabelle (dem Bestellbestätigungsjournal) markiert. Das Erstellungsdatum dieses Journals dient als Aktivitäts-Timestamp.

Erfassen

Verwenden Sie den creation timestamp des ersten PurchPurchaseOrderJour Datensatzes für die Bestellung.

Ereignistyp explicit
Bestellung erstellt
Diese Aktivität kennzeichnet die Erstellung eines Bestellentwurfs im System. Sie wird über den Erstellungs-Timestamp des Bestellkopfdatensatzes erfasst und folgt häufig einer genehmigten Bestellanforderung.
Warum es wichtig ist

Dies markiert den Übergang von einer internen Anforderung zu einem formalen Einkaufsdokument. Es ist ein wichtiger Startpunkt für die Messung der Bestellverarbeitungs- und Genehmigungsdurchlaufzeiten.

Woher erhalten

Dieses Event ist die Erstellung eines Datensatzes in der PurchTable. Das Feld createdDateTime in dieser Tabelle liefert den Timestamp für die Aktivität.

Erfassen

Extrahieren Sie den Erstellungs-Timestamp aus der PurchTable für jede Bestellung.

Ereignistyp explicit
Bestellung genehmigt
Kennzeichnet die endgültige Genehmigung der Bestellung, die den Versand an den Lieferanten autorisiert. Dieses Event wird typischerweise aus einer Statusänderung der Bestellung abgeleitet oder direkt aus der Workflow-Historie erfasst.
Warum es wichtig ist

Dies ist ein entscheidender Meilenstein, da keine weiteren Maßnahmen ergriffen werden können, bis die Bestellung genehmigt ist. Er ist unerlässlich für die Analyse von Genehmigungs-Engpässen und die Messung des KPI 'Genehmigungsdurchlaufzeit von Bestellungen'.

Woher erhalten

Abgeleitet aus der Änderung des DocumentState-Feldes in der PurchTable zu 'Approved'. Alternativ kann es aus dem Abschluss-Timestamp des letzten Genehmigungsschritts in der WorkflowTrackingStatusTable bezogen werden.

Erfassen

Identifizieren Sie den Timestamp, wenn der DocumentState in der PurchTable zu 'Approved' wechselt.

Ereignistyp inferred
Wareneingang gebucht
Kennzeichnet die offizielle Erfassung der erhaltenen Waren im Rahmen der Bestellung im System. Dieses Event wird erfasst, wenn ein Wareneingangsbuchungsblatt gebucht wird.
Warum es wichtig ist

Dies ist ein wichtiger Meilenstein, der den Lagerbestand aktualisiert und den Beginn des Rechnungsabgleichprozesses markiert. Er ist der Endpunkt zur Messung der 'Pünktlichen Lieferrate' und der Lieferantendurchlaufzeit.

Woher erhalten

Erfasst aus der Erstellung des Wareneingangsjournals, gespeichert in VendPackingSlipJour. Das Feld createdDateTime oder PackingSlipDate in dieser Tabelle zeigt an, wann Waren offiziell empfangen wurden.

Erfassen

Verwenden Sie den creation oder posting timestamp aus dem VendPackingSlipJour Datensatz, der mit der Bestellung verknüpft ist.

Ereignistyp explicit
Bestellanforderung genehmigt
Beschreibt die formale Genehmigung einer Bestellanforderung durch einen autorisierten Manager. Dieses Event wird typischerweise aus den Workflow-Verlaufsprotokollen erfasst oder durch die Nachverfolgung einer Statusänderung im Anforderungsdatensatz.
Warum es wichtig ist

Die Genehmigung ist ein kritischer Meilenstein, der die Umwandlung einer Bestellanforderung in eine Bestellung ermöglicht. Verzögerungen hier wirken sich direkt auf den gesamten Beschaffungszeitplan aus.

Woher erhalten

Kann aus der WorkflowTrackingStatusTable, die der Bestellanforderung zugeordnet ist, erfasst oder aus einer Änderung des Statusfelds in der PurchReqTable in den Status 'Approved' abgeleitet werden.

Erfassen

Verwenden Sie den completion timestamp des finalen Genehmigungsschritts in der Workflow-Historie für die Anforderung.

Ereignistyp explicit
Bestellung fakturiert
Diese Aktivität markiert den Zeitpunkt, an dem eine Lieferantenrechnung eingegangen und gegen die Bestellung gebucht wurde. Dieses Event verknüpft die Beschaffungs- und Zahlungsprozesse.
Warum es wichtig ist

Dies ist der letzte Schritt vor der Zahlung und entscheidend für die Berechnung der endgültigen Kosten des Einkaufs. Er bietet einen Endpunkt für die Drei-Wege-Abgleichanalyse.

Woher erhalten

Dieses Event wird aus der Buchung eines Kreditorenrechnungsjournals (VendInvoiceJour) erfasst, das der Bestellung zugeordnet ist. Das InvoiceDate oder Buchungsdatum dieses Datensatzes ist der Timestamp.

Erfassen

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

Ereignistyp explicit
Bestellung geändert
Diese Aktivität erfasst jede Änderung, die an einer Bestellung nach deren Genehmigung vorgenommen wird. Dynamics 365 kann Versionen der Bestellung verfolgen, was die Identifizierung von Änderungen ermöglicht.
Warum es wichtig ist

Änderungen zu verfolgen, ist entscheidend für die Identifizierung von Nacharbeit, das Verständnis von Prozessinstabilität und die Messung der 'Bestelländerungsrate'. Änderungen können zu Verzögerungen und Kostenabweichungen führen.

Woher erhalten

Abgeleitet durch den Vergleich verschiedener Versionen der Bestellung, die in Archiv- oder Versionierungstabellen (z.B. PurchTableHistory) gespeichert sind. Eine Erhöhung der Versionsnummer kennzeichnet eine Änderung.

Erfassen

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

Ereignistyp inferred
Bestellung storniert
Beschreibt die Stornierung einer Bestellung, bevor diese vollständig abgeschlossen wurde. Dies wird durch eine spezifische Statusänderung im Bestelldokument erfasst.
Warum es wichtig ist

Stornierungen sind ein wichtiger Ausnahmepfad. Die Analyse ihrer Häufigkeit und Gründe kann Probleme in der Planung oder Lieferantenverlässlichkeit aufzeigen.

Woher erhalten

Dies wird abgeleitet, wenn das DocumentState-Feld in der PurchTable auf 'Storniert' aktualisiert wird. Der Timestamp dieser Statusänderung markiert das Event.

Erfassen

Identifizieren Sie den Timestamp, wenn der DocumentState in der PurchTable auf 'Canceled' gesetzt wird.

Ereignistyp inferred
Bestellung vom Lieferanten bestätigt
Beschreibt die Bestätigung der Bestelldetails durch den Lieferanten. Dies ist oft ein manueller Datenerfassungsschritt, basierend auf der Kommunikation des Lieferanten.
Warum es wichtig ist

Die Lieferantenbestätigung gibt die Gewissheit, dass die Bestellung bearbeitet wird. Verzögerungen oder Abweichungen in dieser Phase können auf potenzielle Lieferprobleme hinweisen.

Woher erhalten

Dies wird typischerweise aus der Belegung bestätigungsbezogener Datums- oder Statusfelder in der PurchTable abgeleitet, wie z.B. Lieferbestätigungsdaten. Dies ist möglicherweise kein diskretes Event.

Erfassen

Ableiten aus der Belegung eines spezifischen Bestätigungsdatumsfeldes in der PurchTable oder PurchLine.

Ereignistyp inferred
Bestellung zur Genehmigung eingereicht
Beschreibt den Zeitpunkt, an dem ein Bestellentwurf formal in den Genehmigungs-Workflow übermittelt wird. Dies ist typischerweise eine explizite Benutzeraktion, die über Workflow-Protokolle erfasst wird.
Warum es wichtig ist

Diese Aktivität initiiert offiziell den Bestellfreigabezyklus. Ihre Verfolgung ermöglicht eine präzise Messung der Wartezeiten von Bestellungen bis zur Genehmigung und der gesamten Genehmigungsdauer.

Woher erhalten

Erfasst aus der WorkflowTrackingStatusTable für die Bestellung, die das Einreichungsereignis und den Timestamp protokolliert.

Erfassen

Identifizieren Sie das 'Submitted'-Event in der Workflow-Historie, das mit dem PurchTable-Datensatz verknüpft ist.

Ereignistyp explicit
Qualitätsprüfung durchgeführt
Beschreibt den Abschluss einer Qualitätsprüfung für die erhaltenen Güter. Dieses Event wird oft über das Qualitätsmanagementmodul oder eine Statusaktualisierung verwaltet.
Warum es wichtig ist

Diese Aktivität kann einen erheblichen Engpass zwischen dem Wareneingang und der Verfügbarmachung der Waren darstellen. Die Analyse ihrer Dauer trägt dazu bei, den KPI „Durchlaufzeit der Qualitätsprüfung“ zu verbessern.

Woher erhalten

Dies kann aus der Fertigstellung eines Qualitätsauftrags (InventQualityOrderTable) abgeleitet werden, der mit dem Wareneingang der Bestellung verknüpft ist. Der Timestamp der Statusänderung auf 'Bestanden' oder 'Fehlgeschlagen' markiert das Event.

Erfassen

Verfolgen Sie den Timestamp des Statusabschlusses in der InventQualityOrderTable, die mit der Bestellposition verknüpft ist.

Ereignistyp inferred
Ware an Lieferanten zurückgesandt
Zeigt an, dass zuvor erhaltene Waren aufgrund von Problemen wie Beschädigungen oder falschen Artikeln an den Lieferanten zurückgesandt wurden. Dies wird durch die Buchung einer Retourentransaktion erfasst.
Warum es wichtig ist

Retouren stellen Prozessfehler und zusätzliche Kosten dar. Die Nachverfolgung dieser Aktivität hilft bei der Berechnung der 'Bestellrücksendequote' und der Identifizierung von Problemen mit Lieferanten oder Produkten.

Woher erhalten

Dieses Event wird aus der Erstellung einer Bestellung mit negativer Menge oder einem spezifischen Retourenauftragsdokument abgeleitet, das auf die ursprüngliche Bestellung verweist. Das Transaktionsdatum der Retourenbuchung ist der Event-Zeitpunkt.

Erfassen

Identifizieren Sie die Buchung einer Retourenbestellung oder einer Lastschrift gegen die ursprüngliche Bestellung.

Ereignistyp explicit
Empfohlen Optional

Extraktionsleitfäden

So rufen Sie Ihre Daten aus Microsoft Dynamics 365 ab