D I R D E B für den InlandsZahlungsVerkehr

Transkript

1 Projektgruppe EDIFACT Datenformate D I R D E B für den InlandsZahlungsVerkehr Mai 2003 In der vorliegenden Dokumentation wird die Verwendung des DIRDEB für die Erteilung von Lastschriften und Einzugsaufträgen im Inlands beschrieben. DIRDEB Datenbeschreibung STUZZA Version Mai / 33

2 Inhaltsverzeichnis Wozu dient der DIRDEB im österreichischen InlandsZahlungsVerkehr... 3 Wie verhält sich der österreichische IZV-DIRDEB zum internationalen Standard... 3 Die Struktur des DIRDEB / Überblick... 4 Zusammenfassungsregeln für Sammelaufträge ("batching criteria"):... 5 Weiterleitungsszenario und Schnittstelle zur NON-EDIFACT Welt... 5 Erklärungen zur Dokumentation... 6 Branch Diagram... 7 Seitenreferenz C-Beleg DIRDEB Datenbeschreibung STUZZA Version Mai / 33

3 Wozu dient der DIRDEB im österreichischen InlandsZahlungsVerkehr Der DIRDEB dient als elektronischer Auftrag vom KUNDEN an die BANK, von anderen (Zahlungspflichtigen, Bezogenen) Beträge einzuziehen und dem Konto des Auftraggebers gutzuschreiben. Der Einzug kann im Rahmen des Abkommens und Vertrags für sogenannte Abbuchungsaufträge (Lastschriftsabkommen) oder im Rahmen des Einzugsermächtigungsverfahren (EE Abkommen) erfolgen. Mir dem hier beschriebenen DIRDEB für den IZV kann nur von Konten eingezogen werden, die bei einer inländischen Bank geführt werden. Der Einzugsbetrag kann nur in EUR angegeben werden. Andere Währungen werden nicht unterstützt. Ob das Konto, über welches der Einzugsauftrag disponiert wird, in EUR geführt wird oder nicht, ist für die Währungsangabe im Einzugsauftrag belanglos. Wenn die Konto-Denomination1 von der Denomination des Lastschriftsauftrags2 abweicht, wird der entsprechende Gegenwert am Konto gutgeschrieben3. Analoges gilt für die Denomination des Kontos auf der Seite des Zahlungspflichtigen. Wie verhält sich der österreichische IZV-DIRDEB zum internationalen Standard Der "inner-österreichische" DIRDEB ist kein Subset. Die gesamte Definition der Struktur, der Feldbelegung und der zulässigen Codes hält sich an den Rahmen, der durch die internationale Standardisierung auf Basis des Directory 96A. Da es zum Zeitpunkt der Erstellung dieser Dokumentation noch keinen internationalen Message Implementation Guide (MIG) gab, der alle österreichischen Verfahren abdeckt, konnten Codes und Qualifier zum Teil nur "entsprechend" belegt werden. Es ist daher möglich, dass es zu geringfügigen Abweichungen kommt, die aber mit einer entsprechenden Übergangsfrist an den internationalen Standard angepasst werden. Segmente und Felder, denen bei Lastschriftaufträgen im IZV keine sinnvolle Verwendung entspricht, werden als "not used" ausgewiesen. Die Bedeutung von "not used" ist exakt folgende: solche Angaben führen nicht zur Ablehnung des Auftrags, aber sie werden von der Banken-Applikation nicht berücksichtigt. Wenn also zum Beispiel im Einzugsauftrag eine Anweisung über Spesenteilung zwischen Auftraggeber und Bezogenem vorhanden ist (FCA Segment), so wird diese Anweisung ignoriert, da sie im IZV nicht möglich ist. Ebenso scheinen Codes für im IZV nicht zulässigen Abwicklungsvarianten in dieser Dokumentation nicht auf. So wird z.b. nirgends zwischen "pre-authorised" und "not-pre-authorised" unterschieden, da es die Variante des "not pre-authorised" Direct Debits im österreichischen IZV zur Zeit nicht gibt. Andererseits wurden, um die österreichischen "Direct Debit"- Dienstleistungen der Banken wie bisher in Anspruch nehmen zu können und um sie auf den DIRDEB abzubilden, zusätzliche Codes vorgesehen, die eine Erweiterung gegenüber dem internationalen Standard darstellen aber keine Einschränkung desselben. Das Szenario und die rechtlichen Grundlagen für "Direct Debits" sind von Land zu Land verschieden. Eine Anpassung ist nur schwierig, da Services, die sich entwickelt haben, schon zwecks der Service-Kontinuität auch in Zukunft bestehen bleiben müssen. 1 In aller Regel werden die für Einzugsaufträge geführten Konten in EUR geführt, es kann jedoch vorkommen, dass zugunsten eines Kontos anderer Währung z.b. USD eingezogen wird. 2 jemand, der in EUR fakturiert, zieht in EUR ein und muss sich nicht darum kümmern, ob der Zahlungspflichtige sein Konto EUR führt, oder z.b. in GBP. 3 mit einem (textlichen) Hinweis am Kontoauszug, dass der Auftrag in der anderen Denomination war und welcher Betrag in dieser beauftragt wurde. DIRDEB Datenbeschreibung STUZZA Version Mai / 33

4 Die Struktur des DIRDEB / Überblick Der DIRDEB besteht aus drei Ebenen (Leveln)4 : Level A: Level B: beschreibt die Nachricht als ganzes: wer sendet an wen, handelt es sich um das Original der Nachricht oder um eine zusätzliche Kopie, wer ist zu kontaktieren, falls mit der Nachricht Probleme bei der Bank auftreten, Kontrollsummen über die ganze Nachricht etc. enthält die Information zur Abrechnung eines Sammelauftrags: über welches Konto (des auftraggebenden Kunden) soll der Sammelauftrag abgerechnet werden, Durchführungsdatum für den Sammelauftrag, das allen Einzelaufträgen des Sammlers zugrundeliegende Geschäft, die Art der erforderlichen Banktransaktion etc. Der B-Level wird mit einem LIN Segment eingeleitet. Alle Segmente der Nachricht von einem LIN Segment bis zum nächsten LIN Segment5 ergeben in Summe die erforderlich Angaben zu einem Sammelauftrag. Im folgenden wird manchmal auch der Ausdruck "LIN-Abschnitt" dafür verwendet. Da ein DIRDEB mehrere LIN-Abschnitte haben kann, können mit einer DIRDEB-Nachricht mehrere Sammellastschriftsaufträge erteilt werden. Jeder Sammelauftrag resultiert in einer Gutschriftsbuchung am Konto des Auftraggebers. Darüber hinaus können im B-Level Angaben untergebracht werden, die für alle Einzelaufträge des Sammelauftrags gleich bleiben und daher nicht auf C-Level wiederholt werden müssen. Level C wird durch ein SEQ Segment eingeleitet. Alle Segmente zwischen einem SEQ und dem darauffolgenden SEQ6 detaillieren eine Einzellastschrift innerhalb des Sammelauftrags. Die enthaltene Information besagt im wesentlich von wem wieviel aus welchem Grund einzuziehen ist. Im Prinzip kann man mit einem DIRDEB nicht nur Sammelaufträge sondern auch Einzelaufträge senden. Dann steht im B-Level die Auftraggeber-Info und im nachfolgenden C Level (in diesem Fall der einzige SEQ Abschnitt innerhalb des LIN Abschnitts) die Info über und für den Zahlungspflichtigen. Normalerweise wird man jedoch mehrere Aufträge in einem Sammelauftrag zusammenziehen. Insofern entspricht jeder LIN-Abschnitt eines DIRDEB einem V2-Lastschriftbestand. So wie man (heute) nicht beliebige Aufträge in einem V2 Auftragsbestand zusammenfassen kann, gibt es auch Kriterien im DIRDEB, die ein Zusammenfassen von Aufträgen in einen LIN-Abschnitt ausschließen. Einige Kriterien sind bankintern verarbeitungsbedingt, andere folgen aus der Buchungslogik und nicht zuletzt resultieren einige auch daraus, daß man gewisse Angaben im DIRDEB nur auf B-Level vornehmen kann7. 4 wie alle im österreichischen Banken-Szenario als Standard eingesetzten EDIFACT Nachrichten. Die Unterstützung anderer Nachrichten (z.b. PAYORD, PAYEXT etc. ) ist der individuellen Vereinbarung zwischen Kunde und kontoführendem Institut überlassen. 5 im Falle des letzten Sammelauftrags innerhalb der Nachricht wird der entsprechende LIN-Abschnitt nicht wieder durch ein LIN-Segment begrenzt sondern durch das CNT Segment des Level A. 6 der letzte Einzelauftrag (SEQ Abschnitt) innerhalb eines Sammelauftrags wird entweder durch das LIN-Segment des nächsten Sammelauftrags abgeschlossen oder durch das CNT im Level A, wenn es sich um den letzten Einzelauftrag im letzten Sammelauftrag der Nachricht handelt. 7 z.b. ist die Angabe des der Zahlung zugrundeliegenden Geschäfts im derzeitigen (D96A) DIRDEB Aufbau nur im BUS Segment möglich und dieses gibt es auf dem C-Level nicht. Gibt man die Art des Grundgeschäfts (z.b. Versicherung) an, so folgt daraus, dass es für alle Einzelaufträge des LIN-Abschnitts gleich ist. DIRDEB Datenbeschreibung STUZZA Version Mai / 33

5 Zusammenfassungsregeln für Sammelaufträge ("batching criteria"): 1) Lastschriften, die in einem Auftragsbestand (=LIN-Abschnitt) zusammengefasst werden, müssen alle über dasselbe Konto und in gleicher Währung (bzw. Denomination) abgerechnet werden. Sie müssen dasselbe Durchführungsdatum8 aufweisen. 2) Einzüge, die in ATS lauten, können nicht mit in EUR lautenden Einzügen gemischt werden. Diese Regel gilt für den "Übergangszeitraum" (Anfang 1999 bis Ende 2001) wenn im IZV sowohl Schilling als auch Euro eine gültige Denomination für Buchgeld ist. 3) Weiter gilt, dass Aufträge, für die ein Grundgeschäftstyp angegeben wird, nicht mit Einzügen anderen Ursprungs gemischt werden können. Dafür wird dieser Grundgeschäftstyp als Information bis an den Zahlungspflichtigen weitergegeben. Wenn man Lastschriften mit verschiedenem Grundgeschäft in einem Sammelauftrag (LIN-Abschnitt) mischt, muss man die Angabe des Grundgeschäfts weglassen (d.h. Feld C521 im BUS Segment nicht belegen). Alle batching criteria ergeben sich auch zwangsläufig aus den Codier-Bestimmungen des DIRDEB in vorliegender Fassung. Weiterleitungsszenario und Schnittstelle zur NON-EDIFACT Welt Im österreichischen IZV werden EDIFACT Aufträge in voller Struktur und ohne Informationsverlust bis an das Institut des Begünstigten weitergeleitet. DIRDEB Auftraggeber Bank 1 FINPAY Bank 2 MT940 und DEBMUL Begünstigter In der obigen Darstellung sind DIRDEB, FINPAY, DEBMUL und MT9409 die jeweils übermittelten Nachrichtentypen. Wenn also eine Zahlung an einen Geschäftspartner erfolgt, der EDIFACT Anwender ist, so ist ein Informationsverlustfreies end-to-end Service möglich. Problematisch wird es allerdings, wenn der Begünstigte keine EDIFACT Nachrichten entgegennehmen kann. DIRDEB Auftraggeber Bank 1 FINPAY Bank 2? Kein EDIFACT DT Begünstigter Das ist so bei (fast) allen Privatpersonen, bzw. bei der Mehrzahl kleinerer Unternehmen. In diesem Fall muss die Information irgendwie (meist auf einem Beleg) ausgedruckt werden und dazu müsste die strukturierte EDIFACT Information in Text umgesetzt werden. Da das meist weder möglich noch zweckmäßig ist, empfiehlt es sich, für solche Empfänger die Information wie bisher als Text in den Verwendungszweck zu verpacken (S.Gr. 16). 8 sofern überhaupt eines angegeben wird. 9 MT940 ist keine EDIFACT Nachricht, sondern die international standardisierte SWIFT Nachricht für den elektronischen Kontoauszug. DIRDEB Datenbeschreibung STUZZA Version Mai / 33

6 Erklärungen zur Dokumentation Die syntaktische Unterscheidung zwischen M (="mandatory" = Element bzw. Segment muß in der Nachricht vorhanden sein) und C (="conditional" = Segment bzw. Element kann vorkommen) ist in der anwendungsorientierten Beschreibung nicht ausreichend scharf. Es wird daher die erweiterte Nomenklatur verwendet: R D A N O "required": das Element ist syntaktisch "C" aber im Zusammmenhang der beschriebenen Anwendung (IZV) erforderlich, z.b.: Kontonummer des Begünstigten muß bei einer Überweisung angegeben werden. "dependent": ob das Element erforderlich ist oder nicht, hängt von der Konstellation ab, d.h. gewisse Werte in anderen Elementen erfordern auch die Befüllung dieses Elements oder schließen seine Befüllung aus. Beispiel Postleitzahl: nur bei PostBar erforderlich. Auch für den Fall, daß die Verwendung dieses Elements bilateral mit der kontoführenden Bank abgestimmt (vereinbart) werden muß verwenden wir D. "advised": die Verwendung des Elements (in beschriebener Form) wird empfohlen. "not used". Statt "N" in der Spalte "M/C" anzuschreiben, wird der Text "not used" manchmal in der Spalte "Belegung" angeschrieben. Ein eventueller Inhalt solcher Elemente wird in der Bankapplikation ignoriert, als wäre er nicht geschrieben. "optional" (eine zusätzliche Information, die mitgeliefert werden kann, aber nicht muß). Gegenüber "A" also eine wertungsfreie Wahl (Nuance). Wenn ganze Segmente nicht verwendet werden, werden sie hier nicht in ihre Datenelemente aufgelöst dargestellt (zugunsten der Kompaktheit der Darstellung). Der Code "X" = "must not be used" wird soweit möglich vermieden, da dieser zu einer Ablehnung des Auftrags (eventuell der ganzen Nachricht) Anlaß geben würde, wenn ein solches Element in der Nachricht vorhanden ist DIRDEB Datenbeschreibung STUZZA Version Mai / 33

7 Projektgruppe EDIFACT Datenformate Branch Diagram DIRDEB Datenbeschreibung STUZZA Version Mai / 33

8 Branch-Diagram UNH M 1 LEVEL A BGM DTM BUS SGr. 1 SGr. 2 SGr. 3 CNT SGr. 24 UNT M 1 M 1 D 1 D 2 O 5 O 3 R 5 N 5 M 1 RFF FII NAD SGr. 4 AUT M 1 M 1 M 1 M 9999 N 1 DTM CTA COM CTA COM LIN DTM R 1 N 1 N 5 O 1 O 5 M 1 N 1 LEVEL B DTM RFF BUS FCA SGr. 5 SGr. 6 SGr. 7 SGr. 8 SGr. 9 SGr. 10 O 1 R 2 D 1 N 1 R 1 M 1 D 3 D 1 N 10 D 1 MOA FII NAD INP GIS PRC SGr. 11 M 1 M 1 M 1 M 1 M 1 M 1 M CTA COM CTA COM FTX DTM FTX SEQ N 1 N 5 O 1 O 5 N 1 N 2 M 1 M 1 CUX DTM RFF MOA LOC NAD RCS FTX N 1 N 2 N 1 N 1 N 2 N 1 N 1 N 10 LEVEL C MOA DTM RFF PAI FCA SGr. 12 SGr. 13 SGr. 14 SGr. 15 SGr. 16 M 1 N 1 A 3 N 1 N 1 R 3 D 3 O 3 N 10 D 1 FII NAD INP GIS PRC M 1 M 1 M 1 M 1 M 1 CTA COM CTA COM FTX DTM FTX zur Kunden-Info N 1 N 5 N 1 N 5 N 1 N 2 D 5 MOA LOC NAD RCS FTX N 1 N 2 N 1 N 1 N 10 DIRDEB Datenbeschreibung STUZZA Version Mai / 33

9 Branch-Diagram Kunden-Info SGr. 17 SGr. 23 C 9999 C 1 DOC GIS M 1 M 1 MOA DTM RFF NAD SGr. 18 SGr. 19 SGr. 20 MOA C 5 C 5 C 5 C 2 C 5 C 100 C 1000 C 5 Legende Segmentkennung bzw MOA Segmentgruppe mit Nummer CUX AJT DLI M 1 M 1 M 1 DTM MOA RFF FTX MOA PIA DTM SGr. 21 SGr. 22 C 1 M 1 C 1 C 5 M 5 C 5 C 5 C 5 C 10 M 100 Status max. Wiederholungsfaktor Grau unterlegte Segmente sind in der folgenden Beschreibung als "N"ot used gekennzeichnet CUX AJT M 1 M 1 DTM MOA RFF FTX C 1 M 1 C 1 C 5 Status: "M"andatory und "C"onditional Diese Qualifizierung ist vom UN-Directory vorgegeben und stellt sicher, daß die Nachricht richtig aufgelöst werden kann, also festzustellen, ob z.b. das DTM aus SGr. 4 oder bereits aus SGr. 8 stammt. "C" ist konsequent durch "R"equired, "O"ptional, "N"ot used, "D"ependent und "A"dviced ersetzt und qualifiziert die entsprechende Information aus der Sicht der Bankenapplikation, da es wenig sinnvoll ist z.b. ein Datumssegment aufzumachen und das Datum selbst - weil conditional - nicht einzusetzen. Wiederholungsfaktor: Die maximale Wiederholbarkeit des entsprechenden Segments bzw. Segmentgruppe an der jeweiligen Stelle (aus UN-Directory). Ob dies voll ausgeschöpft werden kann oder ob nicht nur eines, sondern mehrere Segmente erwartet werden, ist bei entsprechenden Segmenten in der Beschreibung vermerkt. DIRDEB Datenbeschreibung STUZZA Version Mai / 33

10 Projektgruppe EDIFACT Datenformate Beschreibung der Segmente DIRDEB DIRDEB Datenbeschreibung STUZZA Version Mai / 33

11 Seitenreferenz Level A UNH...12 BGM...12 DTM...13 BUS...13 Segmentgruppe RFF...13 DTM...13 Segmentgruppe FII...14 CTA...14 COM...14 Segmentgruppe NAD...15 CTA...16 COM...16 CNT...16 Segmentgruppe AUT... Fehler! Textmarke nicht definiert. DTM... Fehler! Textmarke nicht definiert. UNT...17 Level B Segmentgruppe LIN...17 DTM...18 RFF...18 BUS...19 FCA...20 Segmentgr MOA...20 CUX...20 DTM...20 RFF...20 Segmentgr FII...21 CTA...21 COM...21 Segmentgr NAD...22 CTA...22 COM...22 Segmentgr INP...23 FTX...23 DTM...23 Segmentgr GIS...23 MOA...23 LOC...23 NAD...23 RCS...23 FTX...23 Segmentgr PRC...24 FTX...24 (x) Die Segmentgruppen 17 bis 23 werden im separaten Dokument Strukturierte Kunden zu Kunden Information beschrieben. Level C Segmentgr SEQ...25 MOA...25 DTM...25 RFF...26 PAI...26 FCA...26 Segmentgr FII...27 CTA...28 COM...28 Segmentgr NAD...28 CTA...29 COM...29 Segmentgr INP...29 FTX...30 DTM...30 Segmentgr GIS...30 MOA...30 LOC...30 NAD...30 RCS...30 FTX...30 Segmentgr PRC...31 FTX...32 Segmentgr (x) DOC...(x) MOA...(x) DTM...(x) RFF...(x) NAD...(x) Segmentgr (x) CUX...(x) DTM...(x) Segmentgr (x) AJT...(x) MOA...(x) RFF...(x) FTX...(x) Segmentgr (x) DLI...(x) MOA...(x) PIA...(x) DTM...(x) Segmentgr (x) CUX...(x) DTM...(x) Segmentgr (x) AJT...(x) MOA...(x) RFF...(x) FTX...(x) Segmentgr (x) GIS...(x) MOA...(x) DIRDEB Datenbeschreibung STUZZA Version Mai / 33

12 UNH-BGM-DTM-BUS-SG1-SG2-SG3-SG4-CNT-SG24-UNT UNH NACHRICHTEN-KOPFSEGMENT M NACHRICHTEN-REFERENZNUMMER M an..14 Diese Referenznummer ist aus syntaktischen Gründen erforderlich. Sie hat weder buchhalterische, noch Nachforschungs-Bedeutung. Auf sie wird bei Rückmeldung von Syntax-Fehlern (CONTRL Nachricht) und ggf. bei nachfolgender Authentifizierung (AUTACK) Bezug genommen. Sie muss innerhalb eines Interchanges (siehe Einleitung) eindeutig sein. Meist wird sie von Konvertern automatisch vergeben. S009 NACHRICHTENKENNUNG M 0065 Nachrichtentyp-Kennung M an..6 "DIRDEB" 0052 Versionsnummer des Nachrichtentyps M an..3 "D" 0054 Freigabenummer des Nachrichtentyps M an..3 "96A" 0051 Verwaltende Organisation, codiert M an..2 "UN" 0057 Anwendungscode der zuständigen R an..6 "FAT01G" für Finance AusTria VersionsnuMMer Generell Organisation 0068 ALLGEMEINE ZUORDNUNGS-REFERENZ N an..35 S010 STATUS DER ÜBERMITTLUNG N 0070 Übermittlungsfolgenummer M n Erste und letzte Übermittlung N a1 Beispiel: UNH+M1+DIRDEB:D:96A:UN:FAT01G' UNH-BGM-DTM-BUS-SG1-SG2-SG3-SG4-CNT-SG24-UNT BGM BEGINN DER NACHRICHT M 1 C002 DOKUMENTEN-/NACHRICHTENNAME R 1001 Dokumenten-/Nachrichtenname, codiert R an..3 "214" = Direct Debit Order 1131 Codeliste, Qualifier N an Verantwortliche Stelle für Codepflege, codiert N an Dokument/Nachrichtenname N an DOKUMENTEN-/NACHRICHTENNUMMER R an..35 Referenznummer des Dokuments. Mittels Angabe dieser Referenz im RFF der SGr.1 kann eine spätere Nachricht (z.b. ein DIRDEB als Kopie dieser Nachricht) einen Bezug herstellen. Daher muß sie eindeutig über einen Zeitraum von einem Monat sein. Für die Nachforschung hat diese Nummer keine Bedeutung NACHRICHTENFUNKTION, CODIERT R an..3 "9" = Original, "7" = Duplikat ("31" = Kopie). ein Duplikat ist immer an den Receiver des Originals gerichtet, eine Kopie immer an einen Dritten ANTWORT TYP, CODIERT N an..3 Beispiel: BGM+214+REFD3AL14+9' 10 Bezüglich der "Verpackung" der Nachricht zur Übertragung in einen Interchange siehe Beschreibung in der Einleitung. PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

13 UNH-BGM-DTM-BUS-SG1-SG2-SG3-SG4-CNT-SG24-UNT DTM DATUM/UHRZEIT/ZEITRAUM M 1 C507 DATUM/UHRZEIT/ZEITRAUM M 2005 Datum/Uhrzeit/Zeitraum, Qualifier M an..3 "137" = Erstellungszeit der Nachricht 2380 Datum/Uhrzeit/Zeitraum R an..35 CCYYMMDDHHMM oder CCYYMMDD 2379 Datum/Uhrzeit/Zeitraum, Formatqualifier R an..3 "203" bzw. "102" bevorzugt ist das Format "203", aus Gründen der internationalen Kompatibilität sind jedoch auch "102" zugelassen. Beispiel: DTM+137: :203' UNH-BGM-DTM-BUS-SG1-SG2-SG3-SG4-CNT-SG24-UNT BUS ART DES GESCHÄFTSVORFALLES D 1 detaillierte Beschreibung siehe BUS SGr UNH-BGM-DTM-BUS-SG1-SG2-SG3-SG4-CNT-SG24-UNT Segmentgruppe 1 D 2 wird nur verwendet, wenn auf eine frühere Nachricht Bezug genommen wird (BGM.1225 ungleich "9") RFF-DTM RFF REFERENZANGABEN M 1 C506 REFERENZ M 1153 Referenz, Qualifier M an..3 "ACW" = Referenznummer aus vorhergehender Nachricht 1154 Referenznummer R an..35 Referenznummer aus Feld 1004 des BGM der früheren Nachricht 1156 Zeilennummer N an Referenz Versionsnummer N an..35 Beispiel: RFF+ACW:REFD3AL10' RFF-DTM DTM DATUM/UHRZEIT/ZEITRAUM R 1 Anzugeben, wenn auf eine frühere Nachricht Bezug genommen wird C507 DATUM/UHRZEIT/ZEITRAUM M 2005 Datum/Uhrzeit/Zeitraum, Qualifier M an..3 "171" = Referenzdatum /Uhrzeit 2380 Datum/Uhrzeit/Zeitraum R an..35 CCYYMMDDHHMM oder CCYYMMDD 2379 Datum/Uhrzeit/Zeitraum, Formatqualifier R an..3 "203" bzw. "102" bevorzugt ist das Format "203", aus Gründen der internationalen Kompatibilität sind jedoch auch "102" zugelassen. Beispiel: DTM+171: :203' 11 Alle Angaben, die man in diesem BUS Segment auf Level A machen kann, können im BUS Segment auf Level B gemacht werden. Daher empfiehlt es sich, das BUS Segment im Level A wegzulassen, es sei denn, die im Level A gemachte Angabe trifft für alle Aufträge des gesamten DIRDEB zu. PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

14 UNH-BGM-DTM-BUS-SG1-SG2-SG3-SG4-CNT-SG24-UNT Segmentgruppe 2 O 5 Dient der Angabe der BLZ des empfangenden Instituts bzw. in speziellen Fällen auch einer Kundennummer bzw. Identifikation (FII C078:3194) DIESE GRUPPE WIRD NUR EINMAL AKZEPTIERT FII-CTA-COM FII KREDITINSTITUT M BETEILIGTER, QUALIFIER M an..3 "MR" message receiver (normalerweise das beauftragte Bank-Institut) C078 KONTOANGABEN O Nur gegen Vereinbarung mit dem empfangenden Institut in definierten Fällen 3194 Kontonummer R an..35 Identifikationsnummer entsprechend Vereinbarung Kontoinhaber N an Kontoinhaber N an Währung, codiert N an..3 C088 KREDITINSTITUT-IDENTIFIKATION R 3433 Internationaler Bankcode N an Codeliste, Qualifier N an Verantwortliche Stelle für Codepflege, codiert N an Nationaler Bankcode R an..17 BLZ des Empfängers der Nachricht 1131 Codeliste, Qualifier O an..3 "25" = Bank identification nur angebbar, wenn 3434 befüllt 3055 Verantwortliche Stelle für Codepflege, codiert O an..3 "137" =Austrian bankers association nur angebbar, wenn 3434 befüllt 3432 Name des Kreditinstitutes N an Ortsangabe einer Zweigstelle N an LAND, CODIERT R an..3 "AT" - ISO 3166 zwei Zeichen Ländercode; Beispiel: FII+MR++:::12000+AT' FII+MR+PS7006+:::60000:25:137+AT' FII-CTA-COM CTA KONTAKTSTELLE N 1 Der Kunde kann sich nicht zur Durchführung seiner Aufträge auf eine spezielle Stelle in der Bank beziehen FII-CTA-COM COM KOMMUNIKATIONSART N 5 Der Kunde kann sich nicht zur Durchführung seiner Aufträge auf eine spezielle Stelle in der Bank beziehen 12 Die Angabe dient hier ausschließlich zur Identifikation des Auftraggebers. Die Konten, denen die Auftragssummen gutgeschrieben werden, stehen im FII mit Qualifier OR in Segmentgruppe 6. PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

15 UNH-BGM-DTM-BUS-SG1-SG2-SG3-SG4-CNT-SG24-UNT Segmentgruppe 3 O 3 Diese Segmentgruppe kann verwendet werden, wenn die kontoführende Stelle eine zusätzliche Kennung des Absenders vorschreibt oder um eine Kontaktstelle für Rückfragen zu definieren. DIE SEGMENTGRUPPE WIRD NUR EINMAL AKZEPTIERT NAD-CTA-COM NAD NAME UND ANSCHRIFT M BETEILIGTER, QUALIFIER M an..3 "MS" = message sender C082 IDENTIFIKATION DES BETEILIGTEN O Identifikation des Beteiligten M an..35 siehe Fußnote Codeliste, Qualifier O an..3 siehe Fußnote Verantwortliche Stelle für Codepflege, codiert O an..3 siehe Fußnote 13 C058 NAME UND ANSCHRIFT N Wenn eine Angabe gemacht wird, dann in C080 und folgende 3124 Zeile für Name und Anschrift M an Zeile für Name und Anschrift N an Zeile für Name und Anschrift N an Zeile für Name und Anschrift N an Zeile für Name und Anschrift N an..35 C080 NAME DES BETEILIGTEN O Name des Senders der Nachricht; ggf. weitere Angaben in C059 und folgende 3036 Name des Beteiligten M an Name des Beteiligten O an Name des Beteiligten O an Name des Beteiligten O an Name des Beteiligten O an Name des Beteiligten Format, codiert N an..3 C059 STRASSE O Selbsterklärend 3042 Straße und Hausnummer/ Postfach M an Straße und Hausnummer/ Postfach O an Straße und Hausnummer/ Postfach O an Straße und Hausnummer/ Postfach O an ORT O an..35 selbsterklärend; gemeinsam mit 3251 maximal 35 Stellen 3229 REGION/BUNDESLAND, IDENTIFIKATION N an POSTLEITZAHL O an..9 Selbsterklärend 3207 LAND, CODIERT O an..3 ISO 3166 zwei Zeichen Ländercode Beispiel: NAD+MS' NAD+MS+++Medizinisch Diagnostisches Laborato:des Österr. Apothekerverbandes+Michelbeuerng. 1+Wien AT' 13 Ein internationaler Firmencode ist zur Zeit in Ausarbeitung bei der ISO. PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

16 NAD-CTA-COM CTA KONTAKTSTELLE O KONTAKT FUNKTION, CODIERT R an..3 "MS" Kontaktstelle des 'Message Sender' als einzig zulässiger Wert C056 KONTAKTSTELLE / KONTAKTPERSON R 3413 Kontaktstellen / Kontaktperson Identifikation O an..17 Abteilungs(Kurz)bezeichnung wo die Kontaktperson erreichbar ist 3412 Kontaktstellen / Kontaktperson R an..35 Name der Kontaktperson Beispiel: CTA+MS+:Mag. Ursula Klemperer' CTA+MS+Leistungsverrechn:Mag. Ursula Klemperer' NAD-CTA-COM COM KOMMUNIKATIONSART O 5 Sollte verwendet werden, wenn CTA kodiert ist, sonst nicht C076 KOMMUNIKATIONSART M 3148 Kommunikationsnummer M an..512 Kontakt"nummer" der Kontaktstelle / Kontaktperson. Die Länge wird applikatorisch auf 128 beschränkt 3155 Kommunikationsart Qualifier M an..3 "TE" Telefon, "EM" , "FX" Fax 14 Beispiel: COM+(01) :FX' COM+? :TE' COM+gustav.eisen@domaene.at:EM' A C H T U N G : An diese Stelle gehört der Level B. Die Beschreibung setzt jedoch mit dem Level A fort, damit diese Ebene im Ganzen abgeschlossen ist. UNH-BGM-DTM-BUS-SG1-SG2-SG3-SG4-CNT-SG24-UNT CNT KONTROLLWERTE R 5 Dieses Segment muß dreimal verwendet werden! C270 KONTROLLSUMMEN M 6069 Kontrollsumme, Qualifier M an..3 "1" algebraische Summe aller SGr. 5 MOA Betragsfelder der Nachricht "2" Anzahl der LIN-Abschnitte (=Anzahl der Auftragsbestände) der Nachricht "39" Anzahl der SEQ-Abschnitte (=Anzahl der "Be"Auftragungen) in der Nachricht 6066 Kontrollsummenwert M n..18 Summe entsprechend obigem Qualifier 6411 Maßeinheit, Qualifier N an..3 Beispiel: CNT+1:12036,54'CNT+2:8'CNT+39:18' 14 Telex und X400 werden nicht empfohlen, aber akzeptiert PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

17 UNH-BGM-DTM-BUS-SG1-SG2-SG3-SG4-CNT-SG24-UNT Segmentgruppe 24 N 5 Die Segmentgruppe 24 wird nicht verwendet. Die Autorisierung und Authentifizierung erfolgt über die separate Nachricht AUTACK AUT-DTM AUT AUTORISIERUNGSERGEBNIS N 1 AUT-DTM DTM DATUM/UHRZEIT/ZEITRAUM N 1 UNH-BGM-DTM-BUS-SG1-SG2-SG3-SG4-CNT-SG24-UNT UNT NACHRICHTEN-ENDE SEGMENT M ANZAHL SEGMENTE in der NACHRICHT M n..10 Für IZV auf maximal 10 Stellen erweitert! 0062 NACHRICHTEN-REFERENZNUMMER M an..14 derselbe Wert wie im UNH 0062 der Nachricht Beispiel: UNT+253+M1' Hier beginnt der Level B. UNH-BGM-DTM-BUS-SG1-SG2-SG3-SG4-CNT-SG24-UNT Segmentgruppe 4 M 9999 Das LIN-Segment leitet einen Auftragsbestand ein. Einem Auftragsbestand entspricht eine Sammelbelastung am Konto, welches in SGr 6 FII angegeben wird. LIN-DTM-RFF-BUS-FCA-SG5-SG6-SG7-SG8-SG9-SG10-SG11 LIN POSITIONSDATEN M POSITIONSNUMMER R n..6 fortlaufende Nummer, beginnend mit 1 innerhalb der Nachricht ACTION REQUEST / NOTIFICATION, CODED N an..3 C212 ITEM NUMBER IDENTIFICATION N 7140 Item number N an Item number Type, codiert N an Codeliste, Qualifier N an Verantwortliche Stelle für Codepflege, codiert N an..3 C829 SUB-LINE INFORMATION N 5495 Sub-line indicator, codiert N an Line item N n CONFIGURATION LEVEL N n CONFIGURATION, CODIERT N an..3 Beispiel: LIN+1' PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

18 LIN-DTM-RFF-BUS-FCA-SG5-SG6-SG7-SG8-SG9-SG10-SG11 DTM DATUM/UHRZEIT/ZEITRAUM O 1 Nur im Fall der Angabe eines in der Zukunft liegenden Durchführungsdatums C507 DATUM/UHRZEIT/ZEITRAUM M 2005 Datum/Uhrzeit/Zeitraum, Qualifier M an..3 "203" gewünschtes Durchführungsdatum 2380 Datum/Uhrzeit/Zeitraum R an..35 CCYYMMDD 2379 Datum/Uhrzeit/Zeitraum, Formatqualifier R an..3 "102" Beispiel: DTM+203: :102' LIN-DTM-RFF-BUS-FCA-SG5-SG6-SG7-SG8-SG9-SG10-SG11 RFF REFERENZANGABEN R 2 Zur Angabe einer Bestandskontrollnummer; scheint in der Gutschriftsanzeige bzw. am Kontoauszug des Auftraggebers auf WIRD NUR EINMAL AKZEPTIERT! C506 REFERENZ M 1153 Referenz, Qualifier M an..3 "AKJ" Auftragsnummer des Einzugsbestands 1154 Referenznummer R an..35 vom Kunden vergebene, innerhalb eines Jahres eindeutige Referenz für diesen Sammelauftrag. (wegen der Einschränkung des MT940 z.zt. auf 16 Stellen begrenzt). Die Referenznummer darf, mit Ausnahme des Bindestrichs, KEINE Sonderzeichen enthalten! 1156 Zeilennummer N an Referenz Versionsnummer N an..35 Beispiel: RFF+AKJ:LAB ' PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

19 LIN-DTM-RFF-BUS-FCA-SG5-SG6-SG7-SG8-SG9-SG10-SG11 BUS ART DES GESCHÄFTSVORFALLES D 1 Die bevorzugte Verwendung dieses Segments ist an dieser Stelle (Level B), kann jedoch auch auf Level A erfolgen. Es muß jedoch einmal verwendet werden. Jede Angabe im BUS Segment bedingt, daß diese Angabe für alle folgenden Einzelaufträge gilt. Die möglichen Eintragungen im BUS Segment stellen somit Zusammenfassungskriterien für Aufträge (in Sammelaufträge) dar. Einzelaufträge, die verschiedene Einträge in diesem BUS Segment benötigen, können nicht in einem Auftragsbestand (LIN-Abschnitt) gemischt werden. C521 ART DES GESCHÄFTSVORFALLS O 4027 Art des Geschäftsvorfalls, Qualifier M an..3 "1" der nachfolgende Code beschreibt den der Zahlung zugrundeliegenden Geschäftsvorfall (aus Sicht des Auftraggebers) 4025 Art des Geschäftsvorfalls, codiert M an..3 CODE entsprechend UN-Tabelle (siehe Fußnote) Codeliste, Qualifier N an Verantwortliche Stelle für Codepflege, codiert N an Beschreibung der Geschäftsart N an GEOGRAPHISCHER BEREICH, CODIERT R an..3 "DO"=domestic, der Begünstigte ist in Österreich und ist hier resident 4487 ART DER FINANZTRANSAKTION, CODIERT D an..3 Die folgenden Transaktionscodes sind verwendbar: "14" Einzug gemäß Einzugsermächtigungsverfahren (temporärer Code war "82") "13" Lastschrift auf Basis Abbuchungsauftrag (temporärer Code war "83") Alternativ zu SEQ:1159 wird 4487 nicht kodiert, muss SEQ:1159 kodiert werden C551 BANK OPERATION (ZAHLUNGSFORM) R Die Angabe eines Bank Operation Code ist zwingend 4383 Bank operation, codiert M an..3 "DDT" Direct Debit Transfer 1131 Codeliste, Qualifier N an Verantwortliche Stelle für Codepflege, codiert N an INTRA-COMPANY PAYMENT, CODIERT N an..3 Beispiel: BUS++DO++DDT' BUS+1:LOR+DO++DDT' BUS++DO+13+DDT' BUS+1:LOR+DO+13+DDT' 15 Dieser Code wird (unkontrolliert) bis zur Empfängerbank (und, wenn der Empfänger EDIFACT Daten entgegennimmt, bis zum Empfänger) durchgeschleust. Der Empfänger kann daraus schließen, in welchen Teilbereich seiner Buchhaltung er den Einzug zu buchen hat. Diese Angabe ist jedoch nicht zwingend. PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

20 LIN-DTM-RFF-BUS-FCA-SG5-SG6-SG7-SG8-SG9-SG10-SG11 FCA FINANCIAL CHARGES ALLOCATION N 1 LIN-DTM-RFF-BUS-FCA-SG5-SG6-SG7-SG8-SG9-SG10-SG11 Segmentgruppe 5 R 1 MOA-CUX-DTM-RFF MOA GELDBETRAG M 1 Die Angabe dieses Gesamtauftragswerts wird abschließend im CNT Segment auf Level A zur algebraischen Summe hinzuaddiert. C516 GELDBETRAG M 5025 Geldbetragsart, Qualifier M an..3 "9" einzuziehender Gesamtbetrag, der dem Konto des Auftraggebers in weiterer Folge gutgeschrieben wird Geldbetrag R n..18 Summe aller Überweisungsbeträge der Einzelaufträge dieses LIN-Abschnitts (bankseitig auf 12 Vorkommastellen begrenzt). Maximal 2 Nachkommastellen Währungscode R an..3 ISO 4217 drei Zeichen Währungscode "EUR" als einzig zulässiger Wert 6343 Währung, Qualifier N an Status codiert N an..3 Beispiel: MOA+9:12580,50:EUR' MOA-CUX-DTM-RFF CUX CURRENCIES N 1 MOA-CUX-DTM-RFF DTM DATUM/UHRZEIT/ZEITRAUM N 2 MOA-CUX-DTM-RFF RFF REFERENZANGABEN N 1 PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

21 LIN-DTM-RFF-BUS-FCA-SG5-SG6-SG7-SG8-SG9-SG10-SG11 Segmentgruppe 6 M 1 FII-CTA-COM FII KREDITINSTITUT M BETEILIGTER, QUALIFIER M an..3 "OR" Kontoverbindung des Auftraggebers = Einziehers bei der beauftragten Bank 16 C078 KONTOANGABEN R 3194 Kontonummer R an..35 Kontonummer oder IBAN des Auftraggebers. Auf dieser erfolgt die Gutschrift für den Sammelauftrag Kontoinhaber R an..35 Zwingend mit Kontowortlaut zu befüllen Kontoinhaber O an..35 Fortsetzung Kontowortlaut 6345 Währung, codiert R an..3 ISO 4217 drei Zeichen Währungscode des Auftraggeberkontos C088 KREDITINSTITUT-IDENTIFIKATION D Nicht zu verwenden bei IBAN in 3194, sonst zwingend 3433 Internationaler Bankcode N an Codeliste, Qualifier N an Verantwortliche Stelle für Codepflege, codiert N an Nationaler Bankcode R an..17 BankLeitZahl des beauftragten Instituts (exakt 5 Stellen) Codeliste, Qualifier O an..3 "25" = Bank identification nur angebbar, wenn 3434 befüllt 3055 Verantwortliche Stelle für Codepflege, codiert O an..3 "137" =Austrian bankers association nur angebbar, wenn 3434 befüllt 3432 Name des Kreditinstitutes N an Ortsangabe einer Zweigstelle N an LAND, CODIERT D an..3 "AT" - ISO 3166 zwei Zeichen Ländercode; nicht zu verwenden bei IBAN in 3194, sonst zwingend Beispiel: FII+OR+AT :Med. Diag. Laboratorium::EUR' FII+OR+AT :MED. DIAG. LABORATORIUM:1090 Wien:EUR' FII+OR :Med. Diag. Laboratorium::EUR+:::60000:25:137+AT' FII+OR :Med. Diag. Laboratorium:1090 Wien:EUR+:::60000:25:137+AT' FII-CTA-COM CTA KONTAKTSTELLE N 1. FII-CTA-COM COM KOMMUNIKATIONSART N 5 16 Aus der hier angegebenen Kontoverbindung resultiert die Abrechnungswährung für den Auftraggeber. 17 Die Verwendung des NAD mit Qual "OY" für die Auftraggeberbezeichnung ist nur dann erforderlich, wenn der Kontoinhaber nicht mit dem Auftraggeber übereinstimmt (Einzug im Namen eines Anderen, z.b. "Huber Corp." als Kontoinhaber zieht ein für "Huber Information Services" als Auftraggeber). PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

22 LIN-DTM-RFF-BUS-FCA-SG5-SG6-SG7-SG8-SG9-SG10-SG11 Segmentgruppe 7 D 3 Die Daten dieser Segmentgruppe werden unverändert an den Bezogenen weitergegeben, sofern dieser EDIFACT entgegennehmen kann. Andernfalls kann nur die Weitergabe von 2 Zeilen à 35 Zeichen garantiert werden. Wenn die Bezogenenbank die Daten des Auftrags für den Bezogenen ausdrucken muß, wird sie diese Felder in zwei Zeilen à 35 Stellen zusammenziehen und bei Überschreiten der möglichen Gesamtlänge (=70) entsprechend kürzen (bzw. abschneiden). Die Verwendung des NAD mit Qualifier "OY" (Auftraggebername) ist nur dann möglich wenn der Inhaber des Auftraggeberkontos nicht identisch ist mit dem Auftraggeber oder der Auftraggeber eine zusätzliche, kodifizierte Identifikation seiner selbst im Feld 3039 an den Bezogenen weitergeben möchte und der LIN Abschnitt nur Abbuchungen von diesem Bezogenen enthält. WIRD NUR EINMAL AKZEPTIERT! LIN-DTM-RFF-BUS-FCA-SG5-SG6-SG7-SG8-SG9-SG10-SG11 NAD-CTA-COM NAD NAME UND ANSCHRIFT M BETEILIGTER, QUALIFIER M an..3 "OY" für Auftraggeber C082 IDENTIFIKATION DES BETEILIGTEN O 3039 Identifikation des Beteiligten M an..35 Code (unter dem der Auftraggeber dem Bezogenen bekannt ist, z.b. eigene Kundennummer beim Abnehmer). Überschreibt beim Druckservice die zusätzliche Auftraggeberzeile Codeliste, Qualifier N an Verantwortliche Stelle für Codepflege, codiert N an..3 C058 NAME UND ANSCHRIFT N Auftraggeberangaben erfolgen immer strukturiert! 5 x 3124 Zeile für Name und Anschrift M an..35 C080 NAME DES BETEILIGTEN D Zwingend wenn Auftraggeber ungleich Kontoinhaber; sonst nicht zu verwenden 5 x 3036 Name des Beteiligten M an Name des Beteiligten Format, codiert N an..3 C059 STRASSE O Optional wenn Auftraggeber ungleich Kontoinhaber; sonst nicht zu verwenden 4 x 3042 Straße und Hausnummer/Postfach M an ORT O an..35 Optional wenn Auftraggeber ungleich Kontoinhaber; sonst nicht zu verwenden; gemeinsam mit 3251 maximal 35 Stellen 3229 REGION/BUNDESLAND, IDENTIFIKATION N an POSTLEITZAHL O an..9 Optional wenn Auftraggeber ungleich Kontoinhaber; sonst nicht zu verwenden 3207 LAND, CODIERT O an..3 ISO 3166 zwei Zeichen Ländercode Beispiel: NAD+OY+++Medizinisch Diagnostisches Laborato:des Östterr. Apothekerverbandes+Michelbeuerng. 1+Wien AT' NAD-CTA-COM CTA KONTAKTSTELLE O 1 NAD-CTA-COM COM KOMMUNIKATIONSART O 5 PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

23 LIN-DTM-RFF-BUS-FCA-SG5-SG6-SG7-SG8-SG9-SG10-SG11 Segmentgruppe 8 D 1 detaillierte Beschreibung siehe SGr. 14. Wenn die Weisung auf Level B aufscheint, gilt sie für alle Einzelaufträge des Auftragsbestands (LIN-Abschnitt). Die Verwendung der SGr. 8 ist gegenseitig ausschließend mit der Verwendung der SGr 14. Ein Überschreiben der Weisung im Level B durch eine andere im Level C codierte Weisung ist nicht möglich! INP-FTX-DTM INP BESONDERE WEISUNG M 1 INP-FTX-DTM FTX FREIER TEXT N 1 INP-FTX-DTM DTM DATUM/UHRZEIT/ZEITRAUM N 2 LIN-DTM-RFF-BUS-FCA-SG5-SG6-SG7-SG8-SG9-SG10-SG11 Segmentgruppe 9 N 10 GIS-MOA-LOC-NAD-RCS-TFX GIS GENERAL INDICATOR M 1 GIS-MOA-LOC-NAD-RCS-TFX MOA GELDBETRAG N 1 GIS-MOA-LOC-NAD-RCS-TFX LOC PLACE / LOCATION IDENTIFICATION N 2 GIS-MOA-LOC-NAD-RCS-TFX NAD NAME UND ANSCHRIFT N 1 GIS-MOA-LOC-NAD-RCS-TFX RCS REQUIREMENTS AND CONDITIONS N 1 GIS-MOA-LOC-NAD-RCS-TFX FTX FREIER TEXT N 10 PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

24 LIN-DTM-RFF-BUS-FCA-SG5-SG6-SG7-SG8-SG9-SG10-SG11 Segmentgruppe 10 D 1 Die SGr. 10 dient (so wie SGr. 16) zur Weitergabe von den Einzug betreffende Information vom Auftraggeber an den Bezogenen. SGr. 10 kann jedoch nur dann verwendet werden, wenn 1) die Information in unstrukturierter Form weitergegeben wird und 2) für alle nachfolgenden Einzelaufträge gleich ist - d.h. die gleichbleibende Information wird auf Level B herausgehoben. Typischer Fall = "Prämie MM/JJ" für alle Versicherten, deren Prämieneinzüge folgen. zu beachten : (*) wird die SGr. 10 (Level B) benützt, so darf in den zugehörigen Einzelumsätzen in S.Gr 16 kein FTX auftreten. PRC-FTX PRC PROZESSBEZEICHNUNG M 1 C242 PROZESSART UND -BESCHREIBUNG M 7187 Prozeßart, Identifikation M an..17 "11" Information in unstrukturierter Form -> FTX folgt 1131 Codeliste, Qualifier N an Verantwortliche Stelle für Codepflege, codiert N an..3 2 x 7186 Prozeßart N an..35 Beispiel: PRC+11' PRC-FTX FTX FREIER TEXT M TEXTZUORDNUNG, QUALIFIER M an..3 "PMD" Verwendungszweck (Payment Details) 4453 TEXTVERARBEITUNGSHINWEIS, CODIERT N an..3 C107 TEXT-REFERENZ N 4441 Freier Text, codiert M an Codeliste, Qualifier N an Verantwortliche Stelle für Codepflege, codiert N an..3 C108 TEXT R 5 x 4440 Freier Text M an..70 Verwendungszweck in Textform SPRACHE, CODIERT N an..3 Beispiel: FTX+PMD+++Prämie Leben 04/03 inkl. Anpassung 3,456%' 18 Es wird dringend empfohlen auf die Längenbeschränkungen der Zeilen gemäß C-Beleg zu achten (also maximal 5 Zeilen mit maximal 57 Stellen). Andernfalls muß beim Ausdruck umformatiert werden und es kann nicht garantiert werden, daß die Information dabei vollständig bleibt. PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

25 LIN-DTM-RFF-BUS-FCA-SG5-SG6-SG7-SG8-SG9-SG10-SG11 Segmentgruppe 11 M 9999 IZV: Diese Segmentgruppe leitet die Angaben zum Einzelauftrag ein. Jedem SEQ-Abschnitt entspricht ein Auftrag innerhalb des Sammelauftrags (Auftragsbestands = LIN-Abschnitt) Für IZV Auftragsbestände gilt die Beschränkung des UN/EDIFACT Max-Wiederholungsfaktor von 9999 nicht. Die meisten Banken akzeptieren auch größere Auftragsbestände. Der tatsächlich maximale Wiederholungsfaktor ist mit der kontoführenden Bank abzustimmen. SEQ-MOA-DTM-RFF-PAI-FCA-SG12-SG13-SG14-SG15-SG16 SEQ EINZELHEITEN ZUR REIHENFOLGE M STATUSKENNZEICHEN, CODIERT N an..3 C286 INFORMATION ÜBER EINE FOLGE R 1050 Folgenummer M an..6 fortlaufende Nummer, beginnend mit "1" innerhalb des Auftragsbestands 1159 Folgenummer source, codiert D an..3 Transaktionscode als Alternative zum Code im BUS Segment "82" Einzug gemäß Einzugsermächtigungsverfahren "83" Lastschrift auf Basis Abbuchungsauftrag "66" mit PSK zu vereinbaren und nur an PSK zu liefern. Nicht zu verwenden wenn BUS:4487 kodiert ist, sonst zwingend 1131 Codeliste, Qualifier D an..3 "EBA" Zwingend wenn 1159 kodiert ist, sonst nicht zu verwenden 3055 Verantwortliche Stelle für Codepflege, codiert D an..3 "137" Zwingend wenn 1159 kodiert ist, sonst nicht zu verwenden Beispiel: SEQ++1' SEQ++1:83:EBA:137' SEQ-MOA-DTM-RFF-PAI-FCA-SG12-SG13-SG14-SG15-SG16 MOA GELDBETRAG M 1 C516 GELDBETRAG M 5025 Geldbetragsart, Qualifier M an..3 "9" für Einzugsbetrag 5004 Geldbetrag R n..18 Einzugsbetrag. (z.zt. bankseitig auf 9 Vorkommastellen begrenzt). Maximal 2 Nachkommastellen Währungscode R an..3 ISO 4217 drei Zeichen Währungscode "EUR" als einzig zulässiger Wert 6343 Währung, Qualifier N an Status codiert N an..3 Beispiel: MOA+9:123,75:EUR' SEQ-MOA-DTM-RFF-PAI-FCA-SG12-SG13-SG14-SG15-SG16 DTM DATUM/UHRZEIT/ZEITRAUM N 1 Angabe des Durchführungsdatums ist immer für den ganzen Auftragsbestand gültig und daher auf Level B anzugeben PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

26 SEQ-MOA-DTM-RFF-PAI-FCA-SG12-SG13-SG14-SG15-SG16 RFF REFERENZANGABEN A 3 Dieses Segment dient dazu, Referenzen zum aktuellen Auftrag für Sender und Empfänger bzw. Bank aufzunehmen. Ein Segment mit Qualifier CR dient der eigenen Zuordnung. Die Qualifier PQ und AEF sind Referenzen für den Bezogenen (Kunde od. Bank). Die Angabe einer Auftraggeberreferenz (CR) ist strengstens empfohlen! Im Fall einer Rücklastschrift erlaubt sie die einfache und rasche Zuordnung zum ursprünglichen Einzugsauftrag. Jede dieser Referenzen (PQ, AEF, CR) darf maximal einmal vorkommen!. C506 REFERENZ M International ist dieses Segment mindestens mit "CR" mitzugeben! 1153 Referenz, Qualifier M an..3 "PQ" Referenz für den Zahlungspflichtigen. 19 "AEF" für die Weitergabe einer Referenznummer an den Zahlungspflichtigen 20 (der zugehörige Wert in Feld 1154 muß numerisch und genau 12 Stellen sein). "CR" Auftraggeber-Referenz 1154 Referenznummer R an..35 entsprechende Nummer (Wert) entsprechend obigem Qualifier 1156 Zeilennummer N an Referenz Versionsnummer N an..35 Beispiel: RFF+PQ:Lebensversicherung Polizze 34/45678'RFF+CR:APO ' RFF+PQ:Gebäudeversicherung'RFF+AEF: 'RFF+CR:APO ' SEQ-MOA-DTM-RFF-PAI-FCA-SG12-SG13-SG14-SG15-SG16 PAI PAYMENT INSTRUCTION N 1 SEQ-MOA-DTM-RFF-PAI-FCA-SG12-SG13-SG14-SG15-SG16 FCA FINANCIAL CHARGES ALLOCATION N 1 19 Zum Unterschied von Gutschriftsaufträgen ist bei Einzügen der Initiator der Transaktion gleichzeitig auch der Erbringer der Leistung (Lieferant, etc). Das bedeutet, daß bei Lastschriften meist der Auftraggeber selbst den Grundgeschäftsfall referenziert hat und diese Referenz bei Geschäftsabschluß dem Geschäftspartner (=Bezogener) bekannt gegeben hat. Auf diese Referenz sollte sich der Einzieher unter "PQ" beziehen. Daher ist PQ ist eine alphanumerische Referenz für den Empfänger, die das dem (meist periodischen wiederkehrenden) Einzug zugrundeliegende Grundgeschäft bezeichnet: z.b. Policennummer, Anschlussnummer (Gas, Telefon) oder ähnliches. Diese Referenz sollte von Einzug zu Einzug gleich bleiben. AEF ist eine Referenz für den Bezogenen für die Weitergabe eines rein numerischen Begriffs, z.b. an Hausverwaltungen. CR hingegen ist eine Referenz, die der Auftraggeber selbst (nur) dieser Einzugstransaktion zugeordnet hat. Sie wird im Falle einer Rücklastschrift zurückgeleitet und dient dem Auftraggeber dann zur Identifikation der ursprünglichen Lastschrift. Auch wenn das Grundgeschäft für die Einzüge gleichbleibt, kann die (und wird wohl auch) "CR" Referenz von Mal zu Mal wechseln (z.b. ein Wert, der sowohl Policennummer, als auch Prämien Monat in eine (vielleicht nur für den Auftraggeber interpretierbare) Nummer zusammenschließt. Ist eine CR angegeben, so wird diese bei Rücklastschriften immer zurückgegeben. Die Rückgabe der Bezogenenreferenz (PQ und AEF) ist im Fall einer Rücklastschrift empfohlen, kann aber nicht garantiert werden. 20 Werden PQ und AEF gemeinsam verwendet darf der PQ Wert nicht länger als 28 Stellen sein. Tritt PQ ohne AEF auf, so ist es maximal 35 Stellen lang. PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

27 SEQ-MOA-DTM-RFF-PAI-FCA-SG12-SG13-SG14-SG15-SG16 Segmentgruppe 12 R 3 Zwingend für die Angabe der Kontoverbindung des Zahlungspflichtigen. Mehrfachnennung ist nicht möglich. FII-CTA-COM FII KREDITINSTITUT M BETEILIGTER, QUALIFIER M an..3 "PH" Kontoverbindung des Zahlungspflichtigen C078 KONTOANGABEN R 3194 Kontonummer M an..35 Kontonummer, maximal 11 stellig, numerisch, bzw. IBAN (siehe Fußnote) Kontoinhaber R an..35 Kontowortlaut Kontoinhaber O an..35 Kontowortlaut, optionale zweite Zeile 6345 Währung, codiert N an..3 C088 KREDITINSTITUT-IDENTIFIKATION D Nicht zu verwenden bei IBAN, sonst zwingend 3433 Internationaler Bankcode N an Codeliste, Qualifier N an Verantwortliche Stelle für Codepflege, codiert N an Nationaler Bankcode R an..17 BLZ Empfänger Institut (exakt 5 Stellen) 1131 Codeliste, Qualifier O an..3 "25" = Bank identification nur angebbar, wenn 3434 befüllt 3055 Verantwortliche Stelle für Codepflege, codiert O an..3 "137" =Austrian bankers association nur angebbar, wenn 3434 befüllt 3432 Name des Kreditinstitutes N an Ortsangabe einer Zweigstelle N an LAND, CODIERT D an..3 "AT" - ISO 3166 zwei Zeichen Ländercode. Bei IBAN nicht verwendet, sonst erforderlich. Beispiel: FII+PH+AT :Apotheke zur Kaiserkrone' FII+PH :Apotheke zur Kaiserkrone:1010 Freyung 4+:::60000:25:137+AT' 21 Die IBAN (international bank account no) ist eine international normierte Schreibweise (ISO 13616) der Kontoverbindung, die sowohl das Land (des kontoführenden Instituts) als auch sämtliche national notwendigen Informationen enthält in der Form "LLppNNNNNNNNNNNNNNNN" wobei LL der ISO LänderCode (ISO 3166), pp eine Prüfziffer (Länder- und Institutsübergreifend nach ISO 7604) und NNNNNNNNNNNNNNNN die Bankleitzahl und die Kontonummer enthält. Die österreichischen Kreditinstitute geben die IBAN seit Beginn 1999 an ihre Kunden zur Verwendung als Kontoverbindung mit ihren ausländischen Geschäftspartnern aus. Im Zuge der Angleichungen der europäischen nationalen Zahlungssysteme kann der Auftraggeber die IBAN auch für den IZV verwenden werden, mit dem Vorteil, daß der Prüfvorgang unabhängig von der BLZ ist. Sie wird daher als Alternative zur getrennten Angabe von BLZ und Kontonummer zugelassen. Im IZV kann sich die IBAN allerdings nur auf eine inländische Kontoverbindung beziehen, d.h. sie muß genau 20 Stellen lang sein und mit AT beginnen. 22 An dieser Stelle wird immer die Bezeichnung (Name und Anschrift) des Bezogenenkontos angegeben, eine alternative Angabe der Kontobezeichnung in SGr. 13 NAD ist nicht möglich. PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

28 FII-CTA-COM CTA KONTAKTSTELLE N 1 FII-CTA-COM COM KOMMUNIKATIONSART N 5 SEQ-MOA-DTM-RFF-PAI-FCA-SG12-SG13-SG14-SG15-SG16 Segmentgruppe 13 D 3 Nur möglich, wenn Zahlungspflichtiger nicht gleich Kontoinhaber (FII SGr. 12) oder der Kontoinhaber nicht resident ist. NAD-CTA-COM NAD NAME UND ANSCHRIFT M BETEILIGTER, QUALIFIER M an..3 "PL" Zahlungspflichtiger 23 C082 IDENTIFIKATION DES BETEILIGTEN N 3039 Identifikation des Beteiligten M an Codeliste, Qualifier N an Verantwortliche Stelle für Codepflege, codiert N an..3 C058 NAME UND ANSCHRIFT D Alternativ zu C080 falls Bezogener ungleich Kontoinhaber; der strukturierten Angabe ist der Vorzug zu geben. Die gleichzeitige Kodierung in sowohl strukturiert als auch unstrukturiert ist verboten! 5 x 3124 Zeile für Name und Anschrift M an..35 C080 NAME DES BETEILIGTEN D Alternativ zu C058 5 x 3036 Name des Beteiligten M an..35 Die bevorzugte Angabe ist die strukturierte Form (C080, C059, 3164, 3229, 3251) 3045 Name des Beteiligten Format, codiert N an..3 C059 STRASSE D Alternativ zu C058 4 x 3042 Straße und Hausnummer/Postfach M an ORT D an..35 Alternativ zu C058; gemeinsam mit 3251 maximal 35 Stellen 3229 REGION/BUNDESLAND, IDENTIFIKATION N an POSTLEITZAHL O an..9 optional 3207 LAND, CODIERT O an..3 ISO 3166 zwei Zeichen Ländercode. (angeben wenn nicht AT z.b. Zahlungspflichtiger /Kontoinhaber ist nonresident, hat aber ein Konto in Österreich) Beispiel: NAD+PL+++Mag. Dr. Kommerzialrat:Eugen Apothezky-Nasselreuth+Naglergasse 12/6:Postfach 24+Zürich CH' 23 Für die Angabe der bezogenen Seite ist PL der einzig mögliche Qualifier. Die Angabe von Name/Anschrift des Bezogenen falls ident mit dem Kontoinhaber erfolgt in Feld 3192 im FII Segment SGr. 12. In diesem Fall wird das NAD ausschließlich zur ev. Kennzeichnung eines nicht Residenten verwendet. Nur wenn der Kontoinhaber nicht ident mit dem Bezogenen des Einzugs ist, ist das NAD mit PL zur Angabe der Daten des Bezogenen zu verwenden. Generell ist die Angabe in strukturierter Form vorzuziehen, auch wenn die Längenbeschränkungen für den Ausdruck dadurch nicht geändert werden (2 Zeilen à 35). PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

29 NAD-CTA-COM CTA KONTAKTSTELLE N 1 NAD-CTA-COM COM KOMMUNIKATIONSART N 5 SEQ-MOA-DTM-RFF-PAI-FCA-SG12-SG13-SG14-SG15-SG16 Segmentgruppe 14 O 3 Im IZV kann die SGr. 14 (und SGr. 8 ) für spezielle Institutsservices verwendet. werden INP-FTX-DTM INP BESONDERE WEISUNG M 1 C849 BETEILIGTE an der WEISUNG R 3301 Beauftragter einer Weisung, Identifikator M an..17 "3" Bank des Begünstigten Empfänger der Aktion/Weisung, Identifikator N an..17 C522 WEISUNG R 4403 Weisung, Qualifier M an..3 "1" (action required) 4401 Weisung, codiert R an..3 Nach Vereinbarung 1131 Codeliste, Qualifier R an..3 Nach Vereinbarung 3055 Verantwortliche Stelle für Codepflege, codiert R an..3 Nach Vereinbarung 4400 Instruction D an..35 Nach Vereinbarung C850 STATUS OF INSTRUCTION N 4405 Status, codiert M an Party name N an ACTION REQUEST/NOTIFICATION, CODED N an..3 PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33

30 INP-FTX-DTM FTX FREIER TEXT N 1 INP-FTX-DTM DTM DATUM/UHRZEIT/ZEITRAUM N 2 SEQ-MOA-DTM-RFF-PAI-FCA-SG12-SG13-SG14-SG15-SG16 Segmentgruppe 15 N 10 GIS-MOA-LOC-NAD-RCS-FTX GIS GENERAL INDICATOR M 1 GIS-MOA-LOC-NAD-RCS-FTX MOA GELDBETRAG N 1 GIS-MOA-LOC-NAD-RCS-FTX LOC PLACE / LOCATION IDENTIFICATION N 2 GIS-MOA-LOC-NAD-RCS-FTX NAD NAME UND ANSCHRIFT N 1 GIS-MOA-LOC-NAD-RCS-FTX RCS REQUIREMENTS AND CONDITIONS N 1 GIS-MOA-LOC-NAD-RCS-FTX FTX FREIER TEXT N 10 PAYMUL IZV Datenbeschreibung STUZZA Version Mai / 33