Detalles (Obligatorio)
Propósito de la sección:
Explicar de manera clara y comprensible qué se hizo y por qué, desde el punto de vista del usuario o del negocio.
Qué debe contener:
- 1 o 2 párrafos cortos (no bullets).
- Lenguaje no técnico o mínimamente técnico.
- Enfocado en el problema que existía y la mejora introducida.
- Si aplica, mencionar el área/módulo donde se encuentra el cambio (sin usar nombres internos de módulos).
- Debe contener por lo menos una imagen.
Guía para redactar (estructura sugerida):
- Situación previa (breve):
- “Antes, los usuarios experimentaban…”
- Qué se hizo (resumen del cambio):
- “Se mejoró / corrigió / ajustó…”
- Resultado esperado (beneficio general):
- “Esto permite…”, “Con esto se logra…”.
¿Qué cambia? (Obligatorio)
Propósito de la sección:
Desglosar de forma clara y accionable los cambios más relevantes en formato de lista.
Qué debe contener:
- Entre 1 y 5 bullets como máximo.
- Cada punto debe iniciar con un verbo en pasado:
- “Se mejoró…”, “Se corrigió…”, “Se optimizó…”, “Se agregó…”, “Se ajustó…”
- Enfocado en cambios visibles o relevantes para el usuario.
Guía para redactar:
Cada bullet debe responder a una de estas preguntas:
- ¿Qué ahora funciona mejor?
- ¿Qué error se corrigió?
- ¿Qué nueva capacidad tiene el usuario?
Detalle técnico (Opcional)
Propósito de la sección:
Documentar cambios internos relevantes que no son necesarios para todos los usuarios, pero sí útiles para soporte, auditoría o desarrollo.
Usar cuando:
- Hay cambios de librerías, arquitectura o lógica interna.
- El cambio puede ser relevante para troubleshooting futuro.
- Se requiere trazabilidad técnica.
Qué debe contener:
- 1 a 3 bullets como máximo.
- Lenguaje técnico aceptable.
- Evitar detalles excesivamente bajos (logs, funciones internas específicas).
- Se mejora el método para obtener utilidades debido a que puede existir el escenario donde la utilidad se creo con otro empleado, actualmente mejoramos para buscar las líneas de utilidad por número de identificación
- Se contempla el escenario de diferentes contratos en un mismo periodo, realizando una búsqueda de todos los contratos y agrupándolos por número de identificación, para realizar la búsqueda de todas las nóminas que se generaron con esos contratos
- Se refactoriza el método _compute_income_base_and_tax que genera los valores de impuesto a la renta causado para el RDEP, para que realice los cálculos en un orden similar a las reglas, con redondeo de forma que no tengamos diferencia de centavos con las reglas salariales
Ticket: # 39655
Generación de Anexo de retenciones en la fuente RDEP