Pedido de Pablo (28 Abr)
La idea es que formal sea descuento jubilatorio e informal lo contrapuesto.
Definición actual implementada (Fase 4 del épico #6)
En `ETL/01-extract.R:21-25` se construye la variable `formalidad` solo para asalariados (`CAT_OCUP == 3`):
```r
formalidad = case_when(
CAT_OCUP == 3 & PP07H == 1 ~ 1L, # Formal: asalariado con aportes
CAT_OCUP == 3 & PP07H == 2 ~ 2L, # Informal: asalariado sin aportes
TRUE ~ NA_integer_
)
```
Es decir, hoy el análisis solo cubre asalariados (definición clásica OIT acotada). Cuenta propia, patrón y trabajador familiar quedan fuera (NA).
Cambio pedido
`Formal` y `Informal` deberían definirse por descuento jubilatorio, sin acotar a una categoría ocupacional. La idea es bajar la fricción cognitiva del análisis: el usuario filtra por "tiene/no tiene descuento" y listo.
Preguntas abiertas a resolver antes de implementar
- Universo: ¿la definición se aplica a toda la población ocupada o sigue siendo solo asalariados? `PP07H` se pregunta solo a asalariados en la EPH; para no-asalariados habría que evaluar otras variables (monotributo, autónomos, etc.).
- No-asalariados: ¿se consideran formales los cuenta propia con monotributo (paga jubilación)? ¿Qué variable refleja esto en EPH? Habrá que mirar `PP04D`, `PP07J`, `PP07K` o equivalentes.
- NA: ¿qué hacer con los casos donde no se puede determinar (no-asalariados sin info)? ¿Excluir o categorizarlos como "Sin determinar"?
- Caption del gráfico: `mod_analisis_formalidad.R:217` dice "Definición clásica: PP07H sobre asalariados (CAT_OCUP=3)". Hay que actualizarlo según la nueva definición.
- Histórico pre-computado: `data_output/panel_formalidad_historico.csv` se generó con la definición anterior (`ETL/06-build_panel_formalidad.R`). Hay que regenerarlo con la nueva definición.
Archivos afectados
- `ETL/01-extract.R:21-25` (construcción de `formalidad`)
- `ETL/06-build_panel_formalidad.R` (script que pre-computa el histórico)
- `R/mod_analisis_formalidad.R` (caption + posibles ajustes en filtros si cambia el universo)
- `data_output/panel_formalidad_historico.csv` (regenerar)
Prioridad
Media. La app ya muestra el análisis con la definición anterior; el cambio es una mejora de claridad conceptual, no un bug bloqueante.
Pedido de Pablo (28 Abr)
Definición actual implementada (Fase 4 del épico #6)
En `ETL/01-extract.R:21-25` se construye la variable `formalidad` solo para asalariados (`CAT_OCUP == 3`):
```r
formalidad = case_when(
CAT_OCUP == 3 & PP07H == 1 ~ 1L, # Formal: asalariado con aportes
CAT_OCUP == 3 & PP07H == 2 ~ 2L, # Informal: asalariado sin aportes
TRUE ~ NA_integer_
)
```
Es decir, hoy el análisis solo cubre asalariados (definición clásica OIT acotada). Cuenta propia, patrón y trabajador familiar quedan fuera (NA).
Cambio pedido
`Formal` y `Informal` deberían definirse por descuento jubilatorio, sin acotar a una categoría ocupacional. La idea es bajar la fricción cognitiva del análisis: el usuario filtra por "tiene/no tiene descuento" y listo.
Preguntas abiertas a resolver antes de implementar
Archivos afectados
Prioridad
Media. La app ya muestra el análisis con la definición anterior; el cambio es una mejora de claridad conceptual, no un bug bloqueante.