Code: Alles auswählen.
:
:
call function 'REUSE_ALV_GRID_DISPLAY'
exporting
i_callback_program = sy-repid
i_callback_top_of_page = 'PRINT_HEADER'
i_default = 'X'
i_save = 'X'
is_variant = g_variant
it_fieldcat = i_fieldcat
is_layout = i_layout
i_callback_user_command = 'USER_COMMAND'
tables
t_outtab = t_vbap
exceptions
program_error = 1
others = 2.
:
:
*&---------------------------------------------------------------------*
*& Form print_header ( FÜR VBAK DATEN )
*&---------------------------------------------------------------------*
* text
*----------------------------------------------------------------------*
FORM print_header.
DATA: t_show_line TYPE slis_t_listheader,
show_line TYPE slis_listheader.
:
:
CLEAR: show_line.
show_line-typ = 'S'.
CONCATENATE 'Date/Time:' sy-datum '/' l_uzeit INTO show_line-info.
APPEND show_line TO t_show_line.
CALL FUNCTION 'REUSE_ALV_COMMENTARY_WRITE'
EXPORTING
it_list_commentary = t_show_line.
ENDFORM. "PRINT_HEADER
... BAPI_SALESORDER_CREATEFROMDATA2 hätte für solche Fälle ein Simulationsflag (TESTRUN = 'X').Manchmal lässt sich der Auftrag aber nicht anlegen, weil irgendwelche Daten (aus externer Quelle) Müll sind
moin,ralf.wenzel hat geschrieben:Hintergrund ist eine Transaktion, die Aufträge anlegt (VA01). Das macht die mit Batch-Input, weil der Anwender noch drübergucken soll ehe der Auftrag wirklich gespeichert wird. Manchmal lässt sich der Auftrag aber nicht anlegen, weil irgendwelche Daten (aus externer Quelle) Müll sind, also will man VOR dem Auftrag-Anlegen (oder wenn man merkt, der konnte nicht angelegt werden) in die Daten reingucken können zu Diagnosezwecken.
Also bringst mir nix, wenn ich per Batch-Input genau das mache, was ohnehin gemacht werden soll, aber nicht funktioniert Es geht wirklich nur darum, die Daten mal zu SEHEN, wie sie aus der Quelle kommen, damit man diagnostizieren kann, ob die sendende Anwendung Mist gebaut hat.
Der Hintergrund ist, dass der Anwender nur sehen kann, dass der BI nicht funktioniert, mit den technischen Details aber nix anfangen kann - ICH will aber ohne Breakpoint in die Daten gucken können und die Kollegen aus der Java-Truppe auch (wenn ich denen mit Debugger komme, treten die mir ins Kreuz).Thomas17 hat geschrieben:Aber Du siehst doch dann im BI welche Daten Mist sind. Wenn Du die Daten im Vorfeld als ALV oder auch nur als Reportausgabe rauslässt, muss der Fehler ja gesucht und gefunden(!) werden. Der BI sagt Dir doch was falsch ist (im E - Mode werden Dir doch die Fehler angezeigt, Kundennummer existiert nicht, etc.).
So wie ich das sehe wird die nächste Anfrage an Dich sein - "Schön jetz sehen wir die Daten - aber wo ist der Fehler? Können Sie nicht den Fehler noch darstellen und gleich ein Warnsignal mit Blinklicht ausgeben?"
Code: Alles auswählen.
CALL TRANSACTION 'VA01' USING gt_bdcdata[] MODE 'E' UPDATE 'S'.
Je nachdem wo welcher "Fehler" auftaucht sehe ich aber nicht alle Daten.Thomas17 hat geschrieben:Dann bleibt der BI doch dort stehen wo der Fehler auch tatsächlich ist.
Ist halt nix für asynchrone Verarbeiten - so wie ich Dich verstehe passiert das aber eh im Dialog,
damit ja noch Daten ergänzt werden können.
jo - dann sehe ich den ersten Fehler, korrigiere diesen und dann kommt der nächste, sofern änderbar... schon klar.JHM hat geschrieben:Wenn ein "Fehler" in der ersten Position auftritt, siehst du die anderen Positionen erst mal nicht!