nemiah / phpfints Goto Github PK

Vorweg: das Problem tritt bei uns nur bei der BTV-Bank auf (BLZ: 72012300) - die anderen Banken gehen einwandfrei. Außerdem geht der Abruf mit der Ursprungsversion von diesem Fork auch ohne Fehlermeldung.

Meldung (Zugangsdaten stimmen):
Request Failed: Die Nachricht enthält Fehler. (TRE) (9050); Anmeldung nur noch mit Alias oder VR-Kennung zulässig (TRP) (9150); Dialog abgebrochen (TRE) (9800); Auftrag abgelehnt. (TRE) (9340).

Ich konnte es soweit eingrenzen: FinTs.php - Zeile 142
$dialog->endDialog();

Der endDialog wird wohl ausgeführt bevor alle Dialoge beendet sind (alternativ: der Init danach geht schief). Jedenfalls geht der weitere Dialog nach dem Aufruf von endDialog(); nicht weiter.

Wenn ich diese Zeile auskommentiere dann Läuft der Abruf komplett erfolgreich durch.
Ich kenne jedoch die Architektur der Klasse zu wenig um die eigentliche Ursache näher einzugrenzen.

Hoffe es ist ok wenn ich hier auf Deutsch schreibe. Kann es auch auf Englisch schreiben wenn gewünscht.

Vielen Dank für deine Arbeit an diesem vielversprechenden Fork 😄.
mschindler83/fints-hbci-php scheint mir nicht mehr weitergeführt zu werden, daher halte ich es für sinnvoller Verbesserungen hier zu pflegen.

Da der Server unserer Bank sich manchmal sehr viel Zeit beim Antworten lässt, muss ich den Timeout auf mehr als 30 Sekunden erhöhen. Dies ist momentan nur mit einigem Copy und Paste möglich.

Am einfachsten wäre es die Methode \Fhp\Adapter\Curl::connect auf protected zu ändern. Dann kann man die Klasse bzw. Methode ableiten und den Timeout setzen. Alternativ wäre natürlich ein neuer Parameter $timeout in den Klassen FinTs und Curl noch besser.

Der folgende Fall wird nicht korrekt geparst:

:86:171(...)?20EREF+TedyHz.1568781920
13439?210?22KREF+(...)

EREF müsste "TedyHz.1568781920134390" sein, die "0" am Ende wird jedoch abgeschnitten.

Ich schlage vor, die Zeile

zu

if ($m[2] != '') {

zu ändern.

Hey nemiah, great work on this module. If you could help me out for a moment: some classes don't seem to be included anymore. E.g. SEPADirectDebitBasic. I first got the error

Uncaught Error: Class 'nemiah\phpSepaXml\SEPADirectDebitBasic' not found

and I then realized that I cannot find it myself.

Or maybe I'm just doing something really wrong.
Regards

Beim Aufruf von "getSEPAAccounts" erhalten wir folgende Meldung:

Request Failed: Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800); Falsche Segmentzusammenstellung (9110)

Eine gültige Registernummer liegt vor. Woran könnte es liegen?

Weiß jemand, ob es in der Response irgendein einheitliches Merkmal gibt, dass eine TAN erforderlich ist? Oder ist das eine eigene Abfrage im Vorhinein?

Die Sparkasse läuft bei den Umsätzen ohne TAN durch, die Postbank antwortet schon bei getSEPAAccounts mit Auftrag ausgeführt. (0020); BPD nicht mehr aktuell. Aktuelle Version folgt. (1040); Meldung unterstützter Ein- und Zwei-Schritt-Verfahren (3920); Starke Authentifizierung ab dem 2019-09-08 erforderlich. (3075); Gewähltes Zwei-Schritt-Verfahren nicht unterstützt. (9200); Teilweise fehlerhaft. (9050) in verschiedenen Severities und es kommt zu einer FailedRequestException. Zumindest unter https://wiki.windata.de/index.php?title=HBCI-Fehlermeldungen konnte ich aber keinen Code davon als eindeutig identifizieren.

Beim Abruf der Kontoumsätze bei Sparda, kommt die Fehlermeldung

Der gewünschte Auftrag kann nicht verteilt signiert werden.

Was mir leider nicht viel sagt, hat einer eine Idee?

[info] HKKAZ (statement of accounts) initialize
[info] Start date: 2019-10-28
[info] End date : 2019-10-28
[debug] >
HNHBK:1:3+000000000447+300+[dialogid]+3'
HNVSK:998:3+PIN:2+998+1+1::[systemid]+1:20191028:103010+2:2:13:@800000000:5:1+280:[blz]:[xxx]:V:0:0+0'
HNVSD:999:1+@234@HNSHK:2:4+PIN:2+996+4805100+1+1+1::[systemid]+1+1:20191028:103010+1:999:1+6:10:16+280:[blz]:[xxx]:S:0:0'
HKKAZ:3:5+[xxx]::280:[blz]+N+20191028+20191028++'
HKTAN:4:6+4+HKIDN++++N++++++'
HNSHA:5:2+4805100++[xxx]''
HNHBS:6:1+3'
[debug] <
HNHBK:1:3+000000000561+300+[dialogid]+3+[dialogid]:3'
HNVSK:998:3+PIN:2+998+1+2::[systemid]+1:20191028:113010+2:2:13:@800000000:5:1+280:[blz]:[xxx]:V:0:0+0'
HNVSD:999:1+@317@HNSHK:2:4+PIN:2+996+4805100+1+1+2::[systemid]+1+1:20191028:113010+1:999:1+6:10:16+280:[blz]:[xxx]:S:0:0'
HIRMG:3:2+9050::Die Nachricht enth?lt Fehler.+3905::Antwortliste konnte nicht signiert werden.'
HIRMS:4:2:3+9010::Der gew?nschte Auftrag kann nicht verteilt signiert werden.'
HNSHA:5:2+4805100''
HNHBS:6:1+3'

Uncaught TypeError: Return value of testLogger::log() must be an instance of void, none returned

Was mach ich falsch?

hi guys,

can you please create a new github release with the latest stuff (or change composer require nemiah/php-fints to composer require nemiah/php-fints:dev-master in readme).

thanks.

Hey,
besteht die Möglichkeit, diese Funktionalität mit einzubinden?

Ich könnte dabei auch behilflich sein hinsichtlich der Programmierung und Testung. Vielleicht lässt sich dies gemeinsam realisieren?

Beim Aufrufen der FinTs::getSaldo()-Funktion werfen die Sparkassen folgenden Fehler:

[Fhp\Dialog\Exception\FailedRequestException]
  Request Failed: Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet.(Die angegebene Bankreferenz/
  Dialog-ID ist nicht gültig.) (9010); Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800)

Wenn man bei DKB Umsätze für mehrere Monate abholt, wird eine TAN abgefragt. Beim Senden der TAN ist das Segment HKTAN fehlerhaft. Hier die Log:

HNHBK:1:3+000000000434+300+838777019240=915521646312BLDW=+4'
HNVSK:998:3+PIN:2+998+1+1::JjfQADhssW0BAAAaHkKx0lkXrAQA+1:20191009:130913+2:2:13:@8@00000000:5:1+280:12030000:1234567890:V:0:0+0'
HNVSD:999:1+@213@HNSHK:2:4+PIN:2+921+6094421+1+1+1::JjfQADhssW0BAAAaHkKx0lkXrAQA+1+1:20191009:130913+1:999:1+6:10:16+280:12030000:1234567890:S:0:0'
HKTAN:3:6+2++++6446-10-09-19.08.47.211169++N++++'
HNSHA:4:2+6094421++123456:123456'
'
HNHBS:5:1+4'


HNHBK:1:3+000000000519+300+838777019240=915521646312BLDW=+4+838777019240=915521646312BLDW=:4'
HNVSK:998:3+PIN:2+998+1+2::JjfQADhssW0BAAAaHkKx0lkXrAQA+1:20191009:190914+2:2:13:@8@00000000:5:1+280:12030000:1234567890:V:0:0+0'
HNVSD:999:1+@265@HNSHK:2:4+PIN:2+921+6094421+1+1+2::JjfQADhssW0BAAAaHkKx0lkXrAQA+1+1:20191009:190914+1:999:1+6:10:16+280:12030000:1234567890:S:0:0'
HIRMG:3:2+9050::Die Nachricht enthält Fehler.'
HIRMS:4:2:2+9110:7:Ungültige Auftragsnachricht?: Unbekannter Aufbau.'
HNSHA:5:2+6094421'
'
HNHBS:6:1+4'

So funktioniert es:

HNHBK:1:3+000000000429+300+869099164116=310616646312BLDW=+4'
HNVSK:998:3+PIN:2+998+1+1::NCrxADhssW0BAAAaHkKx0lkXrAQA+1:20191009:131721+2:2:13:@8@00000000:5:1+280:12030000:1234567890:V:0:0+0'
HNVSD:999:1+@208@HNSHK:2:4+PIN:2+921+7593837+1+1+1::NCrxADhssW0BAAAaHkKx0lkXrAQA+1+1:20191009:131721+1:999:1+6:10:16+280:12030000:1234567890:S:0:0'
HKTAN:3:6+2++++7760-10-09-19.16.57.711109+N'
HNSHA:4:2+7593837++123456:123456'
'
HNHBS:5:1+4'

HNHBK:1:3+000000026628+300+869099164116=310616646312BLDW=+4+869099164116=310616646312BLDW=:4'
HNVSK:998:3+PIN:2+998+1+2::NCrxADhssW0BAAAaHkKx0lkXrAQA+1:20191009:191721+2:2:13:@8@00000000:5:1+280:12030000:1234567890:V:0:0+0'
HNVSD:999:1+@26372@HNSHK:2:4+PIN:2+921+7593837+1+1+2::NCrxADhssW0BAAAaHkKx0lkXrAQA+1+1:20191009:191721+1:999:1+6:10:16+280:12030000:1234567890:S:0:0'
HIRMG:3:2+3060::Bitte beachten Sie die enthaltenen Warnungen/Hinweise.'
HIRMS:4:2:3+0020::Der Auftrag wurde ausgeführt.+0020::Die gebuchten Umsätze wurden übermittelt.+3040::Es liegen weitere Informationen vor.:3855-10-09-19.17.21.638552'
HITAN:5:6:3+2++7760-10-09-19.16.57.711109'
HIKAZ:6:5:3+@25923@

Der Unterschied liegt im HKTAN-Segment

HKTAN:3:6+2++++6446-10-09-19.08.47.211169++N++++'
HKTAN:3:6+2++++7760-10-09-19.16.57.711109+N'

Bei der GLS-Bank enthalten die Bezeichner der Aufsetzpunkte ("Touchdowns") auch "+", welches ein reserviertes Zeichen ist.

In der Methode FinTs::getStatementOfAccount muss der Parameter $touchdowns[HKKAZ::NAME] für den $this->createStateOfAccountMessage Aufruf durch
$this->escapeString($touchdowns[HKKAZ::NAME]) ersetzt werden.

Siehe: mschindler83/fints-hbci-php#93 (comment)

Bereits aus mehreren Quellen wurde berichtet, dass aktuell bei der Postbank keine Umsätze abgeholt werden können.

Es scheint daran zu liegen, dass die Postbank die HBCI-Zugänge vorerst abgeschaltet hat.
Da wir darauf keinen Einfluss haben, bitte ich darum, diesbezüglich keine weiteren issues zu erstellen.

Liebe Grüße
Nena

Seit kurzem unterstützen die Server für einige Sparkassen nur TLSv1.2
https://www.ssllabs.com/ssltest/analyze.html?d=banking-bw3.s-fints-pt-bw.de

Gibt es einen Grund, warum phpFinTS auf SSLv1 eingeschränkt ist?

Response::getSummaryBySegment only searches for the first occurrence of the segment. At least Postbank responses contain more than one HIRMS elements, though. Changing the method as below fixes this issue.

protected function getSummaryBySegment($name)
{
	if (!in_array($name, array('HIRMS', 'HIRMG'))) {
		throw new \Exception('Invalid segment for message summary. Only HIRMS and HIRMG supported');
	}

	$result = array();
	foreach ($this->findSegments($name) as $segment) {
		$segment = $this->splitSegment($segment);
		array_shift($segment);
		foreach ($segment as $de) {
			$de = $this->splitDeg($de);
			$result[$de[0]] = $de[2];
		}
	}

	return $result;
}

Sorry for not making a pull request but my own fork of mschindler83/fints-hbci-php would need some serious refactoring in advance.

Dank PSD2 müssen viele Banken jetzt/bald auch beim Login eine TAN verlangen. Manche verlangen sie immer, andere nur manchmal. Im Fall der Consorsbank ist die TAN nur von der Uhrzeit abhängig, kann also ohne Challenge generiert werden bevor die phpFinTS-Bibliothek überhaupt das erste Mal aufgerufen wird. Bei anderen Banken könnte das anders sein. Denkbar wäre zum Beispiel nur ein Bestätigen auf dem Smartphone (so ist es bei der DKB, wenn man es entsprechend einrichtet), oder die Eingabe eines Challenge-Codes bevor die TAN generiert wird.

Mit der Consorsbank erhalte ich aktuell die Meldung "HIRMS:4:2:4+0020::Informationen fehlerfrei entgegengenommen.+3050::BPD nicht mehr aktuell. Aktuelle Version folgt.+3920::Zugelassene Ein- und Zwei-Schritt-Verfahren für den Benutzer:900:999" aus syncDialog(). Dann versucht phpFinTS einfach, seine normale Anfrage zu schicken, woraufhin der Server verständlicherweise abbricht mit "HIRMG:2:2:+9800::Der Dialog wurde abgebrochen.+9120::Unerwartete Nachricht."

Die Umstellung scheint noch nicht abgeschlossen: https://twitter.com/consorsbank/status/1170984484960968704

I use an IDE with an interactive debugger in order to figure out how the bank communicates. In the variables view of the debugger, the presentation of messages and segments are pretty much useless because their internal storage format is just a couple of arrays (it mirrors the FinTS wire format).

The segment creation logic becomes more cumbersome due to this, e.g. here.

The parsing logic and assignment to human-readable identifiers is only done in the getters (e.g. getEncodedData() knows that the encoded data is stored in the 0-th data element. That same information is hard-coded redundantly in the constructor and in setEncodedData(). More parsing logic is scattered at several call sites, e.g. getSupportedTanMechanisms knows that it needs to look in the element with ID 3920 inside the segment HIRMS but there is not even a HIRMS class.

I propose to (1) have one class per segment version, e.g. HKTANv6 and (2) use plain fields inside, e.g. /** @type string */ public $processID;. This will require some mapping to the wire format, as each field needs to declare its position (and ideally also whether it's required or not). A potential solution could be annotations, e.g. /** @type string @DE(5) */.

Please let me know what you think.

Hi,
seit der SCA/PSD2 Umstellung gestern erhalte ich trotz Angabe meiner Registrierungs- und Versionsnummer seitens der Sparkasse die Meldung:

Request Failed: Die Nachricht enthält Fehler. (9050); Banking-Programm nicht PSD2-fähig, bitte aktualisieren. (9075); Dialog abgebrochen (9800); Ungültige Auftragsnachricht? (9340)

setTANMechanism habe ich auch korrekt gesetzt.

Jemand eine Idee?

Momentan wird jede Antwort vom Server in Connection.php via

return iconv('ISO-8859-1', 'UTF-8', $this->adapter->send($message));

nach UTF-8 konvertiert. Dies führt zu Kodierungsfehlern, wenn die Payload schon UTF-8 ist, wie z.B. Kontoumsätze im CAMT XML Format.

Meine erste Idee dies zu fixen wäre, die allgemeine Konvertierung (siehe oben) rauszunehmen und in der Methode Response::findSegments abhängig nach Segment zu kodieren.

$split = explode(':', $segment, 2);

if ($name != 'HICAZ') {
    $segment = iconv('ISO-8859-1', 'UTF-8', $segment);
}

Ich kann nicht bestätigen, dass die DKB funktioniert, obwohl sie ja bei COMPATIBILITY.md gelistet ist.
Ich erhalte folgenden Fehler:
"Request Failed: Pflichtfeld nicht gefunden (9160); Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800)".

Mach ich etwas falsch?

Die Abhängigkeit zu nemiah/php-sepa-xml wird ja nur für die Beispiele benötigt.

Könnte man die Abhängigkeit in der composer.json in suggest verschieben?

Aufgrund minimum-stability = stable, lässt sich nemiah/phpFint momentan nur installieren wenn man auch

"nemiah/php-sepa-xml": "dev-master@dev"

mit angibt.

Guten Tag,

die Sparkasse liefert seit 13.10.2019 andere Daten. Bisher:

168?00ECHTZEIT-GUTSCHRIFT?**?20SVWZ+**description**?30**bankCode**?31**IBAN**?32**name**

neu:

168?00ECHTZEIT-GUTSCHRIFT?**?00SVWZ+**description**?30**bankCode**?31**IBAN**?00**name**

In bookingText steht jetzt auf einmal der Name, description1 + description2 ist leer.

Dürfte an den ?00 liegen. Leider gibt es je nach Datenmenge eine unterschiedliche Anzahl von ?00.

MT940, parseDescription ist wohl zuständig.

Bin etwas ratlos, mir fällt keine gescheite Lösung ein.

@nemiah 61:1906290701 (bzw: 61:1812310102 61:1901011228)
19 = Jahr
0629 = 29.06. (valutaDate)
0701 = 01.07. (bookingDate)

$year = substr($transaction, 0, 2);
$valutaDate = $this->getDate($year . substr($transaction, 2, 4));

$bookingDate = substr($transaction, 6, 4);

// if valuta date is earlier than booking date, then it must be in the new year.
$year = substr($transaction, 2, 2) < substr($transaction, 6, 2) ? --$year : $year;

if (substr($transaction, 2, 2) == '12' && substr($transaction, 6, 2) == '01') {
$year++;
} elseif (substr($transaction, 2, 2) == '01' && substr($transaction, 6, 2) == '12') {
$year--;
}
$bookingDate = $this->getDate($year . $bookingDate);

Wenn ich richtig schaue, wird aus:

61:1906290701
29.06.19 und 01.07.18 = falsch

61:1812310102
31.12.18 und 02.01.19 = richtig

61:1901011228
01.01.19 und 28.12.17 = falsch

ohne

// if valuta date is earlier than booking date, then it must be in the new year.
$year = substr($transaction, 2, 2) < substr($transaction, 6, 2) ? --$year : $year;

würde es passen

Originally posted by @djm03 in #43 (comment)

Die Methode scheint rausgeflogen zu sein?
Gibts denn noch eine möglichkeit eine Transaktion eindeutig zu identifizieren?

All FinTS products are required to register for a product number, which have to be sent in the dialog:

https://www.hbci-zka.de/register/register_faq.htm

FinTS integration will be unusable after 2019-08-01!

Are there plans to integrate the possibility to set the product ID into the library?

Ich bin auf diesen Fork aufmerksam geworden, weil seit einigen Tagen/Wochen die "altbekannte" FinTs-Lösung nicht mehr wie gewünscht funktioniert. Ich habe hier herausgelesen, dass mit diesem Fork bereits eine Aktualisierung erarbeitet wird.
Gibt es zu dem bisherigen Entwicklungsstand (TAN-Verfahren) bereits eine Dokumentation?

Hi nemiah,

thanks for looking into it and get it working with mtan. I just set up all the stuff and tried your sample directDebit.php file. For me it's not working. It recognizes no 901 tan mechanism, but a 942 tan mechanism. Do you have a list which number represents which mechanism? After that the communication failes.

Do you have a skype contact or email address? I would like to provide some more information for the key version. I'm getting a complete trace of the communication with the banking server but I don't want to put this trace online here.

Cheers
Andi

Dear all,

as Phillipp91 wrote: "Ab dem 14.09.2019 stellen die Mehrzahl der Kreditinstitute neben der FinTS-Schnittstelle eine weitere Schnittstelle nach den Regularien der PSD2-Richtlinien bereit. Zahlungsauslösedienste und Kontoinformationsdienste bedürfen dann einer Zulassung der deutschen (BaFin) oder einer anderen europäischen Regulierungsbehörde. Detaillierte Hinweise sowie Informationen zu Testzugängen finden sie auf den Web-Seiten der Institute, bzw. deren IT-Dienstleister oder unter nisp.online. Die bisherige FinTS-Schnittstelle darf durch diese Dienste bei Zugriffen auf Zahlungskonten dann nicht mehr genutzt werden."

Do we have any chance to get our implementations running again? With the lastest version from nemiah calling "Fhp\FinTs->getSEPAAccounts( )" I get today: "Fatal error: Uncaught exception 'Fhp\Dialog\Exception\FailedRequestException' with message 'Request Failed: Pflichtfeld nicht gefunden (9160); Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800)' [...]"

Hoping for the best,

Martin

Hallo Nena,

jetzt scheint es auch bei den Volksbanken zur Umstellung zu kommen. Seit heute Mittag bekommen wir die Meldung:

Die Nachricht enthält Fehler. (9050); Starke Kundenauthentifizierung notwendig. (9075); Dialog abgebrochen (9800); Auftrag abgelehnt. (9340)

Ich versuche mich jetzt mal schlau zu machen - oder gibt es bereits einen Lösungsansatz?

Viele Grüße
Christian

Tagchen,

ich benutze Deinen Code (dev-master) und sage mal vorerst besten Dank für das Weiterentwickeln vom mschindler83-Code.

Ich rufe im Moment folgende Banken problemlos mit meinem Programm ab: Volksbank Karlsruhe & DKB

ING-DiBa will noch nicht so recht.
Kannst Du mit dem Log etwas anfangen?

SYNC initialize
> HNHBK:1:3+000000000387+300+0+1
HNVSK:998:3+PIN:1+998+1+1::0+1:20190927:185439+2:2:13:@8@00000000:5:1+280:50010517:**********:V:0:0+0
HNVSD:999:1+@224@HNSHK:2:4+PIN:1+999+5717716+1+1+1::0+1+1:20190927:185439+1:999:1+6:10:16+280:50010517:**********:S:0:0
HKIDN:3:2+280:50010517+**********+0+1
HKVVB:4:3+0+0+0+*************************+1.0
HKSYN:5:3+0
HNSHA:6:2+5717716++**********

HNHBS:7:1+1

< HNHBK:1:3+000000001602+300+000006JJKLDOR5OOS9OR167VMC9VMV+1+000006JJKLDOR5OOS9OR167VMC9VMV:1
HNVSK:998:3+PIN:1+998+1+2::0+1+2:2:13:@8@        :6:1+280:50010517:**********:V:0:0+0
HNVSD:999:1+@1391@HIRMG:2:2:+3060::Teilweise liegen Warnungen/Hinweise vor.
HIRMS:3:2:3+0020::Angemeldet.
HIRMS:4:2:4+0020::Informationen fehlerfrei entgegengenommen.+3050::BPD nicht mehr aktuell. Aktuelle Version folgt.+3920::Zugelassene Ein- und Zwei-Schritt-Verfahren für den Benutzer:900
HIRMS:5:2:5+0020::Die Synchronisierung der Kundensystem-ID war erfolgreich.
HIBPA:6:3:4+7+280:50010517+ING-DiBa+0+1+220:300+200
HIKOM:7:4:4+280:50010517+1+3:https?://fints.ing-diba.de/fints/
HISPAS:8:1:4+1+1+0+J:J:J:urn?:iso?:std?:iso?:20022?:tech?:xsd?:pain.001.003.03
HIPAES:9:1:4+1+1+0
HICCSS:10:1:4+1+1+0
HITANS:11:1:4+1+1+0+J:N:0:0:900:2:iTAN:iTAN:6:1:Index:3:1:N:N
HIKAZS:12:5:4+1+1+390:N:N
HICDNS:13:1:4+1+1+1+0:1:360:J:J:J:J:J:N:N:N:J:00:00::0
HICSBS:14:1:4+1+1+0+N:N
HICSAS:15:1:4+1+1+0+1:360
HIWPDS:16:6:4+1+1+0+N:N:N
HIWPDS:17:5:4+1+1+N:N:N
DIPAES:18:1:4+1+1
HICDLS:19:1:4+1+1+1+1:360:N:J
HIPROS:20:3:4+1+1
HICSES:21:1:4+1+1+0+1:360
HICSLS:22:1:4+1+1+0+J
HICDBS:23:1:4+1+1+0+N
HISALS:24:5:4+1+1
HICDES:25:1:4+1+1+1+4:1:360:00:00::0
DIPINS:26:1:4+1+1+HKSPA:N:HKPAE:J:HKCCS:J:HKTAN:N:HKKAZ:N:HKCDN:J:HKCSB:N:HKCSA:J:HKWPD:N:DKPAE:J:HKCDL:J:HKPRO:N:HKCSE:J:HKCSL:J:HKCDB:N:HKSAL:N:HKCDE:J
HIPINS:27:1:4+1+1+0+5:10:6:Kontonummer::HKSPA:N:HKPAE:J:HKCCS:J:HKTAN:N:HKKAZ:N:HKCDN:J:HKCSB:N:HKCSA:J:HKWPD:N:DKPAE:J:HKCDL:J:HKPRO:N:HKCSE:J:HKCSL:J:HKCDB:N:HKSAL:N:HKCDE:J
HISYN:28:4:5+000006JJKLDTA8B536533NCEMCA87D

HNHBS:29:1+1

[HIRMG] 3060: Teilweise liegen Warnungen/Hinweise vor.
[HIRMS] 0020: Die Synchronisierung der Kundensystem-ID war erfolgreich.
[HIRMS] 3050: BPD nicht mehr aktuell. Aktuelle Version folgt.
[HIRMS] 3920: Zugelassene Ein- und Zwei-Schritt-Verfahren für den Benutzer (900)
Received system id: 000006JJKLDTA8B536533NCEMCA87D
Received dialog id: 000006JJKLDOR5OOS9OR167VMC9VMV
Supported TAN mechanisms: iTAN (900)
SYNC end

SYNC initialize
> HNHBK:1:3+000000000415+300+0+1
HNVSK:998:3+PIN:2+998+1+1::0+1:20190927:185439+2:2:13:@8@00000000:5:1+280:50010517:**********:V:0:0+0
HNVSD:999:1+@252@HNSHK:2:4+PIN:2+900+2819411+1+1+1::0+1+1:20190927:185439+1:999:1+6:10:16+280:50010517:**********:S:0:0
HKIDN:3:2+280:50010517+**********+0+1
HKVVB:4:3+0+0+0+*************************+1.0
HKTAN:5:6+4+HKIDN+++++N++++
HKSYN:6:3+0
HNSHA:7:2+2819411++**********

HNHBS:8:1+1

< HNHBK:1:3+000000000332+300+000006JJKLE1FPTDDFVV7PQM2EEL6D+1+000006JJKLE1FPTDDFVV7PQM2EEL6D:1
HNVSK:998:3+PIN:2+998+1+2::0+1+2:2:13:@8@        :6:1+280:50010517:**********:V:0:0+0
HNVSD:999:1+@123@HIRMG:2:2:+9050::Nachricht teilweise fehlerhaft.
HIRMS:3:2:5+9010::Der gewünschte Geschäftsvorfall wird nicht unterstützt.

HNHBS:4:1+1

[HIRMG] 9050: Nachricht teilweise fehlerhaft.
[HIRMS] 9010: Der gewünschte Geschäftsvorfall wird nicht unterstützt.
Request Failed: Der gewünschte Geschäftsvorfall wird nicht unterstützt. (9010); Nachricht teilweise fehlerhaft. (9050)
Request Failed: Der gewünschte Geschäftsvorfall wird nicht unterstützt. (9010); Nachricht teilweise fehlerhaft. (9050)

If you provide an empty product name, an exception is thrown in nemiah\php-fints\lib\Fhp\FinTs.php on line 91.

There must be added a backslash in order to avoid the namespace conflicts:

	if(trim($productName) == '')
		throw new **\**Exception ("Product name required!");
	
	if(trim($productVersion) == '')
		throw new **\**Exception ("Product version required!");

Zunächst einmal vielen Dank an alle, die an diesem Projekt mitarbeiten!

Beim Versuch Umsatzdaten abzurufen, erhalte ich seit neuestem bei der GLS Bank auch die von mehreren Usern berichtete Meldung "Pflichtfeld nicht gefunden (9160); Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800)"

Eine Registrierungsnummer habe ich bereits beantragt und erhalten, finde aber leider keine Info, wo ich diese im Script einpflegen muss.

Kann jemand weiterhelfen?

Bei der Deutschen Bank bekomme ich folgende Fehlermeldung:

Request Failed: Nicht belegt. (9160); Dialoginitialisierung abgebrochen. (9800)

dieser tritt auf wenn:

$fints->getSEPAAccounts();

ausgeführt wird. Entsprechend der Kompatibilitätsliste sollte die Deutsche Bank unterstützt werden und es da funktionieren.

Es wird das Sample Skript verwendet mit diesen Bankdaten:
define('FHP_BANK_URL', 'https://fints.deutsche-bank.de/');
define('FHP_BANK_PORT', 443);
define('FHP_BANK_CODE', '61370024');

Jemand eine Idee?
Schon einmal vielen lieben Dank für die Hilfe.

Ich versuche gerade, die TAN-Bestätigung bei der Abfrage der Statements zu implementieren. Dabei erhalte ich folgende Fehler:

Request Failed: Ungültige Auftragsnachricht? (9110); Die Nachricht enthält Fehler. (9050)

Meine Implementierung:

$this->io->title('HBCI Testing');

$this->hbciService->syncBankAccounts();

$accountRepo = $this->entityManager->getRepository(HbciAccount::class);
$account     = $accountRepo->find(2);

$this->finTs->setTANMechanism(910); // Chip-TAN manuell

$soa = $this->finTs->getStatementOfAccount($account->toFinTsSepaAccount(), new \DateTime('2010-09-01'), new \DateTime());

if ($soa->isTANRequest()) {
    $this->io->error('TAN IS REQUIRED');
    $startCode = $this->getStartCodeFromSoa($soa);

    $this->io->text('Startcode: '.$startCode);

    $tan = $this->io->ask('Enter TAN');

    $soa = $this->finTs->finishStatementOfAccount($soa, $account->toFinTsSepaAccount(), new \DateTime('2019-09-15'), new \DateTime(), $tan);
}

/** @var Statement $statement */
foreach ($soa->getStatements() as $statement) {
    foreach ($statement->getTransactions() as $transaction) {
        $referenceText = substr($transaction->getDescription1(), strpos($transaction->getDescription1(), 'SVWZ+') + 5);

        $this->io->text($referenceText);
    }
}

Debug-Log:

11:16:34 INFO      [app] [HIRMS] 0030: Auftrag empfangen - Bitte die TAN eingeben.(MBT61970200002)

[ERROR] TAN IS REQUIRED

 Startcode: 80044216

 Enter TAN:
 > 912945

11:16:53 INFO      [app]
11:16:53 INFO      [app] HKTAN (Zwei-Schritt-TAN-Einreichung) initialize
11:16:53 DEBUG     [app] > HNHBK:1:3+000000000422+300+[removed]=[removed]=+8'HNVSK:998:3+PIN:2+998+1+1::FEf/[removed]+1:20190919:111653+2:2:13:@8@00000000:5:1+280:[BLZ]:[username]:V:0:0+0'HNVSD:999:1+@207@HNSHK:2:4+PIN:2+910+6856580+1+1+1::FEf/[removed]+1+1:20190919:111653+1:999:1+6:10:16+280:[BLZ]:[username]:S:0:0'HKTAN:3:6+2++++9159-09-19-11.16.34.500839++N++++'HNSHA:4:2+6856580++[password]:924921''HNHBS:5:1+8'
11:16:53 DEBUG     [app] < HNHBK:1:3+000000000507+300+[removed]=[removed]=+8+[removed]=[removed]=:8'HNVSK:998:3+PIN:2+998+1+2::FEf/[removed]+1:20190919:111653+2:2:13:@8@00000000:5:1+280:[BLZ]:[username]:V:0:0+0'HNVSD:999:1+@259@HNSHK:2:4+PIN:2+910+6856580+1+1+2::FEf/[removed]+1+1:20190919:111653+1:999:1+6:10:16+280:[BLZ]:[username]:S:0:0'HIRMG:3:2+9050::Die Nachricht enthält Fehler.'HIRMS:4:2:2+9110:7:Ungültige Auftragsnachricht?: Unbekannter Aufbau.'HNSHA:5:2+6856580''HNHBS:6:1+8'
11:16:53 ERROR     [app] [HIRMG] 9050: Die Nachricht enthält Fehler.
11:16:53 ERROR     [app] [HIRMS] 9110: Ungültige Auftragsnachricht?
11:16:53 ERROR     [app] Request Failed: Ungültige Auftragsnachricht? (9110); Die Nachricht enthält Fehler. (9050)
11:16:53 CRITICAL  [app] Request Failed: Ungültige Auftragsnachricht? (9110); Die Nachricht enthält Fehler. (9050)
11:16:53 ERROR     [console] Error thrown while running command "app:hbci:test -vvv". Message: "Request Failed: Ungültige Auftragsnachricht? (9110); Die Nachricht enthält Fehler. (9050)"

Guten Tag,

mit dem dev-master von gestern konnte ich heute das erste mal wieder abrufen. Jetzt habe ich erneut das letzte Update eingespielt und erhalte beim Abruf:

[HIRMG] 3060: Bitte beachten Sie die enthaltenen Warnungen/Hinweise.
[HIRMS] 3050: BPD nicht mehr aktuell, aktuelle Version enthalten.
[HIRMS] 3920: Zugelassene Zwei-Schritt-Verfahren für den Benutzer.
[HIRMS] 0020: Der Auftrag wurde ausgeführt.
[HIRMS] 3076: Starke Kundenauthentifizierung nicht notwendig.
Received dialog ID: ...=...=
DIALOG end

HKSPA (SEPA accounts) initialize
...
[HIRMG] 9050: Die Nachricht enthält Fehler.
[HIRMG] 9800: Dialog abgebrochen
[HIRMG] 9930: Kein gültiges Sicherheitsprofil.
[HIRMS] 9010: Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet.
Request Failed: Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (9010); Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800); Kein gültiges Sicherheitsprofil. (9930)
Request Failed: Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet. (9010); Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800); Kein gültiges Sicherheitsprofil. (9930)

Hat jemand einen Tipp für mich? Danke!

Seit der Umstellung am 11.09.19 funktioniert unser Import von neuen Bank-Transaktionen leider nicht mehr. Wir sind bei der Volksbank Emmerich-Rees.
Wir benutzen phpFinTS seit einigen Monaten erfolgreich in unserer eigenen Firmensoftware. Diese ist auf Apache/PHP/MySQL basiert. Der Abgleich erfolgt z.Zt noch über einen Cronjob. Möglicherweise müsste dieser in Zukunft interaktiv manuell aufgerufen werden (?)

Hätte jemand Interesse sich des Problems anzunehmen? Es handelt sich um eine vergütete Arbeit, möglichst auf Rechnung. Dank & Gruß an die Gemeinschaft.
M.Meinesz

Meiner Meinung nach wäre jetzt der ideale Zeitpunkt die TAN-Behandlung abzuändern, sodass die Verbindung zum Server zwischen TAN-Request der Gegenstelle und TAN-Übermittlung beendet wird. Oder anders gesagt, man braucht die Response nicht die ganze Zeit durchschleifen und Callbacks pollen.

Da ja bei diversen Anfragen eine TAN verlangt werden kann, könnte z.B. sendMessage eine TanRequiredException schmeißen und die ProcessID dort speichern.

...
$response = new GetTANRequest($response->rawResponse, $dialog);
$response->get()->getProcessID();
...

Wenn man dann die TAN vom Nutzer abgefragt hat, schickt man diese hin, z.B. so

public function confirmProcessIdWithTAN($processID, $tan)
{
    if (empty($tan)) {
        throw new TANException("No TAN received!");
    }

    $dialog = $this->getDialog();

    $message = new Message(
        $this->bankCode,
        $this->username,
        $this->pin,
        $dialog->getSystemId(),
        $dialog->getDialogId(),
        $dialog->getMessageNumber(),
        array(
            new HKTAN(HKTAN::VERSION, 3, $processID)
        ),
        array(
            AbstractMessage::OPT_PINTAN_MECH => $this->getUsedPinTanMechanism($dialog)
        ),
        $tan
    );
}

und kann danach ggf. die Funktion wieder aufrufen die zur TAN-Exception geführt hat.

So wie es jetzt ist, muss ja jede Anfrage wie z.B. "getStatementOfAccount" sich selbst um die Unterbrechung durch die TAN kümmern.

Originally posted by @ampaze in #20 (comment)

Hallöchen,

erstmal ein Lob für die aktive Arbeit an diesem Projekt! Besonders jetzt zur PSD2 Einführung!

Bei der Comdirect funktioniert der aktuelle Master-Stand noch nicht, man erhält die Fehlermeldung "Dialog abgebrochen".
Diese Fehlermeldung kommt beim abrufen der getSEPAAccounts() Funktion. Eine Mobil-Tan wird von der Comdirect generiert. zugesendet und das Konto nach 5 Versuchen gesperrt (Ist mir schon 2 mal passiert...)
Ist das Problem bekannt und überschneidet es sich ggf. schon mit anderen offenen Issues?

Ich sehe z.B. hier, dass extra Anpassungen für die Comdirect Bank gemacht werden mussten.

Wenn es noch nicht bekannt ist, kann ich später noch mehr Informationen bereitstellen, was die Log ausspuckt.

Mein Aufruf ist wie folgt:

$fints = new FinTs(
FHP_BANK_URL_DKB,
FHP_BANK_PORT_DKB,
FHP_BANK_CODE_DKB,
FHP_ONLINE_BANKING_USERNAME_DKB,
FHP_ONLINE_BANKING_PIN_DKB,
new testLogger(),
FHP_REGISTRATION_NO,
FHP_SOFTWARE_VERSION
);

$fints->setTANMechanism(921); // die Nummer 921 stand irgendwo in einer Response der DKB...

$accounts = $fints->getSEPAAccounts();

Aber ich erhalte:
Fatal error: Uncaught Fhp\Dialog\Exception\FailedRequestException: Request Failed: Aufrufe ohne PSD2-Modus nicht mehr erlaubt, Dialog abgebrochen (9075); Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800); Banking-Programm muss zum 14.09.2019 auf PSD2 umgestellt werden. (3075) in /var/www/html/vendor/nemiah/php-fints/lib/Fhp/Dialog/Dialog.php:165

Danke für eure Hilfe.

Hallo beim ausführen von $fints->executeSEPADirectDebit(...) bekomme ich folgende Fehlermeldung:
Request Failed:
Die Nachricht enthält Fehler. (9050);
Dialog abgebrochen (9800);
Eine Challenge-Anfrage wurde abgebrochen, der Auftrag wird nicht ausgeführt. (9260)

kann jemand damit etwas anfangen und hat einen Tipp?

Vielen Dank im Voraus.

Ich hätte eine kleine Anregung.

Was mich sehr verwundert hat, ist, dass HBCI keine Unique-IDs zur Identifizierung der Buchungen liefert. Ich hatte den Fall, dass ich von einer Person zwei absolut identische Buchungen (Datum, Betreff, Summe) bekommen habe. Klar, wenn die Buchungen identisch sind, dann ist es egal, in welcher Reihenfolge man sie bearbeitet. Aber trotzdem will ich sie ja noch in meine Datenbank schreiben. Und wenn man aus Kontrollgründen Constraints setzt, kann es sein, dass identische Buchungen nicht geschrieben werden.

Also generiere ich mir meine eigene Pseudo-ID. Bisher (2+ Jahre) läuft es problemlos.

$statementnumber=0;
	foreach ($soa->getStatements() as $statement) {
		$statementnumber++;
		foreach ($statement->getTransactions() as $transaction) {
		$date = $transaction->getValutaDate()->format('Ymd'); # getBookingDate lieferte schon einmal das falsche Jahr, lieber valutadate
		if (!isset($dateCounters[$date])) {
			$dateCounters[$date] = 0;
		}
		$dateCounters[$date]++;
		$uniqId = $date.sprintf('%05d', $statementnumber).sprintf('%05d', $dateCounters[$date]);
		$betrag=($transaction->getCreditDebit() == Transaction::CD_DEBIT ? '-' : '') . $transaction->getAmount();
		echo 'Pseudo ID   : '.$uniqId.PHP_EOL;
		echo 'bookingDate : '.$transaction->getBookingDate()->format('Y-m-d').PHP_EOL;
		echo 'valutaDate  : '.$transaction->getValutaDate()->format('Y-m-d').PHP_EOL;
		echo 'Amount      : ' . $betrag.PHP_EOL;
		echo 'Booking text: ' . $transaction->getBookingText() . PHP_EOL;
		echo 'Name        : ' . $transaction->getName() . PHP_EOL;
		echo 'Description : ' . $transaction->getDescription1() . PHP_EOL;
		echo '=======================================' . PHP_EOL . PHP_EOL;
	}
}

Was meinen die Spezialisten hier? Ist das sinnvoll, praktikabel, sicher? Oder könnte es immer noch passieren, dass identische Pseudo-IDs generiert werden?

Hallo,
bin gerade dabei das Original von mschindler83 (wegen diverser Probleme) durch diese Version zu ersetzen - sieht bisher sehr viel besser aus - danke dafür!

Folgendes ist mir noch aufgefallen;
Fehlermeldung: E_WARNING: preg_match() expects parameter 2 to be string, object given in /var/www/test3/evyn/core/vendor/nemiah/php-fints/lib/Fhp/Response/Response.php line 394

Hab es wie folgt gelöst:
Zeile 38 von Response.php
if ($rawResponse instanceof Initialization) {
ersetzt durch:
if ($rawResponse instanceof Response) {

Viele Grüße!

Hallo.

Erstmal vielen Dank für die Mühen aller in dieses Projekt eingebundenen Leute.

Bis zur pösen Umstellung funktionierte der Zugriff auf mein Postbank-Konto per HBCI problemlos.

Jetzt habe ich fleißig meine FinTS-Registrierungsnummer beantragt und (wie ich hoffe) auch richtig eingetragen.

Allerdings bekomme ich bei statement_of_account.php folgende Fehlermeldung:

Sth. went wrong - Request Failed: Gewähltes Zwei-Schritt-Verfahren nicht unterstützt. (9200); Dialogabbruch. (9800)

Noch zur Info: Ich habe unter meinem Alias/Username bei der Bank drei verschiedene Girokonten. Kann es daher zu Problemen kommen?

Ich weiß jetzt leider nicht mehr weiter. Wer kann mich netterweise in die richtige Richtung schubsen.

Danke
Jürgen

Wäre es möglich einen neuen Release / neue Version zu machen, damit man via Composer nicht die Minimum Stability überschreiben muss?

Code von master a9a13c6. $fints->getVariables() liefert tanModes=[900=SecurePlus]. Also $fints->setTANMechanism(900);. $fints->getSEPAAccounts(), aber die Antwort auf HKSPA ist HIRMG:2:2:+9800::Der Dialog wurde abgebrochen.+9120::Unerwartete Nachricht..

Laut dem Forum der Consorsbank (und meinem Test mit Banking4) brauchen andere Programme eine von der App generierte TAN für jede Aktion. Vermutlich hätte phpFinTS also eine TAN mitsenden müssen. Ich versuche, das mal vorübergehend einzubauen.

With other GitHub repositories, I see automated tests being run whenever I send a pull request, and sometimes even auto-formatting for the code, which could prevent this. I have no idea how that can be configured and whether that costs any money to run those tests, but I'm sure some folks here may have experience with it. With a couple of upcoming PSD2 changes and banks likely changing their implementations over the next months, it would be difficult to ensure that an incremental improvement for one bank does not break things for another. So my plan is to add "integration tests" (actually just unit tests, but with a mock bank) that closely mirror the communication with actual banks (minus personal information). It would be nice if those and the existing tests could be run automatically to prevent regressions.

Hey Nena,

I have yet another problem. When I try to execute a direct debit I get

[HIRMG] Teilweise fehlerhaft.
[HIRMS] Wird nicht unterstützt.

Also:

HIRMS:4:2:4+9210::Name des TAN-Medium erforderlich.

In Postbank you can assign up to 5 mobileTan phone numbers. You also have to give them a name. On the website of Postbank they say:

Ist in Ihrem Finanzprogramm die manuelle Eingabe des TAN Mediums/der TAN Bezeichnung erforderlich, geben Sie die Daten bitte wie im folgenden Beispiel ein. Bitte beachten Sie die Groß- und Kleinschreibung.

cT:Peter
mT:Frank
SO:Lisa

While ct = chipTan, mT = mobileTan and SO = Seal One.

With a little research I only found little information about how to name the parameters. A small hint though was this:

(http://microsoft.public.de.money.narkive.com/Qy252AjE/postbank-kein-abruf-moglich)

...
Pin.TAN.Zweischrittverfahren
1
999,901
561
901
HITAB:4:2:3+0+M:1:::::::::::mT?:iphone'
HIUPA:83:4:4+********8+316+0+Name
...

Further than that the name "iphone" didn't appear on the site. It would be great if you could help me out with this. It really seems like only one small piece of information (mT:name) is missing.

Regards,
Dai

Beim Abruf von Kontoumsätzen bei der Sparkasse Düren wird der Trenner zwischen gebuchten und vorgemerkten Umsätzen nicht erkannt.

$this->rawData:

:20:STARTUMSE
...
:62F:C190919EURXXX,XX
-+@1073@
:20:STARTDISPE
...
-

$cleanedRawData:

:20:STARTUMSE
...
:62F:C190919EURXXX,XX-+@1073@
:20:STARTDISPE
...
:90D:3EURXX,XX
:90C:0EURXX,XX-

$day[$i]:

62F:C190919EURXXX,XX-+@1073@

Dies wird dann hier leider nicht erkannt:

Ich kenne die Spezifikation leider zu wenig, so dass ich hier keinen vernünftigen Verbesserungsvorschlag machen kann.

Hi,

while my reviews (see pull request #65 ) i discovered some issues if "FinTs::getVariable" gets called on the way to receive transactions.

Trace:

• fints = new FinTS\FinTS(...)
• fints->getSEPAAccounts()
• fints->getVariables()
• fints->getStatementOfAccount <-- Here will the error be logged

I could produce this problem with these banks:

Deutsche Bank:
Auftrag ausgeführt. (0020); Auftrag abgelehnt - Zwei-Schritt-TAN inkonsistent. Eingereichter Auftrag gelösch (9210); Teilweise fehlerhaft. (9050)

Volksbank:
Auftrag wegen genereller Fehler in Auftragsnachricht nicht verarbeitet.(Die angegebene Bankreferenz ist nicht gültig.) (9010); Die Nachricht enthält Fehler. (9050); Dialog abgebrochen (9800)

Without calling "getVariables", the result is fine.

After some tests, I'm pretty sure, it has nothing to with HKTAN (especially the segementIdent) or the given Pin/Tan method in generally.