Ihr Datentemplate für den Order-to-Cash-Prozess: Fakturierung und Rechnungsstellung
Ihr Datentemplate für den Order-to-Cash-Prozess: Fakturierung und Rechnungsstellung
- Empfohlene Attribute für eine umfassende Analyse
- Wichtige Prozessschritte und Meilensteine zur Nachverfolgung
- Praktische Hinweise zur Datenextraktion aus SAP ECC
Attribute für Order-to-Cash: Fakturierung und Rechnungsstellung
| Name | Beschreibung | ||
|---|---|---|---|
| Aktivität ActivityName | Die Bezeichnung des Geschäftsereignisses oder Prozessschritts im Lebenszyklus einer Rechnung. | ||
| Beschreibung Dieses Attribut beschreibt eine konkrete Aktion oder Statusänderung im Fakturierungsprozess, zum Beispiel „Rechnung erzeugt“, „Rechnung gebucht“ oder „Kundenzahlung eingegangen“. Die Aktivitäten werden konzeptionell aus verschiedenen Systemereignissen, Statusänderungen in Belegen oder von Benutzern ausgeführten Transaktionscodes abgeleitet. Die Abfolge dieser Aktivitäten bildet den Prozessfluss und ist die Grundlage der Process-Mining-Analyse. Anhand der Aktivitäten erkennen Unternehmen, welche Schritte in welcher Reihenfolge und wie häufig ausgeführt werden. So lässt sich die tatsächliche Prozessausführung mit dem geplanten Prozess vergleichen. Warum das wichtig ist Sie legt die Schritte in der Prozessdarstellung fest und ermöglicht es, Prozessabläufe, Abweichungen und Engpässe sichtbar zu machen und zu analysieren. Woher beziehen Dieses konzeptionelle Attribut wird aus mehreren Quellen abgeleitet, etwa aus Transaktionscodes (CDHDR-TCODE), Belegstatusänderungen (VBUK-FKSTK) und Buchungen von Buchhaltungsbelegen. Beispiele Rechnung erstelltRechnung gebuchtZahlungserinnerung versendetRechnung ausgeglichen | |||
| Rechnungsnummer InvoiceNumber | Die eindeutige Kennung des Fakturabelegs, die als primäre Case-ID für den Rechnungsprozess dient. | ||
| Beschreibung Die Rechnungsnummer, in SAP als Fakturabelegnummer bezeichnet, identifiziert jede Rechnung eindeutig. Im Process Mining dient sie als Case-ID und fasst alle zugehörigen Aktivitäten wie Erstellung, Buchung, Versand, Zahlung und Ausgleich zu einem durchgängigen Prozessfall zusammen. Die Analyse nach Rechnungsnummer ermöglicht einen vollständigen Überblick über den Lebenszyklus jeder Fakturatransaktion, von der Erstellung bis zum endgültigen Ausgleich. Das ist entscheidend für die Berechnung wichtiger Kennzahlen wie Days Sales Outstanding (DSO) und der gesamten Rechnungsdurchlaufzeit. So entsteht eine klare Grundlage, um die Leistung zu messen und Verbesserungen abzuleiten. Warum das wichtig ist Sie ist der zentrale Schlüssel, um den gesamten Verlauf einer Rechnung nachzuverfolgen und Durchlaufzeiten, Engpässe und Abweichungen für jede einzelne Fakturatransaktion zu analysieren. Woher beziehen SAP-ECC-Tabelle: VBRK, Feld: VBELN Beispiele 90001234900012359000123690001237 | |||
| Startzeit EventTime | Der Timestamp, der angibt, wann eine bestimmte Aktivität oder ein Ereignis stattgefunden hat. | ||
| Beschreibung Der Ereigniszeitpunkt erfasst Datum und Uhrzeit jeder Aktivität im Lebenszyklus einer Rechnung. Dieser Timestamp ist die Grundlage für alle zeitbezogenen Process-Mining-Analysen, darunter die Berechnung von Durchlaufzeiten, die Ermittlung von Engpässen und die Überwachung der Prozessleistung anhand von Service-Level-Vereinbarungen. Das Attribut wird in der Regel aus einem Datumsfeld wie dem Buchungsdatum (BUDAT) und einem Zeitfeld (UZEIT) aus verschiedenen SAP-Tabellen gebildet, in denen Änderungen oder die Belegerstellung erfasst werden. Genaue Timestamps sind entscheidend für ein zuverlässiges Event Log und aussagekräftige Leistungsanalysen. Warum das wichtig ist Dieses Attribut bildet die Grundlage für alle Leistungsanalysen. Es ermöglicht die Berechnung von Durchlaufzeiten, Dauern und Wartezeiten zwischen Prozessschritten. Woher beziehen Wird aus verschiedenen Datums- und Zeitfeldern mehrerer Tabellen gebildet, zum Beispiel BKPF (BUDAT, CPUTM), VBRK (ERDAT, ERZET) und Änderungsprotokolltabellen wie CDHDR (UDATE, UTIME). Beispiele 2023-04-15T10:30:00Z2023-04-16T11:00:00Z2023-05-20T09:00:00Z | |||
| Benutzername UserName | Die ID des Benutzers, der die Aktivität ausgeführt oder den Beleg angelegt hat. | ||
| Beschreibung Dieses Attribut erfasst die SAP-Benutzer-ID, die für ein bestimmtes Ereignis verantwortlich ist, etwa für die Erstellung einer Rechnung oder die Buchung einer Zahlung. Es ist wichtig, um den menschlichen Anteil am Prozess zu analysieren. Anhand dieser Daten lassen sich Leistungsunterschiede zwischen Benutzern oder Teams untersuchen, Schulungsbedarf ermitteln und mögliche Compliance-Probleme erkennen. Außerdem können manuelle Aktivitäten von Benutzern von automatisierten Schritten durch System- oder Batch-Benutzer unterschieden werden. Das ist wichtig für die Berechnung des Automatisierungsgrads. Warum das wichtig ist Ermöglicht die Analyse der Benutzerleistung und der Arbeitsverteilung. Außerdem lassen sich manuelle und automatisierte Aktivitäten unterscheiden, was Initiativen zur Automatisierung und Effizienzsteigerung unterstützt. Woher beziehen SAP-ECC-Tabelle: VBRK, Feld: ERNAM (Erstellt von), BKPF, Feld: USNAM (Benutzername) oder CDHDR, Feld: USERNAME (Benutzer). Beispiele JSMITHBW_BATCHLROSSIMKUMAR | |||
| Buchungskreis CompanyCode | Die Kennung der juristischen Person, die die Rechnung ausgestellt hat. | ||
| Beschreibung Der Buchungskreis steht in SAP für eine eigenständige rechtliche und buchhalterische Einheit. Alle Finanztransaktionen, einschließlich Rechnungen, werden einem bestimmten Buchungskreis zugeordnet. Er ist ein grundlegendes organisatorisches Datenelement. Im Process Mining dient der Buchungskreis dazu, die Leistung von Fakturierungsprozessen verschiedener juristischer Personen innerhalb eines Unternehmens zu vergleichen. So lassen sich bewährte Vorgehensweisen einer Einheit erkennen und auf andere übertragen. Zugleich berücksichtigt die Analyse die Organisationsstruktur des Unternehmens. Warum das wichtig ist Ermöglicht das Filtern und Vergleichen von Prozessen über verschiedene juristische Personen hinweg. Das ist eine wichtige Grundlage für Finanzanalysen und den Vergleich innerhalb der Organisation. Woher beziehen SAP-ECC-Tabelle: VBRK, Feld: BUKRS Beispiele 10002000US01DE01 | |||
| Fakturabelegart BillingDocumentType | Ein Code zur Kategorisierung des Fakturabelegs, zum Beispiel als Rechnung, Gutschrift oder Lastschrift. | ||
| Beschreibung Die Fakturabelegart ordnet Transaktionen anhand ihres Geschäftszwecks verschiedenen Kategorien zu. „F2“ steht beispielsweise für eine Standardkundenrechnung, „G2“ für eine Gutschrift. In SAP wird diese Klassifizierung konfiguriert und steuert die Verarbeitung der verschiedenen Fakturabelege. Für Process Mining ist dieses Attribut wichtig, um unterschiedliche Fakturierungsszenarien zu filtern und zu vergleichen. Analysten können Standardrechnungen getrennt von Gutschriften untersuchen und so deren jeweilige Abläufe, Durchlaufzeiten und Herausforderungen nachvollziehen. Das ermöglicht gezieltere Prozessverbesserungen. Warum das wichtig ist Ermöglicht die getrennte Analyse verschiedener Fakturierungsprozesse, etwa von Standardrechnungen und Gutschriften, deren Abläufe sich oft deutlich unterscheiden. Woher beziehen SAP-ECC-Tabelle: VBRK, Feld: FKART Beispiele F2G2L2IV | |||
| Kundennummer CustomerNumber | Eine eindeutige Nummer, die den Kunden identifiziert, an den die Rechnung gestellt wird. | ||
| Beschreibung Die Kundennummer ordnet eine Rechnung einem bestimmten Kunden oder Geschäftspartner zu. Dieses Attribut ist wichtig, um den Fakturierungsprozess anhand von Kundenmerkmalen aufzuschlüsseln und zu analysieren. Analysten können damit die Days Sales Outstanding (DSO) verschiedener Kunden vergleichen, häufig verspätete Zahlungen erkennen oder die Einhaltung von Zahlungsbedingungen untersuchen. Solche Muster helfen dabei, Kundenbeziehungen zu steuern und passende Strategien für den Zahlungseinzug zu entwickeln. Warum das wichtig ist Ermöglicht kundenbezogene Analysen, mit denen sich Zahlungsverhalten und DSO je Kunde untersuchen sowie passende Strategien für den Zahlungseinzug entwickeln lassen. Woher beziehen SAP-ECC-Tabelle: VBRK, Feld: KUNRG (Zahler) oder KUNAG (Auftraggeber). Beispiele 100023200541CUST-A487910345 | |||
| Rechnungsnettobetrag TotalInvoiceAmount | Der gesamte Nettowert des Fakturabelegs. | ||
| Beschreibung Dieses Attribut enthält den Nettogesamtbetrag der Rechnung ohne Steuern. Der Rechnungsbetrag ist eine wichtige Finanzinformation zum Fakturierungsprozess. Er lässt sich für verschiedene Analysen verwenden, etwa um Rechnungen nach hohem und niedrigem Wert zu gruppieren und ihre Prozessabläufe zu vergleichen. Außerdem kann er dabei helfen, den Zahlungseinzug zu priorisieren oder zu untersuchen, warum die Freigabe oder Bezahlung hochpreisiger Rechnungen länger dauert. Dieser finanzielle Kontext erweitert die Prozessanalyse um eine wichtige Perspektive. Warum das wichtig ist Liefert wichtigen finanziellen Kontext für wertbezogene Analysen. So lässt sich beispielsweise feststellen, ob hochpreisige Rechnungen einen anderen Prozess durchlaufen oder länger bis zum Ausgleich benötigen. Woher beziehen SAP-ECC-Tabelle: VBRK, Feld: NETWR Beispiele 1500.7525000.00500.0012345.67 | |||
| Ausgleichsdatum ClearingDate | Das Datum, an dem die Zahlung eingegangen und die Rechnung in der Debitorenbuchhaltung ausgeglichen wurde. | ||
| Beschreibung Das Ausgleichsdatum ist der Tag, an dem ein offener Posten wie eine Rechnung im Finanzsystem als bezahlt oder „ausgeglichen“ gekennzeichnet wird. Es gibt an, wann der Zahlungseingang als vereinnahmt und abgestimmt gilt. Dieses Datum zählt zu den wichtigsten im Order-to-Cash-Zyklus. Es bildet den Endpunkt für die Berechnung von Days Sales Outstanding (DSO) und der gesamten Durchlaufzeit von der Rechnung bis zum Zahlungseingang. Anhand des Ausgleichsdatums lässt sich die Wirksamkeit des Zahlungseinzugs messen. Warum das wichtig ist Markiert den letzten Schritt im Lebenszyklus der Rechnung. Das Datum dient als Endpunkt für die Berechnung von DSO und der gesamten Durchlaufzeit und gibt Aufschluss über die Effizienz des Zahlungseinzugs. Woher beziehen SAP-ECC-Tabelle: BSAD, Feld: AUGDT Beispiele 2023-05-142023-06-012023-06-25 | |||
| Automatisiert IsAutomated | Eine Kennzeichnung, die angibt, ob eine Aktivität von einem Systembenutzer oder automatisiert ausgeführt wurde. | ||
| Beschreibung Dieses berechnete Attribut ist ein boolescher Wert, der manuelle von automatisierten Aktivitäten unterscheidet. Es wird üblicherweise ermittelt, indem das Attribut „Benutzername“ mit einer Liste bekannter System- oder Batch-Benutzer-IDs wie „BATCHUSER“ oder „SAPSYSTEM“ abgeglichen wird. Die Kennzeichnung ist wichtig, um den Automatisierungsgrad im Fakturierungsprozess zu messen. Viele Unternehmen wollen damit die Effizienz steigern und Kosten senken. Die KPI für die automatisierte Fakturierung wird direkt aus diesem Attribut berechnet und zeigt den Fortschritt von Automatisierungsinitiativen. Warum das wichtig ist Unterstützt direkt die Berechnung der Automatisierungsrate in der Fakturierung. So lassen sich die Prozesseffizienz und die Auswirkungen von Automatisierungsprojekten messen. Woher beziehen Wird aus dem Attribut „Benutzername“ abgeleitet. Die Logik könnte beispielsweise lauten: IF UserName IN ('BATCH', 'SYSTEM', 'RFCUSER') THEN true ELSE false. Beispiele truefalse | |||
| Belegdatum DocumentDate | Das Datum auf dem Originalbeleg, das vom Lieferanten oder Ersteller angegeben wurde. | ||
| Beschreibung Das Belegdatum ist das Ausstellungsdatum des Originalbelegs. Bei der Fakturierung entspricht es in der Regel dem Erstellungsdatum der Rechnung und dient häufig als Grundlage für die Berechnung des Fälligkeitsdatums. Dieses Datum ist wichtig für die Finanzberichterstattung und die Berechnung zentraler Kennzahlen wie Days Sales Outstanding (DSO). Aus Kundensicht markiert es den Beginn des Zahlungszeitraums. Abweichungen zwischen Beleg- und Buchungsdatum können interne Verzögerungen bei der Bearbeitung eingehender Rechnungen sichtbar machen. Warum das wichtig ist Dient als Ausgangspunkt für die Berechnung des Rechnungsalters und des DSO und ist eine wichtige Bezugsgröße für Finanzanalysen und die Auswertung von Zahlungsbedingungen. Woher beziehen SAP-ECC-Tabelle: VBRK, Feld: FKDAT (Fakturadatum) Beispiele 2023-04-152023-04-162023-05-20 | |||
| Buchungsdatum PostingDate | Das Datum, an dem der Beleg in der Finanzbuchhaltung gebucht wird. | ||
| Beschreibung Das Buchungsdatum bestimmt die Geschäftsjahresperiode, in der die Transaktion im Hauptbuch erfasst wird. Es ist ein wichtiges Datum für Buchhaltung und Finanzberichterstattung. Verzögerungen zwischen Belegerstellung und Buchung können auf Ineffizienzen bei der internen Bearbeitung von Fakturabelegen hinweisen. Im Process Mining markiert das Buchungsdatum einen wichtigen Meilenstein im Lebenszyklus der Rechnung. Die Zeitspanne zwischen Rechnungserstellung und Buchung kann als Kennzahl für die Effizienz der Fakturierungsabteilung dienen. Warum das wichtig ist Markiert einen wichtigen finanziellen Meilenstein und ist für die Buchhaltung entscheidend. Die Zeitspanne zwischen Rechnungserstellung und Buchung misst die Effizienz der internen Bearbeitung. Woher beziehen SAP-ECC-Tabelle: BKPF, Feld: BUDAT Beispiele 2023-04-152023-04-172023-05-21 | |||
| Letzte Datenaktualisierung LastDataUpdate | Der Timestamp der letzten Aktualisierung oder Extraktion der Daten aus dem Quellsystem. | ||
| Beschreibung Dieses Attribut gibt an, wann der Datensatz zuletzt aus dem Quellsystem aktualisiert wurde. Es liefert wichtigen Kontext für die Analyse und zeigt Benutzern, wie aktuell die angezeigten Daten sind. In Dashboards und Berichten informiert dieser Timestamp die Beteiligten über den Aktualitätsstand der Daten. So können sie einschätzen, ob sehr neue Transaktionen bereits sichtbar sind. Der Wert wird üblicherweise am Ende der Datenextraktion erzeugt. Warum das wichtig ist Informiert Benutzer über den Aktualitätsstand der Daten. Das ist wichtig, wenn sie auf Grundlage der Analyse operative Entscheidungen treffen. Woher beziehen Wird während der Datenextraktion, -transformation und -ladung (ETL) erzeugt und gespeichert. Beispiele 2023-10-27T02:00:00Z2023-10-28T02:00:00Z | |||
| Nacharbeit IsRework | Eine Kennzeichnung, die angibt, ob eine Aktivität einen Nacharbeits- oder Korrekturschritt darstellt. | ||
| Beschreibung Dieses berechnete Attribut kennzeichnet Aktivitäten, die Nacharbeit darstellen, etwa „Rechnung korrigiert“ oder Belegstornierungen. In der Regel handelt es sich um einen booleschen Wert, der aus dem Aktivitätsnamen oder aus Transaktionscodes für Korrekturen und Stornierungen abgeleitet wird, zum Beispiel „VF11“ zum Stornieren eines Fakturabelegs. Im Process Mining ist diese Kennzeichnung besonders hilfreich, um den Umfang der Nacharbeit im Fakturierungsprozess zu messen. Sie unterstützt direkt Kennzahlen wie die Rechnungsberichtigungsquote und macht Nacharbeitsschleifen in der Prozessdarstellung sichtbar. So werden Ineffizienzen und Qualitätsprobleme deutlich, die Betriebskosten erhöhen und Zahlungen verzögern. Warum das wichtig ist Macht Ineffizienzen und Qualitätsprobleme messbar, indem sichtbar wird, wie viel Aufwand für Fehlerkorrekturen anfällt. Unterstützt direkt Kennzahlen zur Nacharbeit. Woher beziehen Wird aus dem Aktivitätsnamen oder Transaktionscode abgeleitet. Beispiel: IF ActivityName = 'Invoice Corrected' OR TransactionCode = 'VF11' THEN true ELSE false. Beispiele truefalse | |||
| Quellsystem SourceSystem | Gibt an, aus welchem Quellsystem die Daten extrahiert wurden. | ||
| Beschreibung Dieses Attribut bezeichnet das führende System, aus dem die Daten stammen. In Unternehmen mit mehreren ERP-Instanzen oder integrierten Systemen hilft dieses Feld, Daten aus unterschiedlichen Quellen zu unterscheiden. Für Process Mining ist es wichtig, um Daten zu validieren und Prozesse über verschiedene Systeme oder Organisationseinheiten hinweg zu vergleichen. Das Feld wird bei der Datenextraktion in der Regel mit einem festen Wert befüllt, der den Datensatz kennzeichnet. Warum das wichtig ist Gibt Aufschluss über die Herkunft der Daten. Das ist in Umgebungen mit mehreren Systemen wichtig, um die Datenintegrität sicherzustellen und systembezogene Analysen zu ermöglichen. Woher beziehen Dieser feste Wert wird üblicherweise während der Datenextraktion, -transformation und -ladung (ETL) hinzugefügt und kennzeichnet die jeweilige SAP-ECC-Instanz (z. B. „ECC_PROD_NA“). Beispiele SAP_ECC_PRODECC_EU_100SAP_US_FIN | |||
| Rechnungsfälligkeitsdatum InvoiceDueDate | Das Datum, bis zu dem der Kunde voraussichtlich zahlt. | ||
| Beschreibung Das Rechnungsfälligkeitsdatum ist der Zahlungstermin, der sich aus den Zahlungsbedingungen ergibt. Es ist eine wichtige Grundlage für die Verwaltung offener Forderungen und die Einleitung von Maßnahmen zum Zahlungseinzug. Dieses Attribut dient zur Berechnung der KPI für die fristgerechte Zahlung, indem es mit dem tatsächlichen Zahlungsdatum verglichen wird. Die Analyse nach Fälligkeitsdatum hilft bei der Liquiditätsplanung und dabei, den Zahlungseinzug für anstehende oder überfällige Zahlungen zu priorisieren. Das Datum wird üblicherweise aus dem Basisdatum und den Zahlungsbedingungen abgeleitet. Warum das wichtig ist Dient als Maßstab für die fristgerechte Zahlung und ist wichtig für die Verwaltung offener Forderungen und die Liquiditätsplanung. Woher beziehen Wird anhand des Basisdatums (BSEG-ZFBDT) und der Zahlungsbedingungen (BSEG-ZTERM) berechnet. Das Datum ist nicht immer direkt in einem Feld gespeichert. Beispiele 2023-05-152023-05-302023-06-20 | |||
| Transaktionscode TransactionCode | Der SAP-Transaktionscode, mit dem eine Aktivität ausgeführt wurde. | ||
| Beschreibung Der Transaktionscode, auch T-Code genannt, ist die eindeutige Kennung einer bestimmten Funktion oder eines Programms in SAP, zum Beispiel „VF01“ zum Anlegen eines Fakturabelegs. Der T-Code zu jedem Ereignis zeigt auf technischer Systemebene, wie ein Prozess ausgeführt wurde. Diese Information ist für die Ursachenanalyse besonders wertvoll. Treten beispielsweise häufig Fehler auf, können Analysten prüfen, ob ein nicht standardisierter Transaktionscode verwendet wird. Der T-Code hilft außerdem dabei, die Aktivität abzuleiten und zu verstehen, welche Systemfunktionen im Prozess zum Einsatz kommen. Warum das wichtig ist Liefert technischen Kontext zur Ausführung einer Aktivität. So lassen sich Ursachen von Prozessabweichungen untersuchen und nicht standardisierte Benutzeraktionen erkennen. Woher beziehen SAP-ECC-Tabelle: CDHDR, Feld: TCODE Beispiele VF01VF02FB01F-28 | |||
| Verkaufsbelegnummer SalesDocumentNumber | Die Kennung des ursprünglichen Kundenauftrags, aus dem die Rechnung hervorgegangen ist. | ||
| Beschreibung Dieses Attribut verknüpft die Rechnung direkt mit dem Kundenauftrag, der die Transaktion ausgelöst hat. Diese Rückverfolgbarkeit ist wichtig für eine durchgängige Order-to-Cash-Analyse. Durch die Verknüpfung des Fakturierungsprozesses mit dem vorangehenden Kundenauftragsprozess können Unternehmen die gesamte Durchlaufzeit vom Kundenauftrag bis zum Zahlungseingang analysieren. So lässt sich feststellen, ob Verzögerungen bei der Fakturierung durch Probleme im Vertrieb, in der Auftragsabwicklung oder in der Fakturierungsabteilung entstehen. Das ermöglicht einen umfassenderen Blick auf den Prozess. Warum das wichtig ist Verknüpft den Fakturierungsprozess mit dem Kundenauftrag und ermöglicht eine durchgängige Order-to-Cash-Analyse. So lassen sich auch abteilungsübergreifende Verzögerungen erkennen. Woher beziehen SAP-ECC-Tabelle: VBRP, Feld: VGBEL Beispiele 100000451000004610000047 | |||
| Verkaufsorganisation SalesOrganization | Die Organisationseinheit, die für den Verkauf von Produkten oder Dienstleistungen verantwortlich ist. | ||
| Beschreibung Die Verkaufsorganisation ist eine Organisationseinheit in SAP, die für den Vertrieb von Waren und Dienstleistungen sowie für die Aushandlung von Verkaufsbedingungen zuständig ist. Sie ist ein wichtiges Merkmal für die Strukturierung der Vertriebsabläufe. Im Process Mining ermöglicht dieses Attribut, den Fakturierungsprozess aus Sicht der Vertriebsstruktur zu analysieren. Die Leistung verschiedener Verkaufsorganisationen lässt sich vergleichen. So können Unternehmen erkennen, welche Regionen oder Geschäftsbereiche ihre Rechnungen effizienter bearbeiten, und bewährte Vorgehensweisen standardisieren. Warum das wichtig ist Ermöglicht Leistungsvergleiche und Analysen zwischen Vertriebsbereichen oder Regionen. So lassen sich bewährte Vorgehensweisen und Verbesserungsmöglichkeiten erkennen. Woher beziehen SAP-ECC-Tabelle: VBRK, Feld: VKORG Beispiele 1000NA01EU01AP01 | |||
| Währung Currency | Der Währungscode für die in der Rechnung angegebenen Beträge. | ||
| Beschreibung Dieses Attribut gibt die Transaktionswährung an, zum Beispiel USD, EUR oder JPY. Es liefert den nötigen Kontext für Geldbeträge wie den Rechnungsnettobetrag. Bei der Analyse von Daten eines multinationalen Unternehmens ist das Währungsfeld wichtig, um Finanzwerte korrekt zu interpretieren und umzurechnen. Es ermöglicht eine konsistente Berichterstattung und verhindert, dass Beträge ohne korrekte Währungsumrechnung zusammengefasst werden. Andernfalls wären die Finanzanalysen fehlerhaft. Warum das wichtig ist Liefert den nötigen Kontext für alle Geldbeträge und ermöglicht genaue Finanzanalysen, insbesondere bei mehreren Währungen. Woher beziehen SAP-ECC-Tabelle: VBRK, Feld: WAERK Beispiele USDEURGBPJPY | |||
| Zahlungsbedingungen PaymentTerms | Die Bedingungen, unter denen ein Verkäufer einen Verkauf abschließt, einschließlich des Zahlungsplans. | ||
| Beschreibung Die Zahlungsbedingungen legen fest, wann eine Zahlung fällig ist, zum Beispiel „Netto 30“ oder „Netto 60“. Sie werden mit dem Kunden vereinbart und beeinflussen den Cashflow maßgeblich. Eine Analyse nach Zahlungsbedingungen kann zeigen, ob bestimmte Vereinbarungen mit längeren Zahlungszyklen oder häufigeren verspäteten Zahlungen einhergehen. Diese Erkenntnisse helfen dem Unternehmen, bessere Bedingungen auszuhandeln oder die Finanzplanung anzupassen. Die Zahlungsbedingungen sind außerdem eine wichtige Grundlage für die Berechnung des Rechnungsfälligkeitsdatums. Warum das wichtig ist Hilft dabei, das Zahlungsverhalten der Kunden und die Auswirkungen vereinbarter Zahlungsbedingungen auf den Cashflow zu analysieren. Die Erkenntnisse unterstützen die Optimierung kommerzieller Vereinbarungen. Woher beziehen SAP-ECC-Tabelle: VBRK, Feld: ZTERM Beispiele Z030Z060Z001 | |||
Aktivitäten für Order-to-Cash: Fakturierung und Rechnungsstellung
| Aktivität | Beschreibung | ||
|---|---|---|---|
| Kundenzahlung eingegangen | Eine Kundenzahlung ist eingegangen und wurde im System als Zahlungseingang oder Bankeinzahlung gebucht. Dabei wird ein separater Zahlungsbeleg erstellt, der noch nicht der konkreten Rechnung zugeordnet ist. | ||
| Warum das wichtig ist Dies ist ein wichtiger Meilenstein im Cash Conversion Cycle. Die Zeit vom Rechnungsversand bis zum Zahlungseingang ist ein wesentlicher Bestandteil des Days Sales Outstanding (DSO). Woher beziehen Erfasst als neuer Beleg in BKPF und BSEG, üblicherweise mit einem Belegtyp für Kundenzahlungen wie „DZ“. Das Buchungsdatum (BUDAT) kennzeichnet das Ereignis. Erfassung Anhand des Buchungsdatums des Kundenzahlungsbelegs in BKPF. Ereignistyp explicit | |||
| Rechnung an Kunden gesendet | Zeigt an, dass die Rechnung über einen festgelegten Ausgabekanal wie Druck, E-Mail oder EDI an den Kunden versendet wurde. Dieses Ereignis wird üblicherweise anhand der Protokolle des Ausgabemanagementsystems erfasst. | ||
| Warum das wichtig ist Dieses Ereignis ist ein wichtiger Meilenstein, ab dem die Zahlungsfrist des Kunden läuft. Verzögerungen wirken sich direkt darauf aus, wann mit einer Zahlung zu rechnen ist, und beeinträchtigen die Effizienz des Forderungseinzugs. Woher beziehen Lässt sich anhand von Datum und Uhrzeit der Verarbeitung in der Nachrichtenstatus-Tabelle (NAST) für den zur Rechnung gehörenden Ausgabetyp ermitteln. Erfassung Abgeleitet aus einem Eintrag in Tabelle NAST mit dem Verarbeitungsstatus „1“ (erfolgreich verarbeitet). Ereignistyp inferred | |||
| Rechnung ausgeglichen | Der endgültige Status einer erfolgreich bezahlten Rechnung. Er zeigt an, dass der offene Posten durch eine entsprechende Zahlung oder Gutschrift ausgeglichen wurde. Die Rechnung gilt damit als vollständig beglichen. | ||
| Warum das wichtig ist Kennzeichnet den erfolgreichen Abschluss des Order-to-Cash-Zyklus für eine Rechnung. Dies ist das wichtigste End Event zur Messung der durchschnittlichen Gesamtdauer des Rechnungszyklus. Woher beziehen Tritt ein, wenn die Felder für den Ausgleichsbeleg (AUGBL) und das Ausgleichsdatum (AUGDT) für die Rechnungsposition in Tabelle BSEG befüllt sind. Erfassung Das Ereignis tritt am Ausgleichsdatum (AUGDT) ein, das für die Rechnungsposition in Tabelle BSEG erfasst ist. Ereignistyp explicit | |||
| Rechnung erstellt | Kennzeichnet die Erstellung des Abrechnungsbelegs im System. Das Ereignis wird erfasst, wenn in der Tabelle für Buchhaltungsbelegköpfe (BKPF) ein neuer Eintrag mit einem bestimmten Belegtyp für Rechnungen angelegt wird. | ||
| Warum das wichtig ist Dies ist der Ausgangspunkt des gesamten Rechnungsstellungsprozesses. Anhand der Zeit ab diesem Ereignis lässt sich die Zykluszeit der Rechnungserstellung messen. Außerdem bildet sie die Grundlage für die Berechnung des Days Sales Outstanding (DSO). Woher beziehen Erfasst in Tabelle BKPF. Das Erstellungsdatum (CPUDT) und die Erstellungszeit (CPUTM) eines bestimmten Belegs (BELNR) kennzeichnen dieses Ereignis. Der Belegtyp (BLART) weist ihn als Rechnung aus. Erfassung Anhand des Erstellungs-Timestamp (CPUDT) des Rechnungsbelegs in Tabelle BKPF. Ereignistyp explicit | |||
| Rechnung gebucht | Die Rechnung wird offiziell im Nebenbuch der Debitorenbuchhaltung und im Hauptbuch erfasst. Dadurch wird sie rechtsverbindlich und weist die Forderung gegenüber dem Kunden aus. | ||
| Warum das wichtig ist Dies ist ein wichtiger Meilenstein, ab dem die Frist für den Forderungseinzug läuft. Die Zeit zwischen Erstellung und Buchung kann interne Verzögerungen sichtbar machen, die den Cashflow beeinträchtigen. Woher beziehen Erfasst in Tabelle BKPF. Das Buchungsdatum (BUDAT) des Belegs (BELNR) kennzeichnet dieses Ereignis. Bei geparkten Belegen ist dies der Zeitpunkt, an dem der Beleg gebucht wird. Erfassung Anhand des Buchungsdatums (BUDAT) des Rechnungsbelegs in Tabelle BKPF. Ereignistyp explicit | |||
| Klärungsfall erstellt | Für die Rechnung wurde ein formeller Klärungsfall erfasst, in der Regel aufgrund einer Kundenbeschwerde. Der Fall wird im SAP Dispute Management dokumentiert. | ||
| Warum das wichtig ist Zeigt Rechnungen mit dem Risiko verspäteter Zahlung und macht die zugrunde liegenden Ursachen für die Unzufriedenheit des Kunden sichtbar. Damit beginnt ein wichtiger Prozess zur Bearbeitung von Ausnahmen. Woher beziehen Erfasst, wenn in der Tabelle für Klärungsfälle (UDM_CASE) ein Fall angelegt wird, der mit dem Buchhaltungsbeleg der Rechnung verknüpft ist. Erfassung Wird protokolliert, wenn ein Benutzer über die Transaktion UDM_DISPUTE einen Klärungsfall erstellt. Ereignistyp explicit | |||
| Rechnung abgeschrieben | Ein alternativer Endstatus: Die Rechnung gilt als uneinbringlich und der offene Betrag wird gegen ein Konto für uneinbringliche Forderungen ausgebucht. Damit wird die Rechnung ohne Kundenzahlung abgeschlossen. | ||
| Warum das wichtig ist Kennzeichnet ein negatives Prozessergebnis und einen Umsatzausfall. Die Erfassung dieser Ereignisse hilft dabei, die Ursachen uneinbringlicher Forderungen zu analysieren und die Richtlinien für das Kreditmanagement zu verbessern. Woher beziehen Wird anhand der Ausgleichsbuchung für die Rechnung ermittelt. Wird das Ausgleichsdokument auf ein bestimmtes Sachkonto für Forderungsausfälle gebucht, gilt die Rechnung als abgeschrieben. Erfassung Wird ermittelt, wenn bei der Ausgleichsbuchung auf ein festgelegtes Sachkonto für Forderungsausfälle gebucht wird. Ereignistyp inferred | |||
| Rechnung fällig | Ein berechnetes Ereignis, das den Tag kennzeichnet, an dem die Rechnung gemäß den Zahlungsbedingungen fällig ist. Es handelt sich nicht um eine Aktivität eines Benutzers oder Systems, sondern um einen wichtigen Zeitpunkt. | ||
| Warum das wichtig ist Wichtig für die Analyse des Zahlungsverhaltens und der Compliance. Das Ereignis dient als Grundlage, um pünktliche von verspäteten Zahlungen zu unterscheiden und den KPI für die Quote pünktlicher Zahlungen zu berechnen. Woher beziehen Abgeleitet aus dem Vergleich des aktuellen Datums mit dem Nettofälligkeitsdatum. Das Fälligkeitsdatum steht in Feld BSEG-ZFBDT oder wird anhand des Basisdatums und der Zahlungsbedingungen berechnet. Erfassung Vergleichen Sie das Systemdatum mit dem Feld für das Nettofälligkeitsdatum im Rechnungspositionseintrag (BSEG). Ereignistyp calculated | |||
| Rechnung genehmigt | Kennzeichnet die formelle Freigabe der Rechnung, durch die sie gebucht oder an den Kunden gesendet werden kann. Häufig lässt sich dies daran erkennen, dass ein geparkter Beleg in einen gebuchten Beleg umgewandelt wird. | ||
| Warum das wichtig ist Erfasst den internen Freigabe-Workflow, der häufig Engpässe verursacht. Die Analyse dieser Aktivität unterstützt das Dashboard zur Analyse des Rechnungsfreigabeprozesses, indem sie langsame Freigaben sichtbar macht. Woher beziehen Lässt sich am Übergang eines Belegs vom geparkten Status (in VBKPF) zum gebuchten Status (in BKPF) erkennen. Wird ein Workflow-System verwendet, kann das Ereignis alternativ explizit in den Workflow-Protokollen erfasst sein. Erfassung Vergleichen Sie das Erstellungsdatum des geparkten Belegs (VBKPF) mit dem Buchungsdatum des endgültigen Belegs (BKPF). Ereignistyp inferred | |||
| Rechnung geparkt | Der Rechnungsbeleg wurde vorläufig gespeichert, aber noch nicht im Hauptbuch gebucht. Dies wird häufig verwendet, wenn Angaben fehlen oder der Beleg vor der endgültigen Buchung geprüft werden muss. | ||
| Warum das wichtig ist Erfasst Schritte vor der Buchung und mögliche Verzögerungen. Eine lange Verweildauer im geparkten Status kann auf Probleme mit der Datenqualität oder Engpässe im Vorabfreigabeprozess hinweisen. Woher beziehen Geparkte Belege werden in Tabelle VBKPF gespeichert. Wird dort ein Beleg angelegt und später gebucht, kennzeichnet dies die Aktivität. Erfassung Wird beim Speichern eines geparkten Belegs über eine Transaktion wie FV70 protokolliert. Ereignistyp explicit | |||
| Rechnung korrigiert | Kennzeichnet eine Nacharbeit, bei der eine zunächst fehlerhafte Rechnung storniert wurde. Dies wird erfasst, indem Stornobelege ermittelt werden, die mit der ursprünglichen Rechnung verknüpft sind. | ||
| Warum das wichtig ist Macht Ineffizienzen und Qualitätsprobleme im Prozess sichtbar. Häufige Korrekturen weisen auf Probleme in vorgelagerten Vertriebs- oder Abrechnungsdaten hin und unterstützen das Dashboard zu Rechnungsnacharbeit und Fehlerquoten. Woher beziehen Wird anhand eines Stornobelegs erkannt, bei dem BKPF-STBLG auf den ursprünglichen Beleg verweist. Das Ereignis ist die Erstellung dieses Stornobelegs. Erfassung Wird protokolliert, wenn ein Stornobeleg erstellt wird, zum Beispiel über FB08. Ereignistyp explicit | |||
| Zahlung der Rechnung zugeordnet | Die eingegangene Kundenzahlung wurde der konkreten offenen Rechnung zugeordnet und zum Ausgleich vorgemerkt. Bei diesem Abstimmungsschritt wird die Zahlung mit der Forderung verknüpft. | ||
| Warum das wichtig ist Diese Aktivität ist wichtig, um die Zykluszeit der Zahlungszuordnung zu messen. Verzögerungen bei der Zuordnung können den tatsächlichen Forderungsbestand falsch darstellen und verfügbare Liquidität verdecken. Woher beziehen Abgeleitet aus dem Ausgleichsvorgang, zum Beispiel F-32, der die Ausgleichsfelder im Rechnungspositionseintrag befüllt. Der Timestamp des Ereignisses ist das Ausgleichsdatum. Erfassung Abgeleitet daraus, dass das Ausgleichsdatum (AUGDT) in der Rechnungspositionstabelle (BSEG) eingetragen ist. Ereignistyp inferred | |||
| Zahlungserinnerung versendet | Das System hat für eine überfällige Rechnung eine Mahnung oder Zahlungserinnerung erstellt und an den Kunden gesendet. Dieses Ereignis wird anhand der Mahnprotokolle erfasst. | ||
| Warum das wichtig ist Hilft dabei, die Wirksamkeit der Einzugsstrategie zu bewerten. Für den KPI zur Wirksamkeit von Zahlungserinnerungen ist es wichtig, die Zeit zwischen Erinnerung und Zahlungseingang zu analysieren. Woher beziehen Erfasst in den Mahndatentabellen, insbesondere MHNK (Mahndatenkopf) und MHND (Mahndatenpositionen), die beim Mahnlauf erstellt werden (Transaktion F150). Erfassung Wird protokolliert, wenn für den überfälligen Posten ein Mahnlauf ausgeführt wird (F150). Ereignistyp explicit | |||
Anleitungen zur Datenextraktion
Schritte
- ABAP-Editor öffnen: Melden Sie sich bei Ihrem SAP-ECC-System an. Öffnen Sie den ABAP-Editor über den Transaktionscode
SE38. - Programm anlegen: Geben Sie im Feld „Programm“ einen Namen für das neue Programm ein, zum Beispiel
Z_PM_O2C_INVOICE_EXTRACT, und klicken Sie auf „Anlegen“. Vergeben Sie einen aussagekräftigen Titel und wählen Sie als Programmtyp „Ausführbares Programm“. - Selektionsbild definieren: Legen Sie im Quellcode des Programms die Parameter des Selektionsbilds fest. Damit können Benutzer die zu extrahierenden Daten filtern. Wichtige Parameter sind der Zeitraum des Belegerstellungsdatums (
S_ERDAT), der Buchungskreis (S_BUKRS) und die Fakturaart (S_VBTYP). - Datenstrukturen definieren: Deklarieren Sie eine interne Tabelle für die endgültigen Event-Log-Daten. Die Struktur muss Felder für
InvoiceNumber,ActivityNameundEventTimesowie empfohlene Attribute wieUserName,BillingDocumentType,CustomerNumber,CompanyCodeundTotalInvoiceAmountenthalten. - Datenauswahl implementieren: Schreiben Sie die zentrale ABAP-Logik für die Datenauswahl. Lesen Sie zunächst anhand der Eingaben im Selektionsbild die relevanten Fakturabelege aus den Tabellen
VBRKundBKPFaus und speichern Sie sie in einer temporären internen Tabelle. - Aktivitäten extrahieren: Durchlaufen Sie die Liste der Fakturabelege. Lesen Sie für jeden Beleg weitere Tabellen aus, um die 13 erforderlichen Aktivitäten zu ermitteln. Fragen Sie beispielsweise die Tabelle
NASTnach Ereignissen wie „Rechnung an Kunden gesendet“,BSEGnach Ausgleichsinformationen („Rechnung ausgeglichen“, „Zahlung zugeordnet“) undMHNKnach Mahndaten („Zahlungserinnerung versendet“) ab. - Event-Log-Tabelle erstellen: Fügen Sie für jede im vorherigen Schritt gefundene Aktivität einen neuen Datensatz in die endgültige interne Event-Log-Tabelle ein. Übernehmen Sie
InvoiceNumber,ActivityName,EventTimeund die übrigen Attribute korrekt aus den Quelltabellen. - Datei auf den Anwendungsserver schreiben: Sobald die Schleife abgeschlossen und die Event-Log-Tabelle vollständig gefüllt ist, schreiben Sie deren Inhalt mit den Anweisungen
OPEN DATASET,LOOP AT... TRANSFERundCLOSE DATASETin eine Textdatei auf dem SAP-Anwendungsserver. Geben Sie einen zugänglichen logischen Dateipfad an. - Datei abrufen: Öffnen Sie mit dem Transaktionscode
AL11die Verzeichnisse des Anwendungsservers und suchen Sie die erzeugte Datei. Stimmen Sie sich mit Ihrem SAP-Basis-Team ab, um die Datei vom Server auf Ihren Rechner oder an einen freigegebenen Netzwerkspeicherort herunterzuladen. - Datei abschließend formatieren: Öffnen Sie die heruntergeladene Datei und prüfen Sie, ob es sich um eine CSV-Datei mit Kopfzeile handelt. Speichern Sie die Datei in UTF-8-Codierung, damit sie mit ProcessMind hochgeladen werden kann.
Konfiguration
- Voraussetzungen: Berechtigung zum Anlegen und Ausführen von ABAP-Programmen (Transaktion SE38). Leseberechtigung für FI- und SD-Tabellen, darunter
VBRK,VBRP,BKPF,BSEG,NAST,MHNKundUDM_CASE_ATTR00(für Dispute Management). - Zeitraum auswählen: Das Programm sollte einen verpflichtenden Zeitraumparameter enthalten, üblicherweise basierend auf dem Belegerstellungsdatum (
ERDATin VBRK/BKPF). Für die erste Extraktion empfiehlt sich ein Zeitraum von 3 bis 6 Monaten, damit der Datenbestand überschaubar bleibt. - Wichtige Filter: Filtern Sie immer nach
CompanyCode(BUKRS), um den Umfang der Extraktion zu begrenzen. Empfehlenswert ist außerdem ein Filter nach Fakturaart (VBTYPaus VBRK) oder Buchungsbelegart (BLARTaus BKPF), damit nur relevante Rechnungsarten berücksichtigt werden. Verwenden Sie beispielsweise „RV“ für Standardbuchungsrechnungen und schließen Sie Gutschriften und andere Belege aus. - Leistung berücksichtigen: Bei großen Datenbeständen über mehrere Monate sollte das Programm als Hintergrundjob laufen, um Sitzungsabbrüche zu vermeiden. Optimieren Sie die ABAP-Logik durch indizierte Tabellenzugriffe und vermeiden Sie verschachtelte Schleifen mit Datenbankabfragen. Lesen Sie die Daten zunächst in interne Tabellen ein und verarbeiten Sie sie anschließend.
- Ausgabedatei konfigurieren: Geben Sie im ABAP-Code den Dateipfad auf dem Anwendungsserver und das Trennzeichen der CSV-Datei an, üblicherweise ein Komma oder Semikolon. Stellen Sie sicher, dass das Verzeichnis global konfiguriert und zugänglich ist.
a Beispielabfrage abap
REPORT Z_PM_O2C_INVOICE_EXTRACT.
*&---------------------------------------------------------------------*
*& Tables
*&---------------------------------------------------------------------*
TABLES: VBRK, BKPF.
*&---------------------------------------------------------------------*
*& Type Definitions for Event Log Output
*&---------------------------------------------------------------------*
TYPES: BEGIN OF ty_event_log,
invoicenumber TYPE vbrk-vbeln,
activityname TYPE string,
eventtime TYPE timestamp,
username TYPE xubname,
billingdocumenttype TYPE vbrk-vbtyp,
customernumber TYPE vbrk-kunnr,
companycode TYPE vbrk-bukrs,
totalinvoiceamount TYPE vbrk-netwr,
END OF ty_event_log.
*&---------------------------------------------------------------------*
*& Data Declarations
*&---------------------------------------------------------------------*
DATA: gt_event_log TYPE TABLE OF ty_event_log,
gs_event_log TYPE ty_event_log.
DATA: BEGIN OF gs_invoice,
vbeln TYPE vbrk-vbeln, " SD Doc (Invoice)
awkey TYPE bkpf-awkey, " Accounting Doc Reference Key
bukrs TYPE vbrk-bukrs, " Company Code
kunnr TYPE vbrk-kunnr, " Customer
vbtyp TYPE vbrk-vbtyp, " SD Doc Type
netwr TYPE vbrk-netwr, " Net Value
waerk TYPE vbrk-waerk, " Currency
fkdat TYPE vbrk-fkdat, " Billing Date
erdat TYPE vbrk-erdat, " Creation Date
erzet TYPE vbrk-erzet, " Creation Time
ernam TYPE vbrk-ernam, " Creator
belnr TYPE bkpf-belnr, " Acct Doc
gjahr TYPE bkpf-gjahr, " Fiscal Year
cpudt TYPE bkpf-cpudt, " Acct Doc Entry Date
cputm TYPE bkpf-cputm, " Acct Doc Entry Time
usnam TYPE bkpf-usnam, " Acct Doc User
stblg TYPE bkpf-stblg, " Reversal Doc
END OF gs_invoice.
DATA: gt_invoices LIKE TABLE OF gs_invoice.
*&---------------------------------------------------------------------*
*& Selection Screen
*&---------------------------------------------------------------------*
SELECT-OPTIONS: s_erdat FOR vbrk-erdat OBLIGATORY,
s_bukrs FOR vbrk-bukrs OBLIGATORY,
s_vbtyp FOR vbrk-vbtyp.
PARAMETERS: p_path TYPE string DEFAULT '/usr/sap/trans/tmp/invoice_extract.csv' OBLIGATORY.
*&---------------------------------------------------------------------*
*& Main Processing Block
*&---------------------------------------------------------------------*
START-OF-SELECTION.
" 1. Select base set of invoices
SELECT vbrk~vbeln, vbrk~bukrs, vbrk~kunnr, vbrk~vbtyp, vbrk~netwr, vbrk~waerk,
vbrk~fkdat, vbrk~erdat, vbrk~erzet, vbrk~ernam,
bkpf~belnr, bkpf~gjahr, bkpf~cpudt, bkpf~cputm, bkpf~usnam, bkpf~stblg, bkpf~awkey
INTO CORRESPONDING FIELDS OF TABLE gt_invoices
FROM vbrk
INNER JOIN bkpf ON bkpf~awkey = vbrk~vbeln AND bkpf~awtyp = 'VBRK'
WHERE vbrk~erdat IN s_erdat
AND vbrk~bukrs IN s_bukrs
AND vbrk~vbtyp IN s_vbtyp.
IF gt_invoices IS INITIAL.
MESSAGE 'No invoices found for the selected criteria.' TYPE 'I'.
RETURN.
ENDIF.
LOOP AT gt_invoices INTO gs_invoice.
CLEAR gs_event_log.
gs_event_log-invoicenumber = gs_invoice-vbeln.
gs_event_log-billingdocumenttype = gs_invoice-vbtyp.
gs_event_log-customernumber = gs_invoice-kunnr.
gs_event_log-companycode = gs_invoice-bukrs.
gs_event_log-totalinvoiceamount = gs_invoice-netwr.
" Activity: Invoice Generated (using accounting doc creation)
gs_event_log-activityname = 'Invoice Generated'.
gs_event_log-username = gs_invoice-usnam.
CONCATENATE gs_invoice-cpudt gs_invoice-cputm INTO DATA(lv_ts_gen).
CONVERT DATE gs_invoice-cpudt TIME gs_invoice-cputm INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Posted (same as generated for non-parked docs)
gs_event_log-activityname = 'Invoice Posted'.
gs_event_log-username = gs_invoice-usnam.
CONVERT DATE gs_invoice-cpudt TIME gs_invoice-cputm INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Approved (inferred by posting)
gs_event_log-activityname = 'Invoice Approved'.
APPEND gs_event_log TO gt_event_log.
" Activity: Invoice Sent To Customer
SELECT SINGLE addat, aduhr FROM nast
INTO (DATA(lv_nast_date), DATA(lv_nast_time))
WHERE kappl = 'V3' AND objky = gs_invoice-vbeln AND vszst > '0'.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Sent To Customer'.
gs_event_log-username = sy-uname.
CONVERT DATE lv_nast_date TIME lv_nast_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Corrected / Reversed
IF gs_invoice-stblg IS NOT INITIAL.
SELECT SINGLE cpudt, cputm, usnam FROM bkpf
INTO (DATA(lv_rev_date), DATA(lv_rev_time), DATA(lv_rev_user))
WHERE belnr = gs_invoice-stblg AND gjahr = gs_invoice-gjahr.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Corrected'.
gs_event_log-username = lv_rev_user.
CONVERT DATE lv_rev_date TIME lv_rev_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
" Activity: Payment Applied, Cleared, Due Date, Written Off (from BSEG)
SELECT SINGLE augdt, augbl, zfBDT, hkont FROM bseg
INTO (DATA(lv_augdt), DATA(lv_augbl), DATA(lv_zfbdt), DATA(lv_hkont))
WHERE bukrs = gs_invoice-bukrs
AND belnr = gs_invoice-belnr
AND gjahr = gs_invoice-gjahr
AND koart = 'D'. " Customer line
IF sy-subrc = 0.
" Due Date Reached (Calculated event)
IF lv_zfbdt IS NOT INITIAL.
gs_event_log-activityname = 'Invoice Due Date Reached'.
gs_event_log-username = 'System'.
CONVERT DATE lv_zfbdt INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Cleared, Applied, Write-Off
IF lv_augdt IS NOT INITIAL.
SELECT SINGLE usnam, cpudt, cputm, blart FROM bkpf
INTO (DATA(lv_clear_user), DATA(lv_clear_date), DATA(lv_clear_time), DATA(lv_clear_type))
WHERE belnr = lv_augbl AND bukrs = gs_invoice-bukrs.
IF sy-subrc = 0.
gs_event_log-username = lv_clear_user.
CONVERT DATE lv_clear_date TIME lv_clear_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
IF lv_clear_type = 'DZ'. " Standard Customer Payment
gs_event_log-activityname = 'Customer Payment Received'. APPEND gs_event_log TO gt_event_log.
gs_event_log-activityname = 'Payment Applied To Invoice'. APPEND gs_event_log TO gt_event_log.
gs_event_log-activityname = 'Invoice Cleared'. APPEND gs_event_log TO gt_event_log.
ELSE. " Assuming other clearing doc types could be write-offs
gs_event_log-activityname = 'Invoice Written Off'.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDIF.
ENDIF.
ENDIF.
" Activity: Payment Reminder Issued (Dunning)
SELECT COUNT(*) FROM mhnk WHERE kunnr = gs_invoice-kunnr AND bukrs = gs_invoice-bukrs AND lafdn > gs_invoice-cpudt.
IF sy-subrc = 0 AND sy-dbcnt > 0.
SELECT SINGLE lafdn FROM mhnk
INTO DATA(lv_dunning_date)
WHERE kunnr = gs_invoice-kunnr AND bukrs = gs_invoice-bukrs AND lafdn > gs_invoice-cpudt.
gs_event_log-activityname = 'Payment Reminder Issued'.
gs_event_log-username = 'System'.
CONVERT DATE lv_dunning_date INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Invoice Parked (Example from VBKPF, may require system specific logic)
SELECT SINGLE cpudt, cputm, usnam FROM vbkpf
INTO (DATA(lv_park_date), DATA(lv_park_time), DATA(lv_park_user))
WHERE awkey = gs_invoice-vbeln AND awsys = 'LOG' AND bstat = 'V'.
IF sy-subrc = 0.
gs_event_log-activityname = 'Invoice Parked'.
gs_event_log-username = lv_park_user.
CONVERT DATE lv_park_date TIME lv_park_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
" Activity: Dispute Case Created (Requires Dispute Management module)
SELECT SINGLE create_date, create_time, create_user FROM udm_case_attr00
INTO (DATA(lv_disp_date), DATA(lv_disp_time), DATA(lv_disp_user))
WHERE [Your logic to link invoice to dispute case, e.g., via a custom field or object link].
IF sy-subrc = 0.
gs_event_log-activityname = 'Dispute Case Created'.
gs_event_log-username = lv_disp_user.
CONVERT DATE lv_disp_date TIME lv_disp_time INTO TIME STAMP gs_event_log-eventtime TIME ZONE sy-zonlo.
APPEND gs_event_log TO gt_event_log.
ENDIF.
ENDLOOP.
*&---------------------------------------------------------------------*
*& Write data to file
*&---------------------------------------------------------------------*
OPEN DATASET p_path FOR OUTPUT IN TEXT MODE ENCODING UTF-8.
IF sy-subrc <> 0.
MESSAGE 'Error opening file.' TYPE 'E'.
ENDIF.
" Header
DATA(lv_header) = 'InvoiceNumber,ActivityName,EventTime,UserName,BillingDocumentType,CustomerNumber,CompanyCode,TotalInvoiceAmount'.
TRANSFER lv_header TO p_path.
LOOP AT gt_event_log INTO gs_event_log.
DATA(lv_line) = |
{ gs_event_log-invoicenumber }|
,{ gs_event_log-activityname }|
,{ gs_event_log-eventtime }|
,{ gs_event_log-username }|
,{ gs_event_log-billingdocumenttype }|
,{ gs_event_log-customernumber }|
,{ gs_event_log-companycode }|
,{ gs_event_log-totalinvoiceamount }|.
TRANSFER lv_line TO p_path.
ENDLOOP.
CLOSE DATASET p_path.
WRITE: 'Extraction complete. File created at:', p_path. Schritte
- Voraussetzungen und Zugriff: Stellen Sie sicher, dass Sie über einen Datenbankbenutzer mit Lesezugriff auf die erforderlichen SAP-ECC-Tabellen verfügen, darunter VBRK, BKPF, BSAD, NAST, CDHDR, CDPOS, SCASE und weitere in der Abfrage angegebene Tabellen. Ein solcher Zugriff wird üblicherweise nur Systemadministratoren oder bestimmten Datenanalyseteams gewährt.
- Mit der Datenbank verbinden: Stellen Sie mit einem gängigen SQL-Client wie DBeaver, Oracle SQL Developer oder Microsoft SQL Server Management Studio eine Verbindung zur SAP-ECC-Datenbank her.
- SQL-Abfrage vorbereiten: Kopieren Sie die vollständige SQL-Abfrage aus dem Abschnitt „query“ in den Editor Ihres SQL-Clients.
- Platzhalter anpassen: Ersetzen Sie die Platzhalter in der Abfrage durch Werte für Ihre Umgebung. Dazu gehören:
'YYYYMMDD': Ersetzen Sie alle Vorkommen durch Anfangs- und Enddatum des gewünschten Analysezeitraums. Begrenzen Sie den Zeitraum unbedingt auf einen überschaubaren Umfang.'XXXX': Ersetzen Sie den Platzhalter durch den oder die zu analysierenden Buchungskreise.[Your Invoice Output Type]: Geben Sie den Ausgabetyp an, mit dem Rechnungen an Kunden gesendet werden, zum Beispiel „RD00“.[Your Bad Debt G/L Account]: Geben Sie die Sachkontonummer an, auf die uneinbringliche Rechnungen abgeschrieben werden.[Your Dispute Case Invoice Attribute]: Geben Sie den Attributnamen an, unter dem die Rechnungsnummer in Ihrer Dispute-Management-Konfiguration gespeichert ist, zum Beispiel „INVOICE_ID“.
- Timestamp-Funktionen prüfen: Die Abfrage verwendet die allgemeine Syntax
CAST(CONCAT(date_field, time_field) AS TIMESTAMP). Passen Sie diese gegebenenfalls an Ihr Datenbanksystem an, zum Beispiel mitTO_TIMESTAMPfür Oracle oderDATETIMEFROMPARTSfür SQL Server. - Abfrage ausführen: Führen Sie die angepasste Abfrage aus. Je nach Umfang der SAP-Tabellen und gewähltem Zeitraum kann die Ausführung längere Zeit in Anspruch nehmen.
- Ergebnisse prüfen: Prüfen Sie nach Abschluss der Abfrage, ob die erwarteten Spalten enthalten sind: InvoiceNumber, ActivityName, EventTime und die empfohlenen Attribute. Achten Sie auf Fehler und leere Ergebnisse.
- Als CSV exportieren: Exportieren Sie das vollständige Ergebnis aus Ihrem SQL-Client in eine CSV-Datei. Verwenden Sie UTF-8-Codierung, um Probleme mit Sonderzeichen zu vermeiden.
- Für den Upload vorbereiten: Prüfen Sie vor dem Upload in ein Process-Mining-Tool, ob die CSV-Spaltenüberschriften exakt den erforderlichen Attributnamen entsprechen, zum Beispiel
InvoiceNumber,ActivityName,EventTime,UserName.
Konfiguration
- Datenbankverbindung: Erforderlich ist eine direkte SQL-Verbindung mit Lesezugriff auf die zugrunde liegende SAP-ECC-Datenbank. Bei dieser Methode wird die SAP-Anwendungsschicht vollständig umgangen.
- Berechtigungen: Der Datenbankbenutzer benötigt
SELECT-Berechtigungen für alle in der Abfrage verwendeten Tabellen aus den Modulen FI, SD und gegebenenfalls FSCM. - Zeitraum: Begrenzen Sie die Abfrage unbedingt auf einen bestimmten Zeitraum, damit Leistung und Datenvolumen im Rahmen bleiben. Wir empfehlen, zunächst einen Zeitraum von 3 bis 6 Monaten zu verwenden. Die Platzhalter
'YYYYMMDD'für den Datumsfilter müssen an mehreren Stellen in der Abfrage angepasst werden. - Buchungskreisfilter: Die Abfrage ist für eine Filterung nach Buchungskreis (
BUKRS) ausgelegt. Üblicherweise werden jeweils ein oder wenige Buchungskreise analysiert. - Belegarten konfigurieren: Die Erkennung von Ereignissen wie Rechnungskorrekturen, Abschreibungen oder versendeten Belegen hängt von der SAP-Standardkonfiguration ab. Passen Sie die Abfrage gegebenenfalls an, wenn Ihr Unternehmen benutzerdefinierte Belegarten (
BLART), Ausgabetypen (KSCHL) oder Sachkonten für diese Prozesse verwendet. - Leistung berücksichtigen: Die Ausführung dieser Abfrage auf einem produktiven SAP-System kann erhebliche Ressourcen beanspruchen und den laufenden Betrieb beeinträchtigen. Führen Sie umfangreiche Extraktionen möglichst außerhalb der Spitzenzeiten oder auf einer dedizierten Reporting-Replik der Datenbank aus.
a Beispielabfrage sql
WITH InvoiceBase AS (
SELECT
VBRK.VBELN AS InvoiceNumber,
VBRK.FKART AS BillingDocumentType,
VBRK.KUNRG AS CustomerNumber,
VBRK.BUKRS AS CompanyCode,
VBRK.NETWR AS TotalInvoiceAmount,
VBRK.ERNAM AS CreatorName,
VBRK.ERDAT AS CreationDate,
VBRK.ERZET AS CreationTime
FROM VBRK
WHERE VBRK.ERDAT BETWEEN '20230101' AND '20231231' -- Filter by Invoice Creation Date
AND VBRK.BUKRS IN ('1000') -- Filter by Company Code
AND VBRK.FKART NOT IN ('S1', 'S2') -- Exclude cancelled invoices
)
-- 1. Invoice Generated
SELECT
ib.InvoiceNumber,
'Invoice Generated' AS ActivityName,
CAST(CONCAT(ib.CreationDate, ib.CreationTime) AS TIMESTAMP) AS EventTime,
ib.CreatorName AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM InvoiceBase ib
UNION ALL
-- 2. Invoice Parked
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Parked' AS ActivityName,
CAST(CONCAT(b.CPUDT, b.CPUTM) AS TIMESTAMP) AS EventTime,
b.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF b
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND b.BSTAT = 'V' AND b.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 3. Invoice Posted
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Posted' AS ActivityName,
CAST(CONCAT(b.CPUDT, b.CPUTM) AS TIMESTAMP) AS EventTime,
b.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF b
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND b.BSTAT = '' AND b.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 4. Invoice Approved (from Parked to Posted)
SELECT
SUBSTRING(h.OBJECTID, 4, 10) AS InvoiceNumber,
'Invoice Approved' as ActivityName,
CAST(CONCAT(h.UDATE, h.UTIME) AS TIMESTAMP) AS EventTime,
h.USERNAME AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM CDHDR h
JOIN CDPOS p ON h.MANDANT = p.MANDANT AND h.OBJECTCLAS = p.OBJECTCLAS AND h.OBJECTID = p.OBJECTID AND h.CHANGENR = p.CHANGENR
JOIN InvoiceBase ib ON SUBSTRING(h.OBJECTID, 4, 10) = ib.InvoiceNumber
WHERE h.OBJECTCLAS = 'BELEGV'
AND p.TABNAME = 'BKPF'
AND p.FNAME = 'BSTAT'
AND p.VALUE_OLD = 'V'
AND p.VALUE_NEW = ' '
AND h.UDATE BETWEEN '20230101' AND '20231231'
UNION ALL
-- 5. Invoice Sent To Customer
SELECT
n.OBJKY AS InvoiceNumber,
'Invoice Sent To Customer' AS ActivityName,
CAST(CONCAT(n.DATVR, n.UHRVR) AS TIMESTAMP) AS EventTime,
n.VSTAT AS UserName, -- User who processed is not directly available, using processing status as a proxy
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM NAST n
JOIN InvoiceBase ib ON n.OBJKY = ib.InvoiceNumber
WHERE n.KSCHL = '[Your Invoice Output Type]' -- E.g., 'RD00'
AND n.VSTAT = '1' -- Processed successfully
AND n.DATVR BETWEEN '20230101' AND '20231231'
UNION ALL
-- 6. Invoice Corrected (Reversed)
SELECT
SUBSTRING(orig_doc.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Corrected' AS ActivityName,
CAST(CONCAT(rev_doc.CPUDT, rev_doc.CPUTM) AS TIMESTAMP) AS EventTime,
rev_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
rev_doc.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BKPF orig_doc
JOIN BKPF rev_doc ON orig_doc.STBLG = rev_doc.BELNR AND orig_doc.BUKRS = rev_doc.BUKRS AND orig_doc.GJAHR = rev_doc.STJAH
JOIN InvoiceBase ib ON SUBSTRING(orig_doc.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE orig_doc.AWTYP = 'VBRK' AND orig_doc.STBLG IS NOT NULL AND rev_doc.CPUDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 7. Invoice Due Date Reached
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Invoice Due Date Reached' AS ActivityName,
CAST(CONCAT(bs.ZFBDT, '000000') AS TIMESTAMP) AS EventTime,
'System' AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
b.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSEG bs
JOIN BKPF b ON bs.MANDT = b.MANDT AND bs.BUKRS = b.BUKRS AND bs.BELNR = b.BELNR AND bs.GJAHR = b.GJAHR
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE b.AWTYP = 'VBRK' AND bs.KOART = 'D' AND bs.ZFBDT BETWEEN '20230101' AND '20231231'
UNION ALL
-- 8. Payment Reminder Issued
SELECT
SUBSTRING(b.AWKEY, 1, 10) AS InvoiceNumber,
'Payment Reminder Issued' AS ActivityName,
CAST(CONCAT(h.LAUFD, '000000') AS TIMESTAMP) AS EventTime,
h.LAUFI AS UserName, -- Dunning Run ID
ib.BillingDocumentType,
ib.CustomerNumber,
d.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM MHND d
JOIN MHNK h ON d.MANDT = h.MANDT AND d.LAUFD = h.LAUFD AND d.LAUFI = h.LAUFI
JOIN BKPF b ON d.MANDT = b.MANDT AND d.BUKRS = b.BUKRS AND d.BELNR = b.BELNR AND d.GJAHR = b.GJAHR
JOIN InvoiceBase ib ON SUBSTRING(b.AWKEY, 1, 10) = ib.InvoiceNumber
WHERE h.LAUFD BETWEEN '20230101' AND '20231231'
UNION ALL
-- 9. Dispute Case Created
SELECT
attr.ATTR_VALUE AS InvoiceNumber,
'Dispute Case Created' AS ActivityName,
sc.CREATE_TIME AS EventTime,
sc.CREATED_BY AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
ib.CompanyCode,
ib.TotalInvoiceAmount
FROM SCMG_T_CASE_ATTR attr
JOIN SCASE sc ON attr.CASE_GUID = sc.CASE_GUID
JOIN InvoiceBase ib ON attr.ATTR_VALUE = ib.InvoiceNumber
WHERE attr.ATTR_NAME = '[Your Dispute Case Invoice Attribute]' -- e.g., 'INVOICE_ID'
AND CAST(sc.CREATE_TIME AS DATE) BETWEEN '20230101' AND '20231231'
UNION ALL
-- 10, 11, 12. Clearing Events (Payment, Clearing, Write-Off)
SELECT
InvoiceNumber,
ActivityName,
EventTime,
UserName,
BillingDocumentType,
CustomerNumber,
CompanyCode,
TotalInvoiceAmount
FROM (
SELECT
bsad.XBLNR AS InvoiceNumber,
CASE
WHEN clearing_item.HKONT = '[Your Bad Debt G/L Account]' THEN 'Invoice Written Off'
ELSE 'Customer Payment Received'
END AS ActivityName,
CAST(CONCAT(clearing_doc.CPUDT, clearing_doc.CPUTM) AS TIMESTAMP) AS EventTime,
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
LEFT JOIN BSEG clearing_item ON clearing_doc.MANDT = clearing_item.MANDT AND clearing_doc.BUKRS = clearing_item.BUKRS AND clearing_doc.BELNR = clearing_item.BELNR AND clearing_doc.GJAHR = clearing_item.GJAHR AND clearing_item.HKONT = '[Your Bad Debt G/L Account]' -- e.g. '148000'
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
UNION ALL
SELECT
bsad.XBLNR AS InvoiceNumber,
'Payment Applied To Invoice' AS ActivityName,
CAST(CONCAT(bsad.AUGDT, '000000') AS TIMESTAMP) AS EventTime,
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
UNION ALL
SELECT
bsad.XBLNR AS InvoiceNumber,
'Invoice Cleared' AS ActivityName,
CAST(CONCAT(bsad.AUGDT, '235959') AS TIMESTAMP) AS EventTime, -- Add time to separate from 'Payment Applied'
clearing_doc.USNAM AS UserName,
ib.BillingDocumentType,
ib.CustomerNumber,
bsad.BUKRS AS CompanyCode,
ib.TotalInvoiceAmount
FROM BSAD bsad
JOIN InvoiceBase ib ON bsad.XBLNR = ib.InvoiceNumber
JOIN BKPF clearing_doc ON bsad.MANDT = clearing_doc.MANDT AND bsad.BUKRS = clearing_doc.BUKRS AND bsad.AUGBL = clearing_doc.BELNR AND bsad.AUGGJ = clearing_doc.GJAHR
WHERE bsad.AUGDT BETWEEN '20230101' AND '20231231' AND bsad.UMSKZ = ''
) AS ClearingEvents Schritte
- Voraussetzungen: Stellen Sie sicher, dass Sie über ein lizenziertes ETL-Tool mit einem zertifizierten SAP-Connector verfügen, zum Beispiel Informatica PowerCenter mit SAP Connector oder Talend mit SAP Connector. Prüfen Sie, ob Sie SAP-Zugangsdaten mit den erforderlichen Berechtigungen zum Lesen der Finanz-, Vertriebs- und Systemtabellen haben (BKPF, BSEG, VBRK, NAST, MHNK, UDM_CASE_ATTR00, CDHDR, CDPOS).
- SAP-Verbindung herstellen: Richten Sie in Ihrem ETL-Tool eine neue Verbindung zu Ihrem SAP-ECC-System ein. Konfigurieren Sie Anwendungsserver, Systemnummer, Mandant, Benutzer und Passwort. Testen Sie anschließend die Verbindung.
- Datenquellen festlegen: Definieren Sie für jede zu extrahierende Aktivität die zugehörigen SAP-Tabellen als Datenquellen in Ihrem ETL-Auftrag. Fügen Sie beispielsweise VBRK für die Rechnungserstellung, BKPF für Buchungsereignisse und NAST für die Kundenkommunikation hinzu.
- Extraktionslogik für jede Aktivität erstellen: Richten Sie für jede der 13 erforderlichen Aktivitäten einen eigenen Datenfluss oder eine eigene Transformation ein. Filtern Sie darin die relevanten Datensätze, zum Beispiel nach Buchungskreis (BUKRS), Belegart (BLART) und einem bestimmten Zeitraum (etwa nach Erstellungsdatum ERDAT).
- Felder zuordnen und Daten umwandeln: Ordnen Sie in jedem Datenfluss die Felder der SAP-Quelltabellen der Zielstruktur des Event Logs zu: InvoiceNumber, ActivityName, EventTime, UserName und weitere empfohlene Attribute. Legen Sie den jeweiligen Wert für „ActivityName“ in jedem Datenfluss fest und formatieren Sie Datums- und Timestamp-Werte korrekt.
- Komplexe Aktivitäten verarbeiten: Berechnen Sie Ereignisse wie „Rechnung fällig“ anhand des Basiszahlungsdatums (ZFBDT) und der Zahlungsbedingungen oder übernehmen Sie einfach das Nettofälligkeitsdatum (NETDT) aus BSEG. Für Ereignisse aus Änderungsprotokollen wie „Rechnung genehmigt“ müssen Sie möglicherweise BKPF und CDHDR/CDPOS anhand von Belegnummer und Datum verknüpfen.
- Aktivitätsdaten zusammenführen: Führen Sie die Ergebnisse der 13 einzelnen Datenflüsse mit einer „Union“- oder „Merge“-Transformation in Ihrem ETL-Tool zu einem Datensatz zusammen. Achten Sie vor dem Zusammenführen auf einheitliche Spaltennamen und Datentypen.
- Ziel festlegen: Definieren Sie das Ausgabeziel für Ihr Event Log. Möglich sind eine Textdatei (CSV), eine Datenbanktabelle oder eine direkte Verbindung zu einem Staging-Bereich.
- Extraktionszeitplan festlegen: Konfigurieren Sie die Parameter für den Extraktionszeitraum. Für den ersten Ladevorgang können Sie 6 bis 12 Monate an Daten extrahieren. Richten Sie für spätere Delta-Ladevorgänge den Auftrag so ein, dass er Daten seit dem letzten Lauf abruft.
- Ausführen und exportieren: Führen Sie den ETL-Auftrag aus. Prüfen Sie anschließend, ob die Ausgabedatei das erforderliche Format hat. Die fertige CSV-Datei sollte für den Upload in ProcessMind bereitstehen und jede Zeile einem eindeutigen Ereignis entsprechen.
Konfiguration
- SAP-Verbindung: Erforderlich ist eine Verbindung zum Anwendungsserver des betreffenden SAP-ECC-Systems. Der SAP-Benutzer benötigt RFC-Zugriff und Berechtigungen für Tabellen wie VBRK, BKPF, BSEG, NAST und weitere in der Abfrage angegebene Tabellen.
- ETL-Tool-Lizenz: Eine gültige Lizenz für das kommerzielle ETL-Tool und den zugehörigen SAP-Connector ist erforderlich.
- Zeitraum: Für eine aussagekräftige Stichprobe ohne übermäßige Systemlast empfiehlt sich eine Extraktion über einen Zeitraum von 3 bis 6 Monaten. Verwenden Sie konfigurierbare Parameter für Anfangs- und Enddatum.
- Wichtige Filter: Filtern Sie immer nach Buchungskreis (BUKRS), um den Umfang der Extraktion zu begrenzen. Filtern Sie außerdem unbedingt nach den relevanten Fakturaarten (VBRK-FKART) und Buchungsbelegarten (BKPF-BLART), damit nur Standardrechnungen berücksichtigt und andere Belegarten wie Gutschriften oder interne Belege ausgeschlossen werden.
- Leistung: Die Extraktion aus großen Tabellen wie BSEG kann lange dauern. Verwenden Sie gezielte Filter, lassen Sie nicht benötigte Felder weg und planen Sie die Extraktion außerhalb der Spitzenzeiten, um die Auswirkungen auf das SAP-Quellsystem zu begrenzen.
a Beispielabfrage config
// ETL Data Extraction Logic for SAP Order-to-Cash Invoicing
// This represents the configuration logic within a graphical ETL tool.
// == Global Parameters ==
// $StartDate: '[Start Date]' (e.g., '2023-01-01')
// $EndDate: '[End Date]' (e.g., '2023-06-30')
// $CompanyCodes: '[Company Code(s)]' (e.g., '1000', '2000')
// $BillingDocTypes: '[Billing Document Type(s)]' (e.g., 'F1', 'F2')
// == Source 1: Invoice Generated ==
// Tables: VBRK
DATA_SOURCE generated_invoices FROM VBRK WHERE
ERDAT >= $StartDate AND ERDAT <= $EndDate
AND BUKRS IN ($CompanyCodes)
AND FKART IN ($BillingDocTypes)
MAP {
InvoiceNumber: VBELN,
ActivityName: 'Invoice Generated',
EventTime: ERDAT + ERZET, // Combine date and time
UserName: ERNAM,
BillingDocumentType: FKART,
CustomerNumber: KUNAG,
CompanyCode: BUKRS,
TotalInvoiceAmount: NETWR
}
// == Source 2: Invoice Posted ==
// Tables: BKPF joined with VBRK
DATA_SOURCE posted_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.BUDAT >= $StartDate AND A.BUDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = ' '
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Posted',
EventTime: A.BUDAT + A.CPUTM, // Posting date and entry time
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 3: Invoice Parked ==
// Tables: BKPF joined with VBRK
DATA_SOURCE parked_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.CPUDT >= $StartDate AND A.CPUDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = 'V'
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Parked',
EventTime: A.CPUDT + A.CPUTM,
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 4: Invoice Approved (Transition from Parked to Posted) ==
// Tables: BKPF joined with VBRK
DATA_SOURCE approved_invoices FROM BKPF as A
INNER JOIN VBRK as B ON (A.AWKEY = B.VBELN AND A.AWTYP = 'VBRK')
WHERE A.BUDAT >= $StartDate AND A.BUDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.BSTAT = ' '
AND EXISTS (SELECT 1 FROM VBELEGV C WHERE C.BELNR = A.BELNR) // Check if it was ever parked
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Approved',
EventTime: A.BUDAT + A.CPUTM, // Use posting date as approval date
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 5: Invoice Sent To Customer ==
// Tables: NAST joined with VBRK
DATA_SOURCE sent_invoices FROM NAST as A
INNER JOIN VBRK as B ON (A.OBJKY = B.VBELN)
WHERE A.ERDAT >= $StartDate AND A.ERDAT <= $EndDate
AND B.BUKRS IN ($CompanyCodes)
AND A.VSTAT = '1' // Successfully processed
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Sent To Customer',
EventTime: A.ERDAT + A.ERUHR,
UserName: A.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: B.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 6: Invoice Corrected (Reversed) ==
// Tables: VBRK (for the reversal document)
DATA_SOURCE corrected_invoices FROM VBRK as A
WHERE A.ERDAT >= $StartDate AND A.ERDAT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.SFAKN <> '' // SFAKN is the original cancelled invoice
MAP {
InvoiceNumber: A.SFAKN, // Case ID is the original invoice
ActivityName: 'Invoice Corrected',
EventTime: A.ERDAT + A.ERZET,
UserName: A.ERNAM,
BillingDocumentType: A.FKART,
CustomerNumber: A.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: NULL // Amount belongs to the reversal doc, not original
}
// == Source 7: Invoice Due Date Reached ==
// Tables: BSEG joined with VBRK
DATA_SOURCE due_invoices FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
WHERE A.NETDT >= $StartDate AND A.NETDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.KOART = 'D' // Customer line item
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Due Date Reached',
EventTime: A.NETDT, // Net due date
UserName: 'System',
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 8: Payment Reminder Issued ==
// Tables: MHNK, MHND, VBRK
DATA_SOURCE reminders FROM MHNK as A
INNER JOIN MHND as D ON (A.LAUFD = D.LAUFD AND A.LAUFI = D.LAUFI)
INNER JOIN VBRK as B ON (SUBSTRING(D.XBLNR, 1, 10) = B.VBELN) // XBLNR may need parsing
WHERE A.LAUFD >= $StartDate AND A.LAUFD <= $EndDate
AND D.BUKRS IN ($CompanyCodes)
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Payment Reminder Issued',
EventTime: A.LAUFD, // Dunning date
UserName: A.IDAPS,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: D.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 9: Dispute Case Created ==
// Tables: UDM_CASE_ATTR00
DATA_SOURCE disputes FROM UDM_CASE_ATTR00 as A
WHERE A.CREATE_TIMESTAMP >= $StartDate // Timestamp format may vary
AND A.FIN_COMP_CODE IN ($CompanyCodes)
AND A.PROCESS = 'FIN_FSCM_DIS'
MAP {
InvoiceNumber: A.BILL_DOC_ID,
ActivityName: 'Dispute Case Created',
EventTime: A.CREATE_TIMESTAMP,
UserName: A.CREATE_USER,
BillingDocumentType: NULL,
CustomerNumber: A.BP_NUMBER,
CompanyCode: A.FIN_COMP_CODE,
TotalInvoiceAmount: A.DISPUTED_AMOUNT
}
// == Source 10: Customer Payment Received ==
// Tables: BKPF
DATA_SOURCE payments FROM BKPF
WHERE BUDAT >= $StartDate AND BUDAT <= $EndDate
AND BUKRS IN ($CompanyCodes)
AND BLART = 'DZ' // Example for Customer Payment
MAP {
InvoiceNumber: NULL, // Invoice not yet known
ActivityName: 'Customer Payment Received',
EventTime: BUDAT + CPUTM,
UserName: USNAM,
BillingDocumentType: NULL,
CustomerNumber: NULL, // Requires join to BSEG to get customer
CompanyCode: BUKRS,
TotalInvoiceAmount: NULL
}
// == Source 11 & 12: Payment Applied To Invoice & Invoice Cleared ==
// Tables: BSEG joined with VBRK
DATA_SOURCE cleared_items FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
WHERE A.AUGDT >= $StartDate AND A.AUGDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND A.AUGBL <> ''
// Generate two records from this source
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Payment Applied To Invoice',
EventTime: A.AUGDT, // Clearing Date
UserName: H.USNAM, // User from header of original invoice doc
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
UNION WITH {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Cleared',
EventTime: A.AUGDT, // Clearing Date
UserName: H.USNAM,
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Source 13: Invoice Written Off ==
// Tables: BSEG (for the invoice line) and BKPF (for clearing doc type)
DATA_SOURCE written_off FROM BSEG as A
INNER JOIN BKPF as H ON (A.BUKRS = H.BUKRS AND A.BELNR = H.BELNR AND A.GJAHR = H.GJAHR)
INNER JOIN VBRK as B ON (H.AWKEY = B.VBELN AND H.AWTYP = 'VBRK')
INNER JOIN BKPF as C ON (A.AUGBL = C.BELNR AND A.BUKRS = C.BUKRS AND A.AUGGJ = C.GJAHR)
WHERE A.AUGDT >= $StartDate AND A.AUGDT <= $EndDate
AND A.BUKRS IN ($CompanyCodes)
AND C.BLART = '[Your Write-Off Document Type]' // e.g., 'AB'
MAP {
InvoiceNumber: B.VBELN,
ActivityName: 'Invoice Written Off',
EventTime: A.AUGDT,
UserName: C.USNAM, // User who posted the write-off
BillingDocumentType: B.FKART,
CustomerNumber: B.KUNAG,
CompanyCode: A.BUKRS,
TotalInvoiceAmount: B.NETWR
}
// == Final Union of all sources ==
OUTPUT generated_invoices
UNION ALL posted_invoices
UNION ALL parked_invoices
UNION ALL approved_invoices
UNION ALL sent_invoices
UNION ALL corrected_invoices
UNION ALL due_invoices
UNION ALL reminders
UNION ALL disputes
UNION ALL payments
UNION ALL cleared_items
UNION ALL written_off Möchten Sie loslegen?
Mit diesem Template bereiten Sie Ihre Daten effizient vor und gewinnen wertvolle Erkenntnisse zu Ihren Fakturierungs- und Rechnungsstellungsprozessen. Beginnen Sie noch heute damit, Ihren Cashflow zu beschleunigen.
Beschleunigen Sie Ihren Cashflow: Optimieren Sie Fakturierung und Rechnungsstellung noch heute!
Beseitigen Sie Ineffizienzen, verkürzen Sie die Zykluszeit um 30 % und verbessern Sie Ihren Cashflow.
Keine Kreditkarte erforderlich. Beginnen Sie in wenigen Minuten mit der Optimierung.