Vigilancia Automática de Vencimientos de Contratos

¿Qué hace este flujo y qué problema resuelve?

Este flujo de n8n automatiza la vigilancia de vencimientos de contratos para evitar incumplimientos operativos, pérdidas financieras y riesgos de cumplimiento legal. Detecta en forma periódica contratos próximos a vencer, evalúa reglas internas (por ejemplo, umbrales de 90, 60 y 30 días), y ejecuta acciones coordinadas: notificación a responsables, creación de tareas de renovación, bloqueo de procesos comerciales dependientes y registro de la trazabilidad en el sistema de gestión documental.

Problema que resuelve

• Eliminación del riesgo de continuidad operacional por contratos caducos (por ejemplo, contratos de transporte o soporte técnico).
• Reducción del costo por renovaciones urgentes o por renovaciones con penalidades por retraso.
• Mejora de cumplimiento regulatorio y auditoría mediante registro automatizado de alertas y acciones tomadas.
• Mayor eficiencia administrativa al centralizar la gestión de vencimientos y acciones asociadas.

Cómo opera, a alto nivel

1. Agendado: un nodo Cron en n8n ejecuta el flujo a diario (o con menor frecuencia según volumen).
2. Consulta: el flujo lee la fuente de datos de contratos (base SQL, Google Sheets o Airtable) y filtra contratos por fecha de vencimiento.
3. Evaluación: se aplican reglas (umbral de alertas, exclusiones por cláusulas de prórroga) y se determina la acción correspondiente.
4. Notificación y registro: el flujo envía alertas por correo/Slack, crea tickets en el gestor de tareas y actualiza el registro del contrato con estado y notas.
5. Escalado: si no hay respuesta en el plazo definido, el flujo escalona a un responsable de mayor jerarquía.

Ejemplo operativo (empresa ficticia)

InnovaLogistics S.A. mantiene contratos con transportistas. Un contrato con TransMove vence en 30 días. El flujo detecta este vencimiento y: 1) envía un correo a Procurement, 2) crea un ticket en el gestor de incidencias del área logística, 3) añade un evento en el calendario corporativo para la reunión de revisión, y 4) marca el registro del contrato como "Alerta 30 días" en la base de datos. Si a los 10 días no hay acción, el flujo escalona al Director de Operaciones.

Beneficios medibles

• Reducción de incidentes por contratos vencidos: estimación inicial 70%.
• Menor gasto de emergencia por renovaciones inmediatas: ahorro proyectado en el primer año.
• Trazabilidad completa para auditoría: todas las notificaciones y acciones quedan registradas.

Consideraciones de implementación

• Definir fuente de datos principal y autoridad del registro maestro (quién actualiza fechas y cláusulas).
• Establecer reglas de negocio claras: umbrales, excepciones y equivalente de escalado.
• Garantizar permisos seguros para nodos que acceden a sistemas sensibles (DB, API, correo).

Cuándo usar este flujo

Detección de nuevo contrato en Drive

Objetivo: Detectar automáticamente la llegada de un nuevo contrato en Google Drive y generar el evento inicial del flujo de vigilancia de vencimientos. Esta sección describe la configuración práctica de los nodos n8n, pasos detallados y un ejemplo operativo con una empresa ficticia.

Visión general del flujo en esta etapa: un nodo disparador que vigila una carpeta específica en Drive, filtro de validación para garantizar que solo se procesen contratos, y un nodo que normaliza los metadatos del archivo para el resto del flujo.

1. Nodo 1: Google Drive Trigger

   1. Tipo: Trigger
   2. Operación: Watch Files (o Polling, si no se dispone de webhook)
   3. Credenciales: Cuenta de servicio o credenciales OAuth vinculadas a la carpeta corporativa
   4. Carpeta a vigilar: especificar el Folder ID de la carpeta contenedora (ejemplo: carpeta "Contratos/Vigentes")
   5. Filtros recomendados: mimeType igual a application/pdf y name contains Contrato
   6. Intervalo de sondeo: 60 segundos para procesos críticos, 5 minutos para menor frecuencia

2. Nodo 2: IF node (validador de archivo)

   1. Condición 1: fileName matches RegExp para patrón de nombre. Ejemplo de expresión: ^Contrato_\d{4}_.+\.pdf$
   2. Condición 2: mimeType equals application/pdf
   3. Acción: si se cumple, continuar al nodo de normalización; si no, registrar o mover el archivo a carpeta de revisión

3. Nodo 3: Google Drive - Get File (metadatos)

   1. Operación: Get File
   2. Input: fileId desde salida del Trigger
   3. Campos a recuperar: id, name, createdTime, modifiedTime, owners, webViewLink
   4. Salida: mapa de campos estandarizados para downstream

4. Nodo 4: Set / Transform

   1. Normalizar campos clave: fileId, fileName, uploadDate, folderPath, downloadUrl
   2. Extraer metadatos adicionales del nombre de archivo (por ejemplo proveedor y fecha de vencimiento si embebida)

Ejemplo operativo con empresa ficticia

InnovaLegal S.A. centraliza contratos en Drive siguiendo la convención de nombres Contrato_YYYY_Proveedor.pdf y guarda archivos en la carpeta Contratos/Vigentes. Al añadir Contrato_2026_ACME.pdf el Google Drive Trigger detecta el archivo, el IF valida patrón y mimeType, el nodo Get File recupera id y enlace, y Set normaliza el registro para el módulo de vencimientos.

Output esperado

Problemas frecuentes

1. Sintoma: El trigger no detecta archivos nuevos

Causa: Credenciales caducas o permisos insuficientes sobre la carpeta.

Solución: Revisar y actualizar credenciales en n8n, confirmar que la cuenta tiene acceso de lectura a la carpeta y probar con un archivo manual.

2. Sintoma: Archivos detectados pero filtrados por el IF sin razón aparente

Causa: Expresión regular mal construida o diferencias en la convención de nombres.

Solución: Validar la expresión regular en una herramienta externa, añadir logs temporales que muestren fileName, y ajustar condiciones para aceptar variantes permitidas.

3. Sintoma: Metadata incompleta al usar Get File

Causa: Limitaciones de la API o campos no solicitados explícitamente.

Solución: Configurar el nodo para solicitar explícitamente los campos necesarios y verificar cuotas API. Si corresponde, reintentar con backoff.

4. Sintoma: Falsos positivos por archivos temporales o borradores

Causa: Herramientas que crean archivos temporales durante la subida (nombre temporal diferente).

Solución: Aplicar una segunda validación temporal que espere unos segundos y verifique que el archivo finaliza la subida; excluir nombres que contengan tmp o ~.

5. Sintoma: Alta latencia entre subida y disparo del flujo

Causa: Intervalo de polling elevado o limitación por cuota.

Solución: Reducir polling si la carga lo permite o implementar webhook si la cuenta y el entorno lo soportan. Monitorizar uso de cuota y ajustar frecuencia.

Adaptaciones y variantes

• Vigilancia en SharePoint: sustituir Google Drive Trigger por un conector SharePoint / Microsoft Graph que vigile una librería de documentos y mantener la misma lógica IF y normalización.

• Detección por correo: en lugar de Drive, usar un nodo IMAP o Gmail Trigger para detectar adjuntos con patrón de nombre y volcar adjuntos a una carpeta temporal en Drive para posterior procesamiento.

• Monitor SFTP: usar nodo SFTP Trigger para detectar nuevos archivos en un repositorio seguro y aplicar los mismos filtros y transformaciones.

• Validación por contenido: añadir un paso OCR o análisis de texto para extraer fecha de vencimiento desde el PDF cuando la fecha no está en el nombre de archivo; útil en contratos escaneados.

Notas finales: documente la convención de nombres y los permisos de la carpeta como parte del contrato operativo. Mantenga logs de los archivos rechazados para auditoría y ajuste progresivo de los filtros según la operativa real.

Extracción de fechas con IA local

Actualización del registro maestro

Actualización del registro maestro (step3)

Objetivo: persistir en la base maestra la información consolidada de vencimientos tras la verificación y el cálculo de plazos. Esta etapa actualiza o crea el registro en la tabla contracts_master y registra metadatos operativos para auditoría.

Resumen de nodos recomendados en n8n y configuración específica:

1. Preparación del payload (Nodo: Set - nombre: PreparePayload)
   1. Agregar campos: contract_id => expression: {{$json['contract_id']}}
   2. expiry_date => {{$json['expiry_date']}} (ISO 8601 preferible)
   3. counterparty => {{$json['counterparty']}}
   4. source_flow => 'vencimientos-tenant-1' (string fijo para trazabilidad)
   5. modified_by => {{$json['processed_by']}} o email del sistema
2. Cálculo de fechas y flags (Nodo: Function - nombre: CalculateDates)
   1. Code: calcular days_to_expiry y next_renewal_date (ej. expiry_date menos 30, 90 días) usando Date en JS.
   2. Salida: next_renewal_date (ISO), days_to_expiry (número), status_update (e.g., 'vencido' | 'por_vencer' | 'vigente').
3. Lectura previa del maestro (Nodo: PostgreSQL - nombre: GetMasterRow)
   1. Credentials: PostgresCreds
   2. Operation: Execute Query (o Get All Rows si está disponible)
   3. Query: SELECT * FROM contracts_master WHERE contract_id = {{$json['contract_id']}} LIMIT 1
4. Merge de datos (Nodo: Merge - nombre: MergeExisting)
   1. Strategy: Merge by property (key: contract_id). Preferir valores calculados desde CalculateDates para fields críticos (expiry_date, days_to_expiry).
5. Actualización/Inserción (Nodo: PostgreSQL - nombre: Update Master Record)
   1. Credentials: PostgresCreds
   2. Operation: Update
   3. Table: contracts_master
   4. Identifier column: contract_id
   5. Columns a actualizar: expiry_date, next_renewal_date, days_to_expiry, status, counterparty, last_modified_by, last_modified_at
   6. Expresiones ejemplo para valores: expiry_date => {{$json['expiry_date']}}, days_to_expiry => {{$json['days_to_expiry']}}, last_modified_at => {{$now}}.
   7. Si el update no afecta filas (registro no existente): encadenar nodo Insert (Operation: Insert) con los mismos campos para crear el registro maestro.
6. Registro de auditoría / salida (Nodo: HTTP Request o Google Sheets - nombre: AuditLog)
   1. Guardar evento: contract_id, acción (update/insert), actor, timestamp, origen del flujo.

Flujo lógico: PreparePayload -> CalculateDates -> GetMasterRow -> MergeExisting -> (If exists) Update Master Record -> (Else) Insert Master Record -> AuditLog.

Ejemplo operativo

Caso realista: Grupo Altamira S.A. detecta que un contrato con ID 'ALT-2026-099' vence en 2026-09-30. El flujo calcula 30 días de aviso y actualiza el maestro.

Problemas frecuentes

Síntoma: El nodo Update devuelve 0 filas afectadas a pesar de existir el contrato.

Causa: Discrepancia en el identificador (espacios, mayúsculas/minúsculas) o uso de claves compuestas no mapeadas. Solución: Normalizar contract_id en Set/Function (trim, toUpperCase) y volver a ejecutar. Verificar la consulta SELECT previa.

Síntoma: Fecha calculada incorrecta (desfase de 1 día).

Causa: Diferencias en zona horaria o formato de fecha (UTC vs local). Solución: Convertir y forzar ISO 8601 en el Function node; utilizar getTimezoneOffset si necesario y estandarizar a YYYY-MM-DD.

Síntoma: Inserción duplicada de registros.

Causa: Condición de carrera cuando varios flujos procesan el mismo contrato simultáneamente. Solución: Implementar bloqueo optimista (campo version/timestamp) o serializar por contract_id mediante nodos que hagan queueing o uso de transacciones en la base.

Síntoma: Campos nulos en master tras update.

Causa: El Merge no prioriza correctamente los valores nuevos y reemplaza con valores vacíos. Solución: Revisar configuración del Merge (preferir incoming) o validar y filtrar antes de Update (Set sólo con campos no vacíos).

Síntoma: Error de conexión a la base: authentication failed.

Causa: Credenciales caducadas o IP bloqueada. Solución: Verificar PostgresCreds en n8n, renovar credenciales, comprobar reglas de firewall y lista de IPs permitidas.

Adaptaciones y variantes del flujo

• Guardar el maestro en Google Sheets: sustituir nodos PostgreSQL por Google Sheets (Operation: Update / Append) cuando la organización use hoja compartida como registro canónico.
• Uso de Airtable como tabla maestra: emplear el nodo Airtable para Update/Upsert y aprovechar campos vinculados para avisos automáticos entre equipo legal y procurement.
• Base NoSQL (MongoDB): adaptar el Merge usando _id y operaciones upsert; calcular days_to_expiry en Function y usar UpdateOne con upsert=true para garantizar idempotencia.
• Sincronización bilateral: después de Update, emitir evento (Webhook o Message Queue) para notificar a sistemas externos (ERP, CRM) que consuman la versión maestra actualizada.

Recomendación final: incluir siempre auditoría mínima (who/when/source) y pruebas con datos ficticios antes de activar en producción. Documente el contrato de datos (nombres de campos y formatos) para mantener consistencia entre upstream y la tabla maestra.

Alertas escalonadas de vencimiento

Esta sección describe cómo implementar alertas escalonadas de vencimiento en n8n para asegurar respuestas progresivas según la proximidad del contrato a su fecha final. El objetivo es notificar al responsable inicial y, ante la falta de acción, escalar a responsables de mayor nivel y a canales alternativos. A continuación se detallan los nodos recomendados y la configuración práctica.

Resumen del flujo: ejecutar diariamente, extraer contratos próximos a vencer, calcular días restantes, determinar nivel de alerta, enviar notificaciones y actualizar el registro para evitar duplicados.

1. Preparar la fuente de datos
   1. Nodo Cron: ejecutar cada día a las 08:00. Configuración: schedule='0 8 * * *'.
   2. Nodo PostgreSQL/MySQL: consulta de contratos activos. Ejemplo de SQL:
      • SELECT contract_id, title, counterparty, end_date, owner_email, last_alert_level FROM contracts WHERE end_date >= now() AND end_date <= now() + INTERVAL '30 days' AND status = 'active';
2. Calcular prioridad y nivel de alerta
   1. Nodo Function: calcular days_left y proponer nivel. Lógica sugerida:
      • days_left = difference entre end_date y now()
      • if days_left > 15 and <= 30 => level='30d'
      • if days_left > 7 and <= 15 => level='15d'
      • if days_left > 1 and <= 7 => level='7d'
      • if days_left <= 1 => level='1d'
   2. Incluir campo next_alert_level y bandera should_send si level > last_alert_level.
3. Rutas y envíos escalonados
   1. Nodo Switch/IF: ramas según next_alert_level.
      • Case '30d' => enviar a owner_email via Email node.
      • Case '15d' => enviar a owner_email y CC a jefe de departamento (campo manager_email).
      • Case '7d' => enviar a owner_email, manager y crear ticket en sistema (HTTP Request a API de gestión).
      • Case '1d' => enviar a owner, manager y legal; y marcar como crítico.
   2. Nodo Email: configurar from='no-reply@empresa.com', subject con plantilla 'Alerta de vencimiento: {{title}} - {{days_left}} días'.
   3. Nodo HTTP Request: POST a endpoint de ticketing con payload JSON con contract_id, prioridad y enlace al contrato.
   4. Nodo PostgreSQL Update: registrar last_alert_level y last_alert_date para evitar reenvíos duplicados.
4. Persistencia y registros
   1. Guardar trazabilidad en tabla alerts_log: contract_id, alert_level, sent_at, channel, recipients.
   2. Añadir manejos de error y reintentos con Delay y registros en un log central.

Ejemplo operativo (empresa ficticia): InnovaLogix S.A. tiene un contrato con ID 2024-117 que vence en 14 días. El workflow ejecuta Cron, consulta la base, Function calcula days_left=14 y asigna level='15d'. Switch envía correo a maria.gomez@innovalogix.com (owner) y CC a luis.rios@innovalogix.com (manager). Se crea entrada en alerts_log y se actualiza last_alert_level='15d'. Si a los 7 días no hay actualización de estado, se ejecutará la rama '7d' y se abrirá un ticket en JIRA vía HTTP Request asignado al equipo legal de InnovaLogix.

Output esperado

Problemas frecuentes

Síntoma: No llegan correos a los destinatarios

Causa: Configuración SMTP incorrecta o bloqueo por proveedor. Solución: Verificar credenciales SMTP en nodo Email, revisar logs del servidor y probar envío manual desde n8n. Configurar registros SPF/DKIM si procede.

Síntoma: Alertas duplicadas cada día

Causa: No se actualiza last_alert_level o la condición should_send siempre es true. Solución: Añadir UPDATE en la base tras cada envío y comprobar la lógica en el nodo Function para que compare correctamente last_alert_level.

Síntoma: Filtrado SQL devuelve menos registros que esperado

Causa: Zona horaria o formato de fecha en la base. Solución: Normalizar fechas usando UTC en consultas y revisar uso de INTERVAL con la misma zona horaria que n8n.

Síntoma: HTTP Request a ticketing falla con 401/403

Causa: Token API caducado o permisos insuficientes. Solución: Renovar token, comprobar alcance y probar el endpoint con herramientas externas; manejar respuestas de error en n8n e implementar reintentos limitados.

Síntoma: Workflow se queda bloqueado en Function o Switch

Causa: Excepciones no capturadas por datos inesperados. Solución: Añadir validaciones sobre campos obligatorios y rutas de error; registrar el payload que causa la excepción para depuración.

Adaptaciones

• Escala a canales externos: En lugar de correo, enviar SMS en etapas críticas usando un nodo HTTP Request a Twilio o proveedor local.
• Gestión legal prioritaria: Para contratos con cláusula de confidencialidad, iniciar automáticamente revisión legal y crear tarea en el sistema interno con prioridad alta.
• Escalas internas por SLA: En organizaciones con SLAs, mapear niveles de alerta a penalizaciones o acciones automáticas (suspensión de renovación automática) y activar un flujo de cobros o retención.
• Integración PLM/ERP: En empresas manufactureras ficticias como TecnoProd S.L., sincronizar con ERP para bloquear órdenes ligadas a contratos vencidos automáticamente tras la alerta '1d'.

Implementar estas prácticas garantiza trazabilidad, evita notificaciones redundantes y facilita la acción escalonada con mínima intervención manual.

Output esperado del flujo

Problemas frecuentes y cómo resolverlos

Adaptaciones del flujo para otros contextos

Esta sección describe adaptaciones prácticas del flujo de vigilancia automática de vencimientos de contratos en n8n para distintos contextos organizativos. Proporciona variantes del diseño, un ejemplo detallado con configuración de nodos, el resultado esperado en un caso concreto y una lista de problemas frecuentes con síntoma, causa y solución. Los ejemplos usan empresas ficticias verosímiles para facilitar la comprensión y la replicabilidad.

Variantes del flujo para otros contextos

• Renovaciones automáticas con aprobación humana: flujo híbrido para contratos que requieren revisión antes de renovar.

  1. Trigger: Cron diario que obtiene contratos con vencimiento en 30 días.
  2. Consulta: nodo Database/Google Sheets para listar contratos y estado de renovación.
  3. Condición: nodo IF que separa contratos con cláusula de aprobación manual.
  4. Para los que requieren aprobación: nodo Email/Slack para enviar notificación a responsable con enlace a un Webhook de aprobación.
  5. Webhook: recibe la decisión humana y activa el nodo que actualiza el contrato o programa la renovación automática.

  Ejemplo: la firma ficticia Constructora Altamira utiliza este flujo para contratos de subcontratación cuyo valor supera 50.000 EUR.

• Seguimiento de proveedores y SLAs: orientado a medir cumplimiento de servicios asociados a contratos.

  1. Trigger: Cron semanal.
  2. Integración: HTTP Request a API del proveedor para obtener métricas SLA.
  3. Transformación: Function node que calcula desviaciones y vincula métricas al contrato correspondiente.
  4. Alertas: Si desviación > umbral, nodo Email/Teams para responsable y nodo CRM para crear actividad.

  Ejemplo: la logística ficticia InnovaLogistics realiza esta variante para contratos de transporte con cláusulas de puntualidad.

• Contratos financieros con vencimientos escalonados: añade cálculo de amortizaciones y fechas intermedias.

  1. Trigger: Cron mensual.
  2. Transformación: Function node que genera calendario de vencimientos parciales (cuotas) a partir de calendario y tabla financiera.
  3. Condición: IF para alertar según tipo de cuota (capital, interés, comisión).
  4. Salida: Generar entrada en ERP y notificación contable automatizada.

  Ejemplo: Banco Solera (ficticio) aplica esta variante para préstamos con pagos trimestrales.

• Integración con ERP/CRM para gestión comercial: actualiza estados contractuales en sistemas comerciales y crea tareas de renovación.

  1. Trigger: Webhook activado por cambios en ERP/CRM o Cron para sincronización periódica.
  2. Transformación: nodo Set/Function para mapear campos entre sistemas.
  3. Integración: HTTP Request o nodo nativo del ERP para actualizar registro y crear actividad de seguimiento.

  Ejemplo: la empresa de servicios AquaTech Servicios sincroniza contratos con su CRM comercial para que el equipo de cuentas gestione renovaciones prioritarias.

Configuración específica de nodos (ejemplo práctico para la variante de aprobación humana)

1. Cron node: programar a las 08:00 todos los días.

2. Database node (MySQL/Postgres): consulta SQL:

   1. SELECT id, cliente, fecha_vencimiento, requiere_aprobacion FROM contratos WHERE fecha_vencimiento BETWEEN CURRENT_DATE AND CURRENT_DATE + INTERVAL '30 days' AND estado = 'activo';

3. IF node: condición: requiere_aprobacion == true

4. Email node (SMTP): campo Para: responsable_legal; Asunto: "Solicitud de aprobación de renovación — Contrato {{id}}"; Cuerpo: resumen de contrato y link al Webhook de aprobación.

5. Webhook node: ruta pública que recibe JSON { contractId, decision, observaciones } y dispara un Function node que aplica la decisión y actualiza la base de datos.

Output esperado (ejemplo concreto)

Lista de alertas generadas en una ejecución para la empresa ficticia Constructora Altamira:

Problemas frecuentes y soluciones

1) Síntoma: No se genera ninguna alerta pese a existir contratos próximos al vencimiento.

Causa: Query de base de datos con rango de fechas incorrecto o zona horaria mal configurada.

Solución: Revisar la consulta SQL, comprobar uso de CURRENT_DATE vs TIMESTAMP y ajustar la zona horaria del nodo Cron y la base de datos.

2) Síntoma: Correos de notificación no llegan a los responsables.

Causa: Configuración SMTP errónea o bloqueos por políticas de seguridad (SPF/DKIM).

Solución: Verificar credenciales SMTP, probar envío manual desde n8n, y coordinar con TI para revisar registros SPF/DKIM y whitelist del servidor.

3) Síntoma: Las aprobaciones enviadas por Webhook no modifican el estado del contrato.

Causa: Mapeo de campos en el Function node o problemas de autorización al escribir en la base de datos/ERP.

Solución: Habilitar logging en el Function node, comprobar payload recibido, validar credenciales/API keys usadas para actualización y probar la llamada de forma aislada.

4) Síntoma: Duplicidad de notificaciones para el mismo contrato.

Causa: El flujo no marca contratos como procesados o el trigger Cron se ejecuta varias veces solapadas.

Solución: Implementar un campo de estado "alerta_generada" con marca de tiempo al final del flujo y añadir lógica IF para evitar re-procesos; ajustar el comportamiento del Cron para evitar solapamientos.

5) Síntoma: Errores intermitentes al integrar con el ERP externo.

Causa: Límites de tasa (rate limits) o latencia de red.

Solución: Implementar reintentos exponenciales en HTTP Request, añadir manejo de códigos 429 y 5xx, y programar ventanas de sincronización fuera de picos de carga.

Resumen ejecutivo: adapte la variante que mejor se alinee con la gobernanza del contrato en su organización (autónoma, híbrida o integrada con finanzas/ERP). Priorice trazabilidad (marcas de procesamiento), seguridad (credenciales y registros) y claridad en las notificaciones para reducir fricción operativa. Las configuraciones de nodos y las pruebas con datos ficticios permiten validar el flujo antes de pasar a producción.