Closed zachgoll closed 4 months ago
See #892 for some additional context around this. I'll be doing namespace changes prior to this implementation.
+1 !
I was really surprised about seeing, that Maybe does not (yet) support Investments / Investment Portfolios – I was under the impression that was the main purpose for Maybe ^^ So very much looking forward to this!!
@oliveratgithub yep, the prior version of Maybe was heavily focused on investments from the get-go. This rework will also put a huge emphasis on investing, but we've started with a lot of the budgeting/transactions stuff early on so we can support all types of use cases for users across different walks of life!
In order to support portfolio management, we will need to introduce an
InvestmentTransaction
type.Account "Entries"
To support this new hierarchy, I came up with the following delegated types hierarchy:
Base "Entry"
In this schema, an
Account::Entry
represents anything that affects anAccount
value. Each "Entry" will have a common set of attributes:date
name
amount
- either a user-inputted or calculated value of the transaction in a specific currencycurrency
- the currency thatamount
is represented inaccount_id
Naming rationale
I had originally come up with
Account::Event
for this base model, but I now believeAccount::Entry
is a more appropriate name. An "event" is too generic and could easily collide with non-financial (i.e. has noamount
field) events on an account such as a "creation", "closure", "sync", or even "edit"s.Additionally, an "Entry" fits well in the finance space as it overlaps with the accounting concept of a "Journal Entry" or "Ledger Entry" that indicates a change to the account's value.
Valuation Entries
This will require a slight refactor as the existing sync process incorporates both transactions and valuations.
Right now, this will be an empty model, but in the future will hold metadata about the valuation (i.e. valuation source, valuation method, etc.)
Transaction Entries
Represents a regular transaction, often an "income" or "expense" transaction that can have categories, tags, merchants, and other "budgeting" related metadata.
category_id
merchant_id
transfer_id
- optionally, can be a transferTrade Entries (investment)
Represents a buy/sell/other "stock trade" entry.
qty
- quantity sold/purchased of a securityprice
- price of security on date of transactionsecurity_id
subtype
- not 100% sure on the naming of this, but would represent things liketrade
,tax
, etc.Crypto Entries
This will not be implemented here for this issue, but is a preview of how this hierarchy might work as we incorporate new event types like a "crypto trade"