Project

General

Profile

Bug #55

Buchungsdatum fehlt in Context-Datei

Added by jannh 25 days ago. Updated 18 days ago.

Status:
Closed
Priority:
High
Category:
-
Start date:
09/18/2019
Due date:
Betriebssystem:
AqBanking-Version:
Anwendung:
Version der Anwendung:

Description

Wenn man die Transaktionen von der Bank abruft und in eine Context-Datei speichert (z.B. aqbanking-cli request --transactions --ctxfile=file ), dann ist pro Transaktion immer nur das Wertstellungsdatum in der Datei vorhanden. Das Buchungsdatum fehlt leider. Gibt es eine Möglichkeit, hier dieses Feld hinzuzufügen?

Getestet mit der Volksbank Stuttgart und folgenden Versionen:
Versions:
AqBanking-CLI: 5.99.30
Gwenhywfar : 4.99.15.0
AqBanking : 5.99.30.0

History

#1 Updated by martin 25 days ago

Moin,

also bei mir sind diese Felder - date und valutaDate - beide immer gesetzt.
Koenntest Du mir vielleicht mal ein Kommunikationslog vom Abruf schicken, damit ich mir die Ausgangsdaten vor dem Parsen einmal anschauen kann? Siehe Wiki.

Bitte nur an mich direkt senden, nicht hier anhaengen.

Gruss
Martin

#2 Updated by martin 25 days ago

  • Status changed from New to Feedback

#3 Updated by jannh 21 days ago

Hallo Martin,

ich fürchte, da hier persönliche Daten unserer Vereinsmitglieder enthalten sind, kann ich diese nicht zur Verfügung stellen.

Ich habe den Log allerdings selbst mal angesehen, das ist ja Mt940 Format. Vermutlich interessiert dich folgende Zeile:
:61:190916D5,39NMSC

Oder brauchst du mehr?

Hier findet sich wohl tatsächlich nur das Valuta-Datum... Ist das unter Kontrolle der Bank, welche Information in den Nachrichten enthalten ist oder gibt's da Parameter?

Danke für deinen Einsatz jedenfalls!!

Grüße Jann

#4 Updated by martin 21 days ago

  • Status changed from Feedback to Closed

Danke, diese Zeile hat mir schon gereicht.
Tatsaechlich sendet Deine Bank nur das Wertstellungsdatum.
Ich habe AqBanking angepasst, wenn das normale Datum fehlt, wird hier stattdessen aus dem Wertstellungsdatum ergaenzt.

#5 Updated by jannh 21 days ago

Hallo Martin,

also so wie es in den Logs aussieht, schickt die Volksbank für jeden Tag einen Block von :20: bis :62F: - wenn ich also mehrere Tage auf einmal abrufen, erhalte ich mehrere dieser Blöcke. Wobei trotzdem die Felder :61: und :86: öfter vorkommen können, wenn es mehr als eine Transaktion am Tag gibt.

Sofern im Feld :61: also das Buchungsdatum fehlt, wäre es nicht besser, das Buchungsdatum aus dem Block :60F: oder eben :62F: zu nehmen?

In meinem Fall (genossenschaftliche Banken) würde das jedenfalls optimal passen, ich kann allerdings nicht sagen, wie andere Banken das handhaben. Das Wertstellungsdatum kann sich manchmal schon erheblich vom Buchungsdatum unterscheiden...

Danke und Grüße,
Jann

#6 Updated by jannh 20 days ago

Hallo nochmal,

Ich habe mir nochmal den swift940 Parser angeschaut und folgendes gefunden:
https://github.com/aqbanking/aqbanking/blob/12efe1ea3f6056fc6109a82ce529fea86f8aaab2/src/libs/plugins/parsers/swift/swift940.c#L978

An dieser Stelle wird versucht, das Buchungsdatum aus dem Feld :60F: als Default für die Buchungen des Ganzen Tages zu verwenden, falls im Feld :61: kein Buchungsdatum genannt ist. Das hat in den pre-PSD2 Versionen von aqbanking auch funktioniert (wir hatten vorher 5.7.8 in Benutzung). Jetzt fehlt das Buchungsdatum aber im Context.

:60F:D190920EUR1733,09
:61:190920C100,00NMSC

Das wäre nochmal der relevante Ausschnitt des Kommunikationslogs. Beide Daten sind eigentlich vorhanden. Meines Erachtens ist das eine Regression, können wir den Bug wieder öffnen?

Danke für eure super Arbeit!

Grüße Jann

#7 Updated by martin 20 days ago

  • Status changed from Closed to In Progress

Moin,

danke fuer den Hinweis. Okay, ich werde mir das in den naechsten Tagen noch einmal anschauen.

Das Problem ist halt bei manchen Banken, dass sie nur ein eintiges 60er Tag verwenden, dann kommen alle Umsaetze fuer den gesamten abgefragten Zeitraum, und am Ende noch ein Endsaldo. Dann stimmen die Daten natuerlich ueberhaupt gar nicht mit den anzunehmenden echten Daten ueberein...

Aber die Chancen stehen ja nicht schlecht, dass das ausgerechnet bei solchen Bank nicht auch noch der Fall ist, wenn sie schon keine Daten in den anderen Feldern liefern...

Habe das Ticket entsprechend wieder geoeffnet (haettest Du aber auch machen koennen, wenn das Problem aus Deiner Sicht noch nicht abgeschlossen ist).

Gruss
Martin

#8 Updated by jannh 20 days ago

Hallo Martin,

ich hab mir das gerade angesehen und den Patch im Anhang gebaut. Der löst zumindest bei uns das Problem.

Es scheint, als ob in der bisherigen Implementierung die Variable dbDate immer Null bleibt und daher das Buchungsdatum aus Feld 60F nicht in die Transaktionen übernommen wird. Zumindest sagen das die Logmessages, die ich mit rein gebaut hatte. Es kam also gar nie dazu, dass in den "if dbDate" Block hineingesprungen wurde.

Den Overwrite konnte ich jetzt nicht testen, da die Volksbank im Feld 61 ja kein Buchungsdatum schickt.

Bezüglich Status ändern: Ich sehe hier nichts, wo ich das tun könnte... Vielleicht fehlen mir da Rechte oder ich bin blind ;-)

Danke fürs Ansehen vom Patch!

Grüße Jann

#9 Updated by admin 20 days ago

  • Assignee set to martin
  • Priority changed from Normal to High

Moin,

ah, da fehlten Berechtigungen. Habe die jetzt am eingetragen, danke fuer den Hinweis.
Zum Patch:

Da werde ich zumindest einen Teil uebernehmen, zumindest den letzten, wo das Datum als Default gestzt wird. Da muss ich noch einmal in den Gesamtcode schauen. Werde die Prioritaet des Bugs mal hochsetzen.

Vielen Dank!

#10 Updated by martin 19 days ago

  • Status changed from In Progress to Resolved

Moin,

sollte jetzt im aktuellen git aber gefixed sein...

Gruss
Martin

#11 Updated by jannh 19 days ago

Hallo Martin,

ich habs mit dem aktuellen Master nochmal getestet und es ist alles wie erwartet.

Danke für deine Arbeit!

Grüße Jann

P.S.: Ich hab nun zwar einige Dinge, die ich per Dropdown ändern kann (z. B. Priorität, zugewiesen an, Beschreibung, Zielversion), der Status des Bugs ist allerdings nach wie vor nicht veränderbar. Aber du kannst hier natürlich schließen.

#12 Updated by martin 18 days ago

  • Status changed from Resolved to Closed

Also available in: Atom PDF