Es sieht eben doch wie Kraut und Rüben aus, und zwar deshalb, weil Du mitten im PAI eines Dynpros einen WRITE-Befehl geschrieben hast, der da nicht hingehört.
Wobei, so ganz richtig ist das auch nicht. Du kannst sehr wohl im PAI eines eigenen Dynpros WRITE verwenden. Du musst vorher nur den Befehl
LEAVE TO LIST-PROCESSING AND RETURN TO SCREEN '0'. bringen.

Lies Dir die Online-Doku dazu ruhig mal durch; vielleicht kannst Du das mal brauchen.
black_adept hat geschrieben:was du beschreibst ist ein "Vorschaltprogramm".
Und ein "Vorschaltprogramm" ist was? Letztlich entnehme ich Deinen Worten, dass Du das Selektionsbild des Reports selbst als "Vorschaltprogramm" verstehst, was man sicherlich vertreten kann. Nur hat er ja deutlich gemacht, dass ihm genau das eben nicht reicht und dass er da eine erweiterte, flexible Programmsteuerung haben möchte. Und in dem Moment, in dem das so ist, ist ein Report mit seiner einfachen
Selektionsbild -> Ergebnisliste-Struktur nicht mehr ausreichend, sondern dann braucht man eine flexible Programmablaufsteuerung. Die einzige Alternative wäre, über FUNCTION KEY Schaltflächen in das Selektionsbild einzubauen und bei deren Nutzung dann aus dem entsprechenden AT SELECTION-SCREEN-Block einen CALL SCREEN auszuführen.
Ich schreibe andauernd neue Progrämmchen, welche diverse Dynpros verwenden. Aber wann ich dafür tatsächlich noch einen Modulpool verwendet habe - ich kann mich nicht erinnern das in den letzten 10 Jahren noch gemacht zu haben.
Würde gerne mal wissen, wie das aussehen soll. Ein Report generiert Dir aus Deinem Selektionsbild ein Dynpro 1000. Bei Abfahrt geht es in das Ergebnisbild. Viel mehr kann ein Report nicht. Vielleicht kannst Du den Ablauf umbiegen, indem Du im Ereignis START-OF-SELECTION dann plötzlich andere Dynpros per CALL SCREEN rufst, aber das kommt mir wie eine üble Vergewaltigung des REPORT-Konzeptes vor. Ich sehe auch keine Vorteile; im Gegenteil bist Du bei der Gestaltung Deines Selektionsbildes auf die Möglichkeiten beschränkt, die die Report-Programmierung Dir bietet, anstatt Dein Einstiegsdynpro komfortabel per WYSIWYG zu erstellen und dabei alle Möglichkeiten offen zu haben. Allein das Gekrampfe, dass PARAMETERS-Feldnamen nur maximal 8 Zeichen lang sein dürfen, was aussagekräftige Feldnamen zunichte macht, oder dass die Selektionstexte auch auf eine oft unzureichend kurze Länge beschränkt sind, die man sich aufwendig durch die kalte Küche erweitern muss, indem man einen
SELECTION-SCREEN BEGIN/END OF LINE-Block baut und dann ein Textsymbol anstelle des normalen Selektionstextes für den Parameter verwendet...
Wenn man einige Parameter erfragen und dann eine wie auch immer geartete Liste ausgeben
(oder aufgrund der eingegebenen Daten sonst irgendwas veranstalten) will, dann ist ein Report optimal. Tatsächlich sind das die meisten Anwendungsfälle, so dass auch ich nur noch sehr selten einen Modulpool baue. Aber in dem Moment, in dem Du z.B. eine Pflegetransaktion für etwas baust, ist ein Report Mist. Versuch mal, eine MM01/MM02 als Report zu bauen! Ganz zu schweigen von einer SE80. Das wird auf jeden Fall eine Vergewaltigung des Reportkonzeptes. Erst recht wenn das Programm komplexer ist und man in Unter-Dynpros verzweigen muss.