Ihr Datentemplate für Procure-to-Pay – Einkaufsbestellungen
Ihr Datentemplate für Procure-to-Pay – Einkaufsbestellungen
- Empfohlene Attribute für die Detailanalyse
- Wichtige Aktivitäten zur Verfolgung innerhalb des Prozesses
- Schritt-für-Schritt-Anleitung zur Datenextraktion
Purchase to Pay - Bestellattribute
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivität ActivityName | Der Name des Geschäftsereignisses oder -schritts, der im Bestellprozess stattgefunden hat. | ||
| Beschreibung Dieses Attribut beschreibt eine spezifische Aktion oder Statusänderung innerhalb des Bestelllebenszyklus, wie z.B. 'Bestellung angelegt', 'Bestellung genehmigt' oder 'Wareneingang gebucht'. Die Abfolge dieser Aktivitäten bildet den Prozessablauf. Die Analyse der Reihenfolge und Häufigkeit von Aktivitäten ist der Kern des Process Mining. Sie hilft, den tatsächlichen Prozess zu entdecken, ihn mit dem entworfenen Modell zu vergleichen, Engpässe zu identifizieren (z.B. lange Wartezeiten nach 'Rechnung eingegangen') und Nacharbeit zu quantifizieren (z.B. wiederholte 'Bestellung geändert'-Aktivitäten). Bedeutung Es definiert die Prozessschritte und ermöglicht so die Visualisierung und Analyse des End-to-End-Ablaufs, die Variantenanalyse und die Identifizierung von Engpässen. Datenquelle Typischerweise abgeleitet aus einer Kombination von Tabellen und Feldern, wie Statusfeldern in EKKO/EKPO oder Änderungsbelegprotokollen in CDHDR/CDPOS, um wichtige Geschäftsmeilensteine darzustellen. Beispiele `Bestellung` erstelltBestellung genehmigt`Wareneingang` gebuchtRechnung eingegangen | |||
| Bestellung PurchaseOrderNumber | Die eindeutige Kennung für die Bestellung (PO), die als primäre Case-ID zur Verfolgung des Beschaffungslebenszyklus dient. | ||
| Beschreibung Die Bestellnummer ist die zentrale Kennung, die alle damit verbundenen Aktivitäten von der initialen Erstellung bis zum finalen Wareneingang und Abschluss miteinander verknüpft. Sie dient als Case-ID für die Process Mining-Analyse. In der Analyse ermöglicht die Gruppierung von Events nach dieser Nummer die Rekonstruktion des Weges jeder einzelnen Bestellung. Dies ist essenziell für die Berechnung von Durchlaufzeiten, die Analyse von Prozessvarianten und die Identifizierung von Engpässen oder Abweichungen, die spezifisch für eine einzelne Bestellung sind. Bedeutung Er ist der essenzielle Schlüssel, um alle Beschaffungsereignisse zu einem einzigen End-to-End-Prozess zu verbinden. Dies ermöglicht eine detaillierte Analyse des Lebenszyklus jeder Bestellung. Datenquelle Dieses Attribut ist in der SAP S/4HANA Tabelle EKKO, Feld EBELN, zu finden. Beispiele 450001712345000171244500017125 | |||
| Ereigniszeit EventTime | Der Timestamp, der angibt, wann die Aktivität stattfand. | ||
| Beschreibung Dieses Attribut erfasst das genaue Datum und die Uhrzeit jeder Aktivität im Prozess. Es ist grundlegend für alle zeitbasierten Analysen im Process Mining. Die Event Time wird verwendet, um die Aktivitäten chronologisch zu ordnen und den Prozessablauf zu erstellen. Darüber hinaus ist sie die Basis für die Berechnung aller durati-onsbezogenen Metriken, wie z.B. Durchlaufzeiten zwischen Aktivitäten, Wartezeiten und Bearbeitungszeiten, die für die Leistungsanalyse und Engpassidentifizierung entscheidend sind. Bedeutung Dieser Zeitstempel ist entscheidend für die korrekte Reihenfolge der Events und die Berechnung aller Performance-Metriken, einschließlich Durchlaufzeiten, Lieferzeiten und Wartezeiten. Datenquelle Zeitstempelfelder, die mit spezifischen Aktivitäten verbunden sind, wie z.B. Erstellungsdatum (EKKO-AEDAT für Änderungen) oder Buchungsdatum (MKPF-BUDAT für Wareneingänge). Erfordert oft die Kombination von Daten aus mehreren Tabellen. Beispiele 2023-04-15T10:00:00Z2023-04-15T14:30:00Z2023-05-01T09:15:00Z | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp, wann die Daten zuletzt aktualisiert oder aus dem Quellsystem extrahiert wurden. | ||
| Beschreibung Dieses Attribut gibt die Aktualität der analysierten Daten an. Es zeigt Datum und Uhrzeit des letzten Datenabzugs aus SAP S/4HANA. Die Kenntnis des letzten Datenaktualisierungszeitpunkts ist für Benutzer entscheidend, um die Aktualität ihrer Analyse zu verstehen. Es hilft ihnen, die Ergebnisse korrekt zu interpretieren, da sie wissen, ob sie Echtzeitinformationen oder einen Schnappschuss von einem bestimmten Zeitpunkt betrachten, was die Relevanz aller auf der Analyse basierenden Maßnahmen beeinflusst. Bedeutung Informiert Benutzer über die Aktualität der Daten und stellt sicher, dass sie den Kontext und die Relevanz ihrer Analyseergebnisse verstehen. Datenquelle Dies ist ein Metadaten-Zeitstempel, der während des Datenextraktions-, Transformations- und Ladeprozesses (ETL) hinzugefügt wird. Beispiele 2024-05-21T02:00:00Z2024-05-20T02:00:00Z2024-05-19T02:00:00Z | |||
| Quellsystem SourceSystem | Identifiziert das Quellsystem, aus dem die Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut gibt das Ursprungssystem für die Event-Daten an, z.B. 'SAP S/4HANA Produktion' oder 'SAP ECC'. In Umgebungen mit mehreren Systemen ist dieses Feld entscheidend für die Datenherkunft, Fehlerbehebung und um sicherzustellen, dass Daten aus verschiedenen Quellen korrekt interpretiert werden. Es hilft, den Kontext der Daten zu verstehen und kann zur Filterung der Analyse für spezifische Systemumgebungen verwendet werden. Bedeutung Liefert wesentlichen Kontext über die Herkunft der Daten, was für Daten-Governance, Validierung und Analyse in Multi-System-Landschaften entscheidend ist. Datenquelle Dies ist typischerweise ein statischer Wert, der während des Datenextraktions-, Transformations- und Ladeprozesses (ETL) hinzugefügt wird, um den Datensatz mit seiner Herkunft zu kennzeichnen. Beispiele S4H_PROD_100ECC_EU_200S4H_US_300 | |||
| `Bestellanforderung` PurchaseRequisitionNumber | Die Kennung der Purchase Requisition (PR), die die Bestellung initiiert hat. | ||
| Beschreibung Dieses Attribut verknüpft die Bestellung mit ihrer ursprünglichen Bestellanforderung. Nicht alle Bestellungen haben eine Bestellanforderung, wenn sie direkt erstellt werden. Diese Verknüpfung ist essenziell für die Analyse des gesamten End-to-End-Beschaffungsprozesses, beginnend mit der initialen Anforderung. Sie unterstützt KPIs wie die 'Bestellanforderungs-Genehmigungszeit' und ist grundlegend für die Identifizierung von 'Maverick Spend', wo Bestellungen ohne vorhergehende, genehmigte Anforderung erstellt werden. Bedeutung Verbindet die Bestellung (PO) mit der ursprünglichen Anforderung und ermöglicht so eine End-to-End-Prozessanalyse sowie die Identifizierung von nicht-compliantem Maverick Spend. Datenquelle Dieses Attribut befindet sich in der SAP S/4HANA Tabelle EKPO (Bestellpositionsebene), Feld BANFN. Beispiele 1001005110010052 | |||
| Angefordertes Lieferdatum RequestedDeliveryDate | Das Datum, an dem das Unternehmen den Lieferanten aufgefordert hat, die Waren oder Dienstleistungen zu liefern. | ||
| Beschreibung Dieses Attribut gibt das in der Bestellung vereinbarte Zieldatum für die Lieferung an. Es dient als Grundlage zur Messung der Lieferantenlieferleistung. Im Process Mining wird dieses Datum mit dem tatsächlichen Wareneingangsdatum (Zeitstempel 'Wareneingang gebucht') verglichen, um die KPI 'Lieferantenpünktlichkeitsrate' zu berechnen. Die Analyse von Abweichungen von diesem Datum hilft bei der Bewertung der Lieferantenzuverlässigkeit und dem Management von Lieferkettenrisiken. Bedeutung Dient als Grundlage zur Messung der Lieferantenpünktlichkeit, einer kritischen KPI für Supply Chain Management und operative Planung. Datenquelle Dies ist in der Einteilungstabelle EKET, Feld EINDT, zu finden. Beispiele 2023-06-012023-06-152023-07-01 | |||
| Benutzer UserName | Die Kennung des Benutzers, der eine bestimmte Aktivität ausgeführt hat. | ||
| Beschreibung Dieses Attribut erfasst die SAP-Benutzer-ID, die für die Erstellung, Änderung oder Genehmigung eines Dokuments verantwortlich ist. Es bietet Rückverfolgbarkeit für im System durchgeführte Aktionen. Die Analyse nach Benutzer hilft, Schulungsbedarfe, Arbeitslastverteilung und individuelle Leistung zu identifizieren. Zum Beispiel kann damit festgestellt werden, ob bestimmte Benutzer konsistent mit langen Genehmigungszeiten oder häufigen Änderungen nach Genehmigung verbunden sind, was zur Ressourcenverwaltung und zu Prozessverbesserungsinitiativen beitragen kann. Bedeutung Schafft Verantwortlichkeit und ermöglicht Leistungsanalysen auf individueller Ebene oder Teamebene, um Schulungsmöglichkeiten oder Ressourcenengpässe zu identifizieren. Datenquelle Diese Information ist in Feldern wie ERNAM (Erstellt von) in EKKO oder aus dem Benutzerfeld in Änderungsbelegtabellen (CDHDR-USERNAME) zu finden. Beispiele CB9980000012JSMITHRROE | |||
| Bestelldokumentart DocumentType | Eine Klassifizierung, die verschiedene Arten von Bestellungen unterscheidet, wie z.B. Standardbestellungen, Dienstleistungsbestellungen oder Umlagerungsbestellungen. | ||
| Beschreibung Die Dokumentart ist ein zentrales Konfigurationselement in SAP, das den Prozessablauf, den Nummernkreis und die Felder einer Bestellung steuert. Sie ermöglicht es Unternehmen, den Beschaffungsprozess für verschiedene Szenarien anzupassen. Die Analyse des Prozesses nach Dokumentart ist entscheidend, um Prozessvariationen zu verstehen. So kann der Prozess für eine Standardwarenbestellung sehr unterschiedlich zu dem einer Dienstleistungsbestellung oder einer Umlagerung sein. Dieses Attribut ermöglicht das Filtern und Vergleichen dieser unterschiedlichen Prozessabläufe, um spezifische Verbesserungsmöglichkeiten zu finden. Bedeutung Es kategorisiert Bestellungen, ermöglicht den Vergleich verschiedener Beschaffungsprozesse und hilft, Abweichungen in Prozessabläufen und Durchlaufzeiten zu erklären. Datenquelle Dieses Attribut befindet sich in der SAP S/4HANA Tabelle EKKO, Feld BSART. Beispiele NBFOUB | |||
| Gesamtnettobetrag TotalNetAmount | Der Gesamtwert der Bestellung, exklusive Steuern und Frachtkosten. | ||
| Beschreibung Dieses Attribut repräsentiert den monetären Nettowert der Bestellung. Es ist eine zentrale Finanzkennzahl, die die Größe der Beschaffungstransaktion angibt. Dieser Betrag ist entscheidend für die Finanzanalyse, z.B. um Bestellungen nach Wert zu kategorisieren (hochwertig vs. geringwertig), um zu sehen, ob sich ihre Prozesspfade unterscheiden. Er kann auch zur Priorisierung der Analyse verwendet werden, um sich auf hochwertige Bestellungen zu konzentrieren, die ein höheres finanzielles Risiko bergen oder eine größere Auswirkung auf das Geschäft haben können. Bedeutung Ermöglicht eine finanzbasierte Analyse, die hilft, Bestellungen nach Wert zu segmentieren und Prozessverbesserungsbemühungen auf Ausgabenbereiche mit hohem Volumen zu priorisieren. Datenquelle Dieses Attribut ist in der SAP S/4HANA Tabelle EKKO, Feld NETWR, zu finden. Beispiele 1500.0025000.50125.75 | |||
| Lieferanten-ID VendorId | Die eindeutige Kennung für den Lieferanten oder Anbieter der Waren oder Dienstleistungen. | ||
| Beschreibung Die Lieferanten-ID ist ein kritischer Stammdatensatz, der eine Bestellung mit einem bestimmten Lieferanten verknüpft. Sie wird während des gesamten Beschaffungsprozesses für Kommunikation, Lieferung und Zahlung verwendet. Im Process Mining ermöglicht dieses Attribut eine Segmentierung der Leistungsanalyse nach Lieferanten. Es ist essenziell für Dashboards wie 'Lieferantenlieferzeit-Performance' und 'Retourenquote nach Lieferant', um die zuverlässigsten Lieferanten und diejenigen zu identifizieren, die Verzögerungen oder Qualitätsprobleme verursachen könnten. Bedeutung Ermöglicht eine lieferantenzentrierte Analyse, die hilft, die Leistung zu bewerten, leistungsstarke und weniger leistungsstarke Lieferanten zu identifizieren und die Lieferkette zu optimieren. Datenquelle Dieses Attribut befindet sich in der SAP S/4HANA Tabelle EKKO, Feld LIFNR. Beispiele 100023100045100088 | |||
| `Materialnummer` MaterialNumber | Die Kennung für das spezifische Material oder die Ware, die beschafft wird. | ||
| Beschreibung Die Materialnummer ist ein eindeutiger Code, der jedem Materialstammsatz in SAP zugewiesen wird. Sie wird für alle Transaktionen verwendet, die sich auf dieses Material beziehen, einschließlich Beschaffung, Bestandsführung und Vertrieb. Die Analyse nach Materialnummer oder Materialgruppe ermöglicht eine warenbezogene Analyse. Sie kann helfen zu identifizieren, ob Beschaffungsprozesse für bestimmte Materialarten weniger effizient sind, längere Lieferzeiten haben oder anfälliger für Retouren sind, und liefert so Erkenntnisse für das Warengruppenmanagement. Bedeutung Ermöglicht eine warengruppenbasierte Analyse, die hilft, Prozessprobleme oder Lieferantenleistungsprobleme im Zusammenhang mit spezifischen Produkten oder Materialien zu identifizieren. Datenquelle Dieses Attribut befindet sich in der SAP S/4HANA Tabelle EKPO, Feld MATNR. Beispiele RM100-100FG210SERV-CONSULT | |||
| Artikelkategorie ItemCategory | Klassifiziert eine Bestellposition, z.B. Standard, Konsignation, Lohnbearbeitung oder Dienstleistung. | ||
| Beschreibung Die Positionskategorie bestimmt, wie die Beschaffung eines spezifischen Materials oder einer Dienstleistung gesteuert und verarbeitet wird. Sie beeinflusst nachfolgende Schritte wie Wareneingang und Rechnungsprüfung. Dieses Attribut ist wichtig für die Analyse von Prozessvarianten, basierend darauf, was beschafft wird. Zum Beispiel unterscheidet sich der Prozess für eine Dienstleistungsposition (die einen Leistungsnachweis erfordert) erheblich von dem einer Standardlagerposition. Die Analyse nach Positionskategorie hilft, diese Unterschiede zu erklären und gezielte Prozessverbesserungen zu ermöglichen. Bedeutung Erklärt Prozessvarianten durch die Unterscheidung zwischen verschiedenen Arten der Beschaffung, wie z.B. Waren, Dienstleistungen oder Lohnbearbeitung. Datenquelle Dieses Attribut befindet sich in der SAP S/4HANA Tabelle EKPO, Feld PSTYP. Beispiele 093 | |||
| Buchungskreis CompanyCode | Die Kennung für die juristische Einheit oder das Unternehmen, für die die Bestellung erstellt wird. | ||
| Beschreibung Der Buchungskreis repräsentiert eine unabhängige Rechnungslegungseinheit innerhalb einer Organisation. Alle finanzbezogenen Transaktionen einer Bestellung werden einem spezifischen Buchungskreis zugeordnet. Dies ist ein grundlegendes organisatorisches Attribut, das das Filtern und Vergleichen von Beschaffungsprozessen über verschiedene juristische Einheiten hinweg ermöglicht. Eine Analyse nach Buchungskreis kann Inkonsistenzen in der Prozessausführung, unterschiedliche Effizienzgrade oder variierende Compliance-Raten innerhalb der Organisation aufzeigen. Bedeutung Ermöglicht die Segmentierung der Prozessanalyse nach juristischen Einheiten, wodurch Leistungs- und Compliance-Vergleiche über verschiedene Geschäftsbereiche hinweg erleichtert werden. Datenquelle Dieses Attribut befindet sich in der SAP S/4HANA Tabelle EKKO, Feld BUKRS. Beispiele 101017102000 | |||
| Einkäufergruppe PurchasingGroup | Die spezifische Gruppe von Einkäufern, die für bestimmte Beschaffungsaktivitäten verantwortlich ist. | ||
| Beschreibung Eine Einkaufsgruppe ist ein Einkäufer oder eine Gruppe von Einkäufern, die für bestimmte Einkaufsaktivitäten, Materialien oder Lieferanten verantwortlich sind. Sie sind der primäre Ansprechpartner für Lieferanten. Dieses Attribut ermöglicht eine granularere Analyse von Arbeitslast und Leistung als die Einkaufsorganisation. Es kann verwendet werden, um überlastete Teams zu identifizieren, die Effizienz verschiedener Einkäufergruppen zu messen und zu verstehen, welche Gruppen anfälliger für Prozessabweichungen wie Maverick Spend sind. Bedeutung Bietet eine detaillierte Ansicht der Leistung von Einkaufsgruppen, die eine Analyse von Arbeitslast, Effizienz und Prozesseinhaltung auf Teamebene ermöglicht. Datenquelle Dieses Attribut befindet sich in der SAP S/4HANA Tabelle EKKO, Feld EKGRP. Beispiele 001002N00 | |||
| Einkaufsorganisation PurchasingOrganization | Die `Organisationseinheit`, die für die `Beschaffung von Materialien und Dienstleistungen` sowie die `Verhandlung mit Lieferanten` zuständig ist. | ||
| Beschreibung Die Einkaufsorganisation ist eine zentrale Organisationseinheit in der Beschaffung. Sie kann auf Konzern-, Unternehmens- oder Werksebene strukturiert sein und ist für alle Einkaufsaktivitäten verantwortlich. Die Analyse des Prozesses nach Einkaufsorganisation hilft, die Effizienz und Leistung verschiedener Beschaffungsteams oder Regionen zu bewerten. Sie kann Unterschiede in der Lieferantenverhandlung, Prozess-Compliance oder Genehmigungsverzögerungen zwischen Organisationseinheiten aufzeigen. Bedeutung Ermöglicht den Leistungsvergleich zwischen verschiedenen Beschaffungsabteilungen oder Regionen und hilft, Best Practices und Verbesserungspotenziale zu identifizieren. Datenquelle Dieses Attribut befindet sich in der SAP S/4HANA Tabelle EKKO, Feld EKORG. Beispiele 10101710US01 | |||
| Genehmigungs-`Cycle Time` der Bestellung PoApprovalCycleTime | Die berechnete Dauer von der Erstellung einer Bestellung bis zu ihrer endgültigen Genehmigung. | ||
| Beschreibung Diese Metrik misst die verstrichene Zeit zwischen der Aktivität 'Bestellung angelegt' und der Aktivität 'Bestellung genehmigt'. Sie wird für jeden Bestellfall berechnet. Dieses Attribut bietet ein direktes Maß für die interne Genehmigungseffizienz. Es ist die primäre Metrik für das Dashboard und die KPI 'Bestellgenehmigungs-Durchlaufzeit' und hilft, Verzögerungen im Genehmigungsprozess zu identifizieren und Beschleunigungsmöglichkeiten aufzuzeigen. Bedeutung Misst direkt die Effizienz des internen Genehmigungsprozesses und hilft, Engpässe zu identifizieren und zu beheben, die die Beschaffung verlangsamen. Datenquelle Berechnet durch Ermittlung der Zeitdifferenz zwischen dem Event „Bestellung genehmigt“ und dem Event „Bestellung erstellt“ für jede Bestellung. Beispiele P2D4H30MP0D2H15MP5D | |||
| Ist Maverick Spend IsMaverickSpend | Ein berechnetes Flag, das anzeigt, ob eine Bestellung ohne eine vorhergehende, genehmigte Bestellanforderung erstellt wurde. | ||
| Beschreibung Dieses boolesche Flag wird während der Datenverarbeitung abgeleitet. Es wird auf 'wahr' gesetzt, wenn einer Bestellung keine zugehörige Bestellanforderung fehlt oder wenn die Bestellerstellung den Standard-Genehmigungs-Workflow umgeht. Dieses Attribut unterstützt direkt das Dashboard 'Maverick Spend Identifizierung' und die damit verbundenen KPIs. Es hilft, das Ausmaß nicht konformen Einkaufsverhaltens zu quantifizieren und ermöglicht es Unternehmen, spezifische Abteilungen oder Benutzergruppen anzusprechen, um Beschaffungsrichtlinien und -kontrollen zu stärken. Bedeutung Identifiziert direkt nicht-konforme Beschaffung, hilft Prozessabweichungen zu quantifizieren und Finanzkontrollen sowie Beschaffungsrichtlinien durchzusetzen. Datenquelle Berechnetes Feld basierend auf dem Fehlen eines Wertes in „PurchaseRequisitionNumber“ für spezifische Dokumenttypen oder durch Analyse der Event-Sequenz. Beispiele truefalsch | |||
| Ist Nacharbeit IsRework | Ein berechnetes Flag, das anzeigt, ob die Bestellung Nacharbeit erfahren hat, wie z.B. eine Änderung nach Genehmigung oder eine Warenrücksendung. | ||
| Beschreibung Dieses boolesche Attribut wird durch die Analyse der Abfolge von Aktivitäten für jede Bestellung berechnet. Es wird auf 'wahr' gesetzt, wenn ein 'Bestellung geändert'-Ereignis nach einem 'Bestellung genehmigt'-Ereignis auftritt oder wenn ein 'Waren retourniert'-Ereignis vorhanden ist. Dieses Flag vereinfacht die Berechnung der KPI 'Straight-Through Processing Rate'. Es ermöglicht ein einfaches Filtern und Visualisieren aller Bestellungen, die manuelle Eingriffe oder Korrekturen erforderten, und hilft, die Kosten und Häufigkeit von Nacharbeiten zu quantifizieren. Bedeutung Hilft, Prozesseffizienz zu quantifizieren, indem Fälle mit Nacharbeit markiert werden, was entscheidend für die Berechnung von Straight-Through-Processing-Raten und die Identifizierung von Ursachen für Abweichungen ist. Datenquelle Berechnetes Feld basierend auf der Abfolge der Aktivitäten. Die Logik prüft, ob auf ein Genehmigungsevent ein Event „Bestellung geändert“ folgt oder ob ein Event „Warenrücksendung“ existiert. Beispiele truefalsch | |||
| Lieferantenpünktlichkeit SupplierOnTimeDelivery | Ein berechnetes Flag, das anzeigt, ob der Wareneingang am oder vor dem angeforderten Lieferdatum gebucht wurde. | ||
| Beschreibung Dieses boolesche Attribut wird durch den Vergleich des Zeitstempels der Aktivität 'Wareneingang gebucht' mit dem 'Angeforderten Lieferdatum' abgeleitet. Wenn der Wareneingang am oder vor dem angeforderten Datum erfolgt, wird es auf 'wahr' gesetzt. Dieses Attribut unterstützt direkt die KPI 'Lieferantenpünktlichkeitsrate'. Es vereinfacht die Analyse, indem es Benutzern ermöglicht, einfach nach pünktlichen oder verspäteten Lieferungen zu filtern, was für Lieferanten-Performance-Dashboards und Lieferantenbewertungen unerlässlich ist. Bedeutung Misst direkt die Lieferantenverlässlichkeit, bildet die Grundlage für den Pünktlichkeits-KPI und ermöglicht ein effektives Lieferantenleistungsmanagement. Datenquelle Berechnet durch Vergleich des Zeitstempels der Aktivität „Wareneingang gebucht“ mit dem Attribut „RequestedDeliveryDate“. Beispiele truefalsch | |||
| Werk Plant | Die operative Einrichtung oder der Standort, an den die Waren geliefert oder Dienstleistungen erbracht werden. | ||
| Beschreibung In SAP ist ein Werk ein physischer Standort, an dem Waren produziert, gelagert oder Dienstleistungen erbracht werden. Es ist ein Schlüsselelement für Logistik und Planung. Die Segmentierung der Prozessanalyse nach Werken kann regionale oder standortspezifische Variationen im Beschaffungsprozess aufzeigen. Zum Beispiel kann sie zeigen, ob bestimmte Werke längere Lieferzeiten haben oder höhere Raten von Warenrücksendungen aufweisen, was auf lokalisierte Logistik- oder Qualitätskontrollprobleme hinweist. Bedeutung Ermöglicht eine standortbasierte Analyse, die Prozessleistungsunterschiede zwischen verschiedenen Betriebsstandorten, Werken oder Lagern aufzeigt. Datenquelle Dieses Attribut befindet sich in der SAP S/4HANA Tabelle EKPO, Feld WERKS. Beispiele 10101710DE01 | |||
Purchase to Pay - Bestellaktivitäten
| Aktivität | Beschreibung | ||
|---|---|---|---|
| `Bestellanforderung` erstellt | Diese Aktivität markiert die formale Anforderung von Waren oder Dienstleistungen und initiiert den Beschaffungsprozess. Das Ereignis wird explizit erfasst, wenn ein Benutzer ein neues Bestellanforderungsdokument speichert (z.B. mit Transaktion ME51N). | ||
| Bedeutung Dies ist der primäre Startpunkt für viele Bestelllebenszyklen. Die Analyse der Zeit von diesem Ereignis bis zur Bestellerstellung hilft, Verzögerungen bei der Beschaffung und internen Bearbeitung zu identifizieren. Datenquelle Erfasst in Tabelle EBAN (Bestellanforderung). Der Zeitstempel des Erstellungsereignisses ist in den Änderungsbelegtabellen CDHDR und CDPOS für das EBAN-Objekt zu finden. Erfassen Event erfasst bei der Erstellung eines Belegs in der Tabelle EBAN. Ereignistyp explicit | |||
| `Bestellanforderung` genehmigt | Stellt die formale Genehmigung einer Bestellanforderung durch einen Manager oder designierten Genehmiger dar. Dies wird typischerweise aus einer Statusänderung im Anforderungsdokument abgeleitet, was bedeutet, dass es zur Umwandlung in eine Bestellung bereit ist. | ||
| Bedeutung Dies ist ein kritischer Meilenstein zur Verfolgung von Genehmigungsdurchlaufzeiten und zur Identifizierung von Engpässen. Verzögerungen hier wirken sich direkt darauf aus, wie schnell eine Bestellung erstellt und an einen Lieferanten gesendet werden kann. Datenquelle Abgeleitet aus den Freigabestatusfeldern in der Tabelle EBAN (z.B. FRGZU – Freigabekennzeichen). Der Zeitstempel wird aus den Änderungsbelegen (CDHDR/CDPOS) abgeleitet, die aufzeichnen, wann der endgültige Freigabestatus gesetzt wurde. Erfassen Abgeleitet aus Änderungsbelegen (CDHDR/CDPOS) für Freigabestatusfelder in der Tabelle EBAN. Ereignistyp inferred | |||
| `Bestellung` abgeschlossen | Diese Aktivität bedeutet, dass eine Bestellposition aus logistischer Sicht als abgeschlossen gilt. Dies wird abgeleitet, wenn die Indikatoren 'Lieferung abgeschlossen' und 'Endrechnung' beide gesetzt sind. | ||
| Bedeutung Dies dient als Endpunkt für die Analyse des Bestelllebenszyklus. Die Messung der Zeit bis zu diesem Ereignis liefert die End-to-End-Durchlaufzeit für Beschaffungsvorgänge. Datenquelle Abgeleitet von Statuskennzeichen in der Bestellpositionstabelle EKPO. Das Event tritt auf, wenn sowohl das Kennzeichen „Lieferung abgeschlossen“ (ELIKZ) als auch das Kennzeichen „Rechnungseingang abgeschlossen“ (EREKZ) auf „true“ gesetzt sind. Erfassen Abgeleitet aus Änderungsbelegen, wenn die EKPO-Felder ELIKZ und EREKZ beide als vollständig gekennzeichnet sind. Ereignistyp inferred | |||
| `Bestellung` erstellt | Markiert die Erstellung des offiziellen Bestelldokuments, welches mit oder ohne Bezug zu einer Bestellanforderung angelegt werden kann. Dies ist ein explizites Ereignis, das erfasst wird, wenn das Bestelldokument erstmals im System gespeichert wird. | ||
| Bedeutung Diese Aktivität kann als alternativer Startpunkt für den Prozess dienen, insbesondere für die Maverick Buying-Analyse. Sie ist ein fundamentales Ereignis zur Verfolgung der gesamten Bearbeitungszeit von Bestellungen. Datenquelle Erfasst in der Bestellkopftabelle EKKO. Das Erstellungsdatum (AEDAT) und die Uhrzeit sind direkt in dieser Tabelle für das Dokument gespeichert. Erfassen Erstellungszeitstempel (AEDAT) in der Tabelle EKKO für das Bestelldokument. Ereignistyp explicit | |||
| `Wareneingang` gebucht | Stellt den physischen Wareneingang vom Lieferanten und die entsprechende Erfassung im System dar. Dies ist eine explizite Transaktion, die die Bestellhistorie aktualisiert. | ||
| Bedeutung Dies ist ein wichtiger Meilenstein, der die Lieferantenlieferzeit beendet und den internen Prozess der Rechnungsprüfung einleitet. Er ist essenziell für die Verfolgung der Pünktlichkeitsraten bei Lieferungen. Datenquelle Erfasst als Materialbeleg in den Tabellen MKPF (Kopf) und MSEG (Position) und verknüpft in der Bestellhistorientabelle EKBE mit einer spezifischen Bewegungsart (z.B. 101). Erfassen Buchungsdatum (BUDAT) aus dem Materialbelegkopf (MKPF), verknüpft über EKBE. Ereignistyp explicit | |||
| Bestellung genehmigt | Bedeutet, dass die Bestellung alle notwendigen internen Genehmigungen erhalten hat und zur Freigabe an den Lieferanten autorisiert ist. Das Ereignis wird aus einer Statusänderung in der Freigabestrategie der Bestellung abgeleitet. | ||
| Bedeutung Dies ist ein wichtiger Meilenstein zur Messung der Genehmigungseffizienz und der Nacharbeit nach Genehmigung. Die Analyse der Zeit zwischen Bestellerstellung und -genehmigung zeigt interne Prozessverzögerungen auf. Datenquelle Abgeleitet aus dem Freigabekennzeichen (FRGKE) in der Tabelle EKKO. Der Zeitstempel wird durch Betrachten der Änderungsgeschichte (CDHDR/CDPOS) ermittelt, wann dieses Feld auf den Status „freigegeben“ aktualisiert wurde. Erfassen Abgeleitet aus Änderungsbelegen für das Freigabekennzeichenfeld (FRGKE) in der Tabelle EKKO. Ereignistyp inferred | |||
| Rechnung eingegangen | Stellt die Erfassung einer Lieferantenrechnung im SAP-System dar, die mit der entsprechenden Bestellung verknüpft wird. Dies ist eine explizite Finanzbuchung, die ein Buchhaltungsbeleg erzeugt. | ||
| Bedeutung Dies ist ein kritischer Meilenstein, der den Beschaffungsprozess mit dem Kreditorenprozess verbindet. Er ermöglicht die Analyse der Zeit zwischen Wareneingang und Rechnungsverarbeitung. Datenquelle Ein Buchhaltungsbeleg wird in der Tabelle BKPF (Kopf) erstellt, und seine Einzelposten befinden sich in BSEG oder im Universal Journal ACDOCA. Der Beleg ist in der Tabelle RSEG mit der Bestellung (PO) verknüpft. Erfassen Belegerfassungsdatum (CPUDT) aus der Buchhaltungsbelegkopftabelle BKPF. Ereignistyp explicit | |||
| `Bestellung` gelöscht | Stellt die Stornierung oder logische Löschung einer Bestellposition oder des gesamten Dokuments dar. Dies wird erfasst, indem ein Benutzer ein Löschkennzeichen im Dokument setzt. | ||
| Bedeutung Diese Aktivität ist ein alternativer Endpunkt für den Prozess, der einen Fehler oder eine Stornierung anzeigt. Die Analyse der Gründe für gelöschte Bestellungen kann Probleme in der Bedarfsplanung oder Anforderungsdefinition aufdecken. Datenquelle Erfasst aus dem Löschkennzeichen (LOEKZ) in den Bestellanforderungs-Kopf-(EKKO) oder Positions-(EKPO)-Tabellen. Der Zeitstempel wird aus den Änderungsbelegen (CDHDR/CDPOS) abgeleitet. Erfassen Zeitstempel aus Änderungsbelegen (CDHDR/CDPOS), wenn das Löschkennzeichen (LOEKZ) gesetzt ist. Ereignistyp explicit | |||
| `Waren zurückgesendet` | Zeigt an, dass zuvor erhaltene Waren an den Lieferanten zurückgesendet wurden, typischerweise aufgrund von Qualitätsproblemen, Beschädigungen oder falschen Lieferungen. Dies wird als explizite Stornierung der Warenbewegung erfasst. | ||
| Bedeutung Diese Aktivität hebt Nacharbeit und potenzielle Probleme mit der Lieferantenqualität oder der Bestellgenauigkeit hervor. Eine hohe Retourenhäufigkeit für einen bestimmten Lieferanten oder ein Material deutet auf ein Problem hin. Datenquelle Erfasst als Materialbeleg mit einer spezifischen Retourenbewegungsart (z.B. 122). Das Ereignis wird in MKPF/MSEG protokolliert und mit der Bestellung in der Historientabelle EKBE verknüpft. Erfassen Buchungsdatum aus dem Materialbeleg mit einer Retourenbewegungsart in EKBE. Ereignistyp explicit | |||
| Bestellung an Lieferanten gesendet | Stellt den Zeitpunkt dar, zu dem die Bestellung dem Lieferanten mitgeteilt wird, z.B. per EDI, E-Mail oder Ausdruck. Dieses Ereignis wird oft über die Protokolle des Ausgabemanagements des Systems erfasst. | ||
| Bedeutung Diese Aktivität ist der eigentliche Start der Lieferantenlieferzeit. Sie ist entscheidend für die genaue Messung der Lieferantenleistung ab dem Moment, in dem sie die Bestellung erhalten. Datenquelle Erfasst aus der Ausgabesteuerungstabelle NAST, die gesendete Nachrichten für ein Einkaufsdokument protokolliert. Datum und Uhrzeit des relevanten Ausgabetyps (z.B. EDI, E-Mail) können verwendet werden. Erfassen Zeitstempel der ersten erfolgreichen Ausgabenachricht für die Bestellung in der Tabelle NAST. Ereignistyp inferred | |||
| Bestellung geändert | Diese Aktivität zeigt an, dass eine Änderung an der Bestellung nach ihrer initialen Erstellung vorgenommen wurde, wie z.B. eine Änderung der Menge, des Preises oder des Lieferdatums. Sie wird explizit in den Systemänderungsprotokollen erfasst. | ||
| Bedeutung Das Nachverfolgen von Änderungen, insbesondere nach der Genehmigung, ist entscheidend, um Prozesseffizienz, Nacharbeit und potenzielle Compliance-Probleme zu identifizieren. Häufige Änderungen können auf mangelhafte initiale Spezifikationen hindeuten. Datenquelle Erfasst in den Änderungsbelegtabellen CDHDR (Kopf) und CDPOS (Position) für Bestellobjekte (EINKBELEG). Jede Änderung erzeugt einen detaillierten Protokolleintrag. Erfassen Event für Änderungen an Schlüsselfeldern in den Tabellen EKKO oder EKPO, erfasst in CDHDR/CDPOS. Ereignistyp explicit | |||
| Dienstleistungsbestätigung erfasst | Diese Aktivität markiert die Bestätigung, dass eine in einer Bestellung spezifizierte Leistung erbracht wurde. Sie wird explizit durch die Erstellung eines Leistungsnachweises erfasst. | ||
| Bedeutung Für die dienstleistungsbasierte Beschaffung ist dies das Äquivalent eines Wareneingangs. Es ist entscheidend für die Verfolgung von Dienstleistungsfristen und die Ermöglichung pünktlicher Lieferantenzahlungen. Datenquelle Erfasst durch die Erstellung eines Leistungsnachweises, wobei die Daten in den Tabellen ESSR (Kopf) und ESLL (Positionen) gespeichert werden. Das Erstellungsdatum dient als Zeitstempel. Erfassen Erstellungsdatum des Dienstleistungserfassungsbelegs in Tabelle ESSR. Ereignistyp explicit | |||
| Rechnung bezahlt | Markiert die endgültige Begleichung der Lieferantenrechnung durch einen Zahlungslauf oder manuelle Zahlung. Dies ist eine explizite Finanztransaktion, die ein Ausgleichsdokument erzeugt. | ||
| Bedeutung Obwohl technisch Teil des Zahlungsprozesses, bietet die Einbeziehung dieser Aktivität eine vollständige Ansicht des Procure-to-Pay-Zyklus. Sie ist entscheidend für die Analyse von Zahlungsbedingungen und Leistung. Datenquelle Die Zahlung wird als Ausgleichsdokument in BKPF/ACDOCA erfasst. Das Ausgleichsdatum (AUGDT) auf der Rechnungszeile in Tabelle BSEG oder ACDOCA zeigt das Zahlungsereignis an. Erfassen Ausgleichsdatum (AUGDT) des Rechnungsbelegs, zu finden in BSEG oder ACDOCA. Ereignistyp explicit | |||
Extraktionsleitfäden
Schritte
- Voraussetzungen und Zugang: Stellen Sie sicher, dass Sie einen Benutzer mit entsprechenden Berechtigungen zum Abfragen von Core Data Services (CDS) Views im SAP S/4HANA System haben. Der Zugang kann über SAP HANA Studio, ABAP Development Tools (ADT) für Eclipse oder ein Drittanbieter-Datenextraktionstool erfolgen, das SQL-Verbindungen zur SAP HANA Datenbank unterstützt.
- Systemverbindungsdetails ermitteln: Beschaffen Sie sich die notwendigen Verbindungsparameter für Ihr SAP S/4HANA System, einschließlich Host, Instanznummer und Ihre Authentifizierungsdaten.
- Verbindung zur Datenbank herstellen: Stellen Sie mit Ihrem bevorzugten SQL-Client eine Verbindung zur SAP S/4HANA Datenbank her, auf der die CDS-Views liegen.
- SQL-Abfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage, die im Abfrageabschnitt dieses Dokuments bereitgestellt wird, in Ihren SQL-Editor. Diese Abfrage ist darauf ausgelegt, alle erforderlichen Aktivitäten und Attribute zu extrahieren.
- Filterparameter festlegen: Suchen Sie die Platzhalterwerte innerhalb der Abfrage. Ersetzen Sie _start_date und _end_date durch den gewünschten Datumsbereich für Ihre Analyse (z.B. „20230101“ und „20231231“). Ändern Sie den Filter poh.CompanyCode, um die spezifischen Buchungskreise einzuschließen, die Sie analysieren möchten.
- Abfrage ausführen: Führen Sie die geänderte SQL-Abfrage gegen die S/4HANA Datenbank aus. Abhängig vom Datenvolumen und dem angegebenen Datumsbereich kann diese Ausführung einige Zeit in Anspruch nehmen.
- Vorläufige Ergebnisse überprüfen: Nach Abschluss der Abfrage überprüfen Sie kurz die Ausgabe in Ihrem SQL-Client. Prüfen Sie auf das Vorhandensein verschiedener Aktivitäten, stellen Sie sicher, dass Zeitstempel korrekt ausgefüllt sind, und verifizieren Sie, dass die Case-ID (PurchaseOrderNumber) konsistent ist.
- Daten exportieren: Exportieren Sie den vollständigen Ergebnissatz aus Ihrem SQL-Tool in eine CSV-Datei (Comma Separated Values). Stellen Sie sicher, dass die Datei die UTF-8-Kodierung verwendet, um Zeichenprobleme zu vermeiden.
- Für den Upload vorbereiten: Bevor Sie zu ProcessMind hochladen, öffnen Sie die CSV-Datei und überprüfen Sie, ob die Spaltenüberschriften genau mit den in den Datenanforderungen definierten Attributen (PurchaseOrderNumber, ActivityName, EventTime, etc.) übereinstimmen. Passen Sie die Spaltennamen an, falls Ihr Export-Tool diese geändert hat.
- Zu ProcessMind hochladen: Laden Sie die finalisierte CSV-Datei in Ihr ProcessMind Projekt hoch. Ordnen Sie die Spalten in Ihrer Datei während des Importvorgangs den entsprechenden Feldern für Case-ID, Aktivität und Zeitstempel zu.
Konfiguration
- Verwendete Schlüssel-CDS-Views: Die Extraktionslogik basiert auf einer Reihe von standardmäßigen, semantisch reichhaltigen CDS-Views. Die primären Views umfassen:
- I_PurchaseOrderItemAPI01: Für die Stammdaten der Bestellpositionen.
- I_PurchaseRequisitionItemAPI01: Für Bestellanforderungsdetails.
- I_MaterialDocumentItem: Für Warenbewegungen wie Zugänge und Retouren.
- I_ServiceEntrySheetAPI01: Für Dienstleistungserfassungsereignisse.
- I_SupplierInvoiceAPI01: Für Lieferantenrechnungsinformationen.
- I_OperationalAcctgDocItem: Zum Verknüpfen von Rechnungen mit Finanzdokumenten zur Zahlungsverfolgung.
- I_ChangeDocument: Zum Erfassen von Änderungen an der Bestellung.
- Datumsbereichsfilterung: Es ist entscheidend, einen Datumsbereichsfilter anzuwenden, um Leistung und Datenvolumen zu steuern. Die Abfrage verwendet Platzhalter _start_date und _end_date für das Bestelldatum (PurchaseOrderDate). Ein empfohlener Startbereich beträgt 3 bis 6 Monate Daten.
- Organisationale Filterung: Die Abfrage sollte immer nach CompanyCode gefiltert werden, um den Extraktionsumfang auf relevante Geschäftseinheiten zu beschränken. Zusätzliche Filter für PurchaseOrderType oder PurchasingOrganization können dem Haupt-CTE PO_base zur weiteren Verfeinerung hinzugefügt werden.
- Voraussetzungen: Der Benutzer, der die Abfrage ausführt, benötigt eine SELECT-Berechtigung für alle oben genannten CDS-Views. Der Zugriff auf diese Views wird typischerweise über spezifische Geschäfts- oder Analyse-Rollen in S/4HANA gewährt. Ohne entsprechende Berechtigungen schlägt die Abfrage fehl.
a Beispielabfrage sql
WITH PO_base AS (
SELECT
poh.PurchaseOrder AS PurchaseOrderNumber,
poi.PurchaseOrderItem AS PurchaseOrderItem,
poh.CompanyCode,
poh.PurchaseOrderType AS DocumentType,
poh.Supplier AS VendorId,
poh.PurchaseOrderDate,
poi.PurchaseRequisition AS PurchaseRequisitionNumber,
poi.NetPriceAmount * poi.OrderQuantity AS TotalNetAmount, -- Note: This is item-level net amount
poh.CreationDate AS POCreationDate,
poh.CreationTime AS POCreationTime,
poh.LastChangeDateTime AS POLastChangeDateTime,
poi.IsDeleted,
poi.DeliveryIsCompleted,
poi.FinalInvoiceIsExpected,
poi.GoodsReceiptIsExpected,
poi.LastGoodsReceiptDate,
poi.LastInvoiceReceiptDate
FROM I_PurchaseOrderAPI01 poh
JOIN I_PurchaseOrderItemAPI01 poi
ON poh.PurchaseOrder = poi.PurchaseOrder
WHERE
poh.PurchaseOrderDate BETWEEN '_start_date' AND '_end_date' -- Placeholder: e.g., '20230101' and '20230630'
AND poh.CompanyCode IN ('[YourCompanyCode]') -- Placeholder: e.g., '1010'
)
-- 1. Purchase Requisition Created
SELECT
po.PurchaseOrderNumber,
'Purchase Requisition Created' AS ActivityName,
CAST(CONCAT(pr.CreationDate, 'T', pr.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem, -- Placeholder
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
pr.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate, -- Available in PR, add if needed
po.DocumentType
FROM I_PurchaseRequisitionItemAPI01 pr
JOIN PO_base po
ON pr.PurchaseRequisition = po.PurchaseRequisitionNumber AND pr.PurchaseRequisitionItem = po.PurchaseOrderItem
UNION ALL
-- 2. Purchase Requisition Approved
SELECT
po.PurchaseOrderNumber,
'Purchase Requisition Approved' AS ActivityName,
CAST(CONCAT(pr.PurReqnReleaseDate, 'T', '000000') AS TIMESTAMP) AS EventTime, -- Time is not available in this view
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- Approver info requires complex joins
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_PurchaseRequisitionItemAPI01 pr
JOIN PO_base po
ON pr.PurchaseRequisition = po.PurchaseRequisitionNumber AND pr.PurchaseRequisitionItem = po.PurchaseOrderItem
WHERE
pr.PurReqnReleaseDate IS NOT NULL
UNION ALL
-- 3. Purchase Order Created
SELECT
po.PurchaseOrderNumber,
'Purchase Order Created' AS ActivityName,
CAST(CONCAT(po.POCreationDate, 'T', po.POCreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
poh.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
UNION ALL
-- 4. Purchase Order Approved
SELECT DISTINCT
po.PurchaseOrderNumber,
'Purchase Order Approved' AS ActivityName,
CAST(poh.ReleaseDate AS TIMESTAMP) AS EventTime, -- Assuming ReleaseDate reflects final approval
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- Approver info requires complex joins
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
WHERE poh.ReleaseDate IS NOT NULL
UNION ALL
-- 5. Purchase Order Sent to Vendor
SELECT DISTINCT
po.PurchaseOrderNumber,
'Purchase Order Sent to Vendor' AS ActivityName,
CAST(poh.ReleaseDate AS TIMESTAMP) AS EventTime, -- Using ReleaseDate as a proxy for sending time
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
WHERE poh.ReleaseDate IS NOT NULL
UNION ALL
-- 6. Purchase Order Changed
SELECT DISTINCT
ch.OBJECTID AS PurchaseOrderNumber,
'Purchase Order Changed' AS ActivityName,
CAST(CONCAT(ch.ChangeDocumentDate, 'T', ch.ChangeDocumentTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
ch.UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_ChangeDocument ch
JOIN PO_base po ON ch.OBJECTID = po.PurchaseOrderNumber
WHERE
ch.ObjectClassName = 'EINKBELEG' -- Object Class for Purchase Documents
AND CAST(CONCAT(ch.ChangeDocumentDate, 'T', ch.ChangeDocumentTime) AS TIMESTAMP) > CAST(CONCAT(po.POCreationDate, 'T', po.POCreationTime) AS TIMESTAMP)
UNION ALL
-- 7. Goods Receipt Posted
SELECT
po.PurchaseOrderNumber,
'Goods Receipt Posted' AS ActivityName,
CAST(CONCAT(md.PostingDate, 'T', md.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
md.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_MaterialDocumentItem md
JOIN PO_base po
ON md.PurchaseOrder = po.PurchaseOrderNumber AND md.PurchaseOrderItem = po.PurchaseOrderItem
WHERE
md.GoodsMovementType = '101'
UNION ALL
-- 8. Services Confirmation Entered
SELECT
po.PurchaseOrderNumber,
'Services Confirmation Entered' AS ActivityName,
CAST(se.PostingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
se.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_ServiceEntrySheetAPI01 se
JOIN PO_base po
ON se.PurchaseOrder = po.PurchaseOrderNumber AND se.PurchaseOrderItem = po.PurchaseOrderItem
UNION ALL
-- 9. Goods Returned
SELECT
po.PurchaseOrderNumber,
'Goods Returned' AS ActivityName,
CAST(CONCAT(md.PostingDate, 'T', md.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
md.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_MaterialDocumentItem md
JOIN PO_base po
ON md.PurchaseOrder = po.PurchaseOrderNumber AND md.PurchaseOrderItem = po.PurchaseOrderItem
WHERE
md.GoodsMovementType = '122'
UNION ALL
-- 10. Invoice Received
SELECT
po.PurchaseOrderNumber,
'Invoice Received' AS ActivityName,
CAST(inv.PostingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
inv.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_SupplierInvoiceAPI01 inv
JOIN PO_base po
ON inv.PurchaseOrderReference = po.PurchaseOrderNumber
WHERE
inv.DebitCreditCode = 'H' -- 'H' for Credit (Supplier Invoice)
UNION ALL
-- 11. Invoice Paid
SELECT
po.PurchaseOrderNumber,
'Invoice Paid' AS ActivityName,
CAST(doc.ClearingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
doc.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_SupplierInvoiceAPI01 inv
JOIN I_OperationalAcctgDocItem doc
ON inv.AccountingDocument = doc.AccountingDocument
JOIN PO_base po
ON inv.PurchaseOrderReference = po.PurchaseOrderNumber
WHERE
doc.IsCleared = 'X' AND doc.ClearingDate IS NOT NULL
UNION ALL
-- 12. Purchase Order Completed
SELECT
po.PurchaseOrderNumber,
'Purchase Order Completed' AS ActivityName,
CAST(GREATEST(po.LastGoodsReceiptDate, po.LastInvoiceReceiptDate) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
'SYSTEM' AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
WHERE
po.DeliveryIsCompleted = 'X'
AND (po.FinalInvoiceIsExpected = 'X' OR po.GoodsReceiptIsExpected = '') -- Logic for completion
AND GREATEST(po.LastGoodsReceiptDate, po.LastInvoiceReceiptDate) IS NOT NULL
UNION ALL
-- 13. Purchase Order Deleted
SELECT
po.PurchaseOrderNumber,
'Purchase Order Deleted' AS ActivityName,
CAST(po.POLastChangeDateTime AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- User who set the flag is in change docs
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
WHERE
po.IsDeleted = 'X' Schritte
- Voraussetzungen und Zugang: Stellen Sie sicher, dass Sie einen Benutzer mit entsprechenden Berechtigungen zum Abfragen von Core Data Services (CDS) Views im SAP S/4HANA System haben. Der Zugang kann über SAP HANA Studio, ABAP Development Tools (ADT) für Eclipse oder ein Drittanbieter-Datenextraktionstool erfolgen, das SQL-Verbindungen zur SAP HANA Datenbank unterstützt.
- Systemverbindungsdetails ermitteln: Beschaffen Sie sich die notwendigen Verbindungsparameter für Ihr SAP S/4HANA System, einschließlich Host, Instanznummer und Ihre Authentifizierungsdaten.
- Verbindung zur Datenbank herstellen: Stellen Sie mit Ihrem bevorzugten SQL-Client eine Verbindung zur SAP S/4HANA Datenbank her, auf der die CDS-Views liegen.
- SQL-Abfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage, die im Abfrageabschnitt dieses Dokuments bereitgestellt wird, in Ihren SQL-Editor. Diese Abfrage ist darauf ausgelegt, alle erforderlichen Aktivitäten und Attribute zu extrahieren.
- Filterparameter festlegen: Suchen Sie die Platzhalterwerte innerhalb der Abfrage. Ersetzen Sie _start_date und _end_date durch den gewünschten Datumsbereich für Ihre Analyse (z.B. „20230101“ und „20231231“). Ändern Sie den Filter poh.CompanyCode, um die spezifischen Buchungskreise einzuschließen, die Sie analysieren möchten.
- Abfrage ausführen: Führen Sie die geänderte SQL-Abfrage gegen die S/4HANA Datenbank aus. Abhängig vom Datenvolumen und dem angegebenen Datumsbereich kann diese Ausführung einige Zeit in Anspruch nehmen.
- Vorläufige Ergebnisse überprüfen: Nach Abschluss der Abfrage überprüfen Sie kurz die Ausgabe in Ihrem SQL-Client. Prüfen Sie auf das Vorhandensein verschiedener Aktivitäten, stellen Sie sicher, dass Zeitstempel korrekt ausgefüllt sind, und verifizieren Sie, dass die Case-ID (PurchaseOrderNumber) konsistent ist.
- Daten exportieren: Exportieren Sie den vollständigen Ergebnissatz aus Ihrem SQL-Tool in eine CSV-Datei (Comma Separated Values). Stellen Sie sicher, dass die Datei die UTF-8-Kodierung verwendet, um Zeichenprobleme zu vermeiden.
- Für den Upload vorbereiten: Bevor Sie zu ProcessMind hochladen, öffnen Sie die CSV-Datei und überprüfen Sie, ob die Spaltenüberschriften genau mit den in den Datenanforderungen definierten Attributen (PurchaseOrderNumber, ActivityName, EventTime, etc.) übereinstimmen. Passen Sie die Spaltennamen an, falls Ihr Export-Tool diese geändert hat.
- Zu ProcessMind hochladen: Laden Sie die finalisierte CSV-Datei in Ihr ProcessMind Projekt hoch. Ordnen Sie die Spalten in Ihrer Datei während des Importvorgangs den entsprechenden Feldern für Case-ID, Aktivität und Zeitstempel zu.
Konfiguration
- Verwendete Schlüssel-CDS-Views: Die Extraktionslogik basiert auf einer Reihe von standardmäßigen, semantisch reichhaltigen CDS-Views. Die primären Views umfassen:
- I_PurchaseOrderItemAPI01: Für die Stammdaten der Bestellpositionen.
- I_PurchaseRequisitionItemAPI01: Für Bestellanforderungsdetails.
- I_MaterialDocumentItem: Für Warenbewegungen wie Zugänge und Retouren.
- I_ServiceEntrySheetAPI01: Für Dienstleistungserfassungsereignisse.
- I_SupplierInvoiceAPI01: Für Lieferantenrechnungsinformationen.
- I_OperationalAcctgDocItem: Zum Verknüpfen von Rechnungen mit Finanzdokumenten zur Zahlungsverfolgung.
- I_ChangeDocument: Zum Erfassen von Änderungen an der Bestellung.
- Datumsbereichsfilterung: Es ist entscheidend, einen Datumsbereichsfilter anzuwenden, um Leistung und Datenvolumen zu steuern. Die Abfrage verwendet Platzhalter _start_date und _end_date für das Bestelldatum (PurchaseOrderDate). Ein empfohlener Startbereich beträgt 3 bis 6 Monate Daten.
- Organisationale Filterung: Die Abfrage sollte immer nach CompanyCode gefiltert werden, um den Extraktionsumfang auf relevante Geschäftseinheiten zu beschränken. Zusätzliche Filter für PurchaseOrderType oder PurchasingOrganization können dem Haupt-CTE PO_base zur weiteren Verfeinerung hinzugefügt werden.
- Voraussetzungen: Der Benutzer, der die Abfrage ausführt, benötigt eine SELECT-Berechtigung für alle oben genannten CDS-Views. Der Zugriff auf diese Views wird typischerweise über spezifische Geschäfts- oder Analyse-Rollen in S/4HANA gewährt. Ohne entsprechende Berechtigungen schlägt die Abfrage fehl.
a Beispielabfrage sql
WITH PO_base AS (
SELECT
poh.PurchaseOrder AS PurchaseOrderNumber,
poi.PurchaseOrderItem AS PurchaseOrderItem,
poh.CompanyCode,
poh.PurchaseOrderType AS DocumentType,
poh.Supplier AS VendorId,
poh.PurchaseOrderDate,
poi.PurchaseRequisition AS PurchaseRequisitionNumber,
poi.NetPriceAmount * poi.OrderQuantity AS TotalNetAmount, -- Note: This is item-level net amount
poh.CreationDate AS POCreationDate,
poh.CreationTime AS POCreationTime,
poh.LastChangeDateTime AS POLastChangeDateTime,
poi.IsDeleted,
poi.DeliveryIsCompleted,
poi.FinalInvoiceIsExpected,
poi.GoodsReceiptIsExpected,
poi.LastGoodsReceiptDate,
poi.LastInvoiceReceiptDate
FROM I_PurchaseOrderAPI01 poh
JOIN I_PurchaseOrderItemAPI01 poi
ON poh.PurchaseOrder = poi.PurchaseOrder
WHERE
poh.PurchaseOrderDate BETWEEN '_start_date' AND '_end_date' -- Placeholder: e.g., '20230101' and '20230630'
AND poh.CompanyCode IN ('[YourCompanyCode]') -- Placeholder: e.g., '1010'
)
-- 1. Purchase Requisition Created
SELECT
po.PurchaseOrderNumber,
'Purchase Requisition Created' AS ActivityName,
CAST(CONCAT(pr.CreationDate, 'T', pr.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem, -- Placeholder
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
pr.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate, -- Available in PR, add if needed
po.DocumentType
FROM I_PurchaseRequisitionItemAPI01 pr
JOIN PO_base po
ON pr.PurchaseRequisition = po.PurchaseRequisitionNumber AND pr.PurchaseRequisitionItem = po.PurchaseOrderItem
UNION ALL
-- 2. Purchase Requisition Approved
SELECT
po.PurchaseOrderNumber,
'Purchase Requisition Approved' AS ActivityName,
CAST(CONCAT(pr.PurReqnReleaseDate, 'T', '000000') AS TIMESTAMP) AS EventTime, -- Time is not available in this view
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- Approver info requires complex joins
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_PurchaseRequisitionItemAPI01 pr
JOIN PO_base po
ON pr.PurchaseRequisition = po.PurchaseRequisitionNumber AND pr.PurchaseRequisitionItem = po.PurchaseOrderItem
WHERE
pr.PurReqnReleaseDate IS NOT NULL
UNION ALL
-- 3. Purchase Order Created
SELECT
po.PurchaseOrderNumber,
'Purchase Order Created' AS ActivityName,
CAST(CONCAT(po.POCreationDate, 'T', po.POCreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
poh.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
UNION ALL
-- 4. Purchase Order Approved
SELECT DISTINCT
po.PurchaseOrderNumber,
'Purchase Order Approved' AS ActivityName,
CAST(poh.ReleaseDate AS TIMESTAMP) AS EventTime, -- Assuming ReleaseDate reflects final approval
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- Approver info requires complex joins
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
WHERE poh.ReleaseDate IS NOT NULL
UNION ALL
-- 5. Purchase Order Sent to Vendor
SELECT DISTINCT
po.PurchaseOrderNumber,
'Purchase Order Sent to Vendor' AS ActivityName,
CAST(poh.ReleaseDate AS TIMESTAMP) AS EventTime, -- Using ReleaseDate as a proxy for sending time
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
poi.RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
JOIN I_PurchaseOrderAPI01 poh ON po.PurchaseOrderNumber = poh.PurchaseOrder
JOIN I_PurchaseOrderItemAPI01 poi ON po.PurchaseOrderNumber = poi.PurchaseOrder AND po.PurchaseOrderItem = poi.PurchaseOrderItem
WHERE poh.ReleaseDate IS NOT NULL
UNION ALL
-- 6. Purchase Order Changed
SELECT DISTINCT
ch.OBJECTID AS PurchaseOrderNumber,
'Purchase Order Changed' AS ActivityName,
CAST(CONCAT(ch.ChangeDocumentDate, 'T', ch.ChangeDocumentTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
ch.UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_ChangeDocument ch
JOIN PO_base po ON ch.OBJECTID = po.PurchaseOrderNumber
WHERE
ch.ObjectClassName = 'EINKBELEG' -- Object Class for Purchase Documents
AND CAST(CONCAT(ch.ChangeDocumentDate, 'T', ch.ChangeDocumentTime) AS TIMESTAMP) > CAST(CONCAT(po.POCreationDate, 'T', po.POCreationTime) AS TIMESTAMP)
UNION ALL
-- 7. Goods Receipt Posted
SELECT
po.PurchaseOrderNumber,
'Goods Receipt Posted' AS ActivityName,
CAST(CONCAT(md.PostingDate, 'T', md.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
md.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_MaterialDocumentItem md
JOIN PO_base po
ON md.PurchaseOrder = po.PurchaseOrderNumber AND md.PurchaseOrderItem = po.PurchaseOrderItem
WHERE
md.GoodsMovementType = '101'
UNION ALL
-- 8. Services Confirmation Entered
SELECT
po.PurchaseOrderNumber,
'Services Confirmation Entered' AS ActivityName,
CAST(se.PostingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
se.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_ServiceEntrySheetAPI01 se
JOIN PO_base po
ON se.PurchaseOrder = po.PurchaseOrderNumber AND se.PurchaseOrderItem = po.PurchaseOrderItem
UNION ALL
-- 9. Goods Returned
SELECT
po.PurchaseOrderNumber,
'Goods Returned' AS ActivityName,
CAST(CONCAT(md.PostingDate, 'T', md.CreationTime) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
md.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_MaterialDocumentItem md
JOIN PO_base po
ON md.PurchaseOrder = po.PurchaseOrderNumber AND md.PurchaseOrderItem = po.PurchaseOrderItem
WHERE
md.GoodsMovementType = '122'
UNION ALL
-- 10. Invoice Received
SELECT
po.PurchaseOrderNumber,
'Invoice Received' AS ActivityName,
CAST(inv.PostingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
inv.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_SupplierInvoiceAPI01 inv
JOIN PO_base po
ON inv.PurchaseOrderReference = po.PurchaseOrderNumber
WHERE
inv.DebitCreditCode = 'H' -- 'H' for Credit (Supplier Invoice)
UNION ALL
-- 11. Invoice Paid
SELECT
po.PurchaseOrderNumber,
'Invoice Paid' AS ActivityName,
CAST(doc.ClearingDate AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
doc.CreatedByUser AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM I_SupplierInvoiceAPI01 inv
JOIN I_OperationalAcctgDocItem doc
ON inv.AccountingDocument = doc.AccountingDocument
JOIN PO_base po
ON inv.PurchaseOrderReference = po.PurchaseOrderNumber
WHERE
doc.IsCleared = 'X' AND doc.ClearingDate IS NOT NULL
UNION ALL
-- 12. Purchase Order Completed
SELECT
po.PurchaseOrderNumber,
'Purchase Order Completed' AS ActivityName,
CAST(GREATEST(po.LastGoodsReceiptDate, po.LastInvoiceReceiptDate) AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
'SYSTEM' AS UserName,
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
WHERE
po.DeliveryIsCompleted = 'X'
AND (po.FinalInvoiceIsExpected = 'X' OR po.GoodsReceiptIsExpected = '') -- Logic for completion
AND GREATEST(po.LastGoodsReceiptDate, po.LastInvoiceReceiptDate) IS NOT NULL
UNION ALL
-- 13. Purchase Order Deleted
SELECT
po.PurchaseOrderNumber,
'Purchase Order Deleted' AS ActivityName,
CAST(po.POLastChangeDateTime AS TIMESTAMP) AS EventTime,
'[Your S/4HANA System ID]' AS SourceSystem,
CURRENT_UTCTIMESTAMP AS LastDataUpdate,
po.VendorId,
NULL AS UserName, -- User who set the flag is in change docs
po.TotalNetAmount,
po.PurchaseRequisitionNumber,
NULL AS RequestedDeliveryDate,
po.DocumentType
FROM PO_base po
WHERE
po.IsDeleted = 'X' Schritte
- Spezifikation und Design: Definieren Sie die endgültige Datenstruktur für die Event-Log-Datei, einschließlich aller erforderlichen und empfohlenen Attribute. Dokumentieren Sie die spezifischen SAP-Tabellen (z.B. EKKO, EKPO, EKBE, CDHDR, CDPOS, BKPF), die zur Beschaffung von Daten für jede der 13 erforderlichen Aktivitäten verwendet werden.
- Programmerstellung: Navigieren Sie in der SAP GUI zum ABAP Editor über den Transaktionscode SE38 oder SE80. Erstellen Sie ein neues ausführbares Programm, z.B. Z_PM_PO_EXTRACT.
- Selektionsbild definieren: Programmieren Sie das Selektionsbild für den Bericht. Dies ermöglicht Benutzern, die Daten zu filtern, die sie extrahieren möchten. Fügen Sie Parameter für den Erstellungsdatumsbereich der Bestellung (P_AEDAT), den Buchungskreis (P_BUKRS) und den Bestelldokumenttyp (P_BSART) hinzu.
- Datendeklarationen: Definieren Sie die für das Programm benötigten internen Tabellen und Datenstrukturen. Dazu gehört eine interne Tabelle für das finale Event-Log, die der im Spezifikationsschritt definierten Struktur entspricht.
- Datenlogik implementieren: Schreiben Sie die Kern-ABAP-Logik, um Daten für jede der 13 Aktivitäten auszuwählen. Dies umfasst eine Reihe von SELECT-Anweisungen gegen die relevanten SAP-Tabellen, gegebenenfalls mit Joins. Für änderungsbasierte Events lesen Sie aus den Änderungsbelegtabellen CDHDR und CDPOS.
- Daten transformieren und zuordnen: Ordnen Sie für jeden abgerufenen Datensatz die SAP-Tabellenfelder den entsprechenden Spalten in Ihrer finalen Event-Log-internen Tabelle zu. Legen Sie den ActivityName basierend auf dem zu verarbeitenden Event fest (z.B. „Bestellung erstellt“). Konvertieren Sie Datums- und Zeitfelder in ein konsistentes Zeitstempelformat für EventTime.
- Event-Daten konsolidieren: Nachdem alle 13 Aktivitätstypen verarbeitet wurden, stellen Sie sicher, dass alle Daten in einer einzigen, einheitlichen internen Tabelle gesammelt werden. Diese Tabelle repräsentiert nun das vollständige Event-Log für die ausgewählten Bestellungen.
- Dateiausgabe implementieren: Fügen Sie Funktionen hinzu, um die finale interne Tabelle in eine Datei zu schreiben. Der empfohlene Ansatz ist die Verwendung der cl_gui_frontend_services=>gui_download Methode, um Benutzern zu ermöglichen, die Datei als CSV auf ihrem lokalen Rechner zu speichern, oder OPEN DATASET, um sie für die Hintergrundverarbeitung auf dem SAP-Anwendungsserver zu speichern.
- Transaktionscode erstellen (Optional): Um das Programm für Geschäftsanwender leicht zugänglich zu machen, verwenden Sie den Transaktionscode SE93, um einen benutzerdefinierten Transaktionscode (z.B. ZPM_PO_EXTRACT) zu erstellen, der Ihr ABAP-Programm ausführt.
- Hintergrundjob planen: Für große Datenmengen oder automatisierte Extraktionen verwenden Sie den Transaktionscode SM36, um das Programm als Hintergrundjob zu planen. Die Ausgabedatei wird im im Programmlogik angegebenen Pfad des Anwendungsservers gespeichert.
Konfiguration
- Selektionskriterien: Das Programm sollte Selektionsparameter zur effektiven Filterung der Daten enthalten. Wichtige Filter sind:
- Datumsbereich: Ein obligatorischer Datumsbereich für das Bestelldatum (EKKO-AEDAT). Es wird empfohlen, mit einem Zeitraum von 3-6 Monaten zu beginnen, um das Datenvolumen und die Berichtsleistung zu steuern.
- Buchungskreis (BUKRS): Unverzichtbar für Organisationen mit mehreren juristischen Einheiten, um den Extraktionsumfang einzugrenzen.
- Bestelldokumenttyp (BSART): Ermöglicht die Filterung spezifischer Bestelldokumenttypen, wie z.B. Standardbestellung, Rahmenvertrag oder Umlagerungsbestellung, um die Analyse zu fokussieren.
- Lesen der Änderungsbelege: Die Extraktion von Aktivitäten wie „Bestellung genehmigt“ oder „Bestellung geändert“ basiert auf dem Lesen der SAP-Änderungsbelegtabellen (CDHDR, CDPOS). Dies kann ressourcenintensiv sein. Die ABAP-Logik sollte optimiert werden, um nur die notwendigen Objektklassen (EINKBELEG, BANF) und Tabellen-/Feldkombinationen auszuwählen.
- Berechtigungen: Der Benutzer oder das technische Konto, das diesen Bericht ausführt, benötigt umfassende Leseberechtigungen für Tabellen über mehrere SAP-Module hinweg, einschließlich Materialwirtschaft (MM), Finanzbuchhaltung (FI) und systemweite Tabellen. Dazu gehören Tabellen wie EKKO, EKPO, EBAN, EKBE, BKPF, BSAK, RBKP, NAST, CDHDR und CDPOS.
- Hintergrundausführung: Bei Extraktionen, die Daten über mehr als einige Monate umfassen oder in einem System mit hohem Transaktionsvolumen laufen, sollte das Programm immer im Hintergrund ausgeführt werden, um Timeouts bei Dialogprozessen zu vermeiden.
a Beispielabfrage abap
REPORT z_pm_po_extract.
" ====================================================================
" SELECTION SCREEN
" ====================================================================
SELECTION-SCREEN BEGIN OF BLOCK b1 WITH FRAME TITLE TEXT-001.
SELECT-OPTIONS: s_aedat FOR sy-datum OBLIGATORY.
SELECT-OPTIONS: s_bukrs FOR ekko-bukrs.
SELECT-OPTIONS: s_bsart FOR ekko-bsart.
PARAMETERS: p_sysid TYPE string DEFAULT '[Your SAP System ID]'.
SELECTION-SCREEN END OF BLOCK b1.
" ====================================================================
" DATA DECLARATIONS
" ====================================================================
TYPES: BEGIN OF ty_event_log,
purchaseordernumber TYPE ebeln,
activityname TYPE string,
eventtime TYPE timestamp,
sourcesystem TYPE string,
lastdataupdate TYPE timestamp,
vendorid TYPE lifnr,
username TYPE ernam,
totalnetamount TYPE netwr,
purchaserequisitionnumber TYPE banfn,
requesteddeliverydate TYPE eedat,
documenttype TYPE bsart,
END OF ty_event_log.
DATA: lt_event_log TYPE TABLE OF ty_event_log,
ls_event_log TYPE ty_event_log.
DATA: lt_ekko TYPE TABLE OF ekko,
lt_ekpo TYPE TABLE OF ekpo.
" ====================================================================
" START OF SELECTION
" ====================================================================
START-OF-SELECTION.
" Get current timestamp for LastDataUpdate
GET TIME STAMP FIELD ls_event_log-lastdataupdate.
ls_event_log-sourcesystem = p_sysid.
" --- Initial Data Selection: Purchase Orders in Scope ---
SELECT * FROM ekko INTO TABLE lt_ekko
WHERE aedat IN s_aedat
AND bukrs IN s_bukrs
AND bsart IN s_bsart.
IF lt_ekko IS INITIAL.
MESSAGE 'No Purchase Orders found for the given criteria.' TYPE 'S' DISPLAY LIKE 'E'.
RETURN.
ENDIF.
SELECT * FROM ekpo INTO TABLE lt_ekpo
FOR ALL ENTRIES IN lt_ekko
WHERE ebeln = lt_ekko-ebeln.
" --- 1. Purchase Requisition Created ---
SELECT ban.banfn, ban.erdat, ban.erzet, ban.ernam,
ekpo.ebeln, ekpo.netwr, ekpo.eindt, ekpo.bsart, ekpo.lifnr, ekko.bukrs
FROM eban AS ban
INNER JOIN ekpo AS ekpo ON ban.banfn = ekpo.banfn AND ban.bnfpo = ekpo.bnfpo
INNER JOIN ekko AS ekko ON ekpo.ebeln = ekko.ebeln
WHERE ekko.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_pr_created).
LOOP AT lt_pr_created INTO DATA(ls_pr_created).
ls_event_log-purchaseordernumber = ls_pr_created-ebeln.
ls_event_log-activityname = 'Purchase Requisition Created'.
CONVERT DATE ls_pr_created-erdat TIME ls_pr_created-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-vendorid = ls_pr_created-lifnr.
ls_event_log-username = ls_pr_created-ernam.
ls_event_log-totalnetamount = ls_pr_created-netwr.
ls_event_log-purchaserequisitionnumber = ls_pr_created-banfn.
ls_event_log-requesteddeliverydate = ls_pr_created-eindt.
ls_event_log-documenttype = ls_pr_created-bsart.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 2. Purchase Requisition Approved (via Change Docs on Release Indicator) ---
SELECT h.objectid, h.udate, h.utime, h.username
FROM cdhdr AS h
INNER JOIN cdpos AS p ON h.objectclas = p.objectclas AND h.objectid = p.objectid AND h.changenr = p.changenr
INNER JOIN ekpo AS ekpo ON h.objectid = ekpo.banfn
INNER JOIN ekko AS ekko ON ekpo.ebeln = ekko.ebeln
WHERE h.objectclas = 'BANF'
AND p.tabname = 'EBAN'
AND p.fname = 'FRGZU'
AND p.value_new = 'X' "Configure based on your system release indicator for 'Approved'
AND ekko.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_pr_approved).
LOOP AT lt_pr_approved INTO DATA(ls_pr_approved).
SELECT SINGLE ebeln FROM ekpo INTO ls_event_log-purchaseordernumber WHERE banfn = ls_pr_approved-objectid.
ls_event_log-activityname = 'Purchase Requisition Approved'.
CONVERT DATE ls_pr_approved-udate TIME ls_pr_approved-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_pr_approved-username.
" Other attributes can be populated with another SELECT if needed.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 3. Purchase Order Created ---
LOOP AT lt_ekko INTO DATA(ls_ekko_created).
ls_event_log-purchaseordernumber = ls_ekko_created-ebeln.
ls_event_log-activityname = 'Purchase Order Created'.
CONVERT DATE ls_ekko_created-aedat TIME ls_ekko_created-erzet INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-vendorid = ls_ekko_created-lifnr.
ls_event_log-username = ls_ekko_created-ernam.
ls_event_log-totalnetamount = ls_ekko_created-rlwrt.
ls_event_log-purchaserequisitionnumber = ''. "Can be enriched later if needed
ls_event_log-requesteddeliverydate = ''. "Can be enriched from EKPO
ls_event_log-documenttype = ls_ekko_created-bsart.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 4. Purchase Order Approved (via Change Docs on Release Indicator) ---
SELECT h.objectid, h.udate, h.utime, h.username
FROM cdhdr AS h
INNER JOIN cdpos AS p ON h.objectclas = p.objectclas AND h.objectid = p.objectid AND h.changenr = p.changenr
WHERE h.objectclas = 'EINKBELEG'
AND p.tabname = 'EKKO'
AND p.fname = 'FRGKE'
AND p.value_new = 'R' "R for Released
AND h.objectid IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_approved).
LOOP AT lt_po_approved INTO DATA(ls_po_approved).
ls_event_log-purchaseordernumber = ls_po_approved-objectid.
ls_event_log-activityname = 'Purchase Order Approved'.
CONVERT DATE ls_po_approved-udate TIME ls_po_approved-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_approved-username.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 5. Purchase Order Sent to Vendor ---
SELECT n.objky, n.vstat, n.datvr, n.uhrvr, e.ernam
FROM nast AS n
INNER JOIN ekko AS e ON n.objky = e.ebeln
WHERE n.kappl = 'EF' "Application for Purchasing
AND n.kschl = '[Your PO Output Type]' "e.g. NEU
AND n.vstat = '1' "Successfully processed
AND n.objky IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_sent).
LOOP AT lt_po_sent INTO DATA(ls_po_sent).
ls_event_log-purchaseordernumber = ls_po_sent-objky.
ls_event_log-activityname = 'Purchase Order Sent to Vendor'.
CONVERT DATE ls_po_sent-datvr TIME ls_po_sent-uhrvr INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_sent-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 6. Purchase Order Changed ---
SELECT objectid, udate, utime, username FROM cdhdr
WHERE objectclas = 'EINKBELEG'
AND tcode IN ('ME22', 'ME22N')
AND objectid IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_changed).
LOOP AT lt_po_changed INTO DATA(ls_po_changed).
ls_event_log-purchaseordernumber = ls_po_changed-objectid.
ls_event_log-activityname = 'Purchase Order Changed'.
CONVERT DATE ls_po_changed-udate TIME ls_po_changed-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_changed-username.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 7. Goods Receipt Posted & 9. Goods Returned ---
SELECT e.ebeln, m.budat, m.cpudt, m.cputm, m.usnam, b.shkzg, b.bwart
FROM mkpf AS m
INNER JOIN mseg AS s ON m.mblnr = s.mblnr AND m.mjahr = s.mjahr
INNER JOIN t156 AS t ON s.bwart = t.bwart
INNER JOIN ekbe AS e ON s.ebeln = e.ebeln AND s.ebelp = e.ebelp AND s.mblnr = e.belnr AND s.mjahr = e.gjahr
WHERE e.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
AND e.bwart IN ('101', '102', '122', '123') "GR, GR Reversal, Return
INTO TABLE @DATA(lt_goods_mvmt).
LOOP AT lt_goods_mvmt INTO DATA(ls_goods_mvmt).
ls_event_log-purchaseordernumber = ls_goods_mvmt-ebeln.
IF ls_goods_mvmt-bwart = '101'.
ls_event_log-activityname = 'Goods Receipt Posted'.
ELSE.
ls_event_log-activityname = 'Goods Returned'.
ENDIF.
CONVERT DATE ls_goods_mvmt-cpudt TIME ls_goods_mvmt-cputm INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_goods_mvmt-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 8. Services Confirmation Entered ---
SELECT h.erdat, h.erzeit, h.ernam, l.ebeln
FROM essr AS h
INNER JOIN esll AS l ON h.lblni = l.lblni
WHERE l.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_services).
LOOP AT lt_services INTO DATA(ls_services).
ls_event_log-purchaseordernumber = ls_services-ebeln.
ls_event_log-activityname = 'Services Confirmation Entered'.
CONVERT DATE ls_services-erdat TIME ls_services-erzeit INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_services-ernam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 10. Invoice Received ---
SELECT r.ebeln, r.cpudt, r.cputm, r.usnam
FROM rbkp AS r
WHERE r.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_invoice_rcvd).
LOOP AT lt_invoice_rcvd INTO DATA(ls_invoice_rcvd).
ls_event_log-purchaseordernumber = ls_invoice_rcvd-ebeln.
ls_event_log-activityname = 'Invoice Received'.
CONVERT DATE ls_invoice_rcvd-cpudt TIME ls_invoice_rcvd-cputm INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_invoice_rcvd-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 11. Invoice Paid ---
SELECT b.ebeln, s.augdt, s.augbl, b.usnam
FROM rbkp AS b
INNER JOIN bseg AS e ON b.belnr = e.belnr AND b.gjahr = e.gjahr
INNER JOIN bsak AS s ON e.bukrs = s.bukrs AND e.belnr = s.belnr AND e.gjahr = s.gjahr AND e.buzei = s.buzei
WHERE b.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
AND s.augdt IS NOT NULL
INTO TABLE @DATA(lt_invoice_paid).
LOOP AT lt_invoice_paid INTO DATA(ls_invoice_paid).
ls_event_log-purchaseordernumber = ls_invoice_paid-ebeln.
ls_event_log-activityname = 'Invoice Paid'.
CONVERT DATE ls_invoice_paid-augdt INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_invoice_paid-usnam.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- 12. Purchase Order Completed & 13. Purchase Order Deleted (via Change Docs) ---
SELECT h.objectid, h.udate, h.utime, h.username, p.fname
FROM cdhdr AS h
INNER JOIN cdpos AS p ON h.changenr = p.changenr
INNER JOIN ekpo AS ekpo ON h.objectid = |{ ekpo.ebeln }{ ekpo.ebelp }|
WHERE h.objectclas = 'EINKBELEG'
AND p.tabname = 'EKPO'
AND p.fname IN ('ELIKZ', 'EREKZ', 'LOEKZ')
AND p.value_new = 'X'
AND ekpo.ebeln IN @( VALUE #( FOR ls_ekko IN lt_ekko ( ls_ekko-ebeln ) ) )
INTO TABLE @DATA(lt_po_status_change).
LOOP AT lt_po_status_change INTO DATA(ls_po_status_change).
ls_event_log-purchaseordernumber = substring( val = ls_po_status_change-objectid, off = 0, len = 10 ).
CASE ls_po_status_change-fname.
WHEN 'LOEKZ'.
ls_event_log-activityname = 'Purchase Order Deleted'.
WHEN 'ELIKZ' OR 'EREKZ'.
"This logic may need refinement to check if both are now set.
ls_event_log-activityname = 'Purchase Order Completed'.
ENDCASE.
CONVERT DATE ls_po_status_change-udate TIME ls_po_status_change-utime INTO TIME STAMP ls_event_log-eventtime TIME ZONE sy-zonlo.
ls_event_log-username = ls_po_status_change-username.
APPEND ls_event_log TO lt_event_log.
ENDLOOP.
" --- Final Output to CSV ---
CALL METHOD cl_gui_frontend_services=>gui_download
EXPORTING
filename = 'C:\temp\po_event_log.csv'
filetype = 'ASC'
CHANGING
data_tab = lt_event_log.