SAP PRESS ABAP-Programmierung für den Vertrieb mit SAP – User-Exits und BAdIs von Petra Just, Thomas Klein 1. Auflage Rheinwerk Verlag 2011 Verlag C.H. Beck im Internet: www.beck.de ISBN 978 3 8362 1722 4 schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG
38
Embed
ABAP-Programmierung für den Vertrieb mit SAP User-Exits ... · PDF fileDie Vertriebskomponente von SAP (Sales & Distribution, SD) ist sehr umfangreich und beinhaltet Einstellun...
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
SAP PRESS
ABAP-Programmierung für den Vertrieb mit SAP – User-Exits und BAdIs
vonPetra Just, Thomas Klein
1. Auflage
Rheinwerk Verlag 2011
Verlag C.H. Beck im Internet:www.beck.de
ISBN 978 3 8362 1722 4
schnell und portofrei erhältlich bei beck-shop.de DIE FACHBUCHHANDLUNG
1.4 Exit oder BAdI? ...................................................................... 64
2 Generelle Erweiterungsmöglichkeiten im Vertrieb mit SAP .................................................................. 67
2.1 Übersicht über den Auftrag ................................................... 672.2 Werk im Auftrag vorschlagen ................................................. 68
3.6 Kundeneigene Logik der Routenfindung implementieren ....... 1293.6.1 Bedarf spezifizieren ................................................... 1293.6.2 Alternativen im Standard prüfen ............................... 1303.6.3 Programmierung in den Exit einbinden ..................... 1313.6.4 Zweiter Exit mit Customizing-Tabelle ........................ 1343.6.5 Programmierung in ein BAdI einbinden ..................... 1363.6.6 Zweites Beispiel mit Customizing-Tabelle .................. 139
3.7 Eigene Felder in der Nachrichtenfindung nutzen .................... 1403.7.1 Bedarf spezifizieren ................................................... 1413.7.2 Feld in die Kommunikationsstruktur einbinden ......... 1413.7.3 Feld in die Kommunikationsstruktur KOMB
einbinden ................................................................. 1433.7.4 Neues Feld über Exit füllen ....................................... 1433.7.5 In das Customizing einbinden ................................... 144
147
4 Erweiterungsmöglichkeiten in der Fakturierung ................ 147
4.1 Übersicht über den Rechnungsbeleg ...................................... 1474.2 Faktura mit eigenen Daten versorgen .................................... 148
4.3 Nummernvergabe in der Faktura erweitern ............................ 1534.3.1 Bedarf spezifizieren ................................................... 1544.3.2 Kundeneigene Tabelle anlegen .................................. 1544.3.3 Erweiterung analysieren ............................................ 1554.3.4 Sourcecode des User-Exits ........................................ 1554.3.5 Zweites Beispiel zur Nummernvergabe in der
Rechnung ................................................................. 1584.4 Preisfindung in der Faktura erweitern .................................... 159
5 Erweiterungsmöglichkeiten im Transportwesen ................ 167
5.1 Übersicht über den Transportbeleg ........................................ 1675.1.1 Bedeutung des Transportbeleges ............................... 1675.1.2 Mögliche Schritte im Transportbeleg ......................... 169
A User-Exits und BAdIs in Vertrieb und Versand .................................. 223A.1 Auftrag .................................................................................. 223A.2 Lieferung/Versand ................................................................. 231A.3 Faktura .................................................................................. 236A.4 Transportbeleg ...................................................................... 239A.5 Frachtkosten .......................................................................... 241
B Übersicht aller Programmierbeispiele ............................................... 245B.1 Listings aus Kapitel 1 ............................................................. 245B.2 Listings aus Kapitel 2 ............................................................. 246B.3 Listings aus Kapitel 3 ............................................................. 250B.4 Listings aus Kapitel 4 ............................................................. 256B.5 Listings aus Kapitel 5 ............................................................. 260B.6 Listings aus Kapitel 6 ............................................................. 267
C Die Autoren ..................................................................................... 271
Index ........................................................................................................ 273
11
Einleitung
Die Vertriebskomponente von SAP (Sales & Distribution, SD) ist sehr umfangreich und beinhaltet Einstellungsmöglichkeiten der Prozesskette vom Auftrag über Lieferung, Transportbeleg und Rechnung bis hin zum Fracht-kostenbeleg. Um das Standard-SAP-System so einzustellen, dass es die spezi-fischen Prozesse eines Unternehmens abdeckt, verwendet man das Customi-zing. Zusätzlich gibt es aber auch zahlreiche Erweiterungsmöglichkeiten durch eigene Programmierung, die an bestimmten Stellen und unter Einhal-tung gewisser Regeln implementiert werden können.
Vielleicht haben Sie sich auch schon einmal gefragt, warum es eigentlich bis-her kein Buch über genau diese zahlreichen Erweiterungsmöglichkeiten der SAP-Vertriebskomponente (»SD-Modul«) gibt. So ging es uns jedenfalls. Während unserer langjährigen Arbeit mit dem SAP-System haben wir immer wieder Erweiterungen genutzt. In unterschiedlichen Projekten haben man-che von uns sogar oft die gleichen Exits mit ähnlichem Sourcecode verwen-det – die aber nie zentral dokumentiert und mit Beispielen belegt wurden, um sie vernünftig anwenden zu können. Darüber haben wir mit befreunde-ten Entwicklern und Beraterkollegen gesprochen, und so ist die Idee zu die-sem Buch entstanden. Gerade zu den Erweiterungen ist ein Buch eine sinn-volle Ergänzung zum SAP-System, das in diesem Bereich nicht so umfangreich dokumentiert ist. Diese Lücke möchten wir füllen – zumindest zu einem kleinen Teil.
Zielsetzung
Wir haben die Beispiele ausgewählt, die uns in der Praxis besonders häufig begegnet sind. Unser Ziel war auch, dass das Zusammenspiel verschiedener Exits deutlich wird, und daher haben wir einige Beispiele so gestaltet, dass Sie sie als Gesamtkonzept umsetzen können. Neue Felder im Kundenstamm beinhalten zum Beispiel die Erweiterung des Bildschirms im Kundenstamm, die Erweiterung des Bildschirms im Auftrag, die Einbindung in das Unvoll-ständigkeitsprotokoll und die Kopiersteuerung in die Auslieferung.
Es war uns dabei sehr wichtig, dass Sie als Leser dieses Buches unmittelbar davon profitieren. Anhand zahlreicher Screenshots können Sie »wie im
Einleitung
12
System« lernen, auch wenn Sie nicht gerade das SAP-System vor sich haben, sondern das Buch im Flugzeug oder Zug lesen. Zum Teil haben wir versucht, mehrere Transaktionen in einer Abbildung darzustellen, damit Sie alle Schritte auf einen Blick sehen können.
Das Gleiche gilt für die Beispielprogramme: Diese haben wir alle Schritt für Schritt für Sie kommentiert, damit Sie die wesentlichen Bestandteile sofort im Verlauf eines Abschnitts oder Kapitels nachvollziehen können. Aber Sie finden sie auch vollständig und zusammenhängend im Anhang des Buches abgedruckt, falls Sie sich den Komplettaufbau anschauen möchten, ohne dafür in das System zu wechseln.
Bei alledem ist es uns ein Anliegen, aufzuzeigen, wie wichtig es ist, trotz aller Alternativen möglichst mit dem SAP-Standard zu arbeiten und kundenspezi-fische Erweiterungen über das Standard-Customizing zu erreichen. Auch Erweiterungen in Exits und BAdIs können Sie nah am Standard oder weit entfernt vom Standard programmieren. Wir können Ihnen nur dazu raten, möglichst nah am Standard zu bleiben, daher geben wir Ihnen im Buch immer wieder konkrete Empfehlungen, wann die Abweichung von diesem Weg sinnvoll oder geboten ist.
Zielgruppen
In vielen Projekten gibt es eine klare Aufteilung der Teams in funktionale Berater/Mitarbeiter und Entwickler. Der funktionale Berater schreibt eine Spezifikation, die der Entwickler programmiert. Dabei ist es hilfreich, wenn der Entwickler über den Tellerrand hinausschaut und dem funktionalen Berater eigene Vorschläge unterbreitet und der funktionale Berater sich nicht nur auf den Business-Bereich beschränkt, sondern auch tiefer gehende technische Kenntnisse hat.
Dieses Buch ist daher für beide Zielgruppen geschrieben: für den Entwickler, der das Customizing und den Hintergrund verstehen und auch gern Vor-schläge für BAdIs, Exits oder Routinen unterbreiten möchte. Er kann hier Programmbeispiele finden, die seine direkte Arbeit erleichtern werden. Aber das Buch ist auch für den funktionalen Berater/Mitarbeiter von Nutzen, der die Erweiterungen des Systems verstehen möchte, um die richtige Option anbieten zu können.
Neben diesen beiden Arten von Projektmitarbeitern gibt es viele andere, die von diesem Buch profitieren werden: Projektleiter, die sich auch fachlich
Einleitung
13
detailliert auskennen möchten, und alle anderen Projektmitarbeiter, deren fachliche Qualifikation von größter Bedeutung ist. Sie alle hatten wir im Hin-terkopf, da wir selbst schon verschiedene dieser Rollen in Projekten besetzt und ausgefüllt haben, uns aber vor allem mit Kollegen und Freunden ausge-tauscht haben, die ihre Sicht auf die Inhalte dieses Buches geschildert haben.
Aufbau und Inhalt
Das Buch ist so aufgebaut, dass wir für die Bereiche Vertrieb, Versand, Fak-turierung, Transport und Frachtkosten möglichst jeweils BAdIs und Exits vorstellen. Der Aufbau folgt dabei der Logik der Prozesskette im Vertrieb:
� In Kapitel 1, »Allgemeines zu User-Exits, Routinen und BAdIs«, wird aus-führlich beschrieben, welche SD-Erweiterungen es gibt und wie Sie sie finden. Gerade die Suche nach passenden Exits, Routinen, aber auch BAdIs ist in der Praxis für alle Projektmitglieder wichtig. Hier kam es uns darauf an, sowohl die Suchwege über das Repository als auch die klassi-schen Möglichkeiten über die direkte Transaktion aufzuzeigen.
� In den folgenden Kapiteln werden dann Exits, BAdIs und Routinen konkret beschrieben. Dabei ist jedem Beleg in der Prozesskette des SD-Systems ein Kapitel gewidmet: Auftrag (Kapitel 2, »Generelle Erweite-rungsmöglichkeiten im Vertrieb mit SAP«), Auslieferung (Kapitel 3, »Erweiterungsmöglichkeiten im Versand«), Rechnung (Kapitel 4, »Erwei-terungsmöglichkeiten in der Fakturierung«), Transport (Kapitel 5, »Erwei-terungsmöglichkeiten im Transportwesen«) und Fracht (Kapitel 6, »Erweiterungsmöglichkeiten im Frachtkostenbeleg«).
Innerhalb dieser fünf Kapitel gibt es dann jeweils eine Einleitung, die den Beleg zur besseren Übersicht kurz aus Anwendungssicht erklärt, und wei-tere Abschnitte, die jeweils eine Erweiterung behandeln. Dazu wird zunächst der Bedarf spezifiziert, um den Zusammenhang und die Zielset-zung der Erweiterung zu erläutern. Anschließend wird die jeweilige Erweiterung technisch betrachtet, es werden verfügbare Tabellen gezeigt und Vorbereitungsmaßnahmen beschrieben. Schließlich wird der Source-code Schritt für Schritt erklärt.
� Natürlich konnten wir unmöglich alle Erweiterungsmöglichkeiten der SAP-Vertriebskomponente beschreiben. In Anhang A finden Sie stattdes-sen eine vollständige Liste mit je einer Kurzbeschreibung pro Erweite-rung, die Sie zum schnellen Nachschlagen verwenden können.
Einleitung
14
Beispiele zu diesem Buch
Alle Beispiele zu diesem Buch sind nicht nur in Anhang B zu finden, son-dern auch als Download in Form von Textdateien auf der Bonus-Seite zu die-sem Buch. Den Link zur Bonus-Seite finden Sie unter http://www.sap-press.de/2550. Alternativ können Sie auch unter http://www.sap-press.de/bonus-seite den vorne im Buch abgedruckten Zugangscode eingeben.
Systemvoraussetzungen
Die meisten gezeigten Exits sind seit Langem verfügbar, meist ab Release 3.0. Sie erkennen dies nicht zuletzt an den Screenshots in diesem Buch, die wir in den unterschiedlichsten Systemen erstellt haben. Sie benötigen daher nicht unbedingt ein ERP-System in Release 6.0 oder höher, um die in diesem Buch vorgestellten Beispiele anwenden zu können. BAdIs beruhen auf einer neue-ren Technologie. Hier sollten Sie einfach in Ihrem Release gemäß der in Kapi-tel 1 dargestellten Weise nachschauen, ob das BAdI verfügbar ist.
Rückmeldungen
Es ist uns ein Anliegen, Ihre Rückmeldungen zu den Beispielen in diesem Buch zu erhalten – oder sogar Ihre eigenen Erweiterungsprogrammierungen für den Vertrieb mit SAP anderen Lesern zur Verfügung zu stellen. Schicken Sie sie einfach an unseren Lektor ([email protected]), er wird sie uns dann zur Qualitätsprüfung weiterleiten. Wenn Sie es wünschen, werden wir Ihre Beispiele dann ebenfalls auf der Bonus-Seite zu diesem Buch veröf-fentlichen und unter Umständen sogar in mögliche Folgeauflagen dieses Buches aufnehmen. Machen Sie mit: Wir freuen uns auf Ihre Rückmeldung!
Zusatzinformationen
Wichtige Hinweise und Zusatzinformationen werden in diesem Buch in Form von grau hinterlegten Kästen gesondert hervorgehoben. Diese Kästen haben unterschiedliche Schwerpunkte und sind mit verschiedenen Symbo-len markiert:
Achtung: Seien Sie bei der Durchführung der Aufgabe oder des Schrittes besonders vorsichtig, der mit einem Ausrufezeichen markiert ist. Eine Erklä-rung, warum hier Vorsicht geboten ist, ist beigefügt.
Hinweis: Wird das besprochene Thema erläutert und vertieft, macht ein Doppelpfeil Sie darauf aufmerksam.
Einleitung
15
Schritt für Schritt: Einige Arbeitsabläufe im System wiederholen sich. Diese haben wir für Sie in Schritt-für-Schritt-Anleitungen zum schnellen Überblick zusammengefasst, die mit dem Kästchen-Icon gekennzeichnet sind.
Tipp: Nützliche Tipps und Shortcuts, die Ihnen die Arbeit erleichtern, sind an einem Pluszeichen zu erkennen. Hierunter fallen auch Erfahrungswerte, die wir in verschiedenen Projekten gesammelt haben.
Danksagung
Für die Programmierung der Anwendungsbeispiele haben wir mit mehreren Entwicklern zusammengearbeitet, damit jeder seine langjährige Erfahrung einbringen konnte.
Die Hauptarbeit in diesem Bereich haben neben uns Fares Charrabé und Martin Traube geschultert. Fares Charrabé von der alogis DEVELOPMENT GmbH hat uns einige Freitagnachmittage gewidmet, viele Programmiertricks in das Buch eingebracht und geduldig die Beispiele am System getestet. Es war beeindruckend zu sehen, wie schnell er die Programme geschrieben hat und wie wenig wir nach dem Testen verändern mussten. Seine Beispiele konnten wir für die Kapitel Versand, Fakturierung und Transportwesen nut-zen. Für den Bereich Frachtkosten konnten wir Martin Traube gewinnen, ebenfalls ein Experte mit beeindruckender SAP-Erfahrung, der sich die Mühe gemacht hat, zwei Beispiele beizusteuern und entsprechende Erklä-rungen dazu zu schreiben. Ohne diese Zusammenarbeit wäre das Buch nicht möglich gewesen, und dafür möchten wir uns bei den beiden herzlich bedanken.
Eine große Hilfe war auch Stefan Kuisle, der uns viele Recherchearbeiten im SAP-System abgenommen und damit wesentlich zur pünktlichen Abgabe des Buches beigetragen hat.
Zusätzlich möchten wir uns bei den Entwicklern/Beratern Andreas Tillmann, Sandor Bingyu, Ramesh Mavilla, Franz Förster, Ingo Twardowski und Ionel Burlacu bedanken, die alle punktuell Anwendungsbeispiele oder ihr Exper-tenwissen beigesteuert haben.
Ein weiterer Dank gilt unserem Lektor, Stefan Proksch von Galileo Press, der Vertrauen in unsere Arbeit hatte und uns durch alle Höhen und Tiefen unse-res ersten Buchprojektes begleitet hat.
Petra Just dankt zusätzlich der Firma alogis DEVELOPMENT GmbH in Ber-lin, die das Projekt mit Anwendungsbeispielen unterstützt hat: Ich durfte
Einleitung
16
jederzeit mit einem Entwicklungsbenutzer am SAP-Testsystem von alogis in Berlin arbeiten. Daher möchte ich mich bei einem der zwei Vorstände, Jörn Samuelson, dafür bedanken, dass er von Anfang an aufgeschlossen war, das Projekt zu fördern. Ein herzlicher Dank geht an meinen Koautor Thomas Klein sowie an Frau Bartenschlager und Herrn Savoia von meiner Lieblings-agentur K2 Partnering Solutions, die mich von Anfang an bei der Idee zu diesem Buch unterstützt und auch den Kontakt zu Thomas Klein hergestellt haben. Ohne ihn wäre das Buch nicht möglich gewesen. Er hat über Wochen alle Beispiele im System getestet und die Screenshots zur Verfügung gestellt sowie unzählige Fragen beantwortet. Dabei war er immer freundlich, hilfs-bereit und geduldig, gleichgültig, wie sehr ich ihn mit Fragen gelöchert habe. Ein besonderer Dank gilt schließlich meinem Freund Erich Hunger, der mir an den knappen Wochenenden die nötige Zeit gegeben hat, dieses Buch zu schreiben.
Der größte Dank von Thomas Klein gilt der Hauptautorin dieses Buches, Petra Just. Ohne ihre Mühe und ihre intensive Arbeit wäre dieses Ergebnis nicht zustande gekommen. Bei Frau Bartenschlager von der Agentur K2 Part-nering Solutions möchte ich mich nochmals für die Kontaktherstellung zu Petra Just bedanken. Ein großes Dankeschön geht an alle Entwickler und Berater, die uns für dieses Buch ihr Wissen zur Verfügung gestellt haben. Nicht zuletzt bedanke ich mich bei meinen drei Töchtern und meiner Ehe-frau, die mich in der Entstehungsphase des Buches mental immer unterstützt haben und oft auf mich verzichten mussten.
Petra JustSAP-Beraterin SD/IS-Oil
Thomas KleinSAP-Entwickler und Migrationsberater
147
4 Erweiterungsmöglichkeiten in der Fakturierung
In diesem Kapitel werden Erweiterungen im Rechnungsbeleg beschrieben. Sie erfahren, wie Sie eigene Felder in der Rechnung füllen, wie Sie eigene Nummernkreise vergeben und wie Sie die Preisfindung und die Kontenfin-dung beeinflussen.
Anders als in den bisherigen Kapiteln zeigen wir Ihnen diesmal verschiedene Beispiele, die nicht miteinander zusammenhängen. Natürlich hätten wir Ihnen auch wieder erklären können, wie Sie das neu eingeführte Feld ZZAUSin die Rechnung einfügen. Aus unserer Sicht ist es aber interessanter, den Exit zum Füllen eigener Daten in der Rechnung anhand eines ganz anderen Beispiels aus der Praxis angewendet zu sehen – und alle Beispiele, die Sie in diesem Kapitel finden, sind in der Praxis so oder ähnlich vorgekommen.
Zunächst füllen wir die Kontierungsgruppe anhand einer Selektion. Neben der erwähnten Erweiterung zu den Rechnungsfeldern stellen wir zwei Erweiterungen vor, die es Ihnen ermöglichen, die Rechnungsnummer der Faktura nach ganz eigenen Regeln zu ermitteln. Des Weiteren beschreiben wir je einen Exit zur Beeinflussung der Preisfindung und einen Exit zur Erlöskontenfindung in der Faktura. In den meisten Projekten sind beide Bereiche sehr wichtig. Auch wenn der Standard hier eine hohe Flexibilität ermöglicht, sind Exits ergänzend sinnvoll. Dabei setzen wir voraus, dass immer alle Möglichkeiten im Standard geprüft wurden, bevor eine Eigenent-wicklung unternommen wird.
4.1 Übersicht über den Rechnungsbeleg
Bevor wir wieder mit der Programmierung beginnen, geben wir Ihnen einen kurzen Überblick über den Rechnungsbeleg. Wir möchten Ihre Aufmerk-samkeit dabei besonders auf die wesentlichen Felder lenken, die auf jeder Rechnung enthalten sein müssen. Wie Sie in Abbildung 4.1 sehen, enthält der Rechnungsbeleg den Regulierer 1, den Artikel 2, die Menge 3 und die Preisfindung 4. Die Kopfdaten werden in der Tabelle VBRK (Vertriebsbeleg –
Erweiterungsmöglichkeiten in der Fakturierung4
148
Rechnungskopf) und die Positionsdaten in der Tabelle VBRP (Vertriebsbeleg – Positionsdaten) abgelegt.
Abbildung 4.1 Überblick über Rechnungsbeleg
Im Wesentlichen muss der Rechnungsbeleg mit Bezug zur Auslieferung angelegt werden, wenn für diese ein Warenausgang gebucht wurde. Dann werden anhand der Preisfindung ein Verkaufspreis sowie die Mehrwert-steuer ermittelt. In Abbildung 4.1 sehen Sie das Ergebnis als Gesamtnetto-wert in Punkt 4. Mit diesem Wert wird dann auch der Umsatz gebucht.
Bei der Weiterleitung der Rechnung an die Buchhaltung werden automatisch die Erlöskonten gefunden, der Umsatz wird erhöht, und es entsteht eine For-derung im Finanzwesen. Das heißt, dass eine Bezahlung vom Regulierer erwartet wird. Beim Speichern wird wie bei den anderen Belegen eine Num-mer vergeben. Diese ist über den Belegfluss mit den Vorgängerbelegen ver-bunden. Anhand des Warenausgangs und der Erlöskontenbuchung sehen Sie, wie integriert das SAP-System ist und wie ehemals manuelle Buchungen in das Finanzwesen automatisiert werden.
Die Programmierbeispiele in diesem Kapitel drehen sich um die beschriebe-nen Schritte. Sie haben folgende Funktionen:
� Versorgung der Faktura mit eigenen Daten
� eigene Rechnungsnummernvergabe
� Beeinflussung der Preisfindung
� Ermittlung der Erlöskonten mit eigener Logik
4.2 Faktura mit eigenen Daten versorgen
Als Basis für alle anderen Aktionen benötigt die Rechnung zunächst einmal Daten. Wie erwähnt, wird ein Großteil der Daten aus den Vorgängerbelegen
Faktura mit eigenen Daten versorgen 4.2
149
kopiert. Der Kunde, der Artikel und der Preis sind zum Beispiel aus der Aus-lieferung bekannt. Darüber hinaus werden bestimmte Zusatzdaten wie die Zahlungsbedingungen oder die Kontierungsgruppe aus den Stammdaten ermittelt. Im Standard wird eine hohe Anzahl von Feldern gefüllt.
Wenn Sie eigene Daten füllen oder eine eigene Logik zum Füllen der vorhan-denen Daten einbringen möchten, können Sie den in diesem Abschnitt beschriebenen Exit verwenden.
4.2.1 Bedarf spezifizieren
Den Exit für die Versorgung der Faktura mit eigenen Daten werden wir dazu nutzen, ein Feld aufgrund von bestimmten Zusammenhängen zu füllen. In unserem Beispiel soll die Kontierungsgruppe beeinflusst werden. Normaler-weise wird die Kontierungsgruppe im Kundenstamm gefüllt und von da aus in den Rechnungskopf (VBRK) kopiert. Wenn Sie die Faktura dann an das Rechnungswesen weiterleiten, wird die Kontierungsgruppe des Kunden zusammen mit anderen Kriterien verwendet, um das Erlöskonto zu finden, das bebucht werden soll. Es kann von Interesse sein, die Erlöse genau zu unterteilen, sodass Sie exakt wissen, wo der Erlös zuzuordnen ist.
Nehmen wir ein Beispiel, in dem bestimmte Werke eine bestimmte Gruppe von Kunden als privilegierte Kunden unterscheiden möchten, andere Werke aber nicht. Diese würden dann die Kontierungsgruppen »Standardkunden« und »Privilegierte Kunden« anlegen, die zweite aber nicht im Kundenstamm zuordnen, sondern im Rechnungsbeleg anhand des Werkes (besser einer Tabelle »Werkkontierungsgruppe«) festlegen. So können bestimmte Werke für bestimmte Kunden eigene Erlöskonten definieren. Später können dann in der Auswertung die Umsätze separat ausgegeben werden.
4.2.2 Erweiterung analysieren
Um zusätzliche Felder zu füllen, müssen wir den in Abbildung 4.2 gezeigten USEREXIT_FILL_VBRK_VBRP in Programm RV60AFZC im Modulpool SAPLV60Aeinsetzen. Dieser User-Exit wird nur beim Anlegen der Faktura aufgerufen. Er wird verwendet, um den Kopf und die Position der zu erstellenden Fak-tura mit abweichenden oder zusätzlichen Daten zu versorgen. Tabelle 4.1zeigt die in diesem Exit verfügbaren Tabellen.
Erweiterungsmöglichkeiten in der Fakturierung4
150
Abbildung 4.2 USEREXIT_FILL_VBRK_VBRP
4.2.3 Kundeneigene Tabelle anlegen
Um keine Hartcodierung vornehmen zu müssen, werden wir eine kunden-eigene Tabelle anlegen. Die entsprechenden Daten und Felder finden Sie in Tabelle 4.2 dargestellt. Die Datenelemente, die Sie für die vier Felder ver-wenden, sind in Abbildung 4.3 dargestellt.
Abbildung 4.3 Tabelle ZSD_SPEZIAL
Verfügbare Tabelle Name im Exit Bedeutung
VBRK XVBRK Rechnungskopf
VBRP XVBRP Rechnungsposition
Tabelle 4.1 Verfügbare Tabellen in RV60AFZC
Faktura mit eigenen Daten versorgen 4.2
151
4.2.4 Programmierung einbinden
Nach dieser Vorbereitung können wir die Kontierungsgruppe für die gepflegten Kombinationen aus Verkaufsorganisation und Werk aus unserer Tabelle herausselektieren. Sollte die Kombination nicht gepflegt sein, greift der Standard. Problematisch wird es hier, weil wir Kriterien auf Kopf- und Positionsebene haben. Der Exit funktioniert nur, wenn es keine unterschied-lichen Werke in den unterschiedlichen Rechnungspositionen gibt. Dies könnte wiederum über einen Exit geprüft werden.
Im Folgenden schauen wir uns wieder die wichtigsten Coding-Abschnitte der Exit-Programmierung an. Die vollständige Programmierung finden Sie als Listing B.20 in Anhang B. Zunächst ist wichtig, dass Sie direkt die Tabelle VBRK/VBRP verwenden und nicht XLIKP. Dann wird die Kontierungsgruppe ermittelt, die für die im Lieferkopf angegebenen Organisationsdaten (Ver-kaufsorganisation, Vertriebsweg und Werk) in der kundeneigenen Tabelle gepflegt ist:
SELECT SINGLE ktgrd FROM zsd_spezial INTO vbrk-ktgrd WHERE vkorg = xvbrk-vkorg AND vtweg = xvbrk-vtweg AND werks = xvbrp-werks.
War die Selektion erfolgreich, wird die gefundene Kontierungsgruppe in den Lieferkopf geschrieben. Sie überschreibt dann die Standardkontierungs-gruppe, die aus dem Kundenstamm vorgeschlagen wurde. Das Beispiel zeigt, dass ein Element der Konditionstechnik zur Erlöskontenfindung umgeändert und mit dem geänderten Wert die Ermittlung weiterhin über den Standard laufen gelassen werden kann.
Problematisch ist dabei aber, dass Sie, wenn Sie nun im Customizing nach-schauen, eine ganz andere Ermittlung sehen als die, die tatsächlich im Beleg
Verkaufsorganisation (VKORG)
Vertriebsweg (VTWEG)
Werk (WERKS)
Kontierungsgruppe/Debitor (KTGRD)
DE Einzelhandel WIES 11 AL
DE Einzelhandel KÖLN 12 NM
DE Einzelhandel BERL 11 AL
DE Einzelhandel MÜNC 1 AL
Tabelle 4.2 Tabelle ZSD_SPEZIAL zur Ermittlung der Kontierungsgruppe
Erweiterungsmöglichkeiten in der Fakturierung4
152
durchgeführt wird. Zum Beispiel möchten Sie im Allgemeinen für alle Nah-rungsmittelketten die Kontierungsgruppe »Nahrungsmittelketten« einführen. Dann geben Sie im Kundenstamm eines Kunden XY die Kontierungsgruppe NM(Nahrungsmittel) an. Im Customizing verweist diese Kontierungsgruppe auf das Erlöskonto »Nahrungsmittel«. Später soll aber der Kunde, wenn er beispiels-weise aus Wiesbaden beliefert wird, ein besonderes Erlöskonto »Nahrungsmit-tel – Kunde XY« erhalten, weil er für dieses Auslieferungswerk eine besondere Rolle spielt. Sie erstellen daher einen Eintrag in Tabelle ZSD_SPEZIAL:
� Verkaufsorganisation: DE
� Vertriebsweg: EH (Einzelhandel)
� Werk: WIES (Wiesbaden)
� Kontierungsgruppe: XY (Kunde XY)
Im Customizing sehen Sie nun, dass für die Kontierungsgruppe XY ein beson-deres Erlöskonto zu finden ist, Sie sehen aber nicht, dass die Kontierungs-gruppe nicht aus dem Kundenstamm kommt, sondern in der Rechnung über eine Erweiterung ermittelt wird. Wenn ein Experte von diesem Exit nichts weiß, wird er sich wundern, warum der Kunde NM im Kundenstamm hat, aber XY im Rechnungsbeleg.
4.2.5 Zusatzbeispiel
Als zweites Beispiel zur Beeinflussung der Daten in der Faktura könnte es den Bedarf geben, das Fakturadatum auf das Tagesdatum der Faktura zu set-zen. Hier könnten Sie den gleichen Exit (siehe auch Listing B.21 in Anhang B) mit folgender Anweisung nehmen:
vbrk-fkdat = vbrk-erdat.
Achtung: Hier sollten Sie wieder darüber nachdenken, was bei einer Ände-rung geschieht! In diesem Fall wird bei jeder Änderung wieder das Faktura-
Hinweis
Daran wird auch deutlich, wie wichtig eine gute Dokumentation der Exits ist. Solange im Unternehmen immer dieselben SAP-Experten das System betreuen, wis-sen diese Bescheid, dass und wie die Funktionalität verändert wurde. Wird der Experte aber krank oder wechselt in ein anderes Unternehmen, muss ein anderer sich in die Logik hineinfinden. Natürlich kann er debuggen und so im Coding sehen, was gemacht wurde, aber das kann aufwendig sein. Eine gute Dokumentation sichert Unternehmen auch langfristig die Stabilität der Systeme und sollte möglichst im SAP-System erstellt werden. Für jedes Programm können Sie in Transaktion SE38 im Menüpunkt Dokumentation eine genaue Beschreibung einfügen.
Nummernvergabe in der Faktura erweitern 4.3
153
datum aktualisiert. Jedes Mal wenn der Endanwender sich die Rechnung anschaut, würde das Fakturadatum auf diesen Tag gesetzt. Das kann eigent-lich nicht gewollt sein, denn das Fakturadatum beeinflusst, wann der Kunde die Ware zu bezahlen hat. So kann er sich Zeit lassen, wenn der Sachbearbei-ter nur häufig genug seine Rechnung aufruft. Wenn Sie das nicht möchten, sollten Sie statt des Tagesdatums (SY-DATUM) das Erstellungsdatum (VBRK-ERDAT) verwenden – oder noch besser, Sie nehmen das Warenausgangs-datum der Lieferung. Das bedeutet, dass die Rechnung an dem Tag gestellt wird, an dem der Warenausgang stattgefunden hat (siehe Abschnitt 3.4, »Fakturadatum nach eigenen Kriterien bestimmen«).
4.3 Nummernvergabe in der Faktura erweitern
Wir werden nun einen Exit verwenden, um die Nummernvergabe in der Rechnung zu steuern. Normalerweise können Sie den Nummernkreis in der Rechnung über die Fakturaart wie folgt konfigurieren (siehe Abbildung 4.4): In Schritt 1 rufen Sie den Customizing-Pfad Vertrieb � Fakturierung � Fak-
turen � Fakturaarten definieren auf und wählen in Schritt 2 den Eintrag Fakturaarten definieren aus. In Schritt 3 können Sie nun bei einer Stan-dardfakturaart nachschauen (zum Beispiel F1). Schließlich sehen Sie in Abbil-dung 4.5, dass der Nummernkreis eine der ersten Einstellungen ist, die Sie in der Fakturaart vornehmen können.
Abbildung 4.4 Nummernkreis in der Fakturaart konfigurieren
Erweiterungsmöglichkeiten in der Fakturierung4
154
Abbildung 4.5 Zuordnung des Nummernkreises
4.3.1 Bedarf spezifizieren
Da wir eine davon abweichende Logik umsetzen werden, wählen wir folgen-des fiktives Beispiel: In einer großen Firma soll es unterschiedliche Nummern für die Rechnungen in unterschiedlichen Ländern geben. Das ermöglicht, dass anhand der Rechnungsnummer sofort zu erkennen ist, um welches Land es sich handelt. Dies kann die Arbeit in Sammellisten erleichtern. Zusätzlich soll aber auch nach folgenden Kriterien unterschieden werden:
� Land (VBRK-LANDTX)
� Buchungskreis (VBRK-BUKRS)
� Verkaufsorganisation (VBRK-VKORG)
� Werk (VBRP-WERKS)
4.3.2 Kundeneigene Tabelle anlegen
Daraus folgt, dass eine kundeneigene Tabelle mit den Werten aus Tabelle 4.3angelegt werden muss.
Land (LAND)
Buchungskreis (BUKRS)
Verkaufsorgani-sation (VKORG)
Werk (WERKS)
Nummernkreis (ZNR_RANGE)
DE Holding Süd Altmanns-hofen
01
DE XX Deutschland AG Nord Harburg 02
FR XX France SRL Province Gravenchon 03
FR Joint-Venture Region Parisienne
Rueil Malmaison
04
Tabelle 4.3 Kundeneigene Tabelle zur Nummernkreisvergabe
Nummernvergabe in der Faktura erweitern 4.3
155
Da sich das Werk auf Positionsebene befindet, soll jeweils das Werk auf der ersten Position ausschlaggebend für die Vergabe der Nummer sein.
4.3.3 Erweiterung analysieren
Für diesen Bedarf nehmen Sie den Exit USEREXIT_NUMBER_RANGE (Modulpool SAPLV60A, Programm RV60AFZZ, siehe Abbildung 4.6). Der im Standard ver-wendete interne Nummernkreis wird in der Tabelle der Fakturaarten vorge-geben und kann in diesem User-Exit verändert werden. Der User-Exit wird nur beim Anlegen der Faktura aufgerufen. Wird die Faktura gespeichert, ver-gibt das System eine Nummer, die mit dem Exit beeinflusst werden kann.
Abbildung 4.6 Exit zur kundeneigenen Nummernvergabe in der Faktura
4.3.4 Sourcecode des User-Exits
Wir gehen nun auf die wichtigsten Bestandteile des Codes ein, den Sie als Listing B.22 in Anhang B finden können. Alle Felder, die nicht im Exit als Parameter vorhanden sind, müssen wir deklarieren. Die Anweisung DATAbewirkt, dass Datenobjekte zu Beginn der Laufzeit des Kontextes von der
Erweiterungsmöglichkeiten in der Fakturierung4
156
ABAP-Laufzeitumgebung erzeugt werden, hier der Nummernkreis und das Länderkennzeichen. Sie leben dann so lange wie der Kontext.
DATA: l_num_range TYPE numki, l_land1 TYPE land1.
Das Hilfsfeld, in das der Nummernkreis hineinselektiert wird, muss den glei-chen Typ haben wie der Nummernkreis selbst (NUMKI). Das Hilfsfeld, in das das Länderkennzeichen hineinselektiert werden soll, muss den gleichen Typ haben wie das dazugehörige Datenbankfeld KNA1-LAND1.
Anschließend wird häufig die eigene Tabelle deklariert:
TABLES: zsd_nr_faktura.
Das ist hier jedoch nicht notwendig: Folgender Kasten erklärt, warum und wann Sie das Statement auch weglassen können.
Da wir später das Werk aus dem Auftrag benötigen, müssen wir vorher ein Hilfswerk vom gleichen Typ wie das Feld VBAP-WERKS deklarieren.
l_werks TYPE werks_d.
Mit den folgenden Zeilen ermitteln Sie das Land des steuerlichen Senders oder des Buchungskreises, falls dieses im Rechnungskopf leer sein sollte.
IF xvbrk-landtx IS INITIAL. SELECT SINGLE land1 FROM t001 INTO l_land1 WHERE bukrs = xvbrk-bukrs. ELSE. l_land1 = xvbrk-landtx. ENDIF.
Das Werk ist zwar auch im Rechnungsbeleg vorhanden, aber auf Positions-ebene. Das heißt, dass wir auf die Position anhand der Rechnungsnummer selektieren müssten. Das ist in diesem Exit nicht möglich, da die Rechnungs-nummer noch nicht vergeben ist. Wir befinden uns im Anlegemodus, bevor
Tipp
Dieses TABLES-Statement kann und sollte weggelassen werden. Es legt einen über-flüssigen Arbeitsbereich für die Tabelle an. Beim späteren SELECT INTO wird nur ein Feld benötigt, daher muss nicht die ganze Tabelle deklariert werden. Ein weit-verbreiteter Irrtum ist, dass alle im Programm genutzten Tabellen deklariert wer-den müssen. Das ist aber nicht der Fall, wenn beim SELECT der INTO-Zusatz ver-wendet wird.
Nummernvergabe in der Faktura erweitern 4.3
157
die Nummer vergeben wird. Der Vorgängerbeleg ist aber schon in der Rech-nungsposition vorhanden (XVBRP-VBELV). Wir müssen daher das Werk des Auftrages anhand des Vorgängerbeleges herausfinden. Daraus ergibt sich fol-gende SELECT-Anweisung:
SELECT SINGLE werks FROM vbap INTO l_werks WHERE vbeln = xvbrp-vbelv.
Im nächsten Schritt ermitteln Sie den Nummernkreis anhand einer kunden-eigenen Tabelle:
SELECT SINGLE znr_range FROM zsd_nr_faktura INTO l_num_range WHERE vkorg = xvbrk-vkorg AND bukrs = xvbrk-bukrs AND land1 = l_land1 AND ( werks = l_werks OR werks = space ).
In der nächsten Zeile fragen wir den Returncode (SY-SUBRC) ab, weil es nur dann sinnvoll ist, den Nummernkreis zu übergeben, wenn er auch in der Datenbank gefunden wird. Wird er nicht gefunden, sollte es auch eine Kon-sequenz geben. Zum Beispiel könnten Sie eine Nachricht ausgeben und das Speichern der Rechnung verhindern. Ist alles in Ordnung, können Sie das Ergebnis der Selektion an das vorgegebene Zielfeld US_RANGE_INTERN überge-ben:
IF sy-subrc = 0. us_range_intern = l_num_range. ELSE. MESSAGE a002(zalo) WITH xvbrp-posnv. ENDIF.
Die Nachricht, die Sie ausgeben, wenn die Suche des Nummernkreises nicht erfolgreich war, könnte zum Beispiel so lauten:
Ein Anlegen der Rechnung ist für den Auftrag Nr. &1 nicht möglich, weil kein Nummernkreis ermittelt werden konnte.
In den Langtext könnten Sie Folgendes schreiben
»Prüfen Sie das Customizing der Fakturaart (Tabelle TVFK) und die kunden-eigene Tabelle ZSD_NR_FAKTURA.«
Erweiterungsmöglichkeiten in der Fakturierung4
158
Ein solcher Langtext vermeidet Debugging für den Support und damit häufig die Weitergabe des Problems, weil sofort klar ist, in welcher Tabelle der Nummernkreis gepflegt werden muss.
4.3.5 Zweites Beispiel zur Nummernvergabe in der Rechnung
Für diesen Exit in der Faktura stellen wir noch ein zweites Beispiel vor (siehe auch Listing B.23 in Anhang B). Diesmal sollen der ursprüngliche Nummern-kreis, die Verkaufsorganisation und der Vertriebsweg als Kriterien zur Ermitt-lung des Nummernkreises dienen. Tabelle 4.4, die wir als ZNR_ERMITT bezeich-net haben, enthält Beispieleinträge, die die Logik verständlich machen.
Der Nummernkreis, der im Customizing der Fakturaart festgelegt ist, steht in Tabelle TVFK im Feld NUMKI. Die Tabelle TVFK ist direkt im Exit verfügbar. Sie können daher direkt abfragen, ob die Fakturaart im Customizing (TVFK) nicht die gleiche ist wie die Fakturaart im Rechnungskopf (VBRK). Nur dann ergibt ein Selektieren auf die Datenbank Sinn, um den Nummernkreis für die Fak-turaart in diesem Rechnungsbeleg zu ermitteln:
IF tvfk-fkart <> vbrk-fkart. SELECT SINGLE * FROM tvfk WHERE fkart = xvbrk-fkart.
Sollte die Selektion nicht erfolgreich sein, wird TVFK geleert, anderenfalls wären dort die Werte vom letzten Durchlauf des Exits enthalten und die Überprüfung, ob der Nummernkreis gefüllt ist, wäre erfolgreich. Die darauf-
Tipp
In der Praxis haben wir in diesem Beispielprogramm folgenden Aufruf gefunden:
REFRESH l_num_range.
Der Befehl REFRESH ist an dieser Stelle falsch. Er wird für interne Tabellen verwen-det und nicht für einzelne Felder. Hier wäre allenfalls der Befehl CLEAR richtig. Des Weiteren werden alle Felder, die mit DATA deklariert sind, am Ende der Form geleert, was die Anweisung überflüssig macht. Nur die Deklaration per STATIC(statt DATA) würde bewirken, dass der letzte Wert im Feld verbleibt.
Originalnummernkreis (ZNUMKI)
Verkaufsorganisa-tion (VKORG)
Vertriebsweg (VTWEG)
Nummernkreis (Z_NRKREIS)
01 Süd 01 03
02 Nord 01 04
Tabelle 4.4 Nummernkreisermittlung anhand des Originalnummernkreises
Preisfindung in der Faktura erweitern 4.4
159
folgende Selektion auf die kundeneigene Tabelle würde mit irgendeinem Wert erfolgen.
IF sy-subrc <> 0. CLEAR tvfk. ENDIF.
Dann wird geprüft, ob der Nummernkreis tatsächlich gefüllt ist:
CHECK NOT tvfk-numki IS INITIAL.
Anschließend wird der Nummernkreis aus einer kundeneigenen Tabelle selektiert:
SELECT SINGLE z_nrkreis FROM znr_ermitt INTO us_range_intern WHERE vkorg = xvbrk-vkorg AND vtweg = xvbrk-vtweg AND znumki = tvfk-numki.
Kann der Nummernkreis so nicht gefunden werden, werden wir das Spei-chern des Rechnungsbeleges abbrechen:
IF sy-subrc <> 0. MESSAGE a002(zalo) WITH xvbrp-posnv. ENDIF.
Die Nachricht könnte lauten:
Das Anlegen der Rechnung ist für die Lieferung XYZ nicht möglich, da kein Nummernkreis gefunden wurde.
4.4 Preisfindung in der Faktura erweitern
Nach diesen Beispielen von klassischen Exits im Rechnungsbeleg werden wir nun noch einen Exit vorstellen, der Kommunikationsstrukturen für die Preis-findung füllt. Diesmal soll es sich um die Preisfindung in der Rechnung handeln.
4.4.1 Bedarf spezifizieren
In folgendem Beispiel spielt das Wunschlieferdatum eine Rolle bei der Preis-findung. Deshalb selektiert das Programm dieses Datum (VDATU) in der
Erweiterungsmöglichkeiten in der Fakturierung4
160
Faktura aus dem vorhergehenden Auftragsbeleg und stellt es der Preisfin-dung zur Verfügung.
4.4.2 Erweiterung analysieren
Wie in Abschnitt 2.5.2, »Füllen der Werte über den Exit«, für den Auftrag erklärt, können Sie auch neue Felder in die Preisfindung für die Rechnung einfügen. Dazu nutzen Sie den Funktionsbaustein USEREXIT_PRICING_
PREPARE_TKOMK im Programm RVCOMFZZ.
4.4.3 Programmierung einbinden
Wir sprechen nun wieder Schritt für Schritt die eigentliche Programmierung durch, die Sie in Listing B.24 in Anhang B vollständig dargestellt finden. Zuerst wird der Returncode geleert, damit sicher ist, dass er nicht 4 ist.
CLEAR sy-subrc.
Dann weisen Sie einfach dem gleichnamigen Feld ZZVTWEG in der Struktur TKOMK den Vertriebsweg aus dem Rechnungskopf zu. Nun können Sie den Vertriebsweg in der Preisfindung der Rechnung nutzen.
tkomk-zzvtweg = xvbrk-vtweg.
Das war einfach, weil das Feld VTWEG in einer Struktur des Exits vorhanden war. Beim Wunschlieferdatum ist es nicht ganz so einfach, weil das Datum nicht in der Rechnung enthalten ist. Es wird im Auftrag durch den Vertrieb gepflegt und nicht in den Rechnungsbeleg kopiert. Wir müssen es folglich aus dem Auftrag herausselektieren. Dazu benötigen wir die Auftragsnum-mer. Diese befindet sich in der Rechnungsposition (VBAP-AUBEL). Wir selek-tieren daher wie für die entsprechende Auftragsnummer aus dem Auftrags-kopf (VBAK) das Wunschlieferdatum heraus.
IF NOT xvbrp-aubel IS INITIAL. SELECT SINGLE vdatu FROM vbak INTO tkomk-zzvdatu WHERE vbeln = xvbrp-aubel. ENDIF.
Als Zielfeld können Sie direkt das Feld TKOMK-ZZVDATU wählen. Das setzt vor-aus, dass Sie die zwei neuen Felder der Struktur TKOMK hinzugefügt haben. Wir haben beim Thema Preisfindung im Auftrag in Abschnitt 2.5.1, »Kom-munikationsstruktur erweitern«, beschrieben, wie Sie die Struktur erwei-
Kontenfindung in der Faktura erweitern 4.5
161
tern. Daran können Sie sich orientieren, um das Gleiche für die Preisfindung zu erreichen.
4.5 Kontenfindung in der Faktura erweitern
In der Rechnung werden Erlöskonten über die Kontenfindung ermittelt. Die Kontenfindung funktioniert auch mit der Konditionstechnik. Sie können daher anhand verschiedener Kriterien das Sachkonto ermitteln. In Abbil-dung 4.7 sehen Sie den Menüpfad zum Customizing der Erlöskontenfindung (Vertrieb � Grundfunktionen � Kontierung/Kalkulation � Erlöskonten-
findung). Sie können darin selbst entscheiden, welche Kombination von Kriterien Sie dafür wählen möchten. Wir haben ein Beispiel gewählt, in dem die Findung des Erlöskontos mithilfe folgener Felder funktioniert:
� Applikation: V (für Vertrieb)
� Kontenfindungsart: zum Beispiel KOFI
� Kontenplan
� Verkaufsorganisation (wird im Auftrag auf Kopfebene angegeben und in die Rechnung kopiert)
� Kontierungsgruppe Debitor (wird in den Vertriebsdaten des Kunden-stamms festgelegt)
� Kontierungsgruppe Material (wird im Materialstamm festgelegt)
� Erlöskontenschlüssel (ERL, der in der Preisfindung neben der Konditions-art angegeben wird)
Um Ihnen das Prinzip zu erklären, haben wir eine Tabelle angelegt, die zwei verschiedene Erlöskonten anhand verschiedener Debitorengruppen ermit-telt. Um alle Kriterien der Erlöskontenfindung inklusive Beschreibung zu zei-gen, haben wir die horizontale Customizing-Tabelle aus Abbildung 4.7 in eine vertikale Tabelle umgewandelt. Das Erlöskonto finden Sie folglich in der letzten Zeile (siehe Tabelle 4.5).
Tipp
Selbstverständlich gibt es noch weitere zahlreiche Möglichkeiten, um die Preisfin-dung zu beeinflussen. Wir verweisen in diesem Zusammenhang auf das Buch Preis-findung und Konditionstechnik in SAP ERP (SAP PRESS, 2010), in dem diese Funk-tionalität genau beschrieben wird.
Erweiterungsmöglichkeiten in der Fakturierung4
162
Abbildung 4.7 Erlöskontenfindung in der Faktura
4.5.1 Bedarf spezifizieren
Nehmen Sie nun einen anderen Bedarf an, bei dem die Erlöskonten nicht allein über die Kontierungsgruppe im Kundenstamm ermittelt werden kön-nen, sondern über den Warenempfänger aus der Lieferung. Stellen Sie sich einen Großkunden vor, der zahlreiche Filialen im Bundesgebiet hat und den verschiedene Verkaufsorganisationen beliefern. Da der Kunde aber sehr wichtig für die SAP-Anwender ist, soll es unterschiedliche Erlöskonten für verschiedene Filialen (Warenempfänger) und bestimmte Verkaufsorganisati-onen geben.
Anschaulich wird dies, wenn Sie sich eine Einzelhandelskette XY vor Augen führen. Diese hat zahlreiche Filialen in ganz Deutschland (XY Berlin-Prenz-
lauer Berg, XY Frankfurt-Höchst etc.). Diese werden im SAP-System als Warenempfänger abgebildet. Der Hauptsitz (XY Verwaltung) ist der Auftrag-geber. Über unterschiedliche Erlöskonten ist zu sehen, wie viel Umsatz in den jeweiligen Städten generiert wird. Da die Kontierungsgruppe sich aber nicht im Warenempfänger befindet, muss auf einen Exit zugegriffen werden. Tabelle 4.6 veranschaulicht, was abgebildet werden soll.
4.5.2 Kundeneigene Stammdatentabelle erstellen
Wir benötigen daher wieder eine kundeneigene Tabelle, die wir ZSD_WE_LISTE nennen (siehe Tabelle 4.7). Achtung: Diesmal darf es keine Customi-zing-Tabelle sein, denn die Kundennummern können in verschiedenen Sys-temen unterschiedlich sein! Die Tabelle muss als Stammdatentabelle ange-legt werden. Sie muss in jedem System wieder neu gefüllt und bei Neueinführungen in die To-do-Liste zur Datenübernahme übernommen werden.
4.5.3 Erweiterung analysieren
Um diesen Bedarf umzusetzen, können Sie den USEREXIT_ACCOUNT_PREP_KOMKCV (Modulpool SAPLV60A, Programm RV60AFZZ) nutzen. In diesem User-Exit werden zusätzliche Felder für die Kontenfindung in die Kommunikati-onsstruktur KOMKCV (Kopffelder) aufgenommen, die im Standard nicht vorge-sehen sind. Abbildung 4.8 zeigt, wie Sie den Exit in Transaktion CMOD auf-rufen.
Verkaufsorganisation (VKORG)
Warenempfänger (KUNNR, WE)
Kontierungsgruppe (KTGRD)
Deutschland 80000001 (XY Berlin-Prenzlauer Berg)
01 XY Berlin
Deutschland 80000002 (XY Frankfurt-Höchst) 02 XY Frankfurt
Tabelle 4.6 Beispieltabelle
Verkaufsorganisation (VKORG)
Warenempfänger (KUNNR, WE)
Kontierungsgruppe (KTGRD)
1000 80000001 01
2000 80000001 02
2000 80000003 02
Tabelle 4.7 Kundeneigene Tabelle ZSD_WE_LISTE
Erweiterungsmöglichkeiten in der Fakturierung4
164
Abbildung 4.8 Exit RV60AFZZ zur Kontenfindung in der Faktura
Den gleichen Exit gibt es auch auf Positionsebene: USEREXIT_ACCOUNT_PREP_KOMPCV.
4.5.4 Programmierung einbinden
Nachdem Sie die Vorbereitung abgeschlossen haben, beginnen Sie mit dem Coding (siehe auch Listing B.25 in Anhang B). Zuerst müssen Sie ein Hilfsfeld deklarieren, in das Sie hineinselektieren möchten:
DATA: l_kunwe TYPE kunnr.
Da der Bedarf von der Fakturaart abhängig sein soll, müssen Sie diese hart-codiert abfragen:
IF vbrk-fkart = 'ZFAK'.
Besser wäre es, die Fakturaart in die Tabelle einzufügen (aber das würde die Anzahl der Einträge erheblich erhöhen und unübersichtlich machen, wenn es viele Warenempfänger und/oder Fakturaarten gibt). Alternativ könnten Sie über eine weitere Tabelle mit einem Flag pro Fakturaart nachdenken. Wir belassen es hier der Einfachheit halber bei dem Hinweis, dass Sie die Hartcodierung nach Möglichkeit vermeiden sollten.
Wir werden nun den Warenempfänger des Auftrages ermitteln, der zu die-ser Rechnung gehört, und selektieren dazu auf die Tabelle VBPA (Partner-tabelle für verschiedene Vertriebsbelege) anhand des Vorgängerbeleges, der in der Rechnungsposition angegeben ist. Dabei akzeptieren wir, dass es für verschiedene Rechnungspositionen verschiedene Aufträge mit verschiede-nen Warenempfängern geben kann. Wir loopen aber nicht über alle Rech-nungspositionen. Das kann funktionieren, wenn Sie sicher sind, dass alle Rechnungen jeweils nur eine Position haben und nur einen vorausgehenden
Kontenfindung in der Faktura erweitern 4.5
165
Lieferbeleg – das ist aber nicht die Regel und muss in diesem Exit beachtet werden.
SELECT SINGLE kunnr FROM vbpa INTO l_kunwe WHERE vbeln = vbrp-aubel AND parvw = 'WE' AND posnr = '000000'.
Wenn wir dann einen Warenempfänger gefunden haben, können wir mit dieser Kundennummer auf unsere interne Tabelle selektieren. Zusätzlich benötigen wir die Verkaufsorganisation. Diese ist im Exit verfügbar (KOMKCV-VKORG), sodass wir die Kontierungsgruppe herausfinden können:
SELECT SINGLE ktgrd FROM zsd_we_liste INTO komkcv-ktgrd WHERE kunnr = l_kunwe AND vkorg = komkcv-vkorg.