Erstellen einer multiuser-fähigen Fallstudie zum Customizing des SAP ECC

Transkript

1 Hochschule-Aalen Studiengang Informatik Seminararbeit Erstellen einer multiuser-fähigen Fallstudie zum Customizing des SAP ECC Quelle: "Fallstudie Hochregellagermodell - Teil 1 - Lager anlegen", Mäule A.; Abbildung 1 Abbildung 1: Das Modell des Hochregellagers Betreuender Professor: Herr Prof. Dr. Rössle Angefertigt von: Frank Blaga Nicolas Macho Abgabedatum: 25. Juni 2014

2 Inhaltsverzeichnis Inhaltsverzeichnis 1 Einleitung Aufgabenstellung Was ist SAP ERP Central Component (ECC)? Prozesse und Organisationsstruktur der Lagerlogistik in SAP Das Hochregallager-Modell Die ursprüngliche Fallstudie im Überblick Der Inhalt der ursprünglichen Fallstudie Prozessübersicht Prozesse der einzelnen SAP Module Customizing des SAP ECC Die Arten des Customizing Customizing in der Fallstudie Die Kommunikation über die verschiedenen Schnittstellen Customizing zur weiteren Funktionalität der Fallstudie Die multi-user-fähige Fallstudie Teil 1 - Unternehmensorganisation und Lager Teil 2 - Material, Einkaufs- und Vertriebsbedingungen anlegen Teil 3 - Kopplung über ALE Teil 4 - Die Prozesse im Hochregallagermodell Literatur Abbildungsverzeichnis Eidesstattliche Erklärung II IV V I

3 1 EINLEITUNG 1 Einleitung Das Herzstück eines jeden großen, modernen Unternehmens ist seine Prozessund Informationsstruktur. Ohne die IT ist die Verwaltung von Unternehmensressourcen heutzutage nicht mehr möglich. Dieser Verwaltungsaufwand steigt mit der Größe des Unternehmens, da in einer globalisierten Welt verschiedene Standorte, Zulieferer, Kunden und Mitarbeiter unter einen Hut gebracht werden müssen. Die Kosten die für die Verwaltung anfallen steigen exponentiell und werden Agency-Kosten genannt. Die IT trägt maßgeblich zur Senkung dieser Kosten bei. Viele große Unternehmen haben deshalb SAP ECC im Einsatz. Doch was ist SAP ECC überhaupt? 1.1 Aufgabenstellung Das Thema unserer Seminararbeit beschäftigt sich mit der Frage welche Anpassungsmöglichkeiten SAP ECC bietet, welche Besonderheiten diese aufweisen und wie man sie praktisch anwenden kann um eine Fallstudie die sich mit einem Prozess für die Lagerhaltung in einem Hochregellager beschäftigt, multiuserfähig zu gestalten. Dabei wird dieser Prozess immer von SAP-Seite aus gestartet und kontrolliert. Die Befehle werden dabei mittels dem SAP-seitigen Datenaustauschformat IDoc an die Fremdsysteme übermittelt. (SA14d) Aus welchen Bestandteilen ein IDoc genauer besteht und wie die Kommunikation in der Fallstudie stattfindet wird später noch genauer erläutert. Unsere Aufgabe war es also zuerst die Theorie zu einigen relevanten Gebieten des Customizing und der Kommunikation mit Fremdsystemen genauer zu begutachten und daraus die vorhandene Fallstudie zu überarbeiten und sie multiuserfähig zu gestalten und neu zu dokumentieren, damit diese von Studenten bearbeitet werden kann. Über die Theorie zum Customizing und zur Kommunikation zwischen SAP und Fremdsystemen, die ursprüngliche Fallstudie und deren Logistikprozesse, das Vorgehen und die resultierende multiuserfähige Fallstudie wird im Folgenden berichtet. 1.2 Was ist SAP ERP Central Component (ECC)? SAP ECC ist ein ERP-System zur Unterstützung sämtlicher in einem Unternehmen ablaufenden Geschäftsprozesse und zur Verwaltung sämtlicher Unternehmensressourcen. Die SAP AG ist hierbei weltweiter Marktführer mit über Kunden in 180 Ländern und einem Gesamtumsatz von 16,90 Milliarden Euro im Geschäftsjahr Außerdem hat die SAP AG durch SAP HANA eine marktführende Technologie für Echtzeit-Computing auf den Markt gebracht. (SA14g) Es sind für nahezu jeden Einsatz Lösungen, teilweise durch externe Partner, erhältlich. 1

4 1 EINLEITUNG Außerdem kann ein SAP-System auf Rechner-Plattformen zahlreicher Hersteller installiert werden, ohne dabei Einschränkungen in der Funktionalität hinnehmen zu müssen. Die Endanwender greifen über Clients auf das SAP-System zu. Ebenso sind zahlreiche Datenbanksysteme für das SAP-System geeignet. (FGSK08, S.16-17) Ein SAP-System ist in Module unterteilt, welche jeweils einen betriebswirtschaftlichen Bereich abdecken: Quelle: Abbildung 2: SAP Module Des Weiteren sind alle Systemkomponenten konsequent mehrsprachig und erlauben somit einen internationalen Einsatz. Weiterhin ist ein SAP-System mandantenfähig und erlaubt es so mehrere wirtschaftlich und rechtlich selbstständige Unternehmen abzubilden. Die komplette Organisationsstruktur eines solchen Unternehmens lässt sich dabei in sogenannten Organisationselementen abbilden. (FGSK08, S.19) Das System ist in einer dreiteiligen Client-Server-Architektur aufgebaut. Diese besteht aus: 1. Datenbankserver 2. Applikationsserver 3. Präsentationsschicht auf der Client-Seite 2

5 1 EINLEITUNG Dabei werden die Daten über den Datenbankserver und die Anwendungen von den Applikationsservern bereitgestellt. Der Benutzerdialog findet hingegen auf einem Client statt welcher mittels TCP/IP-Protokoll über das Netzwerk kommuniziert. (FGSK08, S.19-20) 1.3 Prozesse und Organisationsstruktur der Lagerlogistik in SAP Für die Abbildung der allgemeinen Logistik werden verschiedene Organisationsstrukturen verwendet. Diese sind: 1. Werk 2. Lagerort 3. Einkaufsorganisation 4. Einkäufergruppe 5. Bewertungskreis In einem Werk findet für gewöhnlich die Produktion statt. Für die Buchführung wird ein Werk genau einem Buchungskreis zugeordnet, wobei ein Buchungskreis mehrere Werke haben kann. Ein Werk hingegen kann mehrere Lagerorte besitzen, in denen die Inventur und die Bestandsführung erfolgen. Der Lagerort kann nur einem Werk zugeordnet werden. Abbildung 3: SAP Zuordnung der Organisationseinheiten 3

6 1 EINLEITUNG Eine Einkaufsorganisation und eine Einkäufergruppe sind hingegen folgendermaßen gegliedert. Wenn es sich um eine werksbezogene Einkaufsorganisation handelt wird diese Einkaufsorganisation genau einem Werk zugeordnet, sodass nur für dieses Werk die erforderlichen Materialien über diese Einkauforganisation beschafft werden. Jedoch gibt es auch die Möglichkeit der werksübergreifenden Einkaufsorganisation die für alle Werke eines Buchungskreises verantwortlich ist. Weiterhin gibt es sogar buchungskreisübergreifende Einkaufsorganisationen. Eine Einkäufergruppe hingegen ist eine interne Person oder eine Gruppe von Personen die für den Einkauf verantwortlich ist. Wohingegen auf Basis des Bewertungskreises die Materialbewegung stattfindet. Beim Vertrieb kommen zu dieser Organisationsstruktur noch folgende Organisationseinheiten hinzu: 1. Verkaufsorganisation 2. Vertriebsweg 3. Sparte 4. Vertriebsbereich 5. Verkaufsbüro 6. Verkäufergruppe (BH11, S.49-51) Beim Customizing eines Lagers welches Einkaufs- und Vertriebsprozess abbilden kann müssen also diese aufgelisteten Organisationseinheiten dargestellt werden. Die Prozesse die die Lagerlogistik betreffen erstrecken sich nicht nur auf das Modul Logistik, sondern es sind in der Regel mehrere Module bei diesem Zusammenspiel beteiligt, wie zum Beispiel auch das Rechnungswesen. In diesen Modulen werden einige Komponenten häufiger für die Prozesse benötigt als andere. Besonders sind hier die folgenden Komponenten zu nennen: 1. Produktionsplanung und -steuerung (PP) 2. Materialwirtschaft (MM) 3. Vertrieb (SD) 4. Finanzwesen (FI) 5. Controlling (CO) (BH11, S ) 4

7 1 EINLEITUNG Es gibt zahlreiche Prozesse die in der Lagerlogistik mittels SAP abgebildet werden können. Hier sollen nur ein paar Grundlagen erläutert werden. Die für die Fallstudie relevanten Prozesse werden in den jeweiligen Kapitel genauer erläutert. Die Komponente "Produktionsplanung und -steuerung (PP)" beschäftigt sich mit den Planungs- und Durchführungsprozessen. Eine zentrale Stellung nimmt dabei der Fertigungsauftrag ein. In der Materialwirtschaft werden die Bestandsführung und die Einkaufsprozesse verwaltet. Außerdem findet hier die rechnerische und sachliche Rechnungsprüfung der Lieferantenrechnungen satt. Die Bestandsführung beinhaltet die Inventur, sowie die wert- und mengenmäßige Führung der Materialbestände und verbucht die Lagerbewegungen, inklusive Wareneingang und Warenausgang. Die Vertrieb-Komponente beschäftigt sich mit den Verkaufsaktivitäten wie dem Erfassen von Kundenaufträgen und die Versandabwicklung. Am Ende eines Vertriebsprozess steht die Fakturierung, welche im Finanzwesen ausgeziffert wird. Somit enden die Prozesse meist im Finanzwesen und Controlling, wo sie sich für die Erstellung der Bilanz und der Gewinn- und Verlustrechnung, im Hauptbuch niederschlagen. Für die beteiligten Kunden, Lieferanten und Anlagen werden entsprechende Nebenbücher wie die Kontokorrentbuchhaltung geführt. Im Controlling erfolgen schlussendlich die Kostenrechnung, das Gemeinkostencontrolling und die Ergebnisrechnung, inklusive Produktkostenrechnung und Profit-Center-Rechnung. (BH11, S ) 1.4 Das Hochregallager-Modell Das Hochregallager-Modell besteht aus Fischertechnik und befindet sich in der Elektronikwerkstatt der Infotronik-Fakultät der Hochschule Aalen. Es wird über ein SPS-Programm gesteuert. Die externe Kommunikation erfolgt über einen angebundenen FTP-Server. Auf diesem FTP-Server legt der Microsoft BizTalk- Server Steuerungsdateien ab und holt die Quittierungsdateien ab. Der BizTalk- Server kommuniziert über die SAP Schnittstelle mit dem SAP System unter Verwendung von IDoc s. Die primäre Funktion des BizTalk-Servers ist die Übersetzung und Filterung der relevanten Daten aus dem IDoc-Format in das SPS- Format und zurück. Über ein Touch-Panel werden die Grundfunktionen der SPS bedient sowie jederzeit ein definierter Startzustand hergestellt. Des weiteren verfügt das Hochregallager über einen Warenturm der mit MAOAMs befüllt ist und vom ERP System als Lieferant verwendet wird. Der Warenturm ist in einer festgelegten Reihenfolge mit verschiedenen MAOAMs befüllt, sodass je nach Bestellung die richtige Ware eingelagert werden kann. Das Hochregallager verfügt über einen Lagerplatz für den Warenempfang vom Lieferanten, 50 Lagerplätze für Paletten innerhalb des Hochregallagers selbst sowie einen Lagerplatz für den Warenversand zum Kunden. 5

8 1 EINLEITUNG Quelle: "Fallstudie Hochregellagermodell - Teil 1 - Lager anlegen", Mäule A.; Abbildung 3 Abbildung 4: Die Übersicht über das Hochregallager-Modell Der Warenempfang und -versand wird durch kleine Modell-LKW s dargestellt. Der Lieferant liefert in diesem Modell die Ware immer als ganze Paletten. Das Lagersystem des Unternehmens verfügt über entsprechende Laufbänder um die Ware zu seinem Lagerplatz zu transportieren. Bei einem Terminauftrag eines Kunden wird die Ware ebenfalls über Laufbänder zum Warenausgang transportiert wo ein entsprechender Modell-LKW bereits auf die Maoam-Palette wartet. (Mae13b, S.2-3) 6

9 2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK 2 Die ursprüngliche Fallstudie im Überblick Die ursprüngliche Fallstudie besteht ebenfalls, wie unsere überarbeitete Version aus 4 Teilen. In dieser Übersicht werden die einzelnen Bearbeitungsschritte zusammengefasst und kurz erklärt. Zur Durchführung der Fallstudie ist diese Übersicht nicht geeignet da auf Bilder, Eingabevorgaben und Pfadangaben sowie Transaktionscodes bewusst verzichtet wurde. 2.1 Der Inhalt der ursprünglichen Fallstudie Der erste Teil beinhaltet das Anlegen eines Lagers. Dieses wird im SAP so angelegt, dass die Prozesse voll automatisch verwaltet werden können. Dabei wird zuerst der Lagerort angelegt, welcher das physische Lager abbildet. (Mae13b, S.2-5) Anschließend muss die Lagernummer definiert werden. Sie bildet einen Teil des Gesamtlagers, also einen Lagerkomplex ab, welcher aus Lagerplätzen und Lagertypen besteht. Auf der Ebene der Lagernummer finden später alle Prozesse statt. Die Lagernummer muss deshalb noch zu einem gewünschten Werk zugeordnet werden, zu welchem sie auch in der Realität gehört. (Mae13b, S.8-10) Zu dieser Lagernummer müssen anschließend die Stammdaten gepflegt werden. Diese enthalten Daten wie die Gewichtseinheit und sonstige Steuerparameter wie die Sperrlogik, welche benötigt wird um bei mehreren parallelen Prozessen das ACID-Prinzip einzuhalten. (Mae13b, S.11-12) Als nächstes werden die Nummernkreisintervalle angelegt, diese geben an in welchem Bereich z.b. die Transportaufträge durchnummeriert werden. Die Spannweite sollte daher möglichst groß sein und darf nur numerische Werte enthalten. Diese Intervalle müssen nun der zugehörigen Lagernummer zugeordnet werden. (Mae13b, S.14-17) Nun folgt die Aufgliederung der Lagernummer, also des Lagerkomplex. Dies erfolgt durch das Anlegen von Lagertypen zu der Lagernummer. Dabei werden Wareneingangszone, Warenausgangszone und das Lagerregal jeweils mit einem eigenem Lagertyp versehen. Dabei wird auch die Einlagerungs- und die Auslagerungssteuerung angelegt. Es kann hierfür z.b. FIFO oder LIFO, etc. gewählt werden. (Mae13b, S.18) Anschließend müssen zu den einzelnen Lagertypen zu weiteren Aufteilung, Lagerbereiche gepflegt werden. In einem Bereich des realen Lagers können nämlich eventuell nur Paletten oder Waren bei niedriger Temperatur gelagert werden. (Mae13b, S.23) 7

10 2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK Danach muss die Vorgabe eines Lagerplatzes definiert werden. Hierzu wird ein Lagerplatztyp angelegt. Zu diesem Lagerplatztyp und zu dem angelegten Lagertyp der Regale, sowie der Lagernummer werden die Lagerplätze über eine Lagerplatzstruktur maschinell angelegt. Für die Wareneingangs- und Warenausgangszone erfolgt das Anlegen eines Lagerplatzes manuell. (Mae13b, S.25-29) Des Weiteren muss noch bekannt gemacht werden wie die Lagerbereiche gefunden werden sollen. Dabei werden Lagerbereichskennzeichen gepflegt, die Suchreihenfolge festgelegt und die Lagerbereichsprüfung aktiviert. (Mae13b, S.31-32) Die Lagertypfindung wird im Anschluss ebenfalls definiert. Auch hier wird zunächst das Lagertypkennzeichen angelegt und die Suchreihenfolge gepflegt. Des Weiteren wird die Zugriffsoptimierung durch die Typkennzahl aktiviert. (Mae13b, S.33-35) Darüber hinaus müssen auch noch die Bedarfstypen definiert werden, welche die Gründe für Transporte im Lager abbilden wie z.b. ein Kundenauftrag. Genauso müssen auch die Transportarten gepflegt werden, die angeben um was für einen Transport es sich handelt z.b. eine Auslagerung. Anschließend müssen noch die Bewegungsarten angelegt werden. Sie geben den Ablauf einer Warenbewegung vor. (Mae13b, S.36-39) Nun wird noch die Lagereinheit für das Material definiert. Diese Einheit gibt an wie das Material normalerweise vorliegt, in unserer Fallstudie sind dies z.b. Paletten. (Mae13b, S.47-48) Als nächstes erfolgt das Anlegen der Lagerplatztypfindung. Da Lagerplatztypen und Lagereinheitstypen nun bereits angelegt sind erfolgt hier nur die Zuordnung des Lagereinheitstyps zum Lagertyp, sowie die Zuordnung des Lagereinheitstyps zum Lagerplatztyp. Anschließend ist das Lager für die weiteren Teile der Fallstudie voll konfiguriert. (Mae13b, S.48-50) 8

11 2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK Im 2. Teil der Fallstudie wird das Material angelegt das im Lager verwaltet werden soll. Bei dem Material handelt es sich um Maoams die als Handelsware angelegt werden. Die Branche des Materials ist dementsprechend "Handel". Folgende Sichten werden zu den Materialien gepflegt: Grunddaten 1 & 2 Vertrieb: VerkaufsorgDaten 1 & 2 Vertrieb: allg. Werksdaten Vertriebstext Einkauf Einkaufsbestelltext Disposition 1-4 Prognose Allg. Werksdaten/Lagerung 1 & 2 Lagerverwaltung 1 & 2 Qualitätsmanagement Buchhaltung 1 & 2 Kalkulation 1 & 2 (Mae13c, S.2-3) Als Daten der Organisationsebene wurden in der ursprünglichen Fallstudie die Werte für die Eingliederung des Lagers unter dem Werk 1000 vorgenommen. Weshalb die Materialien für folgende Organisationsdaten angelegt werden: Parameter Wert Werk 1000 Lagerort Das erstellte Lager ### Verkaufsorganisation 1000 Vertriebsweg 10 Lagernummer Die angelegte Lagernummer zum Lager ### Lagertyp Keine Angabe (Mae13c, S.4) 9

12 2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK Wie diese Sichten zu pflegen sind wird anschließend in der Fallstudie erläutert. In der Sicht Einkauf erfolgt eine Umrechnung von der Bestellmengeneinheit Palette zur Basismengeneinheit Stück. Dabei enthält eine Palette 3 Stück des Materials. (Mae13c, S.5-27) Die weiteren Materialien sind in ihrem Aufbau identisch. Sie unterscheiden sich lediglich in ihrer Bezeichnung, da sie eine andere Sorte von Maoams abbilden. Sie können deshalb vom erstellten Maoam-Material kopiert werden, dabei muss hinterher nur der Einkaufstext sowie der Vertriebstext angepasst werden. (Mae13c, S.29-31) Zum Schluss dieses Teils der Fallstudie ist das Anlegen eines Lieferanten, sowie die zugehörigen Orderbücher und Infosätze der Materialien und des Lieferanten. Außerdem werden die Preiskonditionen festgelegt. (Mae13c, S.32) 10

13 2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK Im 3. Teil wird die Erstellung der IDoc s behandelt. Die Kommunikation über Idoc s wird im weiteren Verlauf der Seminararbeit nochmal genauer betrachtet. Kurz gesagt handelt es sich hierbei um auf XML basierende Datenaustauschformaten für die Kommunikation mit Fremdsystemen. In der späteren Fallstudie werden mittels IDocs Transportaufträge an den BizTalk-Server versandt. Ein Teil der Funktionalität wird also einem Fremdsystem übertragen, weshalb man von integriertem Geschäftsprozess spricht. Das Fremdsystemsystem meldet das Ergebnis der Verarbeitung in Form einer Quittierung, als IDoc zurück an das SAP-System. Damit dieser Datenaustausch möglich wird muss das Fremdsystem zuerst über ALE an das SAP-System gekoppelt werden. Deshalb wird als erster Schritt dieses Teiles der Fallstudie die Kopplung über ALE angelegt. Dabei wird zunächst eine Schnittstelle zur angelegten Lagernummer aktiviert. Anschließend wird die Schnittstellen-Steuerung zum Subsystem definiert. Im Anschluss muss die Erstellung der IDoc s für die Transportaufträge angelegt werden, dabei wird zur angelegten Lagernummer ein neuer Eintrag mit dem IDoc WMTORD gepflegt. Danach wird noch die Ereigniskopplung aktiviert. (Mae13d, S.2-6) Für die Bestellung eines Lieferanten ist eine Quittierung nicht erforderlich. Anders als bei den Transportaufträgen werden hier die Materialien von außerhalb bestellt. Im Modell wird dabei die Ware aus dem Warenturm entnommen und an die Wareneingangszone gebracht. Deshalb reicht hierfür eine unidirektionale Verbindung zum Fremdsystem. Diese wird nun in der Fallstudie angelegt. Dabei wird die Applikation "Einkauf Bestellung" gewählt und für die Konditionen die Nachrichtenfindung festgelegt. Der Konditionssatz wird im Anschluss daran angelegt. Zum Schluss wird noch dargestellt wie man die IDoc-Konfiguration überprüfen kann. Dabei wird wie im 4.Teil vorgegangen und eine Lieferantenbestellung angelegt. Jedoch befindet sich das Modell dabei nicht in Betrieb. (Mae13d, S.8-9) 11

14 2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK Im 4. und letzten Teil der Fallstudie werden die Prozesse im Hochregallagermodell durchgeführt. In der ursprünglichen Fallstudie müssen sich alle beteiligten absprechen wer jetzt den Prozess starten darf, da ansonsten verschiedene IDoc s über den BizTalk-Server an das Modell gesendet werden, was zu einer falschen Verarbeitung am Hochregallagermodell führen würde. Zunächst wird für das Werk und den Lagerort eine Palette der Ware beim Lieferanten bestellt. Hierdurch wird der erste IDoc des Typs "Orders01" an das Fremdsystem versendet. Im Modell wird die bestellte Palette aus dem Lagerturm genommen und durch einen bereitstehenden LKW zur Wareneingangszone gebracht. (Mae13e, S.3-6) Anschließend muss die eingetroffene Ware verbucht werden, dabei ist die Eingabe der Bestellnummer der vorher angelegten Lieferantenbestellung erforderlich. Danach wird automatisch ein Transportbedarf erstellt. Hierbei ist die Lagernummer und der Lagertyp anzugeben aus dem die Ware transportiert werden soll. Der Transportauftrag wird dabei "hell" angelegt, wodurch er im Vordergrund abgewickelt wird. Das heißt der Transportauftrag der Benutzer kann die bestehenden Daten kontrollieren und gegebenenfalls bearbeiten. (SA14c) (Mae13e, S.7-11) Anschließend wird der in Teil 3 zugeordnete IDoc mit der Bezeichnung "WMTO- ID01" erstellt, welcher die Daten des Transportauftrags enthält. Im Modell wird dadurch die Palette eingelagert. Das Modell quittiert den Transportauftrag ebenfalls mit einem IDoc. Da dies nicht immer zuverlässig funktioniert besteht hier auch die Möglichkeit den Transportauftrag im SAP-System manuell zu quittieren. (Mae13e, S.11-13) Nun kann die Ware weiter an den Kunden verkauft werden. Dazu wird ein Terminauftrag angelegt. Dabei ist zu beachten, dass der Kunde eine Stückzahl bestellt und im Lager Paletten enthalten sind. Es erfolgt also eine Umrechnung. Danach kann der Warenausgang gebucht werden. Auch wird wieder ein Transportauftrag als Folgefunktion angelegt. Der Ablauf ist dabei "Systemgesteuert" und sowohl die Kommissioniermenge also auch die Einlagerungsmenge wird als Liefermenge in der Lieferung übernommen. Auch hier wird wieder ein IDoc erstellt und an das Hochregallagermodell abgesetzt. (Mae13e, S.15-19) Im Anschluss transportiert das Modell die Ware zum Warenausgang wo der LKW sie zum Kunden fährt. Nun muss der Transportauftrag wieder quittiert werden, was durch das Touchpanel oder manuell im SAP-System geschehen kann. Danach muss noch der Warenausgang verbucht werden und an den Kunden eine Faktura gestellt werden, welche im Anschluss noch beglichen werden muss. Danach ist die komplette Fallstudie abgeschlossen. (Mae13e, S.20-22) 12

15 2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK 2.2 Prozessübersicht Da sich der 1. Teil der Fallstudie mit dem Customizing des Lagers beschäftigt, werden hier betriebswirtschaftlich relevante Geschäftsprozesse nur vorbeireitet, jedoch nicht selber durchgeführt. Es gibt jedoch eine Ablaufreihenfolge nach der das Lager angelegt wird. Diese ist: (Mae13b) Abbildung 5: Die Ablaufreihenfolge beim Anlegen eines Lagers Im 2. Teil wird auf normale Art und Wiese ein Material angelegt. Dabei werden zunächst die Sichten und die Organisationsebenen ausgewählt. Anschließend werden die Sichten gepflegt. Die weiteren Materialien können dann durch Kopieren angelegt werden. (Mae13c) Abbildung 6: Die Ablaufreihenfolge beim Anlegen der Materialien Außerdem wird noch ein Lieferant angelegt. Im Anschluss daran werden zum Lieferanten und zu den Materialien Infosätze und Orderbücher gepflegt. 13

16 2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK Im 3. Teil wird die Kommunikation über IDoc konfiguriert. Der integrierte Geschäftsprozess über ALE ist im Folgenden beschrieben. Für den IDoc über EDI ist eine Quittierung nicht erforderlich. (Mae13d) Abbildung 7: Der integrierte Geschäftsprozess über ALE Da das Anlegen dieser Kommunikation genauer im Abschnitt 4.3 beschrieben wird, wird an dieser Stelle auf eine Darstellung der Ablaufreihenfolge verzichtet. 14

17 2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK Im 4. Teil wird zuerst der Geschäftsprozess einer Lieferbestellung bis zur Einlagerung beschrieben. (Mae13e) Abbildung 8: Der Geschäftsprozess einer Lieferbestellung Anschließend kann die Ware verkauft werden. Der Geschäftsprozess dazu beschreibt das Anlegen eines Terminauftrags bis zur Rechnungsbegleichung durch den Kunden. (Mae13e) Abbildung 9: Der Geschäftsprozess des Vertriebs 15

18 2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK 2.3 Prozesse der einzelnen SAP Module Da die Teile 1 und 3 ausschließlich Customizing enthalten finden hier in den einzelnen Module keine Geschäftsprozesse im eigentlichen Sinne statt. Der 1.Teil bezieht sich durch das Anlegen des Lagers und betrifft somit ausschließlich das Modul "Logistik" einschließlich der Komponente Materialwirtschaft (MM). Im 3. Teil wird die Kommunikation angelegt, dabei ist kein betriebswirtschaftliches Modul betroffen, jedoch sind auch Komponenten außerhalb des SAP Systems beteiligt, welche die Kommunikation von Seiten des Fremdsystems regeln. Im 2. Teil ist durch das Anlegen des Material die Komponente Materialwirtschaft (MM) des Moduls "Logistik" beteiligt. Das Anlegen eines Lieferanten, der Infosätze und der Orderbücher erfolgt ebenfalls in dieser Komponente. Jedoch ist der Lieferant, als Kreditor auch für das Modul "Rechnungswesen" relevant. In Teil 4 sind durch die Geschäftsprozesse der Lieferbestellung und des Vertriebs die Komponenten Materialwirtschaft (MM) und Vertrieb (SD) des Moduls "Logistik" und die Komponente Finanzwesen (FI) des Moduls "Rechnungswesen" beteiligt. 16

19 3 Customizing des SAP ECC 3.1 Die Arten des Customizing 3 CUSTOMIZING DES SAP ECC In SAP ECC ist ein großer Teil der Funktionalität durch Einstellung von Parametern in Tabellen konfigurierbar. Dies wird im engeren Sinn als Customizing bezeichnet und muss bei der Einführung des Systems sowie jedes Moduls vorgenommen werden. Hierbei handelt es sich um die vom Hersteller präferierte Art das SAP-System zu modifizieren. Des Weiteren stehen noch Modifikationen, Erweiterungen (Customer-Exists) und Eigenentwicklung (Zusatzprogrammierung) zur Verfügung, welches im weiteren Sinn ebenfalls zum Customizing zählt. (FGSK08, S.14) Die Parameter der Customizing-Tabellen werden zur Laufzeit vom System ausgewertet und angewandt. Zur Unterstützung der Pflege wird eine Baumstruktur bereitgestellt. Diese Art der Anpassung ist die häufigste und unproblematischste, Releasewechsel haben keine Auswirkungen auf die getroffenen Anpassungen. Es ist jedoch auch möglich die Steuertabellen direkt per Zusatzprogrammierung zu beschreiben. Dadurch können z.b. über Mandanten hinweg gleiche Einstellungen einfach via Programm wiederholt vorgenommen werden. (FGSK08, S.14) Nachfolgendes Beispiel stellt den Customizing-Eintrag eines Werkes in den Systemtabellen via IMG, sowie den Pfad dorthin, dar. Abbildung 10: SAP Customizing - Baumstruktur (Werk definieren) 17

20 3 CUSTOMIZING DES SAP ECC Abbildung 11: SAP Customizing - Werk definieren, Tabellenansicht Abbildung 12: SAP Customizing - Werk definieren, Detailansicht eines Werkes In der SAP-Software sind weiterhin sogenannte Customer-Exits für die Erweiterung der Standardfunktionalität enthalten. An diesen durch den Hersteller vorbereiteten Stellen im Quelltext von Programmen, Menüs und Dynpros (dynamisches Programm) können Bereiche mit individueller Programmlogik, zur Erweiterung des Standardablaufs, integriert werden. Durch diese Erweiterungen wird der Quelltext der Standardprogramme jedoch nicht verändert. Bei einem Releasewechsel werden die Standardprogramme ersetzt und die individuellen Bereiche dabei automatisch an den entsprechenden Stellen im neuen Quelltext integriert. Diese Erweiterungen sind Release-fest. (FGSK08, S.14) 18

21 3 CUSTOMIZING DES SAP ECC Eine Erweiterung der Customer-Exits stellen die User-Exits dar. In diesen kann, im Unterschied zu den Customer-Exits, auf Programmteile und Datenobjekte des Standards zugegriffen sowie Veränderungen an diesen vorgenommen werden. Da bei einem Releasewechsel Änderungen im Standard vorgenommen worden sein könnten muss zwingend geprüft werden, ob die eigenen Programmteile mit den neuen Programmteilen und Datenobjekten des Standards harmonieren (SA14h). Auf Anforderung ist auch ein Eingriff in den Namensraum der Standardprogramme durch den Integrator möglich. Von diesen Eingriffen wird allerdings abgeraten, da die Standardprogramme bei jedem Update mit der Originalversion aus dem Updaterelease überschrieben werden. Außerdem empfiehlt die SAP AG generell die Aufteilung in eine 3-System-Landschaft, bestehend aus einem Entwicklungssystem, einem Test-und Abnahmesystem und einem Produktivsystem. (FGSK08, S.15-17) Es ist natürlich möglich die individuellen Änderungen nach einem Update wieder nach zuführen. Dies ist entsprechend aufwändig sowie, wenn sich durch das Update die Programmstruktur des Standardprogramms geändert hat, mit einer Anpassung der individuellen Erweiterung verbunden. Des Weiteren ist es möglich, Eigenentwicklungen zu erstellen. Hierbei werden beispielsweise individuelle Datentabellen sowie für die Datenerfassung Bildschirmbilder (Dynpros) erstellt. Diese Erweiterungen greifen nicht in den Standardlieferumfang der SAP-Software ein und werden daher durch Releasewechsel nicht verändert. Setzen die Eigenentwicklungen allerdings Datenquellen und Funktionen des Standardlieferumfangs voraus muss durch den Entwickler geprüft werden, ob das Vorhandensein dieser Voraussetzungen nach dem Releasewechsel weiterhin gewährleistet ist. Aus diesem Grund ist der Aufwand für das Vor- und Nacharbeiten bei einen Releasewechsel betreffend Eigenentwicklungen vergleichbar mit dem bei Eingriffen in den Namensraum der Standardprogramme. 19

22 3 CUSTOMIZING DES SAP ECC 3.2 Customizing in der Fallstudie Die Fallstudie beschränkt sich auf das Customizing der Parametertabellen via Customizing-Einführungsleitfaden (Transaktionscode: SPRO -> SAP Referenz-IMG). Diese Bezeichnung dieser Liste steht für "Implementation Guide". (FGSK08, S.14) Der Umfang wird in den einzelnen Teilen der Fallstudie beschrieben. 3.3 Die Kommunikation über die verschiedenen Schnittstellen Für die Kommunikation zwischen dem SAP System und dem Hochregallagermodell wird eine Datenübertragung benötigt. Hierfür sind zwei Arten der Kopplung verfügbar: 1. Lose Kopplung: die Systeme sind lose gekoppelt und voneinander unabhängig. Die Systeme kommunizieren hierbei asynchron und es werden Nachrichten im IDoc (Intermediate Documents) Format ausgetauscht. Dadurch kann das aufrufende System auch bei Nichtverfügbarkeit des aufgerufenen Systems weiterarbeiten. Es werden vom SAP System verschiedene IDoc Typen bereitgestellt, welche alle auf XML aufbauen, jedoch eine abweichenden Syntax verwenden. Die Konfiguration der losen Kopplung findet über das SAP Customizing statt, sodass ABAP Kenntnisse nicht benötigt werden. Für diese Kopplung stehen die ALE-Technologie (Application Link Enabling, bidirektionale Kommunikation möglich) und die die EDI-Technologie (Electronic Data Interchange, nur unidirektionale Kommunikation) zur Verfügung. (SA14a) 2. Enge Kopplung: die Systeme sind eng gekoppelt und voneinander abhängig. Die Systeme kommunizieren synchron. Dies erfolgt allgemein über den synchronen Aufruf von remotefähigen Funktionsbausteinen des aufrufenden auf dem aufgerufenen System. Die Exportparameter des Funktionsbausteins können vom aufrufenden System ausgewertet werden. Jedoch muss das aufgerufene System bei der engen Kopplung zwingend verfügbar sein. Es wird hierbei die BAPI-Technologie (Business Application Programming Interface) verwendet. (SA14a) 20

23 3 CUSTOMIZING DES SAP ECC Die Kommunikation zwischen dem SAP System und dem Hochregallagermodell wird mittels loser Kopplung abgewickelt. Es wird unterschieden zwischen: 1. Übermittlung der Transportaufträge an das Hochregallagermodell. Hierbei handelt es sich um einen sogenannten integrierten Geschäftsprozess. Das bedeutet, dass Teile der Funktionalitäten die vom SAP unterstützt werden an ein Fremdsystem abgegeben werden. Es wird hierfür die ALE-Technologie mit bidirektionaler Kommunikation eingesetzt. Die Übergabe der benötigten Daten findet dabei über die verschiedenen IDoc s statt. Dem Fremdsystem liegen anschließend die Daten zur Verarbeitung vor. Nach Abschluss dieser meldet das Fremdsystem das Ergebnis der Verarbeitung zurück. Die Verarbeitung dieser Daten ist in dem Fall des Hochregallagermodells mit der Aus- und Einlagerung von Material in das Hochregellager gekoppelt. Das bedeutet, dass die von SAP übermittelten Daten von der Steuerung des Hochregellagers ausgelesen und für die Ansteuerung der einzelnen Teile des Hochregallagermodells verwendet werden. Nachdem alle durch einen IDoc übermittelten Arbeitsaufträge abgearbeitet wurden, wird eine sogenannte Quittierung erwartet. Das bedeutet, dass vom Fremdsystem wiederum ein IDoc mit einer vorgegebenen Struktur an das SAP System übermittelt wird um den Status der Verarbeitung an das System zurück zu melden.(mae13d) 2. Übermittlung des Beschaffungsauftrags an den Lagerturm des Lieferanten. Hierbei handelt es sich nicht um einen integrierten Geschäftsprozess sondern um eine normale Datenübertragung. Es wird hierfür die EDI-Technologie mit unidirektionaler Kommunikation eingesetzt. Die Übermittlung der Daten selbst wird über einen dafür vorgesehenen IDoc abgewickelt. Der Lagerturm des Lieferanten ist im Hochregallagermodell integriert. Die Kommunikation zwischen dem SAP-System und dem Hochregallagermodell erfolgt unter Verwendung eines Microsoft BizTalk-Servers. Die Konfiguration entstammt der Bachelorarbeit (Mae13a) und wird vollumfänglich verwendet. Abbildung 13: Kommunikationskopplung: SAP - Hochregallagermodell 21

24 3 CUSTOMIZING DES SAP ECC 3.4 Customizing zur weiteren Funktionalität der Fallstudie Ab Teil 4 "Die Prozesse im Hochregallagermodell" der Fallstudie zum Hochregallager finden Interaktionen zwischen dem SAP System und dem Hochregallagermodell statt. Diese Interaktionen dürfen zeitgleich nur von einem Werk durchgeführt werden. Zudem muss der Teil 4 von jedem Anwender am Stück abgearbeitet werden. Eine Unterbrechung zugunsten anderer Anwender ist nicht möglich. Um Kollisionen zwischen den Anwendern zu verhindern muss ein entsprechender Sperrmechanismus hergestellt werden. Der Sperrmechanismus besteht in einer Datenbanktabelle, in welcher das aktuelle aktive Werk für die Customizing Fallstudie gespeichert wird und einer Prüffunktion beim Anlegen einer Lieferantenbestellung in Form einer Programmerweiterung des zugeordneten Customer-Exits. Diese Programmerweiterung prüft, ob für die Kombination aus eingetragenem Lieferanten und eingetragener Einkaufsorganisation eine entsprechende EDI-Konfiguration vorhanden ist. Im zutreffenden Fall wird dann für jede Bestellposition geprüft, ob das dort eingetragene Werk dem aktuell aktiven Werk für die Customizing Fallstudie zum Hochregallagermodell entspricht und im Negativfall das Speichern der Lieferantenbestellung, nach Hinweis für den Anwender, unterbunden. Um die Funktionalität der Fallstudie herzustellen sind nachfolgende Customizing Erweiterungen notwendig: 1. Für die Verwaltung des aktuell gültigen Werkes, welches die Fallstudie ab Teil 4 (Lieferantenbestellung anlegen) exklusiv fortführen darf, wird eine Datenbanktabelle sowie ein Dynpro zur Änderung des Werkeintrags benötigt. In der Datenbank wird hierfür die Zusatztabelle ZCUSHRLWerk angelegt. In dieser ist nur ein Tabelleneintrag vorhanden in welchem das aktuell aktive Werk für die Fallstudie gespeichert wird. Damit der Betreuer der Fallstudie das aktive Werk schnell und unkompliziert setzen kann wird das Dynpro ZCUSHRLWerk erstellt und die Transaktion ZCUSHRLWerk eingerichtet. Es besteht somit keine Notwendigkeit, dass der Betreuer über tiefer gehende Systemkenntnisse verfügt. 22

25 3 CUSTOMIZING DES SAP ECC 2. Die Prüfung der Lieferantenbestellung beim Speichern, ob für die Kombination aus eingetragenem Lieferanten und eingetragener Einkaufsorganisation eine entsprechende EDI-Konfiguration vorhanden und in diesem Fall, ob in allen Bestellpositionen das aktuell gültige Werke eingetragen ist, wurde im Customer-Exit EXIT_SAPMM06EE_012 via ABAP Erweiterungsprogrammierung integriert. Um die Verriegelung voll umfassend zu gestalten müsste noch beim Anlegen von Transportaufträgen ein Customer-Exit integriert werden, welcher auch dort eine entsprechende Prüfung des Werks durchführt. Da Transportaufträge im Wareneingang eine vorhandene Lieferantenbestellung und im Verkauf einen Lagerplatzbestand voraussetzen ist eine Kollision durch die Vorbedingungen sehr unwahrscheinlich und wurde deshalb in dieser Seminararbeit nicht berücksichtigt. Im Zusatzdokument "Customizing für Fallstudie HRL Modell" sind alle Erweiterungen beschrieben. 23

26 4 Die multi-user-fähige Fallstudie 4 DIE MULTI-USER-FÄHIGE FALLSTUDIE Im nachfolgenden werden die Erweiterungen an der ursprünglichen Fallstudie beschrieben. Durch diese Erweiterungen und das in 3.4 beschriebene weiterführende Customizing wird die Multiuser-Fähigkeit hergestellt. 4.1 Teil 1 - Unternehmensorganisation und Lager Da wir die Fallstudie multi-userfähig gestalten sollten war es praktisch, dass jeder Student sein eigenes Werk erhält. Somit kann man über die Auswahl eines Werks den Zugriff auf das Hochregallagermodell exklusiv für einen Studenten anlegen. Außerdem sind viele Tabellen auf Werksebene angelegt. Da im Standardwerk 1000 sehr viele Datensätze angelegt sind ist es an manchen Stellen umständlich seinen Datensatz zuerst suchen zu müssen. Über den Einführungsleitfaden der Referenz- IMG wird also in der multi-user-fähigen Fallstudie zunächst ein eigenes Werk mit Adresse über "neue Einträge" angelegt. Da in diesem Werk Transaktionen stattfinden muss es als nächstes einem Buchungskreis zugeordnet werden, in dem es abgerechnet wird. Ein Buchungskreis ist dabei eine abgeschlossene Buchhaltung, also eine eigene juristische Person. Es muss hierbei kein neuer Buchungskreis angelegt werden um die erforderlich Multi-User-Fähigkeit zu erreichen. Deshalb wird im nächsten Schritt das angelegte (Dies Zeichenfolge wird beim Bearbeiten durch die jeweilige Kennnummer des Studenten ersetzt) dem Buchungskreis 1000 zugeordnet. Anschließend kann das Lager wie in 2.1 beschrieben angelegt werden. Dabei ist darauf zu achten, dass als Werk immer das angelegte anstelle des Werks 1000 angegeben wird. Nachdem das Lager vollständig konfiguriert ist, muss jetzt jedoch die Unternehmensorganisation weiter angelegt werden. Dabei haben wir uns an der Fallstudie zur Unternehmensstruktur aus der Vorlesung "SAP Customizing" orientiert. (RM10) 24

27 4 DIE MULTI-USER-FÄHIGE FALLSTUDIE Quelle: Vgl. "CUS02 - Unternehmensstruktur DC AA (1.01)", Prof. Dr. Rössle, M.; Müelich, S.; Abbildung 1 Abbildung 14: Die Unternehmensstruktur Daher muss nun zunächst noch eine eigene angelegt werden. Dies wird für den süd-deutschen Raum mit der Statistikwährung "EUR" angelegt. Des Weiteren wird für die Verkaufsorganisation eine beliebige Adresse hinterlegt. Diese Verkaufsorganisation wird im Anschluss dem Buchungskreis 1000 zugeordnet. (RM10) Als nächstes folgt das Zuordnen der Vertriebswege. Dabei wird der angelegten Verkaufsorganisation der Vertriebsweg 10 (Endkundenverkauf) zugeordnet, was einem Direktvertrieb entspricht. Des Weiteren muss der Verkaufsorganisation eine Sparte zugeordnet werden. Hierfür wird die Sparte 00 (Spartenübergreifend)gewählt. Im Anschluss wird aus der Verkaufsorganisation, dem Vertriebsweg und der Sparte ein Vertriebsbereich gebildet. Hiernach folgt die Zuordnung der Kombination aus Verkaufsorganisation und Vertriebsweg zum angelegten (RM10) Des Weiteren wird eine Versandstelle gebildet. Dabei handelt es sich um den physischen Ort, von dem aus die Ware versendet wird, weshalb er möglichst nahe am Lieferwerk liegen sollte. Ein Werk kann dabei mehrere Versandstellen besitzen und eine Versandstelle kann mehrere Werke besitzen. Deshalb wird hier die angelegt und im Anschluss dem zugeordnet. (RM10) 25

28 4 DIE MULTI-USER-FÄHIGE FALLSTUDIE Da beim Erfassen eines Kundenauftrag die Versandstelle für eine Position in Abhängigkeit der im Materialstamm hinterlegten Versandbedingungen und Ladegruppen und des Werks gewählt wird. Daher ist nun eine Zuordnung zwischen Versandbedingung, Ladegruppe, Werk und Versandstelle einzurichten. (RM10) Darüber hinaus soll die Versandstelle zum angelegten Lager gehören. Deshalb wird die Versandstelle weiterführend lagerortsabhängig dem zugeordnet. (SA14i) Da das neue Werk Einkäufe tätigt muss es außerdem auch noch einer Einkaufsorganisation zugeordnet werden. Hierfür wird die Einkaufsorganisation 1000 gewählt. (SA14b) Zum Schluss des ersten Teils der multi-user-fähigen Fallstudie muss noch die Bestandführung für den aktiviert werden. Dabei wird für den und die Materialart "HAWA" (Handelsware) die Mengenfortschreibung und die Wertfortschreibung aktiviert. Im Anschluss ist der 1. Teil der multi-user-fähigen Fallstudie abgeschlossen, welcher im Folgenden als BPMN-Diagramm nochmals dargestellt ist. Die Teile der ursprünglichen Fallstudie sind dabei hellbraun dargestellt. (RM10) Abbildung 15: Teil 1 der multi-user-fähigen Fallstudie 26

29 4 DIE MULTI-USER-FÄHIGE FALLSTUDIE 4.2 Teil 2 - Material, Einkaufs- und Vertriebsbedingungen anlegen Da wir das Material nun für das eigen erstellte anlegen ist es zum Pflegen der Sicht "Disposition 1" erforderlich den verantwortlichen Disponenten anzugeben. Da Disponenten aber Werks-abhängig angelegt werden ist bisher noch keiner vorhanden. Dieser muss deshalb vor dem Anlegen der Materialien angelegt werden. Ebenso muss für die Sicht "Disposition 2" ein neuer Horizontschlüssel für das angelegt werden. Erst jetzt können die Materialien angelegt werden. Dabei werden die gleichen Sichten wie in 2.1 gepflegt. Jedoch ist dabei darauf zu achten, dass die Organisationsebenen nun andere sind. So wird als Werk das angelegte angegeben, als Lagerort der angelegte als Verkaufsorganisation die angelegte der zugeordnete Vertriebsweg 10 und die angelegte Ansonsten werden für die Sichten die gleichen Dateneingaben wie in der ursprünglichen Fallstudie verwendet, da der Disponent und der Horizontschlüssel jeweils mit derselben Bezeichnung wie im Werk 1000 angelegt wurden. Beim Kopieren der weiteren Materialien ist darauf zu achten, dass sowohl die Organisationsebenen des neu zu erstellenden Materials, als auch die des Vorlagematerials richtig, wie die oben genannten angepassten Organisationseinheiten, eingegeben werden. Außerdem haben wir den Vorgang des Anlegens von Lieferant, Infosätzen und Orderbücher genauer in der multi-user-fähigen Fallstudie beschrieben, da beim Anlegen der Orderbücher und der Infosätze auch die zugeordnete Einkaufsorganisation 1000 relevant ist und wir den Vorgang, einschließlich der Preiskonditionen, genauer erläutern wollten. Da wir eine neu angelegte Verkaufsorganisation mit dem zugeordneten Vertriebsweg 10 haben und unter dieser die Materialien angelegt haben, müssen wir nun die Preisfindung hierfür anlegen. Dabei wird die Konditionsart "PR00" verwendet. (SA14f) Damit diese Konditionsart in der Verkaufsorganisation anschließend auch gefunden wird muss im Customizing noch die Kalkulationsschemaermittlung eingerichtet werden. Diese wird in Abhängigkeit des Vertriebsbereichs, des Kundenschemas und des Belegschemas ermittelt. 27

30 4 DIE MULTI-USER-FÄHIGE FALLSTUDIE In einem neuen Eintrag werden deshalb folgende Eingaben gepflegt: (SA14e) Vertriebsweg: 10 Sparte: 00 Belegschema: A (Standard) Kundenschema: 1 (Standard) Kalkulationsschema: RVAA01 (Standard) Konditionsart: PR00 Anschließend ist es erforderlich nun auch einen eigenen Kunden für die anzulegen. Dieser Debitor wird im Buchungskreis 1000, für die dem Vertriebsweg 10 und der Sparte 00 mit der Bezeichnung "@###-MAOAM" angelegt. Als Kontengruppe wird "Debitor allgemein" (KUNA) angegeben. Beim Anlegen des Debitors werden die allgemeinen Daten, die Buchungskreisdaten und die Vertriebsbereichsdaten gepflegt. Dabei ist das Abstimmkonto einzutragen. Ebenso ist darauf zu achten, dass das Auslieferungswerk das ist. Da an diesen Kunden eine Faktura gestellt wird und der Zahlungseingang anschließend beglichen wird, muss für die neue noch die Kontenfindung im Customizing eingerichtet werden. Dabei wird der Erlöskontenfindung ein Sachkonto über den Kontenschlüssel "ERL" zugeordnet. Nun ist auch der 2. Teil der multi-user-fähigen Fallstudie abgeschlossen. Abbildung 16: Teil 2 der multi-user-fähigen Fallstudie 28

31 4 DIE MULTI-USER-FÄHIGE FALLSTUDIE 4.3 Teil 3 - Kopplung über ALE Die Kommunikation zwischen dem SAP System und dem Hochregallagermodell wird mittels ALE- und EDI-Technologie in loser Kopplung abgewickelt. Die Details zu den Methoden wurden in Abschnitt 3.3 beschreiben. Dieser Teil der Fallstudie behandelt die notwendigen Einstellungen bezüglich der Kopplung der Kommunikation und ist in zwei Abschnitte unterteilt. Im ersten Abschnitt wird die bidirektionale Kopplung der Transportaufträge erläutert, im zweiten Abschnitt die unidirektionale Kopplung der Bestellaufträge. Abbildung 17: Kopplung Fremdsysteme 1. Die Einstellungen für die bidirektionale Kopplung der Transportaufträge über ALE werden im SAP System unter Verwendung der Transaktion OMKY vorgenommen, die Einrichtungsschritte umfassen nachfolgende Prozessschritte. Es wird mit der Einrichtung der Schnittstelle zur Lagernummer gestartet. Hierbei wird dem Tabelleneintrag mit der eigenen Lagernummer die Kommunikationsmethode 1 zugewiesen. Anschließen ist die Steuerung der Schnittstelle zum Subsystem einzustellen. Dazu werden für die einzelnen Transportvorgänge, Lagertypen und Bewegungsarten, welche eine Kommunikation zwischen dem SAP System und dem Hochregallagermodell bedürfen, Einträge mit der SAP- BizTalk Schnittstelle des Hochregallagermodells als Empfänger erstellt. Nachdem diese Einstellungen getroffen wurden ist nun die Definition der Funktionsbausteine zum IDoc-Aufbau umzusetzen. Der Tabelleneintrag des eigenen Lagers ist hierzu in der Kopplungssicht auszuwählen und der Funktionsbaustein L_IDOC_CREATE_WMTOID01 einzutragen. Zum Abschluss der Kopplung der Transportaufträge ist nun noch die Ergebniskopplung über den entsprechenden Menüpunkt zu aktivieren. (Mae13d, S.1-7) 29

32 4 DIE MULTI-USER-FÄHIGE FALLSTUDIE Abbildung 18: Kopplung Transportaufträge - ALE 2. Im zweiten Abschnitt werden die Einstellungen für die Bestellungen beim Lieferanten getroffen. Hierzu wird die im SAP System enthaltene unidirektionale EDI-Schnittstelle zur Kommunikation verwendet. Diese wird mittels der Transaktion NACE eingerichtet. Die Konfiguration ist lieferantenbezogen. Dieser Abschnitt startet mit der Einstellung der Nachrichtenart der Konditionensteuerung. Hierzu werden in der Nachrichtensteuerung die Applikation EF - Einkauf Bestellung und die Nachrichtenart NEU - Bestelldruck gewählt. Zu dieser Kombination ist die Nachrichtenfindung Einkaufsorg./Lieferant für EDI zu verwenden. Dem Konfigurationseintrag dieser drei Parameter werden anschließend die Einkaufsorganisation sowie der eigene Lieferant zugeordnet. Abschließend werden im erstellten Konditionssatz die eigenen MAOAM Artikel eingetragen sowie die Kommunikationsparameter gesetzt. (Mae13d, S.8-9) Abbildung 19: Kopplung Bestellungen - EDI 30

33 4 DIE MULTI-USER-FÄHIGE FALLSTUDIE 4.4 Teil 4 - Die Prozesse im Hochregallagermodell Da hier nun die Durchführung der Prozesse erläutert wird, hat sich im Vergleich zur ursprünglichen Fallstudie kaum etwas geändert. Vor dem Start dieses Teils der Fallstudie wird nun das berechtigte Werk des zu prüfenden Studenten über die Transaktion: "ZCUSHRLWerk" eingetragen. Anschließend kann die Fallstudie wie in 2.1 bearbeitet werden. Dabei haben wir die Erstellung der Faktura und die Rechnungsbegleichung ausführlicher erläutert. Außerdem wurde in jedem Teil der Fallstudie Bildschirmabzüge teilweise angepasst und Neue hinzugefügt. Nach der Rechnungsbegleichung durch den Debitor ist dieser Teil und somit die komplette multi-user-fähige Fallstudie abgeschlossen. Der erfolgreiche Abschluss der Fallstudie kann entweder in der Elektronikwerkstatt durch die erfolgreiche Auslieferung beobachtet werden, oder indem man den Belegfluss der Fallstudie nachverfolgt. Der Buchhaltungsbeleg am Ende des 4. Teils der Fallstudie sollte dabei "ausgeziffert" sein. Quelle: "Fallstudie Hochregellagermodell - Teil 4 - Lieferantenbestellung", Mäule A.; Abbildung 23 Abbildung 20: Die Auslagerung und Auslieferung an den Kunden Der Seminararbeit sind folgende Dokumente beigelegt: 1. Die ursprüngliche Fallstudie Teil Die multi-user-fähige Fallstudie Teil Ein Dokument zur Beschreibung des weiterführenden Customizing: "Customizing für Fallstudie HRL Modell" 31

34 Literatur Literatur [BH11] Benz, Jochen ; Hoeflinger, Markus: Logistikprozesse mit SAP. 3. VIEWEG+TEUBNER, 2011 [FGSK08] Frick, Detlev ; Gadatsch, Andreas ; Schaeffer-Kuelz, Ute G.: Grundkurs SAP ERP. 1. Friedr. Vieweg & Sohn Verlag, 2008 [Mae13a] Maeule, Alexander: Fallstudie Hochregallager Modell - Technische Dokumentation. In: Bachelorarbeit - Alexander Maeule Technische Dokumentation (2013) [Mae13b] Maeule, Alexander: Fallstudie Hochregallager Modell - Teil 1 - Lager anlegen. In: Bachelorarbeit - Alexander Maeule Fallstudien zum Hochregallagermodell (2013) [Mae13c] Maeule, Alexander: Fallstudie Hochregallager Modell - Teil 2 - Material anlegen. In: Bachelorarbeit - Alexander Maeule Fallstudien zum Hochregallagermodell (2013) [Mae13d] Maeule, Alexander: Fallstudie Hochregallager Modell - Teil 3 - Idoc erstellung. In: Bachelorarbeit - Alexander Maeule Fallstudien zum Hochregallagermodell (2013) [Mae13e] Maeule, Alexander: Fallstudie Hochregallager Modell - Teil 4 - Lieferantenbestellung. In: Bachelorarbeit - Alexander Maeule Fallstudien zum Hochregallagermodell (2013) [RM10] Roessle, Prof. Dr. Manfred H. ; Mueelich, Sven: CUS02 - Unternehmensstruktur DC AA(1.01). In: SAP Customizing (2010) [SA14a] SAP-AG: ALE. Version: c/helpdata/de/18/22b d396b20004ac96334b/ content.htm, Abruf: [SA14b] SAP-AG: Einkaufsorganisation - Werk zuordnen. Version: e364b20437d1118b3f0060b03ca329/content.htm, Abruf: [SA14c] SAP-AG: Hell-/Dunkelablauf. Version: http: //help.sap.com/saphelp_erp60_sp/helpdata/de/c6/ f839ce4afa11d182b90000e829fbfe/content.htm, Abruf: [SA14d] SAP-AG: IDoc. Version: c/helpdata/de/0b/2a60ef507d11d18ee90000e8366fc2/ content.htm, Abruf: II