admin

 

Der SAP-Report RSLANG20 ist dann hilfreich, wenn neue oder korrigierte Übersetzungen zwar im Objekt angekommen sind (Test hierfür ist z.B. der Aufruf des zugrundeliegenden DTEL in der SE63), aber nicht im Dynpro angezeigt wird.

RSLANG20 kann dann genutzt werden, um alle Dynpros einer Sprache mittels der Zusatzeinstellung „Force Mode“ neu zu generieren. Auf E/I-Systemen bedarf es dafür meist keiner Sonderrechte.

1. Transaktion SE38 aufrufen.
2. „RSLANG20“ eingeben und ausführen.
3. Sprache(n) wählen.
4. Einstellung „Force-Modus“ aktivieren.
5. Ausführen.

Erfahrungsgemäß treten Dynpro-Aktualisierungsprobleme auf P sehr selten, aber durchaus häufiger auf Q auf. Dort ist für das Ausführen dieses Reports dann ein Firefighter notwendig.

Die ausführliche SAP Note findet sich bei:
http://www.se63.info/110910-deleting-the-language-load/

Alternativ kann auch in der SE80 im Entwicklungspaket beim einzelnen Dynpro über einen Rechtsklick im Kontextmenü der Punkt „Aktivieren“ gewählt werden, dies aktualisiert dieses Dynpro.

Share

SQL-Abfragen in Dragoman nutzen

 SAP, Übersetzung  Kommentare deaktiviert für SQL-Abfragen in Dragoman nutzen
Jul 042017
 

Es gibt in Dragoman die Möglichkeit, ein SQL-Statement für die Filterung von Tabelleneinträgen zu nutzen. Dies ist z.B. besonders sinnvoll, wenn die Tabelle sowohl SAP- als auch kundenspezifische Einträge enthält. Diese sind durch die führenden Buchstaben X, Y oder Z kenntlich (abhängig vom Projekt).

Wenn man in einem Dragoman-Szenario eine Tabelle einfügt, wird diese immer komplett ausgewertet. Bei einem Sprachtransport würden ebenfalls alle Zeilen transportiert werden. Über die SQL-Filter kann dies bis herunter auf einzelne Einträge eingeschränkt werden.

Ohne Filterung:

  • 15.000 Zeilen in der Tabelle = im Szenario und damit im Sprachtransport

Nach Filterung auf kundenspezifische Einträge:

  • 3.000 Zeilen im Szenario und damit im Sprachtransport

Nach Filterung auf den bekannten Namen von Einträgen, z.B. ZMNADR*:

  • 5 Zeilen im Szenario und damit im Sprachtransport

Nach spezifischer Filterung auf den bekannten Namen eines Eintrags, z.B. ZMNADR3:

  • 1 Zeile im Szenario und damit im Sprachtransport

Feldnamen für Filter ermitteln

Für den SQL-Filter sind die Feldnamen (DTEL-Objekte) sowie die Filterkriterien (z.B. der Inhalt startet mit „ZMNA*“) notwendig, auf die gefiltert werden kann.

Diese können am einfachsten über die SE16 ermittelt werden.

  1. SE16 aufrufen
  2. Tabelle eingeben.
  3. Vorhandene Felder prüfen, mit den Filtermöglichkeiten experimentieren und die Ergebnisse anzeigen lassen.
  4. Wenn das richtige Feld und Filter identifiziert sind, können diese in Dragoman übertragen werden.

SQL-Statements zusammenstellen

Prinzipiell wird ein FELD (aka eine Spalte) nach einem Inhalt durchsucht und dahingehend gefiltert.

FELD = 'ZMNADR3′        (gleich)

FELD <> 'ZMNADR3′    (ungleich)

FELD Like 'ZMNA%‘      (Feldinhalt beginnt mit ZMNA; das % entspricht einem * in SAP)

FELD Not Like 'ZMNA%‘   (Feldinhalt beginnt nicht mit ZMNA)

Kombinationen:

FELD = 'V2′ AND FELD2 like 'ZMNA%‘    (AND: beide Bedingungen müssen erfüllt sein)

FELD = 'V2′ OR FELD2 like 'ZMNA%‘   (OR: eine von beiden Bedingungen muss erfüllt sein)

 

SQL-Syntax in Dragoman eingeben

Die Eingabe des Filters kann im Dragoman über zwei Wege erfolgen:

  • Konfiguration > Texttabellen > Bearbeiten -> in der Bearbeitungssicht werden die SQL-Abfragen angezeigt
  • Szenariodefinition > Texttabellen

Link zur Dragoman-Dokumentation für SQL-Queries

Bei einer langen Liste von Tabellen, die z.B. mandantenabhängig gefiltert werden sollen, muss die SQL-Abfrage bei jeder Tabelle einzeln eingegeben werden.

Nach Eingabe des SQL-Filters sollte mit einer Vollanalyse und über den Vergleich mit dem Filterergebnis aus der SE16 geprüft werden, dass die richtigen Einträge gefunden wurden.

Danach kann in Dragoman wie üblich übersetzt und transportiert werden.

Als letzter Check kann in der SE09/SE10 noch der Transport geprüft werden. Auch dieser sollte nur die Einträge enthalten, die das SQL-Statement geliefert hat.

Share

Tabellen übersetzen in SAP

 SAP, Übersetzung  Kommentare deaktiviert für Tabellen übersetzen in SAP
Jul 032017
 

Beim Übersetzen von Tabellen in SAP gibt es zwei mögliche Aspekte:

Kundenspezifische Felder (Spalten) der Tabelle

Die Tabelle wurde um kundenspezifische Felder erweitert, z.B. ZMMX_E_VERFALL. (Kundenspezifische Objekte beginnen üblicherweise mit X*, Y* oder Z*, abhängig vom Projekt.)

Analyse:

  1. SE11 aufrufen.
  2. Tabelle eingeben und „Anzeigen“.
  3. Struktur der Tabelle prüfen.
  4. Bei vorhandenem Datenelement mit Z*** Doppelklick auf das Feld, um das Objekt (vom Typ DTEL) zu öffnen.
  5. Über Springen > Übersetzung in die SE63 verzweigen und prüfen, wie der Übersetzungsstand ist.

Hier kann direkt übersetzt werden. Alternativ kann im Dragoman das Objekt in ein Dragoman-Szenario eingefügt werden über Konfiguration > Objektliste.

Übersetzungsrelevante Inhalte in der Tabelle

Die Tabelle selbst kann übersetzungsrelevante Inhalte haben. Dies kann man daran erkennen, dass es ein Feld SPRAS oder LANGU (beide vom Typ LANG) geben muss. Diese enthalten die Sprachkürzel.

Analyse:

  1. SE11 aufrufen.
  2. Tabelle eingeben.
  3. Struktur der Tabelle prüfen. Bei vorhandenem Feld SPRAS oder LANGU beinhaltet die Tabelle übersetzungsrelevante Inhalte.

Übersetzungsrelevante Tabelleneinträge können über die SE63 > Kurztexte > TABL übersetzt werden oder im Dragoman über Szenario > Konfiguration > Texttabellen.

Share

Mehrere Quelldokumentationen sinnvoll in Zieldokumentation überführen

 Dokumentation, Tutorials  Kommentare deaktiviert für Mehrere Quelldokumentationen sinnvoll in Zieldokumentation überführen
Jan 132017
 

Eine häufige Ausgangssituation:

Dokumentation

  • aus zwei oder mehr Quellen
  • mit unterschiedlichen Strukturen
  • mit unterschiedlichen Inhalten
  • mit unterschiedlicher Tiefe an Inhalt

soll vereinheitlicht werden zu einer Zieldokumentation (meist in einem neuen Dokusystem), die alle aktuellen Inhalte abbilden soll.

Typischer Fehler, der an dieser Stelle  gemacht wird: „Wenn wir schon dran sind, vereinheitlichen wir jetzt alle Dokumente auf denselben neuen Stil!“

Meine Erfahrung: Dieser Ansatz führt dazu, dass alle vorhandene Dokumentation als „veraltet“ wahrgenommen und ein riesiger Arbeitsberg generiert wird, bei dem nach 20% dem Projekt die Puste ausgeht, weil das nächste dringende Projekt kommt.

Ein sinnvoller Ablauf (praxiserprobt für interne IT-Dokumentation; es war keine Rechtssicherheit notwendig):

1. Was genau liegt an Dokumenten vor? Dies erzeugt  eine lange und sehr wichtige Masterliste, z.B. in Excel. Hier gehören alle Infos rein:

  • Quellinfo: Laufende Nummer, Link in Dokusystem/Ordersystem/Sharepoint etc., Titel, Ansprechpartner, Größe des Dokument, Quellformat (bei mehreren vorhandenen Formaten), Qualitätsstatus (aktuell, nicht aktuell etc.).
  • Zielinfo: Status „Soll überführt werden“ (sonst Archivieren!), Status „Ist überführt“, Link im Zielsystem, ggf. neuer Titel, ggf. neues Format

Die Vollständigkeit der Liste ist entscheidend für jegliche Aussage über Aufwände und Fortschritt! Ohne eine klare Definition des Ausgangszustandes sind alle Aussagen zur Zielerreichung nur eine Schätzung/Hoffnung!

2. Den optimalen Zielzustand formulieren. Dies beinhaltet

  • das Format der Doku (alles von Copy&Paste bis stundenlanger Umarbeitung), ggf. von Hilfskräften durchführbar.
  • gewünschte Informationen und Tiefe der Informationen – dies führt potentiell zu sehr viel Arbeit bei den Sachexperten!

3. Mit einigen der ausgewählten Dokumente verschiedener Quellformate ein „Rapid Prototyping“ betreiben, d.h. einen Testlauf mit Zeitnahme (!), wie lange eine Umarbeitung in den 100% gewünschten Zustand dauert.

4. Dies mit einem Faktor von 2-3 auf die Dokumentation hochrechnen, die umgezogen werden soll.

5. Abgleichen mit dem gewünschten Endtermin des Projekts (z.B. Abschalttermin von Altsystemen) und den eingeplanten Personen und ihrer realistischen(!) Arbeitsstunden im Projekt.

An diesem Punkt stellt man meist fest, dass das Projekt so nicht machbar ist. Dokumentation umarbeitet kostet viel Zeit, diese wird immer unterschätzt.

6. Den machbaren Zielzustand definieren. Dies erfordert Abstriche an der Wunschliste, die in Punkt 2 formuliert wurde. Oft ist der Punkt „vollständige Dokumentation“ kritisch. Hier besser ein unvollständiges aktuelles Dokument umziehen und später ergänzen, als sich in der Datensammlung aufzuhalten (außer, es ist rechtlich kritische Dokumentation). Auch der Umbau der Formate sollte auf den kleinsten wirklich notwendigen Aufwand gekürzt werden.

7. Eine ausführliche Arbeitsanweisung für den Umzug der Dokumente erstellen, damit alle Schritte ausformuliert und festgehalten sind. Bei Quellformaten mit klaren Strukturen können hier oft Schritte automatisiert werden, z.B. mit VBA-Makros in Word.

8. Mit der Verarbeitung der Quelldokumente beginnen und – wichtig! – Soll-Prozess mit Ist-Prozess abgleichen! Wie lange dauert die Umarbeitung wirklich? Ist der Fortschritt wie geplant?
Erfahrungsgemäß muss eine Automatisierung immer wieder für Fälle erweitert werden, die im ursprünglichen Testset nicht erfasst waren.

Auch  ein Dokumentenumzug unterliegt der 80-20 Regel: 80% der Dokumente machen wenig Aufwand, 20% viel. Dokumente, die Probleme erzeugen, beiseite legen und in der Excel-Masterliste vermerken, damit sie mit etwas mehr Ruhe nachbearbeitet werden können. Etwas für regnerische Freitagnachmittage oder lange Zugfahrten.

Archivieren oder Löschen?

  • Nur wirklich obsolete oder doppelt vorhandene Dokumente sollten gelöscht werden.
  • Archivierte Dokumente sollten noch mindestens 2 Jahre im Zugriff sein. Erfahrungsgemäß muss immer wieder darauf zugegriffen werden, z.B. weil beim Umzug Inhalte verloren gingen oder sich Dokumente nachträglich als doch wichtig herausstellen. Für optimale Durchsuchbarkeit ist ein Ablegen von Word-oder PDF-Snapshots der Quelldateien in einem ganz normalen Ordnersystem hilfreich. Für datenbankbasierte Dokusysteme sollte zwei Jahre ein read-only Zugriff möglich sein. Motto: „Dateien fressen kein Brot. Archivieren ist billiger als neu Schreiben“.

Abschließender Tipp

Hier am Ende möchte ich nochmals betonen, dass ein genauer Überblick über die Dokumentation zum Startpunkt des Umzugs lebenswichtig ist. Dieser Überblick sollte an einer einzigen Stelle vorhanden sein (nicht verteilt über mehrere Systeme), und idealerweise von 1-2 Personen gepflegt sowie von allen Personen im Projekt gelesen werden können.

Mit einer Excel-Masterliste bin ich damals perfekt gefahren. Excel wird gerne kritisiert, dabei hat es auch viele Vorteile:

  • in jeder Firma vorhanden (jedenfalls in jeder, in der ich in 17 Jahren unterwegs war)
  • fast jeder kann die Kernfunktionen schon bedienen oder schnell geschult werden
  • sehr gute und schnelle Filtermöglichkeiten
  • sehr gut mit VBA automatisierbar
  • jederzeit schnell ein Backup in ein ZIP schreibbar

Soweit zum Thema Dateiumzug. Die ebenfalls große Frage „Und wie wird das dann alles zukünftig aktualisiert?“ behandle ich in einem zukünftigen Blogbeitrag.

Share

Wichtigste Schnittstellen beim Übersetzen mit SNP Dragoman

 Business, SAP, Übersetzung  Kommentare deaktiviert für Wichtigste Schnittstellen beim Übersetzen mit SNP Dragoman
Jan 092017
 

Beim Übersetzen mit SNP Dragoman ist die Technik (aka die Verwendung von Dragoman) meist das kleinere Problem, wenn man einige grundlegende Ansätze – wie das Thema Vorschlagswerte und deren Befüllung – verstanden hat.

Die Schnittstelle zu Übersetzungsfirmen wird über die ausgeleiteten Excels abgebildet. Hier gibt es typischerweise folgende Probleme:

  • Das eigenartige Excel-Format (.xls, Format „XML Kalkulationblatt“) führt beim Öffnen beim Empfänger zu einer Meldung, die extra bestätigt werden muss. Dies kann über ein Speichern als echtes .xls geändert werden, muss aber vor dem Import wieder korrigiert werden. Dazu das Excel unter „XML Kalkulationsblatt“ speichern und die Endung im Explorer auf .xls ändern.
  • Bei der Verarbeitung kann es dazu kommen, dass die maximale Länge überschritten wird. Dies muss vor dem Import geprüft werden, bzw. nach erfolglosem Import muss die von Dragoman angemerkte überlange Zeile korrigiert werden.

Eine andere große Schnittstelle ist die mit der SAP Basis. Da SAP-Übersetzungen transportiert werden müssen, sind sie Teil des Transportwesens und unterliegen den in der Firma gelebten Prozessen. Folgende zwei Strategien sind üblich:

  • Übersetzungstransporte hängen an der Anforderung der jeweiligen Entwicklung und werden vom Anforderer selbst freigegeben und weiterbehandelt. Dies ist transporttechnisch die einfachste Strategie, führt allerdings in Dragoman zu vielen kleinen Szenarien. Für den Überblick sollten immer auch zusätzlich regelmäßig Analysen über Module gefahren werden.
  • Übersetzungen gelten als eigene Anforderungen, die Übersetzungen werden übergreifend über alle Module und ungeachtet der spezifischen Entwicklungen darin durchgeführt. Das Übersetzungsteam muss dabei analog zu jedem Entwickler den ganzen Zyklus einer Anforderungs-ID mitmachen. Dies führt zu Mehraufwänden und wird leicht problematisch, wenn das Übersetzungsteam nicht automatisch alle Entwicklungsinfos wie z.B. GoLive-Termine erhält. Außerdem kann durch die Entkopplung von Entwicklung und ihrer Übersetzung nicht immer nachvollzogen werden, wer zuständig ist (siehe nächsten Punkt).

Die dritte Schnittstelle ist die zur Entwicklung / den SAP-Teams, wenn es darum geht, fehlende Übersetzungen aufzuspüren. Typische Probleme:

  • Kein Entwickler zur Unterstützung der Analyse vorhanden. Fehlende SAP-Übersetzungen analysieren erfordert schon SAP-Kenntnisse. Dennoch kann es notwendig sein, für schwierige Fälle einen Entwickler mit der Analyse zu betreuen. Hier muss dem Auftraggeber klargemacht werden, dass hier ein gewisser Bedarf besteht, ca. 1-2 Stunden/Woche.
  • Bei analysiertem, aber für die Übersetzung unlösbaren Problem: Kein definiertes Team vorhanden, d.h. kein dezidierter Ansprechpartner z.B. für ein Modul greifbar. Manchmal hilft hier, Probleme solange auszusitzen, bis das Thema nach oben eskaliert und sich jemand auf der Entwicklungsseite dafür zuständig fühlt, das Problem anzugehen.

Die hier genannten Schnittstellenthemen sind besonders bei der Schätzung des Zeitaufwands von Übersetzungen wichtig, da hier sehr schnell viel Zeit vertreichen kann.

Share

Mehrzeilige Texte in SNP Dragoman

 SAP  Kommentare deaktiviert für Mehrzeilige Texte in SNP Dragoman
Dez 152016
 

Mehrzeilige Texte können in SNP Dragoman in zwei Varianten auftreten:

  • Multiline-Texte („Langtexte“ in SAP): Langtextobjekte wie z.B. DOCU für F1-Hilfen, die in einer gesonderten Datei mit dem Namenszusatz „_ML“ ausgegeben werden.
  • Mehrzeilige Kurztexte: Kurztexte, deren Text auf mehrere Zeilen verteilt ist.

Problem der mehrzeiligen Kurztexte

Normalerweise werden Kurztexte alphabetisch ausgegeben. Bei einem mehrzeiligen Kurztext enden die Textteile daher verteilt im Excel, was für die Übersetzung problematisch sein kann.

Zerlegter Beispielsatz in alphabetischer Sortierung:

  • ggf. mit dem Einbauort aus dem Equipment
  • Soll der Technische Platz
  • überschrieben werden?

Diese Zeilen 1:1 zu übersetzen führt zu einem sehr missverständlichen Ergebnis.

Mehrfachsortierung in Excel

Durch eine Mehrfachsortierung in Excel ist es möglich, solche verteilten Kurztextzeilen zu finden:

Excel-Einstellung „Sortieren und Filtern“ -> „Benutzerdefiniertes Sortieren“:

  1. aufsteigend nach Obj_Name
  2. aufsteigend nach Object
  3. aufsteigend nach Object_Name_3

Das Ergebnis ist der korrekt sortierte Satz, der dann passend (aber auch hier nicht zeilenweise 1:1) übersetzt werden kann.

Soll der technische Platz Should the funct.loc.
ggf. mit dem Einbauort aus dem Equipment possibly be overwritten with inst.loc.
überschrieben werden? of the equipment?
Share

Troubleshooting: Objekte können nicht in SNP Dragoman gefunden werden

 SAP  Kommentare deaktiviert für Troubleshooting: Objekte können nicht in SNP Dragoman gefunden werden
Dez 122016
 

Der Ausgangspunkt: Übersetzungen in der SAP-Oberfläche fehlen und sollen mit SNP Dragoman korrigiert werden. Doch die Objekte können in Dragoman nicht gefunden werden.

Mögliche Ursachen in SAP:

  • Hardkodierte Texte in der Programmierung: für Analyse und Korrektur Entwickler notwendig
  • Oberflächentexte werden aus z.B. einer Tabelle gezogen: für Analyse Entwickler oder Berater notwendig, Korrektur über Szenario mit der Tabelle darin

Mögliche Ursachen in Dragoman:

  • Falsches Entwicklungspaket im Blick, Texte werden aus anderem Modul gezogen: Prüfung über alle Entwicklungspakete
  • Analyse wird über „Anwendertexte“ gefahren, aber der Text wird von Dragoman als „technischer Text“ bewertet: Szenarioeinstellung anpassen und neue Vollanalyse starten
  • Szenario wurde über einzelne Objekte erstellt, aber das gesuchte Objekt ist noch nicht im Szenario: dies erfordert ein komplexeres Vorgehen.
    Beispiel fehlende Objekte in BW: Gesuchter Quelltext ist ABC, einziges bekanntes ELEM ist 123.
  1. Für die Start-Analyse wird ein sehr übergreifendes Szenario benötigt, beispielsweise über alle gelaufenen Transporte (von BW-Team erfragen).
  2. Über dieses Szenario eine Vollanalyse mit den Einstellungen „Alle Texte“ und „Verwendungsnachweis“ laufen lassen.
  3. Den Text ABC suchen und den Verwendungsnachweis aufrufen. Dieser liefert ELEM 123, ELEM 324, ELEM 654 und IOB 1XZ.
  4. Im Einzelszenario alle vier Objekte hinzufügen und die Vollanalyse laufen lassen. Sehr wahrscheinlich tauchen die fehlenden Objekte hier auf.

 

Share

Was ist SAP Fiori?

 Sammelsurium  Kommentare deaktiviert für Was ist SAP Fiori?
Mrz 312016
 

SAP Fiori ist eine Möglichkeit, auf SAP aufsetzende Apps zu entwickeln, mit deren Hilfe sich definieret Prozesse in SAP durchführen lassen. Diese Prozesse müssen im SAP-Backend korrekt funktionieren, die Fiori-App setzt auf dem Backend auf. Es wird SAP HANA als Grundlage empfohlen.

In der Ausgabe basiert Fiori auf OpenUI5, einer von SAP mit-unterstützten Open-Source-JavaScript-Bibliothek.

Unter dem Link können Sie eine Fiori-Ausgabe sehen:
https://www.sapfioritrial.com/

Schöner Einführungsartikel zum Thema:
https://www.linkedin.com/pulse/20140608082721-29503826-sap-fiori-implementation-starter-guidlines

Die Dokumentation zu drei Standard-Apps finden Sie hier:
http://scn.sap.com/community/fiori/blog/2015/03/31/fiori-reference-apps-technical-documents

Eine ausführliche Anleitung zur Erweiterung der Standard-App gibt es hier:
https://de.scribd.com/doc/294681429/4/Technical-Background

Wie zu sehen, benötigt SAP Fiori sowohl Kenntnisse in SAP als auch in GUI-Design.
Nach einigen schmerzhaften Erfahrungen in großen Firmen kann ich nur hoffen, dass heutzutage auch fähige UX-Designer für die Apps genutzt werden – und nicht nur Junior-SAP-Berater ;)

Share

SAP-Oberfläche übersetzen mit der SE63

 SAP, Übersetzung  Kommentare deaktiviert für SAP-Oberfläche übersetzen mit der SE63
Mrz 292016
 

Die Übersetzung der Oberfläche läuft üblicherweise in zwei Schritten:

  • Übersetzung im Entwicklungssystem mit der SE63 durchführen
  • Vorgenommene Übersetzung mit der SLXT in einen Übersetzungsstransport schreiben

Tipp: Die SE63 ist für die schnelle Übersetzung von Objekten gedacht. Wenn Sie in SAP komplette Pakete für die Übersetzung schnüren wollen, nutzen Sie die Transaktion LXE_MASTER zum Einrichten und Verwalten der Übersetzungsumgebung.

Im Folgenden liegt der Fokus auf Kurztexten.

Übersetzungen mit der SE63 durchführen
Mit der Transaktion SE63 können direkt Objekte übersetzt werden. Der große Nachteil der SE63 ist, dass man sehr gut wissen muss, was man übersetzen will. (Hierfür ist die Auswertung mit SNP Dragoman sehr geeignet, wie ich in einem zukünftigen Beitrag beschreibe.)

Schon die Auswahl nur über Kurztexte und dort Oberflächentexte zeigt die große Vielfalt an Übersetzungsobjekten in SAP. Ohne die Kenntnis von Objekttyp und technischem Namen kann die Übersetzung nicht durchgeführt werden.
se63_1

se63_2 se63_3

Die SE63 kann allerdings auch direkt z.B. aus der SE80 über ein Enwicklungspaket angesprungen werden.
Dazu das Entwicklungspaket aufrufen, z.B. einen Dynpro auswählen und Springen > Übersetzung aufrufen.

se63_über_se80

Eine weitere Aufrufsvariante ist, in der SE10 einen Transport aufzurufen, in einzelne Objekte des Transports zu springen und dann wieder über Springen > Übersetzung zu gehen.

Im Folgenden sehen Sie, wie eine zu übersetzende Zeile dargestellt wird. In der Titelzeile steht das aufgerufene Objekt. Es kann direkt in die freie Zeile geschrieben werden. Mit einem Doppelklick können Sie direkt den Text von oben (oder unten, wenn es einen englischen Vorschlag gibt) in die freie Zeile kopieren und dort bearbeiten.
se63_über_se80_2

Danach die Übersetzung speichern.

Übersetzungen mit der Transaktion SLXT transportieren

Nach der Übersetzung muss für die Objekte manuell ein Übersetzungstransport angelegt werden. Dies machen Sie mit der Transaktion SLXT. Geben Sie dort an, welche Übersetzungen transportiert werden sollen, z.B. alle, die Sie am heutigen Tag in Entwicklungspaket X durchgeführt haben. Wählen Sie „Workbenchauftrag“ und beachten Sie bei der Benennung des Transport die bei Ihnen gültigen Transportrichtlinien.

Transaktion SLXT zur SE63

Weiterführende Links:

SAP-Dokumentation zur SE63

SAP-Dokumentation zur SLXT

SAP-Dokumentation zur LXE_Master

Share

SAP-Dokumentation und SAP-Übersetzung

 Dokumentation, SAP, Übersetzung  Kommentare deaktiviert für SAP-Dokumentation und SAP-Übersetzung
Mrz 242016
 

Seit einigen Jahren habe ich in Kundenprojekten viel Erfahrung mit Lösungen rund um SAP-Dokumentation und -Übersetzung gesammelt und biete dieses Thema jetzt explizit an.

Warum ist SAP so ein spezieller Bereich? Hier einige Gründe:

SAP-Dokumentation

  • Hinter dem Kürzel SAP stecken sehr viele unterschiedliche Module, die mehr oder weniger vernetzt sind. Eine SAP-Dokumentation ist damit eigentlich immer eine Modul-Dokumentation.
  • Die Standardfunktionen der Module sind dabei durch kundenspezifische Erweiterungen angereichert. Der übliche Anspruch einer „vollständigen“ Dokumentation ist weder möglich noch erstrebenswert – es geht immer um Dokumentation spezifischer Prozesse. Ohne die SAP-Experten geht dies leider nicht. Ein wildes Testen der Oberfläche wie bei kleineren Software-Paketen ist unmöglich.
  • Durch die Prozessorientierung sind Anwenderdokumentationen oft Klick-Anleitungen, die durch wichtige, kundenspezifische Informationen ergänzt werden müssen.
  • Auf der Entwicklungsseite ist es wichtig, in den Dokumentationen sowohl die betriebswirtschaftliche Seite als auch die betroffenen Transaktionen, Rollen, Tabellen, Programme, Funktionen, User Exits, Prüfungen usw. zu beschreiben. Auch hier muss vorsichtig abgegrenzt werden, was Standard und was Erweiterung ist.

SAP-Übersetzungen

  • SAP hat eine sehr eigene Terminologie, die sich auch in den englischen Übersetzungen auswirkt.
    Dazu kommt oft firmeninterne Terminologie, die sich auch von Modul zu Modul bzw. Bereich zu Bereich unterscheiden kann.
  • Bei der Übersetzung von SAP-Oberflächen gibt es mehrere Möglichkeiten. Die Oberflächen können beispielsweise direkt im System übersetzt werden mit der SE63 oder über Objekte (dies erfordert Systemzugriff für die Übersetzer), oder alternativ können Tools wie SNP Dragoman verwendet werden, um die Inhalte als Excel zu liefern und sie an Übersetzungsdienstleister herauszugeben.
  • In problematischen Fällen muss auch eine Transportanalyse bzw. eine Suche in älteren Transporten über SE10 > „Objekt in Transport“ durchgeführt werden. Andersherum können Transporte von Objekten rein dafür geschnürt werden, dass diese handlicher übersetzt werden können.
  • Bei Erweiterung eines SAP-Systems auf weitere Sprachen ist es wichtig, mittels Scoping etwas einzugrenzen, welche Bereich tatsächlich übersetzt werden müssen. Dabei kann sich allerdings durchaus ergeben, dass das „Auseinanderfieseln“ der relevanten Entwicklungspakete zeitaufwendiger ist, als die kompletten SAP-Oberflächentexte auszuleiten und sie in die Übersetzung zu geben.

Viele dieser Themen werden hier im Blog in den nächsten Monaten ausführlicher diskutiert.

Share
© 2012 Doku-Hotline Suffusion theme by Sayontan Sinha