Verständnisfragen zu MT940

Das ist eigentlich ganz einfach. Feld :61: ist der eigentliche Umsatz. Die erste Zahlenkolonne ist zuerst Wertstellung und dann Buchungstag (ohne Jahr), also Wertstellung 26.10.2015, Buchungstag 26.10.
Dann D wie Debit (also Zahlungsausgang minus), dann R wie Euro (da wird immer der letzte Buchstabe des dreistelligen Währungskürzels gesetzt), dann Betrag 29,89 dann fix N dann noch einige Kennzeichnungen laut SWIFT-Handbuch (unwichtig) und NONREF also keine Scheck-Referenznummer.

Feld :86: ist das Feld mit Zusatzangaben zu dem vorhergegangenen Umsatz. Die ?xx sind die Feldschlüssel von Sub-Feldern. Verständlich aufbereitet wäre das in Deinem Beispiel:

:86:105 (Feld 86, Geschäftsvorfallcode 105)
?00 FOLGELASTSCHRIFT (Subfeld 00 = Buchungstext)
?10 9248 (Subfeld 10 = Primanota)
?20 KUNDENKONTO000048 (Subfeld 20-29 und ggf. Subfeld 60-63 = bis zu 14 Verwendungszweck-Zeilen)
?21 43 44 002117800551/12.
?22 10.15 Gläubiger-ID DE93ZZZ0
?23 0000078 611 Mandatsreferenz
?24 DE00500010000000000
?25 05061316 Kundenreferenz (En
?26 d-to-End) ZAHLUNGSBELEG 208
?27 118226
?30 HYVEDEMMXXX (Subfeld 30 = BIC oder BLZ)
?31 DE687002067302269 (Subfeld 31 = IBAN oder KtoNr)
?32 TELEKOM DEUTSCHLAND (Subfeld 32 = Zahlungsgegnername)
?34 992 (Subfeld 34 = Textschlüsselergänzung)

Dass die Zeilen teils auseinandergerissen sind ist der ggf. mehrfachen Konvertierung zwischen altem IZV und neuem SEPA zwischen den Banken geschuldet, das geht derzeit wohl nicht anders. Auch dürfen die Zeilen im MT940 grundsätzlich maximal 80 (ich glaube) Zeichen lang sein, danach wird umgebrochen. Das heißt, die Zeilenumbrüche im Original-MT940-Datenstrom im Feld 86 sind uninteressant. Um das Feld 86 auszuwerten muß man zuerst alle Zeilenumbrüche entfernen und dann anhand der Subfelder selbst welche reinmachen. Dein Beispiel En?26d-to-End ist völlig korrekt. Da war die Verwendungszweckzeile ?25 voll und der Text geht einfach in der nächsten Zeile ?26 weiter...

Subfelder 20-29 + Subfelder 60-63 (sofern vorhanden, wenn es sehr viel Text gibt) - ja. Diesen Text in einer eigenen Datenbank einfach unter Verlust der "Zeilen" in ein langes Feld zu packen halte ich für das sinnvollste, da die Zeileneinteilung zu Zeiten von SEPA eh kreuz und quer geht. Dein Datenbank-Textfeld müsste dann im Maximum 14*27 Stellen aufnehmen können (eine Textzeile, also ein Subfeld, kann maximal 27 Zeichen lang sein.

Ich beziehe die Umsätze über die Windata-Autoauszug Funktion. Die Kontoumsätze werden von Windata abgerufen und in eine Datei exportiert. Das camt Format wird leider nicht zum Export angeboten. Sonst wäre das natürlich super.

wenn man wüsste was mit den Daten genau passieren soll
... evtl. in welches Programm Import o.ä.
dann wäre wie üblich vieles leichter

des weiteren welche windata Version im Einsatz ist .. die V 8.8? - http://wiki.windata.de/index.p…indata_8.8

http://wiki.windata.de/index.p…sch_Export:
http://wiki.windata.de/index.p…%C3%A4tze_(AutoAuszug)#camt.053_abrufen bzw http://wiki.windata.de/index.p…-Nachricht
http://wiki.windata.de/index.php?title=Kategorie:Export

EBICS wird von allen Banken mit Firmen in der Kundschaft unterstützt, oft kostet es aber Geld.
Die Version 9 von windata ist meines Wissens bereits im Test, evtl. kann die auch CAMT über FinTS/HBCI exportieren.
Eventuell solltest du mal selbst mit dem Windata-Support sprechen, die haben dort durchaus fähige Leute.
Gruß
Raimund

Wie gesagt, es geht um die Entwicklung einer Software zur Kontrolle von Kontobewegungen. Ich möchte auf keinen Fall, dass in dieser Software bzw. der darunterliegenden Datenbank irgendwelche PINs, Schlüsseldateien, etc. gespeichert werden. Es soll auch nicht möglich sein, über die Software Zahlungen vorzunehmen.

Da bin ich konservativ. Ich als Hersteller der Software möchte nicht haften, wenn es jemandem gelingen sollte, meine Software zu hacken und Missbrauch mit vertraulichen Zugangsdaten zu treiben.

Das ist auch ein Grund, weshalb ich auf externe Software wie Windata setze. Wobei es jetzt nicht zwingend Windata sein muss, ich brauche nur eine Möglichkeit automatisiert Umsätze abzurufen und das geht mit dem Windata-Autoauszug halt.

Das ist klar. Aber wenn ich Windata (oder ein vergleichbares kommerzielles Produkt) einsetze, trage ich nicht mehr die alleinige Verantwortung bei Missbrauch. Windata ist dafür verantwortlich, dass ihre Software "sicher" (ein schwammiges Wort) ist, also nicht "geknackt" werden kann. Anders beim Einsatz von Opensource Software: hier liegt die Hauptverantwortung im Fall von Missbrauch auf meiner Seite.

Ich möchte als Entwickler einer Software auf keinen Fall hochsensible Zugangsdaten in "meiner" Datenbank speichern. Diese Verantwortung gebe ich gerne an Windata ab.


Es geht darum, für Konten von Einzelpersonen die Buchhaltung der kompletten Finanzen (alle Ein- und Ausgaben) durchzuführen. Ein Teil dieser Buchhaltung ist die tabellarische Darstellung von Kontoumsätzen, um die Ein-/Ausgaben kontrollieren zu können. Weiterhin werden auch Online Zahlungen durchgeführt, aber das ginge ja dann über Windata.

Ich habe mir auch Buchhaltungsprogramme angesehen, nur oberflächlich. Ich hatte nicht den Eindruck, dass hier eine saubere Schnittstelle möglich ist, um die Einzelpersonen aus meiner Software eindeutig mit den Mandanten in der Buchhaltungssoftware zu verknüpfen.

Also irgendwie kann ich alleine den hier besprochen Part (Kontoumsätze usw.) sowie die Begründung in #12 nicht nachvollziehen.

Der Kunde muss doch bspw. bei seiner Bank einen eingeschränkten HBCI/FinTS (Beraterzugang) beschaffen - dh. hier können nur Kontoumsätze eingesehen werden.
aber selbst wenn der Kunde sein Zugangsdaten aushändigen würde, was oft für automatischer Abruf durch den Stb. gemacht wird (auch wenn bankseits nicht gerne gesehen/rechtlich fraglich) kann dieser ohne das Authorisierungsmedium nichts machen.
Dh. selbst wenn dies komplett Online ablaufen würde und ein hack erfolgt, wären nur die Kontoumsätze einsehbar - egal ob direkt auf der Page oder über die banking-homepage

Komplizierter wird es mit den automatischen Zahlungen, denn welcher Kunde gibt sein Authorisierungsmedium einem "Dritten"? Dies wäre nicht nur Haftungstechnisch eine Frage, der "Dritte/Berater könnte ja frei verfügen und abhauen" sondern auch rechtlich - Richtung Treuhandkonto ..
Hinzu kommen PSD2 - was ja Vor- und Nachteile hat bzw. manche Dinge erschwert usw.
Hier soll es ja gerade Drittanbietern ermöglicht werden div. Services anzubieten und einfacheren Bankenzugang, aber auf der anderen Seite wie vorgenannt soll der Kunde gestärkt werden. Insgesamt dürfte dies aber über eine API gehen wie von den vorgenannten Unternehmen aufgeführt (konfipay = windata) die ja lediglich als Bridge zur Verfügung stehen, dh. der Service ruft die Umätze usw. ab, der Berater stellt evtl. Überweisungsvorlagen ins System und der Kunde autorisiert selbst seine Daten.

Bei @Holger werden bei der o.g. Idee des TS bestimmt alle Alarmglocken schrillen.

@Raimund es geht ja aber auch um Zahlung die der Berater anscheinend durchführt/durchführen soll. (siehe meine vorgenannten Bedenken)
Aber alleine die Kontoumsätze abfragen ist so eine Sache, denn ob "eigener Server" oder externer Dienstleister ist bestimmt ein abendfüllendes Thema - windata mit konfipay oder die anderen Entwickler sehen ja hier Bedarf.
Die start-ups ja auch, denn somit können diese sich fokussieren und müssen sich nicht um Banking-Software usw. kümmern.
Egal ob Banking-Software (Server) oder API kommt eine weitere Hürde noch hinzu, dass ja auch screenscraper unterstützt werden sollen, das kann auch nicht jede Software.

Ich verstehe nicht 100% was Du sagen willst. In meinem Szenario hat der Bevollmächtigte vom Mandanten die Zugangsdaten für HBCI erhalten (kann übrigens auch Zahlungen vornehmen). Selbst wenn ein Krimineller sich "nur" den Zugang zu den Umsätzen verschafft, gelangt er an hochprivate Daten ran und begeht eine Straftat. Ganz zu schweigen, wenn er Zahlungen vornehmen sollte, Auch wenn das nicht publik wird: Online-Zugänge werden in seltenen Fällen geknackt und es entstehen auch finanzielle Verluste.

Windata als Hersteller ist dafür verantwortlich, dass die in Windata gespeicherten Zugangsdaten vor dem unbefugten Zugriff sicher sind. Ich gehe davon aus, dass bei Verwendung einer API wie subsembly die Zugangsdaten in "meiner" Software gespeichert werden. In dem Moment, wo ich die Zugangsdaten in meiner eigenen Software speichere, trage ich als Hersteller der Software die Verantwortung und die will ich nicht haben, deswegen überlasse ich das Windata. Anders sähe es aus, wenn die Zugangsdaten auf den Servern des Service-Providers gespeichert werden (bei konfipay ist das glaube ich so?), dann bin ich die Verantwortung los und kann ruhig schlafen.


Habe ich auch gesehen, danke für den Hinweis.

Damit hier keine Missverständnisse aufkommen: der "Bevollmächtigte" ist ein behördlich bestellter Betreuer (also ein gesetzlicher Vormund). Dieser ist vom zuständigen Amtsgericht beauftragt, sich um die Finanzen seines Mandanten (= der Betreute) zu kümmern, weil dieser aufgrund Alter, Krankheit, etc. dazu nicht mehr in der Lage ist. Rechtlich ist das einwandfrei, der Mandant muss sogar von Amts wegen seine persönlichen Daten rausgeben, damit der Betreuer seine Arbeit machen kann.