Open michielbdejong opened 3 years ago
Following discussion at Federated Bookkeeping Weekly Call, I realised that the format/ontology in which personal finance data is stored in a user's pod, needs not be standardised at all. We can use a 'data lake approach' and store the raw messages/imports along with metadata about them, but not transforming the data before storing it to the user's pod.
The code then transforms the data on the fly, to produce the desired view to the end-user.
At most, there may be an intermediate data format to cache, but this could then be much closer to the view than you would normally do for a data(base) schema in a stand-alone software system.
data sources that go into a view:
code modules:
The parsers generate Entry
s and information about completeness of the view for some dates
Merging and Matching brings data from all sources together into one big list, and filters out the duplicates.
Implied transactions, budgets, and depreciation add three types of additional transactions:
To what extent is this bookkeeping system federated? It's nice that expenses and time sheets can be federated between organisation and employee. This is probably also possible for virtual organisations. invoices can be sent with e-invoicing we could experiment with federated timesheets
should I continue this work in PHP?
Ha, thanks to @paul-french we discovered https://plaintextaccounting.org/ and https://hledger.org/ - will try out if we can switch to that!
Wow, this is very valuable already: https://github.com/simonmichael/hledger/tree/master/examples/csv
And more importers listed on https://plaintextaccounting.org/#data-importconversion
There is quite some code in run.js and chart.html and it uses similar but incompatible data formats. Should tie those together! Would Cambria be useful for that? Or maybe bring it all back to the HalfTrade class and improve that?