KONTOPRUEF-Logo
Sehen Sie sich auch mein anderes Produkt an:
myebilanz – die Freeware-eBilanz aus MySQL und CSV!
myebilanz

Funktionen von KONTOPRUEF

Inhalt dieser Seite:

Online-Prüfungen

Für eine Beschreibung der Parameter und der Ergebnisfelder sehen Sie bitte auf der Seite der Bankverbindungsprüfung bzw. der Adreßprüfung nach. Falls Sie die HanftWddx-COM-Objekte unter Windows installiert haben, finden Sie die Beschreibung der Felder und Funktionen auf der HanftWddx-Seite.

Lokale Installationen

Die generellen Aufrufmechanismen, Datentypen usw. sind auf der Seite "Technik" beschrieben, so daß hier nur auf die universelle Funktionalität eingegangen wird.

Es gibt folgende Objekte:

  • Bank.KtoUpdate zur Datenverwaltung des Gesamtsystems: Datendateien und Updates herunterladen, entpacken und aktivieren;
  • Bank.KtoPruef zum Prüfen von Bankverbindungen und mit anderen Diensten rund um Bankleitzahlen und Kontonummern;
  • Bank.KtoRead zum Einlesen von elektronischen Kontoauszügen in SQL-Datenbanken;
  • Bank.KtoDtaus zum Erzeugen und Prüfen von DTAUS-Dateien;
  • Bank.KtoSepa zum Erzeugen von SEPA-XML-Dateien mit Überweisungen oder Lastschriften, inkl. einer Mini-Datenbank zur automatischen SequenceType-Ermittlung;
  • Bank.KtoSwift zur Abfrage der SWIFT-Website;
  • Bank.KtoArbeit zur Ermittlung der Arbeitstage in einem bestimmten Monat, Quartal oder Jahr.

Hinweis zur Nomenklatur: Eine procedure wird mit verschiedenen Parametern aufgerufen und gibt kein Ergebnis zurück (es können allerdings einige Parameter nach der Rückkehr einen neuen Wert haben - davon wird hier aber nirgendwo Gebrauch gemacht). Eine function wird ebenfalls mit verschiedenen Parametern aufgerufen, gibt aber ein Funktionsergebnis zurück.

An verschiedenen Stellen ist u.U. ein Fehler "-999" möglich: Dieser gibt an, daß momentan überhaupt keine Datendatei (weder "Demo" noch "vollständig") geladen ist.

Allen Objekten gemeinsam sind die beiden folgenden Funktionen:

  • function GetErrorMessage

    Eingabeparameter
    NameTypInhalt
    aErrorCodeIntegerFehlernummer dieses Objekts
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringFehlernummer im Klartext

    Viele Funktionen liefern eine Fehlernummer zurück, wobei 0 meistens "kein Fehler" bedeutet. Die KONTOPRUEF-Fehlernummern (und einige andere) finden Sie auf der Seite mit der Online-Bankverbindungsprüfung; wenn Sie in Ihrer Software einen Fehlertext statt einer Fehlernummer benötigen, können Sie diese Funktion verwenden, die eine Fehlernummer in einen Fehlertext übersetzt. (Dies geht immer und überall - völlig unabhängig davon, ob tatsächlich ein Fehler aufgetreten ist oder nicht! Es handelt sich nur um eine "Zahl-zu-Text-Übersetzung", weiter nichts.)

    Bitte beachten Sie, dass die Fehlernummern des KtoSepa-Objekts davon abweichend an Windows-Fehlernummern angelehnt sind. Hier sollten Sie stets (auch) über die Funktion GetLastError den Fehlertext des zuletzt aufgetretenen Fehler ausgeben (im "OK"-Fall, also bei Result=0, ist dies ein Leerstring).

  • function GetLastError

    Eingabeparameter
    NameTypInhalt
    ---
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringGgf. zusätzliche Informationen zum zuletzt aufgetretenen Fehler

    Wenn ein Fehler aufgetreten ist, können Sie hier u.U. zusätzliche Informationen über die Fehlerursache erhalten (nicht bei allen Funktionen); so wird z.B. beim fehlgeschlagenen Öffnen von Datenbanken bei Bank.KtoRead die Klartext-Fehlermeldung des Betriebssystems abgelegt, mit deren Hilfe Sie dann unterscheiden können, ob die Verbindung zum SQL-Server nicht aufgebaut werden konnte oder ob lediglich Benutzername/Kennwort ungültig waren o.ä.

Hier nun die speziellen Prozeduren und Funktionen der einzelnen Objekte:

Nach oben

KtoUpdate

Bank.KtoUpdate kümmert sich um den Download und die Verwaltung von Datendateien und Updates. Der Name einer Datendatei ist bankxxyz.wbd (wbd=Windows-Bank-Daten) bzw. bankxxyz.lbd (lbd=Linux-Bank-Daten). (In der Demo-Version, in der nur ein Teil der Banken enthalten ist, ist bank durch demo ersetzt.) Neue Datendateien können vom Update-Server heruntergeladen werden, entweder per Softwareaufruf (s.u.) oder per manuellem Download. Die übertragenen Dateien heißen bankxxyz.wbp (wbp=Windows-Bank-Paket) bzw. bankxxyz.lbp (lbp=Linux-Bank-Paket) und sind zur schnelleren Übertragung gepackt (ca. 170 KB statt ausgepackt ca. 800 KB) und mit einer kryptographischen Signatur versehen, um Übertragungsfehler oder Hacker-Angriffe beim Download zu verhindern.

Die Stellen "xxyz" in den Dateinamen bedeuten:

  • xx = Endziffern des Jahres, in dem diese Datei erstellt wurde, also z.B. "04" für 2004;
  • y = Laufende Nummer im jeweiligen Jahr; gegenwärtig erscheinen vier Datendateien pro Jahr; d.h. diese Nummer bedeutet
    • 1 = März
    • 2 = Juni
    • 3 = September
    • 4 = Dezember
  • z = 0 bei den Originaldateien; sollte die Bundesbank innerhalb eines Quartals auf Fehler in ihren Daten aufmerksam machen, gibt es "Zwischen-Updates", die hier von 1 an aufwärts gezählt werden.

Die Datendateien und -pakete werden stets ohne Verzeichnisangabe verwendet. Die Verzeichnisse werden unter Windows bzw. unter Linux unterschiedlich festgelegt:

  • Unter Windows spielt sich das Herunterladen der wbp-Pakete und das Speichern der wbd-Dateien standardmäßig im selben Verzeichnis ab, in dem sich auch Bank.exe befindet. Das Benutzerkonto, unter dem Bank.exe läuft, muß also auf dieses Verzeichnis Schreibzugriff haben. Da das seit Windows Vista problematisch sein kann, empfiehlt es sich, das Datenverzeichnis mit der Funktion KtoUpdate.SetDataDirectory in einen "ungefährlichen" Ordner zu verlegen.
  • Unter Linux wird das Datendateiverzeichnis durch einen Eintrag in der Datei /etc/KtoPruef.conf festgelegt, der z.B. für das Verzeichnis /home/mh/data wie folgt aussehen muß:
    [Directories]
    data=/home/mh/data

Die einzelnen Prozeduren und Funktionen:

  • function KtoUpdate.GetCurrentFileName

    Eingabeparameter
    NameTypInhalt
    ---
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringName der Datendatei, die gerade aktiviert ist. Leer, wenn überhaupt keine Datendatei aktiviert ist

    Gibt den Namen der momentan aktivierten Datendatei zurück. Beim Programmstart wird automatisch die neueste vorhandene Datendatei aktiviert. Falls überhaupt keine bank...-Datei existiert, wird nach demo...-Dateien gesucht und von diesen die neueste aktiviert.

  • function KtoUpdate.GetNewestFileName

    Eingabeparameter
    NameTypInhalt
    ---
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringName der neuesten lokal verfügbaren Datendatei. Leer, wenn überhaupt keine Datendatei lokal verfügbar ist

    Durchsucht das Verzeichnis der Datendateien und gibt den Dateinamen der neuesten lokal verfügbaren Datendatei zurück. Diese Funktion wird auch intern beim Programmstart verwendet, um die damit ermittelte Datendatei automatisch zu aktivieren.

  • function KtoUpdate.GetDataDirectory
    Nur in Windows, nicht in Linux!
    Erst verfügbar ab KONTOPRUEF 2.1 vom 12.02.06!

    Eingabeparameter
    NameTypInhalt
    ---
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringMomentan eingestelltes Verzeichnis für die nächsten Datendatei-Operationen

    Gibt das Verzeichnis zurück, in dem die nächste Datendatei-Operation (Herunterladen, Entpacken, Aktivieren) stattfinden wird. Das Verzeichnis ist immer mit einem Delimiter ("\" unter Windows) abgeschlossen.

  • procedure KtoUpdate.SetDataDirectory
    Nur in Windows, nicht in Linux!
    Erst verfügbar ab KONTOPRUEF 2.1 vom 12.02.06!

    Eingabeparameter
    NameTypInhalt
    aDataDirectoryStringVerzeichnisname
    Ausgabeparameter
    NameTypInhalt
    ---

    Setzt das Verzeichnis, in dem die nächste Datendatei-Operation (Herunterladen, Entpacken, Aktivieren) stattfinden soll. Ein evtl. fehlender Delimiter am Verzeichnisende ("\" unter Windows) wird ggf. automatisch ergänzt. Das übergebene Verzeichnis wird nicht auf Existenz geprüft.

  • procedure KtoUpdate.SetProxy

    Eingabeparameter
    NameTypInhalt
    aHostStringName des Proxy-Servers
    aPortIntegerPortnummer des Proxy-Servers
    Ausgabeparameter
    NameTypInhalt
    ---

    Falls Sie für den Update-Abruf einen Proxy-Server verwenden möchten oder müssen, können Sie hier die nötigen Angaben machen. Es wird nur dann ein Proxy-Server verwendet, wenn der angegebene Name nicht leer ist und wenn der Port von 0 verschieden ist.

  • procedure KtoUpdate.SetTimeout

    Eingabeparameter
    NameTypInhalt
    aTimeoutIntegerTimeout in Sekunden
    Ausgabeparameter
    NameTypInhalt
    ---

    Hier können Sie einen maximalen Grenzwert für das Warten auf die Antwort des Update-Servers einstellen. Wenn der Server nicht in der angegebenen Zeit antwortet, wird der Update-Versuch mit einem Fehlercode abgebrochen. Wenn Sie diese Prozedur nie aufrufen, wird Ihr systemweit konfigurierter Timeout-Wert verwendet.

  • function KtoUpdate.ServerCheck

    Eingabeparameter
    NameTypInhalt
    aUserStringBenutzername für den Update-Server
    aPassStringKennwort für den Update-Server
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringBei Erfolg: '+' und Name des auf dem Update-Server vorhandenen Datendateipakets
    Bei Mißerfolg: '-' und Begleittext

    Fragt den Update-Server nach der momentan dort vorliegenden Datendatei. Ist eine Datei zum Abruf bereit, wird der Dateiname mit einem vorangestellten Pluszeichen zurückgeliefert, also z.B. +bank0430.wbp für die 3. Ausgabe 2004 des Windows-Bank-Pakets. Ist keine Datei vorhanden, ist die Benutzerkennung ungültig oder kann die Verbindung nicht hergestellt werden o.ä., beginnt der Rückgabewert mit einem Minuszeichen, hinter dem im Klartext der Grund des Scheiterns steht. Ggf. können Sie mit KtoUpdate.GetLastError weitere Informationen erhalten.

  • function KtoUpdate.ServerDownload

    Eingabeparameter
    NameTypInhalt
    aUserStringBenutzername für den Update-Server
    aPassStringKennwort für den Update-Server
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringBei Erfolg: '+' und Name des heruntergeladenen Datendateipakets
    Bei Mißerfolg: '-' und Begleittext

    Im Prinzip das gleiche wie ServerCheck, nur daß die Datei im Erfolgsfall gleich heruntergeladen wird (in das Verzeichnis der Datendateien). Eine evtl. bereits vorhandene gleichnamige Datei wird dabei überschrieben.

  • function KtoUpdate.Unpack

    Eingabeparameter
    NameTypInhalt
    aFileNameStringDateiname eines heruntergeladenen Datendateipakets
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok
    5: Zugriff verweigert (s.u.)
    13: Fehler in Datendateipaket

    Hiermit kann ein wbp- bzw. lbp-Datendateipaket zu einer wbd- bzw. lbd-Datendatei entpackt werden. Vorhandene Datendateien werden dabei überschrieben - dies funktioniert jedoch nicht, wenn die zu überschreibende Datendatei gerade aktiviert (d.h. in Gebrauch ist). Bei einem Fehler können Sie mit KtoUpdate.GetLastError weitere Informationen erhalten.

  • function KtoUpdate.Activate

    Eingabeparameter
    NameTypInhalt
    aFileNameStringDateiname einer lokal vorhandenen Datendatei (leer für neueste)
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok
    3: Datei nicht vorhanden bzw. keine Datei gefunden
    13: Neue Datendatei konnte nicht geladen werden; alte Datendatei wurde wieder geladen
    14: Neue Datendatei konnte nicht geladen werden; auch alte Datendatei konnte nicht wieder geladen werden

    Hiermit kann eine lokal vorliegende Datendatei aktiviert und in KONTOPRUEF verwendet werden. Wird kein Dateiname übergeben, wird intern GetNewestFileName aufgerufen, um die neueste Datendatei zu ermitteln. Bei einem Fehler können Sie mit KtoUpdate.GetLastError weitere Informationen erhalten.

Hinweis: Alle Bank.KtoUpdate-Funktionen können im laufenden Betrieb aufgerufen werden!

Nach oben

KtoPruef

  • function KtoPruef.GetVersion

    Eingabeparameter
    NameTypInhalt
    ---
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringVersionsangaben

    Liefert eine Versionsangabe ähnlich Version vom 17.08.04 (BLZ-Stand 06.09.04) zurück.

  • function KtoPruef.GetVersionExtended

    Eingabeparameter
    NameTypInhalt
    ---
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringErweiterte Versionsangaben

    Liefert erweiterte Versionsangaben zurück, und zwar mehrere Angaben in einem String, die durch eine Tilde ("~") getrennt sind. Das Ende des Strings wird durch zwei Tilden ("~~") markiert. Die einzelnen Felder bedeuten:

    1. Lesbare Versionsangabe wie bei GetVersion
    2. Jahr der Daten, z.B. 2004
    3. Lfd. Nr. im Jahr, also 1 bis 4
    4. Korrekturnummer (0 bis 9)
    5. Datum des ersten Gütigkeitstags im Format TT.MM.JJ
    6. Datum des letzten Gütigkeitstags im Format TT.MM.JJ
    7. Angabe, ob es sich um eine Demo-Version handelt (True) oder nicht (False)

    Ein Rückgabewert könnte also wie folgt aussehen:
    Version vom 17.08.04 (BLZ-Stand: 06.09.04)~2004~3~0~06.09.04~05.12.04~True~~
    Es ist damit zu rechnen, daß in künftigen Version noch weitere Felder hinten an den String angehängt werden.

  • function KtoPruef.TestBlzKto

    Eingabeparameter
    NameTypInhalt
    aBlzStringZu prüfende Bankleitzahl
    aKtoStringZu prüfende Kontonummer
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisIntegerPrüfergebnis

    Prüft die angegebene Bankleitzahl-/Kontonummernkombination auf Gültigkeit. Die möglichen Ergebnisse finden Sie hier.

  • function KtoPruef.TestIban

    Eingabeparameter
    NameTypInhalt
    aIbanStringZu prüfende IBAN
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok
    12: Es sind nicht nur Ziffern und Buchstaben enthalten
    13: Prüfzifferfehler (bisher)
    22: Prüfzifferfehler (künftig)
    25: IBAN stammt aus keinem SEPA-Land (z.B. bei "BR..." für Brasilien oder "XY..." für kompletten Unsinn) (ab Version 1412)
    26: IBAN-Format passt nicht zum Land (z.B. in den Niederlanden müssen – nach dem Länderkürzel und der Prüfziffer – vier Buchstaben und zehn Ziffern kommen, in Deutschland 18 Ziffern etc.) (ab Version 1412)

    Prüft die angegebene IBAN auf Gültigkeit (nur die Prüfziffer und das jeweilige Länderformat). Bei deutschen IBAN ("DE...") wird empfohlen, bei einem positiven Prüfergebnis (result=0) zusätzlich BLZ und KTO aus der IBAN zu entnehmen (BLZ=5. bis 12. Stelle der IBAN, KTO=13. bis 22. Stelle) und mit diesen Daten die Funktion TestBlzKto aufzurufen, um zusätzlich die in der IBAN enthaltene nationale Bankverbindung zu prüfen.

  • function KtoPruef.TestCC

    Eingabeparameter
    NameTypInhalt
    aCCStringZu prüfende Kreditkartennummer
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok
    1: Unbekannter Kartentyp
    12: Es sind nicht nur Ziffern enthalten
    13: Prüfzifferfehler

    Prüft die angegebene Kreditkartennummer auf Gültigkeit. Wichtiger Hinweis: Im Gegensatz zu den "amtlichen" Unterlagen bei den Bankverbindungen beruht die Kreditkartenprüfung auf unsicheren Unterlagen aus dem Internet. Die Verfahren sind zwar mit vorhandenen Kreditkarten getestet worden, aber es ist nicht völlig ausgeschlossen, daß diese Prüfung in Einzelfällen ein falsches Ergebnis anzeigt.

  • function KtoPruef.GetIban

    Eingabeparameter
    NameTypInhalt
    aBlzStringBankleitzahl
    Ab Version 1320 (Juni 2013) kann ein Stern angehängt werden für die Berücksichtigung der IBAN-Regeln der Bundesbank und Ermittlung des BIC
    aKtoStringKontonummer
    aSpaceFlagIntegerIBAN soll
    0: ohne
    1: mit
    Zwischenräume(n) zur besseren Lesbarkeit generiert werden
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringGenerierte IBAN
    Bei Angabe eines Stern hinter der BLZ: Generierte IBAN~Generierter BIC
    Weitere mögliche Ergebnisse ab Version 1220 (Juni 2012): Diese Ergebnisse können nur auftreten, wenn an die Bankleitzahl ein Stern angehängt wurde, also z.B. "76010085*" als Bankleitzahl übergeben wurde:
    *Fehlercode
    Führt die Ermittlung der IBAN zu einem Fehler, enthält das Ergebnis an der ersten Stelle einen Stern und dahinter den üblichen KONTOPRUEF-Fehlercode gemäß Fehlercodetabelle (also z.B. "*-1" für "Bankleitzahl existiert nicht" oder "*13" für "Prüfziffer fehlerhaft"). Eine IBAN wird in diesem Fall nicht gebildet.
    *24 erweiterter Fehlercode
    Im Fall des Fehlercodes 24 wird hinter einem Zwischenraum ein "erweiterter" Fehlercode, bestehend aus zwei Zeichen angegeben:
    • I1, I2 etc. für "interne" Fehler, die eigentlich nie vorkommen sollten
    • UN für Uneindeutigkeit des Unterkontos, siehe Funktionsbeschreibung unten
    • NS zeigt an, dass die angegebene Bankverbindung nicht am SEPA-Zahlungsverkehr teilnimmt
    Falls Sie jemals Fehlercode 24 mit einem "I"-Code erhalten sollen, wäre es nett, wenn mir dies (unter Angabe der verwendeten Bankleitzahl und Kontonummer) mitteilen könnten. Im Falle von anderen "24"-Fehlermeldungen bleibt Ihnen leider nichts anderes übrig, als die IBAN tatsächlich bei Ihrem Geschäftspartner zu erfragen (s.u.).

    Generiert aus der angegebenen Bankverbindung eine IBAN (und bei Angabe von * hinter der BLZ auch noch den BIC hinter ~, also z.B. "DE99100000001234567890~BANKDEFFXXX"). Wichtig: In der Standardvariante (Übergabe von Bankleitzahl und Kontonummer wie bisher) akzeptiert diese Funktion jegliche Eingabewerte (auch völlig unsinnige wie "4yti17" als Bankleitzahl) und generiert daraus stur nach Schema eine (möglicherweise ebenso unsinnige) IBAN. Für eine automatisierte Umstellung Ihres Datenbestands sollten Sie also nur die erweiterte Funktion (mit angehängtem Stern an die Bankleitzahl) ab Juni 2013 benutzen, da hier auch geprüft wird, ob das Unterkonto "00" an die Kontonummer angehängt werden muss oder ob ggf. weitere Umwandlungen vorgenommen werden müssen), bevor die IBAN gebildet wird. Beispiel: 1234566 ist bei der Deutschen Bank eine gültige Kontonummer, aber die IBAN muss aus der Kontonummer 123456600 (Unterkonto=00) gebildet werden. KONTOPRUEF berücksichtigt diese Besonderheit und muss lediglich in den wenigen Fällen passen, in denen sowohl die Interpretation der letzten beiden Ziffern als Unterkonto als auch das Anhängen des Unterkontos "00" eine gültige Prüfziffer ergibt. In diesem Fall kann die IBAN nicht zuverlässig ermittelt werden, und Sie müssen sie tatsächlich manuell bei Ihrem Geschäftspartner erfragen.

    Wichtig: Falls Sie den COM-Server "Bank.exe" auch zur Handeingabe bei der Ermittlung von IBAN und BIC verwenden, achten Sie bitte darauf, Version 3.0.2 zu verwenden. Sie können die Datei hier herunterladen. Dies betrifft nur die Handeingabe in der Benutzeroberfläche! Wenn Sie nur die Funktion GetIban mit dem "*" verwenden, genügt auch Version 3.0.0.

    Verwenden Sie nur diese Funktion mit * (ab Juni 2013), um Ihren vorhandenen KTO/BLZ-Datenbestand in IBAN/BIC zu konvertieren!

  • function KtoPruef.GetBic

    Eingabeparameter
    NameTypInhalt
    aBlzStringBankleitzahl
    ab Version 1310: auch mit angehängtem Pluszeichen zur PAN-Ermittlung, oder PAN mit angehängtem Minuszeichen zur BLZ-Ermittlung
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringBIC zur angegebenen Bankleitzahl
    oder: PAN zur angegebenen Bankleitzahl (bei Aufruf mit "+")
    oder: BLZ zur angegebenen PAN (bei Aufruf mit "-")

    Gibt den BIC (Bank Identifier Code) für die angegebene Bank zurück. Ist für diese Bank kein BIC vorhanden, wird ein Leerstring zurückgegeben.
    Ab Bankdatenversion 1310 lässt sich diese Funktion auch zur Ermittlung der PAN "missbrauchen":

    • Eingabeparameter BLZ "76010085" wie bisher: Ergebnis wie bisher: BIC "PBNKDEFF760"
    • Eingabeparameter BLZ "76010085+" (mit angehängtem Pluszeichen): Ergebnis: PAN "10085"
    • Eingabeparameter PAN "10085-" (mit angehängtem Minuszeichen): Ergebnis: BLZ "76010085"
    • Eingabeparameter PAN "21114-" (mit angehängtem Minuszeichen): Ergebnis: BLZ "51370024+51570024+53370024"

    Da die PAN nicht eindeutig ist, können als Ergebnis auch mehrere Bankleitzahlen herauskommen, die dann durch Pluszeichen getrennt sind (siehe letztes Beispiel). Als PAN wird immer nur die nationale fünfstellige Nummer verarbeitet (sowohl bei der Ein- als auch bei der Ausgabe). Wird die angegebene BLZ oder PAN gar nicht gefunden, wird ein Leerstring zurückgegeben.

    Bitte beachten Sie: Zur Konvertierung von KTO/BLZ nach IBAN/BIC ist diese Funktion nicht geeignet, da hier weder Nachfolge-Bankleitzahlen noch die IBAN-Regeln der Bundesbank berücksichtigt werden! Bitte verwenden Sie zur Konvertierung ausschließlich die Funktion GetIban, wobei Sie an die BLZ einen Stern "*" anhängen (ab Bankdatenversion 1320 / Juni 2013).

  • function KtoPruef.GetBankName58

    Eingabeparameter
    NameTypInhalt
    aBlzStringBankleitzahl
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringName der Bank, maximal 58 Zeichen lang

    Liefert den (maximal 58 Zeichen langen) Namen der über die angegebene Bankleitzahl identifizierten Bank zurück. Existiert diese Bankleitzahl nicht, wird ein Leerstring zurückgegeben.

  • function KtoPruef.GetBankName20

    Eingabeparameter
    NameTypInhalt
    aBlzStringBankleitzahl
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringName der Bank, maximal 20 Zeichen lang

    Liefert den (maximal 20 Zeichen langen) Namen der über die angegebene Bankleitzahl identifizierten Bank zurück. Existiert diese Bankleitzahl nicht, wird ein Leerstring zurückgegeben.

  • function KtoPruef.GetBankName27

    Eingabeparameter
    NameTypInhalt
    aBlzStringBankleitzahl
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringName der Bank, maximal 27 Zeichen lang

    Liefert den (maximal 27 Zeichen langen) Namen der über die angegebene Bankleitzahl identifizierten Bank zurück. Existiert diese Bankleitzahl nicht, wird ein Leerstring zurückgegeben. Hinweis: Dies ist der Name, der in früheren KONTOPRUEF-Versionen über GetBankName abrufbar war.

  • function KtoPruef.GetBankPlz

    Eingabeparameter
    NameTypInhalt
    aBlzStringBankleitzahl
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringPostleitzahl der Bank

    Liefert die Postleitzahl der über die angegebene Bankleitzahl identifizierten Bank zurück. Existiert diese Bankleitzahl nicht oder hat die Bank keine Postleitzahl gemeldet, wird ein Leerstring zurückgegeben.

  • function KtoPruef.GetBankOrt

    Eingabeparameter
    NameTypInhalt
    aBlzStringBankleitzahl
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringOrt der Bank

    Liefert den Ort der über die angegebene Bankleitzahl identifizierten Bank zurück. Existiert diese Bankleitzahl nicht, wird ein Leerstring zurückgegeben. Hinweis: Der hier zurückgegebene Ort beinhaltet nicht notwendigerweise die korrekte Schreibweise für Anschriften auf Postsendungen! Prüfen Sie daher die korrekte Schreibweise mit der KONTOPRUEF-Adreßprüfung.

  • function KtoPruef.GetFirstBank

    Eingabeparameter
    NameTypInhalt
    ---
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringBankleitzahl der ersten Bank in der momentan aktivierten Datendatei

    Wenn Sie alle Banken der momentan aktivierten Datendatei auslesen wollen, rufen Sie zuerst GetFirstBank auf, und danach so lange GetNextBank, bis ein Leerstring zurückgegeben wird.

  • function KtoPruef.GetNextBank

    Eingabeparameter
    NameTypInhalt
    ---
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringBankleitzahl der nächsten Bank in der momentan aktivierten Datendatei

    Wenn Sie alle Banken der momentan aktivierten Datendatei auslesen wollen, rufen Sie zuerst GetFirstBank auf, und danach so lange GetNextBank, bis ein Leerstring zurückgegeben wird.

  • function KtoPruef.GetFirstMatch

    Eingabeparameter
    NameTypInhalt
    aSearchStringStringEin oder mehrere Wörter oder Wortbestandteile, nach denen gesucht werden soll (UND-verknüpft)
    aFragmentsFlagIntegerEs soll
    0: nur nach ganzen Wörtern
    1: auch nach Wortbestandteilen
    gesucht werden
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringBankleitzahl der ersten Bank, die die Suchkriterien erfüllt

    Hiermit können Sie die Bankleitzahl einer Bank anhand ihres Namens suchen (es wird der "BankName27" verwendet). Geben Sie mehr als einen Begriff mit Zwischenräumen ein. Wenn bereits hier als Ergebnis ein Leerstring zurückkommt, gibt es überhaupt keine Banken, die Ihre Suchkriterien erfüllen; ansonsten rufen Sie danach so lange GetNextMatch auf, bis ein Leerstring zurückkommt.

    Sonderfunktion: Standardmäßig sucht diese Funktion nur in den Banknamen, die Sie mit GetBankName27 erhalten. Da dort etliche Banknamen nur abgekürzt enthalten sind (insbesondere wird dort oft Spk statt Sparkasse verwendet), können Sie durch Anhängen eines Pluszeichens + an den Suchbegriff die Suche auf den "langen" Banknamen aus GetBankName58 erweitern (d.h. mit der Suche nach Sparkasse+ erhalten Sie alle BLZ, bei denen das Wort "Sparkasse" entweder im BankName27 oder im BankName58 (oder in beiden) vorkommt.

  • function KtoPruef.GetNextMatch

    Eingabeparameter
    NameTypInhalt
    ---
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringBankleitzahl der nächsten Bank, die die Suchkriterien erfüllt

    Arbeitet die Suchergebnisse ab, die Sie bei GetFirstMatch angegeben haben. Wenn keine weitere Bank gefunden wird, wird ein Leerstring zurückgegeben.

Veraltete Interfaces:

  • GetReg: Liefert einen String zurück, in dem steht, daß es keine Registrierungsinformationen mehr gibt.
  • Init, InitFile, InitReg, SetRegCode: Tun nichts und liefern 0 (Ok) zurück.
  • GetBankName: Wird intern auf GetBankName27 abgebildet.

Nach oben

KtoRead

Nur in der Windows-, nicht in der Linux-Version!

Das Objekt Bank.KtoRead bietet Ihnen die Möglichkeit, elektronische Kontoausüge (im Format MT940 und ab Version 1740 auch im Format camt.053), die Sie von Ihrer Bank abgerufen haben, in eine SQL-Datenbank einzulesen. Unter Windows wird dazu die "ADO"-Technologie genutzt; Sie können alle Datenbanken verwenden, für die es einen ODBC-Treiber gibt; außerdem steht ein spezieller Treiber für den MS-SQL-Server zur Verfügung. mySQL-Datenbanken können Sie verwenden, wenn Sie den ODBC-Treiber für mySQL installieren und in KONTOPRUEF den Typ "ODBC" angeben.

Es muß dazu eine Datenbank mit zwei Tabellen geben, die vorab von Ihnen angelegt werden müssen, und zwar wie folgt (fettgedruckte Angaben sind für SEPA nötig und unterscheiden sich von der früheren Definition):

CREATE TABLE KONTOAUSZUEGE (NR INTEGER NOT NULL,
        BLZ VARCHAR(11) NOT NULL,
        KONTO VARCHAR(34) NOT NULL,
        AUSZUGNR INTEGER NOT NULL,
        ALTGUTDATUM DATE NOT NULL,
        ALTGUTWAE CHAR(3) NOT NULL,
        ALTGUTBETRAG NUMERIC(15, 2) NOT NULL,
        NEUGUTDATUM DATE NOT NULL,
        NEUGUTWAE CHAR(3) NOT NULL,
        NEUGUTBETRAG NUMERIC(15, 2) NOT NULL,
        USERID INTEGER NOT NULL,
PRIMARY KEY (NR));

CREATE TABLE KONTOUMSAETZE (NR INTEGER NOT NULL,
        AUSZUGNR INTEGER NOT NULL,
        VALUTA DATE NOT NULL,
        BUCHUNG DATE NOT NULL,
        BETRAG NUMERIC(15, 2) NOT NULL,
        ORIWAE CHAR(3),
        ORIBETRAG NUMERIC(15, 2),
        GVC INTEGER NOT NULL,
        BUTEXT VARCHAR(27),
        PN VARCHAR(10),
        BLZ VARCHAR(11),
        KONTO VARCHAR(34),
        ABSENDER VARCHAR(70),
        VERWEND VARCHAR(378), /* SEPA nur 140 */
        TSE INTEGER,
        USERID INTEGER NOT NULL,
PRIMARY KEY (NR));

Anmerkung: Bei manchen Datenbanken kann für den Betrag auch der Datentyp Money statt Numeric(15,2) verwendet werden bzw. für die Datumsfelder SmallDateTime statt Date. Bitte sehen Sie in der Dokumentation der Datentypen Ihrer Datenbank nach.

Hinweis: Das Feld AuszugNr in der Tabelle KontoUmsaetze ist im Prinzip ein Foreign Key auf das Feld Nr (nicht AuszugNr!) in der Tabelle KontoAuszuege. Den Foreign Key Restraint darf man aber in SQL nicht verwenden, da die Umsätze vor den Auszügen in die Datenbank eingefügt werden). Das Feld AuszugNr in der Tabelle KontoAuszuege ist rein informatorisch (dort wird das von der Bank gelieferte Feld unverändert übernommen).

Wichtiger Hinweis zum Feld KONTO: Obwohl es in Deutschland maximal zehnstellige nationale Kontonummern gibt, ist dieses Feld länger, da Sie von Ihrer Bank möglicherweise systeminterne Kontonummern bereitgestellt bekommen (z.B. mit vorangestellter Filialennummer, mit angefügter Unterkontonummer und/oder Währungskennzeichen). Außerdem kann eine IBAN bis zu 34 Stellen lang sein; am besten konfigurieren Sie das KONTO-Feld daher auch mit (mindestens) dieser Länge.

Beispiele, was im Kontoauszug alles enthalten sein kann, wenn Ihre Kontonummer 123456 lautet:

Empfangene KontonummerBemerkung
123456"Normale" Kontonummer
000000000000123456Mit führenden Nullen
12345600Mit angehängter Unterkontonummer 00
0000123456888Führende Nullen, angehängte 888
416000123456Filiale vor der Kontonummer
0000123456EURFührende Nullen, angehängte Währungsbezeichnung
41600012345600888EURKombination aus allen obigen Möglichkeiten
DE99123456781234567890123456789012IBAN für den SEPA-Zahlungsverkehr
Es ist außerdem auch möglich, daß im Auszug keine Bankleitzahl bzw. kein BIC enthalten ist;
das Feld BLZ in der Datenbank enthält in diesem Fall einen Leerstring!

Neben den allgemeinen beiden Fehlerfunktionen gibt es nur eine einzige spezifische Funktion:

  • function KtoRead.ReadMt940

    Eingabeparameter
    NameTypInhalt
    aDatabaseTypeInteger0: ODBC
    1: MS-SQL
    Modifikatoren:
    +64 (ab Version 1740): Datumswerte werden im Format "YYYY-MM-DD" (statt "DD.MM.YYYY") an die Datenbank übergeben (nötig z.B. für MySQL)
    +128: Es wird nicht versucht, Transaktionsverwaltung in der Datenbank für das Schreiben von Auszügen und Umsätzen zu verwenden
    aDatabaseNameStringBei ODBC: Der System- oder User-DSN-Name aus der ODBC-Verwaltung
    Bei MS-SQL: Der Servername; falls nicht die Default-Datenbank auf diesem Server genutzt werden soll, kann der Datenbankname hinter einem Schrägstrich ("/") noch angehängt werden (also z.B. my.database.xy/Accounting).
    Neu ab Version 0510: Hinter den Datenbanknamen können noch im Format "#Auszugtabellenname#Umsatztabellenname" die Namen der gewünschten Tabellen angehängt werden, falls nicht die Standardtabellennamen (s.o.) verwendet werden sollen.
    aUsernameStringDer Benutzername, mit dem auf die Datenbank zugegriffen werden soll; ist dieser Name leer, wird die Windows-Authentifizierung verwendet
    aPasswordStringDas Kennwort, mit dem auf die Datenbank zugegriffen werden soll
    aFileNameStringDer Dateiname der Kontoauszugsdatei; kann leer sein, dann wird lediglich eine kurze Testverbindung zur Datenbank aufgebaut.
    aTranslationStringParameter, wie Non-Swift-Auszüge übersetzt werden sollen, siehe unten
    aUserIdIntegerBeliebige Zahl, die in die letzte Spalte der Datenbank geschrieben wird, um z.B. die Herkunft eines Datensatzes zu dokumentieren
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok
    1: Datenbanktyp ungültig
    2: ADO ist nicht installiert
    3: Datenbank kann nicht geöffnet werden
    4: Auszugsdatei kann nicht geöffnet werden
    5: Auszug kann nicht in die Datenbank geschrieben werden
    6: Umsatz kann nicht in die Datenbank geschrieben werden

    Diese Funktion liest die angegebene Kontoauszugsdatei in die angegebene Datenbank ein. Bei allen Fehlern können Sie mit KtoRead.GetLastError weitere Informationen abrufen. Wenn kein Fehler aufgetreten ist, erhalten Sie ab Version 1740 mit KtoRead.GetLastError folgende Informationen:

    • den erkannten Auszugstyp (STA, C52, C53 oder C54)
    • die Anzahl der in die Datenbank geschriebenen Auszüge
    • die Anzahl der in die Datenbank geschrieben Umsätze
    • ggf. die Fehlermeldung des XML-Parsers, durch die Sie erkennen können, warum auf das MT940-Format umgeschaltet wurde.

    Mit dem Parameter aTranslation können beliebige MT940-"Non-Swift"-Auszüge in ein geeignetes Format konvertiert werden. Normalerweise geht KONTOPRUEF von einem Swift- Format mit dem Mehrzweckfeld :86: aus (siehe Beschreibung des Swift-Formats). In diesem Fall brauchen Sie bei aTranslation nichts angeben. Sollte Ihre Bank jedoch Non-Swift-Auszüge senden (Mehrzweckfeld :NS:, siehe Beschreibung des Non-Swift-Formats), können Sie hier einen String übergeben, der die einzelnen Felder zuordnet. Dieser String hat das Format XX:YY,XX:YY,XX:YY,XX:YY usw., wobei jedes Feld XX des Non-Swift-Formats in das Feld YY des Swift-Formats übersetzt wird. Ich hatte z.B. einmal einen Auszug, bei dem der String 01:20,02:32,03:00,04:10 lauten mußte, was bedeutet:

    • NS-Feld 01 wird in 20 übersetzt (Verwendungszweck)
    • NS-Feld 02 wird in 32 übersetzt (Auftraggeber)
    • NS-Feld 03 wird in 00 übersetzt (Buchungstext)
    • NS-Feld 04 wird in 10 übersetzt (Primanota)
    • NS-Feld 05 wird ignoriert (unbekannt; hätte eine Uhrzeit sein können; die kommt aber in Swift ohnehin nicht vor).

    Die Belegung ist bei verschiedenen Banken aber leicht unterschiedlich - es empfiehlt sich also, den Kontoauszug der jeweiligen Bank vor dem ersten Einlesen genau zu untersuchen, damit eine vernünftige Übersetzungstabelle übergeben werden kann.

Nach oben

KtoDtaus

Mit dem KtoDtaus-Objekt lassen sich DTAUS-Dateien, mit denen man Überweisungen und Lastschriften an Banken senden kann, sowohl erzeugen als auch prüfen. Ab Version 0442 der Datendatei ist außerdem die Erzeugung des DTAUS-"Spezialformats" für den Auslands-Lastschrifteinzug der Landesbank Baden-Württemberg enthalten. Spezielle Parameter für diesen Dienst, die von den normalen inländischen DTAUS-Dateien abweichen, sind in den folgenden Funktionsbeschreibungen mit "LBBW:" markiert.

Die Funktionen im einzelnen:

  • function KtoDtaus.CreateFile

    Eingabeparameter
    NameTypInhalt
    aFileNameStringDatei, in die die DTAUS-Datei geschrieben werden soll. Geben Sie hier sinnvollerweise einen vollständigen Pfadnamen an (z.B. C:\temp\dtaus001.dta bzw. /tmp/dtaus001.dta), sonst wird die Datei möglicherweise in irgendein System-Unterverzeichnis geschrieben, in dem Sie sie nie wieder finden werden
    aBlzStringEigene Bankleitzahl
    LBBW: 99935000
    aKtoStringEigene Kontonummer
    LBBW: Pseudokontonummer des jeweiligen Landes:
    • 2020202020 für Österreich
    • 2121212121 für Belgien
    • 2222222222 für Frankreich
    • 2323232323 für Schweiz
    • 2424242424 für Niederlande
    • 2525252525 für Italien
    • 2626262626 für Großbritannien
    aNameStringKontobezeichnung des eigenen Kontos (maximal 54stellig; längere Namen werden nach 54 Zeichen abgeschnitten)
    LBBW: Nach der Kontobezeichnung müssen (nach einem Zwischenraum) noch Währung und Landeskennung, getrennt durch einen Bindestrich folgen, also z.B. "MUSTERMANN EUR-IT" für EUR-Lastschriften in Italien. Die Gesamtlänge aus Kontobezeichnung, Wührung und Land darf maximal 27 Zeichen betragen!
    aNumberStringNummer (als String) dieser DTAUS-Datei. Frei wählbar (maximal zehnstellig); bei den meisten Banken wird diese Nummer bei der Buchung im Kontoauszug mit ausgedruckt
    aTypeInteger1: Überweisungen (Gutschriften)
    2: Einzug (Lastschriften)
    LBBW: Hier ist nur 2 für Lastschriften möglich.
    aCheckFlagInteger0: Die angegebenen Bankverbindungen werden ohne Prüfung in die DTAUS-Datei geschrieben
    1: Die angegebenen Bankverbindungen (inkl. der eigenen!) werden nur dann in die DTAUS-Datei geschrieben, wenn eine Prüfung durch KONTOPRUEF ergeben hat, daß die Bankverbindung in Ordnung ist; ansonsten erfolgt eine Fehlerrückmeldung, und der Datensatz wird nicht in die DTAUS-Datei geschrieben. Sollte bei CreateFile die eigene Bankverbindung bereits ungültig sein, wird die DTAUS-Datei gar nicht erst erzeugt und kann daher auch nicht weiter beschrieben werden
    LBBW: Hier muß 0 angegeben werden, da ausländische Bankverbindungen so nicht geprüft werden können.
    aDaysAheadIntegerNormalerweise 0, damit die Datei bei der Bank sofort bearbeitet wird. Soll die Datei erst später bearbeitet werden (z.B. bei Terminüberweisungen), ist hier die Anzahl der Tage anzugeben, die zwischen der Erstellung der Datei und ihrer Bearbeitung liegen sollen (d.h. 1=morgen, 2=übermorgen usw.)
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok
    401: Es ist noch eine andere Datei von vorher geöffnet. Diese muß erst geschlossen werden (mit CloseFile), bevor eine neue Datei erzeugt werden kann
    402: Der angegebene Typ ist nicht 1 (Gutschriften) oder 2 (Lastschriften)
    403: Die eigenen Kontodaten sind unültig. Datei wurde nicht angelegt
    404: Die Datei konnte vom Betriebssystem nicht angelegt werden
    405: Die Datei wurde angelegt und kann beschrieben werden; allerdings ist beim Schreiben des A-Satzes ein Fehler aufgetreten. Die Datei ist daher vermutlich von der Bank nicht auswertbar
    LBBW: 406: Aus dem Kontobezeichnungsfeld "aName" konnte die Währung nicht herausgelesen werden. Die Datei wurde nicht angelegt.

    Diese Funktion legt eine neue DTAUS-Datei an (eine evtl. bereits vorhandene Datei gleichen Namens wird dabei ungefragt überschrieben). Bei allen Fehlern können Sie mit KtoDtaus.GetLastError weitere Informationen abrufen.

  • function KtoDtaus.WriteFile

    Eingabeparameter
    NameTypInhalt
    aBlzStringBankleitzahl des Zahlungsempfängers/-pflichtigen
    LBBW: Kann leer gelassen werden, dann wird 99935000 eingesetzt; ansonsten kann hier die Bankleitzahl des eigenen Hausbank-Kontos angegeben werden.
    aKtoStringKontonummer des Zahlungsempfängers/-pflichtigen
    LBBW: Kann leer gelassen werden, dann wird das Füllzeichen "1111111111" eingesetzt; ansonsten kann hier die Kontonummer des eigenen Hausbank-Kontos angegeben werden.
    aNameStringKontobezeichnung des Zahlungsempfängers/-pflichtigen (maximal 54stellig; längere Namen werden nach 54 Zeichen abgeschnitten)
    LBBW: Hier sind maximal 27 Zeichen zulässig.
    aVerwendStringVerwendungszweck der Überweisung/Lastschrift (maximal 378stellig; längere Verwendungszwecke werden nach 378 Zeichen abgeschnitten)
    LBBW: Der hier übergebene "Verwendungszweck" wird in Teile zu je 27 Zeichen aufgebrochen. Die ersten 27 Zeichen ergeben den tatsächlichen Verwendungszweck; jede weiteren 27 Zeichen ergeben den 1., 2., 3. usw. Erweiterungsteil. Die Erweiterungsteile sind gemäß der LBBW-Spezifikation für das jeweilige Land zu belegen (Kontonummer, Filiale, Bankleitzahl, Postleitzahl, Bankname o.ä. des Schuldners). Die vorgeschriebenen Erweiterungsteil-Aufteilungen sind durch Auffüllen der einzelnen Teile auf 27 Stellen genau einzuhalten!
    aInternStringGgf. interne Nummer (als String), die die einzelne Buchung innerhalb der Datei kennzeichnet und die z.B. für Rückrufe benötigt wird
    aTSIntegerTextschlüssel (bezeichnet die Zahlungsart):
    Bei Gutschriften:
    51: "Normale" Überweisung
    53: Lohn/Gehalt
    54: Vermögenswirksame Leistung
    56: Bezüge öffentlicher Kassen
    Bei Lastschriften:
    4: Abbuchungsauftrags-Lastschrift
    5: Einzugsermächtigungs-Lastschrift
    aTSEIntegerTextschlüsselergänzung (gibt zusätzliche Informationen zur Zahlungsart an); wird von KONTOPRUEF unverändert und ohne weitere Prüfung in die Datei geschrieben. I.d.R. ist hier 0 anzugeben; bei TS=54 geben Sie hier bitte die Endziffer des Jahres an, für das die VL gezahlt wird (also 4 für 2004). Evtl. andere zu benutzende Werte für dieses Feld erfahren Sie bei Ihrer Bank
    aBetragWindows: CurrencyBetrag in EUR mit Cent-Nachkommastellen
    Falls Sie die DLL-Version von KONTOPRUEF-OFFLINE verwenden und Ihre Visual-Studio-Version keinen Currency-Datentyp mehr unterstützt, müssen Sie diesen Parameter als Long definieren und mit Decimal.ToOACurrency(...) konvertiert übergeben.
    Linux: unsigned longBetrag in Cent (Ganzzahl ohne Nachkommastellen)
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok
    411: Es ist keine Datei geöffnet. Die Datei muß erst mit CreateFile erzeugt werden
    412: Der angegebene Textschlüssel paßt nicht zum Auftragstyp
    413: Die angegebene Bankverbindung ist ungültig. Datensatz wurde nicht geschrieben
    414: Datensatz konnte vom Betriebssystem nicht geschrieben werden. Die Datei ist daher vermutlich von der Bank nicht auswertbar

    Diese Funktion schreibt einen Datzensatz in die (zuvor mit CreateFile erzeugte) DTAUS-Datei. Bei allen Fehlern können Sie mit KtoDtaus.GetLastError weitere Informationen abrufen.

  • function KtoDtaus.CloseFile

    Eingabeparameter
    NameTypInhalt
    ---
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok
    421: Es ist keine Datei geöffnet. Die Datei muß erst mit CreateFile erzeugt werden
    422: Die Datei wurde geschlossen, allerdings ist beim Schreiben des E-Satzes ein Fehler aufgetreten. Die Datei ist daher vermutlich von der Bank nicht auswertbar

    Diese Funktion schließt die Datei. Bei allen Fehlern können Sie mit KtoDtaus.GetLastError weitere Informationen abrufen.

  • function KtoDtaus.CheckFile

    Eingabeparameter
    NameTypInhalt
    aFileNameStringDTAUS-Datei, deren Bankverbindungen geprüft werden sollen
    Ab Datendatei 0442 kann man diese Funktion zusätzlich verwenden, um Informationen über die gerade mit KtoDtaus.CreateFile, KtoDtaus.WriteFile und KtoDtaus.CloseFile erzeugte Datei zu erhalten (z.B. um daraus einen sog. "Diskettenbegleitzettel" zu erzeugen). Dazu wird als Dateiname einer der folgenden speziellen - normalerweise unmöglichen - Dateinamen übergeben:
    *A liefert beim nächsten Aufruf von KtoDtaus.GetLastError die Anzahl der geschriebenen Datensätze in der DTAUS-Datei
    *B liefert beim nächsten Aufruf von KtoDtaus.GetLastError die Summe der Beträge in der DTAUS-Datei
    *C liefert beim nächsten Aufruf von KtoDtaus.GetLastError die Summe der Kontonummern in der DTAUS-Datei
    *D liefert beim nächsten Aufruf von KtoDtaus.GetLastError die Summe der Bankleitzahlen in der DTAUS-Datei
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger-431: Die angegebene Spezialfunktion (nach "*" im Dateinamen) existiert nicht
    -3: Datei konnte nicht geöffnet werden
    0: Es befinden sich keine fehlerhaften Bankverbindungen in der Datei
    1..N: Es befinden sich so viele fehlerhafte Bankverbindungen in der Datei

    Diese Funktion prüft die Bankverbindungen in einer vorhandenen DTAUS-Datei. Werden Fehler festgestellt, wird im Verzeichnis der geprüften Datei eine gleichnamige Datei, nur mit dem Typ .out, angelegt, in die die fehlerhaften Datensätze im Klartext geschrieben werden. Beim Ergebnis "-3" können Sie mit KtoDtaus.GetLastError die Fehlermeldung des Betriebssystems abrufen. Mit einem Pseudo-Dateinamen, der mit "*" beginnt, können Informationen über eine soeben geschriebene DTAUS-Datei abgerufen werden (ab Datendatei Version 0442).

Nach oben

KtoSepa

Mit dem KtoSepa-Objekt lassen sich (ab Version 3.0 von KONTOPRUEF-OFFLINE) XML-Dateien für SEPA-Überweisungen und -Lastschriften schreiben. Bei Lastschriften wird auch die Verwaltung der einmaligen/erstmaligen/wiederholten/abschließenden Lastschriften von KONTOPRUEF-OFFLINE übernommen (s.u. und in den allgemeinen SEPA-Informationen).

Bitte beachten Sie: Die Updatefähigkeit (also das Aktivieren einer neuen Datendatei) ist (z.B. im Unterschied zum DTAUS-Schreiben) derzeit nur gegeben, solange gerade keine SEPA-XML-Datei erzeugt wird, d.h. Sie sollten KtoUpdate.Activate nur aufrufen, wenn Sie sich in Ihrem Programmlauf nicht gerade zwischen KtoSepa.OpenCredit und KtoSepa.CloseCredit (bzw. KtoSepa.OpenDebit und KtoSepa.CloseDebit) befinden! Sollten Sie dennoch in diesem Zustand ein Update durchführen und eine neue Datendatei aktivieren, wird derzeit das Erzeugen der SEPA-XML-Datei abgebrochen. Möglicherweise wird in einer zukünftigen Version die Updatemöglichkeit beim laufenden Schreiben eingebaut werden; verlassen Sie sich also nicht auf das beschriebene gegenwärtige Verhalten! Am besten ist, wenn Sie Updates via KtoUpdate.Activate nur dann durchführen, wenn Sie gerade keine SEPA-XML-Datei erzeugen.

Die Funktionen im einzelnen (thematisch geordnet):

  • Vorbereitende Funktionen (Fristen, Ausführungstage)
  • function KtoSepa.SetSepaVersion

    Eingabeparameter
    NameTypInhalt
    aSepaVersionIntegerHier können Sie die Version der zu erstellenden SEPA-XML-Dateien angeben:
    • 24 — Version 2.4 – wird nicht mehr unterstützt
    • 25 — Version 2.5 – Voreinstellung bis Bankdatendatei 132x (pain.001.002.03 für Gutschriften, pain.008.002.02 für Lastschriften)
    • 26 — Version 2.6 – Voreinstellung ab Bankdatendatei 1330 (pain.001.002.03 für Gutschriften, pain.008.002.02 für Lastschriften)
    • 27 — Version 2.7 – Voreinstellung ab Bankdatendatei 1421 (pain.001.003.03 für Gutschriften, pain.008.003.02 für Lastschriften; zulässig seit 4.11.2013, nötig für IBAN-only Aufträge ab 1.2.2014 und COR1-Lastschriften ab 4.11.2013)
    • 28 — Version 2.8 – und 29 — Version 2.9 – bringen keine Änderungen mit sich; hier werden weiterhin pain.001.003.03 und pain.008.003.02 verwendet
    • 30 — Version 3.0 (seit November 2016 bei den Banken in Betrieb) – ist seit Bankdatenversion 1720 (Juni 2017) Voreinstellung und verwendet pain.001.001.03 und pain.008.001.02. Ab dieser Version sind keine COR1-Lastschriften mehr möglich, da die Einlieferungsfristen für Basislastschriften ohnehin entsprechend verkürzt wurden. Falls Sie weiterhin COR1-Lastschriften an KONTOPRUEF übergeben, werden diese intern automatisch in CORE-Lastschriften umgesetzt. Beachten Sie jedoch, dass Sie bei einer EBICS-Übermittlung daher den Auftragstyp CDD (statt CD1) verwenden müssen!
    • 31 — Version 3.1 (seit November 2017 bei den Banken in Betrieb) – ist vollkompatibel zu Version 30 (ebenfalls pain.001.001.03 und pain.008.001.02).
    • 32 — Version 3.2 (seit November 2018 bei den Banken in Betrieb) – ist vollkompatibel zu Version 31 (ebenfalls pain.001.001.03 und pain.008.001.02).
    • 33 — Version 3.3 (seit November 2019 bei den Banken in Betrieb) – ist vollkompatibel zu Version 32 (ebenfalls pain.001.001.03 und pain.008.001.02); hier wurde die Echtzeitüberweisung eingeführt; KONTOPRUEF-OFFLINE unterstützt die Echtzeitüberweisung ab Bankdatenversion 2240; siehe Parameter aPmtInfId bei KtoSepa.OpenCredit; die Angabe einer Uhrzeit (mit pain.001.001.08) wird von KONTOPRUEF-OFFLINE nicht unterstützt!
    • 34 — Version 3.4 (seit November 2020 bei den Banken in Betrieb) – ist vollkompatibel zu Version 33 (ebenfalls pain.001.001.03 und pain.008.001.02).
    • 35 — Version 3.5 (seit November 2021 bei den Banken in Betrieb) – ist vollkompatibel zu Version 34 (ebenfalls pain.001.001.03 und pain.008.001.02); die Regeln zu Echtzeitüberweisungen wurden überarbeitet (Echtzeitüberweisungen werdne von KONTOPRUEF-OFFLINE weiterhin noch nicht unterstützt).
    • 36 — Version 3.6 (seit November 2022 bei den Banken in Betrieb) – ist vollkompatibel zu Version 35 (ebenfalls pain.001.001.03/08/09 und pain.008.001.02).
    In Version 3.7 (ab November 2023) ändert sich voraussichtlich die Definition der "pain"-Formate in 001.001.09 bzw. 008.001.08. Die „alten“ Formate können aber stets noch ein paar Jahre nach Einführung der neuen Formate verwendet werden. Ihre Bank informiert Sie darüber, wenn alte Formate abgeschaltet werden. Bereits jetzt können Sie mit dem SepaCommand.SetPain die Header der XML-Datei entsprechend konfigurieren; sollten darüber hinaus inhaltliche Anpassungen erforderlich werden, wird KONTOPRUEF-OFFLINE natürlich rechtzeitig die neuen Formate unterstützen.
    Wird diese Konstante negativ übergeben (also z.B. als -27), werden Lastschriftdateien in der Version "B2B" statt "CORE" erzeugt. Ab Bankdaten Version 1330 ist diese Zusatzfunktion veraltet und sollte durch KtoSepa.SepaCommand("SETDDTYPE") ersetzt werden.
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisIntegerDie aktuell eingestellte SEPA-Version (immer als positiver Wert ohne Dezimalpunkt, also z.B. 25, 26 oder 27)

    Diese Funktion legt das Format der resultierenden XML-Dateien gemäß der Datenformatspezifikation der Deutschen Kreditwirtschaft fest. Bis ins Jahr 2013 war Version 2.6 "gängig"; Version 2.7 wurde "offziell" seit dem 4.11.2013 gültig, wobei die Banken empfehlungsgemäß das alte 2.5/2.6-Format noch für ein weiteres Jahr unterstützen sollen. Die Standardeinstellung in KONTOPRUEF-OFFLINE hängt von der jeweiligen Bankdatendatei ab und ist in der obigen Tabelle angegeben.

    Der Aufruf dieser Funktion wird ignoriert, wenn gerade eine Datei zum Schreiben geöffnet ist (d.h. wenn Sie sich gerade zwischen Open... und Close... befinden). Rufen Sie diese Funktion daher nur dann auf, wenn gerade keine Datei geöffnet ist!

  • procedure KtoSepa.SetBankDays

    Eingabeparameter
    NameTypInhalt
    aCreditBankOffsetIntegerDie Anzahl der Bankarbeitstage (vom augenblicklichen Zeitpunkt an gerechnet), nach denen die nächste Überweisungsdatei ausgeführt werden soll (d.h. 0=heute, falls die Einlieferungsschlusszeit noch nicht erreicht ist)
    aShortBankOffsetIntegerDie Anzahl der Bankarbeitstage (vom augenblicklichen Zeitpunkt an gerechnet), nach denen die wiederholten ("RCUR") und abschließenden ("FNAL") Lastschriften der nächsten Lastschriftdatei ausgeführt werden sollen (bei CORE-Lastschriften mindestens 2 Bankarbeitstage – Ihre Bank kann eine längere Frist vorschreiben, viele Banken z.B. 3 Bankarbeitstage –, bei B2B- und COR1-Lastschriften mindestens 1 Bankarbeitstag)
    aLongBankOffsetIntegerDie Anzahl der Bankarbeitstage (vom augenblicklichen Zeitpunkt an gerechnet), nach denen die erstmaligen ("FRST") und einmaligen ("OOFF") Lastschriften der nächsten Lastschriftdatei ausgeführt werden sollen (bei CORE-Lastschriften mindestens 5 Bankarbeitstage – Ihre Bank kann eine längere Frist vorschreiben, viele Banken z.B. 6 Bankarbeitstage –, bei B2B- und COR1-Lastschriften mindestens 1 Bankarbeitstag)
    Ausgabeparameter
    NameTypInhalt
    ---

    Diese Funktion legt die Ausführungstage der folgenden SEPA-Buchungen fest. Sie müssen sie nicht unbedingt aufrufen; die Voreinstellung ist (0, 2, 5) – das sind die europäischen Mindesteinlieferungsfristen. Viele Banken fordern jedoch längere Fristen wie z.B. (0, 3, 6). Bitte informieren Sie sich bei Ihrer Bank über die einzuhaltenden Fristen.

    Sie können diese Funktion auch zwischen einzelnen Buchungen, z.B. mit KtoSepa.WriteDebit aufrufen, um die Ausführungstage einzelner Buchungen zu verändern; besser ist allerdings, wenn Sie vor jeder Buchung (falls nötig) ein direktes Datum mit KtoSepa.SepaCommand("CALCDUEDATE") übergeben, da Sie dann nach KtoSepa.CloseCredit bzw. KtoSepa.CloseDebit anhand der hier eingestellten Werte den spätestmöglichen Einlieferungstermin via KtoSepa.GetActualDueDate erhalten.

  • procedure KtoSepa.SetBankHour

    Eingabeparameter
    NameTypInhalt
    aBankHourIntegerDie Einlieferungsschlusszeit Ihrer Bank (z.B. 12 für 12 Uhr). Später eingegangene Aufträge gelten als am nächsten Bankarbeitstag eingeliefert.
    Ausgabeparameter
    NameTypInhalt
    ---

    Diese Funktion legt die Einlieferungsschlusszeit Ihrer Bank fest (bitte erfragen Sie die für Sie geltende Uhrzeit dort). Falls die aktuelle Uhrzeit bereits nach der hier angegebenen Zeit liegt (also wenn Sie z.B. KtoSepa.SetBankHour(12) eingestellt haben – was auch die Voreinstellung ist –, und es ist bereits 14 Uhr), wird der Ausführungstag, den Sie mit KtoSepa.SetBankDays festgelegt haben, nochmals um einen Bankarbeitstag nach hinten verlegt.

    Bitte beachten Sie, dass KONTOPRUEF-OFFLINE natürlich nicht weiß wann Sie die Datei real einliefern werden. Es kann also z.B. (bei der Einstellung 12 Uhr) passieren, dass Sie die Datei um 11 Uhr erzeugen und um 14 Uhr einliefern – dann sind u.U. die Fristen zu kurz, wenn Sie bei KtoSepa.SetBankDays die Minimalwerte angegeben haben!

  • function KtoSepa.GetShortDueDate

    Eingabeparameter
    NameTypInhalt
    ---
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringDas Ausführungsdatum für wiederholte ("RCUR") und abschließende ("FNAL") Lastschriften (im Format JJJJ-MM-TT)

    Mit dieser Funktion erhalten Sie (ggf. nach dem Aufruf von KtoSepa.SetBankDays und/oder KtoSepa.SetBankHour) das reale Ausführungsdatum der wiederholten ("RCUR") und abschließenden ("FNAL") Lastschriften im Format JJJJ-MM-TT (also z.B. "2011-04-15" für den 15. April 2011).

  • function KtoSepa.GetLongDueDate

    Eingabeparameter
    NameTypInhalt
    ---
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringDas Ausführungsdatum für erstmalige ("FRST") und einmalige ("OOFF") Lastschriften (im Format JJJJ-MM-TT)

    Mit dieser Funktion erhalten Sie (ggf. nach dem Aufruf von KtoSepa.SetBankDays und/oder KtoSepa.SetBankHour) das reale Ausführungsdatum der erstmaligen ("FRST") und einmaligen ("OOFF") Lastschriften im Format JJJJ-MM-TT (also z.B. "2011-04-15" für den 15. April 2011).

  • function KtoSepa.GetActualDueDate

    Eingabeparameter
    NameTypInhalt
    ---
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringDas Ausführungsdatum für Gutschriften bzw. für die aktuelle Lastschrift im Format JJJJ-MM-TT (siehe erläuternder Text unten)

    Diese Funktion hat einen mehrfachen Nutzen:

    • Nach dem Aufruf von KtoSepa.SetBankDays und/oder KtoSepa.SetBankHour erhalten Sie das reale Ausführungsdatum einer folgenden Überweisungsdatei
    • Nach dem Aufruf von KtoSepa.WriteCredit bzw. KtoSepa.WriteDebit erhalten Sie das reale Ausführungsdatum der soeben erzeugten Buchung (das bei Lastschriften u.U. vom ggf. automatisch ermittelten Sequenztyp – also einmalig / erstmalig / wiederholt / abschließend – abhängt)
    • Nach dem Aufruf von KtoSepa.SepaCommand("CALCDUEDATE") erhalten Sie das ausgerechnete Datum, wie in den Funktionsparametern angegeben
    • Nach dem Aufruf von KtoSepa.CloseCredit bzw. KtoSepa.CloseDebit bzw. erhalten Sie hier ab Bankdatenversion 1330 den spätestmöglichen Einlieferungstag für die soeben geschriebene XML-Datei (vorausgesetzt, Sie halten die Einlieferungs-Uhrzeit ein, die hier nicht geprüft wird).

    Das zurückgegebene Format ist stets JJJJ-MM-TT (also z.B. 2011-04-15 für den 15. April 2011).

  • Funktionen für Überweisungen
  • Hinweise zu Echtzeitüberweisungen:

    • KONTOPRUEF-OFFLINE unterstützt die Formate für Echtzeitüberweisungen ab Bankdatenversion 2240 (gültig ab dem 5. Dezember 2022).
    • Die Angabe einer Ausführungsuhrzeit (zusätzlich zum Ausführungsdatum) ist mit KONTOPRUEF-OFFLINE derzeit noch nicht möglich.
    • Eine Echtzeitüberweisungs-SEPA-XML-Datei erzeugen Sie mit KONTOPRUEF-OFFLINE, indem Sie bei der Funktion KtoSepa.OpenCredit am Anfang des Parameters aPmtInfId einen Stern * übergeben (also z.B. „*Sammler“).
    • Wenn Sie eine SEPA-Datei mit Echtzeitüberweisungen via EBICS einliefern, müssen Sie dabei den Auftragstyp CIP (statt CCT) verwenden. Möglicherweise müssen Sie sich bei Ihrer Bank erst noch für diesen Auftragstyp freischalten lassen.
    • Zur Übermittlung von Echtzeitüberweisungen via HBCI/FinTS kann ich keine Aussage treffen. Bitte wenden Sie sich bei diesbezüglichen Fragen an den Hersteller Ihrer Banking-Software.
    • Weitere Einstellungen sind aktuell nicht nötig – insbesondere keine manuellen Äderungen des „pain“-Typs auf 001.001.08 oder 001.001.09 mit KtoSepa.SepaCommand("SETPAIN"). Dieses neuen Subtypen werden derzeit nur benötigt, um eine (optionale) Uhrzeit für die Echtzeitüberweisungen zu übermitteln, was mit KONTOPRUEF-OFFLINE aktuell sowieso nicht möglich ist.
  • function KtoSepa.OpenCredit

    Eingabeparameter
    NameTypInhalt
    aMsgIdStringEine wahlfreie Bezeichnung Ihrer Überweisungsdatei (bis zu 35 Zeichen), die in Ihrem Kontoauszug erscheint – darf nicht weggelassen werden
    aPmtInfIdStringEine weitere wahlfreie Bezeichnung Ihrer Überweisungsdatei (bis zu 35 Zeichen), die normalerweise ebenfalls in Ihrem Kontoauszug erscheint (quasi ein "Untertitel") – darf auch nicht weggelassen werden
    Ab Bankdatenversion 2240: Wenn das erste Zeichen dieses Parameters ein Stern * ist, wird die Überweisung als Echtzeitüberweisung ausgeführt. Beachten Sie bei der Einlieferung via EBICS, dass Sie in diesem Fall den Auftragstyp CIP statt CCT verwenden müssen!
    aInitgPtyStringDer Name des Einreichers der Überweisungen (bis zu 70 Zeichen; das muss nicht der Kontoinhaber bzw. Auftraggeber sein, sondern kann z.B. den Namen eines beauftragen Service-Dienstleisters enthalten); darf ebenfalls nicht weggelassen werden. Beachten Sie hierzu bitte auch den Abschnitt Hinweis zur Identifikation von Absender/Empfänger.
    aCtgyPurpStringDie Kategorie des gesamten Sammelauftrags, z.B. "SALA" für Gehaltsüberweisungen. Die Liste der hier zugelassenen Codes finden Sie in Tabelle "4-CategoryPurpose" des "External Code Lists spreadsheet" auf der ISO20022-Website. Die hier gemachte Angabe wird jedoch nicht im Kontoauszug ausgedruckt und ist darüberhinaus wahlfrei; d.h. falls von Ihrer Seite nicht irgendwelche speziellen Gründe für die Angabe eines solchen "Category Purpose" sprechen, empfehlen wir, für diesen Parameter einen Leerstring zu übergeben.
    aAuftraggeberStringDer Absender (Kontoinhaber) der Überweisungen (bis zu 70 Zeichen). Beachten Sie hierzu bitte auch den Abschnitt Hinweis zur Identifikation von Absender/Empfänger.
    aIbanStringDie IBAN (Kontonummer) des Auftraggebers (also das Konto, das mit den Überweisungen belastet wird)
    aBicStringDer BIC (Bank Identifier Code) des Auftraggebers (also die absendende Bank); kann ab 1.2.2014 weggelassen werden, wenn KONTOPRUEF-OFFLINE mit SEPA-Version 2.7 oder neuer betrieben wird.
    Ab Bankdatenversion 1330 wird der BIC auf Existenz im SCL-Directory der Bundesbank geprüft und bei Nichtvorhandensein diese Funktion mit einer Fehlermeldung beendet. Falls Sie BICs verwenden wollen, die nicht im SCL-Directory enthalten sind (wobei es höchst fraglich ist, ob diese dann überhaupt SEPA-fähig sind), müssen Sie an den BIC ein Ausrufezeichen anhängen, um die Prüfung zu übersteuern, also z.B. BANKDEFF123!
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, Überweisungen können mit KtoSepa.WriteCredit geschrieben werden
    4: Es ist bereits eine Datei geöffnet. Wenn Sie zwei Dateien gleichzeitig beschreiben wollen (nicht jedoch Lastschriften), erzeugen Sie bitte ein weiteres KtoSepa-Objekt.
    160: Ungültige Parameter (wenn z.B. aMsgId oder aPmtInf nicht ausgefüllt wurden – außer aCtgyPurp müssen alle Parameter belegt werden!)

    Diese Funktion startet eine Überweisungsdatei und legt u.a. die Auftraggeberdaten fest. Nach erfolgreicher Rückkehr können mit KtoSepa.WriteCredit die einzelnen Überweisungen in die Datei geschrieben werden.

  • function KtoSepa.WriteCredit

    Eingabeparameter
    NameTypInhalt
    aBetragWindows: CurrencyBetrag in EUR mit Cent-Nachkommastellen
    Falls Sie die DLL-Version von KONTOPRUEF-OFFLINE verwenden und Ihre Visual-Studio-Version keinen Currency-Datentyp mehr unterstützt, müssen Sie diesen Parameter als Long definieren und mit Decimal.ToOACurrency(...) konvertiert übergeben.
    Linux: unsigned longBetrag in Cent (Ganzzahl ohne Nachkommastellen)
    aNameStringDer Name des Empfängers der Überweisung (bis zu 70 Zeichen). Beachten Sie hierzu bitte auch den Abschnitt Hinweis zur Identifikation von Absender/Empfänger.
    aIbanStringDie IBAN (Kontonummer) des Empfängers der Überweisung
    aBicStringDer BIC (Bank Identifier Code) des Empfängers der Überweisung; kann ab 1.2.2014 für deutsche und ab 1.2.2016 auch für ausländische Empfänger weggelassen werden, wenn KONTOPRUEF-OFFLINE mit SEPA-Version 2.7 oder neuer betrieben wird.
    Ab Bankdatenversion 1330 wird der BIC auf Existenz im SCL-Directory der Bundesbank geprüft und bei Nichtvorhandensein diese Funktion mit einer Fehlermeldung beendet. Falls Sie BICs verwenden wollen, die nicht im SCL-Directory enthalten sind (wobei es höchst fraglich ist, ob diese dann überhaupt SEPA-fähig sind), müssen Sie an den BIC ein Ausrufezeichen anhängen, um die Prüfung zu übersteuern, also z.B. BANKDEFF123!
    aPurpStringDie Art dieser einzelnen Überweisung. Sie können dieses Feld für normale Zahlungen einfach leer lassen; es werden auch nicht alle Codes im Kontoauszug (des Empfängers) ausgewiesen. Gängige (und evtl. notwendige) Codes sind lediglich BONU / PENS / SALA für Gehaltsüberweisungen (entspricht Textschlüssel 53 der nationalen Überweisungen), BENE / GOVT / SSBE für Zahlungen öffentlicher Kassen (entspricht Textschlüssel 56 der nationalen Überweisungen), CHAR für Spenden (entspricht Textschlüssel 69 der nationalen Überweisungen) sowie CBFF für vermögenswirksame Leistungen (entspricht Textschlüssel 54 der nationalen Überweisungen). Die vollständige Liste der hier zugelassenen Codes finden Sie in Tabelle "11-Purpose" des "External Code Lists spreadsheet" auf der ISO20022-Website.
    aRefStringEine eindeutige Referenz dieser Überweisung (bis zu 35 Zeichen), z.B. eine Rechnungsnummer
    aVerwendStringDer Verwendungszweck dieser Überweisung (beliebiger freier Text bis zu 140 Zeichen)
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, Überweisung wurde geschrieben
    29: Schreibfehler (wenn z.B. KtoSepa.OpenCredit nicht vorher aufgerufen wurde)
    117: Sie haben KtoSepa.WriteCredit zum Schreiben einer Überweisung aufgerufen, aber vorher mit KtoSepa.OpenDebit eine Lastschriftdatei begonnen
    160: Ungültige Parameter (wenn z.B. aIban oder aBic nicht ausgefüllt wurden)

    Diese Funktion schreibt eine einzelne Überweisung in eine zuvor mit KtoSepa.OpenCredit gestartete Überweisungsdatei.

  • function KtoSepa.CloseCredit

    Eingabeparameter
    NameTypInhalt
    aFileNameStringZiel-Dateiname für die XML-Überweisungsdatei (bitte vollen Pfad angeben; nicht einfach nur Dateiname bzw. relativer Pfad; also z.B. C:\Temp\Test.xml oder /var/tmp/test.xml)
    Ab Bankdatenversion 1520 kann ein Platzhalter für eine laufende Nummer angegeben werden, um separate XML-Dateien pro Ausführungstag zu erzeugen (nötig für HBCI/FinTS). Bitte lesen Sie dazu die genaue Beschreibung auf der HBCI-Seite.
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, XML-Überweisungsdatei wurde geschrieben
    29: Schreibfehler (wenn z.B. KtoSepa.OpenCredit nicht vorher aufgerufen wurde und/oder ein ungültiger Dateiname übergeben wurde)
    117: Sie erzeugen gerade eine Lastschriftdatei; bitte verwenden Sie KtoSepa.CloseDebit!

    Diese Funktion schließt die zuvor mit KtoSepa.OpenCredit gestartete Überweisungsdatei und schreibt sie an die durch aFileName angegebene Stelle. Ab Bankdatenversion 1330 können Sie unmittelbar nach dieser Funktion noch KtoSepa.GetActualDueDate aufrufen, um den spätestmöglichen Einlieferungstag für die soeben geschriebene XML-Datei zu erfahren, wenn Sie vorab KtoSepa.SetBankDays richtig gesetzt hatten (vorausgesetzt, Sie halten die Einlieferungs-Uhrzeit ein, die hier nicht geprüft wird).

    Achtung: Sollte diese Funktion (z.B. mit Result=29) fehlschlagen, ist die Überweisungsdatei verloren, und eine erneute Erzeugung muss wieder von vorne mit KtoSepa.OpenCredit beginnen!

  • Funktionen für Lastschriften
  • Generelles zur SEPA-Lastschrifteinreichung (lesen Sie bitte auch die allgemeinen SEPA-Informationen):
    • Sie müssen bei Lastschriften angeben, ob es sich um eine einmalige Lastschrift ("OOFF") handelt (z.B. bei einem Kauf einer Ware durch einen Kunden) oder ob die Lastschrift regelmäßig stattfindet (z.B. bei einem Abonnement mit monatlichen Abbuchungen).
    • Bei regelmäßigen Lastschriften müssen Sie noch angeben, ob es sich um die erste ("FRST"), eine wiederholte (also "mittlere", "RCUR") oder die letztmalige ("FNAL") Lastschrift handelt.
    • Sie können diese Angaben ("Sequenz-Typ", abgekürzt "SeqTp") selbst verwalten oder KONTOPRUEF-OFFLINE überlassen; im letzteren Fall verwaltet KONTOPRUEF-OFFLINE eine "Mini-Datenbank" (eine kleine Datei irgendwo auf Ihrer Festplatte), in der für jeden Kunden und Mandanten die jeweils letzte Lastschrift gespeichert wird, so dass der richtige Typ automatisch herausgefunden werden kann.
    • Ferner müssen Sie bei Mandatsänderungen (Änderung der Mandatsreferenz, Ihres Firmennamens oder Ihrer Gläubiger-ID bzw. Änderung der Bankverbindung Ihres Kunden) die jeweils bisherigen Daten im Datensatz mitschicken. Auch dies erledigt KONTOPRUEF-OFFLINE selbst, wenn Sie die oben erwähnte "Automatik" mit der Mini-Datenbank verwenden; eine manuelle Übergabe dieser "Amendment Information Details" an KONTOPRUEF-OFFLINE ist derzeit ohnehin nicht vorgesehen.
    • Die erwähnte Mini-Datenbank arbeitet zweistufig: Während der Erzeugung der XML-Datei werden die Lastschriften zunächst in eine temporäre Datenbank geschrieben (für Mandant 1 z.B. in die Datei temp1.db) und erst durch Aufruf von KtoSepa.MergeTemp in die "Hauptdatenbank" (mand1.db für Mandant 1) übernommen. Dies hat den Vorteil, dass Sie sich nach der Erzeugung der XML-Datei diese erst einmal anschauen und bei irgendwelchen Fehlern neu erzeugen können. Oder einfach wegwerfen (und die zugehörige temporäre Datenbank mit KtoSepa.DeleteTemp löschen). Nur wenn Sie die XML-Datei tatsächlich bei Ihrer Bank einliefern, sollten Sie KtoSepa.MergeTemp aufrufen, um die "Hauptdatenbank" zu aktualisieren.
    • Die Funktionalität ist dabei wie folgt:
      • Wird eine Einmallastschrift ("OOFF") erzeugt oder Mandant=0 bei KtoSepa.OpenDebit oder Kunde=0 bei KtoSepa.WriteDebit übergeben, passiert nichts (es wird also weder ein SeqTp automatisch ermittelt noch diese Lastschrift für spätere Ermittlungen gespeichert).
      • Alle anderen SeqTp (also die "wiederholenden" Typen FRST/RCUR/FNAL) werden durch KtoSepa.WriteDebit in die temporäre Datenbank geschrieben.
      • Beim Aufruf von KtoSepa.MergeTemp werden in der "Hauptdatenbank" alle "FRST"- und "RCUR"-Datensätze aus der temporären Datenbank anhand der Kundennummer aktualisiert (bzw. hinzugefügt) sowie alle "FNAL"-Datensätze aus der temporären Datenbank in der Hauptdatenbank gelöscht.
    • Rufen Sie vor KtoSepa.OpenDebit ggf. KtoSepa.SetSepaVersion und KtoSepa.SepaCommand("SETDDTYPE") auf – in dieser Reihenfolge.
  • function KtoSepa.SetDbDirectory

    Eingabeparameter
    NameTypInhalt
    aDbDirectoryStringMit diesem Parameter können Sie das Verzeichnis angeben, in dem die mand... und temp... Mini-Datenbanken gespeichert werden. Wenn Sie einen leeren String übergeben, wird das Standardverzeichnis ausgewählt (unter Windows XP z.B. C:\Dokumente und Einstellungen\All Users\Anwendungsdaten\Hanft\KontoPruef\SEPA, unter Linux /var/db/hanft/kontopruef/sepa).
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, Verzeichnis existiert (und wurde ggf. angelegt)
    82: Verzeichnis existiert nicht und konnte auch nicht angelegt werden

    Diese Funktion legt das Verzeichnis fest, in dem die Mini-Datenbanken mit den zuletzt ausgeführten Lastschriften gespeichert werden. Die "endgültige" Datenbank heißt mand...db (wobei für "..." die jeweilige Mandantennummer eingesetzt wird), die temporäre Datenbank temp...db.

    Achtung: Diese Funktion wird mit leerem Parameter auch unmittelbar nach dem Anlegen des KtoSepa-Objekts aufgerufen. Sie können also mit KtoSepa.GetLastError sofort nach dem Anlegen des Objekts prüfen, ob das Standardverzeichnis zur Verfügung steht. (Falls Sie mit dieser Funktion ohnehin ein anderes Verzeichnis auswählen, können Sie diese Angabe natürlich ignorieren.)

    Das Datenbankverzeichnis muss natürlich für den Prozess bzw. Benutzer, unter dem Ihre Anwendungssoftware läft, zum Lesen und Schreiben freigegeben sein!

  • function KtoSepa.GetDbDirectory

    Eingabeparameter
    NameTypInhalt
    ---
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringDas aktuell eingestellte Datenbank-Verzeichnis

    Mit dieser Funktion erhalten Sie das Verzeichnis, in dem die Mini-Datenbanken mit den zuletzt ausgeführten Lastschriften gespeichert werden. Die "endgültige" Datenbank heißt mand...db (wobei für "..." die jeweilige Mandantennummer eingesetzt wird), die temporäre Datenbank temp...db.

  • function KtoSepa.TestDbDirectory

    Eingabeparameter
    NameTypInhalt
    ---
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: OK, Verzeichnis existiert und kann beschrieben und gelesen werden
    5: Die Testdatei kann nicht wieder gelöscht werden
    13: Die gelesenen Daten unterscheiden sich von den geschriebenen Daten
    25: Die Dateipositionierung in der Testdatei funktioniert nicht
    29: In die Testdatei kann nicht geschrieben werden
    30: Aus der Testdatei kann nicht gelesen werden
    82: Das Verzeichnis oder die Testdatei kann nicht angelegt werden

    Mit dieser Funktion prüfen Sie, ob das mit KtoSepa.SetDbDirectory eingestellte Verzeichnis existiert (bzw. angelegt werden kann) und ob darin Dateien für die Mini-Datenbank angelegt, beschrieben, gelesen und gelöscht werden können. Wir empfehlen, vor der Verwendung der Debit-Funktionen mit dieser Funktion die korrekte Einstellung des Mini-Datenbank-Verzeichnisses zu prüfen. Dabei wird immer nur der erste gefundene Fehler zurückgeliefert; Sie müssen also diese Funktion so lange aufrufen (und unterdessen jeden zurückgemeldeten Fehler korrigieren), bis Sie das Ergebnis 0 (OK) erhalten!

  • function KtoSepa.OpenDebit

    Eingabeparameter
    NameTypInhalt
    aMandantIntegerEine Mandantennummer zwischen 1 und 2147483647. Sie können auch 0 übergeben, dann wird die Funktionalität der Mini-Datenbank zur automatischen Ermittlung des SeqTp abgeschaltet (und Sie müssen bei KtoSepa.WriteDebit immer Kundennummer 0 übergeben)
    aMsgIdStringEine wahlfreie Bezeichnung Ihrer Lastschriftdatei (bis zu 35 Zeichen), die in Ihrem Kontoauszug erscheint – darf nicht weggelassen werden
    aInitgPtyStringDer Name des Einreichers der Lastschriften (bis zu 70 Zeichen; das muss nicht der Kontoinhaber bzw. Auftraggeber sein, sondern kann z.B. den Namen eines beauftragen Service-Dienstleisters enthalten); darf ebenfalls nicht weggelassen werden. Beachten Sie hierzu bitte auch den Abschnitt Hinweis zur Identifikation von Absender/Empfänger.
    aCtgyPurpStringDie Kategorie des gesamten Sammelauftrags, z.B. "CASH" für allgemeine Zahlungen. Die Liste der hier zugelassenen Codes finden Sie in Tabelle "4-CategoryPurpose" des "External Code Lists spreadsheet" auf der ISO20022-Website. Die hier gemachte Angabe wird jedoch nicht im Kontoauszug ausgedruckt und ist darüberhinaus wahlfrei; d.h. falls von Ihrer Seite nicht irgendwelche speziellen Gründe für die Angabe eines solchen "Category Purpose" sprechen, empfehlen wir, für diesen Parameter einen Leerstring zu übergeben.
    aAuftraggeberStringDer Auftraggeber der Lastschriften (also der Zahlungsempfänger, bis zu 70 Zeichen). Beachten Sie hierzu bitte auch den Abschnitt Hinweis zur Identifikation von Absender/Empfänger.
    aIbanStringDie IBAN (Kontonummer) des Auftraggebers (also das Konto, dem die Lastschriften gutgeschrieben werden)
    aBicStringDer BIC (Bank Identifier Code) des Auftraggebers (also die Bank des Zahlungsempfängers); kann ab 1.2.2014 weggelassen werden, wenn KONTOPRUEF-OFFLINE mit SEPA-Version 2.7 oder neuer betrieben wird.
    Ab Bankdatenversion 1330 wird der BIC auf Existenz im SCL-Directory der Bundesbank geprüft und bei Nichtvorhandensein diese Funktion mit einer Fehlermeldung beendet. Falls Sie BICs verwenden wollen, die nicht im SCL-Directory enthalten sind (wobei es höchst fraglich ist, ob diese dann überhaupt SEPA-fähig sind), müssen Sie an den BIC ein Ausrufezeichen anhängen, um die Prüfung zu übersteuern, also z.B. BANKDEFF123!
    aCreditorIdStringDie Gläubiger-ID des Auftraggebers/Zahlungsempfängers; kann bei der Bundesbank kostenlos beantragt werden. Die Gläubiger-ID enthält eine Prüfziffer. Bei falscher Prüfziffer bzw. falscher Gläubiger-ID erhalten Sie eine Fehlermeldung.
    Ab Bankdatenversion 1540 können Sie auch beliebige (ungerüfte) Texte hier übergeben, wenn Sie ein Ausrufezeichen anhängen, also z.B. Blah-Muh!; es wird dann die Gläubiger-ID Blah-Muh verwendet. (Manche ausländische Banken verlangen hier offenbar die lokale Steuernummer statt der Gläubiger-ID, was zwar gegen die SEPA-Regeln verstößt, aber wenn Sie Ihren Auftrag sonst nicht einliefern können...)
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, Lastschriften können mit KtoSepa.WriteDebit geschrieben werden
    4: Es ist bereits eine Datei geöffnet. Wenn Sie zwei Dateien gleichzeitig beschreiben wollen (nicht jedoch Lastschriften), erzeugen Sie bitte ein weiteres KtoSepa-Objekt.
    110: Die temporäre Mini-Datenbank konnte nicht geöffnet werden.
    160: Ungültige Parameter (wenn z.B. aMsgId oder aCreditorId nicht ausgefüllt wurden – außer aCtgyPurp müssen alle Parameter belegt werden!)

    Diese Funktion startet eine Lastschriftdatei und legt u.a. die Auftraggeberdaten fest. Nach erfolgreicher Rückkehr können mit KtoSepa.WriteDebit die einzelnen Lastschriften in die Datei geschrieben werden.

    Wenn Sie die Automatik zur Ermittlung des SeqTp benutzen, legt diese Funktion eine neue temporäre Datenbank temp...db an; eine evtl. vorhandene alte Datenbank gleichen Namens (=mit der gleichen Mandantennummer) wird dabei ggf. überschrieben.

  • function KtoSepa.WriteDebit

    Eingabeparameter
    NameTypInhalt
    aKundeIntegerEine Kundennummer zwischen 1 und 2147483647. Sie können auch 0 übergeben, dann wird die Funktionalität der Mini-Datenbank zur automatischen Ermittlung und Speicherung des SeqTp abgeschaltet (und Sie dürfen im Parameter aSeqTp nur Werte zwischen 0 und 3 angeben, s.u.). Wurde bei KtoSepa.OpenDebit Mandant 0 übergeben, muss hier zwingend Kunde 0 übergeben werden!
    aSeqTpIntegerDer Sequenz-Typ dieser Lastschrift. Es stehen Ihnen folgende Möglichkeiten zur Verfügung:
    0: OOFF (einmalige Lastschrift)
    1: FRST (wiederholte Lastschrift; dies ist die erste davon)
    2: RCUR (wiederholte Lastschrift; dies ist eine "mittlere"; also weder die erste noch die letzte)
    3: FNAL (wiederholte Lastschrift; dies ist die letzte davon)
    -1: Automatik; anhand Mandanten- und Kundennummer findet KONTOPRUEF-OFFLINE den richtigen Sequenz-Typ automatisch heraus und berücksichtigt im Lastschriftdatensatz auch noch evtl. Änderungen des Mandats (neue Bankverbindung, Gläubiger-ID etc.)
    -2: wie -1, jedoch signalisieren Sie damit, dass es sich jetzt um die letzte Lastschrift handelt (d.h. es wird i.d.R. FNAL eingesetzt)
    Die negativen Werte können Sie nur übergeben, wenn Sie die Funktionalität der Mini-Datenbank nutzen, d.h. Werte größer als 0 für Mandant und Kunde übergeben haben und das Verzeichnis der Mini-Datenbank schreib- und lesbar ist und sich die Mandantendatenbank (mand...db) dort befindet (beim ersten Aufruf für den jeweiligen Mandanten wird sie natürlich automatisch angelegt).
    aBetragWindows: CurrencyBetrag in EUR mit Cent-Nachkommastellen
    Falls Sie die DLL-Version von KONTOPRUEF-OFFLINE verwenden und Ihre Visual-Studio-Version keinen Currency-Datentyp mehr unterstützt, müssen Sie diesen Parameter als Long definieren und mit Decimal.ToOACurrency(...) konvertiert übergeben.
    Linux: unsigned longBetrag in Cent (Ganzzahl ohne Nachkommastellen)
    aNameStringDer Name des Zahlungspflichtigen (bis zu 70 Zeichen). Beachten Sie hierzu bitte auch den Abschnitt Hinweis zur Identifikation von Absender/Empfänger.
    aIbanStringDie IBAN (Kontonummer) des Zahlungspflichtigen
    aBicStringDer BIC (Bank Identifier Code) der Bank des Zahlungspflichtigen; kann ab 1.2.2014 für deutsche und ab 1.2.2016 auch für ausländische Zahlungspflichtige weggelassen werden, wenn KONTOPRUEF-OFFLINE mit SEPA-Version 2.7 oder neuer betrieben wird.
    Ab Bankdatenversion 1330 wird der BIC auf Existenz im SCL-Directory der Bundesbank geprüft und bei Nichtvorhandensein diese Funktion mit einer Fehlermeldung beendet. Falls Sie BICs verwenden wollen, die nicht im SCL-Directory enthalten sind (wobei es höchst fraglich ist, ob diese dann überhaupt SEPA-fähig sind), müssen Sie an den BIC ein Ausrufezeichen anhängen, um die Prüfung zu übersteuern, also z.B. BANKDEFF123!
    aPurpStringDie Art dieser einzelnen Lastschrift. Sie können dieses Feld für normale Zahlungen einfach leer lassen; es werden auch nicht alle Codes im Kontoauszug (des Empfängers) ausgewiesen. Wenn Sie Energieversorger sind, können Sie hier z.B. ELEC angeben, wenn es sich um eine Lastschrift für die Stromrechnung handelt. Das hat aber bislang keinerlei Auswirkungen; wir empfehlen daher, dieses Feld vorerst leer zu lassen, falls keine besondere Gründe dagegen sprechen. Die vollständige Liste der hier zugelassenen Codes finden Sie in Tabelle "11-Purpose" des "External Code Lists spreadsheet" auf der ISO20022-Website.
    aRefStringEine eindeutige Referenz dieser Lastschrift (bis zu 35 Zeichen), z.B. eine Rechnungsnummer
    aVerwendStringDer Verwendungszweck dieser Lastschrift (beliebiger freier Text bis zu 140 Zeichen)
    aMandatRefStringDie Mandatsreferenz, die Sie Ihrem Kunden z.B. in der Einzugsermächtigung und/oder der Rechnung mitgeteilt haben (bis zu 35 Zeichen)
    aMandatDateStringDas Datum, an dem Ihr Kunde das SEPA-Mandat (die Einzugsermächtigung) unterschrieben hat, im Format JJJJ-MM-TT (also z.B. "2011-04-15" für den 15. April 2011)
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, Überweisung wurde geschrieben
    29: Schreibfehler (wenn z.B. KtoSepa.OpenDebit nicht vorher aufgerufen wurde)
    117: Sie haben KtoSepa.WriteDebit zum Schreiben einer Lastschrift aufgerufen, aber vorher mit KtoSepa.OpenCredit eine Überweisungsdatei begonnen
    160: Ungültige Parameter (wenn z.B. aIban oder aBic nicht ausgefüllt wurden)

    Diese Funktion schreibt eine einzelne Lastschrift in eine zuvor mit KtoSepa.OpenDebit gestartete Lastschriftdatei.

  • function KtoSepa.CloseDebit

    Eingabeparameter
    NameTypInhalt
    aFileNameStringZiel-Dateiname für die XML-Lastschriftdatei (bitte vollen Pfad angeben; nicht einfach nur Dateiname bzw. relativer Pfad; also z.B. C:\Temp\Test.xml oder /var/tmp/test.xml)
    Ab Bankdatenversion 1520 kann ein Platzhalter für eine laufende Nummer angegeben werden, um separate XML-Dateien pro Ausführungstag und Sequence Type zu erzeugen (nötig für HBCI/FinTS). Bitte lesen Sie dazu die genaue Beschreibung auf der HBCI-Seite.
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, XML-Lastschriftdatei wurde geschrieben
    29: Schreibfehler (wenn z.B. KtoSepa.OpenDebit nicht vorher aufgerufen wurde und/oder ein ungültiger Dateiname übergeben wurde)
    117: Sie erzeugen gerade eine Überweisungsdatei; bitte verwenden Sie KtoSepa.CloseCredit!

    Diese Funktion schließt die zuvor mit KtoSepa.OpenDebit gestartete Lastschriftdatei und schreibt sie an die durch aFileName angegebene Stelle. Ab Bankdatenversion 1330 können Sie unmittelbar nach dieser Funktion noch KtoSepa.GetActualDueDate aufrufen, um den spätestmöglichen Einlieferungstag für die soeben geschriebene XML-Datei zu erfahren, wenn Sie vorab KtoSepa.SetBankDays richtig gesetzt hatten (vorausgesetzt, Sie halten die Einlieferungs-Uhrzeit ein, die hier nicht geprüft wird).

    Achtung: Sollte diese Funktion (z.B. mit Result=29) fehlschlagen, ist die Lastschriftdatei verloren, und eine erneute Erzeugung muss wieder von vorne mit KtoSepa.OpenDebit beginnen!

    Wenn Sie die Automatik zur Ermittlung des SeqTp benutzt haben, sollten Sie an dieser Stelle entweder KtoSepa.MergeTemp benutzen, wenn Sie die Datei tatsächlich an Ihre Bank übertragen, oder KtoSepa.DeleteTemp, wenn Sie die Datei nicht an Ihre Bank übertragen.

  • function KtoSepa.GetTempList

    Eingabeparameter
    NameTypInhalt
    ---
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisStringAngaben darüber, welche temporären Mini-Datenbanken es gibt und wie viele Lastschriften sie jeweils enthalten, im Format "A:B C:D" (d.h. es gibt zwei temporäre Mini-Datenbanken, eine für Mandant A mit B Lastschriften, und eine für Mandant C mit D Lastschriften)

    Diese Funktion ermittelt die gegenwärtig existierenden temporären Mini-Datenbanken (wenn es keine gibt, wird ein Leerstring zurückgeliefert). Im "normalen Workflow" brauchen Sie diese Funktion nicht; sie dient lediglich Diagnosezwecken.

  • function KtoSepa.DeleteTemp

    Eingabeparameter
    NameTypInhalt
    aMandantIntegerAngabe der Nummer des Mandanten, dessen temporäre Mini-Datenbank gelöscht werden soll
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, temporäre Mini-Datenbank wurde gelöscht
    2: Es gibt keine temporäre Mini-Datenbank für den angegebenen Mandanten
    3: Das Datenbankverzeichnis (siehe KtoSepa.SetDbDirectory / KtoSepa.GetDbDirectory) existiert nicht
    5: Das Löschen der Datei ist fehlgeschlagen

    Diese Funktion löscht die temporäre Mini-Datenbank des angegebenen Mandanten (wenn Sie die erstellte Lastschriftdatei doch nicht an die Bank schicken wollen). Diese Funktion dient lediglich Ihrem Komfort; Sie können die Datei (temp...db) auch (nachdem sie mit KtoSepa.CloseDebit geschlossen wurde) einfach auf Betriebssystemebene löschen. Oder sie lassen sie einfach stehen; sie wird beim nächsten KtoSepa.OpenDebit für diesen Mandanten sowieso überschrieben und neu angelegt.

  • function KtoSepa.MergeTemp

    Eingabeparameter
    NameTypInhalt
    aMandantIntegerAngabe der Nummer des Mandanten, dessen temporäre Mini-Datenbank in die Mandantendatenbank übernommen werden soll
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, temporäre Mini-Datenbank wurde in die Mandantendatenbank übernommen (und danach gelöscht)
    2: Es gibt keine temporäre Mini-Datenbank für den angegebenen Mandanten
    3: Das Datenbankverzeichnis (siehe KtoSepa.SetDbDirectory / KtoSepa.GetDbDirectory) existiert nicht
    5: Das Löschen einer Datei ist fehlgeschlagen
    29: Es ist ein Schreibfehler aufgetreten
    30: Es ist ein Lesefehler aufgetreten
    82: Es konnte keine neue Datei angelegt werden
    110: Das Öffnen einer Datei schlug fehl
    Es gibt in dieser Funktion zahlreiche Fehlermöglichkeiten; bitte verwenden Sie bei einem Ergebnis ungleich 0 die Funktion KtoSepa.GetLastError, um genauere Informationen über die Fehlerursache zu erhalten!

    Diese Funktion übernimmt die temporäre Mini-Datenbank des angegebenen Mandanten in die Mandantendatenbank. Sie sollten diese Funktion aufrufen, wenn Sie die zuletzt erstellte Lastschriftdatei für einen bestimmten Mandanten zur Bank übertragen haben, damit bei der nächsten Lastschriftdatei der SeqTp korrekt ermittelt werden kann.

  • Diagnose-/Datenbankfunktionen
  • function KtoSepa.ExportToFile

    Eingabeparameter
    NameTypInhalt
    aMandantIntegerAngabe der Nummer des Mandanten, dessen Datenbank in eine externe Textdatei geschrieben werden soll; wird die Nummer positiv angegeben, erhalten Sie die Mandantendatenbank; bei einer negativen Nummer die temporäre Mini-Datenbank der zuletzt erzeugten Lastschriftdatei für diesen Mandanten
    aFileNameStringAngabe der Textdatei, in die der Datenbankinhalt geschrieben werden soll
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, gewünschte Datenbank wurde in die angegebene Textdatei geschrieben
    2: Die gewünschte Datenbank existiert nicht
    3: Das Datenbankverzeichnis (siehe KtoSepa.SetDbDirectory / KtoSepa.GetDbDirectory) existiert nicht
    29: Lesefehler beim Lesen aus der Datenbank
    30: Schreibfehler beim Schreiben in die Textdatei
    82: Das Anlegen der Textdatei ist fehlgeschlagen
    110: Das Öffnen der Datenbankdatei ist fehlgeschlagen

    Diese Funktion schreibt den Datenbankinhalt in eine lesbare Textdatei. Ein Datensatz entspricht einer Textzeile, die stets mit dem Zeichen "$" beendet wird; die einzelnen Felder haben feste Breiten wie folgt:

    FeldlängeFeldinhalt
    10Kundennummer
    35Mandatsreferenz
    70Name des Zahlungsempfängers
    35Gläubiger-ID des Zahlungsempfängers
    34IBAN des Zahlungspflichtigen
    11BIC des Zahlungspflichtigen
    35Referenz der Lastschrift (z.B. Rechnungsnummer)
    01Sequenz-Typ (0=OOFF, 1=FRST, 2=RCUR, 3=FNAL)
    (0 kommt niemals vor, 3 nur in der temporären Datenbank)
    10Ausführungsdatum der Lastschrift (im Format JJJJ-MM-TT)
    01das Zeichen "$" als Zeilenendezeichen

    Alle Felder werden linksbündig belegt. Im "normalen Workflow" brauchen Sie diese Funktion nicht; sie dient lediglich Diagnosezwecken. So können Sie z.B. den Datenbankinhalt mit dieser Funktion in eine lesbare Textdatei exportieren, mit einem normalen Texteditor (z.B. Notepad) darin Daten ändern und mit KtoSepa.ImportFromFile die geänderten Daten wieder in die Datenbank zurückspielen. Natürlich sollten Sie das nur durchführen, wenn Sie wissen, was Sie tun – wir bieten keine Unterstützung, wenn Sie durch einen derartigen manuellen Eingriff Ihre Datenbank beschädigen!

  • function KtoSepa.ImportFromFile

    Eingabeparameter
    NameTypInhalt
    aMandantIntegerAngabe der Nummer des Mandanten, dessen Datenbank aus einer externen Textdatei erzeugt werden soll; wird die Nummer positiv angegeben, wird die Mandantendatenbank erzeugt; bei einer negativen Nummer die temporäre Mini-Datenbank der zuletzt erzeugten Lastschriftdatei für diesen Mandanten
    aFileNameStringAngabe der Textdatei, aus der der neue Datenbankinhalt gelesen werden soll
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, die angegebene Textdatei wurde als Datenbank übernommen
    2: Die angegebene Textdatei existiert nicht
    3: Das Datenbankverzeichnis (siehe KtoSepa.SetDbDirectory / KtoSepa.GetDbDirectory) existiert nicht
    13: Das Datenformat in Ihrer Textdatei stimmt nicht
    29: Fehler beim Schreiben in die Datenbankdatei
    30: Die angegebene Textdatei kann nicht gelesen werden
    82: Die Datenbankdatei kann nicht angelegt werden

    Diese Funktion legt eine Datenbankdatei neu an (eine evtl. bestehende Datenbankdatei wird dabei überschrieben!), mit dem Inhalt der angegebenen Textdatei. Für das Format der Textdatei sehen Sie bitte bei KtoSepa.ExportToFile nach. Im "normalen Workflow" brauchen Sie diese Funktion nicht; sie dient lediglich Diagnosezwecken. So können Sie z.B. einen exportierten Datenbankinhalt mit einem normalen Texteditor (z.B. Notepad) ändern und mit dieser Funktion die geänderten Daten wieder in die Datenbank zurückspielen. Natürlich sollten Sie das nur durchführen, wenn Sie wissen, was Sie tun – wir bieten keine Unterstützung, wenn Sie durch einen derartigen manuellen Eingriff Ihre Datenbank beschädigen!

  • Sonder-/Erweiterte Funktionen
  • function KtoSepa.SepaCommand

    Eingabeparameter
    NameTypInhalt
    aCommandStringAuszuführende Funktion
    aPar1IntegerErster Funktionsparameter (numerisch)
    aPar2IntegerZweiter Funktionsparameter (numerisch)
    aPar3IntegerDritter Funktionsparameter (numerisch)
    aPar4StringVierter Funktionsparameter (Text)
    aPar5StringFünfter Funktionsparameter (Text)
    aPar6StringSechster Funktionsparameter (Text)
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, die angegebene Funktion wurde korrekt ausgeführt
    1: Die angebenene Funktion existiert nicht
    weitere Rückgabecodes je nach gewählter Funktion

    Mit dieser Funktion können künftig neue/weitere SEPA-Funktionen ausgeführt werden, die bei der ursprünglichen Erstellung der KONTOPRUEF-OFFLINE-Software noch nicht enthalten waren, um das grundsätzliche Aufruf-Interface nicht ändern zu müssen. Im folgenden eine alphabetische Liste dieser Funktionen; bitte beachten Sie bei jeder Funktion, ab welcher Version der Bankdatendatei (bank...) zur Verfügung steht!

  • function KtoSepa.SepaCommand("BATCHBOOKING") ab Bankdatendatei 1342

    Mit dieser Funktion können Sie möglicherweise steuern, ob die Buchungen in Ihrer XML-Datei später in Ihrem Kontoauszug als ein einziger Sammelauftrag angezeigt werden oder als einzelne Buchungen. "Möglicherweise", weil jede Bank hier offenbar etwas anders agiert. Laut "offizieller" Dokumentation wird bei Fehlen dieses Parameters (wie bisher) nur der Sammelauftrag in ihrem Kontoauszug angezeigt, und die (mögliche) Aufsplittung in Einzelbuchungen müssten Sie theoretisch erst mit Ihrer Bank vereinbaren. Die Praxis zeigt jedoch, dass manche Banken auch ohne diesen Parameter Einzelbuchungen im Kontoauszug anzeigen. Wie auch immer – wenn Ihnen die momentane Anzeige in Ihrem Kontoauszug (Einzel-/Sammelbuchung) nicht gefällt, können Sie versuchen, mit diesem Parameter auf die andere Anzeige umzuschalten (allerdings ohne Gewähr auf Erfolg). Die Parameter und Ergebnisse sind wie folgt:

    Eingabeparameter
    NameTypInhalt
    aCommandStringDie Textkonstante BATCHBOOKING
    aPar1Integer-1 (wie bisher): Der Parameter "BatchBooking" wird überhaupt nicht in die XML-Datei geschrieben, es gelten die Standardeinstellungen Ihrer Bank
    0: Es wird "BatchBooking=FALSE" in die XML-Datei geschrieben, d.h. Sie wünschen in Ihrem Kontoauszug eine Anzeige der enthaltenen Einzelbuchungen
    1: Es wird "BatchBooking=TRUE" in die XML-Datei geschrieben, d.h. Sie wünschen in Ihrem Kontoauszug einen einzigen Buchungposten (den Sammelauftrag)
    aPar2IntegerDie Konstante 0
    aPar3IntegerDie Konstante 0
    aPar4StringLeere Textkonstante
    aPar5StringLeere Textkonstante
    aPar6StringLeere Textkonstante
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, Ihre Einstellung zu BatchBooking wurde übernommen
    87: Sie haben nicht -1, 0 oder 1 als Parameter angegeben
    117: Sie dürfen diese Funktion nur aufrufen, bevor Sie eine XML-Datei erzeugen (also vor Open...), nicht während der Erzeugung, da dieser Parameter für die gesamte Datei gilt und während des Erzeugens daher nicht mehr geändert werden kann

    Wie bei Fehler 117 bemerkt, dürfen Sie diese Funktion nur aufrufen, bevor Sie eine XML-Datei erzeugen (also vor Open...), nicht während der Erzeugung, da dieser Parameter für die gesamte Datei gilt und während des Erzeugens daher nicht mehr geändert werden kann.

  • function KtoSepa.SepaCommand("BICSCL") ab Bankdatendatei 1230

    Mit dieser Funktion können Sie prüfen, ob ein bestimmter BIC über den SEPA-Clearer des Elektronischen Massenzahlungsverkehrs der Bundesbank erreichbar ist. Sie können damit z.B. ermitteln, ob Sie Lastschriften von dieser Bank einziehen können. Die Parameter und Ergebnisse sind wie folgt:

    Eingabeparameter
    NameTypInhalt
    aCommandStringDie Textkonstante BICSCL
    aPar1IntegerDie Konstante 0
    aPar2IntegerDie Konstante 0
    aPar3IntegerDie Konstante 0
    aPar4StringDer zu prüfende BIC, z.B. PBNKDEFF760
    aPar5StringService, der geprüft werden soll; eine der folgenden Textkonstanten
    SCT ob man zu dieser Bank SEPA-Überweisungen senden kann
    SDD ob man von dieser Bank SEPA-Basislastschriften einziehen kann
    von Version 1340 bis einschließlich Version 1640: COR1 ob man von dieser Bank SEPA-Basislastschriften mit verkürzter Einlieferungsfrist einziehen kann (sog. "COR-1-Lastschriften") — in Version 1641 erhalten Sie hier immer das Ergebnis 21 — ab Version 1642 erhalten Sie bei der "COR1-Prüfung" das Ergebnis der "SDD-Prüfung", da die Bundesbank aufgrund der Migration zu Datenformat 3.0 keine separaten Angaben über COR1-Lastschriften mehr macht
    B2B ob man von dieser Bank SEPA-Firmenlastschriften einziehen kann
    aPar6StringLeere Textkonstante
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, der angebenene BIC existiert und kann für den geprüften Service verwendet werden
    13: Der angegebene BIC wurde im SCL-Directory überhaupt nicht gefunden
    21: Der angegebene BIC existiert, kann für den geprüften Service jedoch nicht verwendet werden
    87: Sie haben einen unbekannten Service angegeben (siehe aPar5 oben)
    Bei allen Funktionsergebnissen außer 13 können Sie unmittelbar anschließend mit der Funktion KtoSepa.GetLastError den Banknamen ermitteln.

    Bitte beachten Sie, dass diese SCL-Directory-Informationen aufgrund unterschiedlicher Update-Zyklen des SCL-Directories, der Bankleitzahlendatei und von KONTOPRUEF nicht immer auf dem tagesaktuellen Stand sind. Da aber natürlich immer mehr Banken immer mehr Services anbieten, können Sie normalerweise davon ausgehen, dass ein Ergebnis 0=Ok auch korrekt ist. Am ehesten könnte noch ein Ergebnis 21 veraltet sein, d.h. dass die geprüfte Bank bereits den geprüften Service anbietet, sich dies jedoch noch nicht im KONTOPRUEF-SCL-Directory widerspiegelt. In diesem Fall werden die aktualisierten Informationen beim nächsten KONTOPRUEF-Update eingespielt.

  • function KtoSepa.SepaCommand("CALCDUEDATE") ab Bankdatendatei 1330

    Mit dieser Funktion können Sie das Buchungsdatum in Abhängigkeit verschiedener Parameter ermitteln und/oder setzen.

    Eingabeparameter
    NameTypInhalt
    aCommandStringDie Textkonstante CALCDUEDATE
    aPar1IntegerEine positive oder negative Zahl, die die Anzahl der Bankarbeitstage angibt, die zum angegegebenen Datum (in aPar4) hinzugezählt oder vom ihm abgezogen werden soll. Die Angabe von 0 ergibt zum angegebenen Datum den nächsten Bankarbeitstag (bzw. unverändert das angegebene Datum selbst, falls es sich unmittelbar um einen Bankarbeitstag handelt)
    aPar2IntegerModus:
    0: Das Datum wird nur ausgerechnet, hat jedoch keinerlei Einfluss auf das Buchungsdatum. Sie können das ausgerechnete Datum mit KtoSepa.GetActualDueDate abfragen
    1: Das ausgerechnete Datum wird nur für die nächste Buchung (mit KtoSepa.WriteCredit oder KtoSepa.WriteDebit) berücksichtigt; danach wird wieder das bisherige Standard-Buchungsdatum verwendet
    2: Das ausgerechnete Datum wird so lange für alle weiteren Buchungen verwendet, bis diese Funktion erneut mit einem anderen Datums- und/oder Modus-Parameter aufgerufen wird (oder das KtoSepa-Objekt freigegeben wird)
    aPar3IntegerDie Konstante 0
    aPar4StringDas gewünschte Buchungsdatum im Format JJJJ-MM-TT, also z.B. 2013-10-30 für den 30. Oktober 2013
    aPar5StringLeere Textkonstante
    aPar6StringLeere Textkonstante
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, das Buchungsdatum wurde erfolgreich ausgerechnet (und bei Modus ≠ 0 für den oder die folgende(n) Write...-Aufrufe gesetzt); bitte holen Sie es ggf. über die Funktion KtoSepa.GetActualDueDate ab (ebenfalls im Format JJJJ-MM-TT)
    160: Das von Ihnen eingegebene Datum war nicht lesbar (nicht im Format JJJJ-MM-TT oder anderer Unsinn)

    Für die Einhaltung der Einlieferungsfristen sind Sie selbst verantwortlich. Sie können mit dieser Funktion z.B. auch den spätestmöglichen Einlieferungszeitpunkt ermitteln, wenn Sie das Buchungsdatum und die Einlieferungsfrist als negative Zahl übergeben (z.B. -6, wenn Sie sechs Tage vorher einliefern müssen – bitte berücksichtigen Sie in diesem Fall die Einlieferungsschlusszeit).

  • function KtoSepa.SepaCommand("GETSEQTP") ab Bankdatendatei 1330

    Mit dieser Funktion können Sie – ohne eine reale XML-Datei zu schreiben – ermitteln, welchen Sequenztyp die nächste Lastschrift für einen bestimmten Kunden hätte.

    Eingabeparameter
    NameTypInhalt
    aCommandStringDie Textkonstante GETSEQTP
    aPar1IntegerMandantennummer, wie auch bei KtoSepa.OpenDebit verwendet
    aPar2IntegerKundennummer, wie auch bei KtoSepa.WriteDebit verwendet
    aPar3Integer0, falls es nicht die letzte Lastschrift ist; 1, falls es die letzte Lastschrift ist
    aPar4StringMandatsreferenz für diese Lastschrift, wie auch bei KtoSepa.WriteDebit verwendet
    aPar5StringIBAN des Kunden, wie auch bei KtoSepa.WriteDebit verwendet
    aPar6StringBIC des Kunden, wie auch bei KtoSepa.WriteDebit verwendet
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Die nächste Lastschrift würde eine OOFF-Lastschrift
    1: Die nächste Lastschrift würde eine FRST-Lastschrift
    2: Die nächste Lastschrift würde eine RCUR-Lastschrift
    3: Die nächste Lastschrift würde eine FNAL-Lastschrift
    Möglicher Fehler:
    87: Mandant und/oder Kunde wurden als 0 übergeben

    Spezialfälle wie z.B. dass ein Mandat nach 36 Monaten ohne Benutzung erlischt o.ä. werden derzeit noch nicht berücksichtigt.

  • function KtoSepa.SepaCommand("REPAIR_BLZ") ab Bankdatendatei 1410

    Mit dieser Funktion können Sie einzelne unbekannte Ziffern in einer Bankleitzahl ermitteln (z.B. wenn die Einzugsermächtigung undeutlich ausgefüllt wurde und die eine oder andere Ziffer nicht eindeutig lesbar ist).

    Eingabeparameter
    NameTypInhalt
    aCommandStringDie Textkonstante REPAIR_BLZ
    aPar1IntegerDie Konstante 0
    aPar2IntegerDie Konstante 0
    aPar3IntegerDie Konstante 0
    aPar4StringDie fragliche Bankleitzahl, mit Fragezeichen ? an den unbekannten Positionen (muss aber acht Stellen lang sein!), z.B. 7?0100?5 (Fragezeichen sind an allen Positionen möglich)
    aPar5StringLeere Textkonstante
    aPar6StringLeere Textkonstante
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisIntegerAnzahl der ermittelten möglichen Bankleitzahlen

    Die ermittelten Bankleitzahlen können Sie anschließend als Komma-separierte Liste mit der Funktion KtoSepa.GetLastError abholen. Wenn Sie die Banknamen dazu benötigen, können Sie diese anschließend mit der Funktion KtoPruef.GetBankName27 abrufen.

  • function KtoSepa.SepaCommand("REPAIR_IBAN") ab Bankdatendatei 1410

    Mit dieser Funktion können Sie einzelne unbekannte Zeichen in einer IBAN ermitteln (z.B. wenn das SEPA-Mandat undeutlich ausgefüllt wurde und die eine oder andere Ziffer nicht eindeutig lesbar ist).

    Eingabeparameter
    NameTypInhalt
    aCommandStringDie Textkonstante REPAIR_IBAN
    aPar1IntegerDie Konstante 0
    aPar2IntegerDie Konstante 0
    aPar3IntegerDie Konstante 0
    aPar4StringDie fragliche IBAN, mit Fragezeichen ? an den unbekannten Positionen (die Länge muss aber stimmen!), z.B. DE0?7?0100?50000001?5? (Fragezeichen sind an allen Positionen möglich, auch beim Land!)
    aPar5StringLeere Textkonstante
    aPar6StringLeere Textkonstante
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisIntegerAnzahl der ermittelten möglichen IBAN

    Die ermittelten IBAN können Sie anschließend als Komma-separierte Liste mit der Funktion KtoSepa.GetLastError abholen.

    Wichtiger Hinweis: Diese Funktion wird mit steigender Anzahl der Fragezeichen sehr rechenintensiv (und kann Ihren Computer damit lahmlegen)! Aus eigener Erfahrung sind maximal ca. 4 bis 6 Fragezeichen sinnvoll (je nach Rechenleistung und anderen Randbedingungen); außerdem würden Sie sonst auch zu viele Ergebnisse erhalten.

  • function KtoSepa.SepaCommand("REPAIR_KTO") ab Bankdatendatei 1410

    Mit dieser Funktion können Sie (bei bekannter Bankleitzahl) einzelne unbekannte Zeichen in einer Kontonummer ermitteln (z.B. wenn die Einzugsermächtigung undeutlich ausgefüllt wurde und die eine oder andere Ziffer nicht eindeutig lesbar ist).

    Eingabeparameter
    NameTypInhalt
    aCommandStringDie Textkonstante REPAIR_KTO
    aPar1IntegerDie Konstante 0
    aPar2IntegerDie Konstante 0
    aPar3IntegerDie Konstante 0
    aPar4StringDie fragliche Kontonummer, mit Fragezeichen ? an den unbekannten Positionen (Länge 1 bis 10 Stellen), z.B. 9249?2385? (Fragezeichen sind an allen Positionen möglich)
    aPar5StringDie vollständige (achtstellige) Bankleitzahl (ohne Fragezeichen)
    aPar6StringLeere Textkonstante
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisIntegerAnzahl der ermittelten möglichen Kontonummern

    Die ermittelten Kontonummern können Sie anschließend als Komma-separierte Liste mit der Funktion KtoSepa.GetLastError abholen.

  • function KtoSepa.SepaCommand("SETDDTYPE") ab Bankdatendatei 1330

    Mit dieser Funktion können Sie den Lastschrifttyp der zu erstellenden Lastschriftdatei(en) setzen:

    • CORE — SEPA-Basislastschriften (=Voreinstellung, wenn Sie nichts daran ändern)
    • B2B — SEPA-Firmenlastschriften
    • COR1 — SEPA-Basislastschriften mit Vorlagefrist D-1

    Verwenden Sie diese Funktion, bevor Sie KtoSepa.OpenDebit aufrufen.

    Eingabeparameter
    NameTypInhalt
    aCommandStringDie Textkonstante SETDDTYPE
    aPar1IntegerDie Konstante 0
    aPar2IntegerDie Konstante 0
    aPar3IntegerDie Konstante 0
    aPar4StringDie Textkonstante CORE, B2B oder COR1
    aPar5StringLeere Textkonstante
    aPar6StringLeere Textkonstante
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, der Lastschrifttyp wurde gesetzt wie gewünscht
    87: Die eingestellte SEPA-Version ist kleiner als 2.7. COR1-Lastschriften können nur ab Version 2.7 verwendet werden.
    117: Es ist gerade eine Datei geöffnet (d.h. Sie befinden sich zwischen Open... und Close...). Der Lastschrifttyp darf nur bei geschlossenen Dateien geändert werden.
    160: Sie haben nicht CORE, B2B oder COR1 als Lastschrifttyp angegeben

    Bitte beachten Sie, dass COR1-Lastschriften nur möglich sind, wenn...

    • Sie KONTOPRUEF-OFFLINE auf mindestens SEPA-Version 2.7 umgestellt haben
    • das Ausführungsdatum nicht vor dem 1. November 2013 liegt
    • Ihre Bank die Einlieferung von COR1-Lastschriften unterstützt
    • alle Banken aller Schuldner ebenfalls COR1-Lastschriften unterstützen
    • Ihr Gläubigerkonto für COR1-Lastschriften freigeschaltet ist
    • Ihr Online-Banking-Programm den EBICS-Auftragstyp CD1 unterstützt
    • und Ihre Bank diesen Auftragstyp in EBICS freigeschaltet hat.

    Sie sind für die Einhaltung all dieser Kriterien selbst verantwortlich!

  • function KtoSepa.SepaCommand("SETPAIN") ab Bankdatendatei 1511

    Mit dieser Funktion können Sie vom Standard abweichende Formatdefinitionen in die erzeugte SEPA-XML-Datei schreiben. Dies müssen Sie i.d.R. niemals tun, außer Sie reichen die SEPA-XML-Datei bei einer ausländischen Bank ein, die ein vom Standard der Deutschen Kreditwirtschaft abweichendes Format verlangt.

    Eingabeparameter
    NameTypInhalt
    aCommandStringDie Textkonstante SETPAIN
    aPar1Integer1: Formatdefinition für Überweisungen
    8: Formatdefinition für Lastschriften
    aPar2IntegerVariante:
    1: ISO 20022/EPC
    2: ZKA/DK Version 2.3-2.6 (nicht mehr verwendet)
    3: ZKA/DK Version 2.7-2.8 (nicht mehr verwendet)
    aPar3IntegerVersion:
    1: ISO Version 09/2005 (nicht mehr verwendet)
    2: ISO Version 09/2006 (verwendet für Lastschriften)
    3: ISO Version 03/2009 (verwendet für Überweisungen)
    4: ISO Version 04/2012 (nicht verwendet)
    5: ISO Version 05/2013 (nicht verwendet)
    6: nicht verwendet
    7: nicht verwendet
    8: ISO Version 2017: Wie 3, aber nur für Echtzeitüberweisungen (EBICS-Auftragstyp CIP statt CCT) mit theoretisch möglicher Uhrzeitangabe, was von KONTOPRUEF-OFFLINE jedoch aktuell nicht unterstützt wird
    9: ISO Version 2019: wie 8, würde theoretisch die Angabe des „CtgyPurp“ per selbst definierten Texten ermöglichen (z.B. „Gehalt“ statt „SALA“) – diese eigenen Texte werden jedoch von KONTOPRUEF-OFFLINE nicht unterstützt
    aPar4StringLeere Textkonstante
    aPar5StringLeere Textkonstante
    aPar6StringLeere Textkonstante
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, die "Pain"-Formatangabe wurde gesetzt wie gewünscht
    160: Sie haben einen ungültigen Wert angegeben; bitte rufen Sie GetLastError auf, um nähere Informationen zu erhalten

    Anmerkung: Normalerweise brauchen Sie diese Funktion nicht; rufen Sie Sie also nur auf, wenn Sie wissen, was Sie tun! Sie müssen genau die Version einstellen, die die Bank von Ihnen erwartet; Sie können also nicht "irgendetwas" ausprobieren!

  • function KtoSepa.SepaCommand("SETTEXTMODE") ab Bankdatendatei 1421

    Mit dieser Funktion können Sie beeinflussen, wie der Zeichensatz (insbesondere Umlaute) in den Feldern "Name" (beim Auftraggeber und beim Zahlungsempfänger/-pflichtigen) und "Verwendungszweck" behandelt werden:

    Eingabeparameter
    NameTypInhalt
    aCommandStringDie Textkonstante SETTEXTMODE
    aPar1Integer0: Umlaute werden durch die Umschreibung mit "e" ersetzt, also z.B. "ä" durch "ae" etc. (Voreinstellung)
    1: Umlaute werden durch ihre Entsprechung ohne diakritische Zeichen ersetzt, also z.B. "ä" durch "a" etc.
    2: Umlaute werden durch die mit der deutschen Kreditwirtschaft vereinbarten Zeichen ersetzt (siehe dazu Anmerkung unten)
    +4: Wenn Sie zum obigen Wert 4 addieren, generiert der Aufruf einer ...Open- bzw. ...Write-Funktion eine Fehlermeldung, wenn die maximale Feldlänge (70 für Namen, 140 für den Verwendungszweck) überschritten wird. Ansonsten wird der Feldinhalt bei der maximalen Länge ggf. kommentarlos abgeschnitten (Voreinstellung).
    aPar2IntegerDie Konstante 0
    aPar3IntegerDie Konstante 0
    aPar4StringLeere Textkonstante
    aPar5StringLeere Textkonstante
    aPar6StringLeere Textkonstante
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisInteger0: Ok, der "Text Mode" wurde gesetzt wie gewünscht
    160: Sie haben keinen der Werte 0, 1, 2, 4, 5 oder 6 angegeben (andere Werte sind nicht zulässig)

    Anmerkungen zu den einzelnen "Umlaut-Methoden":

    • 0 bzw. 4: Dies ist die "schönste" (weil: "lesbarste") Variante, allerdings kann es passieren, dass der Feldinhalt durch die eingefügten zusätzlichen Zeichen zu lang wird (was dann passiert, hängt davon ab, ob Sie 0 oder 4 als Parameter übergeben haben, siehe oben).
    • 1 bzw. 5: Dies ist die "sicherste" Variante, da der Feldinhalt durch die Umcodierung nicht zu lang werden kann; allerdings ist der Feldinhalt nicht so "schön" lesbar ("Muller" statt "Müller" bzw. "Mueller").
    • 2 bzw. 6: Angeblich akzeptieren deutsche Kreditinstitute die gleiche Zeichencodierung wie "damals" bei den DTAUS-Dateien, so dass zumindest Umlaute (und die Sonderzeichen & * $ %) eingeliefert werden können. Ich habe das selbst nie ausprobiert; außerdem gibt es in dieser Codierung keine "kleinen" Umlaute, so dass z.B. "MÜller" dabei herauskäme (falls a) die Einlieferung überhaupt klappt und b) das ganze tatsächlich so zum Empfänger transportiert wird). Sie können diese Einstellung "auf eigene Gefahr" benutzen...

Hinweis zur Identifikation von Absender/Empfänger

Überall, wo Sie den Namen des Zahlungspflichtigen bzw. des Zahlungsempfängers (oder auch den Namen des Auftraggebers) angeben, können Sie jeweils hinter einem senkrechten Strich ("|") noch weitere optionale Parameter angeben. Gegenwärtig sind dies:

  • (ab Bankdatenversion 1511) Organisations-ID (eine Nummer / Kennung / Identifikation bis zu 35 Zeichen)
  • (ab Bankdatenversion 1730) Land (als zweibuchstabiger ISO-Code, z.B. AT für Österreich oder CH für die Schweiz)
  • (ab Bankdatenversion 1730) Erste Adresszeile (Freitext bis zu 70 Zeichen, z.B. Straße und Hausnummer)
  • (ab Bankdatenversion 1730) Zweite Adresszeile (Freitext bis zu 70 Zeichen, z.B. Postleitzahl und Ort)

Wenn dabei ein Feld leer gelassen werden soll, folgen zwei senkrechte Striche unmittelbar aufeinander. Leere Felder am Ende können einfach weggelassen werden.

In den SEPA-Dokumenten der Deutschen Kreditwirtschaft wird von der Verwendung dieser Felder abgeraten. Ich habe auch keine offizielle Information darüber gefunden, ob und wann und welche dieser Felder befüllt werden müssen. Aus Gesprächen mit Kunden kenne ich zwei Verwendungsmöglichkeiten dieser Felder:

  1. In Spanien wird das Feld Organisations-ID mit der Steuernummer befüllt. Hier würden Sie als Name also etwa

    Banco Santander|A39000013

    übergeben.

  2. Lastschrifteinzüge von Schweizer Konten sollen von den Schweizer Banken nur akzeptiert werden, wenn die vollständige Adresse des Schuldners mitgeliefert wird. Hier wäre als Name also z.B.

    Credit Suisse||CH|Limmatquai 58|8001 Zuerich

    denkbar. (Beachten Sie das leere Organisations-ID-Feld zwischen dem Namen Credit Suisse und dem Land CH!)

Ob und wann und wie Sie diese Felder tatsächlich befüllen müssen, klären Sie bitte mit Ihrer Bank (oder versuchen "Try and Error"). Ich stelle Ihnen lediglich die technischen Möglichkeiten dafür zur Verfügung; inhaltlich kann ich Ihnen leider nicht mit weiteren Informationen dienen.

Nach oben

KtoSwift

Das KtoSwift-Modul wird nicht mehr unterstützt.

Nach oben

KtoArbeit

Mit diesem Modul können Sie die Anzahl der Arbeitstage in einem bestimmten Monat, Quartal oder Jahr ermitteln.

  • function KtoArbeit.Arbeitstage

    Eingabeparameter
    aYearIntegerGewüschtes Jahr (z.B. 2004)
    aMonthIntegerEiner der folgenden Werte:
    1 bis 12: Monat
    41 bis 44: Quartal
    0: Gesamtes Jahr
    aSaturdaysFlagInteger0: Samstage zählen nicht als Arbeitstage
    1: Samstage zählen als Arbeitstage
    aFeiertageSetIntegerAngabe, welche Tage als Feiertage gelten sollen (siehe unten)
    Ausgabeparameter
    NameTypInhalt
    FunktionsergebnisIntegerAnzahl der Arbeitstage gemäß der angegebenen Parameter (bei ungültigen Parametern, z.B. aMonth=13, wird -1 zurückgegeben - ebenso bei 30% der Antworten der Demoversion)

    Ermittelt die Anzahl der Arbeitstage anhand der angegebenen Parameter. Für die Angabe der Tage, die als Feiertage gelten sollen, zählen Sie die Werte der folgenden Tage zusammen:

    TagWert
    Heilige drei Könige1
    Christi Himmelfahrt2
    Fronleichnam4
    Friedensfest8
    Mariä Himmelfahrt16
    Reformationstag32
    Allerheiligen64
    Allerseelen128
    Buß- und Bettag256
    Heiliger Abend512
    Silvester1024
    Immer als Feiertag gelten:
    • Neujahr
    • Karfreitag
    • Ostermontag
    • Tag der Arbeit
    • Pfingstmontag
    • Tag der deutschen Einheit
    • 1. Weihnachtstag
    • 2. Weihnachtstag

Nach oben

Sehen Sie sich auch mein anderes Produkt an:
myebilanz – die Freeware-eBilanz aus MySQL und CSV!
myebilanz