-
-
Notifications
You must be signed in to change notification settings - Fork 158
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Make TCJA current-law policy #1803
Conversation
Codecov Report
@@ Coverage Diff @@
## master #1803 +/- ##
======================================
Coverage 100% 100%
======================================
Files 37 37
Lines 3058 3064 +6
======================================
+ Hits 3058 3064 +6
Continue to review full report at Codecov.
|
This comment on pull request #1803 describes how the content of the new The first test compares a dump generated using taxcalc package 0.14.3 and The second test compares a dump generated using taxcalc package 0.14.3 and no reform (called As seen below (after showing the two scripts that execute these tests), the non-cpi_offset parameters are identical in the two dumps for both tests. Both the scripts are located in the Here is the Python script that dumps all the parameter values:
And here is the bash shell script that downloads/creates the taxcalc packages and calls
After executing the
And finally, here is the first dump file comparison:
And here is the second dump file comparison:
|
This comment on pull request #1803 describes how the 2019-2026 values are generated for 12 tax rate brackets and 5 other policy parameters whose values are inflation indexed and revert back to pre-TCJA values (computed with chained-CPI indexing) in 2026. Here is the Python script that generates the values used in the new
And here is the output generated by that script:
|
Thanks @martinholmer! I have yet to review this carefully, but wanted to mention an idea: What about adding a |
On Tue, 9 Jan 2018, codykallen wrote:
Note that this implementation of the wage limitation is only based on the data we have
and can model. I have not included the option for a tax filer to use an alternative to
PT_excl_wagelim_rt, which the TCJA sets to 50% of wages, to instead use 25% of wages
plus 2.5% of tangible depreciable property.
3. The TCJA also phases out the deduction for service businesses. So far, we've
essentially ignored this limitation because we don't have that kind of data. But
now that it's becoming law, we need to figure out a way to split the relevant
measures of business income (e00900p, e00900s, e00900, e26270) into income from
personal service businesses and other business income. But that may be more than
this PR can handle and probably requires work in taxdata.
—
Don't we also need the entity wage bill and assets. I don't see us ever
getting that until SOI releases some data. Perhaps someone at JCT would
give us a hint about what they did, perhaps we could copy them. -I don't
see how they would have any actual data on this either.
dan
|
@feenberg said:
Technically, the business income exclusion and the wage limitation apply on a per income source basis, rather than overall per filer. For example, suppose a filer has $100 of partnership income and $80 of wage income from business A, and $50 of sole proprietorship income and $10 of wage income from business B. The filer calculates the exclusion first for income from business A, and then separately for income from business B. The exclusion for income from business A is $20 ( However, we don't have data on business income source and wage income source, nor is it likely that we can get it. Therefore, I have decided to apply the wage limitation overall, rather than on a per business income source basis. |
@codykallen, Thanks for your enumeration of what needs to be added to TCJA in this comment. The changes in pull request #1803 are already complex enough that I think it is best to handle your observations in other pull requests that immediately follow #1803. I'm going to split up your #1803 comment into individual issues, which will then resolved by subsequent pull requests. Since what has been done in #1803 seems to be correct (although incomplete), I still plan to merge it on Thursday unless someone can point out a mistake. |
@martinholmer said two days ago in #1803:
Here's what's happened since I made the above comment:
So, thanks to the contributions from @codykallen, we remain on schedule to merge #1803 at the end of the day on Thursday, January 11th. |
Why does the |
@evtedeschi3 asked in merged pull request #1803:
Because when the reform is implemented in 2017 --- or typically before 2017 as in this Cookbook advanced recipe or as in the answer to question 1 of this FAQ --- the standard deduction and personal exemption values are at their pre-TCJA values, and those values are projected forward using the unchained CPI, a part of the For proof that this is what happens, see the TCJA and pre-TCJA Comparisons section of the FAQ. |
That is interesting and informative since it's contrary to my prior understanding of how tax-calculator worked. Let me ask the same question differently: if, in the CLI, I run the |
@evtedeschi3 asked:
Good question! I haven't used |
I will certainly post the results when I have them later. Doesn't this imply that theoretically a user would be unable to simulate repealing chained CPI against current TCJA law -- but keeping all other aspects of TCJA -- simply by running a reform file calling |
@evtedeschi3 said:
Great!
That's right. If you want to do that kind of reform you would have to go back to pre-TCJA law (using the The use of such a compound reform --- that is, applying two reforms sequentially to a Policy object --- is discussed in the answer to question 3 of this FAQ and in this advanced Python cookbook recipe. But we have not yet implemented the compound-reform capability in the |
@martinholmer said:
Thanks for all the clarification Martin. Yes, there's going to be debate and analysis over the TCJA from the perspective of pre-TCJA law for some time, so it would be very helpful to be able to implement compound reforms in |
@evtedeschi3 said:
OK, I'll see what I can do about moving this enhancement up from its early February scheduled implementation. Going back to basic understanding. The
Note that Step 2 implements the reform(s) over the whole analysis period, which in the current version of Tax-Calculator is 2013 through 2027. I hope this explanation helps in understanding what's going on "under the hood". |
This pull request attempts to resolve issue #1787.
At the core of this pull request are the changes in the
current_law_policy.json
file to make it reflect TCJA policy and the newreforms/2017_law.json
file that can be used to "reform" the new current-law policy into pre-TCJA policy. The methods used to ensure that these changes are accurate will be described in a subsequent comment to this pull request. Some new code was added to the Policy class to make a nonzero_cpi_offset
parameter work when it is incurrent_law_policy.json
(rather than in a JSON reform file). Also, in doing this work, one very minor change was made in thereforms/TCJA_Reconciliation.json
file to make it more closely correspond to TCJA policy; this change in the first year of the 7.5% value for the_ID_Medical_frt
parameter (from 2018 to 2017) was reviewed and approved by @codykallen, the author of thereforms/TCJA_Reconciliation.json
file.Because of the TCJA "reform-undo" in 2026, the 2019-2026 values of some inflation indexed policy parameters have been hard coded in the new
current_law_policy.json
file. As each year brings more recent known parameter values and when new economic assumptions are used, these hard-coded parameter values will need to be changed. This is not a desirable situation, but seems inevitable given TCJA's complexity and thecurrent_law_policy.json
file structure and associated logic. I will provide more details on this matter in a subsequent comment to this pull request.In order to minimize changes in the extensive testing of reforms, this pull request adds a new "baseline" field to each of the 62 reforms in the
tests/reforms.json
file and adds a "// Reform_Baseline: ..." line in each of thereforms/*.json
files. This new information is used intests/test_reforms.py
to implement a compound reform in which the first call to Policy class'simplement_reform
method is passed the "policy" dictionary fromreforms/2017_law.json
and the second call toimplement_reform
is passed the reform in question. I have also used this same compound-reform technique in three other test files in order to minimize the changes in this pull request. We can decide later whether of not the tests in these three other test files should be changed to use TCJA policy (rather than pre-TCJA policy).This is a complex set of proposed changes, so review and comments will be very helpful.
Note that pull request #1821 contains changes that should have been included in this pull request.