martinohansen / ynabber Goto Github PK

I'd like YNABber to just run one time instead of polling. This would make it possible to run, for example, as a scheduled task.

Even running once per hour would be quite often as there are not so many bank transactions.

It could be accomplished, for example, by interpreting YNABBER_INTERVAL==0 as meaning run only once.
In fact, it now creates a continuous loop if set to zero.

Hi,

It seems Nordigen changed, and is not free and not supporting SolarisBank in Germany.

There is any alternative to keep pushing transactions to YNAB?

What would be the best way to renew the requisitions? It's easy to forget if one expires at least if it needs to be renewed monthly. Is it any way to automatically extend the renewal time so we don't have to renew it?

Or maybe a way to send pull a simple API how many days until it needs to be renewed?

There has been discussion and various attempts to make modifications to where YNAB payee data actually comes from.
The current implementation uses parts of RemittanceInformationUnstructured i.e. parts of what goes to Memo.

This is an issue for the author of this ticket and also apparently for the user who made PR #10 as well.

There are also several branches with suggested solutions. The primary ones being:

• use creditorName/debtorName as payee - never use RemittanceInformationUnstructured
• as above but use the normal behavior as fallback if there is nothing in creditorName or debtorName
• bank id specific coding

The first two were apparently not good for at least the repository owner usage. The coding by bank is likely hard to maintain and would require constant modification if/when new banks are being used.

For me the current solution is memo is nonetheless useless and I have to fix all payees by hand(mostly they are empty).
I am opening this issue so that we could avoid yet another attempt and instead discuss the appropriate solution first with perhaps some insight from other users.

Backwards compatibility may be an issue but I am not against breaking it on occasion. Even big companies (Microsoft/Apple) do it on occasion and the userbase here is miniscule. Just make this something that works for current users and seems right for the near future without too much maintenance.

Currently ynabber.json is the only file in data directory and its structure does not support multiple banks.
Making a rerun using the same data directory with different bank settings results in reusing the data from the old run.

It should be possible to use multiple banks on different sessions even if they share the data directory.

Is it possible to add multiple banks to the same instance (f.eks in docker), or do I need to run one docker instance pr bank?

I am facing this problem with NORWEGIAN_FI_NORWNOK1 - possibly it affects other banks as well.

The requisition creation proceeds normally up to the point when the browser display https://raw.githubusercontent.com/martinohansen/ynabber/main/ok.html . But then the command line client remains stuck forever(or until timeout).

I tried with another bank and that works. Do you have any idea what might be going on?

I already have debugging on but nothing is displayed on console.

The situation with datafile naming has greatly improved now that it is bank specific.

However, I enocuntered a situation where you may need two different logins for different set of bank accounts on same bank. This may happen at least if you are budgeting with your spouse and you have different credit cards on same bank - the same thing with accounts if your spouse does not have at least read access to your accounts.

This may also happen if you have both personal and business accounts on same bank which you want to have in YNAB. You may be required to use a different login to access the business accounts.

This could be resolved by letting user to overdrive the default name by specifying NORDIGEN_DATAFILE which would allow you to specify differant datafiles(and thus logins) for different set of accounts even though they are in the same bank.

I'll get to this eventually but can be commented here.

Hi,

Thanks for the great tool.
However I only get transaction amount and with no data in memo its pretty hard to make sense of it

Is data from my bank structured in an unexpected way ?
How can I find out and patch ?

Thanks in advance for considering this issue :)

For bank id SEB_KORT_AB_NO_SKHSFI21 outflow and inflow columns in YNAB are swapped so purchases appear as inflow and refunds/downpayments appear as outflow.

This is a credit card so the logic is probably reversed from the card issuer compared to a normal account.

Here are two examples with the response from Nordigen along with the imported transactions in YNAB:

Heyhey,

I regularly have the problem that my YNABBER is doing nothing after showing the following logs:

2024/01/03 17:31:26 Successfully sent 257 transaction(s) to YNAB. 0 got skipped and 114 failed.
2024/01/03 17:31:26 Run succeeded
2024/01/03 17:31:26 Waiting 5m0s before running again...
2024/01/03 17:36:27 Found 2 accounts

The docker container shows no action after 2024/01/03.

My requisiton status seems to be "LN" according to the persisted json file.

Any ideas?

If Nordigen, for any reason, fails to pass on the requisition after being authenticated by the user it will hang forever.

We need to add better error checking and inform the user if something is wrong.

Originally posted by @hpernu in #49

This result:

"transactionAmount": {
"amount": "-3899",
"currency": "DKK"
}
is imported into ynab as 38,99

where as:

"transactionAmount": {
"amount": "-397.03",
"currency": "DKK"
},
is imported as 397,03

This is needed as I otherwise get conflicting file names in data directory.

The specific need here is that I have two user accounts to same bank. They need a different requisition and login credentials.
So naming the file just based on BIC code is not enough.

Transactions are sometimes lost and never imported to YNAB. I was able to track this to the way YNAB import id is generated.

Specifically, when the exact same sum on same date is done with the same memo (or empty memo) this will generate the same id. This is fairly common, for example, with transactions between account of my own and sometimes there are those within a same date. I also pay invoices in batches. Sometimes they have the same amount causing the same id even though they are actually to different counterparties. Or sometimes I transfer the same amount to multiple accounts of my own and ynabber only detects this once (on both ends).

Suggest using something more unique. There is, for example the id coming from Nordigen. Although this might have duplicates between banks, I doubt they have any duplicates within a single bank. A hash of, for example, the following data should surely be enough:

• IBAN of the account in question(this already narrows it down to a single account)
• the transaction id from Nordigen(will probably already make it unique but I don't know whether it is seen on all banks - likely so)
• for extra measure, we can also put in payee and memo

For backwards compatibility, though, we have to only start generating new style ids from an agreed upon future date. Otherwise the old transactions would reappear. A suggested date here could be any transaction date greater than 2022-12-01.
This needs to be configurable though for testing purposes.

Any opinions?

Discussed in #72

"bookingDate": "2024-04-22",
"valueDate": "2024-04-22",

{"error":{"id":"400","name":"bad_request","detail":"date must not be in the future or over 5 years ago (index: 0), date must not be in the future or over 5 years ago (index: 1)"}}

If a session to a particular bank has already been established and/or you've selected accounts that you actually don't have in account map, reader may skip importing data to some accounts.

The reader goes through all of the accounts it has established a connection with Nordigen API. If the account is found on account map, the transacation are read. If not, it skips the account and all the rest of the accounts are skipped as well.
If the account map happens to contain accounts which are on start of the internal order the reader is using (i.e. in the order it got from Nordigen API), then no accounts are skipped.

This is not considered an error.

The behavior is not consistent and is dependant on the order of accounts from Nordigen API. This order is outside of user control.
The user also cannot effectively modify the account map if he/she decided to remove one account from imports. This might or might not work depending on the order they have been fetched via Nordigen API.

Instead of skipping all the rest of accounts after a single miss, reader should instead go to next account. This will allow the modification of the account map(or at least removal of accounts) without reinitializing Nordigen connection.

This is likely a single line change.

In latest version v0.7.1 transactions from Sparebank 1 Østlandet are multiplied in ynab. From my first investigations it seems like the ynabber doesn't honor the "InternalTransactionId" environment variable, which is needed for sane behavior with Sparebank 1

NORDIGEN_TRANSACTION_ID=InternalTransactionId

Hei Martin,

I was informed about your project today and conducted a quick test with SEB Kort Bank, which powers lots of credit cards, including the SAS Eurobonus card.

The transactions were successfully parsed and written to YNAB using the default mapper. However, they were written to YNAB as inflows instead of outflows. The transactions are returned as positive values from Nordigen.

Instead of creating a new mapper for this particular bank or provider, you could consider adding a configuration option to invert the sign (+/-) of the transaction's 'Amount' field whenever you have the inclination in the future, which I assume would rectify the problem.

/mike

One of my banks are Sparebank 1 Østlandet. They are making uncleared transactions available, but I would like to filter those out, since they don't contain proper payee information. It seems like the "debtorAccount" is missing on the uncleared transactions, so if it could be configurable to ommit transactions without "debtorAccount", that would be a great feature.