firefly importer uses wrong "Opposing account (name)" when importing csv file

[jschom]

Hi,
i setup fireflyiii & importer using docker compose. Everything seems working fine except one thing:

When using the data importer to import csv file from my bank the transactions are being imported but for some the "Opposing account (name)" is set to the one from another transaction.

Example:
there is this correctly imported line in the csv (german bank):
"24.02.2023";"24.02.2023";"Kartenzahlung";"Deutsche Post";"2023-02-23 Debitk VISA Debit";"DE00000000000000000";"BBBBBBBBB";"-3,80";"";"";"1234567890123";

The opposing account name is correctly set to "Deutsche Post"

After some correctly imported lines, the following line is imported:
"20.02.2023";"20.02.2023";"Kartenzahlung";"Lidl Dienstleistung";"2023-02-18 Debitk VISA Debit";"DE1111111111111111111";"AAAAAAAAAA";"-29,57";"";"";"9876543210987";

In this and additional cases (all of them "Kartenzahlungen") the opposing account name is set incorrectly to "Deutsche Post".

I noticed that there are some spaces in the "Description" part in the csv line.

Anyone an idea what to change or is it a bug?

[JC5]

It's difficult to say from the input. But the logs of the data importer it will clearly show (per transaction) why it picks a specific name, or what it sends to Firefly III.

[jschom]

Thx for the quick response.
By "logs of the data importer" you mean to access the transactions like this:
https://demo.firefly-iii.org/transactions/debug/123 ?

This unfortunately does not work in my setup because it shows the docker internal IP in the overview.
If i replace the internal IP/port with the exposed IP/port i get a 404.

Is there any way i can access it?

[jschom]

Ok, i found the logs :-)

in the importer logs it looks fine i guess. Here is the entry which is show with a wrong opposing name:

[2023-04-16 14:28:48] local.DEBUG: Now at column 4/12
[2023-04-16 14:28:48] local.DEBUG: Now at column #4 (opposing-name), value "Lidl Dienstleistung"
[2023-04-16 14:28:48] local.DEBUG: ColumnIndex is 3
[2023-04-16 14:28:48] local.DEBUG: Value is 'Lidl Dienstleistung'
[2023-04-16 14:28:48] local.DEBUG: Local mapping (will not be printed)
[2023-04-16 14:28:48] local.DEBUG: Column #4 with role "opposing-name" is not mapped.

Mapping is not enabled in the configuration of the import.
I have several rules in firefly but only to set the category.

If i read the logs correct the change of opposing name happens in firefly rather than in the imorter...

[JC5]

So... share those logs please?

[jschom]

i found the problem.

If something is payed with the Debit Visa card the bank DKB always sets the same account number (IBAN) and Bank code (BIC) in the transaction.
Firefly recognizes the Account name for the first time such a transaction occurs correctly.
For the other debit card transactions firefly sees the same IBAN and BIC and uses the account name from the first transaction.

Can this behaviour be changed with some settings or is a change in code necessary?

edit: same problem is discussed here (language german): https://microsoft.public.de.money.narkive.com/ftgHUowj/dkb-keine-empfangerzuordnung-bei-nutzung-der-debitkarte

[JC5]

Can this behaviour be changed with some settings or is a change in code necessary?

Use the mapping function to map names to expense accounts. This requires that these expense accounts already exist.

You can also choose not to set the 'opposing account iban' role so the field gets ignored

[jschom]

not setting oppposing account iban does the job, thanks for your support!
So far firefly looks nice so also thank you for developing it!

[GrigoriOH]

So first of: Hello and thanks a lot for this amazing piece of software - Just found out about it and am already amazed by what it is capable of!

I am having the same problem like jschom, where nordigen delivers DKBs confusing VISA-Debit data to FIDI (1). This gets handed over to Firefly III (2) where some magic happens and the correct destination_name gets overwritten.

Interestingly, all VISA-Debit transactions (I have 3 asset accounts with a total of 4 VISA-Debit cards) link to the same IBAN, hinting that DKB uses this IBAN internally. Maybe @jschom can confirm this? For reference: The IBAN used in my case looks like DE96**************0904.

I was thinking about the suggestion to "not setting oppposing account iban", but am not sure where and if this also applies to other transactions, where IBAN might be of interest, especially for rules and automation. Maybe there is a possibility to block a specific IBAN from being mapped automatically?

1:

 [2023-10-02 17:22:08] production.DEBUG: [8/36] Parsing transaction (3)  
 [2023-10-02 17:22:08] production.DEBUG: Description is now remittanceInformationUnstructured  
 [2023-10-02 17:22:08] production.DEBUG: Nordigen transaction: "2023-09-28T14:39      Debitk.39 2099-12 Zahl.System VISA Debit" with amount EUR -38.40  
 [2023-10-02 17:22:08] production.DEBUG: Returning value date for getValueDate  
 [2023-10-02 17:22:08] production.DEBUG: Returning book date  
 [2023-10-02 17:22:08] production.DEBUG: Returning book date  
 [2023-10-02 17:22:08] production.DEBUG: Description is now remittanceInformationUnstructured  
 [2023-10-02 17:22:08] production.DEBUG: Amount is negative: assume transfer or withdrawal.  
 [2023-10-02 17:22:08] production.DEBUG: Now in App\Services\Nordigen\Conversion\Routine\GenerateTransactions::appendAccountFields($transaction, $entry, "destination")  
 [2023-10-02 17:22:08] production.DEBUG: App\Services\Nordigen\Model\Transaction::getDestinationIban  
 [2023-10-02 17:22:08] production.DEBUG: isValidIBAN("-->[IBAN-that-is-used-by-all-VISA-Debit-payments]<--")  
 [2023-10-02 17:22:08] production.DEBUG: Trim: isValidIBAN("-->[IBAN-that-is-used-by-all-VISA-Debit-payments]<--")  
 [2023-10-02 17:22:08] production.DEBUG: Destination IBAN is "-->[IBAN-that-is-used-by-all-VISA-Debit-payments]<--" (creditor)  
 [2023-10-02 17:22:08] production.DEBUG: App\Services\Nordigen\Model\Transaction::getDestinationNumber  
 [2023-10-02 17:22:08] production.WARNING: Transaction "3bc0dc9f2b9993857683f2718b79532f" has no destination BBAN information.  
 [2023-10-02 17:22:08] production.DEBUG: App\Services\Nordigen\Model\Transaction::getDestinationName  
 [2023-10-02 17:22:08] production.DEBUG: Destination name is "RESTAURANT STEAKHOUSE" (creditor)  
 [2023-10-02 17:22:08] production.DEBUG: Done collecting account numbers and names  
 [2023-10-02 17:22:08] production.DEBUG: "-->[IBAN-that-is-used-by-all-VISA-Debit-payments]<--" is not a valid IBAN OR not recognized as Firefly III asset account so submitted as-is.  
 [2023-10-02 17:22:08] production.DEBUG: IBAN is "-->[IBAN-that-is-used-by-all-VISA-Debit-payments]<--", so leave field "destination_iban" empty.  
 [2023-10-02 17:22:08] production.DEBUG: Field "destination_name" will  be set to "RESTAURANT STEAKHOUSE".  
 [2023-10-02 17:22:08] production.DEBUG: Set field "destination_iban" to "-->[IBAN-that-is-used-by-all-VISA-Debit-payments]<--".  
 [2023-10-02 17:22:08] production.DEBUG: "" is not a valid account nr OR not recognized as Firefly III asset account so submitted as-is.  
 [2023-10-02 17:22:08] production.DEBUG: Account number is "", so leave field "destination_number" empty.  
 [2023-10-02 17:22:08] production.DEBUG: Field "destination_name" will  be set to "RESTAURANT STEAKHOUSE".  
 [2023-10-02 17:22:08] production.DEBUG: End of App\Services\Nordigen\Conversion\Routine\GenerateTransactions::appendAccountFields  
 [2023-10-02 17:22:08] production.DEBUG: Check if "RESTAURANT STEAKHOUSE" is mapped to an account by the user.  
 [2023-10-02 17:22:08] production.DEBUG: Its not mapped by the user.  
 [2023-10-02 17:22:08] production.DEBUG: Parsed Nordigen transaction "3bc0dc9f2b9993857683f2718b79532f". {
    "type":"withdrawal",
    "date":"2023-09-29",
    "datetime":"2023-09-29T00:00:00+02:00",
    "amount":"38.400000000000",
    "description":"2023-09-28T14:39      Debitk.39 2099-12 Zahl.System VISA Debit",
    "payment_date":"2023-09-29",
    "order":0,
    "currency_code":"EUR",
    "tags":[],
    "category_name":null,
    "category_id":null,
    "notes":"",
    "external_id":"3bc0dc9f2b9993857683f2718b79532f",
    "internal_reference":"",
    "additional-information":"",
    "source_id":15,
    "destination_name":"RESTAURANT STEAKHOUSE",
    "destination_iban":"-->[IBAN-that-is-used-by-all-VISA-Debit-payments]<--"} 
 [2023-10-02 17:22:08] production.DEBUG: [8/36] Done parsing transaction.  

2:

 [2023-10-03T01:41:12.642412+02:00] local.INFO: AUDIT: Store new transaction over API. ([redacted ip] ([redacted]@[redacted]) -> POST:http://[redacted hostname]/api/v1/transactions){
 "group_title":"",
 "error_if_duplicate_hash":true,
 "apply_rules":true,
 "fire_webhooks":true,
 "transactions":[{
    "type":"withdrawal",
    "date":"2023-09-29T00:00:00+02:00",
    "order":0,
    "currency_id":null,
    "currency_code":"EUR",
    "foreign_currency_id":null,
    "foreign_currency_code":"",
    "amount":"38.400000000000",
    "foreign_amount":"",
    "description":"2023-09-28T14:39      Debitk.39 2099-12 Zahl.System VISA Debit",
    "source_id":15,
    "source_name":"",
    "source_iban":"",
    "source_number":"",
    "source_bic":"",
    "destination_id":null,
    "destination_name":"RESTAURANT STEAKHOUSE",
    "destination_iban":"-->[IBAN-that-is-used-by-all-VISA-Debit-payments]<--",
    "destination_number":"",
    "destination_bic":"",
    "budget_id":null,
    "budget_name":"",
    "category_id":null,
    "category_name":"",
    "bill_id":null,
    "bill_name":"",
    "piggy_bank_id":null,
    "piggy_bank_name":"",
    "reconciled":false,
    "notes":"",
    "tags":[],
    "internal_reference":"",
    "external_id":"3bc0dc9f2b9993857683f2718b79532f",
    "original_source":"ff3-v6.0.26|api-v2.0.9",
    "recurrence_id":null,
    "bunq_payment_id":"",
    "external_url":"",
    "sepa_cc":"",
    "sepa_ct_op":"",
    "sepa_ct_id":"",
    "sepa_db":"",
    "sepa_country":"",
    "sepa_ep":"",
    "sepa_ci":"",
    "sepa_batch_id":"",
    "interest_date":null,
    "book_date":null,
    "process_date":null,
    "due_date":null,
    "payment_date":"2023-09-29T00:00:00+02:00",
    "invoice_date":null}
 ],
 "user":4} []

[JC5]

I was thinking about the suggestion to "not setting oppposing account iban", but am not sure where and if this also applies to other transactions, where IBAN might be of interest, especially for rules and automation. Maybe there is a possibility to block a specific IBAN from being mapped automatically?

No to both options I'm afraid, in this case you're own your own. This usually happens when the same payment provider (ie. Molly or Adyen) is behind the transaction, they have 1 IBAN but use different names (usually the shop name). There's nothing I can do about that, although I know that banks have been promising better transaction management in these cases.

[GrigoriOH]

So, if I understand that correctly, the option of blocking all IBANs being mapped from Nordigen imports is also not possible, but only available for CSV imports?