Bankschnittstelle
IBAN und BIC/SWIFT-Felder wurden in Version 4.1 vollständig eingeführt. Momentan existieren allerdings nur Einzellösungen für SEPA Import und Export. Ein automatisierter Import von Bankauszügen ist mir bisher nicht bekannt, wobei es prinzipiell kein Problem ist, einen Auszug als CSV-Datei von der Bank zu erhalten und über das entsprechende Import-Fenster einzulesen.
Ich möchte die momentanen Bemühungen bzgl. Bankschnittstelle/SEPA für iDempiere aufzeigen und zusammenfassen. Ich bitte ausdrücklich alle, die sich um das Thema bemühen, hier mitzuschreiben. Es wäre schön, wenn wir als gemeinsames Ergebnis ein schönes Plugin erzeugen könnten und nicht jeder das Rad immer neu erfinden muss.
Was gehört zur Bankschnittstelle?
Unmittelbar reden wir von SEPA-Aufträgen zur Übermittlung von Transaktionen an die Bank. DTAUS sollte hier kein Thema mehr sein.
Lastschriften scheinen im Workflow von iDempiere nicht ganz bedacht zu werden. Teilweise werden nur Lieferantenrechnungen gefiltert etc. Die Lastschrift scheint eine deutsche Besonderheit zu sein. Sie gehört aber IMO ordentlich in die Software integriert.
Die Datenübertragung kann per SEPA-XML-Datei erfolgen. Meine Volksbank bietet z.B. den Upload über das Webinterface an. Schön wäre ein direkter HBCI-Zugang. Aber auch Schnittstellen zu bestehender Online-Banking Software sind denkbar.
Für die Abholung von Kontoauszügen gilt das Gleiche: Es gibt mehrere Möglichkeiten. Automatisierung z.B. per HBCI wäre schön.
Abbildung des gesamten Zahlungsverkehrs: Ist es wünschenswert und möglich, das die Banking-Schnittstelle in iDempiere so mächtig und komfortabel ist, das ich eigentlich gar keinen anderen Zugang mehr zu meiner Bank brauche?
Wenn ich Kontoauszüge automatisiert einlese möchte ich diese auch automatisiert zuordnen bzw. verbuchen können. Dafür gibt es das BankStatementMatcher-Interface, für das ich jedoch bisher noch keine Implementierung gesehen habe.
Für SEPA-Lastschriften braucht man eine Mandatsverwaltung.
Besonderheiten
Vieles ist noch im Fluss. Bis jetzt (November 2013) arbeiten immer noch praktisch alle mit dem alten System. Wir müssen also u.U. einerseits immer noch mit Kontonummer und BLZ umgehen, möchten diese aber andererseits nicht später bis zum Sankt-Nimmerleinstag mitziehen. Man muss also überlegen, wie und ob man Kontonummer und IBAN parallel nutzt (bei möglichst kleinem Aufwand). (Ich bin dagegen, überall neue Felder einzuführen, um mich nicht in wenigen Monaten über dann überflüssige Felder zu ärgern.)
Es gibt bereits ein IBAN-Feld und ein BBAN-Feld im "Bank"-Fenster (Tabelle C_BankAccount), 40 Zeichen lang. Es gibt keine IBAN-Felder in I_BankStatement. Wollen wir dort das vorhandene BankAccount-Feld z.B. zum Matching nutzen, ist dieses aber nur 20 Zeichen lang. Das EftPAyeeAccount-Feld hat 40 Zeichen und wäre geeignet. Es ist aber nicht vom Benutzer beschreibbar, würde also u.U. Funktionalitäten ergeben, die ohne unsere automatische Anbindung nicht nutzbar wären.
HBCI (bzw. FinTS) als Übertragungsmethode hat in beide Übertragungsrichtungen den Vorteil, das es ein Standard ist, der von fast allen eingehalten wird und man nicht für jede Bank das Rad neu erfinden muss. Andererseits ist es, wenn ich das richtig verstanden habe, kein reiner Übertragungsweg für SEPA-Standarddateien, sondern definiert eigene SEPA-Geschäftsvorfälle und überträgt diese in einem eigenen Format(?!?).
Ein ordentlicher BankStatementMatcher sollte vielfältig konfigurierbar sein und könnte fast ein Projekt für sich sein.
Wenn wir Auszugszeilen abgelichen wollen, muss für jede Zahlung eine Zeile da sein. Für selbst versendete Sammler gilt das aber nicht. Wie geht man damit um?
PaymentProcessor ist keine Schnittstelle sondern eine abstrakte Basisklasse. Sie enthält allerlei Zeugs zum HTTP-Datenaustausch, was nichts mit Zahlungen zu tun hat. Außerdem scheint die API immer nur eine einzelne Zahlung ausführen zu können. Entweder konstruiert man ein neues Fenster, wo Zahlungen nochmals gesammelt werden, um später im Block versendet zu werden oder man macht eine neue Schnittstelle, die näher an den Eigenschaften von SEPA liegt.
Meine Erfahrung mit einem eigenen Banking-Programm, das ich vor Jahren mal geschrieben habe, ist davon geprägt, das dauernd Dinge geändert wurden. Jedes neue TAN-Verfahren und jede neue Verschlüsselung brachte wieder Änderungen an meinem Programm mit sich. Daher meine Überlegung, ob man eine Schnittstelle zu einer Software/Bibliothek schafft, die dann jemand anders wartet oder ob man das stärker integriert und dann immer pflegen will. (Sowas kann ja durchaus auch ein Geschäftsmodell sein...) Vielleicht ist der richtige Weg auch, beides anzubieten.
Die Übertragung von Bankauszügen arbeitet auch z.B. in HBCI mit dem Standard MT940. Dieser enthält offensichtlich kein IBAN-Feld. Bisher enthalten Auszüge die Kontonummer des Zahlungsabsenders. Hat dieser per SEPA bezahlt, ist das Feld leer. Wie soll in Zukunft ein BankStatementMatcher automatisch Zahlungen zu Geschäftspartnern zuordnen können?
Fragen, die offen sind
Kann eigentlich jemand so richtig die vorhandenen Teile von iDempiere bzgl. Zahlungsablauf erklären? Wozu ist das Fenster "PaymentBatch" (Zahlungssatz) da und wofür kann man da einen PaymentProvider einsetzen?
Wer hat eigentlich die IBAN-Felder in die Datenbank eingeführt und kann man herausfinden, was derjenige sich sonst noch so dabei gedacht hat?
Welche konkreten Initiativen/Projekte existieren?
- Evenos möchte ein HBCI-Plugin erstellen. Bisher ist einiges davon unter der GPL veröffentlicht (Danke an Evenos!). Entwickler und Ansprechpartner ist Jan Thielemann. Das Plugin benutzt die HBCI4Java Bibliothek.
- Thomas Bayen arbeitet an einer Schnittstelle zu Hibiscus und möchte einen BankStatementMatcher sowie eine Mandatsverwaltung haben. Die Hibiscus-Schnittstelle soll vor allem zuerst einmal ein lernender Einstieg in das Thema Plugin- und WebServices-Programmierung sein. Wenn sie dann am Ende läuft - umso besser. :-) Das Plugin ist selbstverständlich unter der GPL erhältlich. Bisher implementiert ist noch nicht viel:
- Ein BankStatementLoader, der seine Daten direkt aus der Hibiscus-Datenbank zieht
- Philippe Baumann von Integratio möchte SEPA-XML Dateien erzeugen.
Links und Werkzeuge
- HBCI4Java bzw. Olaf Willuhns Fork ist meines Wissen nach die einzige freie HBCI-Bibliothek. ([file:///home/tbayen/Java/workspaces/ws-hbci/hbci4java/doc/javadoc/index.html JavaDoc])
- Hibiscus ist ein freies und plattformunabhängiges Online-Banking-Programm. Es hat eine Datenbank mit einem übersichtlichen Datenmodell und auch eine WebServices-Schnittstelle. Hibiscus ist in Java geschrieben, GPL und nutzt intern HBCI4Java.
- Viele gängige Banking-Programme, die man von seiner Bank zur Verfügung gestellt bekommt (SFirm etc.) besitzen Schnittstellen, die zumeist mit CSV arbeiten
- Hibiscus gibt es auch in einer Version als Hibiscus Payment Server, der automatisiert ohne GUI arbeitet.
- Das Fenster |Import Bankauszug in iDempiere funktioniert ausgezeichnet und sollte die Basis aller Erweiterungen sein.
- http://de.wikipedia.org/wiki/Iban - u.A. Erläuterung des Formats der IBAN
- http://www.kontopruef.de/mt940s.shtml - Erklärung des MT940 Formats
- http://www.hettwer-beratung.de/sepa-spezialwissen/sepa-technische-anforderungen/sepa-gesch%C3%A4ftsvorfallcodes-gvc-mt-940/ - Erwähnung einiger der erweiterten Verwendungszwecke in MT940 für SEPA
- http://www.ingsepa.com/our-help/additional-services/format-validation-tool/ - Online SEPA-Validator, der gut funktioniert und z.B. PAIN-Dateien validiert
- Wikiartikel von Oracle über das SEPA-PAIN Format
- http://www.onlinebanking-forum.de/forum/topic.php?t=16952&page=fst_unread&highlight=sammler - Forumsthread darüber, das GAD-Banken immer mehr als einen Einzug pro Datei haben wollen
- https://groups.google.com/forum/#!msg/hbci4java/RYHCai_TzHM/zYlxcuNluhwJ - Thread im hbci4Java-Forum zu Multi-Lastschriften
- https://groups.google.com/forum/#!topic/hbci4java/ba-x6-vgV6I User:JanThielemann hat einiges in HBCI4Java implementiert und dabei JAXB benutzt. In diesem Forenthread ist dazu einiges erklärt.