- sapb1_manager.buscar_factura_existente busca la factura (proveedor, tipo,
serie, número) en facturas de compra no anuladas y en drafts; si existe no
se crea otro draft y se responde "ya está registrada" sin pisar el registro
de una aceptación anterior.
- SapNoDisponible (subclase de ConnectionError) distingue una caída (timeout,
sin conexión, HTTP 5xx) de un rechazo normal de SAP (HTTP 4xx). Una caída
de Service Layer con HANA sin resultados ya no se lee como "guía no existe".
- Con SAP o HANA caídos se avisa una sola vez al proveedor con la plantilla
"En cola" y el correo se reintenta en los ciclos siguientes (hasta 24), sin
repetir avisos; al agotarse se avisa al equipo.
- La lógica por factura pasa a _procesar_factura; lo ya resuelto dentro de un
correo no se repite al reintentarlo.
- seguimiento: columna intentos (con migración), registrar_intento y el
estado de notificación en_espera.
- database_utilities.DB_NAME pasa a ser absoluto (junto al código).
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
El sistema contesta a quien envió el correo con la plantilla que corresponda.
Por defecto (NOTIFICACION_MODO=prueba) la respuesta va solo al equipo con el
asunto "[PRUEBA → remitente]"; en modo real va al remitente con copia oculta
al equipo. El correo técnico (tablas de SAP, JSON) pasa a ir solo al equipo.
- respuesta_proveedor.py: contextos de las plantillas, envío y protecciones
(remitente desconocido o sin dominio, propio buzón, no-reply, mensajes
automáticos, respuestas a notificaciones, límite de 3 por remitente/24 h).
- observaciones.py: motivos de rechazo con título, filas y cómo corregir
(borrador de textos); también para correos sin comprobante válido.
- Un error de SAP/HANA o un fallo inesperado no se le comunica al proveedor y
ya no tumba el ciclo; "guía no encontrada" exige que HANA responda.
- outlook_utilities: es_mensaje_automatico y copia oculta en send_email.
- seguimiento: notificacion_destinatario (con migración) y
contar_respuestas_correo.
- config_validator anuncia el modo activo; documentación y pruebas.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Nueva tabla comprobantes (creada en init_db) y módulo seguimiento.py: cada
comprobante recibe un código ABR-AAMMDD-NNNNN que conserva si reaparece en
otro correo, más su resultado (aceptado/rechazado/error) y el estado de la
notificación. El pipeline lo registra por factura sin bloquear el flujo si el
seguimiento falla. Las pruebas usan una BD temporal para no tocar emails.db.
Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
