Manejo Movimientos

Domingo 27 1:10 PM -  Lunes 28 1:25 AM

Esta entrada documenta el proceso de implementación de los requerimientos R5 (Listar Movimientos) y R6 (Insertar Movimiento) en el sistema de control de vacaciones. Aunque se avanzó bastante, también fue un proceso lleno de complicaciones, decisiones difíciles, y soluciones parciales que aún requieren ajustes.

 

La implementación comenzó el domingo a la 1:00 pm usando la estructura que ya habíamos venido utilizando: idEmpleado como la clave foránea en la tabla Movimiento.

Se crearon los siguientes procedimientos almacenados:

  1. sp_ListarMovimientosEmpleado:

Devuelve los datos del empleado (nombre, documento, saldo vacaciones) y una lista de sus movimientos.

  1. sp_InsertarMovimientoEmpleado:

Inserta un nuevo movimiento, valida el saldo (que no se vuelva negativo) y actualiza el saldo vacaciones del empleado.

La integración del backend y frontend con idEmpleado fue relativamente fluida al principio. Las rutas quedaron como:

 

/empleados/:idEmpleado/movimientos

/empleados/:idEmpleado/movimientos/nuevo

 

Durante la programación hubo algunos problemas:

·         Rutas inconsistentes entre /employees y /empleados, causando pantallas en blanco.

·         El backend sin correr generaba ERR_CONNECTION_REFUSED en el frontend.

·         Errores al enviar parámetros en Axios, por mal uso de params en PO

Estos se solucionaron relativamente rápido, sin embargo, al probar con los datos reales, nos dimos cuenta del gran problema, estos no contienen idEmpleado, sino que identifican a los empleados por ValorDocumentoIdentidad.

Esto nos llevó a intentar un refactor completo del sistema para reemplazar idEmpleado por ValorDocumentoIdentidad en:

  • Las tablas (Movimiento).
  • Los procedimientos almacenados.
  • Las rutas del backend.
  • Las llamadas desde el frontend.

Intento de refactor: de idEmpleado a ValorDocumentoIdentidad

Se cambió la tabla Movimiento para que referenciara directamente ValorDocumentoIdentidad en lugar de idEmpleado, y se actualizaron los procedimientos almacenados para buscar al empleado y operar usando solo el documento.

Además, el frontend fue ajustado para cambiar las rutas: 

 

/empleados/:ValorDocumentoIdentidad/movimientos

/empleados/:ValorDocumentoIdentidad/movimientos/nuevo

 

A pesar del esfuerzo, el refactor no fue exitoso del todo:

      1. Listar movimientos:
        • La vista quedaba en "Cargando...".
        • Al inspeccionar, se descubrió que el SP no siempre devolvía los dos datasets esperados (empleado + movimientos). Esto hacía que el frontend quedara esperando indefinidamente.
      2. Insertar movimientos:
        • Aunque el SP lograba insertar, los parámetros de salida (@Resultado) seguían retornando nulos en Node.js, pese a ser asignados correctamente en el SP.

Se intentaron varias soluciones, como:

      • Usar SELECT @Resultado AS Resultado.
      • Cambiar OUTPUT por RETURN.

Pero ninguna logró solucionar el problema del parámetro nulo.

Decisión final: volver temporalmente a idEmpleado

Dado el tiempo invertido y la necesidad de avanzar, se volvió a la versión funcional que usa idEmpleado, al menos por ahora.

 Github commit


Comentarios

Publicar un comentario