-
Notifications
You must be signed in to change notification settings - Fork 75
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
Handle individuals using different period structures for the same variable. #564
Comments
Thank you for this bug report, we are going to work on fixing this bug. In the mean time, if you use the same input for both individuals, the API should return a valid output. For instance, for the example you mentioned, this should work: TLDR: Bill's 2015 {
"familles": {
"famille_1": {
"enfants": [
],
"parents": [
"Bill",
"Bob"
]
}
},
"foyers_fiscaux": {
"foyer_fiscal_1": {
"declarants": [
"Bill",
"Bob"
],
"personnes_a_charge": [
]
}
},
"individus": {
"Bill": {
"salaire_de_base": {
"2017": 20000
},
"tns_auto_entrepreneur_chiffre_affaires": {
"2016": 0,
"2016-08": 0,
"2016-09": 0,
"2016-10": 0,
"2016-11": 0,
"2016-12": 0,
"2017-01": 0,
"2017-02": 0,
"2017-03": 0,
"2017-04": 0,
"2017-05": 0,
"2017-06": 0,
"2017-07": 35000,
"2017-08": 35000,
"2015": 35000
}
},
"Bob": {
"tns_auto_entrepreneur_chiffre_affaires": {
"2015": 6000,
"2016": 6000,
"2016-08": 0,
"2016-09": 0,
"2016-10": 0,
"2016-11": 0,
"2016-12": 0,
"2017-01": 0,
"2017-02": 0,
"2017-03": 0,
"2017-04": 0,
"2017-05": 0,
"2017-06": 0,
"2017-07": 0,
"2017-08": 0
}
}
},
"menages": {
"menage_1": {
"conjoint": [
"Bob"
],
"enfants": [
],
"impots_directs": {
"2017": null
},
"personne_de_reference": [
"Bill"
],
"revenu_disponible": {
"2017": null
}
}
}
} |
The computation are vectorized so every variable is treated the same way independently of the individual. |
There is none right now, but the web API could preprocess the input before vectorialization. |
The use case I submitted previously is tricky "tns_auto_entrepreneur_chiffre_affaires": {
"2016": 6000,
"2016-08": 0,
"2016-09": 0,
"2016-10": 0,
"2016-11": 0,
"2016-12": 0
} However, to me, it is reasonable to expect the following payload to be handled without trouble {
"individus": {
"b": {
"salaire_imposable": {
"2016-11": 2556,
"2016-12": 2556,
"2016-07": 2556,
"2016-06": 2556,
"2016-05": 2556,
"2016-04": 2556,
"2016-03": 2556,
"2016-02": 2556,
"2016-01": 2556,
"2016-09": 2556,
"2016-08": 2556,
"2016-10": 2556
}
},
"a": {
"salaire_imposable": {
"2016": 23411.64
}
}
},
"foyers_fiscaux": {
"_": {
"declarants": [
"a",
"b"
],
"irpp": {
"2018": null
}
}
},
"menages": {
"_": {
"personne_de_reference": [
"a"
],
"conjoint": [
"b"
]
}
},
"familles": {
"_": {
"parents": [
"a",
"b"
]
}
}
}
Is that a fair expectation? Many thanks! |
It seems possible to hack it in, we'd need to add your case to test_entities.py as a new unit test. I'm not entirely sure it's desirable as a long-term solution; It seems to me that the solution suggested above by @fpagnoux (preprocess input representations, for instance to transform a value specified for the year into 12 values for each month) would be a better way to go. It's a cleaner separation of concerns and we could (I think we should) simplify Holders by getting rid of |
It is indeed. I'm moving this issue forward in our pipeline, and I've good hope we should be able to deliver by the end of the month. I don't see any potential blocking issue on the implementation side. In the piece of code that builds a vectorial simulation from the JSON-like object, we just need to merge the inputs for different persons/households before building the vector, so that the default value is only applied to persons for which no input was specified. |
Hi there!
I really enjoy OpenFisca, but I recently encountered an issue.
Here is what I did:
I sent the following payload to the preview API:
Here is what I expected to happen:
To return without error.
Here is what actually happened:
I get:
tns_auto_entrepreneur_chiffre_affaires legislation.openfisca.fr/code relies on
set_input_divide_by_period
.For Bob a normalization is required as data is provided annually on 2015.
For Bill a normalisation is not required as data is provided monthly on 2015.
That discrepancy seems to be the origin of the problem.
Context
I identify more as a:
(remove this line as well as all items in the list that don't fit your situation)
The text was updated successfully, but these errors were encountered: