Also, zunächst einmal habe ich hier niemanden als unfähig hingestellt, schon deshalb nicht, weil sich meine Aussagen auf keine Person bezogen. Es ist mir ein Rätsel, warum sich hier Leute persönlich angesprochen fühlen, an die ich beim Schreiben nichtmal gedacht habe.
Ich bleibe dabei, dass Batch-Input in aller Regel die bestenfalls zweitbeste Möglichkeit, Daten ins System zu kriegen. Ich füge meinem Posting daher folgende Aussagen an:
* Warum ist Batch Input veraltet / nicht zukunftsfähig?
Weil die Zukunft offensichtlich der OO-Zweig von ABAP ist (man mag über den streiten wie man will) man kriegt keine modernen Controls ohne OO-Befehlssatz mehr hin - die sind aber allesamt nicht Batchinput-fähig.
* Warum ist eine "eigene" Verbuchung besser?
Man muss unterscheiden zwischen der technischen/kaufmännischen Prüfung und der, die nur Usability erzeugt. Felder auszublenden, weil der Anwender sie nicht braucht, ist nur dann sinnvoll, wenn wirklich ein Anwender vor dem System sitzt. Und wer welches Feld sieht, pflegt man dann schön abteilungsweise oder gar benutzerweise getrennt. Sowas ist in einem Batch-Input nur hinderlich (das meinte ich mit "ich weiß ja gar nicht welche Felder der Anwender sieht"). So muss ich aufwendig Feldsteuerungsregel lesen und meinen Programmlauf davon abhängig machen, was da im Customizing steht. Da ist es mir in meinem Programm lieber, wenn alle Felder offen sind und ich unabhängig von der User-ID die Daten reinschreiben kann, die gebraucht werden.
* Warum ist Batch-Input nicht wartungsfreundlich?
Es gibt nicht nur Transaktionen, die anders aussehen, sondern auch Transaktionen, die ein ganz anderes Programmverhalten im Batch-Input zeigen. Da habe ich nicht eben wenige mit ihrer Aufzeichnung verzweifeln sehen, wenn die dann trotzdem nicht funktioniert.
Viele Dinge gehen auch im Batch-Input gar nicht, weil im Batch-Input der Zeitpunkt der Mappenerstellung losgelöst ist vom Zeitpunkt des Mappenlaufs. Es ist nicht immer einfach/möglich, bei der Mappenerstellung zu berücksichtigen, was erst beim Mappenlauf eintritt.
Das leidige Thema "Performance" will ich gar nicht erst ansprechen.
* Aber die SAP macht das doch auch teilweise noch!
Ehrliche Meinung dazu? Das ist mir egal. Nicht alles, was die SAP macht, muss in meinen Augen richtig sein. Das ist auch umgekehrt nicht anders, der SAP muss nicht alles gefallen, was ich mache. Das gilt übrigens auch für die Forenmitglieder, die meine Postings lesen
Die mögen zum Teil anderer Meinung sein, das ist nicht mehr als normal.
* Warum geht es hier um moderne und unmoderne Arbeitstechniken?
Es gibt Dinge, die "tut man nicht mehr" und das ist auch gut so, auch ABAP entwickelt sich weiter. Deklarationen wie "data: feld like ddictable-feld" sind mir ein Graus, weil sich Tabellen ändern, nicht zuletzt sind Sprachkonstrukte (auch dieses) im OO-Kontext nicht mehr zulässig, worauf man auch hingewiesen wird (wie zum Beispiel auch "TABLES" in FuBau-Schnittstellen).
Wenn man sich überlegt, wie alt die Batch-Input-Technik ist und welchen Stand SAP-Transkationen damals hatten, kann man durchaus sagen, dass es eine auch für Neulinge einfach zu verstehende Technik war, ein Programm zu befüllen. Man musste sich nicht mit den Innereien des Systems beschäftigen. Transaktionen sind heute aber ungleich komplexer, haben tlw. Unmengen von Subscreens und nicht selten ist ein Dynpro im Screen-Painter komplett leer, weil erst zur Laufzeit festgestellt wird, welches Subdynpro und welches Feld überhaupt eingeblendet wird. Und dann hab ich für jede Kreditorengruppe eigene, durch IF/ELSE abgegrenzte Programmläufe.
Die Entwicklerlandschaft ist auch eine vollkommen andere als heute, ein Punkt den man dabei nicht vergessen darf. Die Masse der Entwickler arbeitet heute durchweg schon deshalb professioneller, weil sie von vorn herein anders ausgebildet werden. Das liegt in der Natur der Sache.
Gruß
Ralf
BTW: Grundsätzlich lehne ich die Wartung von Batch-Inputs ab.
