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 5 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 5 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 3 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.