BUG: Replace `_tu` grouping

Question

BUG: Replace `_tu` grouping

Closed this issue 10 months ago · 24 comments

Answer 1 · 2024-02-29T16:38:57.000Z

Hopefully this is all correct, but let me know if something seems off @hmgaudecker

I'll update the list if something comes up.

Answer 2 · 2024-02-29T16:50:14.000Z

kinderbonus_m_tu changes to kinderbonus_m_sn

I think that should just follow kindergeld

Answer 3 · 2024-02-29T16:50:23.000Z

The PR for this likely closes #683, #670
Potentially also #270

Related to #606

Answer 4 · 2024-02-29T16:53:27.000Z

anz_kinder_mit_kindergeld_tu changes to number of Kindergeld claims on _sn level

Does Kindergeld or Kinderfreibetrag matter here or both, @JakobWegmann? In any case, it should be the versions at individual level, if we have them.

Answer 5 · 2024-02-29T17:00:23.000Z

Elterngeld

Net income calculation should be based on lohnst_m, not eink_st_y_tu

Note: Even then the calculation is slightly off compared with the simplified rules described here. Might be something for a different PR.

Yeah. Big one. I still believe this should go altogether and become an input we require from prior calculations. Typically $t-1$. In any case, don't worry much about it in this PR.

Answer 6 · 2024-02-29T17:03:38.000Z

Grundsicherung im Alter
Income checks on the _tu level should be replaced with _sn. But this is just an approximation because i) there might be couples that do not file taxes together but are considered as a couple for Grundsicherung, ii) income of the partner is not considered if the partner cannot satisfy her own needs.

I wonder whether we should support another grouping, like "married" or "einstandspartner" ?

Since 2020, income of children is not considered, even if it is higher than 100.000 € (S. 5 §43 SGB XII).

Yeah, I think we can ignore that until somebody actually needs it. But maybe add a note in the function?

Answer 7 · 2024-02-29T17:10:34.000Z

I wonder whether we should support another grouping, like "married" or "einstandspartner" ?

I agree, especially as we have p_id_einstandspartner as an input variable already. Just learned, that this would be the correct grouping for Grundrente as well (doesn't matter if taxes are filed jointly).

Answer 8 · 2024-02-29T17:18:22.000Z

alleinerz_tu should change to alleinerz_sn and can be determined endogenously.

Leave as is for now (AFAICT, alleinerz is the input variable), make endogenous in a different PR.

Answer 9 · 2024-02-29T17:39:39.000Z

anz_kinder_mit_kindergeld_tu changes to number of Kindergeld claims on _sn level

Does Kindergeld or Kinderfreibetrag matter here or both, @JakobWegmann? In any case, it should be the versions at individual level, if we have them.

I'm 98% sure that only the Kinderfreibetrag matters. I think the law is very clear.

Answer 10 · 2024-02-29T17:42:37.000Z

Elterngeld

Net income calculation should be based on lohnst_m, not eink_st_y_tu

Note: Even then the calculation is slightly off compared with the simplified rules described here. Might be something for a different PR.

Yeah. Big one. I still believe this should go altogether and become an input we require from prior calculations. Typically t−1. In any case, don't worry much about it in this PR.

The parental leave calculation in my Stata code matches the calculation, so I think I can at least fix the calculation in GETTSIM as soon as all these changes are implemented.

Answer 11 · 2024-02-29T18:16:15.000Z

Elterngeld

Net income calculation should be based on lohnst_m, not eink_st_y_tu

Note: Even then the calculation is slightly off compared with the simplified rules described here. Might be something for a different PR.

Yeah. Big one. I still believe this should go altogether and become an input we require from prior calculations. Typically t−1. In any case, don't worry much about it in this PR.

The parental leave calculation in my Stata code matches the calculation, so I think I can at least fix the calculation in GETTSIM as soon as all these changes are implemented.

Yes, but given our annual structure, I suppose the better approximation is not to use concurrent income, right?

Answer 12 · 2024-02-29T19:00:39.000Z

Yes, I agree it would be more intuitive and less error prone to have an additional input.

Answer 13 · 2024-02-29T19:11:49.000Z

It should be an output, though! But not in this PR, @MImmesberger, can you open an issue for that, please?

Answer 14 · 2024-02-29T19:57:08.000Z

It should be an output, though!

Just to make sure I understood that correctly: it should be an output for convenience (when calculating the inputs for t in t-1), i.e. it would not be used as an input for another function?

Answer 15 · 2024-03-01T04:58:27.000Z

Not in the concurrent year, no. But in the subsequent year.

Say I have panel data for 2023 and 2024 and I want to calculate Elterngeld for kids born in 2024. This would proceed as follows:

Run GETTSIM on 2023 data, output elterngeld_eink_relev_current_m .
Call this variable elterngeld_eink_relev_lag_m and run GETTSIM on 2024 data using it as an input.

We'll need to have a suitable distinction of the names, this suggestion is bogus, of course.

Answer 16 · 2024-03-01T09:25:46.000Z

Great! This looks like a big step forward!

I wonder whether we should support another grouping, like "married" or "einstandspartner" ?

I agree, especially as we have p_id_einstandspartner as an input variable already. Just learned, that this would be the correct grouping for Grundrente as well (doesn't matter if taxes are filed jointly).

AFAIK, unmarried partners are considered for Grundsicherung im Alter, but not Grundrente. So I guess we needed three groupings (which should be all available from the input data):

sn; filing tax together -> taxes
married partners -> grundrente
einstandspartner/einstandsgemeinschaft; partners living together -> Grundsicherung im Alter

Answer 17 · 2024-03-01T14:47:09.000Z

(I updated the original post following our discussion. Also, I added the two new groupings that are needed)

Answer 18 · 2024-03-03T13:45:31.000Z

For ALG2 (_bg grouping), the Wohngeld priority check should still be on the _hh level for Wohngeld, correct? I'm referring to this function:

def wohngeld_vorrang_hh(
    wohngeld_nach_vermög_check_m_hh: float,
    arbeitsl_geld_2_vor_vorrang_m_bg: float,
) -> bool:
    """Check if housing benefit has priority.

    Parameters
    ----------
    wohngeld_nach_vermög_check_m_hh
        See :func:`wohngeld_nach_vermög_check_m_hh`.
    arbeitsl_geld_2_vor_vorrang_m_bg
        See :func:`arbeitsl_geld_2_vor_vorrang_m_bg`.

    Returns
    -------

    """
    return wohngeld_nach_vermög_check_m_hh >= arbeitsl_geld_2_vor_vorrang_m_bg

Answer 19 · 2024-03-03T13:53:44.000Z

For ALG2 (_bg grouping), the Wohngeld priority check should still be on the _hh level for Wohngeld, correct?

Not quite. It is possible that some individuals in a household receive Wohngeld and others receive Bürgergeld.

To my understanding, Wohngeld is calculated at the household level but can be broken down to individual values. For the priority check, these should be aggregated at the _bg level and compared there. Does that seem correct, @mjbloemer @michaelhebsaker ? Would you have a reference of how to distribute Wohngeld across household members?

Answer 20 · 2024-03-04T09:59:12.000Z

A married indicator would be useful as well.

Should this be called married or verheirat? I'd wager this should go into demographic_vars.py, right?

Answer 21 · 2024-03-04T10:20:09.000Z

A married indicator would be useful as well.

Should this be called married or verheirat? I'd wager this should go into demographic_vars.py, right?

I think I'd use ehe_id. Short enough and very clear.

Answer 22 · 2024-03-04T10:21:30.000Z

So, ehe_id instead of spouse_id and no additional boolean married variable?

Answer 23 · 2024-03-04T10:43:36.000Z

Ah, sorry, I had not read through @MImmesberger's updates to the main issue. Yes, I think ehe is clearer, also since we are using German identifiers for the other groupings.

Instead of an extra indicator we can check for p_id_ehepartner >= 0, right? Should be easy enough, rather not add an extra variable.

Answer 24 · 2024-03-04T10:47:31.000Z

Instead of an extra indicator we can check for p_id_ehepartner >= 0, right? Should be easy enough, rather not add an extra variable.

Yes, that was the implementation of married anyway. I'll remove it again.

BUG: Replace `_tu` grouping

Bug description

eink_st_y_tu

soli_st_y_tu

abgelt_st_y_tu

Kinderbonus

Lohnsteuer

Freibeträge

Vorsorgeaufwand

zu_verst_eink

Arbeitslosengeld

Elterngeld

Erziehungsgeld

Grundrente

Grundsicherung im Alter

Kindergeld

Unterhaltsvorschuss

Wohngeld

ALG II

Kinderzuschlag