sy-ucomm übergeordnetes Programm
10 Beiträge
•
Seite 1 von 1
10 Beiträge
Seite 1 von 1
Hallo zusammen,
ich habe mittels Append-Struktur einige Felder zu der Tabelle VBRK und anschließend mit einem User-Exit einen Tab XYZ am Faktura-Kopf hinzugefügt.
In meinem Report habe ich dann die Append-Felder in einem Subscreen aufgenommen. Die Felder sind nun im Tab XYZ vorhanden und können mit VF01, VF02 oder VF03
angelegt, geändert oder angezeigt werden.
Nun mein Problem:
Auf dem Subscreen habe ich einen Button mit Funktionscode A. Durch betätigen des Buttons wird CALL TRANSACTION ausgelöst.
Gehe ich nun aber wieder zurück zu meinem Subscreen bekomme ich die Fehlermedung, das die Funktion A hier nicht vorgesehen ist.
Es liegt wohl daran, dass der ok_code gleich an das übergeordnete Programm weitergegeben wird. Ein Clear an diversen Stellen brachte kein Erfolg.
Im Debugger passt mein A aber zu keinem FCODE der Tabelle T185F. Zumindest erhalte ich an dieser Stelle immer den Fehler.
Nun hab ich ein wenig über dirty assign gelesen.
Für mich liest es sich aber immer so, als wenn ich so nur erfahre welcher ok_code an das übergeordnete Programm übergeben wurde?
Oder kann ich diesen gar beienflussen/ändern? Irgendwie sträub ich mich aber davor
Nachfolgend ein Link wo es eigentlich um genau das gleiche Thema ging, aber leider die Lösung recht kurz dargelegt ist.
http://www.apentia-forum.de/viewtopic.php?t=17058
Vielleicht habt ihr einen Tipp für mich?
Viele Grüße
Bjuti
ich habe mittels Append-Struktur einige Felder zu der Tabelle VBRK und anschließend mit einem User-Exit einen Tab XYZ am Faktura-Kopf hinzugefügt.
In meinem Report habe ich dann die Append-Felder in einem Subscreen aufgenommen. Die Felder sind nun im Tab XYZ vorhanden und können mit VF01, VF02 oder VF03
angelegt, geändert oder angezeigt werden.
Nun mein Problem:
Auf dem Subscreen habe ich einen Button mit Funktionscode A. Durch betätigen des Buttons wird CALL TRANSACTION ausgelöst.
Gehe ich nun aber wieder zurück zu meinem Subscreen bekomme ich die Fehlermedung, das die Funktion A hier nicht vorgesehen ist.
Es liegt wohl daran, dass der ok_code gleich an das übergeordnete Programm weitergegeben wird. Ein Clear an diversen Stellen brachte kein Erfolg.
Im Debugger passt mein A aber zu keinem FCODE der Tabelle T185F. Zumindest erhalte ich an dieser Stelle immer den Fehler.
Nun hab ich ein wenig über dirty assign gelesen.
Für mich liest es sich aber immer so, als wenn ich so nur erfahre welcher ok_code an das übergeordnete Programm übergeben wurde?
Oder kann ich diesen gar beienflussen/ändern? Irgendwie sträub ich mich aber davor
Nachfolgend ein Link wo es eigentlich um genau das gleiche Thema ging, aber leider die Lösung recht kurz dargelegt ist.
http://www.apentia-forum.de/viewtopic.php?t=17058
Vielleicht habt ihr einen Tipp für mich?
Viele Grüße
Bjuti
gesponsert ⓘ
Stellenangebote auf ABAPforum.com schalten
kostenfrei für Ausbildungsberufe und Werksstudenten
kostenfrei für Ausbildungsberufe und Werksstudenten
Wenn du in einem SUB-Screen einen OK-Code verarbeitest
musst du den Haupt-Screen danach verlassen, sonst wird er
in weiteren SUB-Screens und im Haupt-Screen nochmal
verarbeitet.
Löschen klappt nicht da jedes Dynpro den OK-Code erneut
ins Programm überträgt.
Es ist eine sehr unübersichtliche und hoch Fehlerträchtige
Programmierung wenn man in SUB-Screens den OK-Code
verarbeitet. Das sollte nur in Ausnahmefällen wenn es anders
nicht möglich ist gemacht werden (z.B. bei Step-Loops).
musst du den Haupt-Screen danach verlassen, sonst wird er
in weiteren SUB-Screens und im Haupt-Screen nochmal
verarbeitet.
Löschen klappt nicht da jedes Dynpro den OK-Code erneut
ins Programm überträgt.
Es ist eine sehr unübersichtliche und hoch Fehlerträchtige
Programmierung wenn man in SUB-Screens den OK-Code
verarbeitet. Das sollte nur in Ausnahmefällen wenn es anders
nicht möglich ist gemacht werden (z.B. bei Step-Loops).
Hallo,
ok ich schaue mir mal Step-Loops an. Noch nie gehört
Ja da mein Subscreen selbst ja kein OK_Code hat ist es tatsächlich schwierig.
Kann man vielleicht auch im User-Exit was mit dem sy-ucomm machen?
Immerhin wäre ich da ja im übergeordneten Programm.
Viele Grüße!
ok ich schaue mir mal Step-Loops an. Noch nie gehört
Ja da mein Subscreen selbst ja kein OK_Code hat ist es tatsächlich schwierig.
Kann man vielleicht auch im User-Exit was mit dem sy-ucomm machen?
Immerhin wäre ich da ja im übergeordneten Programm.
Viele Grüße!
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Hallo Bjuti,
da du dich in einer Faktura rumtreibst und ja auch schon die Tabelle T185F erwähnt hast, solltest du dich mal in der VertriebsbelegFolgeBildSteuerung umschauen ( Transaktion VFBS ) und dort dann einen eigenen ( den von dir ausgelösten ) Funktionscode hinterlegen, damit das Rahmenprogramm wieder weiß was es nach dem Prozessieren des Funktionscodes denn tun soll.
da du dich in einer Faktura rumtreibst und ja auch schon die Tabelle T185F erwähnt hast, solltest du dich mal in der VertriebsbelegFolgeBildSteuerung umschauen ( Transaktion VFBS ) und dort dann einen eigenen ( den von dir ausgelösten ) Funktionscode hinterlegen, damit das Rahmenprogramm wieder weiß was es nach dem Prozessieren des Funktionscodes denn tun soll.
Folgende Benutzer bedankten sich beim Autor black_adept für den Beitrag (Insgesamt 2):
gtoXX • Bjuti
Hallo black_adept,black_adept hat geschrieben:Hallo Bjuti,
da du dich in einer Faktura rumtreibst und ja auch schon die Tabelle T185F erwähnt hast, solltest du dich mal in der VertriebsbelegFolgeBildSteuerung umschauen ( Transaktion VFBS ) und dort dann einen eigenen ( den von dir ausgelösten ) Funktionscode hinterlegen, damit das Rahmenprogramm wieder weiß was es nach dem Prozessieren des Funktionscodes denn tun soll.
erstmal vielen Dank für den Wegweiser.
Die Fehlermeldung ist nun verschwunden, nachdem ich entsprechende Einträge in den Tabellen T185 und T85F im Entwicklungssystem vorgenommen habe.
Ich bekam jedoch die Warnmeldung, dass ich mich im SAP-Namensraum befinde und das die Einträge durch SAP-Updates ggf. überschrieben werden.
Kann ich die Einträge zu kunden-eigene Einträge machen? Oder ist die Warnmeldung in diesem Bereich normal?
Mein Ausgangsproblem hat sich nun aber nur nach hinten verschoben.
Ich bekomme zwar keine Fehlermeldung mehr, aber sy-ucomm im übergeordnetem Programm ist immer noch den Funktionscode des Push-Buttons zugewiesen.
Dadurch wird bei einer anderen Aktionen im Subscreen, welche ja nicht sy-ucomm ändern, natürlich immer noch die Aktion des Push-Buttons ausgeführt.
Ich habe nun folgendes gemacht:
Da jedesmal der User-Exit durchlaufen wird, wenn der Anwender nach dem CALL TRANSACTION zurück zum neuen Tab gelangt,
habe ich im User-Exit folgendes hinzugefügt:
Code: Alles auswählen.
LOOP AT SCREEN.
IF SCREEN-NAME EQ 'TABSTRIP_TAB06'.
"Aufbau Tab
IF sy-ucomm EQ 'PUSH_BUTTON'.
sy-ucomm = ''.
ENDIF.
ENDIF.
ENDLOOP.Viele Grüße
Bjuti
Beitrag
von black_adept (Top Expert / 4089 / 127 /
940
)
»
Moin Bjuti,
1.) Die Warnmeldung ist normal und kann getrost ignoriert werden. Du solltest aber den FCode den du auslöst irgendwie so benennen, dass SAP nicht auf die Idee kommt so einen FCode selber noch mal auszuliefern, was aber bei der Ausrichtung weg von R/3 hin zu S/4 eh nicht so wahrscheinlich ist. Wenn dein Subscreen die Nummer 0815 hat, nenn den Fcode so was wie Z0815_AKTIONWASWEISSICH, dann bist du auf einer recht sicheren Seite.
2.) Mehrfache Ausführung des FCodes wenn du nicht sy-ucomm löscht.
Das ist so eine Crux wenn man in Subscreenerweiterungen im SD rumtreibt. Zunächst einmal muss man bedenken, dass der "eigentliche" Funktionscode zwar in SY-UCOMM gespiegelt wird, aber offiziell in das Feld übergeben wird, welches im Trägerdynpro dafür vorgesehen ist. Allerdings scheint es recht uneinheitlich geregelt zu sein, ob nachher dann der SY-UCOMMM oder das OK-Codefeld ausgewertet wird. Wenn also der FCode nach dem Prozessieren deiner Aktion ( die wahrscheinlich während des CALL SUBSCREEN im PAI ausführst ) wo anders auch noch mal Beachtung finden könnte solltest du ihn tatsächlich löschen, es sei denn dies beeinflusst die Folgebildsteuerung. Andererseits frage ich mich was für Aktionen das sein sollen, die den selben OK-Code noch mal prozessieren lassen. Normalerweise wird doch der OK-Code im PBO gelöscht (wenn man es nicht vergisst) und beim Triggern des PAI sollte dann entweder nix drin stehen bzw. die Aktion die wirklich gefordert ist.
1.) Die Warnmeldung ist normal und kann getrost ignoriert werden. Du solltest aber den FCode den du auslöst irgendwie so benennen, dass SAP nicht auf die Idee kommt so einen FCode selber noch mal auszuliefern, was aber bei der Ausrichtung weg von R/3 hin zu S/4 eh nicht so wahrscheinlich ist. Wenn dein Subscreen die Nummer 0815 hat, nenn den Fcode so was wie Z0815_AKTIONWASWEISSICH, dann bist du auf einer recht sicheren Seite.
2.) Mehrfache Ausführung des FCodes wenn du nicht sy-ucomm löscht.
Das ist so eine Crux wenn man in Subscreenerweiterungen im SD rumtreibt. Zunächst einmal muss man bedenken, dass der "eigentliche" Funktionscode zwar in SY-UCOMM gespiegelt wird, aber offiziell in das Feld übergeben wird, welches im Trägerdynpro dafür vorgesehen ist. Allerdings scheint es recht uneinheitlich geregelt zu sein, ob nachher dann der SY-UCOMMM oder das OK-Codefeld ausgewertet wird. Wenn also der FCode nach dem Prozessieren deiner Aktion ( die wahrscheinlich während des CALL SUBSCREEN im PAI ausführst ) wo anders auch noch mal Beachtung finden könnte solltest du ihn tatsächlich löschen, es sei denn dies beeinflusst die Folgebildsteuerung. Andererseits frage ich mich was für Aktionen das sein sollen, die den selben OK-Code noch mal prozessieren lassen. Normalerweise wird doch der OK-Code im PBO gelöscht (wenn man es nicht vergisst) und beim Triggern des PAI sollte dann entweder nix drin stehen bzw. die Aktion die wirklich gefordert ist.
Hallo black_adept,
nachfolgend mein Vorgehen im Coding bzgl. sy-ucomm / ok_code
So werde ich den Eintrag PUSH_BUTTON in sy-ucomm aber nicht los.
Kommt der Anwender nach CALL TRANSACTION zurück und betätigt in einem anderen Feld (gleicher Tab) ENTER, dann steht weiterhin PUSH_BUTTON in sy-ucomm und es wird wieder CALL TRANSACTION ausgelöst. Ich denke das liegt daran, weil ich zum Subscreen selbst ja kein OK_CODE definieren kann/darf.
Also eigentlich ist mein lokales OK_FELD aktuell überflüssig.
Ich hatte es auch mal mit GET CURSOR FIELD probiert, in der Hoffnung, dass ich so erfahre ob tatsächlich der Push Button betätigt wurde.
Aber das klappte nicht so ganz
Viele Grüße
Bjuti
nachfolgend mein Vorgehen im Coding bzgl. sy-ucomm / ok_code
Code: Alles auswählen.
Data: ok_code LIKE sy-ucomm.
MODULE vor_Ausgabe OUTPUT.
clear ok_code.
".....
ENDMODULE.
MODULE nach_Eingabe INPUT.
".....
ok_code = sy-ucomm.
clear sy-ucomm.
CASE ok_code.
WHEN 'PUSH_BUTTON'
CALL TRANSACTION 'VL03'.
ENDCASE.
".....
ENDMODULE.
Kommt der Anwender nach CALL TRANSACTION zurück und betätigt in einem anderen Feld (gleicher Tab) ENTER, dann steht weiterhin PUSH_BUTTON in sy-ucomm und es wird wieder CALL TRANSACTION ausgelöst. Ich denke das liegt daran, weil ich zum Subscreen selbst ja kein OK_CODE definieren kann/darf.
Also eigentlich ist mein lokales OK_FELD aktuell überflüssig.
Ich hatte es auch mal mit GET CURSOR FIELD probiert, in der Hoffnung, dass ich so erfahre ob tatsächlich der Push Button betätigt wurde.
Aber das klappte nicht so ganz
Viele Grüße
Bjuti
Ok, vielen Dank.
An einer Sache verzweifle ich gerade.
Ich habe für eine implizite Erweiterung eine Stelle gesucht, die sowohl bei der Transaktion VF01 und VF02 nach dem Sichern einer Faktura durchlaufen wird.
Ich bin auch fündig geworden (Form BELEG_SICHERN im Programm SAPMV60A) und habe nachfolgendes versucht.
Nun ist es so, dass der Inhalt im Feld xvbrk-yysd_glbvgbel bei VF01 auch in die VBRK geschrieben wird, bei VF02 aber nicht.
Im Debugger sieht alles gut aus. Habt ihr eine Idee woran das liegen könnte? Sollte ich vielleicht eine andere Stelle für die implizierte Erweiterungsoption suchen?
Viele Grüße
Bjuti
An einer Sache verzweifle ich gerade.
Ich habe für eine implizite Erweiterung eine Stelle gesucht, die sowohl bei der Transaktion VF01 und VF02 nach dem Sichern einer Faktura durchlaufen wird.
Ich bin auch fündig geworden (Form BELEG_SICHERN im Programm SAPMV60A) und habe nachfolgendes versucht.
Code: Alles auswählen.
IF fcode EQ 'SICH'.
IF sy-tcode = 'VF01' OR sy-tcode = 'VF02'.
LOOP AT xvbrk[] INTO xvbrk.
SELECT SINGLE xegld FROM t005 INTO eu
WHERE land1 = vbrk-land1.
IF eu IS NOT INITIAL AND sy-tcode EQ 'VF01'
xvbrk-yysd_glbvgbel = vbuk-vbeln.
ELSEIF eu IS NOT INITIAL AND sy-tcode EQ 'VF02'
SELECT SINGLE vgbel FROM vbrp INTO xvbrk-yysd_glbvgbel
WHERE vbeln = vbrk-vbeln.
ENDIF.
MODIFY xvbrk[] FROM xvbrk
TRANSPORTING yysd_glbvgbel.
ENDLOOP.
ENDIF.
ENDIF.Im Debugger sieht alles gut aus. Habt ihr eine Idee woran das liegen könnte? Sollte ich vielleicht eine andere Stelle für die implizierte Erweiterungsoption suchen?
Viele Grüße
Bjuti
Seite 1 von 1
Vergleichbare Themen
4
Antw.
Antw.
3386
Views
Views
4
Antw.
Antw.
3511
Views
Views
2
Antw.
Antw.
2023
Views
Views
SY-UCOMM für Barcodescanner-Steuerung
von stony007_de » 17.12.2014 13:58 • Verfasst in ABAP® für Anfänger
von stony007_de » 17.12.2014 13:58 • Verfasst in ABAP® für Anfänger
7
Antw.
Antw.
529
Views
Views
cl_gui_html_viewer=>SHOW_URL sy-ucomm abfangen
von JanR » 15.08.2022 14:18 • Verfasst in ABAP® für Anfänger
von JanR » 15.08.2022 14:18 • Verfasst in ABAP® für Anfänger
Frage die ABAP Experten
Über diesen Beitrag
Unterstütze die Community und teile den Beitrag für mehr Leser und Austausch
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1151
vor 2 Tagen von DeathAndPain 4 / 1151
Newsletter Anmeldung
Keine Beiträge verpassen! Wöchentlich versenden wir lesenwerte Beiträge aus unserer Community.Die letzte Ausgabe findest du hier.
Aktuelle Forenbeiträge
Nach Transport von Stellen über RHMOVE30 nur Planvariante "nie verwenden"
vor 2 Tagen von DeathAndPain 4 / 1151
vor 2 Tagen von DeathAndPain 4 / 1151