Consolidar ventas, registrar auditoría y manejar errores con un solo EXEC es exactamente lo que distingue a un ingeniero de datos preparado para producción. Este procedimiento almacenado de cierre de mes replica un proceso real de cualquier empresa de retail y reúne todas las técnicas del módulo en un caso práctico completo.
¿Cómo se diseña un SP de cierre mensual antes de escribir código?
Antes de tocar el teclado, lo fundamental es pensar en el diseño. El procedimiento necesita variables de entrada: el año y el mes del periodo que se quiere cerrar, además de un código país opcional. También requiere un parámetro de salida que devuelva el resultado de la operación, con tres valores posibles: success, already closed o error [01:00].
El flujo del proceso sigue esta secuencia lógica:
- Verificar que el periodo no haya sido cerrado previamente.
- Calcular los totales de ventas por país para ese periodo.
- Insertar el resultado en una tabla llamada resumen mensual.
- Registrar todo en la tabla log Cierres.
- Si algo falla, hacer rollback y registrar el error.
¿Qué tablas de soporte se necesitan crear primero?
El SP depende de dos tablas que deben existir antes de ejecutarlo. Se crean con una verificación condicional: si el objeto no existe, se crea [02:28]. La primera es resumen mensual, donde se almacenan los totales consolidados. La segunda es log Cierres, que funciona como tabla de auditoría para dejar constancia de cada ejecución, ya sea exitosa o fallida.
¿Cómo se validan los parámetros de entrada?
La primera evaluación dentro del SP protege contra datos incorrectos [03:15]. Si el año es menor a 2000 o mayor al año actual más uno, o si el mes es menor a uno o mayor a doce, el procedimiento devuelve inmediatamente un error. Nadie debería poder ingresar un mes catorce o un año como 1999 cuando no existen datos para esa fecha. Cuando se detecta un parámetro inválido, se inserta un registro en log Cierres con el estado de error y el procedimiento termina con RETURN.
¿Cómo se evalúa si un mes ya fue cerrado?
Esta es la segunda barrera antes del proceso real. El SP ejecuta un IF EXISTS que consulta la tabla resumen mensual buscando coincidencias de año, mes y código país [04:30]. Si encuentra registros, significa que ese periodo ya fue procesado. En ese caso, el resultado se establece como mes cerrado, se registra en log Cierres y el procedimiento se detiene.
Si no existe el registro, el procedimiento continúa adelante con el cierre. Esta lógica de doble validación —primero parámetros, luego duplicidad— es lo que convierte a un SP simple en algo robusto.
¿Cómo funciona el proceso de cierre e inserción de datos?
Cuando ambas validaciones pasan, comienza el cierre real [05:48]. El SP ejecuta un INSERT INTO sobre la tabla resumen mensual con las siguientes columnas mapeadas:
- Código país recibe el valor de código país.
- Año y mes se llenan desde las variables de entrada.
- Total pedidos se calcula con un conteo.
- Ventas totales se obtiene con
SUM del campo P total.
- Ticket promedio se calcula como el promedio correspondiente.
Una vez completada la inserción, la variable filas_insertadas toma el valor de @@ROWCOUNT y el resultado se marca como exitoso [06:40]. Ambos valores se insertan en log Cierres junto con un mensaje que confirma el país procesado.
¿Qué ocurre al ejecutar el SP por primera vez?
Al ejecutar el cierre de enero 2024, el resultado muestra la tabla resumen mensual poblada correctamente: dos pedidos para algunos países, un pedido para otros, cada uno con sus ventas y ticket promedio [07:30]. El log Cierres confirma que la ejecución fue exitosa y se procesaron cuatro registros por país.
¿Qué sucede al intentar cerrar el mismo periodo dos veces?
Al volver a ejecutar el mismo cierre, la validación de IF EXISTS detecta que enero 2024 ya fue procesado [08:20]. El log Cierres registra que el periodo ya fue cerrado anteriormente y el SP no permite duplicar la operación. Exactamente el comportamiento esperado.
Este SP funciona, pero todavía tiene una limitación importante: si algo falla durante el INSERT, no ejecuta rollback. La solución es envolver todo en una transacción con TRY-CATCH, que es la diferencia entre un SP funcional y uno listo para producción.
Prueba estos tres escenarios: cierre exitoso de enero 2024, intento de cierre duplicado y cierre con parámetros inválidos como el año 1990. Comparte el pantallazo de tu log de ejecuciones en los comentarios.
