Más arreglos a errores de cálculos

 Lunes 16 de Junio- 5:00 PM a 7:00 PM
 Martes 17 de Junio- 5:00 PM a 7:00 PM

Los avances de estas fechas consisten en terminar de arreglar los errores de procesamiento e implementar algunas funcionalidades más secundarias al funcionamiento principal de la planilla. Esta parte del trabajo prueba ser la una de las más tediosas del proyecto, ya que consiste en:
  • revisar los empleados casi que uno por uno
  • buscar casos únicos y datos fuera de lo común (como cálculos claramente erróneos)
  • revisar la parte del código de la que se puede originar tales errores.
  • comprender la lógica desde 0 de nuevo
  • arreglar el error sin afectar a los casos donde sí funciona correctamente
  • probar los nuevos procesos (cada prueba dura alrededor de 3 o 4 minutos en cargar)  
  • evaluar los nuevos resultados
Por estas razones es que se toma tanto tiempo en arreglar cada error de cálculo. A continuación, un desgloce de los errores corregidos:
  • Cálculo de horas diurnas en jueves de cierre con cambio de jornada
    • Descripción: En el caso muy específico donde un empleado pasa de jornada diurna a nocturna y trabaja la noche del jueves del cierre, ocurrían graves errores de cálculo al no estar seguros a cuál semana se asocia esa marca de asistencia, por lo que los valores eran totalmente incorrectos (200 horas trabajadas por ejemplo). 
    • Razón: La Jornada que utilizaba era la que se asocia a la fecha de inicio (perteneciente a la semana pasada en este caso) cuando debería ser la de la fecha de fin de la jornada la cual se asocia correctamente a la semana adecuada.
    • Solución: se cambió esa simple revisión de fechas y ya no se encuentran esos errores.
  • Cálculo de deducciones obligatorias:
    • Descripción: En ninguno de los empleados ni tablas de deducciones relacionadas se encontraba que se realizara la deducción obligatoria asociada al crear un empleado pero sí se veían que existían en la tabla EmpleadoDeducción. 
    • Razón: Al insertar los empleados, no se cambió que se utilizara la fecha del proceso, si no la fecha actual de la base de datos para documentar la fecha de contratación, creyendo que no tendría mayores repercuriones en el proceso. Sin embargo, la fecha de asociación de la deducción obligatoria, según el trigger, corresponde a la fecha de contratación. Posteriomente, se revisa que la fecha actual de operación sea mayor que la fecha de asociación de la deducción. Esto evitaba que se añadieran las deducciones obligatorias a las deducciones por procesar.
    • Solución: Se cambiaron los statements de GETDATE() por las variables que contienen la fecha de operación. De manera que esto se propague a la fecha de asociación de deducción.
Otros errores encontrados:
  • Se notó que en el XML de operación, algunos empleados activos no trabajaban sus días correspondientes, por lo que quedaban muchas columnas vacías o en 0, se pidió que se realizara esta corrección de operación.

Consultas con el profesor:
        



Por hacer:
  • Agregar/Ajustar funcionalidades de Editar, Insertar y Borrar Empleados desde la interfaz web.
  • Arreglar detalles como números de error y detalles de prácticas de escritura de código.
  • Arreglar el despliegue correcto de algunos datos en la interfaz (Como que el nombre del mes sea el apropiado)
  • Revisiones de cálculos correctos en casos límite no evidentes a simple vista
Errores en tabla DBError:
Ninguno!

Link del commit
Link del repositorio



Comentarios

Entradas más populares de este blog

Configuración del framework

SPs de extracción