HBCI

[Jan Grasnick | grasbauer ug]

Hallo Trytonisten,

ich checke gerade mal die M�glichkeiten der HBCI/SEPA Anbindung in
Tryton. Mein partikularer Verwendungszweck: Zahlungseing�nge auf Vetr�ge
buchen. Insofern muss ich zun�chst nur lesen. Bisher w�rde ich f�r die
Umsetzung auf folgende bestehende L�sungen zur�ckgreifen:

http://www2.aquamaniac.de/sites/aqbanking/index.php

und die dazugeh�rigen Python-Bindings

https://github.com/emdete/python-aqbanking

(um eventuell die Entwicklung zu unterst�tzen)

Ist schon jemand fertig mit diesem Modul ;) ?
Einw�nde gegen die Verwendung der genannten Libs (hbci4java als
Alternative?)?
Sonstige Anmerkungen?

Jan

P.S: Barcelona war wirklich gut und nochmal Gru� an alle, die wir uns
trafen!

[Korbinian Preisler]

Hi Jan,

Am Dienstag, den 12.11.2013, 16:24 +0100 schrieb Jan Grasnick |
grasbauer ug:
> Hallo Trytonisten,
>
> ich checke gerade mal die Möglichkeiten der HBCI/SEPA Anbindung in
> Tryton. Mein partikularer Verwendungszweck: Zahlungseingänge auf Veträge
> buchen. Insofern muss ich zunächst nur lesen.
Sowas ähnliches steht bei uns demnächst evtl. auch an.

> Bisher würde ich für die
> Umsetzung auf folgende bestehende Lösungen zurückgreifen:
>
> http://www2.aquamaniac.de/sites/aqbanking/index.php
>
> und die dazugehörigen Python-Bindings
>
> https://github.com/emdete/python-aqbanking
>
> (um eventuell die Entwicklung zu unterstützen)

>
> Ist schon jemand fertig mit diesem Modul ;) ?

Bisher haben wir noch nicht damit begonnen.

> Einwände gegen die Verwendung der genannten Libs (hbci4java als
> Alternative?)?
Unsere Überlegungen sind im Moment eher in der Richtig, die
XMLRPC-Schnittstelle von hibiscus zu verwenden. Über den
Hibiscus-Server[1] ließen sich die Umsätze automatisiert abholen und
über die XMLRPC-Schnittstelle in Tryton einlesen.

Für hibiscus wird hier aktiv eine Version von HBCI4JAVA gepflegt[2]. Der
Fork ist sehr aktiv. Zu den Python-Bindings für AQBANKING kann ich nicht
viel sagen. Schaut allerdings auf den ersten Blick etwas inaktiv aus.
Zudem erscheint mir AQBANKING weniger offen (ich hatte mir das vor
einiger Zeit mal ein wenig angesehen). Daher würde ich eher auf hibiscus
und HBCI4JAVA setzen.

Viele Grüße

Korbinian


[1] http://www.willuhn.de/products/hibiscus-server/
[2] https://github.com/willuhn/hbci4java

[Jan Grasnick | grasbauer ug]

Am 12.11.2013 17:12, schrieb Korbinian Preisler:
> Hi Jan,

Hallo Korbinian,

> Unsere �berlegungen sind im Moment eher in der Richtig, die
> XMLRPC-Schnittstelle von hibiscus zu verwenden. �ber den
> Hibiscus-Server[1] lie�en sich die Ums�tze automatisiert abholen und
> �ber die XMLRPC-Schnittstelle in Tryton einlesen. F�r hibiscus wird

> hier aktiv eine Version von HBCI4JAVA gepflegt[2]. Der Fork ist sehr

> aktiv. Zu den Python-Bindings f�r AQBANKING kann ich nicht viel

> sagen. Schaut allerdings auf den ersten Blick etwas inaktiv aus.
> Zudem erscheint mir AQBANKING weniger offen (ich hatte mir das vor

> einiger Zeit mal ein wenig angesehen). Daher w�rde ich eher auf
> hibiscus und HBCI4JAVA setzen.
>

Die Pros und Kontras habe ich auch alle durchdacht - zumal ich Hibiscus
selbst als Client nutze und sehr zufrieden bin. Das einzige Pro f�r
meine Variante war eigentlich nur, da� es ein Pythonbinding gibt. Eine
Sache, die eher gegen den Hibiscus-Server spricht ist allerdings, da�
man diesen installieren muss. Ich dachte eher an Cron und Trigger von
Tryton, die den Bankserver direkt anfragen. Du hast mich aber wieder
etwas in Richtung Hibiscus gestubbst. Auf alle F�lle fange ich in den
n�chsten 48 Stunden an, weil es ein sehr dringendes Problem eines Kunden
ist. Bis dahin ist jeder Kommentar willkommen ;)

Jan

[LAG Robin Baumgartner]

Hallo Jan

>> Unsere Überlegungen sind im Moment eher in der Richtig, die
>> XMLRPC-Schnittstelle von hibiscus zu verwenden. Über den
>> Hibiscus-Server[1] ließen sich die Umsätze automatisiert abholen

>> und über die XMLRPC-Schnittstelle in Tryton einlesen. Für hibiscus

>> wird hier aktiv eine Version von HBCI4JAVA gepflegt[2]. Der Fork

>> ist sehr aktiv. Zu den Python-Bindings für AQBANKING kann ich

>> nicht viel sagen. Schaut allerdings auf den ersten Blick etwas
>> inaktiv aus. Zudem erscheint mir AQBANKING weniger offen (ich hatte

>> mir das vor einiger Zeit mal ein wenig angesehen). Daher würde ich

>> eher auf hibiscus und HBCI4JAVA setzen.
>>
>
> Die Pros und Kontras habe ich auch alle durchdacht - zumal ich
> Hibiscus selbst als Client nutze und sehr zufrieden bin. Das einzige

> Pro für meine Variante war eigentlich nur, daß es ein Pythonbinding

> gibt. Eine Sache, die eher gegen den Hibiscus-Server spricht ist

> allerdings, daß man diesen installieren muss. Ich dachte eher an

> Cron und Trigger von Tryton, die den Bankserver direkt anfragen. Du
> hast mich aber wieder etwas in Richtung Hibiscus gestubbst. Auf alle

> Fälle fange ich in den nächsten 48 Stunden an, weil es ein sehr

> dringendes Problem eines Kunden ist. Bis dahin ist jeder Kommentar
> willkommen ;)

Fast wichtiger als woher die Zahlungsdaten kommen, scheint mir die Frage
zu sein, wie diese in Tryton verarbeitet werden sollen. Wir kennen
ebenfalls diverse Schnittstellen für Zahlungsein- und ausgänge (ESR,
DTA, später ebenfalls SEPA) und bisher haben wir da jeweils etwas selber
gebaut.

Langfristig wäre es aber ein grosser Vorteil, wenn wir uns auf eine
gemeinsame Basis zur Verarbeitung der Zahlungsdaten einigen könnten, so
dass nur noch die Art des Imports/Exports allenfalls individualisiert
werden muss.

Das Modul account_statement scheint geeignet für so eine gemeinsame
Basis, aber wir haben bisher noch keine Erfahrungen damit gemacht.
Planst du dieses Modul bei deiner Implementation zu berücksichtigen?

--
Freundliche Grüsse

Robin Baumgartner
Software Engineer

Leuchter Open Source Solutions AG
Winkelriedstrasse 45
CH-6003 Luzern
robin.ba...@leuchterag.ch
tryton.leuchterag.ch
T +41 41 226 50 93
F +41 41 226 50 51

Ein Unternehmen der Leuchter IT Solutions Gruppe

[Jan Grasnick | grasbauer ug]

Hallo Robin,

> Langfristig w�re es aber ein grosser Vorteil, wenn wir uns auf eine
> gemeinsame Basis zur Verarbeitung der Zahlungsdaten einigen k�nnten, so

> dass nur noch die Art des Imports/Exports allenfalls individualisiert
> werden muss.
>

> Das Modul account_statement scheint geeignet f�r so eine gemeinsame

> Basis, aber wir haben bisher noch keine Erfahrungen damit gemacht.

> Planst du dieses Modul bei deiner Implementation zu ber�cksichtigen?

Hatte ich zumindest so vor, da es ja genau daf�r gemacht zu sein scheint
und die Grundfunktionen einer Zahlung per Statement bereits
implementiert. Allerdings muss ich mich da auch noch einlesen. Die Frage
w�rde ich mal an Mathias, Korbinian oder Udo weitergeben, da alles was
mit Buchaltung zu tun hat f�r mich eher ein rotes Tuch ist ;)

Jan

[Mathias Behrle]

* Jan Grasnick | grasbauer ug: " Re: [tryton-de] HBCI" (Wed, 13 Nov 2013
11:10:53 +0100):

Hallo alle,

> > Langfristig wäre es aber ein grosser Vorteil, wenn wir uns auf eine
> > gemeinsame Basis zur Verarbeitung der Zahlungsdaten einigen könnten, so

> > dass nur noch die Art des Imports/Exports allenfalls individualisiert
> > werden muss.
> >

> > Das Modul account_statement scheint geeignet für so eine gemeinsame

> > Basis, aber wir haben bisher noch keine Erfahrungen damit gemacht.

> > Planst du dieses Modul bei deiner Implementation zu berücksichtigen?
>
> Hatte ich zumindest so vor, da es ja genau dafür gemacht zu sein scheint

> und die Grundfunktionen einer Zahlung per Statement bereits
> implementiert. Allerdings muss ich mich da auch noch einlesen. Die Frage

> würde ich mal an Mathias, Korbinian oder Udo weitergeben, da alles was
> mit Buchaltung zu tun hat für mich eher ein rotes Tuch ist ;)

Ich hole mal etwas aus:

Wir haben vor nun langer Zeit (das war noch mit Version 1.4) evaluiert, ob wir
eine für den deutschen Markt zufriedenstellende Lösung auf Basis der
verfügbaren Standardmodule umsetzen können. Dabei fiel account_statement aus
mehreren Gründen durch das Raster. Wenn ich mich recht erinnere (ist
wirklich lange her) waren das auf der einen Seite konzeptionelle Mängel wie
Saldenhandling, Fixierung auf Bankauszug ( -> gerade wenn man an Bankimport
denkt, macht die Modellierung nach einem Papierauszug wenig Sinn, so dass wir
einen Buchungsstapel daraus gemacht haben).
Auf der anderen Seite haben wir als Buchungsinterface eine DATEV-ähnliche
Buchungszeile konzipiert, die direkt auf diesen Buchungsstapeln aufsetzt und
auch für die Verbuchung von Bankimporten verwendet wird.

Von daher scheint mir auch aus heutiger Sicht die Nutzung von account_statement
nur für Nutzer empfehlenswert, die tatsächlich relativ simpel Papierauszüge in
ihrer Buchhaltung abbilden wollen.

So weit erst mal dazu...

Viele Grüße,
Mathias


--

Mathias Behrle
MBSolutions
Gilgenmatten 10 A
D-79114 Freiburg

Tel: +49(761)471023
Fax: +49(761)4770816
http://m9s.biz
UStIdNr: DE 142009020
PGP/GnuPG key availabable from any keyserver, ID: 0x8405BBF6

[Jan Grasnick | grasbauer ug]

Am 13.11.2013 14:10, schrieb Mathias Behrle:

> Ich hole mal etwas aus: Wir haben vor nun langer Zeit (das war noch
> mit Version 1.4) evaluiert, ob wir eine für den deutschen Markt
> zufriedenstellende Lösung auf Basis der verfügbaren Standardmodule
> umsetzen können. Dabei fiel account_statement aus mehreren Gründen
> durch das Raster. Wenn ich mich recht erinnere (ist wirklich lange
> her) waren das auf der einen Seite konzeptionelle Mängel wie
> Saldenhandling, Fixierung auf Bankauszug ( -> gerade wenn man an
> Bankimport denkt, macht die Modellierung nach einem Papierauszug
> wenig Sinn, so dass wir einen Buchungsstapel daraus gemacht haben).
> Auf der anderen Seite haben wir als Buchungsinterface eine
> DATEV-ähnliche Buchungszeile konzipiert, die direkt auf diesen
> Buchungsstapeln aufsetzt und auch für die Verbuchung von Bankimporten
> verwendet wird. Von daher scheint mir auch aus heutiger Sicht die
> Nutzung von account_statement nur für Nutzer empfehlenswert, die
> tatsächlich relativ simpel Papierauszüge in ihrer Buchhaltung
> abbilden wollen. So weit erst mal dazu... Viele Grüße, Mathias

Hallo,

ich hab mal einen ersten Dummy für eine Integration von aqbanking entworfen. Obwohl ich nun Kenntnis der von Matthias erwähnten Module habe, diese aber noch nicht komplett in die 3.0 heben konnte, habe ich es erstmal mit account_statement verbunden

Im Moment sind da die Kommandos an aqbanking direkt im Code - sinvoller wäre es natürlich, eine eigenes Modul zu bauen, in dem man die API von aqbanking verfügbar macht. Das würde ich dann bei Gelegenheit mal angehen. Da ich wenig Zeit hatte und ne schnelle Lösung brauchte, habe ich mich dafür entschieden, erstmal nur die Komandozeile von aqbanking über pexpect anzusprechen. Was noch absolut fehlt ist ein Errorhandling - da muss man mal in aller Ruhe den möglichen Output studieren.

Was im Moment geht ist:
- Zugang anlegen
- Kontoauszüge in account_statement abholen

Achtung: beim Abholen darauf achten, wie lange Eure Bank die Kontoauszüge vorhält. Zum Testen haben ich deshalb in den Wizzard ein Startdatum eingebaut, um erstmal explizit - sagen wir - einen Monat abzuholen. Ich habe bei einem Test mal 9000 Zeilen bekommen - da kackt der Client ab, weil Many2One keine Limits hat.

Mit Euren Einwänden könnt Ihr die Sache hier versehen:

http://review.gewinnmonitor.de/account_statement_hbci/changeset/36da58830523ec10f66ecb85bb2f8ffe382f4b49

TODO unter anderem:

Übersetzung und Scenario (im Moment nur Kopien von einem anderen Modul)

Grüße aus der Heldenstadt Leipzig von einem friedliebenden Dynamofan
Jan