ich bin neu hier im Forum und komme mit einer speziellen Aufgabe nicht mehr weiter.
Ich habe ein Programm geschrieben in welchem der Routenfahrplan (likp-aulwe) zu Lieferungen angezeigt wird. Hier soll ich nun allerdings den Routenfahrplan zu einer Lieferung ändern können. Ich finde nur keinen Weg für einen Eintrag in der LIKP das Feld aulwe zu ändern, außer mit einem MODIFY auf die LIKP. Dies möchte ich allerdings wenn möglich auf jeden Fall umgehen.
Ich denke nicht, dass das gewünscht ist, da ich im ALV eine Zeile mit einer Lieferung auswählen soll, dann einen Button drücken soll, daraufhin ein PopUp erscheint, wo ich Wagen, Tour und Datum eingeben kann und sich daraus die AULWE zusammensetzt, und diese dann per Button speichern gespeichert werden soll.
Mittlerweile denke ich kommt das Modify nur noch in Frage.
Ich bin gerade auf der Suche nach einer Möglichkeit Z-Felder in der LIPS zu ändern. Nach allem was ich bisher dazu gefunden habe, wird es wohl auf den BAPI "BAPI_OUTB_DELIVERY_CHANGE" in Zusammenspiel mit dem BADI "SMOD_V50B0001" Methode "EXIT_SAPLV50I_010" und dem BADI LE_SHP_DELIVERY_UPDATE hinauslaufen.
Im SMOD_V50B0001 versorgt man die Changing Struktur mit seinen Werten und im LE_SHP_DELIVERY_UPDATE muss man dann selbst schauen, dass man sein gewünschtes Feld dann mit den Werten versorgt, bevor es auf die DB geschrieben wird.
Könnte vielleicht auch eine Möglichkeit für dich sein.
Gerade bei Standardfeldern ist so ziemlich alles besser als ein direktes Update, denke ich.
Bei Z-Feldern fände ich einen direkten Schreibzugriff noch vertretbar, wobei man sich natürlich etwaiger Pufferungen der Zieltabelleneinträge bewusst sein muss.
Batch-Input finde ich immer noch besser als manipulation auf der DB. Kann ja im Hintergrund erfolgen.
Ich habe nicht den Eindruck, dass JulEx sich dieser Option bewusst ist. Er scheint davon auszugehen, dass Du den Benutzer in den Standarddialog schicken möchtest.
@JulEx: Man kann "programmierten Batch Input" bauen, bei dem man die Standarddialoge unsichtbar im Hintergrund aufruft und alle dazugehörigen Dynpros aus seinem Programm mit Werten versorgt. Der Benutzer bekommt davon nichts mit; für ihn sieht es so aus, als würde Dein Programm direkt selber in die Datenbank schreiben.
Dazu macht man sich typischerweise eine Vorlage mit der Transaktion SHDB, lässt aus dieser automatisch einen Programmcode erzeugen und baut den erzeugten Programmcode in das eigene Programm ein. Dabei ersetzt man alle in der Vorlage eingegebenen Werte durch Felder des eigenen Programms und am Ende den BDC_TRANSACTION-Aufruf durch einen CALL TRANSACTION USING bdcdata. Dadurch wird die Transaktion dann später im Programm direkt ausgeführt, anstatt nur eine Mappe für die SM35 zu erzeugen.