black_adept hat geschrieben:Wenn du für einen Sack voll Materialien alle eine Stock-Requirement-Analyse von SAP zurückgeben lässt wundern mich lange Laufzeiten nicht sonderlich. Aber ich wüsste auch nicht wie du das umgehen willst.
Je nach angelgegten Orgebenen wird die Stock-Requirement-Analyse für ein Material mehrfach aufgerufen: Anzahl VKorgs * Anzahl Bewertungskreise.
Auch die vielen einzelnen SELECTS in den FORMS sind nicht optimal, da könnte man mit geschickten FOR ALL ENTRIES und READ BINARY auch noch ein wenig Performance raus hohlen.
SELECT * mit INTO CORRESPONDING: Wenn nicht alle gelesenen Felder verwendet werden. Wieso nicht die gewollten Felder explizit angeben? Das verbessert mMn auch die Lesbarkeit des Selects.
FIELD-SYMBOLES beim LOOP verwenden, spart das spätere MODIFY .
READ_DATA wird bei jedem PBO durchlaufen, sollte aber auch nur einmal durchlaufen werden analog dem CREATE go_custom_container.
Wieso ein Dynpro, wenn dann doch ein SALV als "Full-Screen" aufgerufen wird? Der SALV bringt das Dynpro doch schon mit.
Zur verwendeten Notation:
Wenn schon eine Notation genutzt wird, sollte sie auch aussagekräftig sein:
s_werks ist zwar eine SelectionScreenVariable, aber keine SelOpt sondern ein Parameter.
go_ vs. gr_ vs. gcl_: Wann wird was verwendet?
ls_ für globale Daten.
Sprechende Namen für Deklarationen verwenden: itab01, itab02, itab03, itab04 ist nichts sagend ohne ewig zu scrollen.