Creación de procedimientos almacenados: ActualizarEmpleado e InsertarMovimiento

 Fecha: lunes 20 de abril de 2026

Hora de inicio: 11:45 a.m.

Hora de finalización: 4:36 p.m.

Horas trabajadas: 2 h 38 min

El plan para esta sesión era implementar los dos SPs que me faltaban: ActualizarEmpleado e InsertarMovimiento. Fue la sesión más larga hasta ahora porque ambos SP son los más complejos que me correspondían, especialmente InsertarMovimiento.

Actividades realizadas

12:00 p.m. – 1:17 p.m. — SP: ActualizarEmpleado

Este SP permite editar el documento de identidad, nombre y puesto de un empleado existente. La estructura la fui pensando sobre la marcha, lo que hizo que tardara un poco más que los anteriores.

Lo primero que definí fue que necesitaba dos SELECT al inicio, uno para obtener los datos actuales del empleado (para la descripción de la bitácora) y otro para obtener el nombre del nuevo puesto que se está asignando. Ese segundo SELECT no era obvio al principio, pero me di cuenta de que si solo guardaba el id del nuevo puesto no podría construir una descripción legible en la bitácora.

Lo segundo fue las validaciones con IF EXISTS. Lo que hace es verificar si existe algún otro empleado activo con el mismo documento o nombre antes de proceder con el UPDATE, excluyendo siempre al propio empleado que se está editando.

Un detalle de diseño que me pareció importante fue que la bitácora se registra siempre al final, independientemente de si la operación fue exitosa o no, y la descripción incluye tanto los datos anteriores como los nuevos.

Una vez terminado lo probé desde SSMS verificando los tres casos: actualización exitosa, documento y nombre duplicados.

3:15 p.m. – 4:36 p.m. — SP: InsertarMovimiento

Este fue el SP más complejo que me tocó implementar. La lógica tiene varias capas y tuve que investigar algunas cosas antes de escribirlo.

Lo primero fue entender bien cómo debía funcionar la lógica de crédito y débito. El SP recibe un @inIdTipoMovimiento y con base en eso obtiene el campo TipoAccion de la tabla TipoMovimiento, que puede ser 'Credito' o 'Debito'. Dependiendo de ese valor, suma o resta el monto al saldo actual para calcular el nuevo saldo. Parecía simple pero tuve que pensar bien la estructura del IF para que los dos casos quedaran correctamente cubiertos.

Lo segundo fue la validación del saldo negativo. Si el nuevo saldo calculado resulta menor que cero, el SP no procede con la inserción y registra el intento fallido en bitácora. Eso significaba que la transacción solo debía abrirse si el saldo era válido.

Lo tercero fue que dentro de la transacción hay dos operaciones: primero el INSERT en la tabla Movimiento y luego el UPDATE del saldo en Empleado. Tuve que asegurarme de que ambas estuvieran dentro del mismo BEGIN TRANSACTION / COMMIT TRANSACTION para garantizar que si una fallaba, la otra también se revirtiera.

Un detalle que me generó duda fue el CAST(@inPostTime AS DATE) para el campo Fecha del movimiento. El SP recibe @inPostTime como DATETIME, pero la fecha del movimiento debe guardarse solo como DATE, sin la parte de la hora. Investigué cómo hacer esa conversión y la solución fue simplemente castear el DATETIME a DATE al momento del INSERT.

Lo probé verificando los dos casos principales: un movimiento de crédito con saldo válido y un intento de débito que dejara el saldo negativo.

Forma de trabajo del equipo

Nos mantuvimos en contacto por WhatsApp para coordinarnos sobre el estado general del proyecto.

Referencias:

Comentarios

Publicar un comentario

Entradas más populares de este blog

Creación del SP de Cargar Datos

Fecha:  20 de abril Hora de inicio: 9:00 a.m.  Hora de finalización: 12:00 p.m. Hora de inicio: 1:00 p.m.  Hora de finalización: 4:00 p.m. Horas trabajadas: 6h Con las tablas ya creadas en la base de datos, el siguiente paso era poblarlas con los datos de prueba provistos por el equipo del profesor. Para esto, se debía implementar el script para la carga de datos, que lo hicimos como SP, que recibe el contenido de un archivo XML y lo procesa directamente en SQL Server. Actividades realizadas 9:00 a.m. - 12:00 p.m. Antes de escribir el SP, fue necesario investigar cómo SQL Server maneja archivos XML de forma nativa, ya que el profesor indicó en su momento que no debíasmos hacerlo con un parser. Los conceptos investigados fueron:  nodes () y value() : funciones nativas de SQL Server para procesar XML. nodes() navega la estructura del documento y devuelve una fila por cada nodo encontrado — funciona como un recorrido sobre los elementos. value() extrae el v...
Leer más

Implementación de funcionalidades: Editar Empleado y Eliminar Empleado

Imagen
Fecha: sábado 25 de abril de 2026 Hora de inicio: 9:30 a.m. Hora de finalización: 5:38 p.m. Horas trabajadas:  4 h 41 min El plan para esta sesión era implementar las funcionalidades completas de editar y eliminar empleado. Fue la sesión más larga del proyecto hasta ahora, con bastante trabajo tanto en capa lógica como en presentación. Actividades realizadas 9:30 a.m. – 10:35 a.m. — Función actualizar_empleado (modelo) Empecé por la función en Python que conecta con el SP ActualizarEmpleado. La estructura es similar a las funciones que ya había hecho: abre la conexión, ejecuta el SP con cursor.execute, lee el resultset con el código de resultado y cierra la conexión en el finally. Un detalle importante en esta función es el conn.commit() después del fetchone. Como ActualizarEmpleado hace un UPDATE dentro de una transacción, es necesario confirmar el cambio desde la capa Python también, de lo contrario la modificación no persiste en la base de datos. Esto ya lo ha...
Leer más

Implementación de funcionalidad: Consultar Empleado

Imagen
Fecha: viernes 24 de abril de 2026 Hora de inicio: 2:30 p.m. Hora de finalización: 7:45 p.m. Horas trabajadas:  3 h 02 min El plan para esta sesión era implementar la funcionalidad completa de consultar empleado: la función en la capa lógica, el controlador y la vista. Johana ya había terminado su parte de capa lógica y presentación días antes, así que yo había esperado a que estuviera lista para arrancar con la mía, tal como lo acordamos. Actividades realizadas 2:30 p.m. – 3:20 p.m. — Función consultar_empleado (capa lógica) Comencé escribiendo la función consultar_empleado en Python. Esto era bastante similar a lo que hice en la tarea 1, así que no partí desde cero: repasé el código de la tarea anterior para refrescar cómo se hacían las llamadas a SPs con pyodbc y cómo se manejaban los resultsets. La función abre la conexión, ejecuta el SP con cursor.execute, lee el primer resultset con cursor.fetchone para obtener los datos del empleado, y luego llama a cursor.nextset() para ...
Leer más