Textsymbole einer Reports exportieren?

Textsymbole einer Reports exportieren?

Hallo Zusammen,

gibt es eine Möglichkeit, Textsymbole eines Reports zu exportieren, damit ich diese dann in einem anderen System in das selbe Programm wieder importieren kann?

Gruss
kpas

Genau das möchte ich nicht! Möchte nicht immer das Programm transportieren wenn ich ein neues Textsymbol angelegt habe. Wir haben zwei SAP-Systeme, Retail und DIMP. Das Programm wurde Retail angelegt, jedoch bin ich momentan im DIMP am testen.

Damit ich das Programm nicht jedes mal transportieren muss editiere ich es im Retail, lade es auf meine Fesplatte und importiere es wieder im DIMP System.

Nun frage ich mich ob es eine solche Möglichkeit auch gibt, ohne das Transportwesen zu benutzen.

Ich könnte ja auch einfach das Originalsystem in der TAB TADIR ändern, möchte ich aber nicht! schaue mich noch nach ner anderen Möglichkeit um!

Gruss
kpas

Anonymous hat geschrieben:Genau das möchte ich nicht!
...

Dann schreib das bitte auch gleich so.

PS:
mir ist dann nur noch die Copy&Paste-Methode bekannt.

Hallo Kpas und Frank,

wir haben uns bereits seit vielen Jahren ein Programm geschrieben, mit dem man via RFC Programmsourcen und/oder Textelemente von einem System zum anderen System senden bzw. empfangen kann, wenn das Programm im Zielsystem bereits existiert. (mit Berechtigungen sogar ins Produktionssystem !).
Unsere Entwickler nutzen dieses Teil sehr häufig und der Grund dafür liegt in der Konfiguration der Systemlandschaft: Entwicklungssystem, Testsystem, Produktiv-System. Im Entwicklungssystem sind eben in der Regel keine ausreichenden Testdaten vorhanden - dafür aber im Testsystem. In der Entwicklungsphase bei jeder Programmänderung einen normalen SAP-Transport durchzuführen, ist aber ziemlich mühsam. Durch dieses Programm wird tatsächlich die Entwicklung und das Testen von Programmen stark vereinfacht.

@KPAS
So ein Programm zu schreiben, das nur Reports sendet, ist gar nicht so schwer:
Ein Report, das Reportsourcen und Textelemente liest und dann im Zielsystem via RFC einen Funktionsbaustein aufruft, der dort den Update durchführt. (die Berechtigungsprüfungen nicht vergessen)

mfg dele

p.s.
@frank
Es geht darum Risko & Sicherheit gegen Aufwand & Kosten in einem Unternehmen abzuwägen. Wir können es uns heute nicht mehr leisten, dass interne wie externe Entwickler mehr Zeit in Verwaltung als Entwicklung investieren. Natürlich kann man mit solchen Programmen Blödsinn machen. Aber das können Entwickler immer (und die Möglichkeiten dazu liefert SAP sogar selbst). Die 100%-ige Sicherheit gibt es nicht. Um den administrativen Aufwand gering und die Flexibilität und Motivation hoch zu halten, haben wir uns für eine gute Portion Vertrauen entschieden. Bei Missbrauch oder Fahrlässigkeit gibt's dann jedoch Ärger.