Hochschule-Aalen

Studiengang Informatik

Seminararbeit

Erstellen einer multiuser-fähigenFallstudie 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 44337Nicolas Macho 44360

Abgabedatum: 25. Juni 2014

Inhaltsverzeichnis

Inhaltsverzeichnis

1 Einleitung 11.1 Aufgabenstellung . . . . . . . . . . . . . . . . . . . . . . . . . . . 11.2 Was ist SAP ERP Central Component (ECC)? . . . . . . . . . . 11.3 Prozesse und Organisationsstruktur der Lagerlogistik in SAP . . . 31.4 Das Hochregallager-Modell . . . . . . . . . . . . . . . . . . . . . . 5

2 Die ursprüngliche Fallstudie im Überblick 72.1 Der Inhalt der ursprünglichen Fallstudie . . . . . . . . . . . . . . 72.2 Prozessübersicht . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.3 Prozesse der einzelnen SAP Module . . . . . . . . . . . . . . . . . 16

3 Customizing des SAP ECC 173.1 Die Arten des Customizing . . . . . . . . . . . . . . . . . . . . . . 173.2 Customizing in der Fallstudie . . . . . . . . . . . . . . . . . . . . 203.3 Die Kommunikation über die verschiedenen Schnittstellen . . . . . 203.4 Customizing zur weiteren Funktionalität der Fallstudie . . . . . . 22

4 Die multi-user-fähige Fallstudie 244.1 Teil 1 - Unternehmensorganisation und Lager . . . . . . . . . . . 244.2 Teil 2 - Material, Einkaufs- und Vertriebsbedingungen anlegen . . 274.3 Teil 3 - Kopplung über ALE . . . . . . . . . . . . . . . . . . . . . 294.4 Teil 4 - Die Prozesse im Hochregallagermodell . . . . . . . . . . . 31

Literatur II

Abbildungsverzeichnis IV

Eidesstattliche Erklärung V

I

1 EINLEITUNG

1 EinleitungDas Herzstück eines jeden großen, modernen Unternehmens ist seine Prozess-und Informationsstruktur. Ohne die IT ist die Verwaltung von Unternehmensres-sourcen heutzutage nicht mehr möglich. Dieser Verwaltungsaufwand steigtmit der Größe des Unternehmens, da in einer globalisierten Welt verschiedeneStandorte, Zulieferer, Kunden und Mitarbeiter unter einen Hut gebracht werdenmüssen. Die Kosten die für die Verwaltung anfallen steigen exponentiell undwerden Agency-Kosten genannt.

Die IT trägt maßgeblich zur Senkung dieser Kosten bei. Viele große Un-ternehmen haben deshalb SAP ECC im Einsatz. Doch was ist SAP ECCüberhaupt?

1.1 AufgabenstellungDas Thema unserer Seminararbeit beschäftigt sich mit der Frage welche An-passungsmöglichkeiten SAP ECC bietet, welche Besonderheiten diese aufweisenund wie man sie praktisch anwenden kann um eine Fallstudie die sich mit einemProzess für die Lagerhaltung in einem Hochregellager beschäftigt, multiuserfähigzu gestalten. Dabei wird dieser Prozess immer von SAP-Seite aus gestartet undkontrolliert. Die Befehle werden dabei mittels dem SAP-seitigen Datenaustausch-format IDoc an die Fremdsysteme übermittelt. (SA14d) Aus welchen Bestand-teilen ein IDoc genauer besteht und wie die Kommunikation in der Fallstudiestattfindet wird später noch genauer erläutert. Unsere Aufgabe war es also zuerstdie Theorie zu einigen relevanten Gebieten des Customizing und der Kommuni-kation mit Fremdsystemen genauer zu begutachten und daraus die vorhandeneFallstudie zu überarbeiten und sie multiuserfähig zu gestalten und neu zu doku-mentieren, damit diese von Studenten bearbeitet werden kann. Über die Theoriezum Customizing und zur Kommunikation zwischen SAP und Fremdsystemen,die ursprüngliche Fallstudie und deren Logistikprozesse, das Vorgehen und dieresultierende 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 Unter-nehmen ablaufenden Geschäftsprozesse und zur Verwaltung sämtlicher Unter-nehmensressourcen. Die SAP AG ist hierbei weltweiter Marktführer mit über258.000 Kunden in 180 Ländern und einem Gesamtumsatz von 16,90 MilliardenEuro im Geschäftsjahr 2013. Außerdem hat die SAP AG durch SAP HANA ei-ne marktführende Technologie für Echtzeit-Computing auf den Markt gebracht.(SA14g) Es sind für nahezu jeden Einsatz Lösungen, teilweise durch externe Part-ner, erhältlich.

1

1 EINLEITUNG

Außerdem kann ein SAP-System auf Rechner-Plattformen zahlreicher Herstellerinstalliert werden, ohne dabei Einschränkungen in der Funktionalität hinnehmenzu müssen. Die Endanwender greifen über Clients auf das SAP-System zu. Ebensosind zahlreiche Datenbanksysteme für das SAP-System geeignet. (FGSK08, S.16-17)Ein SAP-System ist in Module unterteilt, welche jeweils einen betriebswirtschaft-lichen Bereich abdecken:

Quelle: http://sapmodules.org/wp-content/uploads/2013/01/SAP-Modules.gif

Abbildung 2: SAP Module

Des Weiteren sind alle Systemkomponenten konsequent mehrsprachig und er-lauben somit einen internationalen Einsatz. Weiterhin ist ein SAP-System man-dantenfähig und erlaubt es so mehrere wirtschaftlich und rechtlich selbstständi-ge Unternehmen abzubilden. Die komplette Organisationsstruktur eines solchenUnternehmens lässt sich dabei in sogenannten Organisationselementen abbilden.(FGSK08, S.19)Das System ist in einer dreiteiligen Client-Server-Architektur aufgebaut. Diesebesteht aus:

1. Datenbankserver

2. Applikationsserver

3. Präsentationsschicht auf der Client-Seite

2

1 EINLEITUNG

Dabei werden die Daten über den Datenbankserver und die Anwendungen vonden Applikationsservern bereitgestellt. Der Benutzerdialog findet hingegen aufeinem Client statt welcher mittels TCP/IP-Protokoll über das Netzwerk kommu-niziert. (FGSK08, S.19-20)

1.3 Prozesse und Organisationsstruktur der Lagerlogistik inSAP

Für die Abbildung der allgemeinen Logistik werden verschiedene Organisationss-trukturen 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ührungwird ein Werk genau einem Buchungskreis zugeordnet, wobei ein Buchungskreismehrere Werke haben kann. Ein Werk hingegen kann mehrere Lagerorte besitzen,in denen die Inventur und die Bestandsführung erfolgen. Der Lagerort kann nureinem Werk zugeordnet werden.

Abbildung 3: SAP Zuordnung der Organisationseinheiten

3

1 EINLEITUNG

Eine Einkaufsorganisation und eine Einkäufergruppe sind hingegen folgender-maßen gegliedert. Wenn es sich um eine werksbezogene Einkaufsorganisationhandelt wird diese Einkaufsorganisation genau einem Werk zugeordnet, sodassnur für dieses Werk die erforderlichen Materialien über diese Einkauforganisationbeschafft werden. Jedoch gibt es auch die Möglichkeit der werksübergreifendenEinkaufsorganisation 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 vonPersonen die für den Einkauf verantwortlich ist.Wohingegen auf Basis des Bewertungskreises die Materialbewegung stattfindet.

Beim Vertrieb kommen zu dieser Organisationsstruktur noch folgende Organisa-tionseinheiten 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 abbildenkann müssen also diese aufgelisteten Organisationseinheiten dargestellt werden.Die Prozesse die die Lagerlogistik betreffen erstrecken sich nicht nur auf dasModul Logistik, sondern es sind in der Regel mehrere Module bei diesem Zusam-menspiel beteiligt, wie zum Beispiel auch das Rechnungswesen. In diesen Modu-len 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.149-150)

4

1 EINLEITUNG

Es gibt zahlreiche Prozesse die in der Lagerlogistik mittels SAP abgebildet wer-den können. Hier sollen nur ein paar Grundlagen erläutert werden. Die für dieFallstudie relevanten Prozesse werden in den jeweiligen Kapitel genauer erläutert.Die Komponente "Produktionsplanung und -steuerung (PP)" beschäftigt sich mitden Planungs- und Durchführungsprozessen. Eine zentrale Stellung nimmt dabeider Fertigungsauftrag ein. In der Materialwirtschaft werden die Bestandsführungund die Einkaufsprozesse verwaltet. Außerdem findet hier die rechnerische undsachliche Rechnungsprüfung der Lieferantenrechnungen satt. Die Bestandsfüh-rung beinhaltet die Inventur, sowie die wert- und mengenmäßige Führung der Ma-terialbestände und verbucht die Lagerbewegungen, inklusive Wareneingang undWarenausgang. Die Vertrieb-Komponente beschäftigt sich mit den Verkaufsakti-vitäten wie dem Erfassen von Kundenaufträgen und die Versandabwicklung. AmEnde eines Vertriebsprozess steht die Fakturierung, welche im Finanzwesen aus-geziffert 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 An-lagen werden entsprechende Nebenbücher wie die Kontokorrentbuchhaltung ge-führt. Im Controlling erfolgen schlussendlich die Kostenrechnung, das Gemeinkos-tencontrolling und die Ergebnisrechnung, inklusive Produktkostenrechnung undProfit-Center-Rechnung. (BH11, S.150-153)

1.4 Das Hochregallager-ModellDas Hochregallager-Modell besteht aus Fischertechnik und befindet sich in derElektronikwerkstatt der Infotronik-Fakultät der Hochschule Aalen. Es wird überein SPS-Programm gesteuert. Die externe Kommunikation erfolgt über einenangebundenen 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 unterVerwendung von IDoc’s. Die primäre Funktion des BizTalk-Servers ist die Über-setzung und Filterung der relevanten Daten aus dem IDoc-Format in das SPS-Format und zurück. Über ein Touch-Panel werden die Grundfunktionen der SPSbedient sowie jederzeit ein definierter Startzustand hergestellt. Des weiteren ver-fügt das Hochregallager über einen Warenturm der mit MAOAMs befüllt istund vom ERP System als Lieferant verwendet wird. Der Warenturm ist in einerfestgelegten Reihenfolge mit verschiedenen MAOAMs befüllt, sodass je nach Be-stellung die richtige Ware eingelagert werden kann. Das Hochregallager verfügtüber einen Lagerplatz für den Warenempfang vom Lieferanten, 50 Lagerplätzefür Paletten innerhalb des Hochregallagers selbst sowie einen Lagerplatz für denWarenversand zum Kunden.

5

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. DasLagersystem des Unternehmens verfügt über entsprechende Laufbänder um dieWare zu seinem Lagerplatz zu transportieren. Bei einem Terminauftrag einesKunden wird die Ware ebenfalls über Laufbänder zum Warenausgang transpor-tiert wo ein entsprechender Modell-LKW bereits auf die Maoam-Palette wartet.(Mae13b, S.2-3)

6

2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK

2 Die ursprüngliche Fallstudie im ÜberblickDie ursprüngliche Fallstudie besteht ebenfalls, wie unsere überarbeitete Versionaus 4 Teilen. In dieser Übersicht werden die einzelnen Bearbeitungsschrittezusammengefasst und kurz erklärt. Zur Durchführung der Fallstudie ist dieseÜbersicht nicht geeignet da auf Bilder, Eingabevorgaben und Pfadangaben sowieTransaktionscodes bewusst verzichtet wurde.

2.1 Der Inhalt der ursprünglichen FallstudieDer erste Teil beinhaltet das Anlegen eines Lagers. Dieses wird im SAP so an-gelegt, dass die Prozesse voll automatisch verwaltet werden können. Dabei wirdzuerst der Lagerort angelegt, welcher das physische Lager abbildet. (Mae13b,S.2-5)Anschließend muss die Lagernummer definiert werden. Sie bildet einen Teildes Gesamtlagers, also einen Lagerkomplex ab, welcher aus Lagerplätzen undLagertypen besteht. Auf der Ebene der Lagernummer finden später alle Prozessestatt. Die Lagernummer muss deshalb noch zu einem gewünschten Werk zuge-ordnet 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 Steuerparameterwie die Sperrlogik, welche benötigt wird um bei mehreren parallelen Prozessendas ACID-Prinzip einzuhalten. (Mae13b, S.11-12)

Als nächstes werden die Nummernkreisintervalle angelegt, diese geben an in wel-chem Bereich z.B. die Transportaufträge durchnummeriert werden. Die Spann-weite 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 er-folgt durch das Anlegen von Lagertypen zu der Lagernummer. Dabei werdenWareneingangszone, Warenausgangszone und das Lagerregal jeweils mit einemeigenem Lagertyp versehen. Dabei wird auch die Einlagerungs- und die Ausla-gerungssteuerung angelegt. Es kann hierfür z.B. FIFO oder LIFO, etc. gewähltwerden. (Mae13b, S.18)Anschließend müssen zu den einzelnen Lagertypen zu weiteren Aufteilung, La-gerbereiche gepflegt werden. In einem Bereich des realen Lagers können nämlicheventuell nur Paletten oder Waren bei niedriger Temperatur gelagert werden.(Mae13b, S.23)

7

2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK

Danach muss die Vorgabe eines Lagerplatzes definiert werden. Hierzu wirdein Lagerplatztyp angelegt. Zu diesem Lagerplatztyp und zu dem angelegtenLagertyp der Regale, sowie der Lagernummer werden die Lagerplätze über eineLagerplatzstruktur maschinell angelegt. Für die Wareneingangs- und Warenaus-gangszone erfolgt das Anlegen eines Lagerplatzes manuell. (Mae13b, S.25-29)

Des Weiteren muss noch bekannt gemacht werden wie die Lagerbereichegefunden werden sollen. Dabei werden Lagerbereichskennzeichen gepflegt, dieSuchreihenfolge festgelegt und die Lagerbereichsprüfung aktiviert. (Mae13b,S.31-32) Die Lagertypfindung wird im Anschluss ebenfalls definiert. Auchhier wird zunächst das Lagertypkennzeichen angelegt und die Suchreihenfolgegepflegt. Des Weiteren wird die Zugriffsoptimierung durch die Typkennzahlaktiviert. (Mae13b, S.33-35)

Darüber hinaus müssen auch noch die Bedarfstypen definiert werden, welche dieGründe für Transporte im Lager abbilden wie z.B. ein Kundenauftrag. Genausomüssen auch die Transportarten gepflegt werden, die angeben um was für einenTransport es sich handelt z.B. eine Auslagerung. Anschließend müssen noch dieBewegungsarten angelegt werden. Sie geben den Ablauf einer Warenbewegungvor. (Mae13b, S.36-39)

Nun wird noch die Lagereinheit für das Material definiert. Diese Einheit gibtan 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 Lagerplatztypenund Lagereinheitstypen nun bereits angelegt sind erfolgt hier nur die Zuordnungdes Lagereinheitstyps zum Lagertyp, sowie die Zuordnung des Lagereinheitstypszum Lagerplatztyp. Anschließend ist das Lager für die weiteren Teile derFallstudie voll konfiguriert. (Mae13b, S.48-50)

8

2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK

Im 2. Teil der Fallstudie wird das Material angelegt das im Lager verwaltetwerden soll. Bei dem Material handelt es sich um Maoams die als Handelswa-re 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 dieWerte für die Eingliederung des Lagers unter dem Werk 1000 vorgenommen.Weshalb die Materialien für folgende Organisationsdaten angelegt werden:

Parameter WertWerk 1000

Lagerort Das erstellte Lager ###Verkaufsorganisation 1000

Vertriebsweg 10Lagernummer Die angelegte Lagernummer zum Lager ###

Lagertyp Keine Angabe(Mae13c, S.4)

9

2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK

Wie diese Sichten zu pflegen sind wird anschließend in der Fallstudie erläutert. Inder Sicht Einkauf erfolgt eine Umrechnung von der Bestellmengeneinheit Palettezur 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 sichlediglich in ihrer Bezeichnung, da sie eine andere Sorte von Maoams abbilden. Siekönnen deshalb vom erstellten Maoam-Material kopiert werden, dabei muss hin-terher nur der Einkaufstext sowie der Vertriebstext angepasst werden. (Mae13c,S.29-31)Zum Schluss dieses Teils der Fallstudie ist das Anlegen eines Lieferanten, sowiedie zugehörigen Orderbücher und Infosätze der Materialien und des Lieferanten.Außerdem werden die Preiskonditionen festgelegt. (Mae13c, S.32)

10

2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK

Im 3. Teil wird die Erstellung der IDoc’s behandelt. Die Kommunikation überIdoc’s wird im weiteren Verlauf der Seminararbeit nochmal genauer betrachtet.Kurz gesagt handelt es sich hierbei um auf XML basierende Datenaustauschfor-maten für die Kommunikation mit Fremdsystemen. In der späteren Fallstudiewerden mittels IDocs Transportaufträge an den BizTalk-Server versandt. EinTeil der Funktionalität wird also einem Fremdsystem übertragen, weshalb manvon integriertem Geschäftsprozess spricht. Das Fremdsystemsystem meldet dasErgebnis der Verarbeitung in Form einer Quittierung, als IDoc zurück an dasSAP-System. Damit dieser Datenaustausch möglich wird muss das Fremdsystemzuerst über ALE an das SAP-System gekoppelt werden. Deshalb wird als ersterSchritt dieses Teiles der Fallstudie die Kopplung über ALE angelegt. Dabei wirdzunächst eine Schnittstelle zur angelegten Lagernummer aktiviert. Anschließendwird die Schnittstellen-Steuerung zum Subsystem definiert.Im Anschluss muss die Erstellung der IDoc’s für die Transportaufträge angelegtwerden, dabei wird zur angelegten Lagernummer ein neuer Eintrag mit dem IDocWMTORD gepflegt. Danach wird noch die Ereigniskopplung aktiviert. (Mae13d,S.2-6)Für die Bestellung eines Lieferanten ist eine Quittierung nicht erforderlich. An-ders als bei den Transportaufträgen werden hier die Materialien von außerhalbbestellt. Im Modell wird dabei die Ware aus dem Warenturm entnommen undan die Wareneingangszone gebracht. Deshalb reicht hierfür eine unidirektionaleVerbindung zum Fremdsystem. Diese wird nun in der Fallstudie angelegt. Dabeiwird die Applikation "Einkauf Bestellung" gewählt und für die Konditionen dieNachrichtenfindung festgelegt. Der Konditionssatz wird im Anschluss daran an-gelegt.Zum Schluss wird noch dargestellt wie man die IDoc-Konfiguration überprüfenkann. Dabei wird wie im 4.Teil vorgegangen und eine Lieferantenbestellung an-gelegt. Jedoch befindet sich das Modell dabei nicht in Betrieb. (Mae13d, S.8-9)

11

2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK

Im 4. und letzten Teil der Fallstudie werden die Prozesse im Hochregallager-modell durchgeführt. In der ursprünglichen Fallstudie müssen sich alle beteiligtenabsprechen wer jetzt den Prozess starten darf, da ansonsten verschiedene IDoc’süber den BizTalk-Server an das Modell gesendet werden, was zu einer falschenVerarbeitung am Hochregallagermodell führen würde.Zunächst wird für das Werk und den Lagerort eine Palette der Ware beim Lie-feranten bestellt. Hierdurch wird der erste IDoc des Typs "Orders01" an dasFremdsystem versendet. Im Modell wird die bestellte Palette aus dem Lager-turm genommen und durch einen bereitstehenden LKW zur Wareneingangszonegebracht. (Mae13e, S.3-6)Anschließend muss die eingetroffene Ware verbucht werden, dabei ist die Eingabeder Bestellnummer der vorher angelegten Lieferantenbestellung erforderlich. Da-nach wird automatisch ein Transportbedarf erstellt. Hierbei ist die Lagernummerund der Lagertyp anzugeben aus dem die Ware transportiert werden soll. DerTransportauftrag wird dabei "hell" angelegt, wodurch er im Vordergrund abge-wickelt wird. Das heißt der Transportauftrag der Benutzer kann die bestehendenDaten 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 wirddadurch die Palette eingelagert. Das Modell quittiert den Transportauftrag eben-falls mit einem IDoc. Da dies nicht immer zuverlässig funktioniert besteht hierauch 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 Ter-minauftrag angelegt. Dabei ist zu beachten, dass der Kunde eine Stückzahl be-stellt und im Lager Paletten enthalten sind. Es erfolgt also eine Umrechnung.Danach kann der Warenausgang gebucht werden. Auch wird wieder ein Trans-portauftrag als Folgefunktion angelegt. Der Ablauf ist dabei "Systemgesteuert"und sowohl die Kommissioniermenge also auch die Einlagerungsmenge wird alsLiefermenge in der Lieferung übernommen. Auch hier wird wieder ein IDoc er-stellt und an das Hochregallagermodell abgesetzt. (Mae13e, S.15-19)Im Anschluss transportiert das Modell die Ware zum Warenausgang wo der LKWsie zum Kunden fährt. Nun muss der Transportauftrag wieder quittiert werden,was durch das Touchpanel oder manuell im SAP-System geschehen kann. Danachmuss noch der Warenausgang verbucht werden und an den Kunden eine Fakturagestellt werden, welche im Anschluss noch beglichen werden muss. Danach ist diekomplette Fallstudie abgeschlossen. (Mae13e, S.20-22)

12

2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK

2.2 ProzessübersichtDa 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 derdas 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 werdenzunächst die Sichten und die Organisationsebenen ausgewählt. Anschließend wer-den die Sichten gepflegt. Die weiteren Materialien können dann durch Kopierenangelegt werden. (Mae13c)

Abbildung 6: Die Ablaufreihenfolge beim Anlegen der Materialien

Außerdem wird noch ein Lieferant angelegt. Im Anschluss daran werden zumLieferanten und zu den Materialien Infosätze und Orderbücher gepflegt.

13

2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK

Im 3. Teil wird die Kommunikation über IDoc konfiguriert. Der integrierte Ge-schäftsprozess über ALE ist im Folgenden beschrieben. Für den IDoc über EDIist eine Quittierung nicht erforderlich. (Mae13d)

Abbildung 7: Der integrierte Geschäftsprozess über ALE

Da das Anlegen dieser Kommunikation genauer im Abschnitt 4.3 beschriebenwird, wird an dieser Stelle auf eine Darstellung der Ablaufreihenfolge verzichtet.

14

2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK

Im 4. Teil wird zuerst der Geschäftsprozess einer Lieferbestellung bis zur Einla-gerung beschrieben. (Mae13e)

Abbildung 8: Der Geschäftsprozess einer Lieferbestellung

Anschließend kann die Ware verkauft werden. Der Geschäftsprozess dazu be-schreibt das Anlegen eines Terminauftrags bis zur Rechnungsbegleichung durchden Kunden. (Mae13e)

Abbildung 9: Der Geschäftsprozess des Vertriebs

15

2 DIE URSPRÜNGLICHE FALLSTUDIE IM ÜBERBLICK

2.3 Prozesse der einzelnen SAP ModuleDa die Teile 1 und 3 ausschließlich Customizing enthalten finden hier in deneinzelnen Module keine Geschäftsprozesse im eigentlichen Sinne statt.Der 1.Teil bezieht sich durch das Anlegen des Lagers und betrifft somitausschließlich das Modul "Logistik" einschließlich der Komponente Materialwirt-schaft (MM).

Im 3. Teil wird die Kommunikation angelegt, dabei ist kein betriebswirtschaft-liches Modul betroffen, jedoch sind auch Komponenten außerhalb des SAPSystems beteiligt, welche die Kommunikation von Seiten des Fremdsystemsregeln.

Im 2. Teil ist durch das Anlegen des Material die Komponente Materialwirt-schaft (MM) des Moduls "Logistik" beteiligt. Das Anlegen eines Lieferanten, derInfosätze und der Orderbücher erfolgt ebenfalls in dieser Komponente. Jedochist der Lieferant, als Kreditor auch für das Modul "Rechnungswesen" relevant.

In Teil 4 sind durch die Geschäftsprozesse der Lieferbestellung und des Vertriebsdie Komponenten Materialwirtschaft (MM) und Vertrieb (SD) des Moduls "Lo-gistik" und die Komponente Finanzwesen (FI) des Moduls "Rechnungswesen"beteiligt.

16

3 CUSTOMIZING DES SAP ECC

3 Customizing des SAP ECC3.1 Die Arten des CustomizingIn SAP ECC ist ein großer Teil der Funktionalität durch Einstellung vonParametern in Tabellen konfigurierbar. Dies wird im engeren Sinn als Customi-zing bezeichnet und muss bei der Einführung des Systems sowie jedes Modulsvorgenommen werden. Hierbei handelt es sich um die vom Hersteller präferierteArt das SAP-System zu modifizieren. Des Weiteren stehen noch Modifikationen,Erweiterungen (Customer-Exists) und Eigenentwicklung (Zusatzprogrammie-rung) 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 aus-gewertet und angewandt. Zur Unterstützung der Pflege wird eine Baumstrukturbereitgestellt. Diese Art der Anpassung ist die häufigste und unproblematischste,Releasewechsel haben keine Auswirkungen auf die getroffenen Anpassungen. Esist jedoch auch möglich die Steuertabellen direkt per Zusatzprogrammierung zubeschreiben. Dadurch können z.B. über Mandanten hinweg gleiche Einstellungeneinfach via Programm wiederholt vorgenommen werden. (FGSK08, S.14)

Nachfolgendes Beispiel stellt den Customizing-Eintrag eines Werkes in denSystemtabellen via IMG, sowie den Pfad dorthin, dar.

Abbildung 10: SAP Customizing - Baumstruktur (Werk definieren)

17

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 Er-weiterung der Standardfunktionalität enthalten. An diesen durch den Herstel-ler 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 Erweite-rungen wird der Quelltext der Standardprogramme jedoch nicht verändert. Beieinem Releasewechsel werden die Standardprogramme ersetzt und die individuel-len Bereiche dabei automatisch an den entsprechenden Stellen im neuen Quelltextintegriert. Diese Erweiterungen sind Release-fest. (FGSK08, S.14)

18

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 Datenobjektedes Standards zugegriffen sowie Veränderungen an diesen vorgenommen werden.Da bei einem Releasewechsel Änderungen im Standard vorgenommen wordensein könnten muss zwingend geprüft werden, ob die eigenen Programmteilemit den neuen Programmteilen und Datenobjekten des Standards harmonieren(SA14h).

Auf Anforderung ist auch ein Eingriff in den Namensraum der Standard-programme durch den Integrator möglich. Von diesen Eingriffen wird allerdingsabgeraten, da die Standardprogramme bei jedem Update mit der Originalversionaus dem Updaterelease überschrieben werden. Außerdem empfiehlt die SAP AGgenerell die Aufteilung in eine 3-System-Landschaft, bestehend aus einem Ent-wicklungssystem, einem Test-und Abnahmesystem und einem Produktivsystem.(FGSK08, S.15-17)Es ist natürlich möglich die individuellen Änderungen nach einem Update wiedernach zuführen. Dies ist entsprechend aufwändig sowie, wenn sich durch dasUpdate die Programmstruktur des Standardprogramms geändert hat, mit einerAnpassung der individuellen Erweiterung verbunden.

Des Weiteren ist es möglich, Eigenentwicklungen zu erstellen. Hierbei wer-den beispielsweise individuelle Datentabellen sowie für die DatenerfassungBildschirmbilder (Dynpros) erstellt. Diese Erweiterungen greifen nicht inden Standardlieferumfang der SAP-Software ein und werden daher durchReleasewechsel nicht verändert. Setzen die Eigenentwicklungen allerdingsDatenquellen und Funktionen des Standardlieferumfangs voraus muss durchden Entwickler geprüft werden, ob das Vorhandensein dieser Voraussetzungennach dem Releasewechsel weiterhin gewährleistet ist. Aus diesem Grund ist derAufwand für das Vor- und Nacharbeiten bei einen Releasewechsel betreffendEigenentwicklungen vergleichbar mit dem bei Eingriffen in den Namensraum derStandardprogramme.

19

3 CUSTOMIZING DES SAP ECC

3.2 Customizing in der FallstudieDie Fallstudie beschränkt sich auf das Customizing der Parametertabel-len via Customizing-Einführungsleitfaden (Transaktionscode: SPRO -> SAPReferenz-IMG). Diese Bezeichnung dieser Liste steht für "Implementation Gui-de". (FGSK08, S.14) Der Umfang wird in den einzelnen Teilen der Fallstudiebeschrieben.

3.3 Die Kommunikation über die verschiedenen SchnittstellenFür die Kommunikation zwischen dem SAP System und dem Hochregallagermo-dell 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 unab-hängig. Die Systeme kommunizieren hierbei asynchron und es werden Nach-richten im IDoc (Intermediate Documents) Format ausgetauscht. Dadurchkann das aufrufende System auch bei Nichtverfügbarkeit des aufgerufenenSystems weiterarbeiten. Es werden vom SAP System verschiedene IDoc Ty-pen bereitgestellt, welche alle auf XML aufbauen, jedoch eine abweichendenSyntax verwenden. Die Konfiguration der losen Kopplung findet über dasSAP Customizing statt, sodass ABAP Kenntnisse nicht benötigt werden.Für diese Kopplung stehen die ALE-Technologie (Application Link Enab-ling, bidirektionale Kommunikation möglich) und die die EDI-Technologie(Electronic Data Interchange, nur unidirektionale Kommunikation) zur Ver-fügung. (SA14a)

2. Enge Kopplung: die Systeme sind eng gekoppelt und voneinander abhän-gig. Die Systeme kommunizieren synchron. Dies erfolgt allgemein über densynchronen Aufruf von remotefähigen Funktionsbausteinen des aufrufendenauf dem aufgerufenen System. Die Exportparameter des Funktionsbausteinskönnen vom aufrufenden System ausgewertet werden. Jedoch muss das auf-gerufene System bei der engen Kopplung zwingend verfügbar sein. Es wirdhierbei die BAPI-Technologie (Business Application Programming Inter-face) verwendet. (SA14a)

20

3 CUSTOMIZING DES SAP ECC

Die Kommunikation zwischen dem SAP System und dem Hochregallagermodellwird mittels loser Kopplung abgewickelt. Es wird unterschieden zwischen:

1. Übermittlung der Transportaufträge an das Hochregallagermo-dell.Hierbei handelt es sich um einen sogenannten integrierten Geschäftsprozess.Das bedeutet, dass Teile der Funktionalitäten die vom SAP unterstützt wer-den an ein Fremdsystem abgegeben werden.Es wird hierfür die ALE-Technologie mit bidirektionaler Kommunikationeingesetzt. Die Übergabe der benötigten Daten findet dabei über die ver-schiedenen IDoc’s statt. Dem Fremdsystem liegen anschließend die Datenzur Verarbeitung vor. Nach Abschluss dieser meldet das Fremdsystem dasErgebnis der Verarbeitung zurück. Die Verarbeitung dieser Daten ist in demFall des Hochregallagermodells mit der Aus- und Einlagerung von Materialin das Hochregellager gekoppelt. Das bedeutet, dass die von SAP übermit-telten Daten von der Steuerung des Hochregellagers ausgelesen und für dieAnsteuerung der einzelnen Teile des Hochregallagermodells verwendet wer-den. Nachdem alle durch einen IDoc übermittelten Arbeitsaufträge abge-arbeitet wurden, wird eine sogenannte Quittierung erwartet. Das bedeutet,dass vom Fremdsystem wiederum ein IDoc mit einer vorgegebenen Strukturan das SAP System übermittelt wird um den Status der Verarbeitung andas System zurück zu melden.(Mae13d)

2. Übermittlung des Beschaffungsauftrags an den Lagerturm desLieferanten.Hierbei handelt es sich nicht um einen integrierten Geschäftsprozess son-dern um eine normale Datenübertragung.Es wird hierfür die EDI-Technologie mit unidirektionaler Kommunikationeingesetzt. Die Übermittlung der Daten selbst wird über einen dafür vor-gesehenen IDoc abgewickelt. Der Lagerturm des Lieferanten ist im Hochre-gallagermodell integriert.

Die Kommunikation zwischen dem SAP-System und dem Hochregallagermodellerfolgt unter Verwendung eines Microsoft BizTalk-Servers. Die Konfiguration ent-stammt der Bachelorarbeit (Mae13a) und wird vollumfänglich verwendet.

Abbildung 13: Kommunikationskopplung: SAP - Hochregallagermodell

21

3 CUSTOMIZING DES SAP ECC

3.4 Customizing zur weiteren Funktionalität der FallstudieAb Teil 4 "Die Prozesse im Hochregallagermodell" der Fallstudie zum Hochre-gallager finden Interaktionen zwischen dem SAP System und dem Hochregal-lagermodell statt. Diese Interaktionen dürfen zeitgleich nur von einem Werkdurchgeführt werden. Zudem muss der Teil 4 von jedem Anwender „am Stück“abgearbeitet werden. Eine Unterbrechung zugunsten anderer Anwender ist nichtmöglich.

Um Kollisionen zwischen den Anwendern zu verhindern muss ein entspre-chender Sperrmechanismus hergestellt werden.Der Sperrmechanismus besteht in einer Datenbanktabelle, in welcher dasaktuelle aktive Werk für die Customizing Fallstudie gespeichert wird undeiner Prüffunktion beim Anlegen einer Lieferantenbestellung in Form einerProgrammerweiterung des zugeordneten Customer-Exits.

Diese Programmerweiterung prüft, ob für die Kombination aus eingetrage-nem Lieferanten und eingetragener Einkaufsorganisation eine entsprechendeEDI-Konfiguration vorhanden ist. Im zutreffenden Fall wird dann für jedeBestellposition geprüft, ob das dort eingetragene Werk dem aktuell aktivenWerk für die Customizing Fallstudie zum Hochregallagermodell entspricht undim Negativfall das Speichern der Lieferantenbestellung, nach Hinweis für denAnwender, unterbunden.

Um die Funktionalität der Fallstudie herzustellen sind nachfolgende Custo-mizing Erweiterungen notwendig:

1. Für die Verwaltung des aktuell gültigen Werkes, welches die Fallstudieab Teil 4 (Lieferantenbestellung anlegen) exklusiv fortführen darf, wirdeine Datenbanktabelle sowie ein Dynpro zur Änderung des Werkeintragsbenötigt.

In der Datenbank wird hierfür die Zusatztabelle ZCUSHRLWerk an-gelegt. In dieser ist nur ein Tabelleneintrag vorhanden in welchem dasaktuell aktive Werk für die Fallstudie gespeichert wird.

Damit der Betreuer der Fallstudie das aktive Werk schnell und un-kompliziert setzen kann wird das Dynpro ZCUSHRLWerk erstellt unddie Transaktion ZCUSHRLWerk eingerichtet. Es besteht somit keineNotwendigkeit, dass der Betreuer über tiefer gehende Systemkenntnisseverfügt.

22

3 CUSTOMIZING DES SAP ECC

2. Die Prüfung der Lieferantenbestellung beim Speichern, ob für die Kombina-tion aus eingetragenem Lieferanten und eingetragener Einkaufsorganisati-on eine entsprechende EDI-Konfiguration vorhanden und in diesem Fall, obin allen Bestellpositionen das aktuell gültige Werke eingetragen ist, wurdeim Customer-Exit EXIT_SAPMM06EE_012 via ABAP Erweiterungspro-grammierung integriert.

Um die Verriegelung voll umfassend zu gestalten müsste noch beim Anlegenvon Transportaufträgen ein Customer-Exit integriert werden, welcher auch dorteine entsprechende Prüfung des Werks durchführt. Da Transportaufträge imWareneingang eine vorhandene Lieferantenbestellung und im Verkauf einenLagerplatzbestand voraussetzen ist eine Kollision durch die Vorbedingungen sehrunwahrscheinlich und wurde deshalb in dieser Seminararbeit nicht berücksichtigt.

Im Zusatzdokument "Customizing für Fallstudie HRL Modell" sind alleErweiterungen beschrieben.

23

4 DIE MULTI-USER-FÄHIGE FALLSTUDIE

4 Die multi-user-fähige FallstudieIm nachfolgenden werden die Erweiterungen an der ursprünglichen Fallstudie be-schrieben. Durch diese Erweiterungen und das in 3.4 beschriebene weiterführendeCustomizing wird die Multiuser-Fähigkeit hergestellt.

4.1 Teil 1 - Unternehmensorganisation und LagerDa wir die Fallstudie multi-userfähig gestalten sollten war es praktisch, dass jederStudent sein eigenes Werk erhält. Somit kann man über die Auswahl eines Werksden Zugriff auf das Hochregallagermodell exklusiv für einen Studenten anlegen.Außerdem sind viele Tabellen auf Werksebene angelegt. Da im Standardwerk 1000sehr viele Datensätze angelegt sind ist es an manchen Stellen umständlich seinenDatensatz 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 mitAdresse über "neue Einträge" angelegt. Da in diesem Werk Transaktionen statt-finden muss es als nächstes einem Buchungskreis zugeordnet werden, in dem esabgerechnet wird. Ein Buchungskreis ist dabei eine abgeschlossene Buchhaltung,also eine eigene juristische Person. Es muss hierbei kein neuer Buchungskreisangelegt werden um die erforderlich Multi-User-Fähigkeit zu erreichen. Deshalbwird im nächsten Schritt das angelegte Werk @### (Dies Zeichenfolge wirdbeim Bearbeiten durch die jeweilige Kennnummer des Studenten ersetzt) dem Bu-chungskreis 1000 zugeordnet. Anschließend kann das Lager wie in 2.1 beschriebenangelegt werden. Dabei ist darauf zu achten, dass als Werk immer das angelegteWerk @###, anstelle des Werks 1000 angegeben wird. Nachdem das Lager voll-ständig konfiguriert ist, muss jetzt jedoch die Unternehmensorganisation weiterangelegt werden. Dabei haben wir uns an der Fallstudie zur Unternehmensstruk-tur aus der Vorlesung "SAP Customizing" orientiert. (RM10)

24

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 Verkaufsorganisation @### angelegtwerden. Dies wird für den süd-deutschen Raum mit der Statistikwährung "EUR"angelegt. Des Weiteren wird für die Verkaufsorganisation eine beliebige Adressehinterlegt. Diese Verkaufsorganisation wird im Anschluss dem Buchungskreis1000 zugeordnet. (RM10)

Als nächstes folgt das Zuordnen der Vertriebswege. Dabei wird der angeleg-ten Verkaufsorganisation der Vertriebsweg 10 (Endkundenverkauf) zugeordnet,was einem Direktvertrieb entspricht. Des Weiteren muss der Verkaufsorganisati-on eine Sparte zugeordnet werden. Hierfür wird die Sparte 00 (Spartenübergrei-fend)gewählt. Im Anschluss wird aus der Verkaufsorganisation, dem Vertriebswegund der Sparte ein Vertriebsbereich gebildet. Hiernach folgt die Zuordnung derKombination aus Verkaufsorganisation und Vertriebsweg zum angelegten Werk@###. (RM10)Des Weiteren wird eine Versandstelle gebildet. Dabei handelt es sich um den phy-sischen Ort, von dem aus die Ware versendet wird, weshalb er möglichst naheam Lieferwerk liegen sollte. Ein Werk kann dabei mehrere Versandstellen besit-zen und eine Versandstelle kann mehrere Werke besitzen. Deshalb wird hier dieVersandstelle @### angelegt und im Anschluss dem Werk @### zugeordnet.(RM10)

25

4 DIE MULTI-USER-FÄHIGE FALLSTUDIE

Da beim Erfassen eines Kundenauftrag die Versandstelle für eine Position inAbhängigkeit der im Materialstamm hinterlegten Versandbedingungen und La-degruppen und des Werks gewählt wird. Daher ist nun eine Zuordnung zwischenVersandbedingung, Ladegruppe, Werk und Versandstelle einzurichten. (RM10)Darüber hinaus soll die Versandstelle zum angelegten Lager gehören. Deshalbwird die Versandstelle weiterführend lagerortsabhängig dem Lagerort @###zugeordnet. (SA14i)Da das neue Werk Einkäufe tätigt muss es außerdem auch noch einer Einkaufs-organisation zugeordnet werden. Hierfür wird die Einkaufsorganisation 1000gewählt. (SA14b) Zum Schluss des ersten Teils der multi-user-fähigen Fallstudiemuss noch die Bestandführung für den Bewertungskreis @### aktiviert wer-den. Dabei wird für den Bewertungskreis @### und die Materialart "HAWA"(Handelsware) die Mengenfortschreibung und die Wertfortschreibung aktiviert.

Im Anschluss ist der 1. Teil der multi-user-fähigen Fallstudie abgeschlossen, wel-cher im Folgenden als BPMN-Diagramm nochmals dargestellt ist. Die Teile derursprünglichen Fallstudie sind dabei hellbraun dargestellt. (RM10)

Abbildung 15: Teil 1 der multi-user-fähigen Fallstudie

26

4 DIE MULTI-USER-FÄHIGE FALLSTUDIE

4.2 Teil 2 - Material, Einkaufs- und Vertriebsbedingungenanlegen

Da wir das Material nun für das eigen erstellte Werk @### anlegen istes zum Pflegen der Sicht "Disposition 1" erforderlich den verantwortlichenDisponenten anzugeben. Da Disponenten aber Werks-abhängig angelegt werdenist bisher noch keiner vorhanden. Dieser muss deshalb vor dem Anlegen derMaterialien angelegt werden. Ebenso muss für die Sicht "Disposition 2" ein neuerHorizontschlüssel für das Werk @### angelegt werden.

Erst jetzt können die Materialien angelegt werden. Dabei werden die gleichenSichten wie in 2.1 gepflegt. Jedoch ist dabei darauf zu achten, dass die Organi-sationsebenen nun andere sind. So wird als Werk das angelegte Werk @###angegeben, als Lagerort der angelegte Lagerort @###, als Verkaufsorganisationdie angelegte Verkaufsorganisation @###, der zugeordnete Vertriebsweg 10und die angelegte Lagernummer @##. Ansonsten werden für die Sichten diegleichen Dateneingaben wie in der ursprünglichen Fallstudie verwendet, da derDisponent und der Horizontschlüssel jeweils mit derselben Bezeichnung wieim Werk 1000 angelegt wurden. Beim Kopieren der weiteren Materialien istdarauf zu achten, dass sowohl die Organisationsebenen des neu zu erstellendenMaterials, als auch die des Vorlagematerials richtig, wie die oben genanntenangepassten Organisationseinheiten, eingegeben werden.

Außerdem haben wir den Vorgang des Anlegens von Lieferant, Infosätzenund Orderbücher genauer in der multi-user-fähigen Fallstudie beschrieben,da beim Anlegen der Orderbücher und der Infosätze auch die zugeordneteEinkaufsorganisation 1000 relevant ist und wir den Vorgang, einschließlich derPreiskonditionen, genauer erläutern wollten.

Da wir eine neu angelegte Verkaufsorganisation mit dem zugeordneten Vertriebs-weg 10 haben und unter dieser die Materialien angelegt haben, müssen wir nundie Preisfindung hierfür anlegen. Dabei wird die Konditionsart "PR00" verwendet.(SA14f)Damit diese Konditionsart in der Verkaufsorganisation anschließend auch gefun-den wird muss im Customizing noch die Kalkulationsschemaermittlung eingerich-tet werden. Diese wird in Abhängigkeit des Vertriebsbereichs, des Kundenschemasund des Belegschemas ermittelt.

27

4 DIE MULTI-USER-FÄHIGE FALLSTUDIE

In einem neuen Eintrag werden deshalb folgende Eingaben gepflegt: (SA14e)

• Verkaufsorganisation: @###

• 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 Ver-kaufsorganisation @### anzulegen. Dieser Debitor wird im Buchungskreis1000, für die Verkaufsorganisation @###, dem Vertriebsweg 10 und der Sparte00 mit der Bezeichnung "@###-MAOAM" angelegt. Als Kontengruppe wird"Debitor allgemein" (KUNA) angegeben. Beim Anlegen des Debitors werdendie allgemeinen Daten, die Buchungskreisdaten und die Vertriebsbereichsdatengepflegt. Dabei ist das Abstimmkonto 140000 einzutragen. Ebenso ist darauf zuachten, dass das Auslieferungswerk das Werk @### ist.

Da an diesen Kunden eine Faktura gestellt wird und der Zahlungseingang an-schließend beglichen wird, muss für die neue Verkaufsorganisation @### nochdie Kontenfindung im Customizing eingerichtet werden. Dabei wird der Erlös-kontenfindung ein Sachkonto über den Kontenschlüssel "ERL" zugeordnet. Nunist auch der 2. Teil der multi-user-fähigen Fallstudie abgeschlossen.

Abbildung 16: Teil 2 der multi-user-fähigen Fallstudie

28

4 DIE MULTI-USER-FÄHIGE FALLSTUDIE

4.3 Teil 3 - Kopplung über ALEDie Kommunikation zwischen dem SAP System und dem Hochregallagermodellwird mittels ALE- und EDI-Technologie in loser Kopplung abgewickelt. DieDetails zu den Methoden wurden in Abschnitt 3.3 beschreiben.

Dieser Teil der Fallstudie behandelt die notwendigen Einstellungen bezüg-lich der Kopplung der Kommunikation und ist in zwei Abschnitte unterteilt.Im ersten Abschnitt wird die bidirektionale Kopplung der Transportaufträgeerlä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 TransaktionOMKY vorgenommen, die Einrichtungsschritte umfassen nachfolgendeProzessschritte.Es wird mit der Einrichtung der Schnittstelle zur Lagernummer gestartet.Hierbei wird dem Tabelleneintrag mit der eigenen Lagernummer dieKommunikationsmethode 1 zugewiesen.

Anschließen ist die Steuerung der Schnittstelle zum Subsystem ein-zustellen. Dazu werden für die einzelnen Transportvorgänge, Lagertypenund Bewegungsarten, welche eine Kommunikation zwischen dem SAPSystem 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 Definitionder Funktionsbausteine zum IDoc-Aufbau umzusetzen. Der Tabellenein-trag des eigenen Lagers ist hierzu in der Kopplungssicht auszuwählen undder Funktionsbaustein L_IDOC_CREATE_WMTOID01 einzutragen.

Zum Abschluss der Kopplung der Transportaufträge ist nun noch dieErgebniskopplung über den entsprechenden Menüpunkt zu aktivieren.(Mae13d, S.1-7)

29

4 DIE MULTI-USER-FÄHIGE FALLSTUDIE

Abbildung 18: Kopplung Transportaufträge - ALE

2. Im zweiten Abschnitt werden die Einstellungen für die Bestellungenbeim Lieferanten getroffen. Hierzu wird die im SAP System enthalteneunidirektionale EDI-Schnittstelle zur Kommunikation verwendet. Diesewird mittels der Transaktion NACE eingerichtet. Die Konfiguration istlieferantenbezogen.

Dieser Abschnitt startet mit der Einstellung der Nachrichtenart derKonditionensteuerung. Hierzu werden in der Nachrichtensteuerung dieApplikation EF - Einkauf Bestellung und die Nachrichtenart NEU -Bestelldruck gewählt.

Zu dieser Kombination ist die Nachrichtenfindung Einkaufsorg./Lieferantfür EDI zu verwenden. Dem Konfigurationseintrag dieser drei Parameterwerden anschließend die Einkaufsorganisation sowie der eigene Lieferantzugeordnet.

Abschließend werden im erstellten Konditionssatz die eigenen MAOAMArtikel eingetragen sowie die Kommunikationsparameter gesetzt. (Mae13d,S.8-9)

Abbildung 19: Kopplung Bestellungen - EDI

30

4 DIE MULTI-USER-FÄHIGE FALLSTUDIE

4.4 Teil 4 - Die Prozesse im HochregallagermodellDa hier nun die Durchführung der Prozesse erläutert wird, hat sich im Vergleichzur ursprünglichen Fallstudie kaum etwas geändert. Vor dem Start dieses Teilsder Fallstudie wird nun das berechtigte Werk des zu prüfenden Studenten überdie Transaktion: "ZCUSHRLWerk" eingetragen. Anschließend kann die Fallstudiewie in 2.1 bearbeitet werden. Dabei haben wir die Erstellung der Faktura unddie Rechnungsbegleichung ausführlicher erläutert.Außerdem wurde in jedem Teil der Fallstudie Bildschirmabzüge teilweiseangepasst und Neue hinzugefügt. Nach der Rechnungsbegleichung durch denDebitor ist dieser Teil und somit die komplette multi-user-fähige Fallstudieabgeschlossen. Der erfolgreiche Abschluss der Fallstudie kann entweder in derElektronikwerkstatt durch die erfolgreiche Auslieferung beobachtet werden, oderindem man den Belegfluss der Fallstudie nachverfolgt. Der Buchhaltungsbelegam 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 1-4

2. Die multi-user-fähige Fallstudie Teil 1-4

3. Ein Dokument zur Beschreibung des weiterführenden Customizing:"Customizing für Fallstudie HRL Modell"

31

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 - TechnischeDokumentation. In: Bachelorarbeit - Alexander Maeule TechnischeDokumentation (2013)

[Mae13b] Maeule, Alexander: Fallstudie Hochregallager Modell - Teil 1 - La-ger anlegen. In: Bachelorarbeit - Alexander Maeule Fallstudien zumHochregallagermodell (2013)

[Mae13c] Maeule, Alexander: Fallstudie Hochregallager Modell - Teil 2 - Ma-terial anlegen. In: Bachelorarbeit - Alexander Maeule Fallstudien zumHochregallagermodell (2013)

[Mae13d] Maeule, Alexander: Fallstudie Hochregallager Modell - Teil 3 - Idocerstellung. In: Bachelorarbeit - Alexander Maeule Fallstudien zumHochregallagermodell (2013)

[Mae13e] Maeule, Alexander: Fallstudie Hochregallager Modell - Teil 4 - Lie-ferantenbestellung. In: Bachelorarbeit - Alexander Maeule Fallstudienzum Hochregallagermodell (2013)

[RM10] Roessle, Prof. Dr. Manfred H. ; Mueelich, Sven: CUS02 - Unter-nehmensstruktur DC AA(1.01). In: 57330 SAP Customizing (2010)

[SA14a] SAP-AG: ALE. Version: 2014. http://help.sap.com/saphelp_46c/helpdata/de/18/22b800773211d396b20004ac96334b/content.htm, Abruf: 08.06.2014

[SA14b] SAP-AG: Einkaufsorganisation - Werk zuordnen. Version: 2014.http://help.sap.com/saphelp_46c/helpdata/de/a0/e364b20437d1118b3f0060b03ca329/content.htm, Abruf: 12.06.2014

[SA14c] SAP-AG: Hell-/Dunkelablauf. Version: 2014. http://help.sap.com/saphelp_erp60_sp/helpdata/de/c6/f839ce4afa11d182b90000e829fbfe/content.htm, Abruf: 10.06.2014

[SA14d] SAP-AG: IDoc. Version: 2014. http://help.sap.com/saphelp_46c/helpdata/de/0b/2a60ef507d11d18ee90000e8366fc2/content.htm, Abruf: 01.06.2014

II

Literatur

[SA14e] SAP-AG: Kalkulationsschemata. Version: 2014. http://help.sap.com/saphelp_crmhana/helpdata/de/dd/5616cc545a11d1a7020000e829fd11/content.htm?frameset=/de/dd/56168b545a11d1a7020000e829fd11/frameset.htm, Abruf:12.06.2014

[SA14f] SAP-AG: Konditionen und Preisfindung. Version: 2014.http://help.sap.com/saphelp_470/helpdata/de/64/7836b39c8911d199aa0000e8a5bd28/frameset.htm, Abruf:12.06.2014

[SA14g] SAP-AG: SAP auf einen Blick. Version: 2014. http://www.sap.com/bin/sapcom/de_de/downloadasset.2014-02-feb-01-01.sap-corporate-2014-fact-sheet-de-pdf.bypassReg.html, Ab-ruf: 16.05.2014

[SA14h] SAP-AG: SAP User-Exit. Version: 2014. http://help.sap.com/saphelp_46c/helpdata/de/35/26b334afab52b9e10000009b38f974/content.htm, Abruf: 11.06.2014

[SA14i] SAP-AG: Versandstellen lagerortabhaengig zuordnen. Version: 2014.http://help.sap.com/saphelp_autoid70/helpdata/de/14/227440d76e6e1de10000000a1550b0/content.htm, Abruf: 12.06.2014

III

Abbildungsverzeichnis

Abbildungsverzeichnis1 Das Modell des Hochregellagers . . . . . . . . . . . . . . . . . . . 12 SAP Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23 SAP Zuordnung der Organisationseinheiten . . . . . . . . . . . . 34 Die Übersicht über das Hochregallager-Modell . . . . . . . . . . . 65 Die Ablaufreihenfolge beim Anlegen eines Lagers . . . . . . . . . . 136 Die Ablaufreihenfolge beim Anlegen der Materialien . . . . . . . . 137 Der integrierte Geschäftsprozess über ALE . . . . . . . . . . . . . 148 Der Geschäftsprozess einer Lieferbestellung . . . . . . . . . . . . . 159 Der Geschäftsprozess des Vertriebs . . . . . . . . . . . . . . . . . 1510 SAP Customizing - Baumstruktur (Werk definieren) . . . . . . . . 1711 SAP Customizing - Werk definieren, Tabellenansicht . . . . . . . 1812 SAP Customizing - Werk definieren, Detailansicht eines Werkes . 1813 Kommunikationskopplung: SAP - Hochregallagermodell . . . . . . 2114 Die Unternehmensstruktur . . . . . . . . . . . . . . . . . . . . . . 2515 Teil 1 der multi-user-fähigen Fallstudie . . . . . . . . . . . . . . . 2616 Teil 2 der multi-user-fähigen Fallstudie . . . . . . . . . . . . . . . 2817 Kopplung Fremdsysteme . . . . . . . . . . . . . . . . . . . . . . . 2918 Kopplung Transportaufträge - ALE . . . . . . . . . . . . . . . . . 3019 Kopplung Bestellungen - EDI . . . . . . . . . . . . . . . . . . . . 3020 Die Auslagerung und Auslieferung an den Kunden . . . . . . . . . 31

IV

EIDESSTATTLICHE ERKLÄRUNG

Eidesstattliche ErklärungHiermit versichern wir, die vorliegende Seminararbeit selbstständig und nurunter Verwendung der von uns angegebenen Quellen und Hilfsmittel verfasstzu haben. Sowohl inhaltlich als auch wörtlich entnommene Inhalte wurden alssolche kenntlich gemacht. Die Arbeit hat in dieser oder vergleichbarer Form nochkeinem anderem Prüfungsgremium vorgelegen.

Frank Blaga:

Datum: Unterschrift:

Nicolas Macho:

Datum: Unterschrift:

V