Ansicht
Dokumentation

CHANGEDOCUMENT_OPEN - Änderungsbeleg Änderungsbelegerstellung öffnen

Fill RESBD Structure from EBP Component Structure   TXBHW - Original Tax Base Amount in Local Currency  
Diese Dokumentation steht unter dem Copyright der SAP AG.
Vorbemerkung

Dieser Funktionsbaustein ist freigegeben.

Die Dokumentation des Funktionsbausteins wird noch überarbeitet, so daß sie auch formal den Anforderungen genügt, die an freigegebene Funktionsbausteine gestellt werden.

Die Änderungsbelegerstellung für eine Objektausprägung muß mit dem Aufruf dieses Funktionsbausteins beginnen. Es werden interne Felder initialisiert und die Objektausprägung bekanntgegeben.

Beispielaufruf:

DATA: OBJECTCLASS LIKE CDHDR-OBJECTCLAS,
OBJECTID LIKE CDHDR-OBJECTID.

OBJECTCLASS = 'BANF'.
OBEJCTID = '30'.

CALL FUNCTION 'CHANGEDOCUMENT_OPEN'
EXPORTING OBJECTCLASS = OBJECTCLASS
OBJECTID = OBJECTID
EXCEPTIONS ...

Allgemeines zur Änderungsbelegerstellung

Änderungsbelege werden im R/3 System objektbezogen erstellt. Dabei werden die Begriffe Objektklasse, Objekt-Id und Objektausprägung unterschieden:

• Objektklasse
  Eine Objektklasse besteht aus einer oder mehreren, im DDIC definierten Tabellen oder Strutkuren. Die Tabellen oder Strukturen müssen einen Schlüssel besitzen. Die Tabellen zu einer Objektklasse sollten einen gemeinsamen Fremdschlüssel besitzen.

• Beispiel:
  Objektklasse Bestellanforderung = BANF besteht aus den DDIC- Tabellen EBAN (Bestellanforderung) und EBKN (Bestellanforderung-Kontierung). Der gemeinsame Schlüssel ist die Bestellanforderungsnummer.

• Objekt-Id
  Die Objekt-Id einer Objektklasse ist der gemeinsame Schlüssel der zugehörigen Tabellen.

• Beispiel:
  Bei der Objektklasse = BANF ist die Objekt-Id die Bestellanforderungsnummer.

• Objektausprägung
  Eine Objektausprägung einer Objektklasse besteht aus allen Zeilen der zugehörigen Tabellen mit gleicher Objekt-Id.

• Beispiel:
  Die Objektausprägung BANF = 30 besteht aus allen Zeilen der Tabellen EBAN und EBKN, deren Bestallanforderungsnummer = 30 ist.

Der erste Schritt bei der Änderungsbelegerstellung muß also die Definition geeigneter Objektklassen sein. Die Objektklassen sind nicht im DDIC zu pflegen.

Der zentrale Teil der Änderungsbelegerstellung besteht aus den Funktionsbausteinen der Funktionsgruppe CDOK. Den Funktionsbausteinen ist eine Änderung unter Angabe des alten, unveränderten und des neuen veränderten Stands zu übergeben.
Eine Ausnahme bilden Textänderungen, die gesondert behandelt werden. Die Übergabe des alten und neuen Stands erfolgt immer pro Tabelle. Dabei kann entschieden werden, ob die Übergabe in Form von Workareas (WORKAREA_OLD, WORKAREA_NEW) oder internen Tabellen (TABLE_OLD, TABLE_NEW) erfolgt. Im ersten Fall spricht man vom "Single Case", im zweiten vom "Multiple Case". Entsprechend werden die DDIC-Tabellen der Objektklassen "Single Case Tabelle" bzw. "Multiple Case Tabelle" genannt.

Die Funktionsbausteine unterscheiden, ob es sich um einen Erfaß-, Lösch-, oder Änderungsvorgang handelt:

Bei einem Erfaßvorgang wird nur ein Änderungsbeleg mit den Schlüsselinformationen des erfaßten Satzes erstellt.

Bei einem Löschvorgang stehen zwei Optionen zur Auswahl. Entweder erfolgt die Änderungsbelegschreibung wie beim Erfassen oder es wird jedes, im DDIC als änderungsbeleg- relevant definierte Feld des gelöschten Satzes dokumentiert (Einzelfeldokumentation).

Bei einem Änderungsvorgang wird für jedes, im DDIC als änderungsbelegrelevant definierte Feld ein Änderungsbeleg erstellt, der den alten und neuen Inhalt des Feldes enthält.

Bei Änderungen von Texten (damit sind Langtexte gemeint) wird nur dokumentiert, daß der entsprechende Text geändert wurde. Der alte und neue Stand wird nicht abgelegt. Aus diesem Grund ist für Textänderungen einer Objektausprägung eine interne Tabelle zu erstellen und der entsprechende Funktionsbaustein aufzurufen.

Bei der Änderungsbelegerstellung sollten die Währungen und Einheiten mitdokumentiert werden, wenn sich die entsprechenden Wertfelder ändern. Da die Funktionsbausteine für jede Tabelle aufgerufen werden, ist dies problemlos, wenn die referenzierten Felder in der gleichen Tabellenstruktur definiert wurden. Ist dies nicht der Fall, besteht die Möglichkeit, den Funktionsbausteinen eine zweite DDIC-Struktur zu übergeben, die die referenzierten Währungs- und Einheitenfelder enthält. Damit der korrekte Bezug von den Funktionsbausteinen hergestellt werden kann, müssen die Feldnamen der zusätzlichen Struktur aus den Namen der entsprechenden Referenztabellen und den Namen der Referenzfelder zusammengesetzt werden. Im "Single Case" Referenzinformationen in Form zweier zusätzlicher Workareas (alt, neu) übergeben. Im "Multiple Case" sind die internen Tabellen um die Referenzstruktur zu erweitern.

• Beispiel: Tabelle X4711
  Feld PREIS bezieht die Währung aus Tabelle T001, Feld WAERS. Also muß im DDIC eine Struktur vom Typ INTTAB angelegt werden, z.B. R4711, die das Feld T001WAERS beinhaltet. Im Anwendungsprogramm müssen dann an geigneter Stelle die Felder T001WAERS der Referenzstruktur (alt und neu) mit T001-WAERS versorgt werden.

Hinweise:

Die Einhaltung der Reihenfolge, in der die einzelnen Funktionsbausteine zur Änderungsbelegerstellung für eine Objekt- ausprägung aufzurufen sind, ist wichtig:

1. CHANGEDOCUMENT_OPEN
2. in beliebiger Reihenfolge
   CHANGEDOCUMENT_SINGLE_CASE (für jede geänderte Single Case Tabelle)
   CHANGEDOCUMENT_MULTIPLE_CASE (für jede geänderte Multiple Case Tabelle)
   CHANGEDOCUMENT_TEXT_CASE (für die Textänderungen)
3. CHANGEDOCUMENT_CLOSE

Um den Verbucher für eine Objektklasse automatisch zu generieren, muss in der Transaktion SCDO die Genierung angestoßen werden.

Intern werden die Änderungsbelege in drei Tabellen abgelegt.

Die erste Tabelle heißt CDHDR und beinhaltet Kopfinformationen, wie z.B. die Objektklasse, die Objekt-Id, das Änderungsdatum etc.. Zur Kennzeichnung, das der geschriebene Änderungsbeleg UNICODE-fähig ist wird im Feld LANGU die Systemsprache zum Zeitpunkt des Schreibens des Änderungsbelegs eingetragen.

Die zweite Tabelle heißt CDPOS und beinhaltet die einzelnen Positionen, also z.B. den Tabellen-/Strukturnamen, den Feldnamen des geänderten Feldes, den alten und den neuen Wert etc..

Seit der UNICODE - Absicherung bei den Änderungsbelegen hat sich die Behandlung des jeweiligen Tabellenkeys verändert. Vor der UNICODE - Absicherung gingen die Bausteine der Änderungebelegerstellung von einem zeichenweise gespeicherten Key aus. Dieser Key musste am Anfang der Tabelle/Struktur stehen. Unter Nutzung der im DDIC abgelegten Keylänge wurde aus der übergebenenen Struktur oder Tabellenzeile der Tabellenkey ausgeschnitten. Dabei passierte es, das nicht konsequent CHAR-Felder als KEY nicht ordnungsgemäß gespeichert wurden. Unter UNICODE ist diese Arbeitsweise nicht mehr abgesichert, da die Längenangabe nicht sicher genutzt werden kann. So wird das Feld TABKEY seit UNICODE feldweise aus den einzelenen Keyfeldern zusammengestellt in einem CHAR - Feld. Bei dieser feldweisen Behandlung zur Gewinnung der CHAR - Felder werden Bausteine der Funktionsgruppe SCD8 herangezogen. Die Information, was ein KEY - Feld ist, wird aus dem DDIC der entsprechenden Tabelle/Struktur entnommen. Wird dieser zusammenzusetzende TABKEY länger als 70 CHAR ist eine dritte Tabelle notwendig, um diesen dann bis max. 254 CHAR langen KEY aufzunehmen.

Die dritte Tabelle CDPOS_UID ist seit der UNICODE - Absicherung der Änderungsbelege notwendig, um den max. 254 CHAR langen Tabellenkey aufzunehmen. Wenn ein solcher Fall auftritt, wird in der CDPOS dann die GUID für den CDPOS_UID-Satz im Feld TABKEY abgespeichert. In der CDPOS_UID steht dann zu dieser GUID u.a. der 254 CHAR lange Tabellenkey. Zusätzlich wird im zugehörenden CDHDR-Satz das Feld Version mit '001' als Kennzeichen für das Vorhandensein eines langen Tabellenschlüssels (größer 70 CHAR) gefüllt.

Alle drei Tabellenbestandteile zu einem Änderungsbeleg sind immer über eine jeweils neue einmalige gemeinsame CHANGENUMMER zu identifizieren.

Parameter

OBJECTCLASS
OBJECTID
PLANNED_CHANGE_NUMBER
PLANNED_OR_REAL_CHANGES

Ausnahmen

SEQUENCE_INVALID

Funktionsgruppe

SCD0

CPI1466 during Backup   PERFORM Short Reference  
Diese Dokumentation steht unter dem Copyright der SAP AG.

Length: 10074 Date: 20240523 Time: 183955     sap01-206 ( 192 ms )