Mal so interessehalber: Den elektronischen Kontoauszug gibt es ja zweimal. Einmal generisch als HKEKA (wo man beim Abruf das gewünschte Datenformat angeben kann, insofern die Bank mehrere Formate unterstützt) und einmal PDF-spezifisch als HKEKP.
Weiss hier jemand was zur Entstehung des zweiten Geschäftsvorfalls? Meine Sparkasse unterstützt beide Varianten (bei HKEKA aber leider nur im MT940-Format, was ich nicht sonderlich sinnvoll finde). Ich könnte mir vorstellen, dass einer der beiden GVs den anderen ablösen soll. HKEKP ist meiner Meinung nach der aktuellere. Kann es sein, dass HKEKA irgendwann gegen HKEKP ersetzt wird?

Es gibt noch einen: HKECA. Komischerweise wurde nicht einfach der HKEKA um CAMT erweitert und statt dessen ein neuer GV definiert.

Es würde mich wundern, wenn sich da in absehbarer Zeit etwas ändert.

Habt ihr in Banking4 alle 3 Varianten umgesetzt?

Der PDF-Auszug entspricht ja dem was die Banken in der Regel 1:1 auch auf dem Postweg versenden würden. (mein bisheriger Kenntnisstand)
diesen würde ich auch immer vorziehen, insbesondere auch im Hinblick aufs "fiskalische" = da wird man sich Diskussionen ersparen

Wir haben nur HKEKA (MT-940 und PDF) und HKEKP (PDF) umgesetzt, und dazu HKQTG, falls erforderlich. Nochmal komplizierter wird es, wenn man Kontoauszüge nacherstellen will, da das bei jedem HBCI Server anders gemacht wird.

Danke für die Info.

jein, bei dem alten GAD-System ist es eher das, was man an den SB-Kontoauszugsdruckern bekommen würde. Beim sogenannten Postkorb im Onlinebanking wird inzwischen meist das A4 Format eingestellt.
Da Kunden auch außer der Reihe über FinTS einen Auszug bestellen können, der dann ein anderes Aussehen hat und dem Postkorb nur noch die Restdaten übrig lässt führt dies schon mal zur Verwirrung bei allen Beteiligten.

Zur Entstehungsgeschichte kenne ich zumindest aus der "damaligen" Zeit diverse Diskussionen, die auf die eine oder andere Intention schliessen lassen.
Die Grundsatzfrage ist, für wen der Auszug gedacht ist und was man vermutet, was der Kunde damit macht.
Der HKEKA hat daher damals alle relevanten Formate (XML, MT940 und grafisch aufbereitet) definiert. Die ersten beiden Varianten waren nur für Firmenkunden gedacht, bei denen die Verarbeitung und auch die spätere Prüfung automatisch erfolgen sollte. Eine bildhafte Darstellung für den Menschen war hier gar nicht relevant. Damals mit Prüfungsverordnungen und diverse Auflagen, durchaus ein interessanter Ansatz, der sich aber nie durchgesetzt hat. Dieser Ansatz wurde nach meinem Stand von den Sparkassen verfolgt. Alle Anderen haben den GV als Ersatz der Papierauszüge gesehen, mit dem Ziel diese für den Menschen lesbar zu haben.
Da die Nachfrage nach den aufbereiteten Auszügen gestiegen ist, die nach den elektronisch verarbeitbaren nicht und sich als Format für die Bildaufbereitung PDF durchgesetzt hat, hat man das Thema auch bei den Sparkassen umgesetzt. Vermutlich weil eine Trennung der GVs nach abgerufenen Formaten von der Administration einfacher und mehr Spielraum lässt, hat man neue GVs definiert, die nur noch ein Format unterstützen.Da nur die Sparkassen den Auszug als PDF Format noch nicht unterstützt haben, setzen diese auf den HKEKP. Der GV weist in der ersten Segmentversion aber noch erhebliche administrative Lücken auf.....

Beim HKECA dem Auszug im camt Format kommt ein camt53 anders als bei der Umsatzabfrage unter FinTS bei dem ein camt52 kommt. Der HKECA wird daher auch von Kunden genutzt die eine Buchaltungsanwendung haben, die bereits auf die camt Verarbeitung umgestellt ist. Gem. der relevanten Spezifikation der Anlage 3 des DFÜ Abkommens werden die camt Formate unterteilt. camt 52 für Vorgemerkte Umsätze (analog MT942) und camt53 für gebuchte Umsätze (analog MT940). D.h. eine Buchhaltung, die sich nur nach der Spezifikation richtet, würde bei den normalen Umsätzen aus FinTS ggf. nur vorgemerkte Umsätze erwarten. Hier hilft auch der HKECA. Dazu kommt, dass hier Tagesauszüge analog EBICS geliefert werden (sollen), so dass man quasi die gleiche Datenqualität wie unter EBICS erhält.
Profi cash und VR-NetWorld Software unterstützen den Abruf HKECA, legen die Daten aber nur zur Weiterverarbeitung durch andere Anwendungen ab.
Beim HKEKP musst Du noch aufpassen. Die Codierung der gelieferten Daten entspricht nicht der Spec. Da sind damals die Programme von Andreas und die VR-NetWorld Software als erste Anwendungen die den GV unterstützt haben auch auf die Nase gefallen.

Viele Grüße

Holger

Danke für die interessanten Hintergrund-Infos!



Ja, in der Spezifikation ist mir schon aufgefallen, dass da ein extra Hinweis steht, dass die Daten - entgegen der Konvention für den Feld-Typ "bin" als Base64-codiert dort abgelegt werden. Zumindest wohl bis auf weiteres. Im Zweifel koennte man hier clientseitig auch ein Fallback einbauen. Wenn die Daten nur Zeichen aus dem ASCII-Raum enthalten, muss es Base64 sein. Andernfalls "bin".

Da jedes PDF irgendwie mit "PDF" (weiß es nicht mehr genau) beginnt kann man an den ersten Zeichen erkennen ob es base64 oder PDF direkt ist.

Stimmt. Das waere auch ne Moeglichkeit. Hatte jetzt grad noch ueberlegt, ob es den dummen Zufall geben koennte, dass auch das Base64 zufaellig mit "PDF" beginnt. Aber wenn jede PDF-Datei mit "PDF" beginnt, kann das ja eigentlich nicht vorkommen, da "PDF" Base64-codiert "UERG" ergibt.

Da jedes PDF mit "%PDF-" beginnt (gefolgt von der Version), kann man ganz konkret nach diesen 5 Zeichen suchen.