Bug #312
offenAutomatic conversion from '-' to '.' in the purpose field when retrieving transactions
Beschreibung
I have used aqbanking-cli to retrieve transactions from Ing DIBA. The "Purpose" field of the transaction shows
xxx-yyyyyyy-zzzzzzz AMZN Mktp DE .......with numbers for [x,y,z].
When I download this transaction with aqbanking-cli request, I get the following message
char purpose="xxx.yyyyyyy.zzzzzzz AMZN Mktp DE ...."i.e. the hyphens are converted to dots. Is this intentional, or is this a bug that should be fixed?
$ aqbanking-cli versions
Versions:
AqBanking-CLI: 6.5.4
Gwenhywfar : 5.9.0.0
AqBanking : 6.5.4.0
Von rhabacker vor mehr als 1 Jahr aktualisiert
Running aqbanking-cli with "verbous" loglevel shows:
7:2024/08/13 22-00-03:aqbanking(24672):swift.c: 350: Creating tag "86" (005?00Lastschrifteinzug?...?20EREF+...?21MREF+R
7:2024/08/13 22-00-03:aqbanking(24672):rYFK)i?...?220Vz?9opu?23CRED+...?24SVWZ
7:2024/08/13 22-00-03:aqbanking(24672):+xxx.yyyyyyy.zzzzzzz AM?25ZN Mktp DE ... PA
7:2024/08/13 22-00-03:aqbanking(24672):YMENTS EUROPE S.C.?33A.)
Dots are also used at this point. Perhaps this will help to find the cause more easily.
Von ipwizard vor 12 Tagen aktualisiert
Within an application using AqBanking (KMyMoney) I don't see this conversion. This transaction dates back to Feb 25.
AqBanking log shows:
::86:835?20SEPA-BASISLASTSCHRIFT SV?21WZ+ 305-2385456-0917124 AMZN Mktp DE G8QNRH4ND0HSDSBL
Transaction in KMyMoney shows:
305-2385456-0917124 AMZN Mktp DE G8QNRH4ND0HSDSBL
Versions used:
gwenhywfar: 5.12.0.0
aqhbci: 6.6.0.0stable
Von rhabacker vor 12 Tagen aktualisiert
I retested with aqbanking-cli
$ aqbanking-cli versions Versions: AqBanking-CLI: 6.6.1 Gwenhywfar : 5.12.0.0 AqBanking : 6.6.1.0
and still got
$ aqbanking-cli request --aid=xxx --fromdate=20251001 --transactions
...
char remoteName="AMAZON PAYMENTS EUROPE S.C.A."
char date="20251017"
char valutaDate="20251017"
...
int transactionCode="5"
char transactionText="Lastschrifteinzug"
char transactionKey="MSC"
int textKey="0"
char purpose="028.7899086.8633917 AMZN Mktp DE 4QW6YZX1WR3Y8YV4"
...
which differs from your observations. I also checked this with KMyMoney from master branch with the same result.
verbose logging shows:
7:2025/11/09 12-25-12:aqbanking(5079):swift.c: 350: Creating tag "86" (005?00Lastschrifteinzug?10006220?20EREF+4QW6YZX1WR3Y8YV4?21MREF+R 7:2025/11/09 12-25-12:aqbanking(5079):rYFK)i?Xsf24qR0lNgieb?220Vz?9opu?23CRED+DE94ZZZ00000561653?24SVWZ 7:2025/11/09 12-25-12:aqbanking(5079):+028.7899086.8633917 AM?25ZN Mktp DE 4QW6YZX1WR3Y8YV4?32AMAZON PA 7:2025/11/09 12-25-12:aqbanking(5079):YMENTS EUROPE S.C.?33A.) 7:2025/11/09 12-25-12:aqbanking(5079):swift.c: 292: End of tag reached
Von rhabacker vor 10 Tagen aktualisiert
I checked my aqbanking settings for Ing Diba according to https://www.aquamaniac.de/rdm/projects/aqbanking/wiki/SetupPinTan#ING, but did not find anything unusual. What I did notice is that the HBCI URL on the page mentioned is outdated.
Then I checked my aqbanking configuration to see if there were any settings related to this, but I couldn't find any.
One visible difference between the two variants is the specified transaction type.
::86:835?20SEPA-BASISLASTSCHRIFT
verse
005?00Lastschrifteinzug?1
Are there any tips on how to proceed?
Since the problem also exists with KMyMoney and it is therefore more difficult to find the corresponding order for a financial transaction (you can no longer click on a link assigned to the recipient), I will add a workaround to KMyMoney for the time being.