Anlage_1_-_Dokumentation_BDAT_Schnittstelle.pdf

[Seite 1]

KM-FINANZEN

Dokumentation

BDAT-Schnittstelle

Anwendungsentwicklung Finanzen & Personal Version 1.0// Januar / 2022

[Seite 2]

BDAT-Doku www.komm.one

Klassifizierung extern Seite 2 von 34

[Seite 3]

Inhaltsverzeichnis

1 Allgemeines ....................................................................................................................................... 5

1.1 Inhalt des Fachkonzepts ................................................................................................................................ 5

1.2 Allgemeiner Hinweis zum vorliegenden Fachkonzept .................................................................................. 5 1.3 Voraussetzungen ........................................................................................................................................... 5

1.3.1 Lizenz ............................................................................................................................................. 5

1.3.2 Customizing.................................................................................................................................... 5

1.3.2.1 Pflege Steuerungstabelle BDAT /DZBW/BCS_BANK_T .................................................................. 5

1.3.2.1.1 Bedeutung Parameter in der Tabelle /DZBW/BCS_BANK_T ......................................................... 7

1.4 Übersicht ....................................................................................................................................................... 8

2 Datensatzbeschreibung.................................................................................................................... 10

3 Verarbeitungslogik .......................................................................................................................... 15

3.1 Sortierung bei der Verarbeitung ................................................................................................................. 15 3.2 KO-Prüfungen .............................................................................................................................................. 15 3.3 Prüfung mehrere GP zu einem VG .............................................................................................................. 15 3.4 Logik Fortschreibung BLZ, Kontonummer, IBAN und BIC............................................................................ 15

3.5 Anlage/Ableitung Zahlwege ........................................................................................................................ 16 3.6 Prüfung auf vorhandene Bankverbindung .................................................................................................. 16 3.7 Verarbeitungslogik der Buchungsschlüssel ................................................................................................. 16

3.7.1 Verarbeitung der Datensätze mit Buchungsschlüssel 010 .......................................................... 16

3.7.1.1 Konstellation 1: Bankverbindung anlegen und referenzieren ..................................................... 17

3.7.1.2 Konstellation 2: Übergebene Bankverbindung noch nicht vorhanden ....................................... 17

3.7.1.3 Konstellation 3: Ergänzung Referenzierung bei bestehender Bankverbindung .......................... 17

3.7.1.4 Konstellation 4: Ignorieren bei Übereinstimmung ...................................................................... 17

3.7.1.5 Konstellation 5: Überschreiben der Bankverbindung .................................................................. 17

3.7.1.6 Konstellation 6: Kein Überschreiben bei Verwendung der Bankverbindung in mehreren VG´s . 17

3.7.1.7 Konstellation 7: Abweichender Regulierer .................................................................................. 18

3.7.1.8 Mandatsanlage mit Buchungsschlüssel 010 ................................................................................ 18

3.7.1.8.1 Übersicht Logik Mandatsanlage................................................................................................... 20

3.7.1.8.2 Pflichtfelder für die Mandatsanlage ............................................................................................ 21

3.7.1.8.3 Automatische Vergabe der Mandatsreferenz ............................................................................. 22

3.7.1.8.4 Customizingtabelle /DZBW/BCS_MNID_T ................................................................................... 23

3.7.1.9 Mandatsänderungen mit Buchungsschlüssel 010 ....................................................................... 25

BDAT-Doku www.komm.one

Klassifizierung extern Seite 3 von 34

[Seite 4]

3.7.1.9.1 Definition verwendbare Mandate ............................................................................................... 26

3.7.1.9.2 Bekannte Querverbindungen ...................................................................................................... 26

3.7.2 Verarbeitung der Datensätze mit Buchungsschlüssel 011 .......................................................... 27

3.7.3 Verarbeitung der Datensätze mit dem Buchungsschlüssel 012 .................................................. 27

3.7.4 Verarbeitung der Datensätze mit Buchungsschlüssel 013 .......................................................... 27

3.7.4.1 Konstellation 1: Bankverbindung anlegen und referenzieren ..................................................... 27

3.7.4.2 Konstellation 2: Übergebene Bankverbindung noch nicht vorhanden ....................................... 27

3.7.4.3 Konstellation 3: Ergänzung Referenzierung bei bestehender Bankverbindung .......................... 27

3.7.4.4 Konstellation 4: Ignorieren bei Übereinstimmung ...................................................................... 28

3.7.4.5 Konstellation 5: Überschreiben der Bankverbindung .................................................................. 28

3.7.4.6 Konstellation 6: Kein Überschreiben bei Verwendung der Bankverbindung in mehreren VG´s . 28

3.7.5 Verarbeitung der Datensätze mir Buchungsschlüssel 020 .......................................................... 28

3.8 Protokollierung ............................................................................................................................................ 30

3.8.1 PRT-Datei ..................................................................................................................................... 30

3.8.2 E-Mail ........................................................................................................................................... 30

3.8.3 Spool-Ausgabe ............................................................................................................................. 30

3.9 Funktionsbausteine für die Online-Verarbeitung ....................................................................................... 31 3.10 Steuerbare Nachrichten .............................................................................................................................. 32

3.10.1 Nachricht /DZBW/CUST 141 ........................................................................................................ 32

3.10.2 Nachricht /DZBW/CUST100 ......................................................................................................... 32

3.10.3 Nachricht /DZBW/CUST202 ......................................................................................................... 32

3.11 DZ-Events .................................................................................................................................................... 33 3.11.1 BDAT_011: BSCHL 011 → Ändern Vertragsgegenstand .............................................................. 33

3.11.2 BDAT_020: BSCHL 020 Anlage Bankverbindung am GP .............................................................. 33

BDAT-Doku www.komm.one

Klassifizierung extern Seite 4 von 34

[Seite 5]

1 Allgemeines

1.1 Inhalt des Fachkonzepts

Diese Dokumentation beschreibt die Funktionen der BDAT-Schnittstelle.

Mit der BDAT-Schnittstelle können PSCD-Bankdaten aus Fachverfahren über das KM-Schnittstellenportal an das KM-Finanzen (PSCD) übergeben werden.

1.2 Allgemeiner Hinweis zum vorliegenden Fachkonzept

Dieses Fachkonzept enthält Beschreibungen von Entwicklungen der Komm.ONE.

Falls im Folgenden nicht auf eine separate Customizing-Dokumentation verwiesen wird, enthält dieses Dokument zudem die Customizing-Einstellungen zur Abbildung der Kommunalmaster-Geschäftsprozesse.

Bei rechtlichen Änderungen, welche Auswirkungen auf den Geschäftsprozess haben, wird dieses Konzept der Komm.ONE aktualisiert.

Die in diesem Dokument enthaltenen Screenshots sollen dem besseren Verständnis des Sachverhalts dienen, die darin abgebildeten Kontierungselemente (Sachkonten, Finanzpositionen, etc.) haben Beispiel-Charakter, d.h. sie werden bei einer Kontenplanänderung oder einer sonstigen rechtlichen Änderung, welche keinen Einfluss auf den Geschäftsprozess hat, nicht von Komm.ONE angepasst.

1.3 Voraussetzungen

1.3.1 Lizenz

Die BDAT-Schnittstelle ist Teil der separat zu lizenzierende Komponente KM-Schnittstellenportal.

Die Komponente KM-Schnittstellenportal des KM-Finanzen muss lizenziert sein.

1.3.2 Customizing

Grund-Customizing der Komponente KM-Schnittstellenportal siehe Dokumentation FK_Allgemeine_Import_Schnittstellenverarbeitung.docx.

1.3.2.1 Pflege Steuerungstabelle BDAT /DZBW/BCS_BANK_T

Pflege Steuerungstabelle BDAT /DZBW/BCS_BANK_T:

BDAT-Doku www.komm.one

Klassifizierung extern Seite 5 von 34

[Seite 6]

➔ Für das verwendete Geschäftsjahr muss ein Eintrag vorhanden sein

Mögliche Einträge:

Achtung: Damit die BDAT-Verarbeitung erfolgen kann, muss ein Eintrag vorhanden sein, ansonsten kommt es zu keiner Verarbeitung der BDAT-Datensätze da der Defaultwert „0“ verwendet wird und die Datensätze werden ignoriert.

BDAT-Doku www.komm.one

Klassifizierung extern Seite 6 von 34

[Seite 7]

1.3.2.1.1 Bedeutung Parameter in der Tabelle /DZBW/BCS_BANK_T

BDAT-Doku www.komm.one

Klassifizierung extern Seite 7 von 34

[Seite 8]

1.4 Übersicht

Mit der BDAT-Schnittstelle ist es möglich, Bankverbindungen nachträglich (d.h. nach der erstmaligen Übernahme der Stammdaten eines Geschäftspartners) zu ändern.

Die Änderungen beinhalten zum einen die nachträgliche Neuanlage der Bankverbindungen und des Mandats, sowie nachträgliche Änderungen von Bankverbindungen.

Mandatsanlagen und Änderungen an Mandaten sind nur mit dem Buchungsschlüssel 010 möglich.

Außerdem ist die Löschung der Verknüpfung der Bankverbindungen und Zahlwege am Vertragsgegenstand möglich.

Die Bankverbindungsänderungen werden mit den Buchungsschlüsseln 010, 011, 012, 013, und 020 verarbeitet.

Im Rahmen der Bankverbindungsänderungen werden folgende Geschäftsvorfälle resultierend aus der Buchungsart 004 verarbeitet.

BDAT-Doku www.komm.one

Klassifizierung extern Seite 8 von 34

[Seite 9]

BDAT-Doku www.komm.one

Klassifizierung extern Seite 9 von 34

[Seite 10]

2 Datensatzbeschreibung

Die Datensatzbeschreibung/ Struktur entspricht der MDAT-Struktur /DZBW/CAS_MASTERDATA_S. Allerdings sind für die Verarbeitung nur die folgenden Felder relevant:

BDAT-Doku www.komm.one

Klassifizierung extern Seite 10 von 34

[Seite 11]

BDAT-Doku www.komm.one

Klassifizierung extern Seite 11 von 34

[Seite 12]

BDAT-Doku www.komm.one

Klassifizierung extern Seite 12 von 34

[Seite 13]

BDAT-Doku www.komm.one

Klassifizierung extern Seite 13 von 34

[Seite 14]

BDAT-Doku www.komm.one

Klassifizierung extern Seite 14 von 34

[Seite 15]

3 Verarbeitungslogik

3.1 Sortierung bei der Verarbeitung

Die BDAT-Datensätze werden bei der Verarbeitung (ab Release KM2019.2) sortiert:

1. Originaldateiname (oname) - aufsteigend

2. Buchungsart (buart) - aufsteigend

3. Vertragsgegenstand (psobkey) - aufsteigend

4. Nr. Altsystem (legacyobjkl) - absteigend

5. Kundennummer-Altsystem (kunnr_old) – absteigend

6. PK-Vorverfahren (psois) – absteigend

7. Buchungszeilennummer (buznr) – aufsteigend

3.2 KO-Prüfungen

Für folgende Felder werden KO-Prüfungen in der BDAT-Schnittstelle durchgeführt:

3.3 Prüfung mehrere GP zu einem VG

Bei der Verarbeitung der BDAT-Sätze wird geprüft, ob zu dem betroffenen Vertragsgegenstand mehrere aktive Geschäftspartner existieren (Hinweis: Es wird berücksichtigt, wenn Geschäftspartner obsolet sind). Ist dies der Fall wird der Datensatz in die Fehlertabelle geschrieben. Die Meldung für diese Prüfung ist „/DZBW/BCS 026 Vertragsgegenstand XY ist mehreren Geschäftspartnern zugeordnet!“.

Der Fall kann aus der Fehlertabelle nur verarbeitet werden, wenn das fehlerhafte Stammdatenkonstrukt korrigiert wurde.

3.4 Logik Fortschreibung BLZ, Kontonummer, IBAN und BIC

Für die Speicherung der Bankdaten nutzt der SAP-Standard die Tabellen TIBAN und BUT0BK. Dies kann bei der Änderung von Bankdaten, sowohl im Dialog als auch per Schnittstelle, zu falschen Bankdaten-Konstellationen führen (z.B. BLZ/Kontonummer passt nicht zur IBAN).

BDAT-Doku www.komm.one

Klassifizierung extern Seite 15 von 34

[Seite 16]

Deshalb werden per MDAT und BDAT immer BLZ, Kontonummer sowie IBAN und BIC aus dem Datensatz in die Tabellen fortgeschrieben. Sind BLZ und Kontonummer nicht im Datensatz enthalten, werden diese aus der IBAN abgeleitet und fortgeschrieben.

Dies setzt voraus, dass der Bankenstamm (Bankschlüssel = Bankleitzahl) in der Tabelle BNKA gepflegt ist (auch wenn Flag „IBAN ohne BIC“ im SAP-Standard-Customizing aktiv ist).

3.5 Anlage/Ableitung Zahlwege

Für die Anlage/Ableitung der Zahlwege ist folgende grundsätzliche Logik implementiert:

Ist ein Eingangs- und/oder Ausgangszahlweg im Datensatz enthalten, wird dieser 1:1 in den Vertragsgegenstand übernommen. Dies ist beim Eingangszahlweg unabhängig davon, ob das Flag „Einzugsermächtigung“ im Datensatz gesetzt ist.

Ist kein Eingangs- und/oder Ausgangszahlweg im Datensatz enthalten, wird der Zahlweg aus der Customizing- Tabelle /DZBW/BCS_MNID_T abgeleitet. Der Eingangszahlweg wird dabei nur am VG hinterlegt, wenn das Flag „Einzugsermächtigung“ im Datensatz gesetzt ist.

Ist auch in der Customizing-Tabelle /DZBW/BCS_MNID_T für die VG-Art kein Eingangs- und/oder Ausgangszahlweg hinterlegt, so wird dieser über den DZ-Key D004A_ZAHLWEG bzw. D004E_ZAHLWEG abgeleitet. Der Eingangszahlweg wird dabei nur am VG hinterlegt, wenn das Flag „Einzugsermächtigung“ im Datensatz gesetzt ist.

3.6 Prüfung auf vorhandene Bankverbindung

In der BDAT-Verarbeitung wird in verschiedenen Stellen geprüft, ob eine im Datensatz übergebene Bankverbindung bereits am Geschäftspartner/Vertragsgegenstand angelegt ist. Dies erfolgt nach folgendem Schema:

• Im Datensatz ist nur BLZ+ Kto.-Nr. enthalten → Prüfung erfolgt nur über diese Felder

• Im Datensatz ist nur die IBAN (+BIC) enthalten → Prüfung erfolgt nur über diese Felder

• Im Datensatz ist BLZ+ Kto. Nr. und IBAN (+BIC) enthalten → Prüfung erfolgt zweistufig:

• im ersten Schritt über IBAN(+BIC), im zweiten Schritt über BLZ+ Kto.Nr.

3.7 Verarbeitungslogik der Buchungsschlüssel

3.7.1 Verarbeitung der Datensätze mit Buchungsschlüssel 010

Mit Buchungsschlüssel 010 können Bankverbindungen angelegt und geändert werden. Dabei wird die angelegte Bankverbindung am Vertragsgegenstand mittels der Bank-ID referenziert, sowie ein Eingangs- und Ausgangszahlweg angelegt bzw. abgeleitet. Zusätzlich kann ein Mandat angelegt bzw. geändert werden.

Dabei treten folgende Konstellationen auf:

BDAT-Doku www.komm.one

Klassifizierung extern Seite 16 von 34

[Seite 17]

3.7.1.1 Konstellation 1: Bankverbindung anlegen und referenzieren

Bei der Verarbeitung der Datensätze wird geprüft, ob die im Datensatz mitgegebene Bankverbindung am GP existiert und am VG referenziert ist.

Ist die Bankverbindung und Referenzierung beim GP bzw. VG noch nicht vorhanden wird die Bankverbindung beim GP neu eingetragen und im VG bei den Ein- u. Ausgangszahlungen als Bankverbindungs-ID zugeordnet. Es wird am VG der Eingangszahlweg und der Ausgangszahlweg zugeordnet.

Zusätzlich erfolgt auch die Mandatsanlage- bzw. Mandatsänderung, wenn die Voraussetzungen erfüllt sind.

3.7.1.2 Konstellation 2: Übergebene Bankverbindung noch nicht vorhanden

In dieser Konstellation ist beim VG keine Bankverbindung vorhanden und der GP hat zwar bereits mehrere Bankverbindungen, aber die in dem BDAT-Satz übergebene Bankverbindung ist nicht dabei. In diesem Fall wird die Bankverbindung im GP angelegt und dem VG bei den Ein- und Ausgangszahlungen zugeordnet.

Der Ablauf erfolgt analog zur Konstellation 1.

3.7.1.3 Konstellation 3: Ergänzung Referenzierung bei bestehender Bankverbindung

In dieser Konstellation sind beim VG keine Bankverbindung-IDs und keine Zahlwege vorhanden (Referenzierungen bei Eingangszahlungen und Ausgangszahlungen). Die per BDAT-Satz übergebene Bankverbindung ist bereits beim GP angelegt.

Im VG wird die Bankverbindung bei den Ein- u. Ausgangszahlungen als Bank-ID zugeordnet. Es wird am VG der Eingangszahlweg und der Ausgangszahlweg zugeordnet.

Zusätzlich erfolgt auch die Mandatsanlage- bzw. Mandatsänderung, wenn die Voraussetzungen erfüllt sind.

3.7.1.4 Konstellation 4: Ignorieren bei Übereinstimmung

Bei dieser Konstellation stimmt die übergebene Bankverbindung mit der am VG zugeordneten und am GP angelegten Bankverbindung überein.

Zusätzlich erfolgt auch die Mandatsanlage- bzw. Mandatsänderung, wenn die Voraussetzungen erfüllt sind.

Stimmen Bank- und Mandatsdaten am GP/VG mit den Daten im BDAT-Datensatz überein wird der Datensatz ignoriert und die Meldung /DZBW/BCS114 (Bankverbindung ist VG bereits zugeordnet. Satz wird ignoriert!) ausgegeben.

3.7.1.5 Konstellation 5: Überschreiben der Bankverbindung

Eine bestehende Bankverbindung wird am GP überschrieben, wenn bereits eine Bankverbindung am GP/VG angelegt und referenziert ist, die Bankverbindung an keinem anderen VG referenziert ist (also nur einem VG zugeordnet ist) und eine neue/andere Bankverbindung im BDAT-Satz übergeben wird.

Zusätzlich erfolgt auch die Mandatsanlage- bzw. Mandatsänderung, wenn die Voraussetzungen erfüllt sind.

3.7.1.6 Konstellation 6: Kein Überschreiben bei Verwendung der Bankverbindung in mehreren VG´s

In dieser Konstellation ist dem GP/VG bereits eine Bankverbindung zugeordnet und im BDAT-Datensatz wird eine neue/andere Bankverbindung übergeben. Allerdings ist die betroffene Bank-ID bereits mehreren VG`s zugeordnet.

BDAT-Doku www.komm.one

Klassifizierung extern Seite 17 von 34

[Seite 18]

Der Datensatz ist nicht eindeutig und es wird Fehlersatz mit der Nachricht /DZBW/BCS119 (Bankverbindungs- ID &1 im GP &2 wird mehrfach genutzt!) erzeugt.

Für die Bearbeitung der Fehlermeldung /DZBW/BCS119 im FTC (Bankverbindungs-ID &1 im GP &2 wird mehrfach genutzt!) stehen zwei Möglichkeiten zur Verfügung:

1. Eintragen der GP-Nummer in den BDAT-Datensatz

Die Bankverbindung im GP wird überschrieben und damit wird die Bankverbindung für alle betroffenen Vertragsgegenstände geändert.

➔ Im Hinblick auf die Mandatsanlage/Mandatsänderung nicht empfehlenswert

2. Verarbeitung des Datensatzes aus dem FTC ohne Eintragen der GP-Nummer

Wird die GP-Nummer nicht im Datensatz ergänzt und aus dem FTC heraus verarbeitet, wird eine neue Bankverbindung am GP angelegt und am VG referenziert und die Zahlwege werden angelegt.

Zusätzlich erfolgt auch die Mandatsanlage- bzw. Mandatsänderung, wenn die Voraussetzungen erfüllt sind.

3.7.1.7 Konstellation 7: Abweichender Regulierer

Ist am betroffenen Vertragsgegenstand ein abweichender Regulierer vorhanden, wird ein Fehlersatz im FTC erzeugt.

Manuelle Klärung: Bevor eine Verarbeitung dieses Satzes erfolgen kann, muss eine manuelle Bereinigung des Vertragsgegenstandes erfolgen. Der am VG angelegte abweichende Regulierer muss mit Eingangszahlweg und Bank-ID manuell gelöscht werden.

Achtung mit der BDAT kann kein abweichender Regulierer angelegt.

3.7.1.8 Mandatsanlage mit Buchungsschlüssel 010

Für die Mandatsanlage gilt die Logik aus der MDAT-Verarbeitung entsprechend. Dabei ist es möglich die Pflichtfelder für die Mandatsanlage im Datensatz zu übergeben oder diese über die Customizing-Tabelle /DZBW/BCS_MNID_T ableiten zu lassen.

Die Mandatsreferenz kann ebenfalls im Datensatz übergeben werden oder wird über den Funktionsbaustein /DZBW/BCS_SEPA_MANDATE_GEN_DEF ermittelt und vergeben.

Ob ein Mandat angelegt wird ist abhängig davon, ob im Datensatz das Flag „Einzugsermächtigung“ gesetzt ist und ein SEPA-Eingangszahlweg übergeben/abgeleitet wird. Die Prüfung des Zahlwegs erfolgt über das Zahlweg-Customizing (Flag „SEPA Mandat“ muss gesetzt sein). Das Flag „Einzugsermächtigung“ muss bei der BDAT-Schnittstelle für die Mandatsanlage nicht im Datensatz mitgegeben werden, sondern wird programmseitig mit Buchungsschlüssel 010 gesetzt.

Ist kein SEPA-Zahlweg gegeben, wird ein Mandat nur angelegt, wenn alle Pflichtfelder für die Mandatsanlage im Datensatz übergeben werden (mit Ausnahme MNDID und REC_ID; diese können ermittelt werden) und die Mandatsanlage per Schnittstelle nicht über die Customizing-Tabelle /DZBW/BCS_MNID_T ausgeschlossen ist.

Die Funktion zur Mandatsanlage steht nur für den Buchungsschlüssel 010 zur Verfügung. Wurde ein Mandat per Schnittstelle angelegt wird die Nachricht „/DZBW/BCS214: Mandat &1 wurde angelegt“ ausgegeben.

BDAT-Doku www.komm.one

Klassifizierung extern Seite 18 von 34

[Seite 19]

Analog zur Anlage von Mandaten im Dialog werden die Felder Erklärung und Sprachenschlüssel mit Fuba /DZBW/BCS_SEPA_DEFAULT_DATA abgeleitet.

BDAT-Doku www.komm.one

Klassifizierung extern Seite 19 von 34

[Seite 20]

3.7.1.8.1 Übersicht Logik Mandatsanlage

*Felder Status des Mandats (SEPA_STATUS), Transaktionstyp (PAY_TYPE) und Datum der Unterschrift (SIGN_DATE)

**Flag Einzugsermächtigung (COLL_AUTH) wird programmseitig mit Buchungsschlüssel 010 gesetzt.

***SEPA Eingangszahlweg im Datensatz oder abgeleitet

****Die Abweisung ins FTC erfolgt auch dann, wenn eine bestehende Bankverbindung und ein bereits bestehendes Mandat übergeben werden.

*****Es wird auch dann kein Mandat angelegt, wenn eine bereits bestehende Bankverbindung mit neuer Mandatsreferenz übergeben wird (nur Feld Mandatsreferenz der Mandatsfelder im Datensatz gefüllt)

BDAT-Doku www.komm.one

Klassifizierung extern Seite 20 von 34

[Seite 21]

3.7.1.8.2 Pflichtfelder für die Mandatsanlage

Die Datensatzstruktur enthält außerdem die Felder Gültigkeitsdatum des Mandats von (VAL_FROM_DATE) und Gültigkeitsdatum des Mandats bis (VAL_TO_DATE). Diese Felder sind für die Mandatsanlage nicht unbedingt notwendig, können aber im Datensatz übergeben werden. In diesem Fall werden die Inhalte 1:1 in das Mandat übernommen. Dabei ist folgendes zu beachten:

• Das Datum „Gültigkeit von“ darf nicht vor der Gültigkeit der Bankverbindung liegen Meldungsausgabe: R1 065 Für Partner XY sind zum [01.08.2013] keine Bankverbindungen gültig

• Das Datum „Gültigkeit bis“ darf nicht in der Vergangenheit liegen. Meldungsausgabe: SEPA 105 Unzulässiges Zeitintervall: Obergrenze liegt in der Vergangenheit

• Das Datum „Gültigkeit bis“ darf nicht vor dem Datum „Gültigkeit von“ liegen. Meldungsausgabe: SEPA 104 Ungültiges Zeitintervall: Untergrenze ist größer als Obergrenze

Hinweis:

Wird die Gültigkeit des Mandats für die Zukunft angegeben (VAL_FROM_DATE größer als aktuelles Datum/ Verarbeitungsdatum), kann keine Zahlwegsableitung (Ein- und Ausgangszahlweg) erfolgen.

Für die Mandatsanlage muss IBAN und BIC im Datensatz oder in der betroffenen Bankverbindung am GP vorhanden sein. Die BIC wird ggfs. aus der IBAN ermittelt.

BDAT-Doku www.komm.one

Klassifizierung extern Seite 21 von 34

[Seite 22]

3.7.1.8.3 Automatische Vergabe der Mandatsreferenz

Wird im Datensatz für die Mandatsanlage keine Mandatsreferenz übergeben, wird diese über den Funktionsbaustein /DZBW/BCS_SEPA_MANDATE_GEN_DEF ermittelt und vergeben.

Abhängig von der Einstellung in der Customizing-Tabelle /DZBW/BCS_MNID_T wird die Mandatsreferenz aus dem Vertragsgegenstand oder der Nummer Altsystem gebildet:

➔ Vertragsgegenstand + 3-stellige laufende Nummer

Oder

➔ Nummer Altsystem + 3-stellige laufende Nummer

Der Funktionsbaustein /DZBW/BCS_SEPA_MANDATE_GEN_DEF muss im Customizing bei der Verwaltung von SEPA-Mandaten hinterlegt werden:

Finanzwesen → Vertragskontokorrent → Geschäftsvorfälle → Zahlungen → Erstellung von Ein- /Ausgangszahlungen → Verwaltung von SEPA-Mandaten → Allgemeine Einstellungen

BDAT-Doku www.komm.one

Klassifizierung extern Seite 22 von 34

[Seite 23]

3.7.1.8.4 Customizingtabelle /DZBW/BCS_MNID_T

Über diese Customizing-Tabelle kann gesteuert werden, wie die Mandatsreferenz gebildet werden soll (auch im Dialog), ob Mandate per Schnittstelle angelegt werden dürfen und welche Mandatsfelder hierüber abgeleitet werden sollen.

Außerdem wird diese Tabelle für die Ableitung der Zahlwege genutzt.

Beispielpflege:

Buchungskreisgruppe (Schlüsselfeld)

• Ein ‚blank‘-Eintrag gilt für alle Buchungskreise

VG-Art von/bis (Schlüsselfeld)

• Ist nur eine VG-Art direkt betroffen, reicht der Eintrag unter VGArt von

• Ein ‚blank‘-Eintrag gilt für alle VG-Arten

Datenherkunft (Schlüsselfeld)

• Ein 'blank'-Eintrag gilt für alle Datenherkünfte

Bildung Mandatsreferenz

1: aus Nummer Vertragsgegenstand

2: aus Nummer Altsystem

Default-Wert: aus Nummer Vertragsgegenstand

Mandatsanlage per Schnittstelle

• X = Mandatsanlage per Schnittstelle

• ‚ ‚ = Keine Mandatsanlage per Schnittstelle → Abweisung ins FTC (unabhängig davon, welche Felder im Datensatz gefüllt sind)

Eingangszahlweg (Auswahl Zahlweg)

• Beispiel: D (SEPA Lastschrift)

• Beschreibung Zahlweglogik siehe weiter unten!

Ausgangszahlweg (Auswahl Zahlweg)

BDAT-Doku www.komm.one

Klassifizierung extern Seite 23 von 34

[Seite 24]

• Mehrere Zahlwege möglich (analog dem SAP Standard, nacheinander weg)

• Beispiel: I (SEPA Auszahlung)

• Beschreibung Zahlweglogik siehe weiter unten!

SEPA Status (aus Domäne SEPA_STATUS, Wertebereich)

0: Erfasst

1: Aktiv

2: Zu bestätigen

3: Gesperrt

4: Storniert

5: Veraltet

6: Abgeschlossen

Default-Wert: aktiv

Datum Unterschrift (welches Datum soll im Mandat verwendet werden)

1. Erfassungsdatum → Erfassungsdatum aus Datensatz

2. Systemdatum

Default-Wert: Systemdatum

Transaktionstyp (aus Domäne SEPA_PAY_TYPE, Wertebereich)

1: Einmal-Mandat

N: Mehrfach verwendbares Mandat

Default-Wert: N Mehrfach verwendbares Mandat

Hinweis zur Pflege der Vertragsgegenstandsart (VGArt):

• Ist nur eine VG-Art direkt betroffen, reicht der Eintrag unter VGArt von

• Ein ‚blank‘-Eintrag gilt für alle VG-Arten

• Ein Eintrag zu einer einzelnen VGArt (von oder von-bis) geht einem Intervall-Eintrag, in welchem dieselbe VGArt vorkommt, vor.

Beispiel:

Eintrag 1: von 0100 bis 0100

Eintrag 2: von 0100 bis 0103

Der Eintrag 1 wird genutzt!

• Bei der Pflege der Tabelle sollte darauf geachtet werden, dass eine VGArt nicht mehrfach enthalten ist bzw.

BDAT-Doku www.komm.one

Klassifizierung extern Seite 24 von 34

[Seite 25]

in diesem Fall eine Unterscheidung nach der Daten-herkunft erfolgt.

3.7.1.9 Mandatsänderungen mit Buchungsschlüssel 010

Die Mandatsänderungen erfolgen nach folgender Logik:

• Die Voraussetzungen für die Mandatsanlage sind nicht erfüllt → Es findet keine Mandatsanlage oder - änderung statt

• Die Voraussetzungen für die Mandatsanlage sind erfüllt und es gibt noch kein Mandat zum Vertragsgegenstand. Im Datensatz wurde keine Mandatsreferenz mitgegeben

→ Es wird ein neues Mandat angelegt (Es erfolgt keine Mandatsänderung)

• Die Voraussetzungen für die Mandatsanlage sind erfüllt und im Datensatz ist eine neue Mandatsreferenz enthalten

→ Es wird ein neues Mandat angelegt; die zum VG bestehenden/verwendbaren Mandate werden auf den Status "abgeschlossen“ gesetzt

• Die Voraussetzungen für die Mandatsanlage sind erfüllt und im Datensatz wird eine bestehende Mandatsreferenz übergeben:

→ Es wird eine Mandatsänderung des Mandats vorgenommen

→ Es werden nur die Felder "Status" und "Gültig-Bis" geändert

→ Die Felder "Status" und "Gültig-Bis" sind Pflichtfelder bei Mandatsänderungen

→ Bei einer Mandatsänderung wird immer die im Datensatz übergebene Bankverbindung (IBAN+BIC) ins bestehende Mandat übernommen

→ Es wird nur das Mandat zur übergebenen Mandatsreferenz geändert

Bevor die Mandatsänderung vorgenommen wird, werden noch zwei Prüfungen vorgenommen:

1. Besteht zu dem VG/PK ein Mandat mit höherer Mandatsreferenznummer mit dem Status aktiv, erfasst oder zu bestätigen? Ist das der Fall, wird ein Fehlersatz erzeugt mit der Meldung "Zu dem VG/ PK &1 besteht das aktuellere Mandat &2. Bitte prüfen!" (/DZBW/BCS471) und es wird keine Mandatsänderung vorgenommen.

2. Hat das zu ändernde Mandat den Status "veraltet", "abgeschlossen", "storniert" oder "gesperrt"? Ist das der Fall wird ein Fehlersatz mit der Meldung „Das zu ändernde Mandat &1 hat den Status &2 und wird nicht geändert!“ (/DZBW/BCS474) ausgegeben.

• Die Voraussetzungen für die Mandatsanlage sind erfüllt und es gibt bereits ein verwendbares Mandat zum Vertragsgegenstand und im Datensatz wurde keine Mandatsreferenz mitgegeben

→ das Systemverhalten hängt vom neuen Flag (Mandat ändern) in der /DZBW/BCS_MNID_T ab:

1. Flag nicht gesetzt: Ein neues Mandat wird angelegt. Das/die bestehende/n Mandat/e wird/werden auf den Status abgeschlossen gesetzt.

2. Flag gesetzt: Es wird kein neues Mandat angelegt. Beim bestehenden Mandat (bestehen mehrere Mandate wird das Mandat mit der höchsten Mandatsreferenz verwendet) werden die Felder Status,

BDAT-Doku www.komm.one

Klassifizierung extern Seite 25 von 34

[Seite 26]

Gültig-bis mit dem Inhalt aus dem Datensatz im Mandat geändert (Die Felder „Gültig-Von"; „Transaktionstyp" und „Datum der Unterschrift" werden nicht geändert). Zuvor wird noch geprüft, ob das bestehende Mandat den Status "veraltet", "abgeschlossen", "storniert" oder "gesperrt"? Ist das der Fall wird ein Fehlersatz mit der Meldung "Das zu ändernde Mandat &1 hat den Status &2 kann nicht geändert werden!" (/DZBW/BCS470) erzeugt. Es findet ebenfalls keine Mandatsänderung statt.

3.7.1.9.1 Definition verwendbare Mandate

Ein Mandat ist verwendbar, wenn

• das gültig-ab-Datum des Mandats kleiner oder gleich und das gültig-bis-Datum größer oder gleich des Systemdatums ist

• es den Status aktiv hat

• es nicht länger als 36 Monate ungenutzt ist (für die Berechnung wird das Systemdatum und das „Datum letzte Verwendung" herangezogen) und

• die Bankverbindung auf welche sich das Mandat bezieht gültig ist (das gültig-ab-Datum kleiner oder gleich und das gültig-bis-Datum größer oder gleich des Systemdatums ist).

3.7.1.9.2 Bekannte Querverbindungen

1. Einstellungen im View V_TFK000SEPA (PSCD)

Die Einstellungen im View V_TFK000SEPA wirken sich auf die Mandatsänderungen per BDAT-Schnittstelle aus.

Es sollten die von Komm.ONE empfohlenen Einstellungen beibehalten werden. Ansonsten kann es zu inkonsistenten Mandatsänderungen kommen.

2. Tabelle SEPA_STATUS_CUST (SEPA-Mandate: Einstellungen der Statusübergänge)

Sollten Einstellungen in der Tabelle SEPA_STATUS_CUST gepflegt sein, werden diese nicht direkt von der Schnittstelle beachtet, könnten aber Auswirkungen aus dem SAP-Standard heraus haben. Die Mandatsänderungen per BDAT-Schnittstelle müssen im Zusammenhang mit diesen Einstellungen getestet werden, wenn die Tabelle verwendet wird.

3. Einstellung in V_SEPA_CUST; Verwendung /DZBW/FFS_SEPA_MAND_AFTER_SAVE

Wird der Fuba /DZBW/FFS_SEPA_MAND_AFTER_SAVE in den Folgeaktionen gepflegt, hat dies zur Folge, dass auch bei Mandatsänderungen per BDAT-Schnittstelle der Eingangszahlweg gelöscht

wird, wenn ein Mandat abgeschlossen wird und keine weiteren gültigen Mandate zum VG bestehen.

BDAT-Doku www.komm.one

Klassifizierung extern Seite 26 von 34

[Seite 27]

3.7.2 Verarbeitung der Datensätze mit Buchungsschlüssel 011

Buchungsschlüssel 011 stellt die Löschung der Eingangszahlwege dar. In diesem Fall sind beim Vertragsgegenstand der Eingangszahlweg und die Bankverbindungs-ID zu entfernen. Es wird nur die Verknüpfung zur Bankverbindungs-ID entfernt. Eine Löschung der Bankverbindung im Geschäftspartner erfolgt nicht.

Der am Vertragsgegenstand hinterlegte Ausgangszahlweg bleibt von der Änderung unberührt.

Ein verwendbares Mandat wird auf den Status abgeschlossen gesetzt.

Voraussetzung ist ein aktivierter Event BDAT_011 (mit Fuba /DZBW/BCS_SAMP_BDAT_BSCHL_011).

3.7.3 Verarbeitung der Datensätze mit dem Buchungsschlüssel 012

Buchungsschlüssel 012 stellt die Löschung der Ausgangszahlwege dar. In diesem Fall sind beim Vertragsgegenstand der Ausgangszahlweg und die Bankverbindungs-ID zu entfernen. Es wird nur die Verknüpfung zur Bankverbindungs-ID entfernt. Eine Löschung der Bankverbindung im Geschäftspartner erfolgt nicht.

Der am Vertragsgegenstand hinterlegte Eingangszahlweg bleibt von der Änderung unberührt.

3.7.4 Verarbeitung der Datensätze mit Buchungsschlüssel 013

Mit Buchungsschlüssel 013 wird die Anlage bzw. Änderung der Bankverbindung des Rückzahlweges angegeben. Ein bestehender Eingangszahlweg wird gelöscht und ein aktives Mandat wird auf den Status abgeschlossen gesetzt. Bei der Verarbeitung dieses Buchungsschlüssels gibt es folgende Fallkonstellationen:

3.7.4.1 Konstellation 1: Bankverbindung anlegen und referenzieren

Bei der Verarbeitung der Datensätze wird geprüft, ob die im Datensatz mitgegebene Bankverbindung am GP existiert und am VG referenziert ist.

Ist die Bankverbindung und Referenzierung beim GP bzw. VG noch nicht vorhanden wird die Bankverbindung beim GP neu eingetragen und im VG bei den Ausgangszahlungen als Bankverbindungs-ID zugeordnet. Es wird am VG der Ausgangszahlweg zugeordnet.

3.7.4.2 Konstellation 2: Übergebene Bankverbindung noch nicht vorhanden

In dieser Konstellation ist beim VG keine Bankverbindung vorhanden und der GP hat zwar bereits mehrere Bankverbindungen, aber die in dem BDAT-Satz übergebene Bankverbindung ist nicht dabei. In diesem Fall wird die Bankverbindung im GP angelegt und dem VG bei den Ausgangszahlungen zugeordnet.

Der Ablauf erfolgt analog zur Konstellation 1.

3.7.4.3 Konstellation 3: Ergänzung Referenzierung bei bestehender Bankverbindung

In dieser Konstellation sind beim VG keine Bankverbindung-IDs und keine Zahlwege vorhanden (Referenzierungen bei Eingangszahlungen und Ausgangszahlungen). Die per BDAT-Satz übergebene Bankverbindung ist bereits beim GP angelegt.

BDAT-Doku www.komm.one

Klassifizierung extern Seite 27 von 34

[Seite 28]

Im VG wird die Bankverbindung bei den Ausgangszahlungen als Bank-ID zugeordnet. Es wird am VG der Ausgangszahlweg zugeordnet.

3.7.4.4 Konstellation 4: Ignorieren bei Übereinstimmung

Bei dieser Konstellation stimmt die übergebene Bankverbindung mit der am VG zugeordneten und am GP angelegten Bankverbindung überein.

Stimmen Bankdaten am GP/VG mit den Daten im BDAT-Datensatz überein wird der Datensatz ignoriert und die Meldung /DZBW/BCS114 (Bankverbindung ist VG bereits zugeordnet. Satz wird ignoriert!) wird ausgegeben.

Der Eingangszahlweg darf nicht zugeordnet sein und ein vorhandener Eingangszahlweg wird gelöscht.

3.7.4.5 Konstellation 5: Überschreiben der Bankverbindung

Eine bestehende Bankverbindung wird am GP überschrieben, wenn bereits eine Bankverbindung am GP/VG angelegt und referenziert ist, die Bankverbindung an keinem anderen VG referenziert ist (also nur einem VG zugeordnet ist) und eine neue/andere Bankverbindung im BDAT-Satz übergeben wird.

3.7.4.6 Konstellation 6: Kein Überschreiben bei Verwendung der Bankverbindung in mehreren VG´s

In dieser Konstellation ist dem GP/VG bereits eine Bankverbindung zugeordnet und im BDAT-Datensatz wird eine neue/andere Bankverbindung übergeben. Allerdings ist die betroffene Bank-ID bereits mehreren VG`s zugeordnet.

Der Datensatz ist nicht eindeutig und es wird Fehlersatz mit der Nachricht /DZBW/BCS119 (Bankverbindungs- ID &1 im GP &2 wird mehrfach genutzt!) erzeugt.

Für die Bearbeitung der Fehlermeldung /DZBW/BCS119 im FTC (Bankverbindungs-ID &1 im GP &2 wird mehrfach genutzt!) stehen zwei Möglichkeiten zur Verfügung:

3. Eintragen der GP-Nummer in den BDAT-Datensatz

Die Bankverbindung im GP wird überschrieben und damit wird die Bankverbindung für alle betroffenen Vertragsgegenstände geändert.

4. Verarbeitung des Datensatzes aus dem FTC ohne Eintragen der GP-Nummer

Wird die GP-Nummer nicht im Datensatz ergänzt und aus dem FTC heraus verarbeitet, wird eine neue Bankverbindung am GP angelegt und am VG referenziert und der Ausgangszahlweg wird angelegt.

3.7.5 Verarbeitung der Datensätze mir Buchungsschlüssel 020

Über Buchungsschlüssel 020 kann zu einem Geschäftspartner eine neue Bankverbindung angelegt werden, ohne dass eine Vertragsgegenstandsnummer mitgegeben werden muss.

Voraussetzung hierfür ist, dass die GP-Nummer im Datensatz mitgegeben wird oder über die „Kundennummer Altsystem“ im Datensatz i.V.m. der Tabelle /DZBW/BCS_KUOL_T (Verknüpfung KUNNR_OLD mit Partner) die Ermittlung des Geschäftspartners sichergestellt wird.

Achtung es kann mit Buchungsschlüssel 020 kein Mandat angelegt werden, da die Mandatsanlage (über Schnittstelle) auf Vertragsgegenstandsebene erfolgt.

BDAT-Doku www.komm.one

Klassifizierung extern Seite 28 von 34

[Seite 29]

Weitere Voraussetzung: Aktiver Event BDAT_020

BDAT-Doku www.komm.one

Klassifizierung extern Seite 29 von 34

[Seite 30]

3.8 Protokollierung

3.8.1 PRT-Datei

Für die BDAT-Schnittstelle besteht die Möglichkeit zusätzlich zum Ergebnisprotokoll und dem Job-Log die Ausgabe einer PRT-Protokolldatei zu erzeugen.

Beispiel PRT-Datei:

Die Aktivierung erfolgt mit dem Event MD_030 und Fuba /DZBW/BCS_SAMP_PROCESS_MD_030.

3.8.2 E-Mail

Im Fehlerfall kann eine Mail an einen Sachbearbeiter verschickt werden. Damit diese Funktionalität verwendet werden kann, ist ein DZKEY Eintrag mit dem Schlüssel „BDAT00“ und der Hinterlegung eines Mail Users notwendig.

3.8.3 Spool-Ausgabe

Änderungen an Bankverbindungen bei denen keine Mehrfachzuordnung vorliegt im Protokoll mit Hinweis auf die Änderung ausgegeben.

BDAT-Doku www.komm.one

Klassifizierung extern Seite 30 von 34

[Seite 31]

3.9 Funktionsbausteine für die Online-Verarbeitung

Für die Online-Verarbeitung steht der Funktionsbaustein /DZBW/BCS_BANKDATA_NEW zur Verfügung:

Für die Anzeige von Bankverbindungen steht der Fuba /DZBW/BCS_BANK_SHOW_NEW_RFC zur Verfügung.

BDAT-Doku www.komm.one

Klassifizierung extern Seite 31 von 34

[Seite 32]

3.10 Steuerbare Nachrichten

3.10.1 Nachricht /DZBW/CUST 141

→In /DZBW/D_DZKEY_T sind keine Einträge zum Zahlweg definiert. (BDAT)

Ist die Nachricht als Fehler ausgesteuert, wird der Satz erst in die Fehlertabelle geschrieben, wenn nicht aus den vorherigen Schritten der neuen Zahlwegslogik (also entweder aus dem Datensatz oder der Tabelle /DZBW/BCS_MNID_T) der Zahlweg ermittelt werden konnte und kein Zahlweg in den DZ_Keys gepflegt wurde.

Wird die Nachricht auf Information/Warnung ausgesteuert, wird eine Warnung/Information ausgegeben, wenn kein Zahlweg abgeleitet werden konnte. Somit wird in einem solchen Fall auch kein Zahlweg am VG angelegt.

Wird die Nachricht auf keine Nachricht ausgesteuert, erfolgt keinerlei Ausgabe.

3.10.2 Nachricht /DZBW/CUST100

→ Daten-Satz ist für Mandant &1 bestimmt. Fall kommt in Fehlertabelle.

Über die Meldung /DZBW/CUST Nr. 100 kann gesteuert werden, wie mit Fällen umgegangen werden soll, die eine andere Mandantenzuordnung haben als der aktuelle Mandant. Bei einem Fehler oder Abbruch- Kennzeichen (E oder A) wird der Satz in die Fehlertabelle geschrieben, alle anderen Fälle führen dazu, dass der Fall verarbeitet wird.

3.10.3 Nachricht /DZBW/CUST202

→SEPA: Bitte zur Bankverbindung immer eine IBAN angeben!

Ist die Meldung als Fehler ausgesteuert, muss eine IBAN übergeben werden.

Achtung: Diese Nachricht wirkt auch in der MDAT-Verarbeitung.

BDAT-Doku www.komm.one

Klassifizierung extern Seite 32 von 34

[Seite 33]

3.11 DZ-Events

3.11.1 BDAT_011: BSCHL 011 → Ändern Vertragsgegenstand

Der Event kann dazu genutzt werden um beim Buchungsschlüssel 011 weitere Daten auf dem Vertragsgegenstand zu ändern.

In der Standard-Ausprägung wird der Buchungsschlüssel 011 zum Löschen des Eingangszahlweges und der zugehörigen Bank-ID am VG genutzt. Zudem wird ein bestehendes verwendbares Mandat auf den Status abgeschlossen gesetzt.

3.11.2 BDAT_020: BSCHL 020 Anlage Bankverbindung am GP

Über Buchungsschlüssel 020 kann zu einem Geschäftspartner eine neue Bankverbindung angelegt werden, ohne dass eine Vertragsgegenstandsnummer mitgegeben werden muss.

Voraussetzung hierfür ist, dass die GP-Nummer im Datensatz mitgegeben wird oder über die „Kundennummer Altsystem“ im Datensatz i.V.m. der Tabelle /DZBW/BCS_KUOL_T (Verknüpfung KUNNR_OLD mit Partner) die Ermittlung des Geschäftspartners sichergestellt wird.

Aktuell sind keine Events ohne Standard-Ausprägung vorhanden.

BDAT-Doku www.komm.one

Klassifizierung extern Seite 33 von 34

[Seite 34]

COPYRIGHT

© Copyright 2026 Komm.ONE

Komm.ONE

Krailenshaldenstraße 44

Alle Rechte vorbehalten. 70469 Stuttgart

Die Weitergabe und Vervielfältigung dieser info@komm.one Dokumentation oder Teilen daraus sind ohne die www.komm.one ausdrückliche Genehmigung durch die Komm.ONE nicht gestattet.

Die Komm.ONE weist darauf hin, dass die in dieser Dokumentation enthaltenen Informationen jederzeit ohne vorherige Ankündigung geändert bzw. ergänzt werden können.

Vertragspartner für gewerbliche Kunden in Baden- Württemberg und alle Kunden außerhalb Baden- Württembergs ist die civillent GmbH, eine Tochtergesellschaft der Komm.ONE.

civillent ist zur Nutzung der Marke Komm.ONE, eine Marke der Komm.ONE AöR, per Lizenz berechtigt.

BDAT-Doku www.komm.one

Klassifizierung extern Seite 34 von 34