Auditoría automática cada noche: cómo detectamos errores antes que el cliente

Antes de automatizarlo, este proceso lo hacía una persona: revisar a mano que el efectivo en caja coincidiera con lo registrado, que las habitaciones marcadas como ocupadas tuvieran una reserva real detrás, y que cada comprobante emitido tuviera su contraparte en el sistema. Es un trabajo mecánico, repetitivo, y exactamente el tipo de tarea que se automatiza mal si se hace sin cuidado — porque un proceso de auditoría que da falsos positivos todas las noches deja de revisarse, y uno que se calla ante un problema real es peor que no tener auditoría.

Qué hace el proceso, cada noche

En HotelPerusoft, un job programado corre de madrugada y compara tres cosas: el efectivo esperado en caja según las transacciones registradas, el estado real de cada habitación contra sus reservas activas, y cada comprobante SUNAT emitido contra el movimiento que debería respaldarlo. Si encuentra una discrepancia, genera una alerta con la severidad correspondiente y la envía por Telegram al responsable — no espera a que alguien revise un dashboard por iniciativa propia.

La parte que no se ve: idempotencia

Un detalle que decide si un proceso automatizado es confiable o no es qué pasa si corre dos veces por error — por ejemplo, si el servidor se reinicia a mitad de la ejecución y el scheduler lo vuelve a disparar. Un proceso mal diseñado puede duplicar alertas, o peor, aplicar una corrección dos veces. El nuestro está diseñado para ser idempotente: correrlo dos veces sobre el mismo periodo produce el mismo resultado que correrlo una vez. Esto aplica también a las marcaciones de asistencia biométrica en nuestra plataforma de RRHH, donde un evento de marcación duplicado por una reconexión del dispositivo no debe generar dos registros de entrada.

Por qué “automatizar” no es solo “quitarle el trabajo a una persona”

Automatizar un proceso de auditoría bien hecho no es simplemente escribir un script que corra a las 2am. Implica decidir qué constituye una discrepancia real (para no generar ruido), a quién y por qué canal avisar según la severidad, y garantizar que el proceso mismo no introduzca errores nuevos al sistema que está revisando. Es la misma exigencia que aplicamos al motor de reservas B2C de HotelPerusoft, donde un circuit breaker evita que un fallo en una pasarela de pago se convierta en un problema mayor por insistir contra un servicio caído.

El resultado, cuando se hace bien, es que un problema que antes se descubría días después — cuando ya era más caro corregirlo — se descubre la misma noche que ocurrió.