gbonnema / rabo2ofx Goto Github PK

On ubuntu 20.04 running the script throws this error

ImportError: No module named configparser

Problem
The problem occurs when you download your main account and your savings account transactions and process them in the same bookkeeping program. Chances are your bookkeeping program will register the transfers between you main and savings account twice. The consequence is an incorrect status of both the main and the savings account. For my account management program (GnuCash) this is certainly true. I would like to hear from other users how their account management program processes these transfers.

Solution
There is no solution that would satisfy everyone and is watertight in its recognition of a transfer.

Having said that, there is a way to guess, but it depends on both transactions being available in the same file.

So:

• either both transactions are downloaded simultaneously and end up in the same file,
• or we store all transactions in a database, that can produce all ofx records and thus recognize transfers.
• or we exclude transfers from the download file (manually).

Except for the cumbersome manual solution, I do not know a simple way to solve this automatically. Both solutions require an overhaul and saving transactions in a database make for a much more complex program. Also it gets more dependencies.

The manual solution in the case of a savings account implies downloading only interest and bank cost transactions and leaving all other transactions out. For 2 different main accounts it may be more complex.

Rabo
The rabo could simply solve it, because the Rabo knows it is a transfer. Especially when transferring from main to savings account and back, they could prevent misunderstandings by making sure I can recognize transfers. Currently they don't. I will bring this issue to their attention, but don't expect them to respond any time soon with any significant response.

When dealing with the Rabo most responses include: "we have sent your request to the IT department" and "sorry, we do not track progress on the issue".

Decision
I am still to decide what to do.

Testing the script I ran into a problem with the reconciliation. In my current workflow I import a month of transactions and reconcile the account to match the account statement of the Rabobank. This runs smoothly. After import the new balance amount always equals the ending balance of the statement. This workflow is in line with the format description of the Rabobank and their email response (01-datum-20180410-Uw-klacht.txt). It may not be 100% in line with accounting principles, but it works very well for me.

However, the reconciliation of my test run failed because there was a transaction with a different processing and value date. As documented, this script uses the value date (interest date) instead of the processing date. This unfortunately prevents matching ending balances in case these dates are in separate months.

It would be great if this script can be used to reconcile imports per month as described above. Is it possible to add an option to this script that enables the user to choose the processing date or the value/interest date as the date for the transaction in the ofx file (<DTPOSTED>)?

Many thanks for this python script, @gbonnema. Great work.
I have been testing it (in Windows 10), in order to kill my Excel-copy-paste workflow for importing Rabo transactions. I have a question about the second booking line as a result of the import. E.g.:
OFX ext. info: |Trans type:Transfer|Memo:Studietoelage Xxxx + Yyyy
This line is not recognized by GnuCash. Could it be caused by the fact that there is no space between Memo: and Studietoelage?
Is it possible to add spaces after the colons by default, so that GnuCash recognizes the imported bookings based on previous imports?