Closed dev590t closed 1 month 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
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.
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
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.
Thanks
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.