redstreet / beancount_reds_importers

Simple ingesting tools for Beancount (plain text, double entry accounting software). More importantly, a framework to allow you to easily write your own importers.
GNU General Public License v3.0
115 stars 39 forks source link

[Feature Request] Support JSON File to able to import from Open Banking API #106

Closed dev590t closed 1 month ago

dev590t commented 2 months ago

Today, thanks to the open banking project, we have universal APIs that allow for the quick and reliable download of transactions from multiple bank accounts.

The open-source accounting software Firefly III already integrates with some free open banking APIs. For more information, you can visit the Firefly III Documentation. An example of an open banking aggregator that could be interesting is GoCardless. GoCardless supports many PSD2-compliant banks in the EU and the UK, and it is free to use.

Supporting JSON format in the beancount_reds_importers could allow users to write just one institution-specific declarations and code for one open banking aggregator, and enabling them to import data for all their bank accounts.

jonnyniv commented 2 months ago

There is already a WIP JSON reader in the main branch, but it's specific to the Schwab format https://github.com/redstreet/beancount_reds_importers/blob/a9e5323159716a633f4cfc4ea412f75bfb52f4a2/beancount_reds_importers/libreader/jsonreader.py#L8

I wonder if guessing isn't the right answer, but instead make the subinstance of the reader define a method which returns an iterator of transactions. Then it's up to the importer to interpret the JSON blob.

It shouldn't be too hard to copy the example code and make a JSON reader if you need one now as well

redstreet commented 2 months ago

I wonder if guessing isn't the right answer, but instead make the subinstance of the reader define a method which returns an iterator of transactions. Then it's up to the importer to interpret the JSON blob.

+1, very much so. @dev590t, see the xmlreader which does exactly this. The IBKR importer uses it, as seen here.

It shouldn't be too hard to copy the example code and make a JSON reader if you need one now as well

Agreed again. @dev590t, if you do this, PR welcome to make a generic JSON reader, perhaps very similar to the xmlreader. an initial version should be trivial to do.

dev590t commented 1 month ago

I have submited a PR for JSON reader.

About GoCardless reader based on JSON reader, which example do you recommand, the data schema the I get from API is less rich than IBKR: I don't have info like balance, or account id.

Here is a example of data:

{
  "transactions": {
    "booked": [
      {
        "transactionId": "202400900002BD27-0025518",
        "entryReference": "202400900002BD27-0025518",
        "bookingDate": "2024-09-28",
        "valueDate": "2024-09-27",
        "transactionAmount": {
          "amount": "-10.50",
          "currency": "EUR"
        },
        "remittanceInformationUnstructuredArray": [
          "COTIS",
          "XCCNV067 2024092700025518000001",
          "CONTRAT CNV0055910671"
        ],
        "bankTransactionCode": "ACMT-MDOP-COMM",
        "internalTransactionId": "f821931fa21970695530cc375cf945ea"
      }
    ],
    "pending": []
  }
}

Here is complete schema specification: https://developer.gocardless.com/bank-account-data/transactions

redstreet commented 1 month ago

Hi there, Any csv importer would be a good example. Schwab, for instance.

Balances are not mandatory for any importer. If you don't have a get_balance_statement() function in your importer, a balance assertion will not be generated.

account_id is used for identifying files. As long as you have some other way (usually based on the filename), you don't need one.

dev590t commented 1 month ago

Thanks