Remove tax unit groupings.

[MImmesberger]

Closes #690

[lars-reimann]

Regarding this comment:

@lars-reimann Can you have a look where the CondaVerificationError in the readthedocs check comes from?

I could not reproduce this locally. It seems to be caused by the upgrade of sphinx-automodapi to version 0.17.0. In previous, successful runs version 0.16.0 was used. Maybe you can add an upper bound for sphinx-automodapi in environment.yml in this PR and try again?

- sphinx-automodapi<0.17.0

[lars-reimann]

That seems to have fixed the install issue at least.

[MImmesberger]

Yes, I guess the other errors are due to this incomplete PR. Thanks!

[hmgaudecker]

Just a couple of remarks while browsing the changes.

[MImmesberger]

I don't think there are particular tests you have to look at.

Just so it doesn't sneak through the review process: In 1d78ded, I set the minimum relevant income for ALG2 to 0. There were some test cases that resulted in negative values after getting rid of tu.

[MImmesberger]

The rounding seems to be an issue when switching from eink_st_y_sn / 12 to eink_st_m_sn, because rounding parameters are expected for the eink_st_m_sn key in the param yaml. They are specified for the eink_st_y_sn key only.

I'm not entirely sure what the expected behavior should be:

1. First round and then time convert (with optional rounding spec for converted column).
2. First time convert and then round (We could use a quick fix by specifying the eink_st_m_sn rounding spec in the params yaml).

Because eink_st_m_sn is used as an approximation for Lohnsteuer (at least for Elterngeld and Grundsicherung; not sure about ALG2) we cannot infer expected behavior from the law.

[hmgaudecker]

Just so it doesn't sneak through the review process: In 1d78ded, I set the minimum relevant income for ALG2 to 0. There were some test cases that resulted in negative values after getting rid of tu.

Cool, thanks for the pointer. In principle, I think that ALG II should guarantee a consumption floor, but it might be that the mechanism for that is more complicated. I would have no idea. But I'd kind of like to guarantee that subsistence level (thinking of running GETTSIM on models that do require a positive consumption), unless the law is different.

If possible, I'd prefer to revert and make an issue that we'll need to investigate this case.

[hmgaudecker]

The rounding seems to be an issue when switching from eink_st_y_sn / 12 to eink_st_m_sn, because rounding parameters are expected for the eink_st_m_sn key in the param yaml. They are specified for the eink_st_y_sn key only.

I'm not entirely sure what the expected behavior should be:

1. First round and then time convert (with optional rounding spec for converted column).

2. First time convert and then round (We could use a quick fix by specifying the `eink_st_m_sn` rounding spec in the params yaml).

Because eink_st_m_sn is used as an approximation for Lohnsteuer (at least for Elterngeld and Grundsicherung; not sure about ALG2) we cannot infer expected behavior from the law.

Behavior 1. and the last two cases we should get rid of eventually now that we have Lohnsteuer.

[MImmesberger]

The rounding seems to be an issue when switching from eink_st_y_sn / 12 to eink_st_m_sn, because rounding parameters are expected for the eink_st_m_sn key in the param yaml. They are specified for the eink_st_y_sn key only.
I'm not entirely sure what the expected behavior should be:

1. First round and then time convert (with optional rounding spec for converted column).

2. First time convert and then round (We could use a quick fix by specifying the `eink_st_m_sn` rounding spec in the params yaml).

Because eink_st_m_sn is used as an approximation for Lohnsteuer (at least for Elterngeld and Grundsicherung; not sure about ALG2) we cannot infer expected behavior from the law.

Behavior 1. and the last two cases we should get rid of eventually now that we have Lohnsteuer.

@lars-reimann Can you have a look?

[hmgaudecker]

@lars-reimann Can you have a look?

Would be great, but let's do that separately from here. Apologies if that means reverting something I noted. Also fine to skip a couple of tests for the moment.

[MImmesberger]

Cool, thanks for the pointer. In principle, I think that ALG II should guarantee a consumption floor, but it might be that the mechanism for that is more complicated. I would have no idea. But I'd kind of like to guarantee that subsistence level (thinking of running GETTSIM on models that do require a positive consumption), unless the law is different.

I think we are talking about different things here. I realized that the issue I raised is solved once we fix #606 because it makes sure that we don't compute negative "anrechenbares Erwerbseinkommen" on the individual level.

[hmgaudecker]

Great work!!! Thanks a ton.

[hmgaudecker]

Can you make a note of this somewhere? My point is that we simply should think about some value other than zero for people who do not have potentially eligible children. Probably tackle in #704, but we should remember explicitly to change this condition.