Creación de los SP: ConsultarPlanillaSemanal y DetalleMovimientoSemana
Fecha: Martes 9 de junio de 2026
Hora de
inicio: 1:00 p.m.
Hora de
finalización: 5:00 p.m.
Total de horas trabajadas: 4 horas
El objetivo de
esta sesión fue desarrollar los SPs necesarios para
consultar la información de la planilla semanal de un empleado.
Primero trabajé
en ConsultarPlanillaSemanal, cuya función es retornar las últimas semanas de
planilla de un empleado activo. Este procedimiento muestra los datos generales
de cada semana, como el salario bruto, las deducciones, el salario neto y las
cantidades de horas trabajadas.
Después
desarrollé DetalleMovimientosSemana, encargado de obtener el detalle de los
movimientos de débito asociados con una planilla semanal específica. Este
segundo procedimiento permite consultar las deducciones aplicadas durante esa
semana, incluyendo el tipo de deducción, el porcentaje cuando corresponda, el
monto, el nuevo saldo y la fecha del movimiento.
Ambos
procedimientos se relacionan con el requerimiento R04 del proyecto y también
debían registrar la operación realizada en la bitácora de eventos.
Actividades realizadas
1:00 p.m. - 1:30 p.m.
Análisis de
las consultas necesarias
Al comenzar la
sesión revisé nuevamente el requerimiento R04 para identificar cuáles consultas
eran necesarias para mostrar correctamente la planilla semanal.
La primera
consulta debía mostrar una lista general de las últimas semanas del empleado. Para
cada semana era necesario retornar:
- Fecha
inicial y final.
- Salario
bruto.
- Total
de deducciones.
- Salario
neto.
- Cantidad
de horas ordinarias.
- Cantidad de horas extra normales.
- Cantidad de horas extra dobles.
Además de la
información general, el usuario debe poder presionar los montos para consultar
información más detallada. Por esta razón también era necesario un
procedimiento separado que recibiera el identificador de una planilla semanal y
retornara los movimientos asociados con ella.
Por ultimo, antes de comenzar a programar revisé las relaciones entre las tablas PlanillaSemanal, Semana, MovPlanilla, MovHoras, TipoMovimiento, EmpXTipoDed y TipoDeduccion.
1:30 p.m. –
2:40 p.m.
Creación de
ConsultarPlanillaSemanal
El primer
procedimiento desarrollado fue ConsultarPlanillaSemanal.
Este
procedimiento recibe los siguientes parámetros:
- El
identificador del empleado.
- La cantidad de semanas que se desean
consultar.
- El identificador del usuario que
realiza la consulta.
- La dirección IP desde donde se
realiza.
Para la cantidad de semanas utilicé un valor predeterminado de 4. De esta manera, si la capa lógica no envía una cantidad diferente, se muestran automáticamente las últimas cuatro semanas.
Antes de realizar
la consulta principal agregué una validación para comprobar que el empleado
existe y se encuentra activo.
La consulta busca
al empleado utilizando su identificador y la condición EsActivo = 1. Si no se
encuentra, se activa una bandera de error, se asigna el código 50012 y se crea
una descripción indicando que el empleado no existe o se encuentra inactivo.
Si el empleado es válido, se crea una descripción indicando que la consulta fue exitosa, el empleado consultado y la cantidad de semanas solicitadas. Luego se llama aRegistrarBitacora, utilizando el tipo de evento correspondiente a consultar una planilla semanal.
Consulta de
las últimas semanas
La consulta principal parte de la tabla PlanillaSemanal, ya que en ella se almacenan los acumulados generales correspondientes a cada empleado y semana. Esta tabla se relaciona con Semana para obtener las fechas inicial y final del periodo. Posteriormente se utilizan LEFT JOIN con MovPlanilla y MovHoras para obtener los movimientos y las cantidades de horas asociadas con cada planilla.
Img. 2: Relaciones entre PlanillaSemanal, Semana, MovPlanilla y MovHoras.Decidí utilizar
LEFT JOIN porque una planilla debe continuar apareciendo en el resultado aunque
no tenga movimientos de alguno de los tipos de horas.
Para separar las
horas ordinarias, extra normales y extra dobles utilicé expresiones CASE dentro
de funciones SUM.
Los tipos de
movimiento utilizados fueron:
- Tipo 1
para horas ordinarias.
- Tipo 2 para horas extra normales.
- Tipo 3 para horas extra dobles.
2:40 p.m. – 3:00 p.m.
Manejo de
errores y pruebas de ConsultarPlanillaSemanal
Después de completar la consulta agregué un bloque TRY-CATCH para controlar posibles errores durante la ejecución. Si ocurre una excepción, el procedimiento asigna el código general 50008 y registra la información técnica en la tabla DBError.
3:00 p.m. - 4:15 p.m.
Creación de
DetalleMovimientosSemana
Después de
completar la consulta general comencé a desarrollar DetalleMovimientosSemana.
Este procedimiento recibe:
- El identificador de la planilla
semanal.
- El
identificador del usuario.
- La
dirección IP.
En este caso no era necesario recibir nuevamente el identificador del empleado, porque la planilla semanal ya se encuentra relacionada con un empleado específico.
Ahora, si la planilla
existe, se registra la consulta en la bitácora utilizando nuevamente el evento
de consulta de planilla semanal.
La descripción
incluye el resultado exitoso y el identificador de la planilla que se está
consultando.
Al igual que en el procedimiento anterior, los intentos fallidos también se registran.
Consulta del
detalle de deducciones
La consulta parte
de MovPlanilla, porque esta tabla contiene los movimientos generados durante el
procesamiento de la planilla.
Luego se
relaciona con TipoMovimiento para conocer el nombre y la acción correspondiente
a cada movimiento.
También se
utilizan relaciones con:
- EmpXTipoDed, para identificar la
asociación entre el empleado y el tipo de deducción.
- TipoDeduccion, para obtener el nombre
de la deducción.
- EXTDPorcentual, para obtener el
porcentaje cuando la deducción es porcentual.
Img. 3:
Relaciones entre MovPlanilla y las tablas relacionadas con las deducciones.
Para obtener
solamente las deducciones de la semana se aplican dos filtros:
- Que el movimiento pertenezca a la
planilla recibida.
- Que la acción del tipo de movimiento
sea igual a D.
La letra D
representa los movimientos de débito, es decir, aquellos que disminuyen el
salario del empleado.
La consulta retorna:
- Identificador
del movimiento.
- Nombre del tipo de movimiento.
- Nombre del tipo de deducción.
- Porcentaje
aplicado, si corresponde.
- Monto
del movimiento.
- Nuevo
saldo.
- Fecha
del movimiento.
Utilicé LEFT JOIN
en las tablas relacionadas con las deducciones porque no todos los movimientos
necesariamente tienen los mismos datos específicos.
Por ejemplo, una deducción de monto fijo no tendría un porcentaje asociado. En ese caso el movimiento debe mostrarse igualmente, aunque el campo de porcentaje sea NULL.
4:15 p.m. –
5:00 p.m.
Pruebas
finales y revisión general
Hice algunas pruebas hasta donde me era posible, pero en ese punto era difícil porque todavía no se tenían datos.
Buenas prácticas y aprendizajes
- Es recomendable validar la existencia
de los registros antes de realizar consultas que dependan de ellos.
- Los parámetros con valores
predeterminados permiten que los procedimientos sean más sencillos de
utilizar.
- LEFT JOIN es útil cuando se desea
conservar el registro principal aunque alguna información relacionada no
exista.
- Las expresiones CASE dentro de SUM
permiten separar distintos tipos de movimientos sin realizar varias
consultas.
- ISNULL evita enviar valores nulos
innecesarios a la capa lógica.
- Cuando se utilizan funciones de
agregación es necesario agrupar correctamente los demás campos
seleccionados.
- Los movimientos de crédito y débito
deben diferenciarse mediante el atributo Accion de TipoMovimiento.
- Una deducción porcentual puede tener
información adicional que no existe para una deducción de monto fijo, por
lo que las relaciones deben permitir valores nulos.
- Las consultas fallidas también deben
registrarse para mantener la trazabilidad completa.
- Los comentarios del código deben
coincidir con la lógica realmente implementada para evitar confusiones
durante la integración.
Comentarios
Publicar un comentario