Die Legacy System Migration Workbench (LSMW) ist ein SAP-Tool, das eine effiziente Datenübertragung in SAP-Systeme ermöglicht. Besonders bei der Erstellung komplexer Datensätze, die nicht über die MASS-Transaktion importiert werden können, spielen "LSMW's" eine wichtige Rolle. Zusätzlich sind für die Anwendung dieses Tools keine Programmierkenntnisse erforderlich. Dies macht das Tool für ein breiteres Spektrum von Benutzern interessant.

Der folgende Artikel bespricht LSMW's im Allgemeinen und untersucht die Business Object Method im Detail anhand eines kurzen Beispiels im RE-FX-Modul. Ein Vorteil der LSMW-Transaktion liegt in ihrer Unterteilung in zahlreiche leicht verständliche Schritte. Dies wird in der folgenden Abbildung veranschaulicht.

In diesem Artikel konzentrieren wir uns hauptsächlich auf die Schritte 1-5, da diese die Konfiguration der LSMW umfassen. Die Schritte 7-16 beinhalten das Hochladen und Verarbeiten der Eingabedaten. Diese Schritte müssen immer wiederholt werden, wenn weitere Daten in das System eingespielt werden sollen. Sie können problemlos durchgeführt werden, sofern die Konfiguration der Schritte 1-5 und die Eingabedatei kompatibel sind.

Schritt 1 ist der wichtigste Schritt bei der Erstellung einer LSMW. Die Erklärung dieses Schritts wird ein grundlegendes Verständnis der LSMW's vermitteln. Die verbleibenden Schritte werden am besten anhand eines Beispiels veranschaulicht. Schritt 6 wird in diesem Artikel nicht gezeigt, da er in vielen Fällen nicht erforderlich und relativ komplex ist.

Auswahl der LSMW-Methode (Schritt 1)

Zu Beginn jedes LSMW's muss angegeben werden, welche Felder gefüllt werden sollen. Hierfür gibt es vier verschiedene Möglichkeiten, Standard-Batch/Direct-Input, Batch-Input-Aufzeichnung, Business-Objekt-Methode und IDoc. Das Selektionsbild ist in der folgenden Abbildung dargestellt.

Batch-Input-Aufzeichnung

Die einfachste Methode für die Benutzer ist die Batch-Input-Aufzeichnung. Der Benutzer kann eine geeignete Transaktion verwenden, um die gewünschten Felder zu befüllen. Die Felder werden während der Verwendung der Transaktion im Hintergrund gespeichert. Der Nachteil dieser Methode ist, dass sie nur eingeschränkt nutzbar und fehleranfällig ist. So können z.B. Pop-Ups oder das Wechseln zwischen Tabs innerhalb einer Transaktion unüberwindbare Hindernisse bei der Anwendung dieser Methode darstellen. Auch ist es möglich, dass Felder unbeabsichtigt befüllt werden, da die Analyse der adressierten Felder eine größere technische Herausforderung ist im Vergleich zur Aufzeichnung. Wenn die verwendete Transaktion jedoch simpel strukturiert ist, bietet dieser Ansatz eine einfache Lösung.

Standard-Batch/Direct-Input Methode

Bei der Standard-Batch/Direct-Input-Methode werden die Felder eines Objekts über ein bestehendes Programm befüllt. Der Nachteil dieser Methode ist, dass sie standardmäßig nur für eine begrenzte Anzahl von Anwendungsfällen zur Verfügung steht. Es hängt daher stark von der Problemstellung ab, ob diese Methode einfach zu handhaben ist. Sollen z.B. Finanzdokumente erfasst werden, so ist dies einfach zu realisieren, da fertige Programme zur Verfügung stehen. Andererseits ist diese Methode für Module wie RE-FX weniger geeignet, da viele Aspekte des Moduls durch die verfügbaren Programme nicht abgedeckt werden.

Business Object & Intermediate Document (IDOC) Methode

Im Falle von RE-FX gibt es viele BAPIs, die für die Business-Objekt-Methode und für die Methode Intermediate Document (IDOC) verwendet werden können. BAPIs (Business Application Programming Interfaces) sind standardisierte Schnittstellen, die von SAP bereitgestellt werden, um den Zugriff auf Geschäftsprozesse und Daten zu ermöglichen. Für den Anwender bedeutet dies, daß eine Struktur zur Verfügung steht, die es ermöglicht, bestimmte Felder zu befüllen. Abhängig vom jeweiligen BAPI können auch komplexere Datenobjekte angesprochen und gefüllt werden. Der Nachteil dieser beiden Methoden ist, daß sie relativ komplex sind. Dies bedeutet, daß zunächst eine erhebliche Hürde überwunden werden muß, bevor sie eingesetzt werden können. Ist diese Hürde überwunden, kann das Wissen auch auf andere Anwendungsfälle übertragen werden, da die Anwendung der verschiedenen BAPI's auf analoge Weise funktioniert.

Der Hauptunterschied zwischen der Business-Objekt- und der IDOC-Methode besteht darin, dass die IDOC-Methode ein standardisiertes Dateiformat (Intermediate Document) verwendet. Das Dateiformat des Intermediate Document ist ähnlich aufgebaut wie das XML-Format. Damit das SAP-System dieses Format verarbeiten kann, muß ein Port eingerichtet werden. Dies ist auch notwendig, wenn die Upload-Daten aus einer Excel-Datei stammen. Diese Anforderungen führen dazu, dass die IDOC-Methode tendenziell noch komplizierter ist und Fehler schwieriger zu beheben sind als bei der Business-Objekt-Methode.  Nach der Definition der Felder, die mit einer der oben genannten Methoden gefüllt werden sollen, müssen die Daten aus der Upload-Datei auf diese SAP-Felder abgebildet werden. Dies geschieht in mehreren Teilschritten, die im nächsten Abschnitt erläutert werden.

Anwendungsbeispiel

In unserem speziellen Anwendungsfall möchten wir Abrechnungseinheiten mit Hilfe des BAPIs "BUS1506_CREATE" anlegen. Die folgende Abbildung zeigt die Auswahl des BAPIs.

Abrechnungseinheiten sind ein wichtiger Bestandteil der Nebenkostenabrechnung im Modul RE-FX. Sie dienen als Gefässe, um die Kosten entweder auf weitere Abrechnungseinheiten oder auf Mietobjekte umzuverteilen.

Die Daten der Abrechnungseinheiten im RE-FX-Modul sind in verschiedene Register aufgeteilt (siehe Transaktion: RESCSU). Mit dem BAPI "BUS1506_CREATE" kann jedes dieser Register einzeln angesteuert werden. Jedes Register selbst enthält bestimmte Felder, die über die Funktion "Objektübersicht" aus dem LSMW-Guide eingesehen werden können. Die Schaltfläche ist in der folgenden Abbildung in Rot hervorgehoben.              

Die nächste Abbildung unten zeigt die Objektübersicht.  Die Spalte "Struktur" enthält einen Eintrag für jedes Register der Abrechnungseinheit. Die Felder, die ausgefüllt werden können, sind in der Spalte "Zielfeldname" aufgeführt.

Benutzer, die mit der Erstellung einer Abrechnungseinheit vertraut sind, werden diese Struktur sofort erkennen. Je nachdem, wie die Abrechnungseinheiten angelegt werden sollen, müssen bestimmte Felder ausgewählt und auf die Eingabedaten gemapt werden.

Quellstruktur pflegen (step 2)

In diesem Arbeitsschritt müssen Sie festlegen, wie die Quellstrukturen aufgebaut sind. Die Quellstrukturen entsprechen den Registerkarten aus der Spalte "Struktur" in der Objektübersicht. In unserem Fall muß hier eine Hierarchie aufgebaut werden, da es beim Anlegen von Abrechnungseinheiten zur Verschachtelung kommen kann. Wir definieren einen Header, der die Grunddaten (Buchungskreis, Wirtschaftseinheit, Nebenkostenschlüssel und Abrechnungseinheitennummer) enthält. Darüber hinaus weitere untergeordnete Dateien, die Daten für jedes spezifische Register der Abrechnungseinheit enthalten. In diesem Fall wollen wir neben dem Kopf auch die Register Basisdaten (E1BP_RE_SETTL_UNIT_DAT), Teilnahmegruppe (E1BP_RE_PARTICIP_REL_DAT) und Aufteilungsregel (E1BP_RE_APPORT_RULE_DAT) füllen. Welche Register zu füllen sind, hängt vom Anwendungsfall ab. Bestimmte Register müssen jedoch immer gefüllt werden und es bestehen Abhängigkeiten zwischen einigen von ihnen. Die Quellstrukturen unseres Beispiels sind in der folgenden Abbildung zu sehen.

Quellfelder pflegen (step 3)

In diesem Schritt werden die Felder der einzelnen Dateien (Quellstrukturen) definiert. Dies sind alle Felder, die aus einer externen Quelle in das System eingegeben werden. In Schritt 5 gibt es weitere Möglichkeiten, Felder, die nicht aus einer externen Quelle stammen, z.B. über Konstanten zu füllen. Die gewünschten Felder können der Spalte "Zielfeldname" in der Objektübersicht entnommen werden. Um die verschiedenen Register/Quellstrukturen korrekt zu verknüpfen, ist es notwendig, eine Mapping-Variable zu definieren. Diese Mapping-Variable sorgt dafür, dass die in Schritt 2 beschriebene Hierarchie gewährleistet werden kann. Die Mapping-Variable verknüpft z.B. die richtige Umlageregel mit dem richtigen Header. Auf der Registerkarte Teilnahmegruppe ermöglicht es diese Mapping-Variable, mehrere Teilnahmegruppen mit einer Abrechnungseinheit zu verknüpfen (1:N-Beziehung). Alle ausgewählten Felder sind in der folgenden Abbildung zu sehen.         

Strukturbeziehungen pflegen (step 4)

In diesem Schritt müssen die Eingabedateien (Quellstrukturen) aus Schritt 2 der Struktur aus der Objektübersicht zugeordnet werden.

Fieldmapping und Regelwerk pflegen (step 5)  

Dieser Schritt ist mit einem erheblichen Aufwand verbunden. Hier legen Sie fest, welche SAP-Felder durch die in Schritt 3 definierten Felder aus den Eingabedateien (Quellfelder) gefüllt werden sollen. Soll ein Feld nicht mit Daten aus der Eingabedatei gefüllt werden, kann dies auch über eine Konstante geschehen. Dies ist sinnvoll, wenn ein Feld immer wieder den gleichen Wert enthält.

Files (step 7)

In diesem Schritt werden die externen Daten bestimmt, die in das SAP-System importiert werden sollen. In unserem Beispiel geschieht dies durch das Hochladen von 4 .txt-Dateien. Die folgenden Bilder veranschaulichen, wie der Inhalt aussehen könnte.

In diesem Beispiel erstellen wir die beiden Abrechnungseinheiten 1000 (Mapping-Variable=1) und 1001 (Mapping-Variable=2). Beide Abrechnungseinheiten würden der Umlageregel ZZ01 zugewiesen. Die Abrechnungseinheit 1000 ist den Teilnahmegruppen 1 und 2 zugeordnet. Die Abrechnungseinheit 1001 ist den Teilnahmegruppen 3, 4 und 5 zugeordnet.

Files zuweisen (step 8-16)  

In Schritt 8 müssen die Eingabedateien nun den zuvor in Schritt 2 definierten Quellstrukturen zugeordnet werden. Die Zuordnung für unser Beispiel ist im Bild unten zu sehen.

Wir werden die Schritte 9-16 hier nicht im Detail erklären, da sie hauptsächlich die Datenverarbeitung betreffen. Diese Schritte sind hilfreich, um Fehler zu erkennen und deren Ursachen zu bestimmen. Es wird empfohlen, die Daten während dieses Prozesses sorgfältig zu überprüfen. Nach der Durchführung dieser letzten Schritte werden die Abrechnungseinheiten erfolgreich im System erstellt.

Fazit

Die Anwendung von LSMW's ist nicht immer einfach, aber sie ermöglichen es den Nutzern enorme Datenmengen zu handhaben. Durch die Verwendung des BAPI "BUS1506_CREATE", wie im Beispiel gezeigt, kann die Erstellung eines wichtigen Objekts des RE-FX-Moduls ohne Programmierkenntnisse automatisiert werden.