11 stellige Kontonummern bei der Deutschen Bank

zumindest bei den von den volksbanken vertriebenen produkten kannst du hier pro bank individuelle "zuschnitte" definieren dass die zuordnung zum korrekten konto erfolgen kann.
würde mich wundern wenn sfirm das nicht auch könnte...

echt?? ist ja fatal...

na dann wirds wohl schwierig, dann musst die mt940 manuell bearbeiten und dann korrigiert einlesen. finde ich persönlich aber nicht alltagstauglich.

oder halt ein produkt suchen dass die dateien korrekt verarbeiten kann...

Doch, es gibt die konten.ini im Datenverzeichnis. Dort kann man das zuordnen. Insbesondere für solche absonderlichen Kontonummern wie bei der DB und CoBa.
Ich weiß nur im Moment die Syntax nicht, bitte mal beim Support der Sparkasse nach der konten.ini fragen!

Wofür? Leg das Konto doch mit seiner tatsächlichen 10stelligen Kontonummer manuell an und ordne es dann über die ini zu damit die STA's richtig eingelesen werden können.

Das habe ich übersehen. Kann die Bank denn nicht einfach normale Kontonummern vergeben wie jede andere auch?
Ansonsten vielleicht tatsächlich Bank oder Software wechseln. Normal ist das ja nicht. Die DB empfiehlt - soweit ich weiß - Starmoney Business. Kann das denn 11stellige Kontonummern?

Probleme lösen zu wollen die es garnicht geben dürfte ehrt dich. Würde ich mir aber garnicht erst an Land ziehen. Lass die DB ihre Sonderheiten selbst regeln. Wenn das immer andere tun merken sie ja nie was sie da fabrizieren. Oder ziehe die Konten rüber. Als Lizenzgeber bist du wahrscheinlich eine Sparkasse und diese Probleme wird es nicht mehr geben.
Hat bei denen die IBAN eigentlich auch mehr Stellen als zulässig?
Falls nein, könnte man da nicht etwas über CAMT regeln? Kann die DB CAMT.053 schon?

Guten Abend,

ich mag falsch liegen, aber ich glaube hier werden zwei Dinge vermischt.
1. Eine "deutsche" Kontonummer sollte laut (ZKA) DFÜ-Abkommen nur max. 10-stellig sein. Leider interessiert das die Bank nicht

2. Das MT940 Format kann z.B. auch ausländische Kontoauszüge übermitteln.
Dort kann das Feld für die Kontonummer 23 Stellen mit Währungskennzeichen lang sein.

Wenn Sie sich bei der Kontonummer nicht dran halten, ist die Frage nach der IBAN zwar nicht unberechtigt, aber eher als Scherz zu sehen - denke ich.
Beim Gesamteuropäischen Gefüge wird sich wohl auch eine Deutsche Bank dran halten müssen *g*.

Zum Problem:
Ich kann mich nicht mehr ganz dran erinnern, wie die Lösung aussah, aber früher wurde in die Konten.ini ein Parameter eingefügt - glaube ich, der ungefähr so ging:

[KONTENLEN]
BLZ(die betroffene Bankleitzahl der Dt. Bank)=11
Bei mehreren Filialen auch mehrere Einträge.

Mir ist irgendwie, dass das heute aber nicht mehr dort geregelt wird, sondern in einer anderen Ini-Datei - vermutlich der hbciinf.ini

Eigentlich sollte hier der Support des Herstellers (über die Sparkasse) eigentlich eine Antwort haben, davon sind ja einige Kunden/Konten dann betroffen. Falls man hier nicht weiterkommt, kann ich mich auch schlau machen - bitte melden

Vorher auch nochmal händisch mit z.B. Editor die orginal STA-Datei öffnen und wirklich kontrollieren, was geliefert wird:

Zeile:
:25:BLZ/Kontonummer

Das neue Kontoauszugsformat camt.52 und camt.53 kann SFirm verarbeiten, aber ob die Deutsche Bank das liefern kann, weiss ich nicht auch funktioniert das - bisher nur bei Einsatz von EBICS und muss sowohl in der Bank freigeschaltet werden und in SFirm eingestellt werden.

Welches Verfahren wir denn genutzt?

Schönen Gruß

Das Problem mit der MT-940 Spezifikation ist, dass anhand der Spezifikation eine eindeutige Interpretation der Daten unmöglich ist. Nur wenn man weiß, was die Banken genau einstellen hat man eine Chance das richtig zu interpretieren.

Im Konkreten Fall ist z.B. nicht klar, wo die Kontonummer aufhört und die DeuBa spezfischen Währungsziffern beginnen. Ich habe auch schon Felder :25: gesehen die vorne noch ein paar zusätzliche Nullen haben.

In besseren Fällen liefern die Banken im Feld :25: die Währung wenigstens als ISO-Code, also z.B.

:25:10000000/1234567890EUR

Das ist dann wenigstens relativ eindeutig interpretierbar.

Insgesamt ist die deutsche MT-940 Spezifikation aus Sicht eines Informatikers aber eine einzige Katastrophe.

Guten Morgen

Leider ist es nach wie vor ein Unterschied - ob man sich die Spezifikation des MT940 (Kontoumsätze) anschaut oder die eigentlich generell geltende Spezifikation für DEUTSCHE Kontonummern.

Im DTAUS Format im DFÜ-Abkommen steht z.B. :

"Kontonummer =
Empfänger/Absender Kunde, max. 10 Stellen (rechtsbündig, nicht belegte Stellen Null). Über dieses Konto wird der Gegenwert verrechnet."

Im MT940 kann das Feld aber viel länger belegt werden, allein schon um ausländische Angaben verarbeiten zu können...
Würde sich die Deutsche Bank an die "erste" Spezifikation halten, könnte also auch im MT940 Format normal keine 11-stellige Nummer landen - IBAN und BIC, Währungsangaben... usw. wären aber konform.
Rein nach MT940 ist auch eine 11-stellige Kto-Nr. korrekt...

Auch wenn Wikipedia mit Vorsicht zu genießen ist unter dem Stichpunkt "Kontonummer"*g*:
"In Deutschland ist der Zahlungsverkehr durch das DFÜ-Abkommen vereinheitlicht; externe Kontonummern bestehen aus bis zu zehn Dezimalziffern. Falls nötig, kann man bei niedrigen Kontonummern führende Füllnullen verwenden..."

Hallo,

eine blöde Frage vorab - bei der 11-stelligen Konto-Nummer handelt es sich aber nicht um Konten mit führenden Nullen, oder?

Die Änderung in einer Ini-Datei konnte ich bisher nicht mehr rekonstruieren, k. A. ob das nicht mehr geht...

Eigentlich fragt Sfirm doch bei jeder nicht zuzuordnenden MT940-Datei(abweichende oder nicht vorhandene Kto-Nr.) genau 1 mal, was mit den Umsätzen gemacht werden soll.
Man kann diese Umsätze dann manuell einem Konto zusortieren oder ignorieren, wobei dann der Hinweis auf das nicht vollständige Einlesen bleibt.
In meinen Augen heisst dass, pro 11-stelligem Konto einmal die Zuordnung machen + bei jedem neuen 11-stelligen Konto auch einmal.
Anschliessend werden die Umsätze/Auszüge für diese Konten doch zukünftig automatisch eingelesen (oder erinnere ich mich da falsch).


EDIT: Mein vorgeschlagenes "Experiment", dass hier stand, funktioniert nicht richtig, daher wieder gelöscht...