Zitat geschrieben von Sinspin
Da steht ja unter anderem MT940 und CSV zur Verfügung.
Was mich etwas wundert:
Der gewaltige Unterschied im Informationsgehalt zwischen den beiden Formaten.
Da ist dem CSV echt der Vorzug zu geben.
Das stimmt so nicht. MT940 ist das "Original-Format", also jenes, was direkt vom Bankrechner übertragen wird. Darin sind *alle* Angaben, die im CSV auch drin sind. Und sogar etwas mehr (z.B. Anfangs- und Endsaldo pro Buchungstag). Sprich: Das CSV-Format ist nur eine Weiterverarbeitung des MT940, für leichteren Zugriff, z.B. mit Excel. Daten, die im MT940 nicht drin sind (also nicht vom Bankrechner geliefert werden), können somit auch nicht im CSV erscheinen. Was hierzu noch zu sagen ist: Die verschiedenen Banken verwenden teilweise *sehr* unterschiedliche "Dialekte" von MT940. Will heißen, eine Bank packt den Empfängernamen ins richtige Subfeld "Name", die nächste packt ihn einfach in die erste Textzeile. Jenachdem kann im CSV der Name dann auch in unterschiedlichen Spalten erscheinen. Überhaupt kocht leider jede Bank bzw. Rechenzentrum ihr eigenes Süppchen...
Zitat geschrieben von Sinspin
Das einzige was mir negativ aufgefallen ist, ist das ich nirgendwo eine Transaktions- oder Buchungsnummer finden kann über die eine eindeutige Zuordnung möglich ist, oder die ich als Tabellenindex verwenden könnte.
Im MT940 gibt es zwar kaum Informationen, dafür aber eine Auftragsreferenznummer, auch wenn die in meinen Versuchen, mit einem Demobankkonto nicht wirklich sinnvoll belegt ist, könnte das ein Kandidat sein. Nur das ich MT940 nur äußerst ungern verwenden möchte.
Ich kann mir nicht recht vorstellen das nicht irgend eine fortlaufende Nummer existiert, die zumindest für das abgefragte Konto eindeutig ist. Da würde mir schon vollständig reichen.
Auch das ist so falsch. Es gibt definitiv KEINE fortlaufende Buchungsnummer o.Ä., an der man eine Buchung eindeutig erkennen könnte. Keine Bank die ich kenne, liefert das. Außerdem wäre dafür in MT940 auch garkein Subfeld definiert. Die genannte Auftragsreferenznumer gibt es zwar, aber sie wird nur in bestimmten Ausnahmefällen vom Bankrechner belegt - bei manchen RZ generell nie. So z.b. bei der Verbuchung von eingereichten DTA-Dateien, da wird in dieses Feld dann die Referenznummer aus der Datei eingestellt. Damit kann man dann erkennen, welche der eingereichten Dateien da verbucht wurde. Weiterhin erscheinen hier u.U. Scheck-Endnummern oder eine interne laufende Nr. eines Dauerauftrags, damit man erkennen kann, welcher DA es ist. Aber das muß man dann beim jeweiligen Bankrechner im Einzelfall sehen, wann da was geliefert wird. Bei normalen Überweisungen und Zahlungseingängen ist das Feld leer bzw. mit "NONREF" belegt. Somit also für den von Dir gewünschten Zweck unbrauchbar. Problematisch wird das Ganze natürlich bei Banken, die untertags laufend buchen. Da bekommt man ja bei jedem erneuten Abruf wieder die bereits schon mal übertragenen Umsätze wieder mitgeliefert. Es gibt dann z.b. für die Übernahme in eine Datenbank *kein* eindeutiges Kennzeichen, was man schon bearbeitet hat und was nicht. Die einfachste und meist praktizierte Lösung ist, in der Datenbank den kompletten letzten Buchungstag zu löschen und neu zu übernehmen. Wenn man in der Datenbank dem Datensatz bereits etwas hinzugefügt hat (interne Kontierung ect.) dann wird es noch komplizierter. Dann muß man ggf. jeden Umsatz Feld für Feld vergleichen, ob das ein Umsatz ist, den man schon hatte oder nicht.
Alles in Allem sind die Genannten Probleme allesamt auf die Datenlieferung der Bankrechner zurückzuführen und nicht Sache von Subsembly.
Achja und noch etwas: Wegen der genannten MT940-Dialekte und der somit nicht bei allen Banken genau übereinstimmenden Datenanlieferungen (gerade bei den Feinheiten, die man braucht, wenn man automatisch weiterverarbeitet) kann man nie eine für alle Bankrechner passende Universallösung schreiben. Im Prinzip sind die einzigen wirklich überall gleich belegten Felder die Felder "Buchungsdatum", "Wertstellungsdatum" und "Betrag". Irgendwo hakt es dann immer und man muß für die jeweilige Bank kleine Anpassungen vornehmen. Nur daß Du dann nicht enttäuscht bist, wenn Du ein tolles Weiterverarbeitprogramm schreibst, und das dann mit "echten" Daten eines realen Kontos nicht 100% klarkommt...
Schöne Grüße,
Michael
