Batch-Schnittstelle

Die Charakter-Strukturen werden nicht mehr ausgeliefert. Sie können allerdings mittels Report (cacs_edt_generate_cstructures) aus einer Dictionary-Informationsdatei erstellt werden. Mögliche Felder für den Datenbereich befinden sich in den folgenden Tabellen:

Daten für den Provisionsfall-Prozeß

Methodenaufruf (siehe Methoden der Schnittstellen)

Der Aufruf der Schnittstelle erfolgt immer über eine der Methoden neu anlegen , ändern oder zurücknehmen (TRI_METH_TYP).

Status der Provisionsfall-Bearbeitung

Das Verarbeitungsziel wird mit TRI_METH_TARGET festgelegt. STATUS_WORK klassifiziert den Bearbeitungszustand.

Revisionsbearbeitung

Die Revisionsbearbeitung ist ein Arbeitsschritt innerhalb der Provisionsfall-Bearbeitung. Hier wird fest gehalten, wann und von wem die Revision durchgeführt wurde.

Wirksamkeits- und Wissensstandsdatum

Das Wirksamkeitsdatum (CLC_DATE) steuert, mit welchem Datum der Prozess den Provisionsvertrag und die Organisationsstruktur liest. Der aufrufende Prozess teilt mit, mit welchem Wissensstandsdatum (KNW_DATE) die Provisionsfall-Bearbeitung erfolgen soll. In den allermeisten Fällen entspricht das dem Tagesdatum („jetzt“). Das Wissensstandsdatum kann nur heute sein bzw. in der Vergangenheit liegen.

Weitere Datumsfelder zum Provisionsfall-Prozess

Das Eingangsdatum, das Haftungsabgrenzungsdatum und das Eingangsdatum (ohne Funktionalität) sind weitere Datumsfelder im Prozess.

Sonderfunktion Kopieren Beteiligteninformationen

Das Kopieren kann sowohl bei Methode Anlegen Provisionsfall als auch bei der Methode Ändern aufgerufen werden.

Prozesssteuerung Migration

Für migrierte Fälle wurden spezielle Felder (FLG_NOSETTLEMENT, FLG_NORESETTLE und FLG_FUTURECHECK) eingeführt, über die die Provisionsfall-Bearbeitung gesteuert werden kann. Diese Informationen gelten nicht generell für den Provisionsfall, sondern für die jeweilige Bearbeitung.

Technische Zusatzfelder

Zu Dokumentationszwecken sind die technischen Zusatzfelder RUN_ID und EXT_RUN_ID vorhanden.

Textfeld Provisionsfall

Im Textfeld CASE_TXT können Eingaben zum jeweiligen Provisionsfall hinterlegt werden.

Informationen zum Objekt Provisionsfall

Allgemeine Informationen zum Provisionsfall

Der Provisionsfall wird aus Sicht des Provisionssystems über folgende Schlüsselfelder identifiziert: MANDT, IMPORT_YEAR und CASE_ID. Aus Sicht des aufrufenden Systems erfolgt die Identifikation über die Felder BUSOBJ_TYPE, BUSOBJ_ID, BUSOBJ_VERS, REM_BUSCASE_TYP und REM_BUSCACS_ID. Diese Felder dürfen dementsprechend bei Änderungen des Provisionsfalls nicht verändert werden. Zusätzliche Informationsfelder: LED_CURR und FLG_CANCEL_OBJ.

Provisionsfall-Version

Bei jeder Änderung des Provisionsfalls wird eine neue Version angelegt. Alte oder zurückgenommene Versionen werden entsprechend gekennzeichnet. Die Änderungszeit, die Änderungstransaktion und der Änderungsuser werden dokumentiert. Der Status der Version zeigt an, in welchem Zustand sich die Version des Provisionsfalls befindet. Das ist keine Information zum Bearbeitungsprozess, sondern zum Objekt Provisionsfall.

Relevante Felder für die Provisionsfall-Version: CASE_VERS, FLG_CANCEL_VERS, CHG_DATE, CHG_TIME, CHG_TCODE, CHG_USER, STATUS_VERSION.

Informationen zum Geschäftsobjekt

Die Felder BUSOBJ_TYPE, BUSOBJ_ID und BUSOBJ_VERS kennzeichnen das vom vergütenden Geschäftsvorfall bearbeitete Objekt.

Informationen zum auslösenden/vergütenden Geschäftsvorfall

Der vergütende Geschäftsvorfall wird durch die Felder REM_BUSCASE_TYP, REM_BUSCASE_ID und REM_BUSCASE_VERS klassifiziert. TRIGGER_SYS kennzeichnet das System, in dem der gelieferte Geschäftsvorfall bearbeitet wurde. Datumsinformationen zum vergütenden Geschäftsvorfall befinden sich in den Feldern TRIGGER_DATE und RELEASE_DATE.

Der auslösende Geschäftsvorfall wird durch die Felder TRI_BUSCASE_TYP, TRI_BUSCASE_ID und TRI_BUSCASE_VERS beschrieben.

Methoden der Schnittstelle

Methode Anlegen Provisionsfall

Die Identifikation eines Provisionsfalls aus Sicht des aufrufenden Systems erfolgt i.d.R. über die fachlichen Schlüssel BUSOBJ_TYPE, BUSOBJ_ID, BUSOBJ_VERS, REM_BUSCASE_TYP und REM_BUSCASE_ID. Aus diesem Grund muss die Methode Anlegen immer dann aufgerufen werden, wenn es sich um ein neues Geschäftsobjekt, eine neue Version des Geschäftsobjekts oder um einen neuen Geschäftsvorfall zum Geschäftsobjekt handelt.

Methode Ändern Provisionsfall

Der Aufruf des Provisionssystems kann mit dem fachlichen oder dem technischen Schlüssel erfolgen. Provisionsfall, Geschäftsobjekt, Version müssen bereits vorhanden sein.

Methode Zurücknehmen Provisionsfall

Der Aufruf des Provisionssystems kann mit dem fachlichen oder dem technischen Schlüssel erfolgen. Provisionsfall, Geschäftsobjekt, Version müssen bereits vorhanden sein. Zurückgenommen wird immer der Provisionsfall, nicht eine einzelne Version des Provisionsfalls.

KOMMETAR

I. BUSOBJ_TYPE wird geprüft gegen die Prüftabelle TCACS_BUSOBJ

II. REM_BUSCASE_TYP wird geprüft gegen Prüftabelle TCACS_BUSCAS

III. Neuanlage und Änderung

Bei Neuanlage und Änderung eines Geschäftsobjekts sind vergütender und auslösender Geschäftsvorfall identisch. Geschäftsvorfallart und Identifikation können entweder für den auslösenden oder den vergütenden Geschäftsvorfall oder für beide Geschäftsvorfälle geliefert werden. Es wird der jeweils andere Geschäftsvorfall mit den Daten des eingegebenen Geschäftsvorfalls versorgt. Die Prozesse setzen auf dem vergütenden Geschäftsvorfall auf.

Der Prozeß „Rücknahme eines bereits gebuchten Provisionsfalls“ erfolgt mit dem vergütenden Geschäftsvorfall. Die Daten des auslösenden Geschäftsvorfalls dienen in diesem Fall zur Identifizierung, mit welchem Geschäftsvorfall die Rücknahme aus dem Vorsystem gemeldet worden ist. Die Unterscheidung zwischen auslösendem und vergütendem Geschäftsvorfall ist in mindestens zwei Fällen bedeutend:

Aus einem Geschäftsvorfall des anliefernden Systems werden mehr als ein Provisionsfall ausgelöst (siehe oben).

Rücknahme eines bereits durchgeführten (vergütenden) Geschäftsvorfalls durch einen neuen (vergütenden) Geschäftsvorfall. Der auslösende Geschäftsvorfall dient in diesem Fall nur dazu, die Rücknahme des vergütenden Geschäftsvorfalls zu dokumentieren (im Sinne von „wurde zurückgenommen durch“).Der Geschäftsvorfall an dem die Bearbeitung ausgeführt wird, ist immer der vergütende Geschäftsvorfall.

Schritt 1:

Bestandssystem

Durch den Geschäftsvorfall 0815 erfolgt mit Wirksamkeit 01.01.2000 die Neuanlage des Geschäftsobjekts 4711 mit Version 1.

Aufruf FS-ICM

Methode: Neuanlage Provisionsfall

Geschäftsobjekt: 4711, Version 1

vergütender Geschäftsvorfall: GV 0815

auslösender Geschäftsvorfall: GV 0815

Schritt 2:

Bestandssystem

Geschäftsobjekt 4711/02 wird mit Wirksamkeit 1.3.2000 durch den GV 0817 geändert.

Aufruf FS-ICM

Methode: Neuanlage Provisionsfall

Geschäftsobjekt: 4711, Version 2

vergütender Geschäftsvorfall: GV 0817

auslösender Geschäftsvorfall: GV 0817

Schritt 3:

Bestandssystem

Am 1.4.2000 wird mit GV 0827 eine Änderung von BusObj 4711 mit Wirksamkeit 1.2.2000 durchgeführt.

Aufruf FS-ICM (Rücknahme)

Methode: Zurücknehmen Provisionsfall

Business Objekt: 4711 Version 2

vergütender Geschäftsvorfall: GV 0817

auslösender Geschäftsvorfall: GV 0827

Zurückgenommen wird der Provisionsfall zu GV0817 BusObj 4711/2. Belastet werden die damals Beteiligten !!

Aufruf FS-ICM (Neuanlage)

Methode: Zurücknehmen Provisionsfall

Business Objekt: 4711 Version 3

vergütender Geschäftsvorfall: GV 0827

auslösender Geschäftsvorfall: GV 0827

Fazit

Aus Sicht des CS ist der zu bearbeitende Provisionsfall immer der zum vergütenden Geschäftsvorfall gehörende. Bei einem normalen Provisionsfall (ohne rückwirkende Änderung) ist vergütender gleich auslösender Geschäftsvorfall. Der auslösende Geschäftsvorfall dient nur zu dokumentatorischen Zwecken. Zu einem auslösenden Geschäftsvorfall des Vorsystems können mehrere Aufrufe im CS erfolgen. Fachlich eindeutiger Schlüssel aus Sicht des anliefernden Systems sind Typ, ID und Version des Geschäftsobjekts, Typ und ID von vergütendem („Normalfall“) und auslösendem Geschäftsvorfall. Die aufgerufene Methode im Provisionssystem (Neuanlage, Änderung, Zurücknehmen) zielt immer auf den vergütenden Geschäftsvorfall.

IV. TRI_METH_TYP wird geprüft gegen Festwerte aus Domäne CACSOPTYPE:

V. TRI_METH_TARGET wird geprüft gegen Prüftabelle TCACS_VALTARG1.

KOMMENTAR

PART_POS ist Mußfeld, wenn Referenzen über hierarchische Schlüssel aufgebaut werden.

<APPLIKATION>_REL zu <APPLIKATION>_INV oder <APPLIKATION>_REL und <APPLIKATION>_ INV zu <APPLIKATION>_ PAR (ansonsten Kannfeld).

Kommentar

I. PART_POS und INV_POS sind Mußfelder, wenn Referenzen über hierarchische Schlüssel aufgebaut werden.

<APPLIKATION>_REL zu <APPLIKATION>_INV oder <APPLIKATION>_REL und <APPLIKATION>_ INV zu <APPLIKATION>_ PAR (ansonsten Kannfelder).

II. ROLE wird geprüft gegen Prüftabelle TCACS_ROLE

I. TRI_OBJ_CHGTYP wird geprüft gegen Festwerte aus Domäne CACSOBJCHANGE:

Struktur bzw. entsprechender Satztyp wird nicht übergeben, wenn keine abweichenden Provisionen erfaßt werden.

I. ADDON_TYPE wird geprüft gegen Festwerte aus Domäne CACSITEMADD

II. In Abhängigkeit vom ADDON_TYPE entweder Mussfeld oder SAP-Systemfeld (siehe F1 oder manuelle Buchung des Provisionsfalls).

III. REM_CURR wird geprüft gegen Prüftabelle TCURC (Währungen)

IV. CLAIM_OBJTYPE wird geprüft gegen Festwerte aus Domäne CACSCLAIMOBJTYPE:

Struktur bzw. entsprechender Satztyp wird nicht übergeben, wenn keine Beteiligtenrelationen erfaßt werden.

KOMMENTAR

I. PART_POS und INV_POS sind Mußfelder, wenn Referenzen über hierarchische Schlüssel aufgebaut werden.

<APPLIKATION>_REL zu <APPLIKATION>_INV oder <APPLIKATION>_REL und <APPLIKATION>_ INV zu <APPLIKATION>_ PAR (ansonsten Kannfelder).

II. ROLETYPE wird geprüft gegen Festwerte aus Domäne CACSCLAIMTYPEDO:

III. CLAIM_OBJTYPE wird geprüft gegen Festwerte aus Domäne CACSCLAIMOBJTYPE:

Struktur bzw. entsprechender Satztyp wird nicht übergeben, wenn keine Umbündelungen vorgenommen werden.

KOMMENTAR

Das referenzierte Objekt muß existieren.

2.    Dictionary-Informationsdatei

Zu jeder Eingabedatei muß eine Dictionary-Informationsdatei existieren, die im selben Verzeichnis wie die Eingabedatei liegen muß. Den Namen dieser Dictionary-Informationsdatei können Sie auf zwei Arten eintragen:

Geben Sie die Dictionary-Informationsdatei in die Eingabedatei mittels Satztyp „0“ ein.

Geben Sie die Dictionary-Informationsdatei im Customizing ein, unter Provisionen Provisionsfall

- Senderstruktur u. Übertragungsregel der FDÜ festlegen

- Optionen für Fremddatenübernahme einstellen

- Dateinamen der Dictionary-Informationsdateien für FDÜ pflegen

Struktur der Dictionary-Informationsdatei:

In der Dictionary-Informationsdatei wird die Struktur derSatztypen definiert:

An erster Stelle steht der Satztyp. Ab der zweiten Stelle steht die Feldbeschreibung in der Syntax <Feldname:Feldlänge>.

1 <MANDT:3><IMPORT_YEAR:4><CASE_ID:10><CASE_VERS:6>

Satztyp <Feldbeschreibung:Feldlänge><Feldbeschreibung:Feldlänge>etc.

Sie können sich eine Beispielsdatei für den Aufbau derEingabedatei und der Dictionary-Informationsdatei erzeugen. Über den Funktionscode EDTFILE können Sie manuelle Eingaben an der Oberfläche in eine Datei kopieren, die dem FDÜ-Format entspricht. Diese Funktionalität steht jeweils nur an der Oberfläche von Provisionsfall und Provisionsbeleg zur Verfügung. Ab Release 4.63 wird zusätzlich eine Dictionary-Informationsdatei angelegt, die alle Felder des Dictionaries der jeweiligen Satztypen enthält.

Sie geben zuerst die Daten im Dialog ein, dann geben Sie den Funktionscode in das Eingabefeld für Transaktionen ein. Es erscheinen zwei Dialogfenster, in die der Name der Dateien angegeben wird, in die geschrieben werden soll. Die Strukturbeschreibung eines Satztyps kann über mehrere Zeilen gehen. Sie müssen nur jene Felder angeben, die auch geliefert werden sollen. Die Reihenfolge der einzelnen Felder ist egal, muß aber der Feldreihenfolge in derEingabedatei entsprechen. Die Feldnamen der Eingabedatei müssen den Feldnamen in den entsprechenden Datenbanktabellen entsprechen.

3.    Meldungstypen

Die Fremddatenübernahme faßt jede Meldung (auch I und S) als Warnung auf. Ab Release 4.63 gibt es H-Meldungen und einen Parameter (CACS_MSGEDT), mit dem zusätzlich zum CACS_MSGSTORE Meldungen bei der FDÜ ausgeblendet werden können. Die H-Meldungen (Header) ermöglichen eine Strukturierung der Protokolle.

Alle Meldungen, die nicht unter CACS_MSGSTORE eingegeben werden, werden nicht protokolliert. Analog werden alle Meldungen, die nicht unter CACS_MSGDISP angegeben werden, nicht im Online angezeigt (sog. Anzeigegeschwätzigkeit). S- und I-Meldungen könnten zumindest nach Abschluß der Tests ausgeblendet werden.

Notwendige Daten für die externe Identifikation eines Provisionsfalls:

Typ des Geschäftsobjekts

ID des Geschäftsobjekts

Version des Geschäftsobjekts

Typ des vergütenden Geschäftsvorfalls

ID des vergütenden Geschäftsvorfalls

Die Daten für den auslösenden Geschäftsvorfall sind dann relevant, wenn aus einem Geschäftsvorfall des anliefernden Systems mehrere Provisionsfälle (mit der gleichen ID des vergütenden Geschäftsvorfalls) zum gleichen Geschäftsobjekt ausgelöst werden (z.B. gleichzeitig Abschlußprovision und Bestandsbetreuung). Im Normalfall reichen die o.a. ersten fünf identifizierende Angaben aus.

Legende für die Beschreibung der Datenfelder

Empfängerstruktur für die Datenübernahme des Provisionsfalls per FDÜ:CACS_S_EDT_S

KOMMENTAR

I. Die Versionsnummer einer Provisionsanwendung zeigt an, um welche Version der Anwendung es sich handelt. Bei jeder Änderung der Objektdaten wird die Versionsnummer um Eins hoch gezählt. Das Provisionssystem lehnt an der Schnittstelle Provisionsfälle ab, die nicht genau die aktuelle Version der Provisionsanwendung haben. Die Version der Provisionsanwendung ist zu finden im IMG unter dem Pfad Anwendungsdesign → Provisionsanwendungen benennen (View T_CACS_APPL).

Im FDÜ-Testbetrieb (nicht nach Produktivsetzung) kann die Angabe der Versionsnummer mit einem Stern (*) an der ersten Stelle des Feldes und fünf weiteren Leerzeichen umgangen werden.

II. Die externe Provisionsfallnummer dient dazu, alle zusammengehörenden Daten (Provisionsfallkopf, Beteiligung, Beteiligte, Aktivitäten, Objekte und abweichende Provision, Beteiligungsrelationen, Um-/Anbündeln) eines Provisionsfalls ermitteln zu können. Sie wird extern vergeben und bildet eine Klammer um alle Daten eines Provisionsfalls. Es handelt sich um eine temporäre Nummer, die nicht gesichert wird.

III. Die Identifikation der Provisionsanwendung ist zu finden im IMG unter dem Pfad Anwendungsdesign→Provisionsanwendungen benennen (View T_CACS_APPL).

IV. Der Satztyp der übergebenen Daten ermöglicht bei einer Fremddatenübernahme die Festlegung, von welcher Datenart die übergebenen Daten der aktuellen Zeile sind. Je nach übergebenem Satztyp werden unterschiedliche Strukturen in den Feldern DUMMY_CH_S1 bis DUMMY_CH_S4 abgelegt.