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:

class Account::Entry < ApplicationRecord
  belongs_to :account

  delegated_type :entryable, types: %w[ Valuation Transaction Trade CryptoTrade ]
end

module Account::Entryable
  extend ActiveSupport::Concern

  included do
    has_one :entry, as: :entryable, touch: true
  end
end

# Point-in-time valuation of an account
class Valuation < ApplicationRecord
  include Account::Entryable
end

class Transaction < ApplicationRecord
  include Account::Entryable
end

# i.e. buy/sell of AAPL
class Trade < ApplicationRecord
  include Account::Entryable
end

# Future extension, will not be implemented yet
class CryptoTrade < ApplicationRecord
  include Account::Entryable
end

Base "Entry"

In this schema, an Account::Entry represents anything that affects an Account 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 currency
• currency - the currency that amount is represented in
• account_id

Naming rationale

I had originally come up with Account::Event for this base model, but I now believe Account::Entry is a more appropriate name. An "event" is too generic and could easily collide with non-financial (i.e. has no amount 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 transfer

Trade Entries (investment)

Represents a buy/sell/other "stock trade" entry.

• qty - quantity sold/purchased of a security
• price - price of security on date of transaction
• security_id
• subtype - not 100% sure on the naming of this, but would represent things like trade, 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"