Some people have individual stocks that have been around for many years and have a very small basis. Then they have other savings accounts and what to know if the stock should be sold first or later.

For example: http://forum.mrmoneymustache.com/taxes/wrote-a-retirement-calculator-because-i-orp-com-didn't-do-what-i-want/msg1460616/#msg1460616
(In this example, I don't think the modeling would have mattered much)

We can model multiple after-tax accounts to answer this question. Add this issue to give people a place to request this feature.

Running with --validate does the following:

C:\Users\cmovi\AppData\Local\Programs\Python\Python39\python.exe C:/Users/cmovi/Documents/github/cmovic-fplan/src/fplan/fplan.py ..\..\examples\sample.toml --validate
Traceback (most recent call last):
  File "C:\Users\cmovi\Documents\github\cmovic-fplan\src\fplan\fplan.py", line 510, in <module>
    main()
  File "C:\Users\cmovi\Documents\github\cmovic-fplan\src\fplan\fplan.py", line 506, in main
    for y in range(1,nyears):
NameError: name 'nyears' is not defined

Should this be fixed? It doesn't appear to do anything - if that's the case can it be removed?

I suspect some users (or at least one) have an aftertax account where they receive distributions every year even when they don't sell anything. Could this be modeled with a percent dividend parameter?

This is making me wonder if this is why i-orp has a separate capital gains column.

Some taxes have a progressive tax system, similar to federal taxes. The program currently only supports a single state tax rate. It should support state brackets.

Also you should be able to specify the state standard deduction when it is different from the federal standard deduction.

The current model has a 'minimum' spending level and sets up the constraints so that every year has at least that much money to spend. The model maximizes that min spending level.

But this leaves a lot of decisions unconstrained as we probably only have some years that are critical for that min level and other years where the spending options don't matter as much. We should add a secondary constraint that the model minimizes the amount of taxes paid.

Like max: spending + total_tax / years / 10

Or perhaps maximizing the money left at the end will do the same thing...

Right now the toml file is used for setting but any extra unused settings are just ignored and most everything has a default value.

So if you make a typo in your file that value will just be ignored and it might not be obvious.

A nice feature would be to print a warning about any data items in the user's toml file that are not used. One way to do this would be to delete each key as it is used and then print warnings about anything remaining. Also include warnings about any keys that have the wrong type.

There are different capital gains tax brackets, but the program assumes that all cap gains are taxed at 15%.

A web app to allow a user to manage the information from the input file and present the results would make this solver a lot more accessible to people.

This would be something I host on my own perhaps with donations or ads to pay for the overhead.

Hi, I'm Vic. I'd like to contribute to the fplan project but I'm deathly afraid of breaking something. I think adding a unit test framework and some simple tests is a start toward building up a robust test environment where I and others will feel more comfortable making changes and having some knowledge that the wheels aren't coming off the train.

I've got experience with pytest so that's an easy place to start. I'm open to other testing frameworks but hope to keep this change simple.

I'm proposing that we create a test top level directory and that it mirrors src and looks something like this:

$ ls -R src test
src:
fplan

src/fplan:
fplan.py

test:
fplan

test/fplan:
test_load_file

test/fplan/test_load_file:
test1.toml  test_load_file.py

pytest runs everything named test_*.py and *_test.py so the test source files can be simple and isolated from each other. There can be multiple directories in test/fplan for specific tests and their data. The example above contains some simple tests for the Data class load_file() function. Adding some solver tests seems like an obvious next step. Repeat as necessary until we have good coverage.

The desired use of this tool is similar to James Welch's 3PEAT scheme for i-orp.com. Basically, you rerun it each year and adjust the current spending as the projections change over time.

I need to add a testing mode to demonstrate that rerunning the tool with fixed returns gives the same results as the original plan at the beginning of the period. Then we can use that feature to simulate using the tool over some historic period in the past. By running simulations over all possible periods from the last 100 years we should be able to select reasonable rules of thumb about what values should be used for returns and inflation.

A good solution is one where the variation in spending level from one year to the next is as low as possible. We don't want to be giving up possible spending, but a safety margin is needed to minimize the adjustments that are needed during market downturns.

In the 3PEAT paper, a 100% stock investment strategy was assumed. A study framework like this can be used to investigate using a stock/bond mix of investments with yearly rebalancing. It would be interesting to see if there is a sweet spot that obtains much of the average gain from 100% stocks but reducing the variation from market downturns. Similarly, I can see if there is a way to optimally select stock/bond ratios by age rather than just following common wisdom.

Another approach to this type of optimizer is to have the user list the desired spending level for each year and have the program maximize the estate left to heirs at the end of the plan.

The spending level would need to be low enough to be feasible, and it would need an assumed tax bracket for the heir. Then the total after estate taxes would be the result being maximized.

The model should consider IRA2Roth conversions during the working years. You would have to provide a baseline AGI instead of the current prep.tax_rate so it can figure the tax impact of additional income from an early conversion.

It would be nice to give people a spreadsheet with all the balances and taxes computed automatically and summary statistics and then fill in the numbers from the model. This way the user that disagrees with an early Roth conversion (for example), they can try changing it and seeing if they can come up with a better plan. It would let them play and see for themselves. Perhaps that is just my engineering brain and "normal" people wouldn't do this...
I might play with something like this http://xlsxwriter.readthedocs.io/ to generate a spreadsheet for the output.

The idea of this tool is that you rerun in every year with updated balances to plan what to do each year. So it plans 30 years in the future, but you only use the first year of the plan. But currently, if we do a Roth conversion we can't record that in the input so that future runs of this tool will know when that contribution is available to spend.

My plan is to have something like this in the input:

[roth]
bal = 100000    # current balance
contrib = [[ 45, 20000],   # previous contributions in [age, ammount] pairs
           [ 46, 10000],
           [ 47, 10000]]

Then the tool would know that contributions can be spent 5 years after they are added before age 59.5.

But the syntax seems a bit awkward.

Some people have a pension with a sliding scale where they can enable it on different years where the longer they wait the larger the yearly payout. Similarly, Social Security has a sliding scale. It can be started as early as age 62 or benefits can be delayed until age 70 for a larger payout.

An example of this is the following discussion on the MMM forums.

It would be good if this tool would examine the options a select the best option for a user.

The law has changed and RMDs no longer begin at 70 for everyone. The program should be updated to reflect that.

The current code allows either an IRA distribution or a Roth conversion to exceed the RMD, but I now believe that Roth conversions don't count so I need to change that part.

Aftertax contributions during your working years are not accurately reflected in the capital gains tax basis. The capital gains tax basis is based on the initial values of the aftertax account. Working year contributions should cause this tax basis to change but the contributions have no impact.

(I suspect that this would be almost impossible to model in the current program and make very little difference to most users.)