# INTERLINK — Actualización v2 de conciliación por banco y billetera ## Alcance Actualización incremental de `patch_wa2_conciliacion_macro_v1.zip`. No es el módulo WhatsApp v2 completo. Requiere que la conciliación v1 y su migración estén instaladas. Se conserva la configuración existente: cuenta Macro, CBU/CVU, CUIT titular, método de cobro, zona horaria y modo simulación/confirmación. La cuenta indicada por el usuario es la misma, terminada en **40018**, alias **soluciones.dc**. No se crea una segunda cuenta ni se modifica el alias. El importador usa los valores guardados, no valores bancarios inventados en código. No requiere otra migración SQL. No cambia las tablas ni los índices únicos de pagos, recibos o imputaciones; no modifica tokens, webhook, motor conversacional, suspensión, reactivación ni plantillas Meta. El reparto entre facturas, crédito a favor y aviso de pago existente se conservan. El identificador completo leído también se guarda cuando el comprobante lo etiqueta como transacción o CoelsaID. ## Reglas incorporadas Estas son reglas operativas acordadas con INTERLINK y ejemplos aportados por el usuario; no se presentan como una especificación universal de los bancos. | Origen | Comparación exigida | |---|---| | Mercado Pago | CUIT/CUIL origen exacto y una secuencia común de seis dígitos consecutivos entre la Referencia del banco y el Código de identificación. No se sustituye este último por el número de operación de Mercado Pago. | | Banco Macro | Referencia igual al número de operación completo, sin coincidencias parciales ni eliminación de ceros. | | Naranja X / NX | CUIT/CUIL origen exacto, fecha e importe. Debe existir un único movimiento compatible. | | Ualá | CUIT/CUIL origen, fecha e importe; requiere además un ID de operación/transacción visible para detectar reutilizaciones del comprobante. | | Personal Pay | CoelsaID completo como identificador dentro de Concepto, más CUIT/CUIL origen exacto. No se utiliza un fragmento de seis dígitos. | | BNA | Referencia igual al número de transacción completo. No se reemplaza por cuenta de origen u otro identificador. | | Otros orígenes, incluido Brubank | Se conserva la regla anterior: documento de origen, fecha e importe y coincidencia única; información insuficiente o contradicciones quedan para revisión. | Además, en todos los casos: destino configurado, moneda ARS, importe positivo exacto a centavos, misma fecha, cliente por WhatsApp inequívoco, comprobante del mes de recepción vigente y comprobación de duplicados de todo el historial. La IA extrae los datos pero no autoriza pagos por un puntaje de confianza. Macro/BNA requieren la referencia completa; el documento del emisor no es obligatorio cuando no está visible, pero un documento existente ilegible/contradictorio bloquea el caso. Si el banco informa nombre, se conserva el control conservador de nombre: una diferencia o truncamiento se envía a revisión. Una coincidencia numérica nunca ignora una contradicción visible. Mercado Pago: `887460` coincide dentro de `41479088746065098C`. `887X460`, `887-460` o `887 460` no se convierten en `887460`. Una referencia de tres caracteres no se completa con ceros. La secuencia de seis dígitos NO se usa como clave única de pago; se mantienen las referencias completas y la identidad del movimiento. No se infiere la billetera a partir de la columna Causal ni del destinatario Banco Macro: la entidad debe ser la emisora que aparece en el comprobante. Los campos originales se conservan en `raw_values`. ## Compatibilidad de extractos 1. Reporte clásico: Fecha / Nro. Transacción / Descripción / Importe / Saldo, con número de cuenta en el encabezado. 2. `Ultimos_Movimientos.xls`: Fecha / Nro. de Referencia / Causal / Concepto / Importe / Saldo. Conserva las celdas originales y Causal como evidencia. Excluye el pie Fecha de descarga / Empresa / Operador. En el segundo formato no aparece la cuenta. Al importar, marcar la casilla que confirma que corresponde a la cuenta configurada, mostrada en pantalla. También se exige que el CUIT de Empresa del pie coincida con el del titular configurado. Esta confirmación no agrega otra cuenta. Si cambia la configuración mientras se carga el archivo, la operación se detiene. Los dos formatos generan la misma clave bancaria v1 para un mismo movimiento: cuenta + fecha + referencia + concepto normalizado + importe + saldo. Causal, nombre de archivo, número de fila y formato no forman parte de esa clave. Se conserva además el control histórico que impide reutilizar una referencia conciliada aunque cambie el saldo o la descripción en otra descarga. No acepta un XLSX/CSV/HTML renombrado como XLS ni fórmulas. No se cambian los importes ni las referencias del original. Un archivo truncado, con pie incompleto o columnas inesperadas se rechaza sin importar parcialmente. ## Instalación Hacer copia de seguridad y no ejecutar confirmaciones en paralelo mientras se reemplazan los archivos. Aplicar primero sobre una copia de la aplicación y base. Descomprimir el ZIP fuera de la carpeta pública, por ejemplo en `/root/wa2-reglas-v2`. Antes de copiar, ejecutar este control **de solo lectura**: ```bash php /root/wa2-reglas-v2/whatsapp_v2/bin/check_bank_rules_v2.php /var/www/html/_inc/whatsapp_v2 ``` Debe indicar `diferencias: 0`. Si informa `REVISAR`, hay modificaciones locales o falta la conciliación v1. No sobrescribir a ciegas; comparar los archivos indicados. Copiar el contenido de `whatsapp_v2/` del ZIP sobre `/var/www/html/_inc/whatsapp_v2/`, manteniendo las rutas. Este paquete no contiene configuraciones privadas ni archivos de medios. Después de copiar: ```bash cd /var/www/html/_inc/whatsapp_v2 php bin/check_bank_rules_v2.php php tests/bank_rules_by_origin.php ``` El segundo comando debe informar **90 comprobaciones**. No se conecta a la base, OpenAI o Meta y no crea archivos ni pagos. La v1 también conserva su diagnóstico de entorno: ```bash php bin/check_bank_reconciliation.php ``` ## Primera ejecución Abrir `WhatsApp v2 → Conciliación bancaria`, recargar la página y comprobar que el subtítulo termina en **v2**. Conservar o seleccionar `Solo simulación` para la primera prueba. No se cambia ese ajuste automáticamente al copiar archivos. Importar el XLS nuevo, marcando la confirmación de cuenta. Los ya importados se reutilizan, no se borran ni duplican. Ejecutar **Analizar comprobantes del mes con IA** y luego **Simular conciliación**. Las extracciones de v1 no distinguían CoelsaID de Código de identificación; se solicita una nueva lectura una vez para poder aplicar las reglas nuevas. Puede consumir API OpenAI. Las extracciones v2 del mismo archivo se reutilizan. Los recibos ya conciliados no se vuelven a analizar ni a imputar. Generar una simulación NUEVA. Las simulaciones antiguas no pueden autorizar un pago, tanto por interfaz como por backend. No hay que borrar historial ni reimportar pagos para actualizar reglas. En Ver comparación se verá la entidad, regla, referencias y, cuando corresponda, los seis dígitos encontrados. Si falta un dato requerido o hay dos candidatos, permanece en revisión con su motivo. Tras revisar resultados en la copia de prueba, se puede activar confirmación y generar otra simulación (el cambio de configuración invalida la anterior). Probar primero una única coincidencia. Confirmar una conciliación previa no registra un nuevo pago. ## Archivos de aplicación incluidos Modificados: `app/Bank/BankRules.php`, `app/Bank/BankReceiptExtractor.php`, `app/Bank/BankReconciliation.php`, `app/Bank/BankSettlement.php`, `admin/api_bank_reconciliation.php`, `admin/bank_reconciliation.php`. Nuevo: `app/Bank/MacroStatementParser.php`. También se incluyen verificador de archivos, pruebas puras, manifiesto SHA-256 y diff contra v1. No se incluyen nuevamente `_nav.php`, `api_receipts.php` ni la migración v1 porque esta es una actualización de ese módulo, no una reinstalación. ## Límites y reversión Una coincidencia demuestra concordancia con el extracto cargado, no autenticidad criptográfica del archivo o comprobante ni una consulta directa al banco. El archivo bancario debe obtenerse de la cuenta correcta por un operador autorizado. No se ejecutaron llamadas con las claves del usuario ni se probaron bloqueos sobre su MariaDB real. Los resultados de pruebas locales y sus límites se detallan en `VALIDACION_REGLAS_BANCARIAS_V2.txt`. Un lint no valida por sí solo el proceso bancario. Ante un error, mantener simulación y conservar los registros. Restaurar la copia de los seis archivos modificados solamente con el procesamiento detenido; no borrar tablas, pagos o imputaciones. Volver a v1 también vuelve a sus reglas de coincidencia, por lo que no se deben confirmar simulaciones antiguas bajo un código diferente.