Ansicht
Dokumentation

RKE_CHACO_PAOBJNR_2 - Umsetzen CO-Objekte für buchhalterische Ergebnisrechnung

CL_GUI_FRONTEND_SERVICES - Frontend Services   TXBHW - Original Tax Base Amount in Local Currency  
Diese Dokumentation steht unter dem Copyright der SAP AG.

ACHTUNG: Dieses Programm sollte nur nach Absprache mit der CO-PA-Entwicklung verwendet werden. Es ist sicherzustellen, dass vor dem Einsatz des Programms in einem Produktivsystem eine Datensicherung des gesamtem Systems erstellt worden ist.

Verwendung

Das Programm kann zum Einsatz kommen, falls aufgrund von Änderungen in der Organisationsstruktur eines Unternehmens die Zuordnung zwischen Kostenrechnungskreisen und Ergebnisbereichen geändert werden soll.

Genauer kann es für den Fall verwendet werden, daß ein oder mehrere Ergebnisbereiche durch genau einen neuen Ergebnisbereich ersetzt werden sollen.

Integration

Im Rahmen der Werteflüsse des ERP-Systems wird für Belegzeilen, die in die Ergebnisrechnung CO-PA gebucht werden, in den Belegtabellen der Module SD, FI, MM bzw.CO im Feld PAOBJNRdie sogenannnte Ergebnisobjektnummer fortgeschrieben.

Der Ergebnisbereich, in dem diese Ergebnisobjektnummer Gültigkeit besitzt, bestimmt sich indirekt aus den in den Belegtabellen gespeicherten Organisationseinheiten, sowie aus der im Customizing hinterlegten Unternehmensstruktur.

Wird in einem System die Zuordnung zwischen Kostenrechnungskreisen und Ergebnisbereichen nachträglich geändert, so können anschließend die vor dieser Zuordnungsänderung in den Belegtabellen abgelegten Ergebnisobjekte vom System nicht mehr korrekt interpretiert werden.

Aufgrund der geänderten Zuordnung der Kostenrechnungskreise wird ein betroffenes Ergebnisobjekt fälschlicherweise im neuen Ergebnisbereich gesucht, obwohl es ursprünglich im alten Ergebnisbereich angelegt wurde und nur in diesem Ergebnisbereich interpretiert werden kann.

Beim Versuch, eine gegebene Ergebnisobjektnummer mit Bezug auf einen falschen Ergebnisbereich zu interpretieren, können zwei Fälle unterschieden werden. Existiert die Ergebnisobjektnummer im neuen Ergebnisbereich nicht, so kommt es in diesem Fall regelmäßig zu einem Short Dump mit der Meldung KE499. Existiert hingegen im neuen Ergebnisbereich zufällligerweise ein Ergebnisobjekt mit der gleichen Nummer, so arbeitet das System mit den Merkmalsausprägungen dieses Ergebnisobjekts. Dies führt dann entweder zu Folgefehlern in der weiteren Belegverarbeitung oder schlimmstenfalls zur Fortschreibung falscher Daten in der Ergebnisrechnung.

Dieses Problem kann mit Hilfe des Programms RKE_CHACO_PAOBJNR_1 gelöst werden. Das Programm ersetzt systematisch in den Belegtabellen der Module SD, FI, MM bzw.CO die Ergebnisobjekte des alten Ergebnisbereichs durch solche des neuen.

Ein ähnliches Problem tritt bei aktivierter buchhalterischer Ergebnisrechnung für die in den CO-Tabellen

• COEP,,,,(Ist-Einzelposten)

• COEJ,,,,(Plan-Einzelposten)

• COSP,,,,(Summensätze Primärkostenarten)

• COSS,,,,(Summensätze Sekundärkostenarten)

abgelegten Kostenrechnungsbelege, die eine Kontierung auf Ergebnisobjekt besitzen, auf.

Diese enthalten in verschiedenen Feldern sogenannte CO-Objekte, die eine kostenrechnungsrelevante Kontierung verschlüsseln. Kontierungen auf Ergebnisobjekt haben die Form 'EOXXXXYYYYYYYYYY', wobei 'XXXX' den Ergebnisbereich und 'YYYYYYYYYY' eine Ergebnisobjektnummer bezeichnet.

Wird ein Ergebnisbereich ersetzt, steht folglich in den Kostenrechnungsbelegen, die eine Kontierung auf ein Ergebnisobjekt dieses Ergebnisbereichs aufweisen, in den Feldern für die CO-Objekte ein falscher Ergebnisbereich und eine Ergebnisobjektnummer aus diesem Ergebnisbereich.

Um dieses Problem zu lösen, kann das Programm RKE_CHACO_PAOBJNR_2 nach vorheriger Durchführung des Programms RKE_CHACO_PAOBJNR_1 verwendet werden.

Mit Hilfe des Programms RKE_CHACO_PAOBJNR_1 werden zunächst die Ergebnisobjekte des alten Ergebnisbereichs in den Belegtabellen des SD, FI, MM bzw. CO systematisch durch solche des neuen Ergebnisbereichs ersetzt. Das Programm RKE_CHACO_PAOBJNR_2 kopiert dann die Kostenrechnungsbelege, die eine Kontierung auf ein Ergebnisobjekt des alten Ergebnisbereichs besitzen, aus den genannten CO-Tabellen in temporäre Tabellen und ersetzt dort den alten durch den neuen Ergebnisbereich. Die zugehörigen Ergebnisobjektnummern des alten Ergebnisbereichs werden durch solche des neuen Ergebnisbereichs ersetzt. Das Programm verdichtet anschließend die Summensätze neu und schreibt die Daten wieder in die CO-Tabellen zurück. Beide Programme können dabei Daten mehrerer alter Ergebnisbereiche, die dem gleichen neuen Ergebnisbereich zugeordnet werden sollen, im gleichen Lauf konvertieren.

Allerdings können mit Hilfe des Programms RKE_CHACO_PAOBJNR_2 kalkulatorische Bewegungsdaten nicht umgesetzt werden. Hierzu verwenden Sie bitte das Programm COPA_COPY.

Voraussetzungen

In den alten Ergebnisbereichen und dem neuen Ergebnisbereich muß für die Ausführung des Programms die buchhalterische Ergebnisrechnung aktiviert sein.

Es werden folgende Szenarien für die Änderung der Zuordnung zwischen Kostenrechnungskreisen und Ergebnisbereichen unterstützt:

1. Ein Ergebnisbereich soll durch einen anderen ersetzt werden. Alle Kostenrechnungskreise, die dem alten Ergebnisbereich zugeordnet waren, werden einem neuen Ergebnisbereich zugeordnet.
2. Mehrere Kostenrechnungskreise, die mehreren Ergebnisbereichen zugeordnet waren, sollen einem neuen Ergebnisbereich zugeordnet werden.

Die nachfolgenden Beispiele sollen dies für die Kostenrechnungskreise '1000' und '2000', sowie die Ergebnisbereiche 'C001', 'D001' und 'E001' verdeutlichen.

Beispiel 1
Alte Zuordnungen	Neue Zuordnungen
	1000 --> C001	1000 --> E001
	2000 --> C001	2000 --> E001

Beispiel 2
Alte Zuordnungen	Neue Zuordnungen
	1000 --> C001	1000 --> E001
	2000 --> D001	2000 --> E001

Beachten Sie, daß immer alle einem alten Ergebnisbereich zugeordneten Kostenrechnungskreise umgehängt werden müssen und daß alle dem gleichen neuen Ergebnisbereich zuzuordnen sind.

Funktionsumfang

Das Programm ist für alle zu ersetzenden Ergebnisbereiche pro Geschäftsjahr auszuführen.

In einem ersten Schritt können mit Hilfe des Programms Kopien der CO-Tabellen COEP, COEJ, COSP und COSS im Kundennamensraum 'Z*' für jedes Geschäftsjahr angelegt werden. Diese Kopien erhalten für jedes Feld, das potentiell ein CO-Objekt enthalten kann, ein zusätzliches Feld, in das später die umgesetzten CO-Objekte zunächst geschrieben werden.

In diese 'Z*'-Tabellen werden die zu einem Geschäftsjahr gehörigen Kostenrechnungsbelege, die eine Kontierung auf ein Ergebnisobjekt der alten Ergebnisbereiche aufweisen, kopiert.

Ein dritter Schritt konvertiert die Daten, d.h er ersetzt in den CO-Objekten mit Kontierung auf ein Ergebnisobjekt der alten Ergebnisbereiche den alten durch den neuen Ergebnisbereich. Außerdem werden die Ergebnisobjektnummern der alten Ergebnisbereiche durch solche des neuen Ergebnisbereichs ersetzt. Die umgesetzten CO-Objekte werden allerdings zunächst in die für die CO-Objekte angelegten Zusatzfelder kopiert.

Der nächste Schritt liest die umgesetzten Daten aus den 'Z*'-Tabellen, füllt die Originalfelder der CO-Objekte, falls notwendig, mit den umgesetzten CO-Objekten und schreibt diesen Datenbestand ebenfalls in die 'Z*'-Tabellen. Zusätzlich wird der aus den Summentabellen COSP und COSS kopierte Datenbestand neu verdichtet, da es passieren kann, daß Summensätze mit verschiedenem Schlüssel durch die Konvertierung einen identischen Schlüssel erhalten.

Daraufhin können die Daten aus den 'Z*'-Tabellen in die CO-Tabellen COEP, COEJ, COSP und COSS zurückgeschrieben werden. Die ursprünglich kopierten Sätze werden dabei aus den CO-Tabellen gelöscht.

Schließlich können die Daten aus den kopierten 'Z*'-Tabellen gelöscht und auch deren Tabellendefinition aus dem Data Dictionary entfernt werden.

Aktivitäten

Vorab können Sie zunächst das Datenvolumen für die umzusetzendenTabellen COEP, COEJ, COSP und COSS für die alten Ergebnisbereiche pro Geschäftsjahr bestimmen, um einen Überblick über die Anzahl der zu kopierenden Tabellenzeilen zu erhalten. Wählen Sie hierzu auf dem Selektionsbildschirm den Menüpunkt

,,'Zusätze --> Datenvolumen bestimmen'

und beantworten Sie die Abfrage, ob Sie fortfahren möchten, mit 'Ja'. Geben Sie die gewünschte Kombination 'Geschäftsjahr' / 'Alte Ergebnisbereiche'ein. Da die Bestimmung des Datenvolumens längere Zeit in Anspruch nehmen kann, muß sie im Hintergrund gestartet werden. Das Programm erstellt einen Job ZZRKE_CHACO_CHECK_SIZE_2, für den Sie auf dem folgenden Bild einen Starttermin auswählen können. Der Job wird automatisch eingeplant und freigegeben. Die Ergebnisse werden in der Spoolliste des Jobs gesichert, die Sie über den Menüpunkt

,,'Springen --> Job-Übersicht'

erreichen können.

Nachfolgend werden die Schritte beschrieben, die für die Durchführung des Programms notwendig sind.

Schritt 1

Führen Sie das Programm RKE_CHACO_PAOBJNR_1 für die Kombination aus alten Ergebnisbereichen und neuem Ergebnisbereich aus.

Schritt 2

Stellen Sie sicher, daß während der Ausfühung des Programms RKE_CHACO_PAOBJNR_2 im System keine Belege gebucht werden.

Schritt 3

Starten Sie das Programm RKE_CHACO_PAOBJNR_2 für die Kombination aus alten Ergebnisbereichen und neuem Ergebnisbereich für jedes Geschäftsjahr.

Dabei sind auf dem Selektionsbild folgende Bereiche auszufüllen:

'Ergebnisbereiche'

'Alte Ergebnisbereiche' / 'Neuer aktiver Ergebnisbereich':

Geben Sie hier die zu ersetzenden alten Ergebnisbereiche, sowie den neuen aktiven Ergebnisbereich ein.

Beispiel

Alte Zuordnungen	Neue Zuordnungen
1000 --> C001	1000 --> E001
2000 --> D001	2000 --> E001

In diesem Fall ist das Programm lediglich für die Kombination 'C001' / 'D001' ('Alte Ergebnisbereiche') und 'E001' ('Neuer aktiver Ergebnisbereich') zu starten.

'Weitere Selektionen'

'Geschäftsjahr':

Geben Sie hier das umzusetzende Geschäftsjahr ein.

'Steuerparameter'

'Testlauf':

Bei dieser Option wird das Programm ist Testlauf für den im Bereich 'Bearbeitungsschritte'ausgewählten Schritt ausgeführt. Die Verarbeitung kann im Vordergrund oder im Hintergrund erfolgen. Das Programm erzeugt ein Protokoll und gibt Fehler aus, wenn solche aufgetreten sind. Um das Protokoll übersichtlich zu halten wird die Verarbeitung beendet, falls mehr als einhundert Fehler aufgetreten sind.

In diesem Modus werden keine Datenbankänderungen vorgenommen. Das Programm merkt sich, für welchen Schritt der Testlauf gestartet wurde und ob er ohne Fehler durchgelaufen ist.

'Echtlauf':

Bei dieser Option wird das Programm im Echtlauf für den im Bereich 'Bearbeitungsschritte'ausgewählten Schritt ausgeführt. Die Verarbeitung sollte im Hintergrund gestartet werden, da sonst die Gefahr eines Time Out besteht.

Das Programm läßt sich nur dann im Echtlauf ausführen, wenn zuvor bereits ein Testlauf für den ausgewählten Schritt ohne Fehler durchgelaufen ist.

Auch hier merkt sich das Programm, für welchen Schritt der Echtlauf gestartet wurde und ob er ohne Fehler durchgelaufen ist.

'Sperren Ergebnisbereich (für Option 'Echtlauf')':

Diese Option ist nur im 'Echtlauf' verfügbar. Sie sperrt den alten und den neuen aktiven Ergebnisbereich gegen Buchungen. Benutzer, die in diese Ergebnisbereiche buchen möchten, erhalten eine entsprechende Fehlermeldung.

'Ableitung im neuen aktiven Erg.ber. aufrufen':

Diese Option ermöglicht es, den umgesetzten Merkmalsvektor im neuen aktiven Ergebnisbereich neu abzuleiten (siehe unten 'Umsetzen der Ergebnisobjekte').

'Merkmale im neuen aktiven Erg.ber. verproben':

Diese Option ermöglicht es, für den umgesetzten Merkmalsvektor im neuen aktiven Ergebnisbereich eine Merkmalswertverprobung durchzuführen (siehe unten 'Umsetzen der Ergebnisobjekte').

'User-Exit für Feldzuordnung':

Diese Option ermöglicht es, über einen User-Exit die Merkmalszuordnung zwischen alten Ergebnisbereichen und neuem aktiven Ergebnisbereich individuell zu gestalten (siehe unten 'Umsetzen der Ergebnisobjekte')

'Identifizierung':

Diese Option ist nur verfügbar, falls die Auswahlmöglichkeit 'User-Exit für Feldzuordnung' eingestellt wurde. Sie ermöglicht es, den User-Exit eindeutig zu identifizieren.

Umsetzen der Ergebnisobjekte:

Im folgenden wird beschrieben nach welcher Logik ein in einem alten Ergebnisbereich angelegtes Ergebnisobjekt in eines des neuen aktiven Ergebnisbereichs überführt wird.

Bitte beachten Sie, daß im Programm grundsätzlich zunächst immer ein MOVE-CORRESPONDING zwischen gleichnamigen Feldern des alten und des neuen aktiven Ergebnisbereichs durchgeführt wird.

Zusätzlich besteht die Möglichkeit, CO-PA-Merkmale nach einer in einem User-Exit hinterlegten Logik aus dem alten in den neuen aktiven Ergebnisbereich zu übernehmen. Der Exit wird, falls aktiviert, für jedes Ergebnisobjekt nach dem MOVE-CORRESPONDING Schritt angesprungen. Felder des neuen aktiven Ergebnisbereichs, die über die MOVE-CORRESPONDING-Logik bereits gefüllt wurden, können im Exit nachträglich verändert werden.

Um den Exit zu aktivieren muß in Tabelle TKEEXITS ein Eintrag eingefügt werden. Die Tabelle kann über Transaktion SE16 wie folgt gepflegt werden:

EXITID	'KE_CHACO_CE4'
	APPL	'KE'
	SEQNO	'001'
	ISACTIVE	'X'
	REPORT	Programmname eines ZZ...-Programms
	FORM	Name einer Formroutine in Programm REPORT

Damit der Exit überhaupt angesprungen wird, muß das Flag 'User-Exit für Feldzuordnung' gesetzt werden. Im dahinterliegenden Feld 'Identifizierung' ist dann ein dreistelliges Kürzel zu hinterlegen.

Die Implementierung des Exit-Logik erfolgt in der Formroutine FORM des Programms REPORT. Übergabeparameter der Formroutine sind die folgenden sechs Parameter in der hier angegebenen Reihenfolge:

• Alter Ergebnisbereich

• Neuer aktiver Ergebnisbereich

• Identifizierung für den Exit: Es wird die auf dem Selektionsbild eingegebene Kennung des Exits übergeben.

• Kennzeichen, ob der Exit aktiv ist und bei den folgenden Durchläufen noch aufgerufen werden soll: Dieses Kennzeichen ist im Coding zu setzen, damit der Exit für die nachfolgenden Ergebnisobjekte weiterhin aufgerufen wird.

• Merkmalsvektor des alten Ergebnisbereichs: Der Merkmalsvektor wird in der Struktur CE4XXXX übergeben, wobei 'XXXX' den alten Ergebnisbereich bezeichnet.

• Merkmalsvektor des neuen aktiven Ergebnisbereichs nach dem MOVE-CORRESPONDING-Schritt:
  Der Merkmalsvektor wird in der Struktur CE4YYYY übergeben, wobei 'YYYY' den neuen aktiven Ergebnisbereich bezeichnet.

Beispiel :

Wenn

• 'S001' den alten Ergebnisbereich

• 'IDEA' den neuen aktiven Ergebnisbereich

• 'ABC' die Identifizierung des User-Exits

bezeichnet und das Merkmal 'Kunde' (KNDNR) im neuen aktiven Ergebnisbereich immer dann auf '0000001001' gesetzt werden soll, wenn es im alten Ergebnisbereich die Ausprägung '0000001000' hat, könnte eine Implementierung des Exits folgendes Aussehen haben:

Eintrag in Tabelle TKEEXITS:

EXITID	'KE_CHACO_CE4'
	APPL	'KE'
	SEQNO	'001'
	ISACTIVE	'X'
	REPORT	ZZKE_CHACO_CE4
	FORM	MODIFY_CHARACTERISTICS

Implementierung des Exits in Programm ZZKE_CHACO_CE4:

REPORT ZZKE_CHACO_CE4.

....
FORM MOVE_CHARACTERISTICS
  CHANGING I_ERKRS_OLD   LIKE TKEBB-ERKRS
           I_ERKRS_NEW   LIKE TKEBB-ERKRS
           I_EXITID      TYPE KEDRSTEPID
           I_EXIT_ACTIVE TYPE C
           IS_CE4_OLD    TYPE ANY
          IS_CE4_NEW    TYPE ANY.

  DATA: LS_CE4S001 LIKE CE4S001,
        LS_CE4IDEA LIKE CE4IDEA.

  CASE I_EXITID.
    WHEN 'ABC'.
      IF I_ERKRS_OLD = 'S001' AND I_ERKRS_NEW = 'IDEA'.
        I_EXIT_ACTIVE = 'X'.,,,,"Activate for further processing
        LS_CE4S001 = IS_CE4_OLD.
        LS_CE4IDEA = IS_CE4_NEW.
        IF LS_CE4S001-KNDNR = '0000001000'.
          LS_CE4IDEA-KNDNR = '0000001001'.
        ENDIF.
        IS_CE4_NEW = LS_CE4IDEA.,,,,"Return characteristics of the
,,,,,,,,,,,,,,"new active operating concern
      ENDIF.
  ENDCASE.

ENDFORM.
....

Falls das Flag 'Ableitung im neuen akt. Erg.ber. aufrufen' ausgewählt wurde, wird nach dem Durchlaufen des Exits für den ermittelten Merkmalsvektor die Merkmalsableitung im neuen aktiven Ergebnisbereich durchlaufen.

Tritt bei der Merkmalsableitung ein Fehler auf, wird dieser ins Protokoll geschrieben. Beim 'Echtlauf' wird mit dem unabgeleiteten Merkmalsvektor eine Ergebnisobjektnummer im neuen aktiven Ergebnisbereich bestimmt. Gegebenenfalls können die Ergebnisobjekte, für die ein Fehler aufgetreten ist, im neuen aktiven Ergebnisbereich durch Zuordnungsänderungen angepaßt werden.

Um die Merkmalswerte auf ihre Gültigkeit zu verproben, kann das Flag 'Merkmale im neuen akt. Erg.ber. verproben'gesetzt werden. Die Verprobung findet nach Aufruf des Exits und vor der Merkmalsableitung statt. Eine Verprobung der Merkmalswerte ist nur sinnvoll, wenn der User-Exit zum Einsatz kommt. Werden in der Ableitung Merkmalswerte geändert, prüft die Ableitung deren Existenz automatisch.

Wie bei der Ableitung wird eine Fehlermeldung ins Protokoll geschrieben. Das Programm fährt trotz Fehlermeldung mit der Verarbeitung fort.

Sinnvollerweise sollte bei Verwendung des User-Exits für die Programme RKE_CHACO_PAOBJNR_1 und RKE_CHACO_PAOBJNR_2 der gleiche Exit verwendet werden, um eine einheitliche Umsetzung der Merkmalswerte zu gewährleisten.

'Tabellen' (siehe unterhalb von Bereich 'Bearbeitungsschritte')

'Kopie von Tabelle COEP' / 'Kopie von Tabelle COEJ' / 'Kopie von Tabelle COSP' / 'Kopie von Tabelle COSS':

Geben Sie hier die für die gewählte Kombination von alten Ergebnisbereichen und neuem aktiven Ergebnisbereich, sowie Geschäftsjahr gewählten Tabellennamen im Kundennamensraum 'Z*'ein. Das Programm macht dabei folgende Vorschläge:

COEP	-->	ZZTKECOEP	(Ist-Einzelposten)
	COEJ	-->	ZZTKECOEJ	(Plan-Einzelposten)
	COSP	-->	ZZTKECOSP	(Summensätze Primärkostenarten)
	COSS	-->	ZZTKECOSS	(Summensätze Sekundärkostenarten)

Diese Namen können entsprechend abgeändert werden, so daß z.B. die Tabellennamen das Geschäftsjahr enthalten, falls mehrere Geschäftsjahre umzusetzen sind.

'Entwicklungsklasse':

Geben Sie hier die Entwicklungsklasse ein, in der die Kopien von Tabelle COEP, COEJ, COSP und COSS angelegt werden sollen. Das Programm schlägt automatisch die lokale Entwicklungsklasse '$TMP' vor. Sie können jedoch auch eine Entwicklungsklasse im Kundennamensraum 'Z*'verwenden. Dies kann insbesondere dann sinnvoll sein, wenn Sie die Tabellendefinition für die Kopien von Tabelle COEP, COEJ, COSP und COSS in einem Quellsystem anlegen und anschließend in andere Systeme transportieren möchten.

'Bearbeitungsschritte'

Führen Sie das Programm für die gewählte Kombination von alten Ergebnisbereichen und neuem aktiven Ergebnisbereich, Geschäftsjahr, Namen der 'Z*'-Tabellen, sowie der entsprechenden Zusatzoptionen, für die nachfolgend beschriebenen sieben Schritte A bis G aus.

Da die Schritte aufeinander aufbauen prüft das Programm beim Ausführen eines Schrittes, ob der vorherige Schritt bereits erfolgreich im Echtlauf durchgeführt wurde und gibt ansonsten eine Fehlermeldung aus.

Schritt A: 'Tabellendefinition kopieren':

In diesem Schritt erstellt das Programm Kopien der Tabellen COEP, COEJ, COSP und COSS unter den im Bereich 'Tabellen'angegebenen Namen im Kundennamensraum 'Z*'.

Für jedes Tabellenfeld FIELDNAME, das potentiell ein CO-Objekt mit Kontierung auf Ergebnisobjekt enthalten könnte, wird ein neues Feld mit dem Namen NEW_FIELDNAMEan die jeweilige 'Z*'-Tabelle angehängt, in das im Schritt 'Daten konvertieren' die umgesetzten CO-Objekte geschrieben werden.

Diese Tabellenfelder sind im einzelnen für Tabelle

COEP	-->	OBJNR / PAROB / PAROB1 / USPOB / OBJNR_N1 / OBJNR_N2 / OBJNR_N2 / OBJNR_HK
	COEJ	-->	OBJNR / PAROB / PAROB1 / USPOB
	COSP	-->	OBJNR
	COSS	-->	OBJNR / PAROB / USPOB

Desweiteren wird an jede 'Z*'-Tabelle ein Indexfeld INDEXOBJNR angehängt, das der Wiederaufsetzbarkeit dient, sowie ein zusätzliches Schlüsselfeld UPDATED eingefügt, das für die interne Verarbeitung notwendig ist.

Schritt B: 'Daten kopieren':

Bei diesem Schritt kopiert das Programm die Daten aus den CO-Tabellen COEP, COEJ, COSP und COSS in die entsprechenden 'Z*'-Tabellen in Paketen von 100000 Sätzen.

Es werden alle Daten für das selektierte Geschäftsjahr kopiert, die in einem der in Schritt A aufgeführten Felder einen der alten Ergebnisbereiche verschlüsselt haben. Jeder Satz erhält im Feld INDEXOBJNR der 'Z*'-Tabelle einen eindeutigen Index.

Das Programm ist in diesem Schritt zwar wiederaufsetzbar, falls z.B. aufgrund von Datenbankproblemen ein Programmabbruch auftritt, allerdings nicht im eigentlichen Sinne, d.h. beim Wiederaufsetzen fängt es nicht an der Stelle des Abbruchs an, sondern beginnt mit diesem Schritt nochmals von vorne. Grund ist, daß die Datenbank bei der Selektion der Daten diese nicht immer in der gleichen Reihenfolge zurückliefert, so daß sich das Programm nicht merken kann, welche Daten bereits in die 'Z*'-Tabellen gebucht wurden und welche nicht. Allerdings merkt sich das Programm, wenn eine der CO-Tabellen COEP, COEJ, COSP und COSS bereits vollständig kopiert wurde. Diese wird dann nicht nochmals kopiert.

Schritt C: 'Daten konvertieren':

Bei diesem Schritt prüft das Programm die in Schritt A aufgeführten Felder der 'Z*'-Tabellen in Paketen von 100000 Sätzen aufsteigend nach ihrem Index im Feld INDEXOBJNR.

Findet es in einem Feld FIELDNAME ein CO-Objekt der Form 'EOXXXXYYYYYYYYYY', wobei 'XXXX' einen der alten Ergebnisbereiche und 'YYYYYYYYYY' eine Ergebnisobjektnummer bezeichnet, liest es zu Ergebnisobjektnummer 'YYYYYYYYYY' in Ergebnisbereich 'XXXX' die Merkmalswertausprägungen. Das Programm ersetzt den alten Ergebnisbereich 'XXXX' durch den neuen aktiven Ergebnisbereich 'ZZZZ'. Das Ergebnisobjekt 'YYYYYYYYYY' wird nach der im obigen Abschnitt 'Umsetzen der Ergebnisobjekte' beschriebenen Logik in ein Ergebnisobjekt 'WWWWWWWWWW' des neuen aktiven Ergebnisbereichs konvertiert. Danach legt es den neuen Feldinhalt 'EOZZZZWWWWWWWWWW' im Feld NEW_FIELDNAMEder entsprechenden 'Z*'-Tabelle ab.

Da sich das Programm den höchsten umgesetzten Index aus Feld INDEXOBJNR merkt, ist es wiederaufsetzbar, d.h. tritt z.B. aufgrund von Datenbankproblemen ein Programmabbruch auf, kann es einfach mit den gleichen Selektionen nochmals gestartet werden.

Schritt D: 'Daten verdichten':

Bei diesem Schritt liest das Programm die in Schritt C konvertierten Daten aus den 'Z*'-Tabellen und schreibt die umgesetzten Feldinhalte aus den Feldern NEW_FIELDNAME in die Ursprungsfelder FIELDNAME zurück. Desweiteren setzt es das Kennzeichen UPDATED. An dieser Stelle werden jedoch die Daten aus den Kopien der CO-Einzelpostentabellen COEP und COEJ anders behandelt als diejenigen der Summentabellen COSP und COSS:

• Daten der 'Z*'-Tabellen für die CO-Einzelpostentabellen COEP und COEJ:
  Die derart geänderten Daten werden in die entsprechende Z*'-Tabelle eingefügt. Jeder Satz erhält dabei im Feld INDEXOBJNR der 'Z*'-Tabelle einen eindeutigen Index.

• Daten der 'Z*'-Tabellen für die CO-Summentabellen COSP und COSS :
  Diese Daten müssen neu verdichtet werden. Grund ist, daß einige der umgesetzten Felder im Schlüssel dieser Tabellen stehen. Daher kann es passieren, daß Summensätze, die vor der Konvertierung in diesen Feldern unterschiedliche CO-Objekte aufwiesen, nach der Konvertierung im neuen aktiven Ergebnisbereich die gleichen CO-Objekte haben und damit gleiche Schlüssel besitzen. Sie müssen folglich zu einem neuen Satz verdichtet werden. Dies kann allerdings nur für CO-Objekte des gleichen Ergebnisbereichs auftreten, da ansonsten die Verschlüsselung von Buchungskreis und Kostenrechnungskreis in der Ergebnisobjektnummer zum Ziehen unterschiedlicher Ergebnisobjektnummern im neuen aktiven Ergebnisbereich bei der Konvertierung führen würde.
  
  Beispiel
  
  Tabelle COSP hat das Feld OBJNR im Schlüssel. 'A001' sei der alte und 'A002' der neue aktive Ergebnisbereich. Betrachtet werden zwei Summensätze, die bis auf das Feld OBJNR den gleichen Schlüssel haben, z.B.
  
  MANDT LEDNR OBJNR GJAHR .... PERBL ....
  001 00 EOA0010000000005 2003 .... 001 ....
  001 00 EOA0010000000009 2003 .... 001 ....
  
  Haben nun zufälligerweise Ergebnisobjekt '0000000005' und '0000000009' ähnliche Merkmalswertausprägungen, so daß bei der Konvertierung für beide Ergebnisobjekte im neuen aktiven Ergebnisbereich Ergebnisobjektnummer '0000000012' gezogen wird, führt dies zu dem Ergebnis
  
  MANDT LEDNR OBJNR GJAHR .... PERBL ....
  001 00 EOA0020000000012 2003 .... 001 ....
  001 00 EOA0020000000012 2003 .... 001 ....
  
  Diese beiden Sätze müßten also zu einem neuen Satz verdichtet werden.
  Die derart neu verdichteten Daten werden anschließend in die entsprechende 'Z*'-Tabelle eingefügt. Jeder Satz erhält im Feld INDEXOBJNR der 'Z*'-Tabelle einen eindeutigen Index..

Diese Daten entsprechen, abgesehen von den Feldinhalten der Felder UPDATED, INDEXOBJNR und NEW_FIELDNAME, den Daten, wie sie im folgenden Schritt E in die CO-Tabellen COEP, COEJ, COSP und COSS zurückgeschrieben werden.

Das Programm ist in diesem Schritt zwar wiederaufsetzbar, falls z.B. aufgrund von Datenbankproblemen ein Programmabbruch auftritt, allerdings nicht im eigentlichen Sinne, d.h. beim Wiederaufsetzen fängt es nicht an der Stelle des Abbruchs an, sondern beginnt mit diesem Schritt nochmals von vorne. Grund ist, daß das Verdichten in einem Schritt über alle Daten erfolgen muß, d.h. die Daten müssen in einem Paket verarbeitet werden. Allerdings merkt sich das Programm, wenn die Daten einer Tabelle bereits vollständig verdichtet wurden. Diese Tabelle wird dann nicht nochmals bearbeitet.

Schritt E: 'Daten zurückschreiben':

In diesem Schritt schreibt das Programm die konvertierten Daten aus den 'Z*'-Tabellen in die entsprechenden CO-Tabellen in Paketen von 100000 Sätzen aufsteigend nach ihrem Index im Feld INDEXOBJNR zurück, im obigen Beispiel also

	ZZTKECOEP	-->	COEP	(Ist-Einzelposten)
	ZZTKECOEJ	-->	COEJ	(Plan-Einzelposten)
	ZZTKECOSP	-->	COSP	(Summensätze Primärkostenarten)
	ZZTKECOSS	-->	COSS	(Summensätze Sekundärkostenarten)

Das Programm liest zunächst alle in Schritt B kopierten Daten aus den 'Z*'-Tabellen und löscht die entsprechenden Sätze aus den CO-Tabellen COEP, COEJ, COSP und COSS. Hierbei handelt es sich um alle Datensätze mit initialem Feld UPDATED.

Anschließend werden die umgesetzten, neu verdichteten Daten gelesen, d.h. die Datensätze, bei denen das Kennzeichen UPDATED gesetzt ist und diese werden in die jeweiligen CO-Tabellen zurückgeschrieben.

Da sich das Programm den höchsten gelöschten bzw. eingefügten Index aus Feld INDEXOBJNR merkt, ist es wiederaufsetzbar, d.h. tritt z.B. aufgrund von Datenbankproblemen ein Programmabbruch auf, kann es einfach mit den gleichen Selektionen nochmals gestartet werden.

Schritt F: 'Daten löschen':

In diesem Schritt können die umgesetzten Daten aus den 'Z*'-Tabellen gelöscht werden. Daten aus den entsprechenden CO-Tabellen COEP, COEJ, COSP und COSS werden mit diesem Schritt nicht entfernt.

Da sich das Programm den höchsten gelöschten Index aus Feld INDEXOBJNR merkt, ist es wiederaufsetzbar, d.h. tritt z.B. aufgrund von Datenbankproblemen ein Programmabbruch auf, kann es einfach mit den gleichen Selektionen nochmals gestartet werden.

Schritt G: 'Tabellendefinition löschen':

Bei diesem Schritt löscht das Programm die Tabellendefinition der 'Z*'-Tabellen aus dem Data Dictionary. Beim Ausführen des Programms im Hintergrund wird dabei eine Fehlermeldung ausgegeben, falls eine Tabelle noch Daten enthält. Wird das Programm online gestartet, kommt eine entsprechende Abfrage hoch, ob die Tabelle trotzdem gelöscht werden soll.

Die einzelnen Schritte können dabei, wie bereits erwähnt, immer nur dann im Echtlauf ausgeführt werden, wenn vorher bereits ein erfolgreicher Testlauf gelaufen ist.

Wie der Status der einzelnen Schritte ist, wird auf dem Selektionsbildschirm des Programms über die neben den Schritten angezeigten Ampeln ersichtlich. Diese zeigen den Status für den jeweiligen Schritt und eine spezielle Kombination von alten Ergebnisbereichen und neuem aktiven Ergebnisbereich, Geschäftsjahr, sowie Tabellennamen der 'Z*'-Tabellen an. Ist die Ampel

• grün, ist bereits ein erfolgreicher Echtlauf durchgeführt worden.

• gelb, ist bereits ein erfolgreicher Testlauf, aber noch kein erfolgreicher Echtlauf ausgeführt worden.

• rot, ist noch kein erfolgreicher Testlauf gelaufen.

Zum Löschen von Statussätzen kann der Menüpfad

,,'Zusätze --> Statusinformationen löschen'

gewählt werden. Auf dem erscheinenden Übersichtsbild können Sie die zu löschenden Statussätze wie auf dem Selektionsbild des Programms gemäß den Bereichen 'Ergebnisbereiche', 'Weitere Selektionen' , 'Tabellen', 'Steuerparameter'und 'Bearbeitungsschritte'auswählen. Beantworten Sie die anschließende Sicherheitsabfrage mit 'Ja'.

CPI1466 during Backup   BAL_S_LOG - Application Log: Log header data  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 40578 Date: 20240601 Time: 195756     sap01-206 ( 607 ms )