Hallo Zusammen,

habe ein Problem mit SFirm 2.5 und der Deutschen Bank.
In der STA-Datei die von der Deutschen Bank geliefert wird, sind die Kontonummern 11.-stellig.
Sfirm kann nur 10.-stellige Nummer verarbeiten.
Im Finanzstatus erscheint die Meldung das MT 940 Dateien nicht eingelesen wurden da es kein passendes Konto in Sfim gefunden wurde.
Klar kann ich, die Zuordnung in Sfirm manuell erledigen.
(Auftraggeber-->Konto anlegen-->und Umsätze dem Konto zuordnen.)
Problem an der Sache ist, wenn es nur hin und wieder ein Konto ist, ist es kein Problem, nur bei mehreren Hundert ist das einfach ein unmöglicher Arbeitsaufwand.
Kennt jemand zufällig eine Lösung?
Starfinanz kann mir keine Lösung anbieten.

Gruß
Nico

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...

Kann SFirm nicht.

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...

Man kann in SFirm die Bank nicht in dem Sinne konfigurieren.
Man legt nur die Zugangsdaten an und verknüpft sie mit dem Konto. (Ebics oder Hbci)

Die Sta Datei manuell anpassen ist auch zu aufwendig nicht praktikabel.

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!

@obnutzer

Die Konten.ini ist mir bekannt, in der *ini wird die Zuordnung geregelt.
Mir geht es um die Kontenanlage.
Suche nach einer Lösung, dass die Konten, wie bei einem anderen Kreditinstitut üblich, über die Meldung im Finanzstatus antomatisch angelegt werden können.

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.

Wenn es sich um wenige Konten handeln würde, ok.
Aber wie ich oben schrieb, es sind mehrere hundert.
Und es kommen ständig mehrere hinzu.

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?

Die 11.Stelle regelt die Kontoart.
Hatte bei der Deutschen Bank angefragt, ob das Auszugsformat geändert werden kann. Geht leider nicht.

Die Sache mit einer anderen Software ist die, wir sind die Lizenzgeber.

Möchte ungern den Kunden verlieren, was leider darauf hinaus läuft, wenn das Problem nicht gelöst werden kann.

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?

Die Kontonummer ist 9stellig, die 10. & 11. Stelle definiert die Währung:
https://www.db-bankline.deutsc…re2002.pdf

Hier mal die MT940- Formatbeschreibung einer Sparkasse.:
https://www.ksk-koeln.de/Datenstruktur_MT940_Swift.pdfx
Darin ist ausdrücklich auch die Währungskennzeichnung im Feld 25 beschrieben. Somit ist es ja wohl eher in SFIRM unsauber programmiert, zumal andere Programme problemlos damit umgehen können.


Ich geh mal davon aus, dass diese Frage nicht erst gemeint ist.


M.W. nein

Tschau
Majo

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ß

Hallo Leute,

wenn ihr euch Spezifikationen oder Veröffentlichungen um die Ohren haut, dann nehmt bitte die, die offiziell von der Deutschen Kreditwirtschaft für Deutschland eröffentlicht wurden: Anlage 3 des DFÜ Abkommens

Hier steht in der aktuellen Version 2.6 zur Kontonummer im Datensatz:
„:25:“
x..35 bis 35 Stellen
BLZ/Konto-Nr. oder BIC/Konto- oder IBAN wobei Konto-Nr. = max. 23 Stellen (ggf. mit Währung)
BLZ = 8-stell. Bankleitzahl
BIC = max. 11-stell. SWIFT-Code

Instinktiv hätte ich auch gesagt was für ein Unsinn. Kontonummern sind doch immer 10 stellig. Aber die DeuBa scheint sich hier an die Spezifikation den MT940 zu halten.

Viele Grüße

Holger

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.

eben: "falsche" Perseptive: von Kaufleuten für Kaufleute und was interessieren mich die anderen...

Deshalb sind in den ZV Prog ini-Datein von Vorteil in denen bankenindividuell die "Konten-Masken" gepflegt werden können. Der Hersteller darf gerne die schon bekannten "Standards" einsteuern - aber die Möglichkeit der späteren schnellen Anpassung ist von Vorteil.

Od

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..."

Diese ganzen Theorien sind ja nun klar. Dass die DB das so macht und auch so machen darf, es aber trotzdem eher hinderlich statt förderlich ist ist auch klar.
Wie kann man nun die Pflege der INI für SFirm automatisieren bei neuen Konten? Makroprogrammierung?

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...