nemiah
Überlanger V-Zweck?
Hallo nochmal. Ich habe ein seltsames Problem. Die KSK Köln liefert neuerdings mitunter ellenlange V-Zwecke., zum Beispiel beim Monatsabschluss.
Im Online-Banking wird das als eine Buchung dargestellt.
Wenn ich die Kontoauszüge aber mit
$getStatement = GetStatementOfAccount::create($this->getSepaAccount(), $from, $ $this->_FinTsClass->execute($getStatement);
und schlussendlich mit
$transactions = $statement->getTransactions();
abrufe, wird der V-Zweck "umgebrochen".
Heißt: getMainDescription(), getDescription1() und getDescription2 hören in der Transaction mit dem langen V-Zweck einfach auf und es wird eine zweite Transaction erzeugt mit Amount = 0.00, der die Fortsetzung des V-Zweck enthält.
Hat das seinen Grund in FinTS oder in phpFinTS? Und kann ich das abfangen?
Danke!
Kannst du evtl. die MT490 Rohdaten des Abrufs zur Verfügung stellen?
Also $statement->getRawMT940()
Die persönliche Daten habe ich mit $-Zeichen ersetzt. Womöglich habe ich auch ein paar Meta-Daten erwischt. Aber die Struktur dürfte klar sein. Auch in den Rohdaten scheinen die 0,00 EUR Einträge vorhanden zu sein.
:20:STARTUMSE
:25:37050299/0000$$$$$$
:28C:00000/001
:60F:D200227EUR$$$$$$$
:61:2002280228DR$$$$$$N023NONREF
:86:805?00ABSCHLUSS?106666?20Abrechnung 27.02.2020?21Information
zur Abrechnung?22Kontostand am 27.02.2020?$$$$$-?24 ------
--------?25Abrechnungszeitraum vom 01.?2602.2020 bis 27.02.2020?2
7$$$$$$-?28Berichtigung der Abrechnung?29 Vorpe
riode?60$$$$$ bis?
6227.02.2020
:61:2002280228DR0,00N023NONREF
:86:805?00ABSCHLUSS?106666?20$$$$$$$Berichtigung der Abrechnung?26 Vorperiode?27$$$$$
:61:2002280228DR0,00N023NONREF
:86:805?00ABSCHLUSS?106666?20Entgelte vom 31.01.2020 bis?21 27.02
.2020 $$$-?22Kontof�hrung $$$$$ Geldautomat $
:61:2002280228DR0,00N023NONREF
:86:805?00ABSCHLUSS?106666?20Gutschrift $$$$$ -------
-------?22Abrechnung 27.02.2020 vor?23Steuer $$$$-?24Umsatzsteu
er 19% auf $$$$?25- USt. $$$-?26 --------------?27Abrechnung
27.02.2020 $$$?280-?29Kontostand/Rechnungsabschlu?60ss am 27.02
.2020 $$$$$$$?61-
:61:2002280228DR0,00N023NONREF
:86:805?00ABSCHLUSS?$$$$$?20Rechnungsnummer. $$$$$
Wenn ich das durch den Parser laufen lasse, werden mir 5 Transaktionen angezeigt. Wie viele sollten es deiner Meinung nach sein?
Die erste hat zumindest in der von dir geposteten Darstellung genau 6 Zeilen hinter :86: bevor sie abbricht. Und hier steht, dass mehr nicht geht. Möglicherweise trickst die Bank deshalb?
Was bedeuten diese ?26?
Unabhängig von diesem Bug:
Im geparsten SVWZ steht sowas wie "Abrechnung 27.02.2020 vorSteuer". Da fehlt eine Leerstelle. Mir ist das schon öfter aufgefallen, dass manchmal der Whitespace kaputt ist. Ist das ein generelles Problem mit MT940, oder ist unser Parser kaputt?
Die erste hat zumindest in der von dir geposteten Darstellung genau 6 Zeilen hinter
:86:bevor sie abbricht. Und hier steht, dass mehr nicht geht. Möglicherweise trickst die Bank deshalb?
Jetzt wo du es sagst, das wird es sein. Da es 0er Buchungen eigentlich nicht geben kann, und es im Kontoauszugdruck dann einigermaßen richtig aussieht. Also man könnte es rein theoretisch einbauen, dass 0 Euro Buchungen der vorherigen Buchung zugeschlagen werden.
Was bedeuten diese ?26?
26 ist die sechste Zeile á 27 Zeichen des Verwendungszwecks. Siehe https://www.kontopruef.de/mt940s.shtml
Im geparsten SVWZ steht sowas wie "Abrechnung 27.02.2020 vorSteuer". Da fehlt eine Leerstelle. Mir ist das schon öfter aufgefallen, dass manchmal der Whitespace kaputt ist. Ist das ein generelles Problem mit MT940, oder ist unser Parser kaputt?
Es ist nicht definiert und auch nicht feststellbar ob nach einer voll gefüllten Zeile ein Leerzeichen kommt oder nicht. Also hat man entweder mal ein Leerzeichen zuwenig oder mal eins zuviel mitten in einem Wort. Das Problem wird verschlimmert, wenn die Verwendungszweck von der Initiierenden Bank auf Art und Weise X auf die Zeilen aufgeteilt wird und von der Empfängerbank auf Art und Weise Y. Mit anderen Wort MT490 war nie dafür gedacht wie es hier verwendet wird.
Das sieht man auch daran, dass es selbst im XML CAMT Format zu solchen Fällen kommt, es also schon bei der Bank so ankommt.
Da es 0er Buchungen eigentlich nicht geben kann, und es im Kontoauszugdruck dann einigermaßen richtig aussieht. Also man könnte es rein theoretisch einbauen, dass 0 Euro Buchungen der vorherigen Buchung zugeschlagen werden.
Zumindest bei meinen Banken gibt es 0-Euro-Buchungen, die für sich alleine stehen. Ich bekomme regelmäßig stolze 0,00€ als Zinsen überwiesen (denn auf den meisten Girokonten gibt es ja mittlerweile nur noch 0% Zinsen). Auch das ist dann so ein "Abschluss" wie im Beispiel oben.
Da es 0er Buchungen eigentlich nicht geben kann, und es im Kontoauszugdruck dann einigermaßen richtig aussieht. Also man könnte es rein theoretisch einbauen, dass 0 Euro Buchungen der vorherigen Buchung zugeschlagen werden.
Zumindest bei meinen Banken gibt es 0-Euro-Buchungen, die für sich alleine stehen. Ich bekomme regelmäßig stolze 0,00€ als Zinsen überwiesen (denn auf den meisten Girokonten gibt es ja mittlerweile nur noch 0% Zinsen). Auch das ist dann so ein "Abschluss" wie im Beispiel oben.
Stimmt wohl 😁
@kvogelsa Vlt kann die KSK ja XML Umsatzabruf?
Danke für Eure Kommentare. Ich werde den XML Abruf mal testen.
Wäre der XML-Abruf generell vorzuziehen? Und: Deiner Frage entnehme ich, dass nicht jede Bank ihn unterstützt, richtig?
Wäre der XML-Abruf generell vorzuziehen? Und: Deiner Frage entnehme ich, dass nicht jede Bank ihn unterstützt, richtig?
Aus meiner Sicht auf jeden Fall vorzuziehen, da die Daten dort strukturiert übermittelt werden und nicht in den Verwendungszweck reingeprügelt werden wie bei MT490.
Unterstützen leider nicht alle Banken. 😞
Ich habe gerade den XML-Abruf versucht. (einfach statt "\Fhp\Action\GetStatementOfAccount" "\Fhp\Action\GetStatementOfAccountXML" verwendet).
Das brachte mir ein
"status": 500,
"detail": "Invalid response from server"
ein. Kann ich daraus schließen, dass die KSK XML nicht unterstützt?
Wenn die Bank es grundsätzlich nicht unterstützt, dann sollte kommen:
The bank (or the given account/user combination) does not allow this type of request.
Status 500 klingt nach Internal Server Error bei der Bank? Kannst du die Raw Response von der Bank angucken?