ADR-0007 · La Etapa D confirma, y el criterio pasa de optimizador a satisficiente

• Estado: aceptado
• Decisores: mvaliente
• Fecha de la decisión: 2026-08-19
• Relacionado: ADR-0005, ADR-0006; RF-02, RF-12, RF-18, TBD-12 del paquete Confirmacion Automatica

Contexto y problema

Hasta hoy el módulo decidía pero no ejecutaba. AUTO_CONFIRM_MODE estaba declarado como interruptor y verificado en el código: aparecía en tres lugares y en los tres era solo una etiqueta que se escribía en el registro. No existía ninguna rama que confirmara. Poner active no cambiaba ningún comportamiento.

Al mismo tiempo, el criterio para llegar a auto_confirmado exigía respaldo de identidad: en cobros al menos una de tres pruebas (documento, referencia exacta o nombre exacto); en pagos las dos a la vez (documento del beneficiario y cuenta destino). Ese criterio dejaba fuera dos poblaciones enteras:

• los cobros cuyo movimiento no trae datos del ordenante — el banco los informa en 53 de 1.095 débitos en guaraníes;
• todos los pagos en dólares, porque el extracto de la cuenta 111403 nunca había pasado por el sync que consulta el detalle y sus 326 filas tienen los UDF del beneficiario en null.

Medido sobre el registro de sombra del 12 al 18 de agosto: de 75 borradores de cobro distintos, 18 llegaban a auto_confirmado y 16 quedaban en sugerido por falta de respaldo, con un único candidato de monto exacto en la ventana.

Decisión

1. El respaldo de identidad deja de ser condición cuando el candidato es único.

Se auto-confirma con dos condiciones: - hay un único movimiento reclamable —o varios del mismo monto pero con la identidad señalando a uno solo—; - ningún otro borrador pendiente disputa ese movimiento.

La evidencia de identidad se sigue calculando y registrando: dejó de decidir, no de existir. Es lo que permite medir cuántas confirmaciones tenían respaldo.

2. Existe una pieza que confirma, AutoConfirmerService, gobernada por AUTO_CONFIRM_MODE. En shadow es inerte; en active ejecuta un changeset con las tres operaciones que ya usa la confirmación manual: PATCH de la cabecera, SaveDraftToDocument y escritura del CardCode en la fila del extracto.

3. Proveedores entra a la Etapa D, revirtiendo la definición del 2026-08-17 que lo dejaba en recomendación permanente.

Fundamento

El cambio de criterio es un pasaje de optimización a satisficing. La regla anterior respondía a "confirmar solo con certeza máxima"; la nueva, a "confirmar cuando la evidencia alcanza para el contexto, dado el costo del error". El fundamento del decisor: un movimiento solo, del monto exacto, en la ventana, es con altísima probabilidad el de la solicitud —tanto más cuanto más distintivo el importe— y el caso en conflicto ya está cubierto, porque dos movimientos del mismo monto producen ambiguo y van a mano.

La medición respalda la parte cubierta: el 19,8% de los créditos en guaraníes tiene otro del mismo monto dentro de ±2 días, y todos esos siguen yendo a una persona.

Consecuencias

Lo que se gana. El territorio programado se duplica en cobros (~18 → ~34 casos por semana). En pagos en dólares, la auto-confirmación pasa a ser posible: antes era estructuralmente inalcanzable.

Lo que se acepta. El riesgo residual de que el único movimiento de ese monto corresponda a algo que el OMS no conoce —un pago de un tercero, otra operación—. No hay disputa que detectar porque el otro lado no existe como solicitud, y el monto solo no lo distingue. Se mitiga midiendo, no con más reglas.

Lo que falta y no es opcional. El satisficing exige un nivel de aspiración explícito —cuántos errores por período se aceptan, en cuánto tiempo se detectan— y hoy no está declarado. Es la decisión #6 del paquete, "criterio de salida", y con la Etapa D encendida deja de ser una formalidad: pasa a ser el único instrumento de control.

Auditabilidad. Confirmar solo también consume atención, en otro lugar: alguien tendrá que poder revisar qué hizo la máquina. Si auditar cuesta lo mismo que confirmar a mano, el diseño movió el trabajo en vez de quitarlo. Por eso cada documento confirmado automáticamente lleva en Remarks un sello [auto <id>] con el id de la decisión que lo justificó. El autor sigue siendo el dueño de la solicitud: la trazabilidad comercial no se rompe.

Tope de reintentos. Un dato malo en la solicitud no se arregla solo. Sin tope, un fallo permanente de SAP haría reintentar en cada sync, en silencio y para siempre. AUTO_CONFIRM_MAX_CONFIRM_ATTEMPTS (default 3) corta y devuelve la solicitud a la bandeja. El contador es en memoria: un reinicio lo pierde y se reintenta, que es lo correcto ante un fallo que pudo ser de infraestructura.

Alternativas descartadas

Enchufar el if dentro del evaluador. Habría fundido decidir con ejecutar y roto la descomponibilidad del módulo justo donde más se necesita: el día que haya que apagar esto con urgencia. La pieza vive aparte y se apaga por configuración.

Relajar también la ambigüedad. Se evaluó y se descartó: dos movimientos del mismo monto son indistinguibles por el criterio que quedó, y elegir uno sería sortear. Siguen yendo a una persona.

Persistir el veredicto en el borrador para mostrarlo en pantalla. Se propuso y el decisor lo descartó con un argumento correcto: si todo lo que no se confirmó solo se trata igual, distinguir sugerido de sin_candidato en la UI no le cambia la acción a nadie.

Estado de encendido

AUTO_CONFIRM_MODE=shadow en todos los ambientes. Nada se confirma hasta que esa variable cambie, y ese cambio mueve contabilidad: crea documentos con número, afecta cuentas, cancela facturas y consume movimientos del extracto. Deshacerlo es anular un documento, no borrar una marca.