Once again: Tabelleninhalte nach Excel

Once again: Tabelleninhalte nach Excel

Hallo,

gegeben sei eine kundeneigene Tabelle, deren Inhalte selektiv nach Excel exportiert werden sollen.

Ich überlege gerade, was die einfachste Möglichkeit (die mit dem geringsten Aufwand) ist, es könnte zum Beispiel ein Programm sein, welches ein eigenes Selektionsbild hat und über die Eingaben die SE16 aufruft. Hinter diese Transaktion könnte man eigene Berechtigungen legen.

Ich weiß dass es sich hierbei um eine Minimallösung handelt, aber genau DAS ist gewünscht: Eine provisorische Minimallösung.

Am ehesten wäre es das, was die Transaktionen

SE16_*

leisten. Z.B. liegt hinter SE16_BKPF das Programm /1BCDWB/DBBKPF -- was aber ein generiertes Programm ist und ich weiß nicht, wie und durch was generiert.

Frage daher: Kann mir jemand einen Denkanstoß geben, wie ich so etwas für eine kundeneigene Tabelle selbst erzeuge? Ich werd da gerade nicht so ganz schlau draus.

Oder gibts nen besseren Weg?


Danke

Ralf

Wenn du keine Lust hast die komfortable Lösung von Enno zu nehmen könntest du auch den Weg der Faulheit nehmen.

- SE16 aufrufen für die eigenen Tabelle.
- Auswählen welche Felder auf dem Selektionsbild zu sehen sein sollen .
- Via SYSTEM -> STATUS den (generierten) Programmnamen abgreifen
- In SE38 dieses generierte Programm kopieren auf ein eigenes Z-Programm.
- Fertig

Re: Once again: Tabelleninhalte nach Excel

ralf.wenzel hat geschrieben:Am ehesten wäre es das, was die Transaktionen

SE16_*

leisten. Z.B. liegt hinter SE16_BKPF das Programm /1BCDWB/DBBKPF -- was aber ein generiertes Programm ist und ich weiß nicht, wie und durch was generiert.

/1BCDWB/DB<tabname> ist doch schon seit 4.0 der Name der in SE16 für eine Tabelle generierten Programme. (Oder war es 4.5/4.6, als die @lfdnr-Programme abgelöst wurden?)

Und wenn Du Dir die Definition von SE16_BKPF ansiehst, siehst Du eine Parameter-Transaktion mit Bezug auf SE16, wobei BKPF als Tabellenname übergeben und das Einstiegsbild übersprungen wird.

Das heißt aber auch: jeder, der Felder aus dem Selektionsbild löscht oder neue aufnimmt, ändert dadurch das Aussehen des Reports für alle anderen User.
Und da SAP hier die Select-Options einfach "durchnummeriert",
kann man auch Report-Varianten nicht sinnvoll nutzen.

Also vor dem Kopieren eine sinnvolle Liste von Feldern ins Selektionsbild aufnehmen.
Außerdem beachten, dass die Berechtigungs-Prüfung auf S_TABU_DIS in der SE16 (SAPLSETB) erfolgt, und nicht IM generierten Report. (Apropos "Report": jeder darf mal raten, warum der Report mit einer FUNCTION-POOL-Anweisung beginnt.)

Eine Neugenerierung findet übrigens neben der direkt vom Benutzer erzwungenen Änderung des Selektionsbildes auch statt, wenn sich die Definition der Tabelle seit der letzten Genererung geändert hat.
Damit trotz identischer Tabellen-Definition und unveränderter Auswahl von Feldern für das Selektionsbild ein abweichender Quelltext generiert wird, müssen in einem Support Package oder OSS-Hinweis Änderungen an LSETB*-Includes vorgenommen worden sein, und aus SAPLSETB muss bei initgen ein neuer "Parameter" mitgegeben werden.

Wem das jetzt spanisch vorkommt, der kann mal mit globaler Suche in SAPLSETB nach initgen suchen, per Doppelklick zur Makrodefinition springen, sich die anderen Makros ansehen,
den Quelltext von LSETBTXT und darin verwendeter "Includes" ansehen, in Tabelle AGDB nachsehen, an welchen Stellen der gleiche Generierungs-Mechanismus verwendet wird, und spaßeshalber mal RSGENPAT mit den Parametern LSETBTXT, SAPLSETB und X starten.
(RSGENPAT ist auch bestens geeignet, um Fehler in eigenen Pattern-Dateien zu finden.
Ich benutze den Mechanismus jedenfalls ganz gerne, wenn mal etwas komplexere Quelltexte zu erzeugen sind.)

Frank