Ich nehme mir mal ein schlankes Thema vor. Das ist kurz und knackig und man braucht es immer nur genau einmal. Daher heißt es; Aufwand reduzieren.
Während mir eine Kollegin vorschlug, die Kontenfindung für die Ertragskontierung doch für die Migration anzupassen (Migrationskontenfindung ins Produktionssystem schießen, Migration durchführen, Kontenfindung zurück auf „Original“ setzen), schwebt mir seit 2004 die gute alte Methode vom Event V050 durch den Kopf.
Was hat es damit auf sich? Das Event V050 wird bei jeder Buchung über die Zahlplanschnittstelle durchlaufen. Hierbei wird bei jeder erstellten DFKKOP-Zeile und jeder DFKKOPK-Zeile hier gestoppt.
Will ich ein spezielles Migrationskonto benutzen, um die Ertragskontierung zu verhindern und statt dessen auf ein Zwischenkonto zu kontieren, kann ich also immer dann, wenn die DFKKOPK-Seite hier Halt macht, ein anderes Konto angeben. Fragt sich nur noch, woran man die Unterscheidung zwischen „normaler“ Buchung und Migrationsbuchung festmachen will? Ich argumentiere immer damit, dass ein eigener Migrationsuser eine tolle Sache ist. Aber auch eine Datumsabgrenzung (Buchungsdatum < xx.xx.xxxx) ist denkbar, wobei nicht ganz so flexibel in den Testmigrationen. Ginge noch über eine TVARV-Variable zu flexibilisieren. Aber in jedem Fall besser, als eine komplexe Kontenfindung zu überschreiben und Angst haben zu müssen, dass hinterher der Produktivbestrieb falsch bucht. Der 5-Zeiler ist mir lieber:
Case i_struct.
when ‚DFKKOPK‘.
if sy-uname = ‚MIGRATION‘.
i_fkkopk-hkont = ‚0815‘. „Migrationskonto.
endif.
endcase.