Kindergeldübertrag #751

MImmesberger · 2024-05-04T08:37:08Z

What problem do you want to solve?

Closes #742

The implementation will still rely on manually removing children from their Bedarfsgemeinschaft (via eigenbedarf_gedeckt) until the corresponding issue #622 has been addressed.

(This PR is based on #744)

…ests accordingly.

…trag.

src/_gettsim/transfers/arbeitsl_geld_2/kindergelduebertrag.py

codecov · 2024-05-04T08:45:49Z

Codecov Report

All modified and coverable lines are covered by tests ✅

Project coverage is 89.51%. Comparing base (0bcd40f) to head (fb8db7e).

Additional details and impacted files

@@            Coverage Diff             @@
##             main     #751      +/-   ##
==========================================
+ Coverage   89.46%   89.51%   +0.04%     
==========================================
  Files          51       52       +1     
  Lines        3656     3682      +26     
==========================================
+ Hits         3271     3296      +25     
- Misses        385      386       +1

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

hmgaudecker

Great work!

src/_gettsim/transfers/arbeitsl_geld_2/arbeitsl_geld_2_eink.py

src/_gettsim/transfers/arbeitsl_geld_2/arbeitsl_geld_2.py

src/_gettsim/transfers/arbeitsl_geld_2/arbeitsl_geld_2_eink.py

src/_gettsim/transfers/arbeitsl_geld_2/kindergelduebertrag.py

hmgaudecker · 2024-05-04T09:45:41Z

src/_gettsim/transfers/arbeitsl_geld_2/kindergelduebertrag.py

+
+aggregate_by_p_id_kindergeldübertrag = {
+    "kindergeld_übertrag_m": {
+        "p_id_to_aggregate_by": "p_id_kindergeld_empf",


Just thinking of a weird case here: what if Kindergeldempfänger is outside the BG? E.g. ex-partner. Is that even allowed? Do we have/need a check?

The concept of Kindergeldübertrag is that the Kindergeldempfänger is in a different BG than the child (and hence there is Kindergeldübertrag). Are you thinking about different fgs?

I.e.

p_id hh_id fg_id bg_id p_id_kindergeld_empf p_id_elternteil_1 p_id_elternteil_2 kind

0 0 0 0 -1 -1 -1 false

1 0 1 1 -1 -1 -1 false

2 0 0 2 1 0 1 true

I'd argue that this is not possible because then, the child should count towards the fg of p_id==1. But we don't have a test for that, we don't account for separated couples in the same household when creating fg_id.

Yes, I meant fg's.

Precondition for fg is living in the same household. I just wonder whether it is possible that the other parent (i.e., of parents living in separate households) gets the Kindergeld. And if not (what I'd kinda expect), whether we check that as a condition on the data.

I'll create an issue on the creation of fg_id. Intuitively, the child should form an fg with the parent that gets the Kindergeld (but could be something else of course). It's not clear to me what GETTSIM is currently doing in that regard.

I am pretty sure the fg conditions on being part of the same household. My main question is whether Kindergeld does the same when parents are separated.

Let me rephrase, that was not clear:

My main question is whether kindergeldempfänger conditions on that parent being part of the same household when parents are separated — and we are talking about means-tested transfers (ofc parents receive kindergeld for kids at college even though they may not be in the same household).

(I am just worried that the machinery here depends implicitly on this assumption being true, would like to make it explicit)

Okay so my point was that the creation of fg_id in case parents have a child, are separated but live in the same household should react to who claims Kindergeld.

Your point is that if parents live in different households p_id_kindergeldempfänger should be compatible with the place of living of the child (if such a requirement exists, presumably it does) if one of the involved individuals gets transfers?

(I am just worried that the machinery here depends implicitly on this assumption being true, would like to make it explicit)

We create neither of the variables endogenously. I'm not sure to which extent creating a consistency check here would create a circle in the DAG.

Your point is that if parents live in different households p_id_kindergeldempfänger should be compatible with the place of living of the child (if such a requirement exists, presumably it does) if one of the involved individuals gets transfers?

Exactly.

(I am just worried that the machinery here depends implicitly on this assumption being true, would like to make it explicit)

We create neither of the variables endogenously. I'm not sure to which extent creating a consistency check here would create a circle in the DAG.

Would be a check pre-DAG, just whether the data passed conforms to expectations.

But how do we check pre-DAG whether the involved individuals get transfers?

If I understood it correctly, if all involved individuals don't have their SGB II Bedarf gedeckt, we want to allow for

p_id hh_id fg_id bg_id p_id_kindergeld_empfänger kind

0 0 0 0 -1 false

1 0 0 0 0 true

2 1 1 1 -1 false

but we don't want to allow for / it would be inconsistent if

p_id hh_id fg_id bg_id p_id_kindergeld_empfänger kind

0 0 0 0 -1 false

1 0 0 0 2 true

2 1 1 1 -1 false

But if all adults have their SGB II Bedarf gedeckt, the latter situation would be perfectly fine.

Fine, let's not get carried away here. It may be more about alleinerziehend status (or, more precisely, having unterhaltsanspruch) and kindergeld, basically it is baked in there already (deduction of 1/2 kindergeld from the alimony payment). We should still think of a check for that, but no need to do it here.

As always, closing an issue by thinking through it opens at least three new ones... 😂

src/_gettsim_tests/test_data/kindergeld/2021/3_children.yaml

hmgaudecker · 2024-05-04T10:01:17Z

Is that skipped test related to #696? I thought the ALG2 comment there referred to other adults (who could work in principle), but not underage children?

MImmesberger · 2024-05-04T10:14:33Z

Yes, that's the bug we discovered some time ago. The skipped test shows that the erwachsene_alle_rentner_hh logic also fails for children because now they have a claim on the transfer themselves (I left a comment in the issue).

We could fix this with a and not kind condition in grunds_im_alter_m_eg, or address the erwachsene_alle_rentner_hh when we fix #696.

hmgaudecker · 2024-05-04T11:42:45Z

Yes, that's the bug we discovered some time ago. The skipped test shows that the erwachsene_alle_rentner_hh logic also fails for children because now they have a claim on the transfer themselves (I left a comment in the issue).

We could fix this with a and not kind condition in grunds_im_alter_m_eg, or address the erwachsene_alle_rentner_hh when we fix #696.

Cool, pick whatever is easier.

…est case for that.

…change.

hmgaudecker

Excellent! No show-stoppers left AFAICT!

hmgaudecker · 2024-05-04T15:57:29Z

src/_gettsim/transfers/arbeitsl_geld_2/kindergelduebertrag.py

+    _mean_kindergeld_per_child_m: float,
+    p_id_kindergeld_empf: np.ndarray[int],
+    p_id: np.ndarray[int],
+) -> float:


Returns an array of floats, no?

I get the following error in the _convert_data_to_correct_types when using numpy.ndarray[float]:

ValueError: The data types of the following columns are invalid: E E - kindergeld_zur_bedarfsdeckung_m: The internal type numpy.ndarray[float] is not yet supported. E E Note that conversion from floating point to integers or Booleans inherently suffers from approximation error. It might well be that your data seemingly obey the restrictions when scrolling through them, but in fact they do not (for example, because 1e-15 is displayed as 0.0). E The best solution is to convert all columns to the expected data types yourself.

Other functions in the code use numpy.ndarray[bool] as expected return and this works. Any idea @lars-reimann?

Looks like GETTSIM raises this error itself. Generally, one should never use floating point numbers to represent exact monetary values, for the reasons cited in the error message. But if a close approximation is fine, we could adjust the error.

The problem is that we check for the type of an input Series in convert_series_to_internal_type, which needs to be float, bool etc.:

277 internal_type = None 278 if column_name in TYPES_INPUT_VARIABLES: 279 internal_type = TYPES_INPUT_VARIABLES[column_name] 280 elif ( 281 column_name in functions_overridden 282 and "return" in functions_overridden[column_name].__annotations__ 283 ): 284 internal_type = functions_overridden[column_name].__annotations__["return"] 285 286 # Make conversion if necessary 287 if internal_type and not check_series_has_expected_type(series, internal_type): 288 try: 289 data[column_name] = convert_series_to_internal_type( 290 series, internal_type 291 ) 292 collected_conversions.append( 293 f" - {column_name} from {series.dtype} " 294 f"to {internal_type.__name__}" 295 ) 296 297 except ValueError as e: 298 breakpoint() 299 -> collected_errors.append(f" - {column_name}: {e}") (Pdb++) column_name 'kindergeld_zur_bedarfsdeckung_m' (Pdb++) internal_type numpy.ndarray[float] (Pdb++) check_series_has_expected_type(series, internal_type) False (Pdb++) check_series_has_expected_type(series, float) True (Pdb++) functions_overridden[column_name].__policy_info__ *** AttributeError: 'function' object has no attribute '__policy_info__'

When we use the correct type annotation for a function that is already vectorised, this fails. @lars-reimann, can you think of a sensible solution here? Probably means making a case distinction regarding the definition of internal_type on line 284 above, depending on whether the function has the skip_vectorization decorator, though I am afraid the last line of my debugging shows we haven't applied it at that point.

Other functions in the code use numpy.ndarray[bool] as expected return and this works.

Most likely we never use them as input columns in tests directly, so convert_series_to_internal_type never gets called. Although I have not checked.

@MImmesberger: I think the short-term hack here is to leave the annotation at float.

The attribute added by the decorator is called __info__, not __policy_info__. Something like this should allow detecting whether the function is vectorized:

gettsim/src/_gettsim_tests/test_docs.py

Line 139 in add6232

if hasattr(func, "__info__") and func.__info__["skip_vectorization"]:

Sorry, misremembered! Thanks!

MImmesberger added 13 commits May 4, 2024 10:10

Transfer Kindergeld back to child level.

fb60823

Prepare ALG2 deductions for new Kindergeld functions.

2fdbfb9

Add new ALG 2 income function without Kindergeldübertrag and adjust t…

5cc305a

…ests accordingly.

Add todo.

6f671c4

Fix ALG2 tests.

5feef5d

Add test without Kindergeldübertrag, add test with full Kindergelüber…

11a4f38

…trag.

Add tests for Kindergeldübertrag.

178d8e9

Add test case to raise test coverage.

23d45f1

Add bg_id as test output.

1e6eb18

Rename ALG2 income functions and split up comment.

71fb2ea

Move Kindergeldübertrag functions to new module.

ede8627

Add todo for Kinderwohngeld.

2b9cd52

Fix tests.

bec9bc9

MImmesberger mentioned this pull request May 4, 2024

Kindergeldübertrag #744

Closed

MImmesberger commented May 4, 2024

View reviewed changes

src/_gettsim/transfers/arbeitsl_geld_2/kindergelduebertrag.py Show resolved Hide resolved

Change and skip the wrong test that was discovered in #747.

31cecc7

hmgaudecker reviewed May 4, 2024

View reviewed changes

MImmesberger added 9 commits May 4, 2024 14:11

Renamings.

1696a66

Adjust docstring.

4d1d812

Make sure children don't have a claim on Grunds im Alter and unskip t…

b4d8aeb

…est case for that.

More renaming.

cd4a25f

Let structure of _mean_kindergeld_per_child_m depict the 2023 policy …

c2d0596

…change.

Style changes do kindergeld per child conditions.

1949d93

Fix test and adjust docstring.

0a129e3

Adjust test case.

f7196e0

Adjust creation of _mean_kindergeld_per_child_m for precitable results.

4804068

MImmesberger added 4 commits May 4, 2024 15:29

Add Kindergeldübertrag to SGB II income.

b6990ac

Add few tests for _mean_kindergeld_per_child_m.

7e78cd6

Remove tests for _kindergeld_erstes_kind_m

b811d29

Add missing input to test.

7a5a7bd

hmgaudecker approved these changes May 4, 2024

View reviewed changes

MImmesberger added 2 commits May 5, 2024 09:02

Use correct return type hint.

0b97162

Change return type back to float for now,

fb8db7e

MImmesberger merged commit 62f67df into main May 6, 2024
9 checks passed

MImmesberger deleted the kindergeldübertrag_new branch May 6, 2024 15:18

This was referenced May 13, 2024

Allow array returns when skip_vectorization is being used, enforce import convention. #755

Merged

ENH: test case seem to have three adults in a Bedarfsgemeinschaft #731

Closed

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Kindergeldübertrag #751

Kindergeldübertrag #751

MImmesberger commented May 4, 2024

codecov bot commented May 4, 2024 •

edited

hmgaudecker left a comment

hmgaudecker May 4, 2024

MImmesberger May 4, 2024

hmgaudecker May 4, 2024 •

edited

MImmesberger May 4, 2024

hmgaudecker May 4, 2024

hmgaudecker May 4, 2024 •

edited

MImmesberger May 4, 2024

hmgaudecker May 4, 2024

MImmesberger May 4, 2024

hmgaudecker May 4, 2024 •

edited

hmgaudecker commented May 4, 2024

MImmesberger commented May 4, 2024

hmgaudecker commented May 4, 2024

hmgaudecker left a comment

hmgaudecker May 4, 2024

MImmesberger May 5, 2024

lars-reimann May 5, 2024 •

edited

hmgaudecker May 6, 2024

lars-reimann May 6, 2024

hmgaudecker May 6, 2024

Kindergeldübertrag #751

Kindergeldübertrag #751

Conversation

MImmesberger commented May 4, 2024

What problem do you want to solve?

codecov bot commented May 4, 2024 • edited

Codecov Report

hmgaudecker left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hmgaudecker May 4, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hmgaudecker May 4, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

hmgaudecker May 4, 2024 • edited

Choose a reason for hiding this comment

hmgaudecker commented May 4, 2024

MImmesberger commented May 4, 2024

hmgaudecker commented May 4, 2024

hmgaudecker left a comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

lars-reimann May 5, 2024 • edited

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

codecov bot commented May 4, 2024 •

edited

hmgaudecker May 4, 2024 •

edited

hmgaudecker May 4, 2024 •

edited

hmgaudecker May 4, 2024 •

edited

lars-reimann May 5, 2024 •

edited