Created attachment 5787 [details] Fehler Bei einem Klick auf die Detailebene wird nicht in die Standard Transaktion für die Belegbearbeitung gesprungen.
Daten werden nun auch auf der FQ0 angezeigt.
Die Klick-Funktionen wurden integriert
(In reply to Grab, Felix from comment #7) > Zeilen die nicht verarbeitet werden sollen, jeweils bei den folgenden > DELKZ-Inhalten: > - BP > - DD > - FH > - KB > - PB > - MS > - SH > - VP > - WB > > Jeweils mit der Meldung "Für dieses Dispoelement ist kein Absprung möglich." Ist umgesetzt und erfolgreich für ein Beispiel mit delkz WB auf der FE0 getestet worden. Bug wird für evtl. Weiterbearbeitung oder Schließung zurückgegeben. Neuer Text ist auf das Übersetzungstool hochgeladen worden.
Zeilen die nicht verarbeitet werden sollen, jeweils bei den folgenden DELKZ-Inhalten: - BP - DD - FH - KB - PB - MS - SH - VP - WB Jeweils mit der Meldung "Für dieses Dispoelement ist kein Absprung möglich."
Wären das dann folgende Mappings: pa_werks <--> Plant, pa_matnr <--> Product, pa_extra <--> extra, pa_berid <--> MRPArea Ich musste (etwas) raten, wie die Felder in der Applikation lauten. Wenn da was falsch sein sollte, einfach melden und ich korrigiere das. Ansonsten wäre das jetzt so umgesetzt. Entwicklertest meinerseits führt momentan allerdings zu Dumps im ABAP Coding. Ich spiele den Ball mal zurück... ;)
Bei weiteren Transaktionsaufrufen wurde festgestellt, dass noch weitere Daten aus der Zeile benötigt werden. Das aufgerufene Programm wurde entsprechend bearbeitet und erwartet folgende Daten: - Materialnummer (Feld PA_MATNR) - Werk (Feld PA_WERKS) - Dispobereich (Feld PA_BERID) - Daten zum Dispoelement (Feld PA_EXTRA) Könntest Du diese noch aus der Fiori App versorgen?
Weitere Tests haben ergeben, dass der Absprung funktioniert, wenn die Daten des angewählten Satzes für die empfangende Transaktion gültig sind. Falls die Daten ungültig sind, wird der Benutzer in dem sich öffnenden Tab auf die FLP Homepage zurückgeworfen. Vorschlag: die empfangende Transaktion sollte eine Fehlerbehandlung vorsehen, um mit ungültigen Datensätzen umzugehen.
*** Bug 15753 has been marked as a duplicate of this bug. ***
Absprung mit Übergabe der genannten Parameter ist wieder eingebaut, allerdings geht derzeit auf der Empfängerseite etwas schief und die Beleganzeige lässt den Aufruf nicht durch. Gibt es da einen Experten, der mal auf WebGUI Ebene schauen kann, warum diese Transaktion die Parameter nicht mag? Oder vielleicht stimmt etwas in der Zielzuordnung nach Updates nicht mehr?
Transaktion /GIB/SCX_TA_ORDER wird auf der FE0 noch aufgerufen, aber die Parameter werden nicht mehr versorgt. Hier müsste man aus dem Frontend schauen, warum die folgenden Parameter nicht mehr ankommen: - pa_delkz - pa_del12 - pa_delnr - pa_delps - pa_delet