interne Tabelle dynamisch mit Spalten erweitern

Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Getting started ... Alles für einen gelungenen Start.
8 Beiträge • Seite 1 von 1
8 Beiträge Seite 1 von 1

interne Tabelle dynamisch mit Spalten erweitern

Beitrag von JM1804_ABAP (ForumUser / 1 / 1 / 0 ) »
Hallo Zusammen,

ich habe folgende Programmaufforderung bekommen.

Ein Programm schreiben, dass eine interne Tabelle dynamisch mit Spalten erweitert.
Also jedes Mal wenn ein bestimmtes Ereignis eintritt, soll diese Methode aufgerufen werden und folgende Struktur bzw. Spalten an die vorhandene Tabelle (mt_ausg) hinzufügen:

Code: Alles auswählen.

TYPES: BEGIN OF ts_tage,
         dzlgt TYPE i, 
         dvzgt TYPE i, 
       END OF ts_tage.
Da das Ereignis beliebig oft auftreten kann, kann ich keine statische ITAB/Struktur vorgeben.
Jetzt weiß ich nicht mal im Ansatz wie ich dieses Problem lösen soll, da der Name der Spalten ebenfalls dynamisch mithilfe eines Übergabeparameters erstellt werden soll.

Da ich noch recht unerfahren in ABAP bin, hoffe ich, dass eventuell einer von euch einen Rat bzw. Lösungsansatz hat.

Danke im Voraus.

gesponsert
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten


Re: interne Tabelle dynamisch mit Spalten erweitern

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
Was willst du denn damit am Ende machen? Im ALV-Grid anzeigen? An eine andere Funktion weiterleiten?

Eine Erweiterung war theoretisch irgendwie möglich, glaube ich, ist aber normalerweise nicht sinnvoll.

wenn es um die Anzeige im ALV-Grid geht: Du könntest die Felder von vornherein einplanen, aber erst einmal ausblenden. Das ist deutlich einfacher!

Re: interne Tabelle dynamisch mit Spalten erweitern

Beitrag von msfox (Specialist / 304 / 50 / 62 ) »
Ob es die Lösung für dein Problem ist, weiß ich nicht. Aber ich brauchte mal die Logik, um dynamisch eine Struktur zu erzeuegen (Für die Serienbrieffunktion im SAP).
Der Code dazu sieht so aus:

Code: Alles auswählen.

FIELD-SYMBOLS: <fs_table> TYPE STANDARD TABLE.
 DATA lt_comp      TYPE cl_abap_structdescr=>component_table.
 DATA lr_struc     TYPE REF TO cl_abap_structdescr.
 DATA lr_table     TYPE REF TO cl_abap_tabledescr.
 DATA lr_data      TYPE REF TO data.
 "Dynamische Struktur erzeugen
 LOOP AT it_field_value ASSIGNING FIELD-SYMBOL(<wa_field_value>).
   APPEND INITIAL LINE TO lt_comp ASSIGNING FIELD-SYMBOL(<wa_comp>).
   <wa_comp>-name = <wa_field_value>-ziel.
   <wa_comp>-type ?= cl_abap_datadescr=>describe_by_data( p_data = <wa_field_value>-value ).
 ENDLOOP.
 lr_struc = cl_abap_structdescr=>create( lt_comp ).
 lr_table = cl_abap_tabledescr=>create(
        p_line_type  = lr_struc
        p_table_kind = cl_abap_tabledescr=>tablekind_std
        p_unique     = abap_false ).
 CREATE DATA lr_data TYPE HANDLE lr_table.
 ASSIGN lr_data->* TO <fs_table>.
 APPEND INITIAL LINE TO <fs_table> ASSIGNING FIELD-SYMBOL(<wa_table>).
Auf it_field_value-ziel steht dabei der Name Strukturfeldes und auf VALUE der Wert.

Muss du für dich etwas zwischen den Zeilen lesen.
Aber im Grunde kann du nicht einfach Spalten anhängen. Du könntest aber die komplette Struktur (Spalten deiner Tabelle) komplett neu erzeugen.

Folgende Benutzer bedankten sich beim Autor msfox für den Beitrag:
JM1804_ABAP


Re: interne Tabelle dynamisch mit Spalten erweitern

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
ewx hat geschrieben:
06.06.2023 18:22
Was willst du denn damit am Ende machen?
Ich denke, das ist einfach eine Programmieraufgabe zum Umgang mit dynamisch definierten Strukturen und Tabellen. Eine Tabelle beliebig oft um eine bestimmte Struktur als neue Spalten zu erweitern (denen man dann ja auch jeweils eindeutige Spaltennamen geben muss, die sich von den bisherigen unterscheiden), dafür kann ich mir keinen sinnvollen produktiven Einsatzzweck vorstellen.

Insofern denke ich, dass wir uns über ALV hier keine Gedanken zu machen brauchen. Diese Aufgabe ist rein akademischer Natur. Die Werkzeuge hat msfox geliefert; jetzt muss JM1804_ABAP ran und seine Aufgabe damit lösen. Wobei msfox vollkommen recht hat: Wenn die Tabelle erst mal da ist, kann man keine Spalten mehr anfügen, sondern allenfalls eine neue mit mehr Spalten erzeugen.

Gewaltig lachen würde ich allerdings, wenn sich herausstellen sollte, dass der Threadersteller die Begriffe "Spalten" und "Zeilen" verwechselt hat und es einfach nur darum geht, einer statisch definierten Tabelle Zeilen hinzuzufügen.

Re: interne Tabelle dynamisch mit Spalten erweitern

Beitrag von JM1804_ABAP (ForumUser / 1 / 1 / 0 ) »
Hallo zusammen,

danke für eure Antworten, ich werde jetzt versuchen den Lösungsvorschlag von msfox einzubauen.

Um die offenen Fragen zu beantworten:

-Es soll in einem ALV angezeigt werden.

-Das im vorhinein Einplanen der Felder ist leider nicht so einfach möglich, da die Felder je nach Selektion eine andere Überschrift brauchen.

-Ja das Programm soll am Ende produktiv genutzt werden. Ich kann aber leider selber nicht sagen, was der Sinn dahinter ist, da mir das Verständnis der Anwenderseite fehlt.

-Nein, ich habe Spalten und Zeilen hier nicht vertauscht.

Um eventuell noch kommende Fragen vorzubeugen:

Das Programm zeigt die Zahltage unserer Kunden, also wie lange der Kunde gebraucht hat um zu zahlen.
Daraus soll ein Durchschnitt pro Monat erstellt werden, der dann pro Monat/Jahr als Spalte ausgegeben wird.
Der Sinn dahinter ist glaube ich, dass man auf einem Blick die durchschnittlichen Zahltage aller Kunden pro Monat/Jahr vergleichen kann.

Nochmal Danke für eure Antworten.
Zuletzt geändert von JM1804_ABAP am 12.06.2023 10:13, insgesamt 1-mal geändert.

Re: interne Tabelle dynamisch mit Spalten erweitern

Beitrag von DeathAndPain (Top Expert / 1795 / 213 / 396 ) »
JM1804_ABAP hat geschrieben:
12.06.2023 10:11
-Das im vorhinein Einplanen der Felder ist leider nicht so einfach möglich, da die Felder je nach Selektion eine andere Überschrift brauchen.
Dagegen ist nichts einzuwenden; das ist halt so ein Anwendungsfall, bei dem man eine dynamisch erzeugte Tabelle braucht. Nur: In dem Moment, in dem Du die Tabelle (zur Laufzeit) erzeugst, solltest Du vollständige Information über die benötigten Spalten haben. Nachher der fertigen Tabelle noch dynamisch weitere Spalten hinzuzufügen, wie Du es ursprünglich beschrieben hast, geht nicht und ergibt in meinen Augen auch keinen Sinn.
JM1804_ABAP hat geschrieben:
12.06.2023 10:11
-Ja das Programm soll am Ende produktiv genutzt werden. Ich kann aber leider selber nicht sagen, was der Sinn dahinter ist, da mir das Verständnis der Anwenderseite fehlt.
Das ist ganz schlecht, wenn der Entwickler nicht weiß, was der Zweck des Programms ist (was die Anwender damit erreichen wollen), weil er dann keine mündigen Designentscheidungen treffen kann. Ich verwende dann gerne einen Vergleich, für den ich von manchen sehr auf politischer Korrektheitslinie befindlichen Zeitgenossen gerne mal angefeindet werde und sage, dass ist, wie wenn Du einen vorgefertigten Programmierauftrag nach Indien vergibst, und dort sitzt dann ein Programmierer im Keller, programmiert das blind herunter, und am Ende gibt's ein Schälchen Reis. Wenn Du das machst, dann bist Du wirklich nur "Programmierer" und nicht "Entwickler". Im SAP-Umfeld halte ich das für besonders problematisch. Da sollte jeder Programmierer auch ein Stück weit Berater sein. Erst diese Kombination macht ihn zum "Entwickler" (und führt dazu, dass er sein meist sehr ordentliches Gehalt wert ist).

Im Computerspielebereich gibt es ein ähnliches Phänomen. Und zwar sind die deutschen Übersetzungen der meisten Computerspiele mies. Und das obwohl sie von beruflichen Übersetzern übersetzt werden. Wieso? Weil das Computerspiel eine Tabelle englischsprachiger Texte enthält, und der Übersetzer übersetzt jeden Eintrag davon ins Deutsche, ohne aber das Spiel zu kennen und den jeweiligen Satz inhaltlich einordnen zu können. Da kommen dann sehr komische Stilblüten bei heraus. Ein Beispiel, das mir gerade aus dem alten (aber erstklassigen) Spiel "Medieval II - Total War" einfällt: Wenn Du da eine neue Kathedrale fertigstellst, dann kommt im englischen der (aus der Erinnerung wiedergegebene) Satz: "The pope has approved the new cathedral." Im Deutschen heißt es dann: "Der Papst hat die neue Kathedrale genehmigt." Das ist natürlich Blödsinn, denn noch nicht mal im Mittelalter brauchte ein Herrscher eine päpstliche Genehmigung für den Bau einer Kathedrale. Vielmehr war der Papst froh, wenn jemand so viel Geld und Ressourcen in die Hand genommen hat, um Bedeutung und Einfluss der Kirche zu stärken. Dementsprechend hätte "approved" hier nicht mit "genehmigt", sondern mit "gutgeheißen" übersetzt werden müssen (führt im Spiel auch dazu, dass Dein Ansehen beim Papst steigt). Ohne den Kontext zu haben, konnte der Übersetzer das aber nicht wissen.

Um den Bogen zurück zu spannen: Wenn Du die Hintergründe nicht verstanden hast, wofür Dein Programm benötigt und verwendet werden wird, dann wirst Du mit einiger Wahrscheinlichkeit keine optimale Lösung hinbekommen. In vielen Fällen ist es sogar so, dass die Anwender Denkfehler machen und ihre Anforderung in dieser Form überhaupt keinen Sinn ergibt. Du mit Deinem technischen Hintergrundwissen kannst das erkennen und ihnen erklären und mit ihnen gemeinsam eine sinnvollere Anforderungsdefinition erarbeiten. Aber dazu musst Du verstanden haben, wo sie mit dem Programm hinwollen.

Ich würde immer Fragen stellen und darauf bestehen, dass mir jemand die Hintergründe genau erklärt. Damit machst Du Dich dann auch auf den Weg vom Junior, der nur von oben vorgekaute Aufgaben umsetzt, zum Senior, der selber denkt.

Re: interne Tabelle dynamisch mit Spalten erweitern

Beitrag von ewx (Top Expert / 4784 / 294 / 628 ) »
DeathAndPain hat geschrieben:
13.06.2023 12:50
JM1804_ABAP hat geschrieben:
12.06.2023 10:11
-Das im vorhinein Einplanen der Felder ist leider nicht so einfach möglich, da die Felder je nach Selektion eine andere Überschrift brauchen.
Dagegen ist nichts einzuwenden; das ist halt so ein Anwendungsfall, bei dem man eine dynamisch erzeugte Tabelle braucht.
nein, braucht man nicht. Da alle Spalten den gleichen Type haben, kann man ausreichen Spalten definieren (m001, m002, etc) und diesen im Feldkatalog einen entsprechenden Titel zuweisen.
IMHO sollte man das auch so machen, denn dann zerstört man nicht das Layout eines ALV-Grid, sobald sich diese jemand für eine mit dynamisch erzeugter Tabelle abspeichert! M001 bleibt M001, auch wenn sich der Titel von Monat zu Monat zu "JUN 2023" zu "JUL 2023" zu "AUG 2023" usw ändert.

Re: interne Tabelle dynamisch mit Spalten erweitern

Beitrag von JM1804_ABAP (ForumUser / 1 / 1 / 0 ) »
Danke für euer Feedback, das hilft mit sehr.
DeathAndPain hat geschrieben:
13.06.2023 12:50
JM1804_ABAP hat geschrieben:
12.06.2023 10:11
-Das im vorhinein Einplanen der Felder ist leider nicht so einfach möglich, da die Felder je nach Selektion eine andere Überschrift brauchen.
Dagegen ist nichts einzuwenden; das ist halt so ein Anwendungsfall, bei dem man eine dynamisch erzeugte Tabelle braucht. Nur: In dem Moment, in dem Du die Tabelle (zur Laufzeit) erzeugst, solltest Du vollständige Information über die benötigten Spalten haben. Nachher der fertigen Tabelle noch dynamisch weitere Spalten hinzuzufügen, wie Du es ursprünglich beschrieben hast, geht nicht und ergibt in meinen Augen auch keinen Sinn.
Ich glaube ich habe mein Problem im ersten Threadpost falsch geschildert.
Mir war klar, dass ich eine vorhandene ITAB nicht einfach erweitern kann, sondern
eine Methode schreiben muss, wo ich diese ITAB mitgebe, zusätzlich mit den entsprechenden Spaltennamen, damit ich als Rückgabe die Ausgabe-ITAB erhalte.

Das hier ist, was ich aus der Selektion der Zwischentabelle erhalte:

Datum Kunde KH4 KH5 KH6 Zahlungstage

08.01.2019 1 H1 H2 H4 5
29.01.2019 1 H1 H3 H4 12
29.01.2019 1 H1 H3 H4 12
20.02.2019 1 H1 H3 H4 0
05.03.2019 1 H1 H3 H4 7
08.03.2019 1 H1 H3 H4 21
11.03.2019 1 H1 H3 H4 32
11.03.2019 1 H1 H2 H4 27
15.04.2019 1 H1 H3 H4 0
23.04.2019 1 H1 H3 H4 8
23.04.2019 1 H1 H3 H4 8
23.04.2019 1 H1 H2 H4 11
29.04.2019 1 H1 H2 H4 4
29.04.2019 1 H1 H2 H4 0

Die Methode soll also über die Zwischentabelle loopen und für jeden Monat eine Spalte erstellen/(umbennen nach Lösungsvorschlag von ewx). Die Ausgabe-ITAB würde so aussehen:

Kunde KH4 KH5 KH6 01.2019 02.2019 03.2019 04.2019
1 H1 H2 H4 5 - 27 5
1 H1 H3 H4 12 0 20 5,3334

Unter den Monaten werden die durchschnittlichen Zahlungstage berechnet.
Anbei nochmal ein Screenshot.
ewx hat geschrieben:
13.06.2023 13:10
DeathAndPain hat geschrieben:
13.06.2023 12:50
JM1804_ABAP hat geschrieben:
12.06.2023 10:11
-Das im vorhinein Einplanen der Felder ist leider nicht so einfach möglich, da die Felder je nach Selektion eine andere Überschrift brauchen.
Dagegen ist nichts einzuwenden; das ist halt so ein Anwendungsfall, bei dem man eine dynamisch erzeugte Tabelle braucht.
nein, braucht man nicht. Da alle Spalten den gleichen Type haben, kann man ausreichen Spalten definieren (m001, m002, etc) und diesen im Feldkatalog einen entsprechenden Titel zuweisen.
IMHO sollte man das auch so machen, denn dann zerstört man nicht das Layout eines ALV-Grid, sobald sich diese jemand für eine mit dynamisch erzeugter Tabelle abspeichert! M001 bleibt M001, auch wenn sich der Titel von Monat zu Monat zu "JUN 2023" zu "JUL 2023" zu "AUG 2023" usw ändert.
Das wäre theoretisch eine einfachere Lösung für mich, aber wie kann man während eines Loops auf den Feldkatalog vom SALV zugreifen?
Zuletzt geändert von JM1804_ABAP am 13.06.2023 14:22, insgesamt 3-mal geändert.

Seite 1 von 1

Vergleichbare Themen

6
Antw.
1394
Views
MD04 Tabelle mit neuen Spalten erweitern
von BecomingAnAbapGuru » 24.02.2022 19:44 • Verfasst in ABAP® für Anfänger
10
Antw.
11842
Views
Gefüllte dynamische Tabelle um Spalten erweitern
von km216 » 15.09.2011 10:09 • Verfasst in ABAP® für Anfänger
2
Antw.
3945
Views
Dynamisch erzeugte Tabelle erweitern
von ewx » 18.01.2007 14:57 • Verfasst in ABAP Objects®
1
Antw.
3144
Views
Interne Tabelle --> Summen von Spalten
von thomas76 » 16.01.2013 09:07 • Verfasst in ABAP® für Anfänger
2
Antw.
4539
Views
Interne Tabelle dynamisch typisieren
von McQueenSix » 23.12.2016 14:07 • Verfasst in ABAP® Core

Über diesen Beitrag



Die Frage ist als "gelöst" markiert. Den entsprechend Beitrag findest du hier.

Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch

Newsletter Anmeldung

Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.
Die letzte Ausgabe findest du hier.
Details zum Versandverfahren und zu Ihren Widerrufsmöglichkeiten findest du in unserer Datenschutzerklärung.

Unbeantwortete Forenbeiträge

Zwischensumme Adobe Forms
vor 4 Tagen von Lucyalison 1 / 71
Group Items auf einer Filterbar
vor einer Woche von Bright4.5 1 / 111
tRFC Transaktionen SM58
vor 4 Wochen von A6272 1 / 141