ADR-0006 · El matcher de pagos a proveedores corre en la misma corrida que cobros¶

Estado: aceptado
Decisores: mvaliente
Fecha de la decisión: 2026-08-17
Relacionado: ADR-0005; ADR-13/ADR-17 del paquete Confirmacion Automatica; doc Matcheo de proveedores - análisis NASA SE

Contexto y problema¶

El motor de reglas de pagos (supplier-rules.ts) existía desde el 2026-08-13 sin nada que lo ejecutara: ni log, ni orquestador, ni disparador. El plan original suponía dos prerrequisitos que resultaron falsos:

que había que reactivar el OutgoingBankSyncScheduler para que entraran débitos — verificado el 2026-08-17: el sync de cobros ya trae el extracto completo, créditos y débitos, con detalle estructurado (fila 3510, PROVEEDORES | GLOBO IMPORT EXPORT S.A.);
que el match se haría consultando el ticket al banco (RF-14) — superado: se matchea contra el extracto, con los mismos criterios que cobros (decisión del usuario, TBD-P4).

Decisión¶

Una sola corrida. procesarCuenta evalúa cobros y, a continuación, pagos — mismo disparador, mismo archivo de log, mismo guard de exclusividad por cuenta. Es el mismo sync el que trajo créditos y débitos: pedir un disparador propio sería una segunda pasada por el mismo dato, y separar los archivos obligaría a cruzar dos fuentes para responder "¿cuánto matcheó el sistema hoy?". El campo tipo (cobro | pago) distingue las entradas y el sobre (id, ts, draft.docEntry) es común.

Pero dos mediciones independientes. Los pagos corren fuera del try de cobros y con su propio manejo de errores: una corrida no puede tumbar a la otra. Y sin cobros pendientes no se sale: una cuenta puede tener débitos que conciliar sin un solo cobro esperando.

Piezas hermanas, no genéricas. supplier-log-entry.ts acompaña a supplier-rules.ts: la evidencia de un pago son tres comparaciones (monto, documento, cuenta destino) y ninguna hora ni referencia SIPAP — nadie tipea un ticket al pagar. Forzar el molde de cobros llenaría cada entrada de campos que nunca van a tener valor, y el lector no podría distinguir "no aplica" de "no se pudo comparar", que es la distinción que sostiene todo el módulo (ADR-13).

Interruptor propio, apagado. AUTO_CONFIRM_SUPPLIERS_ENABLED=false y AUTO_CONFIRM_SUPPLIERS_WINDOW_DAYS=1 (contra los 2 de cobros: la transferencia se ejecuta el día que se ordena; en cobros la demora la pone el cliente). El motor de pagos está en TRL 2 de integración contra el 7 de cobros y la regla de gates del paquete dice que nada se declara probado por analogía.

Proveedores se queda en RECOMENDACIÓN. Aunque AUTO_CONFIRM_MODE sea active, acá no se confirma ningún pago: no hay Etapa D para proveedores y no está previsto que la haya por ahora (decisión del usuario).

Consecuencias¶

La preselección de pagos llega por el mismo camino que la de cobros: la reserva (U_MatchDraft) y el aviso match_completed ya existentes sirven sin cambios.
El asimetría con cobros se mantiene y ahora tiene fundamento registrado: en proveedores nosotros elegimos la cuenta destino, así que la evidencia contraria descarta el candidato (un débito que fue a otra cuenta no es un candidato débil, es el movimiento equivocado), mientras que en cobros no descarta porque el pagador tercero es normal.
Queda pendiente la UI (mostrar la preselección en la pantalla de pagos) y la medición del modo sombra, que ahora sí tiene con qué correr.