Align parsers and separate out implied purchase code

[michielbdejong]

The parsers should produce a list of transactions with:

• from (iban / other)
• to (iban / incassant / description / other)
• amount
• date
• extra data
  • transaction type
  • rest of description

[michielbdejong]

Should use the HalfTrade class there.

[michielbdejong]

The HalfTrades should then also know how to de-dupe themselves. So they really only make sense in a WorldLedgerView where they can 'meet to de-dupe'

[michielbdejong]

The world ledger contains departures and arrivals. A WorldLedgerView may contain unmatched Arrivals, unmatched Departures, and matched Departure-Arrival pairs. A file can contain an exhaustive sequential list of Departures and Arrivals for a given account. it can even be useful to know a file covers a certain period for a given account but has no entries, so begin and start date of the file should also be recorded.

[michielbdejong]

And then there are implied purchases and budget assignments but it's possible to import and parse bank statements without generating those.

There's also account balance (between a person and a bank) which gets updated with each Departure and Arrival in that person's bank account.

[michielbdejong]

How can we store the transactions for an account, knowing gaps may exist that may be filled in later? We should probably use chunks with:

• account
• start date
• end date
• exhaustive list of transactions for that period
• start balance (optional)

Note that this assumes a Y-shaped relationship between Arrivals (left), Account Bank (center), Account Holder (bottom), and Departures (right).

[michielbdejong]

Maybe a bit more general, a WorldLedgerViewChunk (WLVC) has:

• a list of accounts exhaustively covered (DID for the account, optionally start balance)
• a contiguous time period (start/end date)
• a list of mutations
  • account,
  • book datetime (optionally, index within that),
  • amount,
  • other data (optional)