interne Tabelle dynamisch mit Spalten erweitern

Re: interne Tabelle dynamisch mit Spalten erweitern

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

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

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

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?