Kirchensteuerabzug auf abgeltend besteuerte Kapitalerträge ( 51a EStG) - KiStA - Kommunikationshandbuch Teil II Abfrageverfahren

Transkript

1 Kirchensteuerabzug auf abgeltend besteuerte Kapitalerträge ( 51a EStG) - KiStA - Kommunikationshandbuch Teil II Abfrageverfahren Version 1.00 Stand

2 Änderungsübersicht Datum Version Beschreibung Autor Initialversion 2

3 Inhaltsverzeichnis Änderungsübersicht Grundlagen Rechtliche Grundlagen Copyright Grundlagen des Massendatenversands mittels ELMA Grundlagen von ELMA Dateinamen-Konvention Namenskonvention Anfragedateien Namenskonvention und Erstellung Signaturdateien Übernahme einer ELMA Datenlieferung Reaktion auf eine Datenlieferung Aufbau der ELMA-Metadaten Wurzelelement ELMAKM Element ELMAFEHLER zur Beschreibung des Fehlerfalls Element ELMAKOM zur Beschreibung der Lieferdaten Element ELMAHeader zur Beschreibung der generischen Metadaten Element ELMAVerfahren zur Zusammenfassung von verfahrensspezifischen Nutzlastdaten Aufbau des Anfragedatensatzes KiStA-Zulassungsnummer des Dienstleisters KiStA-Zulassungsnummer des KiStAV Liste von Anfragedatensätzen mit Angabe einer Anfrageart Anfragedatensatz mit Angabe einer Anfrageart Anfragetyp Baustein Personen-Anfragedaten (Anfrageart 1 und 3) Baustein IdNr und Geburtsdatum (Anfrageart 2) Antwortdatensatz ELMA-Umschlag Liste der Antwortdatensätze Antwortdatensatz Antwort zu Anfrageart 1 bei fehlerfreier Verarbeitung eines Anfragedatensatzes Antwort zu Anfrageart 2 bei fehlerfreier Verarbeitung eines Anfragedatensatzes 48 3

4 4.3.3 Antwort zu Anfrageart 3 bei fehlerfreier Verarbeitung eines Anfragedatensatzes Auftreten eines fachlichen Fehlers bei einem Anfragedatensatz Fehlerprüfungen Syntaktische Fehler (Typ 1) Datensatzübergreifende Fehler (Typ 2) Release-Historie Release r Erläuterungen zum Datenschema (Zeichendarstellung) Abkürzungsverzeichnis Glossar Referenzen Dokumentation der XSDs Anlageverzeichnis Anlage 1 Vorsatzwort Anlage 2 Namenszusatz Anlage 3 Titel...74 Abbildungsverzeichnis Abbildung 1 Beispiel für ELMA-Metadaten...12 Abbildung 2: ELMA-Wurzelknoten...12 Abbildung 3: ELMAFEHLER-Knoten...14 Abbildung 4: ELMAKOM-Knoten zur Bündelung der Lieferdaten...16 Abbildung 5: ELMAHeader-Knoten...16 Abbildung 6: ELMAVerfahren-Knoten...18 Abbildung 7 Beispiel für eine Anfragedatei...19 Abbildung 8 Wurzelknoten KISTA_KM für KiStAM-Anfragen...21 Abbildung 9 KiStAV_DL...22 Abbildung 10 KiStAV...23 Abbildung 11 Liste von Anfragedatensätzen...24 Abbildung 12 Anfrageart Abbildung 13 Anfrageart Abbildung 14 Anfrageart Abbildung 15 Knotendefinition für Anlassanfrage...27 Abbildung 16 Knotendefinition für Regelanfrage...29 Abbildung 17 Aufbau des PersonenAnfrageType (Baustein Personen-Anfragedaten)...29 Abbildung 18 Aufbau des PersonenDatenType...30 Abbildung 19 Aufbau einer Inlandsadresse...34 Abbildung 20 Aufbau einer Auslandsadresse...35 Abbildung 21 Aufbau einer IdNr- und Geburtsdatumsangabe

5 Abbildung 22 Beispiel für eine Antwortdatei...41 Abbildung 23 Liste von Antwortdatensätzen...44 Abbildung 24 Liste von datensatzübergreifenden Fehlern...45 Abbildung 25 Antwortdatensatz für eine Anfrage der Art Abbildung 26 Antwortdatensatz für eine Anfrage der Art Abbildung 27 Gefülltes KiStAM / neutraler Nullwert in Form eines NULL-KiStAM...49 Abbildung 28 Antwortdatensatz für eine Anfrage der Art Abbildung 29 ELMAKM_ xsd...56 Abbildung 30 ELMAKM_GLOBAL_ xsd...56 Abbildung 31 ELMAKMKOM_ xsd...57 Abbildung 32 ELMAKMFEHLER_ xsd...58 Abbildung 33 ELMAKM_KISTA _ xsd...60 Abbildung 34 KiStA-Standardtypen.xsd...67 Tabellenverzeichnis Tabelle 1 Aufbau des Dateinamens einer KiStAM-Anfrage... 7 Tabelle 2 Aufbau des Dateinamens einer Antwort auf eine KiStAM-Anfrage...10 Tabelle 3 ELMAFEHLER-Knoten...14 Tabelle 4 ELMAHeader-Knoten...16 Tabelle 5 Attribute des KISTA_KM-Knotens...21 Tabelle 6 KiStAV_DL...22 Tabelle 7 KiStAV...23 Tabelle 8 Gemeinsame Attribute aller drei Anfragearten...26 Tabelle 9 Attribute der Anlassanfrage...28 Tabelle 10 Attribute der Regelanfrage...29 Tabelle 11 Personendaten...31 Tabelle 12 Adressdaten...36 Tabelle 13 IdNr- und Geburtstagsdaten...39 Tabelle 14 Attribut der Antwortdatensätze...44 Tabelle 15 Attribut der datensatzübergreifenden Fehler...45 Tabelle 16 Daten der Rückübermittlung der IdNr...47 Tabelle 17 Gefülltes KiStAM...49 Tabelle 18 Returncode bei fachlichen Fehlern...50 Tabelle 19 Mögliche Returncodes in Abhängigkeit von Anfrageart und -Typ...52 Tabelle 20 Änderungen in Release r im Vergleich zum vorherigen Releasestand

6 1 Grundlagen 1.1 Rechtliche Grundlagen Siehe Kommunikationshandbuch Teil I 1.2 Copyright Die vorliegende technische Dokumentation dient der Information der am KiStA-Verfahren beteiligten Gruppen. Weitergehende Veröffentlichungen, Nachdruck, Vervielfältigungen oder die Speicherung - gleich in welcher Form, ganz oder teilweise sind nur mit vorheriger schriftlicher Zustimmung des BZSt zulässig. Die Wiedergabe von Gebrauchsnamen, Handelsnamen, Warenzeichen usw. in diesem Dokument berechtigt auch ohne besondere Kennzeichnung nicht zu der Annahme, dass solche Namen im Sinne der Warenzeichen- und Markenschutz-Gesetzgebung als frei zu betrachten wären und daher von jedermann benutzt werden dürfen. Alle Marken und Produktnamen sind Warenzeichen oder eingetragene Warenzeichen der jeweiligen Zeichenhalter. 6

7 2 Grundlagen des Massendatenversands mittels ELMA KiStAM-Anfragen können auf verschiedenen Kanälen übermittelt werden. Eine Möglichkeit ist der Massendatenversand mittels ELMA. 2.1 Grundlagen von ELMA Das ELMA Kommunikationsverfahren wurde durch das ZIVIT für die Übertragung von Massendaten entwickelt und basiert auf offenen Standards. Die Zielgruppe für das Verfahren sind Institutionen, die Massendaten im Rahmen der verschiedenen steuerlichen Verfahren an das BZSt auf elektronischem Wege verschlüsselt übertragen wollen. Für die Übermittlung der Daten kann der Sender eine seiner Infrastruktur entsprechende Software einsetzen. Das ELMA Übertragungsverfahren kann clientseitig auf nahezu allen Plattformen bis hin zu Mainframe- Systemen eingesetzt werden. Von den mit der Implementierung betrauten Personen werden grundlegende Kenntnisse in der Datenverarbeitung, Netzwerktechnik sowie der IT-Sicherheit vorausgesetzt. Für die Integration in den Rechenzentrums-Betrieb sind besondere Kenntnisse im Bereich der Implementierung und Automatisierung notwendig. 2.2 Dateinamen-Konvention Namenskonvention Anfragedateien Die vom KiStAV generierten Dateinamen sind vollständig in Kleinschreibung zu erstellen. Die Elemente <BZStNr>_und <AccountId> des Dateinamens müssen mit den Feldern in der ELMAHeader - Struktur (siehe Kapitel 2.5.4) innerhalb der Datei übereinstimmen. Der grundsätzliche Aufbau des Dateinamens folgt dem Schema Beispiel: <VK>_<PB>_<BZStNr>_<AccountId>_<DateiId>.xml m5_km_bz _ _sparkohl0001.xml Die Bestandteile des Dateinamens unterliegen klar definierten Regeln. Diese sind in der nachfolgenden Tabelle beschrieben. Tabelle 1 Aufbau des Dateinamens einer KiStAM-Anfrage Lg Typ Art Name Inhalt / Erläuterung Bemerkungen 002 an M <VK> Verfahrenskennung = ELMA-Dateikennung (konstant) 002 an M <PB> KISTA Produktbezeichnung für KiStAM- Anfragedaten Konstant immer: m5 Konstant immer: km 7

8 Lg Typ Art Name Inhalt / Erläuterung Bemerkungen 011 an M <BZStNr> 11-stellige, alphanumerische Senderkennung, entspricht der BZSt-Nummer des versendenden KiStAV oder Dienstleisters, die zur BOP-Nutzung vergeben wurde. 010 an M <AccountId> Account-ID des verwendeten Zertifikates Siehe auch Attribut ELMAHeader. AuthSteuernummer (Tabelle 4) Siehe auch Attribut ELMAHeader. AccountID (Tabelle 4) an M <DateiId> Von der versendenden Stelle (KiStAV oder versendender Dienstleister) zu vergebender, interner Kurzname für diese Anfragedatei. Dieser Bezeichner wird in KiStA nicht geprüft und dient nur der internen Zuordnung des Versenders. Eine naheliegende Option für Dienstleister ist die Codierung des KiStAV, in dessen Auftrag die Anfrage gestellt wird. Darf nur Zeichen aus [a-z, 0-9] enthalten Namenskonvention und Erstellung Signaturdateien Zu jeder Datendatei ist eine zugehörige Signaturdatei mit zu übertragen. Es ist immer zuerst die Datendatei und danach die korrespondierende Signaturdatei in das upload - Verzeichnis auf dem ELMA Server einzustellen. Antworten des BZSt werden ohne Signatur in das Verzeichnis "download" eingestellt. Der Dateiname der Signaturdatei besteht aus dem Dateinamen der Datendatei und den angehängten.sig - Suffix nach folgendem Schema: <VK>_<PB>_<BZStNr>_<AccountId>_<DateiId>.xml.sig Die Bestandteile der Namenskonvention sind dabei identisch zu denen der XML-Datei, siehe obige Tabelle. Auf Linux Systemen kann für die Erstellung der Signaturdatei das OpenSSL Command Line Tool verwendet werden. openssl dgst sha1 binary out <Dateiname-mit-Suffix>.sig \ 8

9 sign ~/.ssh/elster.pem <Dateiname-mit-Suffix> Enter pass phrase for key: <Passphrase> Nach Eingabe der Passphrase wird die Signaturdatei erstellt. Auf Windows Systemen erfolgt die Eingabe aus dem Kommandozeilen-Fenster (Aufruf mittels cmd.exe). [Pfadangabe]\openssl.exe dgst sha1 binary \ out <Dateiname-mit-Suffix>.sig \ sign elster.pem <Dateiname-mit-Suffix> Enter pass phrase for key: <Passphrase> Nach Eingabe der Passphrase wird die Signaturdatei erstellt. 2.3 Übernahme einer ELMA Datenlieferung Die Einlieferung einer ELMA Datei erfolgt über eine Rechner-zu-Rechner-Kopplung per sftp. Der zu verwendende DNS-Name ist elma5p.bfinv.de Es ist zu beachten, dass zur Konfiguration der Serververbindung nur dieser DNS-Name zu verwenden ist, nicht die aufgelöste IP-Adresse. Das BZSt behält sich vor, die IP-Adressse jederzeit ohne Vorankündigung zu ändern. Jede Lieferung besteht immer aus zwei Dateien (Datendatei und Signaturdatei). Sie werden nach dem Eingang einer formalen Vorprüfung unterzogen. Dabei werden folgende Regeln angewendet: 1. Sind eine Datendatei und eine Signaturdatei mit gleichlautenden Dateinamen im Namenteil vor dem Suffix vorhanden und entsprechen die beiden verwendeten Dateinamen den Konventionen? Beispiel: m5_km_bz _ _sparkohl0001.xml (Datendatei) m5_km_bz _ _sparkohl0001.xml.sig (Signaturdatei) JA weiter mit 3 NEIN weiter mit Ist die einzelne Datendatei oder die einzelne Signaturdatei älter als 10 Tage? JA Fehlermail erzeugen und Datei löschen NEIN-> keine Aktion 3. Wurde die zur Datendatei gehörige Signatur mit dem angegebenen Zertifikat erzeugt und ist die Signaturprüfung erfolgreich gewesen? JA weiter mit 4. NEIN Dateien löschen und Fehlermail erzeugen. 9

10 4. Konnte die Schemaprüfung erfolgreich durchgeführt werden? JA Bereitstellung für das Fachverfahren KiStA und Löschung im Verzeichnis upload NEIN Dateien löschen und Fehlermail erzeugen Einstellung einer Fehlerbeschreibung in das Verzeichnis download (sofern möglich). 2.4 Reaktion auf eine Datenlieferung Die Bereitstellung einer Antwortdatei des Fachverfahrens KiStA wird immer durch die Versendung einer Mail des ELMA-Servers an den Zertifikatsinhaber begleitet, aus der der Verarbeitungsstatus erkennbar ist. Eine Antwortdatei bezieht sich immer nur auf die vom KiStAV erhaltene Datei. Die Antwort liegt im download - Verzeichnis auf dem Server zur Abholung bereit. Signaturen werden nicht bestätigt. Der Dateiname der Antwort entspricht dem Eingangsnamen, wobei zur Unterscheidung von der Anfrage noch eine durch KiStA automatisch und zufällig generierte UUID angehängt wird. Das Namensschema stellt sich damit wie folgt dar: Beispiel: <VK>_<PB>_<BZStNr>_<AccountId>_<DateiId>_<UUID>.xml m5_km_bz _ _sparkohl0001_ da5b42ce-9d e-1a089eeb0ec8.xml Die Bestandteile des Dateinamens sind in der nachfolgenden Tabelle beschrieben. Tabelle 2 Aufbau des Dateinamens einer Antwort auf eine KiStAM-Anfrage Lg Typ Art Name Inhalt / Erläuterung Bemerkungen 002 an M <VK> Verfahrenskennung = ELMA-Dateikennung (konstant) 002 an M <PB> KISTA Produktbezeichnung für KiStAM- Anfragedaten Konstant immer m5 Konstant immer km 10

11 Lg Typ Art Name Inhalt / Erläuterung Bemerkungen 011 an M <BZStNr> 11-stellige, alphanumerische Senderkennung, entspricht der BZSt-Nummer des versendenden KiStAV oder Dienstleisters, die zur BOP-Nutzung vergeben wurde. 010 an M <AccountId> Account-ID des verwendeten Zertifikates Siehe auch Attribut ELMAHeader. AuthSteuernummer (Tabelle 4) Siehe auch Attribut ELMAHeader. AccountID (Tabelle 4) an M <DateiId> Von der versendenden Stelle (KiStAV oder versendender Dienstleister) zu vergebender, interner Kurzname für diese Anfragedatei. Dieser Bezeichner wird in KiStA nicht geprüft und dient nur der internen Zuordnung des Versenders. Eine naheliegende Option für Dienstleister ist die Codierung des KiStAV, in dessen Auftrag die Anfrage gestellt wird. Darf nur Zeichen aus [a-z, 0-9] enthalten. 036 an M <UUID> Durch KiStA automatisch und zufällig generierte UUID Zum Konzept und zur Definition einer UUID vgl. [1]. Die UUID wird angehängt, um eine Unterscheidung der Antwort von der angelieferten Datei zu ermöglichen. Der Download von Antwortdateien wird durch den KiStAV durchgeführt. Nur er kann den ordentlichen Erhalt seiner Dateien (ggf. auch mehrfach) feststellen. Nach dem Download löscht er die Antwortdateien selber aus dem Verzeichnis. Nicht gelöschte Dateien werden 100 Tage nach der Einstellung oder Erzeugung durch einen Job automatisiert gelöscht. Danach ist keine Wiederherstellung möglich. 11

12 2.5 Aufbau der ELMA-Metadaten Für die Erstellung der Dateninhalte in einer mittels ELMA versandten Datei ist die UTF-8- Codepage zu verwenden. Abweichende Codepage-Varianten werden nicht unterstützt. Auch die Antwort-Dateien werden mit derselben Codepage zurückgeliefert. Es wird dringend empfohlen, nicht den gesamten in UTF-8 verfügbaren Zeichensatz zu nutzen. Für nicht üblicherweise in Namens- und Adressdaten vorkommende Zeichen kann keine Garantie einer unverfälschten Speicherung und Verarbeitung übernommen werden. Eine Orientierung kann beispielsweise der von der KoSIT definierte Satz der lateinischen Zeichen [3] darstellen. Die Metadaten des ELMA-Verfahrens werden wie ein Umschlag um die eigentlichen KiStA- Daten herumgelegt. Dieser ELMA-Umschlag enthält die nachfolgend beschriebenen Daten. Abbildung 1 Beispiel für ELMA-Metadaten <?xml version="1.0" encoding="utf-8"?> <ELMAKM xsi:nonamespaceschemalocation="./km/01.01/elmakm_ xsd" xmlns:xsi=" <ELMAKOM> <ELMAHeader ELMAKMVersion="1"> <AuthSteuernummer>BZ </AuthSteuernummer> <AccountID> </AccountID> <KundeneigeneID>kundeneigeID</KundeneigeneID> <Verarbeitungslauf>PRODUKTIONSLAUF</Verarbeitungslauf> <ErstellungsDatum> </ErstellungsDatum> <ErstellungsZeit>10:20:30.0Z</ErstellungsZeit> </ELMAHeader> <ELMAVerfahren> <KISTA_KM...> <! -hierzu siehe Beschreibungen in nachfolgenden Kapiteln --> </KISTA_KM> </ELMAVerfahren> </ELMAKOM> </ELMAKM> Wurzelelement ELMAKM Das ELMAKM-Element dient als Wurzelknoten für die gesamte zu übertragende Datei. Es stellt den Einstieg in den Baum dar. Im Falle einer Dateneinlieferung folgt danach der ELMAKOM-Abschnitt. Für eine abgewiesene Datei wird der ELMAFEHLER-Bereich zur Rückgabe der Statusinformationen verwendet. Die Fehlerdatei wird in den Bereich /download der zugehörigen BZSt- Nummer eingestellt. Dabei wird der Dateiname der Einlieferungsdatei verwendet. Abbildung 2: ELMA-Wurzelknoten 12

13 2.5.2 Element ELMAFEHLER zur Beschreibung des Fehlerfalls Die ELMAFEHLER-Sektion wird während der Eingangsprüfung zur Information über einen vorliegenden Parserfehler verwendet (sofern dies möglich ist). Die enthaltenen Felder werden dabei aus ELMAHeader übernommen. Somit ist eine eindeutige Zuordnung zur fehlerhaft versendeten Datei möglich. Der Fehlertext und der verarbeitende Prozess sind dabei optional. Sie werden falls möglich zur Eingrenzung der Ursache mit angegeben. 13

14 Abbildung 3: ELMAFEHLER-Knoten Die ELMAFEHLER-Informationen resultieren aus den im ELMAHeader übertragenen Informationen des Senders. Sie dienen der Identifikation der Vorgangs und der eingelieferten Datei. Der Aufbau und die Versendung erfolgt als Resultat einer abgewiesenen Datei. Tabelle 3 ELMAFEHLER-Knoten Lg Typ Art Name Inhalt / Erläuterung 11 an M AuthSteuernummer Die verwendete BZSt-Nummer 10 an M AccountID Die verwendete AccountID des Anwenders Bemerkungen Ist benutzerabhängig. Beginnt mit BZ oder BX gefolgt von 9 Ziffern. Beispiel: BZ Zu einer BZSt-Nummer kann es mindestens 1 bis max. 99 Zertifikate geben. Diese werden über die AccountID unterschieden. beliebig an k KundeneigeneID Stellt den Bezug zum IT System des Lieferanten her Kann auch als Referenz in die eigene Datenbasis verwendet werden. 14

15 Lg Typ Art Name Inhalt / Erläuterung 36 an k UUID Universally Unique Identifier der Datei Bemerkungen Zum Konzept und zur Definition einer UUID vgl. [1] an M Dateiname Referenz auf den verwendeten Dateinamen Beispiel für einen gültigen Dateinamen siehe an M VerarbeitungsDatum Datum der Verarbeitung 9 an M VerarbeitungsZeit Zeitpunkt der Verarbeitung 10 an M FehlerID Fehlernummer 8001: Parser Fehler (Schemaverletzung) 8002: Codepage Fehler (falls andere Codepage als UTF-8 gewählt) 8003: File Fehler (bei korruptem Inhalt oder Verletzung der Namenskonventionen) Bei den hier genannten Fehlern wird die komplette Datei zurückgewiesen. 11 an k FehlerText optional falls vorhanden. 12 an k FehlerProzess optional falls vorhanden Hier können z.b. Informationen zum Parserfehler eingetragen werden. Maschinenname des verarbeitenden Rechners/Mainframes 15

16 2.5.3 Element ELMAKOM zur Beschreibung der Lieferdaten ELMAKOM fasst die Lieferdaten (ELMAHeader für die generischen Metadaten sowie ELMAVerfahren für verfahrensspezifische Nutzlastdaten) zusammen. Abbildung 4: ELMAKOM-Knoten zur Bündelung der Lieferdaten Element ELMAHeader zur Beschreibung der generischen Metadaten Das Element ELMAHeader enthält alle Informationen des Senders für die Verfahrens- und Versender-Zuordnung. Der Datenkopf ist Bestandteil einer jeden ELMA Lieferung und ist nicht verfahrensspezifisch. Abbildung 5: ELMAHeader-Knoten Tabelle 4 ELMAHeader-Knoten Lg Typ Art Name Inhalt / Erläuterung 1 an M ELMAKMVersion Version der Definition Bemerkungen Zur Zeit immer 1 16

17 Lg Typ Art Name Inhalt / Erläuterung 11 an M AuthSteuernummer Die verwendete BZSt-Nummer 10 an M AccountID Die verwendete AccountID des Anwenders an k KundeneigeneID Stellt den Bezug zum IT System des Lieferanten her 15 an M Verarbeitungslauf Aussteuerung in die Produktionsoder Test- Umgebung Bemerkungen Ist benutzerabhängig. Beginnt mit BZ oder BX gefolgt von 9 Ziffern. Beispiel: BZ Zu einer BZSt-Nummer kann es mindestens 1 bis max. 99 Zertifikate geben. Diese werden über die AccountID unterschieden. Kann als Referenz in die Datenbasis des Lieferanten verwendet werden. PRODUKTIONSLAUF TESTLAUF (Großschreibung beachten) 10 an M ErstellungsDatum Datum der Dateierstellung 10 an M ErstellungsZeit Zeitpunkt der Dateierstellung 36 an k UUID Kennzeichnung der Datenlieferung nach RFC 4122 optional 17

18 2.5.5 Element ELMAVerfahren zur Zusammenfassung von verfahrensspezifischen Nutzlastdaten Das ELMAVerfahren Element gruppiert die Nutzlast des Antragstellers bzw. die daraus resultierende Antwort des BZSt. Abbildung 6: ELMAVerfahren-Knoten Die relevanten Daten für eine KiStAM-Anfrage befinden sich innerhalb des Knotens KISTA_KM (siehe Abbildung 8). Die von KiStA zurückgelieferten Antwortdatensätze weisen den gleichen ELMA-Umschlag auf und finden sich innerhalb des Knotens KISTA_KM_ANTW. Diese Knoten sind detailliert in den nachfolgenden Kapiteln 3 und 4 beschrieben. Der Unique Constraint UUIDIstEindeutig stellt sicher, dass sämtliche UUIDs innerhalb der Datei auf jeden Fall eindeutig sind. 18

19 3 Aufbau des Anfragedatensatzes Eine Anfragedatei, die über die Massendatenschnittstelle übermittelt werden soll, besteht aus folgenden Elementen: ELMA-Umschlag KiStAV-Referenz Liste von Anfragedatensätzen mit Angabe einer Anfrageart, darin: o Anfragetyp o Personen- und Adressdaten (bei Anfrageart 1 und 3) o IdNr- und Geburtsdatumsangabe (bei Anfrageart 2) Zur besseren Anschaulichkeit findet sich in Abbildung 7 ein umfassendes Beispiel für eine Anfragedatei, bevor im Nachfolgenden deren einzelne Bausteine detailliert erläutert werden. Die XML-Kommentare sind dabei nur zur besseren Verständlichkeit in das Beispiel eingestreut und sind in den tatsächlich zu übertragenden Dateien nicht zu verwenden. Abbildung 7 Beispiel für eine Anfragedatei <?xml version="1.0" encoding="utf-8"?> <ELMAKM xsi:nonamespaceschemalocation="./km/01.01/elmakm_ xsd" xmlns:xsi=" <ELMAKOM> <ELMAHeader ELMAKMVersion="1"> <AuthSteuernummer>BZ </AuthSteuernummer> <AccountID> </AccountID> <KundeneigeneID>kundeneigeID</KundeneigeneID> <Verarbeitungslauf>PRODUKTIONSLAUF</Verarbeitungslauf> <ErstellungsDatum> </ErstellungsDatum> <ErstellungsZeit>10:20:30.0Z</ErstellungsZeit> </ELMAHeader> <ELMAVerfahren> <KISTA_KM UUID="76f5ef40-0a74-11e3-8ffd c9a66" OrdBegriff="Sparkasse_Kohlscheid_ _ABC" xsi:schemalocation=" xmlns=" xmlns:xsi=" xmlns:k=" <KiStAV_DL Zulassungsnummer=" " Name="DATEV"/> <KiStAV Zulassungsnummer=" " Name="Sparkasse Kohlscheid"/> <!-- Anfrage Art 1 --> <Anfrage xsi:type="anfrageart1" UUID="3f548c40-0a6f-11e3-8ffd c9a66" KdOrdBegriff="Kto "> <PersAngabe> <Person> <k:nname>musterfrau</k:nname> <k:titel>dr.</k:titel> <k:vname>erika</k:vname> <k:gebdt> </k:gebdt> </Person> <Adresse xsi:type="k:inlandsadresse"> <k:str>musterstr.</k:str> <k:hausnr>20</k:hausnr> <k:hausnrzu>a</k:hausnrzu> <k:ort>musterstadt</k:ort> <k:plz>12345</k:plz> </Adresse> </PersAngabe> </Anfrage> 19

20 <!-- Anlassanfrage Art 2 --> <Anfrage xsi:type="anfrageart2" UUID="4ac85f20-0a6f-11e3-8ffd c9a66" " KdOrdBegriff="LV "> <Anlass Datum=" " Grund="1"/> <IdNrAngabe IdNr=" " GebDt=" "/> </Anfrage> <!-- Anlassanfrage Art 3 --> <Anfrage xsi:type="anfrageart3" UUID="51e a6f-11e3-8ffd c9a66" " KdOrdBegriff="Neukunde "> <Anlass Datum=" " Grund="2"/> <PersAngabe> <Person> <k:nname>mueller</k:nname> <k:vname>karl-friedrich</k:vname> <k:gebdt> </k:gebdt> </Person> <Adresse xsi:type="k:auslandsadresse"> <k:str>calle Porto Pi</k:Str> <k:hausnr>8</k:hausnr> <k:ort>palma de Mallorca</k:Ort> <k:plz>07015</k:plz> <k:adresserg>edificio Reina Constanza</k:AdressErg> <k:staatid>es</k:staatid> </Adresse> </PersAngabe> </Anfrage> <!-- Anfrage Art 1 mit unvollstaendiger (aber zulaessiger) Adresse --> <Anfrage xsi:type="anfrageart1" UUID="bd310c50-0a70-11e3-8ffd c9a66" " KdOrdBegriff="Kto "> <PersAngabe> <Person> <k:nname>katib-hazara</k:nname> <k:gebdt> </k:gebdt> </Person> <Adresse xsi:type="k:inlandsadresse"> <k:ort>wesel</k:ort> <k:plz>46483</k:plz> </Adresse> </PersAngabe> </Anfrage> <!-- Regelanfrage Art 2 --> <Anfrage xsi:type="anfrageart2" UUID="c72cbe20-0a70-11e3-8ffd c9a66" " KdOrdBegriff="AG "> <Regel Datum=" "/> <IdNrAngabe IdNr=" " GebDt=" "/> </Anfrage> <!-- Regelanfrage Art 3 --> <Anfrage xsi:type="anfrageart3" UUID="ceee8580-0a70-11e3-8ffd c9a66" " KdOrdBegriff="Kunden-Nr "> <Regel Datum=" "/> <PersAngabe> <Person> <k:nname>goethe</k:nname> <k:namzu>von</k:namzu> <k:vname>johann Wolfgang</k:VName> <k:gebdt> </k:gebdt> </Person> <Adresse xsi:type="k:inlandsadresse"> <k:str>großer Hirschgraben</k:Str> <k:hausnr>23</k:hausnr> <k:hausnrzu>-25</k:hausnrzu> <k:ort>frankfurt a.m.</k:ort> <k:plz>60311</k:plz> </Adresse> </PersAngabe> </Anfrage> </KISTA_KM> </ELMAVerfahren> </ELMAKOM> </ELMAKM> 20

21 Abbildung 8 Wurzelknoten KISTA_KM für KiStAM-Anfragen Tabelle 5 Attribute des KISTA_KM-Knotens Lg Typ Art Name Inhalt / Erläuterung Bemerkungen 036 an M UUID Global eindeutige ID der zugehörigen Anfragedatei (UUID). Zum Konzept und zur Definition einer UUID vgl. [1]. 21

22 An M OrdBegriff Max. 40-stelliger Ordnungsbegriff zur Kennzeichnung der gesamten Anfrage Kann durch den Lieferanten frei gewählt werden. Ein Dienstleister kann darin z.b. den KiStAV codieren, für den er liefert. Ein selbst liefernder KiStAV könnte Datum oder laufende Nummer codieren, etc. 3.1 KiStA-Zulassungsnummer des Dienstleisters Der Datenblock KiStAV_DL enthält die Daten des Dienstleisters, der für einen KiStAV tätig wird (siehe Abbildung 9). Dieser Datenblock ist nur zu liefern, wenn ein Dienstleister für einen KISTAV tätig wird. Abbildung 9 KiStAV_DL Tabelle 6 KiStAV_DL Lg Typ Art Name Inhalt / Erläuterung Bemerkungen 011 n M Zulassungsnummer KiStA-Zulassungsnummer des Dienstleisters Die Zulassungsnummer wird im Rahmen der Nutzerzulassung durch das BZSt vergeben an K Name Name des Dienstleisters 22

23 3.2 KiStA-Zulassungsnummer des KiStAV Der Datenblock KiStAV enthält die Daten desjenigen KiStAV, der die Anfrage stellt, oder in dessen Namen sie gestellt wird (siehe Abbildung 10). Abbildung 10 KiStAV Tabelle 7 KiStAV Lg Typ Art Name Inhalt / Erläuterung Bemerkungen 011 n M Zulassungsnummer KiStA-Zulassungsnummer des KiStAV Die Zulassungsnummer wird im Rahmen der Nutzerzulassung durch das BZSt vergeben an K Name Name des KiStAV 3.3 Liste von Anfragedatensätzen mit Angabe einer Anfrageart Die Liste von Anfragedatensätzen wird realisiert als Liste von Objekten des abstrakten Typs KiStAMAnfrageType (siehe Abbildung 11). Pro Datei dürfen maximal Datensätze enthalten sein. 23

24 Abbildung 11 Liste von Anfragedatensätzen 3.4 Anfragedatensatz mit Angabe einer Anfrageart Der abstrakte Typ Anfrage, der einen Anfragedatensatz bezeichnet, wird durch drei mögliche Anfragearten konkretisiert (Typ AnfrageArt1, AnfrageArt2 und AnfrageArt3). Die drei Arten können in den Anfragedateien nur bei der Übermittlung über ELMA gemischt vorkommen. Sie werden in den nachfolgenden Abbildungen dargestellt und mit ihren Attributen erklärt. a. Anfrageart = 1 bedeutet, dass eine IdNr mit Personendaten abgefragt werden soll (Anfrage IdNr ). b. Anfrageart = 2 bedeutet, dass ein KiStAM mit einer IdNr und einem Geburtsdatum abgefragt werden soll (Anfrage KiStAM ). c. Anfrageart = 3 bedeutet, dass eine IdNr und ein KiStAM mit Personendaten abgefragt werden soll ( kombinierte Anfrage). Jeder Anfragedatensatz ist durch eine UUID gekennzeichnet, die global (und damit natürlich auch insbesondere innerhalb der Anfragedatei) eindeutig sein muss. Sie darf auch nicht mit früher verwendeten UUIDs übereinstimmen. Bei Übermittlung der Anfragen über BOP wird die UUID von BOP vergeben. 24

25 Abbildung 12 Anfrageart 1 Abbildung 13 Anfrageart 2 25

26 Abbildung 14 Anfrageart 3 Tabelle 8 Gemeinsame Attribute aller drei Anfragearten Lg Typ Art Name Inhalt / Erläuterung Bemerkungen 036 an M UUID Global eindeutige ID dieses Anfragesatzes (UUID) Zum Konzept und zur Definition einer UUID vgl. [1]. Die UUID wird zur Identifikation im entsprechenden Antwortdatensatz wieder mitgeliefert an K KdOrdBegriff Kunden- Ordnungsbegriff Z.B. Kontonummer oder Vertragsnummer des Bankoder Versicherungskunden, für den die KiStAM-Anfrage gestellt wird. Kann vom KiStAV frei vergeben werden und wird zur Identifikation im Antwortdatensatz wieder mitgeliefert. 26

27 3.4.1 Anfragetyp Es gibt zwei Anfragetypen (Anlass- und Regelanfrage), die jeweils bei Anfrageart 2 und 3 vorkommen können. Eine Anfrage der Anfrageart 1 ist weder Anlass- noch Regelabfrage. Eine Anfragedatei kann bei der Übermittlung über ELMA eine Mischung aus Anfragearten 1, 2 und 3 enthalten. Insbesondere können auch Anlass- und Regelanfragen für die Anfragearten 2 und 3 gemischt enthalten sein Anlassanfrage Definition: Der KiStAV kann unabhängig vom für die Regelabfrage geltenden Zeitraum einen Anfragedatensatz übermitteln, wenn einer der nachfolgenden Rechtsgründe erfüllt ist 1. Kapitalerträge im Sinne des 43 Abs. 1 Nr. 4 EStG aus Versicherungsverträgen bei Begründung einer Geschäftsbeziehung auf Veranlassung des Kunden Der Rechtsgrund ist anzugeben. Die Anlassanfrage wird durch einen Knoten des AnlassAnfrageType gekennzeichnet, wie in nachfolgender Abbildung dargestellt. Abbildung 15 Knotendefinition für Anlassanfrage 1 Die Definition der Anlassabfrage entspricht der Änderung des Einkommensteuergesetzes durch das AmtshilfeRLUmsG und ist erstmals auf nach dem zufließende Kapitalerträge anzuwenden. 27

28 Tabelle 9 Attribute der Anlassanfrage Lg Typ Art Name Inhalt / Erläuterung Bemerkungen 010 an M Datum Bezugsdatum der Anlassanfrage im Format jhjj-mm-tt 1 n M Grund Grund für Anlassanfrage Datum darf max. vier Wochen vor dem Eingangsdatum und nicht in der Zukunft liegen. Zeichen muss einem der drei folgenden Einträge entsprechen: 1 = Kapitalerträge im Sinne des 43 Abs. 1 Nr. 4 EStG aus Versicherungsverträgen 2 = Bei Begründung einer Geschäftsbeziehung 3 = Auf Veranlassung des Kunden Bei der Angabe des Grundes der Anlassanfrage ist darauf zu achten, dass der tatsächliche Grund angegeben wird. Das BZSt weist darauf hin, dass durch die gelieferten Informationen ggf. bestimmte Folgeprozesse in der Landesfinanzverwatung und bei der Steuerveranlagung angestoßen werden Regelanfrage Definition: Der KiStAV hat einmal jährlich im Zeitraum vom 1. September bis 31. Oktober beim BZSt anzufragen, ob der Schuldner der Kapitalertragsteuer am 31. August des betreffenden Jahres (Stichtag) kirchensteuerpflichtig war (Regelanfrage) 2. Als Datum der Anfrage muss stets der des aktuellen Kalenderjahres gesetzt sein. Die Regelanfrage wird gekennzeichnet durch einen Knoten vom Typ RegelAnfrageType. 2 Die Definition der Regelanfrage entspricht der Änderung des EStG durch das AmtshilfeRLUmsG und ist erstmals auf nach dem zufließende Kapitalerträge anzuwenden. 28