Currently, Forecast determines income, gross contributions, contribution reductions, net contributions, withdrawals, and tax treatment, in that order. The semantics here have two problems:
It's not intuitive that "gross contributions" includes a lot of things that would typically be thought of as living expenses and which don't contribute to net worth; and
The proposed refactoring in #40 makes it hard to manage debt repayments, since they're lumped in with other reduction amounts but require handling by the top-level Forecast.
It seems like an opportunity to clarify the basic financial model of the software. I propose moving to something like this:
Determine total (net) income for the year.
Determine the portion of net income used for ordinary living expenses.
Determine the portion of net income used for "lifecycle" expenses. These are expenditures on top of ordinary living expenses which vary over time. Inflows to retirement savings accounts are reduced to pay for these. This can include, e.g., childcare, contributions to education accounts, home purchase costs, and so on.
Determine "gross contributions" for the year by deducting lifestyle expenses and ordinary living expenses from net income. This is the total amount saved, including debt repayments as a form of savings.
Determine per-account debt repayments based on gross contributions. Assign these to the accounts.
Determine "net contributions" by deducting the sum of debt repayments from gross contributions. This is the total amount contributed to retirement accounts.
Determine per-account retirement contributions based on net contributions. Assign these to the accounts.
Determine the total amount withdrawn from retirement savings accounts.
Determine per-account withdrawals based on total withdrawals. Assign these withdrawals to the accounts.
Determine total tax liability for the year; if necessary, adjust withdrawals accordingly and repeat.
Determine statistics for the year (e.g. living standard.)
Note that Forecast doesn't necessarily do all of these things; consider whether some functions (like determining and assigning per-account transactions) should be handled by other classes as part of the refactoring process (see #40).
Currently,
Forecastdetermines income, gross contributions, contribution reductions, net contributions, withdrawals, and tax treatment, in that order. The semantics here have two problems:Forecast.It seems like an opportunity to clarify the basic financial model of the software. I propose moving to something like this:
Note that
Forecastdoesn't necessarily do all of these things; consider whether some functions (like determining and assigning per-account transactions) should be handled by other classes as part of the refactoring process (see #40).