ein Kunde aus Osteuropa hat die Anforderung, die TA SP01 als Hintergrundjob laufen zu lassen.
Grundsätzlich spricht dagegen, dass sie nicht variantenfähig ist und dass es auch kein ausführbares Programm ist, sondern ein Modulpool.
Mein erster Ansatz war, ein Caller-Report zu schreiben, der die SP01 aufruft. Dass funktioniert auch perfekt im Dialog. Im Hintergrund dagegen, wird kein Spoolauftrag erzeugt, vermutlich springt die SP01 gleich nach ihrem Aufruf zurück in den Caller.
Da der Kunde unbedingt die SP01 haben will, bin ich nun zu dem Schluss gekommen, die SP01 zu kopieren und die standard Fcodes der Variantenverwaltung zu implementieren (was nach Test im Hoppelmodus auch geht).
Was mir noch fehlt ist: Kann ich den Programmmtypen der SP01 ohne weiteres ändern?
In den zugrundeliegenden Sourcen sind die Selektionsbilder per Code definiert, ebenso PAI und PBO Routinen.
Die Sinnfrage braucht man dem Kunden nicht zu stellen, meiner Meinung nach ist es egal, ob er nun doe SP01 ausführt oder nach der Batchverarbeitung die
TA SMX.
ewx hat geschrieben:Was will der Kunde mit einem Hintergrundjob erreichen??
Mein Kenntnisstand ist, dass er jeden Tag eine Liste der Spoolaufträge mit unterschiedlichen Mehrfachselektionen generieren will, einschließlich der
normalen Absprungmöglichkeiten in die Spoolaufträge. Er hat vor, diverse Ausgaben zu kontrollieren und auszuwerten, es ist ein europäisches R/3 mit zig Standorten.
Dann würde ich doch lieber einen kleinen Report um den Funktionsbaustein RSPO_ISELECT_SPOOLREQS drumherum schreiben.
Die SP01 kopieren wäre ja so, als wenn du die VA02 kopieren wolltest, um Texte anzuzeigen...
Nicht ganz, die SP01 ist sehr überschaubar (1753 Zeilen, nur 3 Definitionsincludes, 6 Screens) und das Variantenhandling klappt
auch ganz gut, wenn ich sy-ucomm im Debugger setze.
Der Funktionsbaustein bringt zwar die Spoolliste, aber die Absprünge in die
Listaufbereitung inkl. der korrekten Druckaufbereitung (einschließlich OTF) müsste dann auch dazu programmiert werden.