CashIN - Cobranzas por transferencia bancaria

No confundir con "Transferencias" ni con "Transferencias Bancarias". Esos manuales son de pagos que SALEN. CashIN es lo contrario: plata que ENTRA por transferencia de un cliente y hay que aplicarla a sus cuotas.

CashIN resuelve una pregunta que antes se contestaba a mano: entró plata por transferencia a la cuenta recaudadora, ¿de quién es y qué cuota paga?

Lo usan cuatro perfiles: el cajero, que le dicta al cliente a dónde y cuánto transferir (la intención de pago); el operador de conciliación, que resuelve lo que el motor no pudo cerrar solo; el administrador, que configura los bancos y el cobro; y soporte, que audita lo que pasó con cada peso.

El circuito completo tiene cinco pasos:

1. El cajero arma la intención (opcional, pero recomendado). Elige el cliente, los créditos y las cuotas, y quién va a transferir. CashIN le da un CBU, un importe y un código de 5 dígitos para dictarle al pagador.
2. El cliente transfiere al CBU de la cuenta recaudadora, o al CVU dedicado que tiene asignado.
3. El Recolector consulta al banco cada tanto y trae los movimientos nuevos al extracto de CashIN. Con BIND, además, el banco avisa por webhook apenas entra la plata, y CashIN va a buscar ese movimiento en el momento.
4. El Conciliador analiza cada movimiento: busca de quién es la plata y, si puede, le pide a Plenario que cobre las cuotas y genere el recibo. Si el cliente no debe nada, le acredita el importe a favor en la cuenta corriente.
5. El operador resuelve a mano lo que el motor no pudo cerrar, deja constancia de lo que ya se cobró por otro lado y descarta lo que no es cobranza.

Las señales con que identifica al cliente

El motor mira las señales en este orden, de la más fuerte a la más débil. El resultado queda guardado con cada movimiento, así que después siempre se puede explicar por qué imputó donde imputó.

Si ninguna intención engancha pero se sabe de quién es la plata, el motor decide solo a qué crédito va: sin deuda, a cuenta corriente; con un solo crédito con deuda, a ese crédito; con varios, un único cobro que Plenario aplica de la cuota más vieja a la más nueva atravesando los créditos (solo en el modo "Con recibo"; en "Movimientos directos" ese caso va a revisión). Si no se sabe de quién es, va a revisión.

Importante: el importe no identifica. El motor no busca "la intención por el mismo monto": sin código en la referencia, una intención se reconoce por el CUIT de quien transfiere o porque es la única del cliente. Y una intención "viva" es Abierta o Matcheada: el motor no mira la fecha de vencimiento.

Importante: el motor es conservador a propósito. Ante cualquier duda manda el movimiento a revisión con el motivo escrito, en vez de adivinar: imputar la cuota equivocada se descubre tarde y se arregla peor.

Qué pasa con la plata que sobra o que falta

CashIN siempre le manda a Plenario el importe que entró: nunca recorta la plata. Lo que hace Plenario con la diferencia depende del caso.

Tres cosas que conviene saber antes de empezar

• CashIN nunca escribe cuotas por su cuenta. El cobro y la acreditación se le piden a Plenario, que es el que genera el recibo o el asiento. Si Plenario no confirma, el movimiento queda sin cobrar y se reintenta.
• El orden de las cuotas lo decide Plenario, no CashIN. Siempre de la más vieja a la más nueva. Por eso, al tildar una cuota, se tildan todas las anteriores.
• Para que se mueva plata hacen falta DOS interruptores prendidos: "Habilitar el cobro real" y el "Estado" de la aplicación de cobranza en "Activo — aplica el cobro" (los dos en Configuración). Con cualquiera apagado, el motor identifica y muestra a qué crédito iría cada pago, pero no escribe en Plenario.

1. Abrí la aplicación — ingresá a la URL de CashIN de tu instalación. Es una aplicación web aparte del Plenario de escritorio.
2. Iniciá sesión — con tu usuario y contraseña de Plenario. CashIN no tiene usuarios propios: valida contra el ERP. La sesión de CashIN dura 8 horas y se renueva mientras la uses.
3. Elegí la pantalla en el menú de la izquierda — arriba figura "Plenario CashIN · Cobranzas por transferencia"; abajo, las pantallas agrupadas en cuatro secciones. Solo ves las que tu usuario tiene permitidas.
4. Fijate la insignia de ambiente — arriba a la derecha dice contra qué ambiente del banco está trabajando la instalación ("Sandbox (pruebas)", "Homologación" o "Producción (banco real)").

Todos los permisos llevan el prefijo WebAppCashin.

Importante: cada ítem del menú depende de su permiso, que contesta Plenario. Las tres entradas de "Configuración de banco" dependen además de que ese banco esté activo en la instalación (parámetro CashIN:BancosActivos del servidor; si no está, opera solo BIND). Un banco no activo no aparece en el menú y su pantalla responde "no encontrada" aunque se escriba la dirección a mano.

Importante: dos pantallas no están en el menú a propósito. A la Caja se entra desde Intenciones → "+ Nueva intención" o desde el botón "Crear intención" de Conciliación; el ítem Intenciones queda marcado como activo mientras se arma una. Devoluciones se ocultó porque por ahora no se usa, pero la página sigue viva: se llega escribiendo /Devoluciones.

Importante: si el WCF de Plenario no contesta, debajo del menú aparece "⚠ No se pudieron consultar los permisos: {motivo}". Un menú corto no siempre significa que te falten permisos: puede ser que no se le haya podido preguntar.

La barra superior

Arriba a la derecha están:

• El breadcrumb "Sección · Título" de la pantalla.
• La insignia de ambiente: muestra el ambiente en uso del banco de la primera cuenta recaudadora habilitada (si no hay ninguna habilitada, la de la primera cuenta cargada) —"Sandbox (pruebas)", "Homologación", "Producción (banco real)" o "Sin ambiente en uso"— y debajo el nombre del banco. El color cambia: neutro en Sandbox, de atención en Homologación, de alarma en Producción y apagado sin ambiente. El tooltip dice "{Banco} · cuenta {cuenta recaudadora}". Dice "Sin configurar" si no hay ninguna cuenta cargada (tooltip: "No hay ninguna cuenta habilitada para recaudar."), si el banco no tiene configurada la conexión con su API o si no se pudo leer la configuración; en esos casos el tooltip dice el motivo. Un clic lleva a /Cuentas si tenés Banco.Administrar; si no, al Dashboard.
• El chip de usuario con tus iniciales, nombre y usuario. Al hacer clic despliega "Cerrar sesión".

Al pie del menú está el 🌓 para cambiar entre tema claro y oscuro (se recuerda en el navegador) y la leyenda de versión.

Cuando vence la sesión de Plenario

La sesión de Plenario vence antes que la de CashIN. Si al apretar un botón que habla con el servidor la sesión del ERP ya venció, aparece un aviso único —"Tu sesion de Plenario vencio", el motivo que manda el servidor, "No se cobro nada: el movimiento sigue en la cola tal como estaba." y "Te llevamos al login…"— que se cierra solo a los 2,2 segundos y te lleva al login; al volver a entrar, quedás en la misma pantalla. Este aviso sale en las acciones que trabajan sin recargar la página (Conciliar, Aplicar, Marcar, la Caja, el Relay…); en los formularios comunes (el "↶" chico, el Motor, Destrabar, Cancelar una intención) la sesión vencida te lleva directo al login.

Importante: con la aplicación de cobranza activa, en Conciliar y Aplicar el servidor verifica la sesión antes de abrir el modal y antes de cobrar, así que un vencimiento nunca deja un cobro a medias: "Tu sesión de Plenario venció. Volvé a iniciar sesión y reintentá: el movimiento sigue en la cola y NO se cobró nada."

El Dashboard es la pantalla de inicio y el tablero del módulo. Es la única que no pide permiso: es a donde se llega después del login.

El interruptor del Motor

Arriba a la derecha hay tres controles: el selector "Auto-refresh" (Off · 15 s · 30 s · 60 s; la elección se recuerda en el navegador), el botón ↻ "Actualizar ahora" y el interruptor "Motor", cuyo tooltip dice "Apagar el motor" o "Encender el motor". Al moverlo se deshabilita y la página se recarga con el estado que quedó guardado. Requiere Motor.Operar; sin él, la página vuelve al estado anterior con "No se hizo nada: {motivo}".

Con el motor apagado aparece un cartel amarillo fijo —"El motor está apagado: no corre nada automático. Cada agente se puede disparar a mano con "Ejecutar ahora"."— con cuándo se apagó y quién lo hizo.

Importante: apagar el motor no detiene lo que ya está corriendo. Mientras esté apagado, los agentes no corren por agenda y el aviso del banco (webhook) se registra pero no va a buscar el movimiento. "Ejecutar ahora" y el Relay sí funcionan con el motor apagado: para eso están.

Si se entró con la sesión de desarrollo (solo en equipos de desarrollo), al pie de la tarjeta de los agentes aparece "⚠ Sesión sin validar contra Plenario (modo desarrollo) · Banco simulado".

Los indicadores

Los dos agentes

La tarjeta "⚙ Operaciones del motor" tiene una tarjeta por agente. Los nombres son los mismos en todas las pantallas:

Cada tarjeta muestra "Última corrida" (con el relativo "hace N min"), "Próxima corrida", "Cada N min" y, si hay, el último mensaje del agente (texto chico, con el mensaje completo en el tooltip). La próxima corrida dice "— motor apagado" si el interruptor está en off, y "— proceso detenido" si ese agente está inactivo en Configuración.

El Recolector muestra además "Hoy: N traídos" (por fecha de ingreso a CashIN) y "Sin procesar: N"; el Conciliador, "Pendientes ahora: N", "Hoy: N imputados" (por fecha de imputación, incluye acreditaciones) y, si hay algo pendiente de revisar, "⚠ N en revisión — revisar".

Los badges de la cabecera son "Corriendo" y "Detenido":

• Corriendo: el agente arrancó hace menos de 30 minutos y no terminó. El botón "▶ Ejecutar ahora" queda apagado y debajo dice "Está corriendo desde las {HH:mm} — por eso el botón está apagado, para no lanzar la misma corrida dos veces. Cuando termine se habilita solo."
• Detenido: el agente está inactivo en Configuración. "⏸ El proceso está detenido: no corre por agenda. Podés dispararlo a mano con el botón, pero no se va a repetir solo hasta que lo actives en Configuración."

Importante: la marca de "corriendo" vence sola a los 30 minutos. Si una corrida se cortó por el medio (por ejemplo, se reinició la aplicación), pasado ese tiempo la tarjeta deja de decir "Corriendo" y el agendador vuelve a tomar el agente sin que nadie haga nada. Además, la marca se suelta sola cada vez que arranca la aplicación.

Ejecutar ahora y Destrabar

"▶ Ejecutar ahora" dispara ese agente en el momento, aunque el motor esté apagado. Abre el modal "Ejecutando" ("Puede tardar unos segundos.") con el botón "Dejar en segundo plano": irse de la página no corta el trabajo, el servidor lo termina igual y el resultado llega como aviso arriba a la derecha. Al terminar muestra "Listo" (o "No se pudo ejecutar") con "{Nombre} — {último mensaje}" y recarga. El permiso depende del agente: Recolector.Ejecutar para el Recolector, Conciliador.Ejecutar para el Conciliador. Si el agente ya está corriendo, responde "{Nombre} ya se está ejecutando (arrancó a las HH:mm). Esperá a que termine y volvé a intentar: el resultado va a aparecer solo."

"⚑ Destrabar motor" aparece cuando algún proceso tiene puesta la marca de "corriendo" (aunque esté vencida). Confirma con "Destrabar los procesos — Marca como no-corriendo a los que quedaron trabados (por ejemplo si la app se reinició en medio de una ejecución) para que vuelvan a entrar en la agenda." y responde "No había ningún proceso trabado." o "N proceso(s) destrabado(s). Vuelven a entrar en la agenda.". Requiere Motor.Operar.

Importante: con la marca que vence sola, "Destrabar" casi nunca hace falta. Si se usa con una corrida viva, el Conciliador igual está protegido: un segundo Conciliador no puede arrancar mientras haya otro corriendo (candado de base de datos). El Recolector no tiene ese candado: lo que evita duplicados es la verificación previa y el índice único del extracto en la base.

Últimas consultas al banco

Al pie, la tarjeta "Últimas consultas al banco" lista las diez últimas operaciones con el banco: "Fecha", "Operación", "Movs", "Estado" y "Mensaje". Incluye los barridos del Recolector, las consultas del Relay y los avisos del webhook. Si nunca se consultó: "Todavía no se consultó al banco."

Las otras pantallas de un vistazo

Cada pantalla arranca con un rango distinto, y eso es a propósito.

Conciliación — arranca en HOY

Botones "Filtrar" y "Hoy", que vuelve a la pantalla sin ningún filtro (no solo la fecha).

Importante: los movimientos excluidos (por regla o con el ✕) no aparecen en Conciliación: están en Excluidos. Los descartados con "✕ No es un pago de cartera" sí aparecen, con el estado "Descartado".

Movimientos — arranca en los ÚLTIMOS 7 DÍAS

Un solo botón: "Filtrar".

Intenciones — nueve filtros que se combinan

Botones "Filtrar" y "Limpiar".

Importante: el placeholder del campo Concepto muestra CIN-000123, pero el código real es un número de 5 dígitos (entre 10000 y 99999). Es corto a propósito, porque el cajero se lo dicta al pagador de palabra o por teléfono.

Excluidos

Botones "Filtrar" y "Limpiar". El número de la columna "Aplicó a" de cada regla también filtra el listado por esa regla.

Reportes

Arranca en hoy solo si no se indicó ni Desde ni Hasta (Hasta vacío = sin tope).

Botones "Hoy" y "Filtrar".

Devoluciones

Precarga todo sin rango. Filtra por "Desde", "Hasta" (fecha del banco o de ingreso), "Banco", "Tipo", "CUIT del pagador", "Referencia" (id del banco, Coelsa, concepto o nombre), "Cliente" y "Crédito", con "Limpiar" y "Filtrar". No muestra excluidos, débitos, descartados ni conciliados a mano.

Paginado y tope

Todas las grillas comparten el paginado: "Mostrando X–Y de Z" y el selector "Filas" (Todos · 5 · 15 · 25 · 50 · 100; por defecto 25).

Importante: hay un tope de seguridad de 2000 filas. En Conciliación y Devoluciones rige siempre; en Movimientos, Intenciones, Excluidos y Reportes (que paginan en la base) solo con "Filas: Todos". Si se supera, el pie avisa "⚠ cortado en 2000": no es que no haya más, es que no se trajeron. Achicá el rango.

Los once estados de Conciliación

El estado no es una columna de la base: sale de cruzar el estado del movimiento con el de su imputación. Por eso el filtro de estado se aplica sobre todo el conjunto, no sobre la página.

Importante: "Conciliado · recibo sin liquidar" es terminal para esta pantalla. Reintentar desde acá le dejaría al cliente un segundo recibo colgado. El Conciliador, en cada corrida, le pregunta a Plenario si esos recibos ya se liquidaron: los que sí, pasan solos a "Cobrado en Plenario" con la nota "El recibo {n} figura liquidado en Plenario: la conciliación se puso al día sola." Los otros tipos de constancia (incierto, parcial, ya procesado) no se ponen al día solos.

Importante: un movimiento en revisión no se muestra como "Sin identificar" cuando el motor dejó guardado el cliente: aparece como "Identificado sin cobrar". Identificar al pagador y decidir a qué crédito imputarle son dos preguntas distintas, y que falte la segunda no borra la primera. Ojo: en los motivos "El concepto matchea {n} intenciones abiertas" y "{n} intenciones abiertas para el CUIT", el motor no guarda el cliente y el movimiento figura como "Sin identificar" aunque el CVU o el CUIT lo hubieran reconocido.

Cómo se calcula el estado

El cruce se evalúa en este orden; el primero que se cumple manda:

1. Sin imputación → Pendiente de procesar.
2. Imputada → Cobrado en Plenario.
3. Acreditada en cuenta corriente → Acreditado en cuenta corriente.
4. Conciliada a mano → Conciliado a mano (se evalúa antes que el paso 9 porque la marca también guarda una referencia en el campo del recibo).
5. Rechazada → Descartado.
6. En devolución → En devolución.
7. Devuelta → Devuelta.
8. En revisión sin constancia del ERP → Identificado sin cobrar si ya tiene cliente; si no, Sin identificar.
9. Cualquier otra con algo en el campo del recibo → Conciliado · recibo sin liquidar.
10. El resto → Sin deuda · por acreditar si el desenlace es cuenta corriente; Identificado sin cobrar si tiene crédito o cliente; Sin identificar si no.

La tarjeta partida en dos

Encima de la lista hay dos rótulos: "Movimiento del banco · estado" y "Aplicación en Plenario · importe y estado"; entre los dos lados de cada fila va una flecha ➜.

Lado izquierdo: el banco

• Primera línea: el importe, la fecha del banco (dd/MM HH:mm), el badge del estado y, si corresponde, el badge "SIMULADO" (tooltip: "Movimiento generado por el simulador (Configuración → Modo simulación). No vino de un banco real: sirve para probar el circuito sin credenciales." con el id).
• Segunda línea (tooltip: el id del banco): de quién es la plata. Si la plata entró a un CVU registrado y activo, el dueño de ese CVU con su CUIT; si no, el nombre y CUIT del ordenante ("Sin nombre" / "sin CUIT"). Después el banco y el concepto.
• Acciones del lado banco: en "Cobrado en Plenario" y "Acreditado en cuenta corriente", "↶ Deshacer". En "Descartado" y "Conciliado a mano", nada. En todos los demás, el tilde para descarte en lote ("Marcar para descartar varios juntos") y el "✕" rojo ("No es un pago de cartera: excluir de la conciliación"); el servidor igual bloquea los que tengan constancia del ERP.

Lado derecho: Plenario

Hay cinco formas, según lo que se haya hecho:

En los cobrados y acreditados reales, a la derecha aparece "✓ Cobrado" o "✓ Acreditado", con el tooltip "{fecha} · la reversa se hace por el BO".

Qué botones aparecen en cada estado

"Marcar conciliado" y "Crear intención" consultan el permiso al dibujar la pantalla: si Plenario dice que no, no aparecen; si no se le pudo preguntar, aparecen inactivos con el motivo en el tooltip ("No se pudo confirmar el permiso con Plenario: {motivo}"). Los demás botones se dibujan siempre y el servidor verifica el permiso al apretarlos: "No se hizo nada: {motivo} NO se cobró ni se movió nada."

Los indicadores de Conciliación

Arriba van las tarjetas: primero "Movimientos" (no clicable) con el total y el importe de lo filtrado, y después una por estado, cada una con cantidad e importe y clicable para filtrar. Un estado en cero no se dibuja, salvo que sea el filtro vigente (queda resaltado).

Importante: los indicadores se calculan sobre todo lo filtrado, nunca sobre la página visible. Al hacer clic en una tarjeta se conservan Desde, Hasta, CUIT y Referencia, pero se pierden los filtros de Banco, Crédito y Solicitud.

Si el cobro real está apagado, la pantalla lo avisa con un cartel fijo:

El cobro real en Plenario está deshabilitado (Configuración → Cobro real). Los movimientos se identifican y se ve a qué crédito irían, pero no se escribe en el ERP: por eso quedan en identificado sin cobrar en vez de pasar a cobrado.

Los motivos de revisión

Cuando el motor manda un movimiento a revisión, el motivo queda escrito en la tarjeta. Estos son los textos y qué significan:

El detalle de un crédito

El enlace "crédito #N" (tooltip: "Ver las cuotas de este crédito: cobradas y pendientes") abre un modal de solo lectura titulado "Crédito #N · {cliente}", con el resumen "X de Y cuotas pagas · N vencida(s) · cobrado $ A · pendiente $ B", el badge "Cancelado" si corresponde, y la tabla "Cuota", "Vence", "Valor", "Cobrado", "Saldo", "Estado" (Pagada · Parcial · Vencida · Pendiente) y "Cobrada el", con una fila "Total". Las cuotas se leen del ERP en el momento.

Las columnas del extracto (Movimientos y Excluidos)

"Fecha" (con el badge "SIMULADO" si corresponde), "Banco", "De quién es" ("{Nombre} (#{cliente})" + "CUIT … · CVU …" o "sin CVU reconocido"), "Quién la ordenó" (nombre, CUIT y los últimos dígitos del CBU de origen), "Monto" (con la marca "débito" debajo si es un débito), "Concepto", "Estado" y "Recibo". En Excluidos no están "Estado" ni "Recibo": en su lugar va "Por qué" —el badge "Regla" con el texto de la regla (o "(regla eliminada)"), o "A mano", más quién y cuándo lo excluyó—, con el tilde de selección y el botón "Reactivar" en cada fila.

Importante: la columna que identifica al cliente es "De quién es" (el CVU destino), no "Quién la ordenó". Con BIND el ordenante a veces es siempre la misma cuenta del banco emisor: mirando esa columna todos los movimientos parecen iguales.

La columna "Estado" de Movimientos muestra el código interno (Nuevo, ProcesadoCashIN, Ignorado, Imputada, AcreditadaCtaCte, Rechazada, ConciliadaManual, EnRevision, EnDevolucion, Devuelta…), no el nombre de Conciliación. La columna "Recibo" muestra la constancia del ERP; en los conciliados a mano, la referencia cargada o "MANUAL" si no se cargó ninguna. Debajo del Relay se lee "Última consulta: dd/MM HH:mm:ss · {operación} · {mensaje}".

La grilla de Intenciones

Columnas: "Fecha", "Concepto", "Titular (a quién se le paga)" (razón social + "Cliente N"), "Crédito" (el número, o "N créditos" con la lista en el tooltip), "Pagador (quién paga)" (nombre + CUIT · DNI), "Transfiere a" (banco + cuenta), "Monto", "Cuotas" (por crédito, separadas con " · "), "Vence", "Estado" y las acciones "Ver datos", "Cancelar" y "Eliminar".

Las columnas de Reportes

"Fecha", "Operación", "Resultado", "Importe", "Movimiento" (fecha + nombre; tooltip con el id del banco), "Cliente / crédito", "Plenario" (referencia + clave de idempotencia, con el tooltip "Clave de idempotencia con la que salió la operación"), "Usuario" y "Detalle". Arriba, la tarjeta "Operaciones" con el total y una tarjeta por tipo con cantidad e importe, clicable (conserva fechas, resultado y usuario).

Los diez tipos de operación son: Cobro en Plenario, Acreditación en cuenta corriente, Devolución al pagador, Reaplicación del cobro, Reversión de la acreditación, Devolución confirmada por el banco, Reversión de la imputación, Descarte del movimiento, Conciliado a mano (fuera de CashIN) y Se quitó la marca de conciliado a mano. Los resultados: Aplicada, Con error y Bloqueada.

Importante: se registra también lo que no se dejó hacer y cada intento fallido del motor. Una fila roja en Reportes no significa que se haya movido plata. Con el cobro real apagado, cada corrida del Conciliador suma filas "Con error" por los movimientos que no pudo cobrar: es esperable.

Correr los agentes a mano

El Relay. "▶ Iniciar Relay" (en Movimientos: "Consulta al banco cada 20 segundos durante 2 minutos (6 consultas) para verificar si entró un pago recién hecho. Independiente del proceso automático.") abre el modal "Buscando pagos en el banco" con un contador vivo —"Ns de 120 · consulta N de 6"— y el número de movimientos recolectados, que se pinta verde apenas entra algo. La primera consulta sale en el acto; cada consulta es un barrido completo de todas las cuentas activas. Tiene dos botones, "Parar" y "Cerrar", y los dos cortan las consultas; no se cierra con Escape ni clickeando afuera. Termina en "¡Entró la plata!" ("Se recolectó N movimiento(s). Ahora conciliá para imputarlo.") o en "Todavía no entró" ("El banco no devolvió ningún movimiento nuevo en 120 segundos. Si recién transfirieron, puede tardar un poco más: volvé a correrlo."). Si entró algo, al cerrar se recarga la pantalla.

Importante: el Relay no se corta cuando entra el primer movimiento: corre los dos minutos completos, para no dejar sin recolectar el resto de un lote. Y no concilia: solo trae.

Importante: si al usuario le falta Recolector.Ejecutar, el Relay no lo dice: cuenta cero durante los dos minutos y termina en "Todavía no entró". Si un Relay nunca encuentra nada, revisá el permiso.

Conciliar pendientes (Movimientos; tooltip "Identifica los movimientos sin procesar y cobra en Plenario lo que corresponda") y Procesar pendientes (Conciliación) corren el Conciliador completo sobre todo lo pendiente. La espera es bloqueante —en Movimientos, "Conciliando pendientes… / Se identifica cada movimiento y se cobra en Plenario. Puede tardar."; en Conciliación, "Procesando pendientes… / Identificando e imputando. Puede tardar: se le pide a Plenario un cobro por cada crédito."— y al terminar muestra "Listo" con el resumen de la corrida, por ejemplo: "12 procesados, 9 cobrados, 2 identificados sin cobrar, 1 en revisión". Las partes posibles del resumen son: procesados, revisiones con cliente identificado que se resolvieron, recibos ya liquidados que pasaron a cobrados, devoluciones confirmadas por el banco, cobrados, identificados sin cobrar, en revisión, no se pudieron guardar, esperando poder cobrar, o "nada para hacer".

Si ya hay una corrida en curso —la agenda u otro usuario— responde: "Ya hay una corrida del Conciliador en curso (la agenda u otro usuario): no se lanzó otra. Probá de nuevo en un momento."

Importante: los dos botones cobran en Plenario, con un pedido por movimiento. Si se corta la conexión, Movimientos avisa "⚠️ Si la corrida ya habia empezado, puede haber cobrado algo: revisa la grilla antes de reintentar."; Conciliación muestra "No se pudo procesar · No se cobró ni se movió nada.", pero si la corrida ya había empezado puede haber cobrado igual. Ante un corte, mirá la grilla antes de reintentar.

Conciliar un movimiento

El botón "Conciliar" aparece en los cuatro estados en que Plenario todavía no escribió nada: Pendiente de procesar, Sin identificar, Identificado sin cobrar y Sin deuda · por acreditar. Su tooltip lo anuncia: "Si el pago tiene intención, lo cobra el Conciliador con esa intención. Si no, se abre el modal para elegir el crédito y las cuotas."

Al apretarlo, el botón pasa a "Analizando…" y aparece la espera "Analizando el movimiento… / El motor lo está cruzando contra Plenario. Si tiene intención, la cobra." El servidor:

1. Verifica el permiso Conciliacion.Conciliar y que la sesión de Plenario siga viva.
2. Si el movimiento está conciliado a mano, se niega: "Este movimiento está conciliado a mano (se saldó fuera de CashIN). Para volver a conciliarlo, primero quitá la marca."
3. Vuelve a analizar el movimiento desde cero, con la misma lógica del motor y sin cobrar. Si no es una transferencia entrante: "Este movimiento no es una transferencia entrante: el motor de cobranza no lo procesa."
4. Si el análisis lo enganchó a una intención, se lo pasa al Conciliador —el mismo agente, con su mismo procedimiento— solo para ese movimiento, y lo cobra sin abrir el modal: la intención ya dice a qué créditos y cuotas va.
5. Si no hay intención, abre el modal "Conciliar el movimiento" y el cobro lo decide el operador con el botón del modal.

Importante: si cerrás el modal sin aplicar y el motor ya había identificado al cliente y el crédito (o que no debe nada), la fila queda "Identificado sin cobrar" (o "Sin deuda · por acreditar") y la próxima corrida del Conciliador lo cobra o lo acredita sola. Si no querés que eso pase, resolvelo en el momento: "Marcar conciliado", "✕" o "Crear intención".

Si el pago tiene intención: cobra directo

Importante: con intención, el clic en "Conciliar" es la confirmación: la plata se mueve en ese momento. Si la intención no corresponde a ese pago, cancelala antes de apretar.

Si no tiene intención: el modal "Conciliar el movimiento"

El modal se titula "Conciliar el movimiento" y debajo muestra la pista principal del servidor, por ejemplo "El motor lo identificó: crédito {N}. Revisá y confirmá para aplicarlo." o "El motor no pudo identificarlo."

Una tarjeta de contexto de dos lados resume el caso: PAGA (importe, fecha, nombre, CUIT y concepto o "sin concepto") y SE LE APLICA A (razón social, "Cliente N · CUIT" y, si hay intención, su código, estado, créditos y monto; o "Sin créditos con cuotas impagas"; o "Sin identificar / Buscá al titular abajo.").

Debajo, la pista con 💡, en este orden de prioridad:

• Lo que ya resolvió el motor: "Identificado por el CVU {cvu}, que es de este cliente. El ordenante ({nombre}) es quien hizo la transferencia, no necesariamente el titular." o "El motor ya identificó al titular de este movimiento."
• Una intención vigente: "Hay una intención de pago ({código}, {estado}) a favor de {titular}, {créditos}, por $ X — la generó {pagador} como pagador."
• Lo que dice el CUIT del ordenante en Plenario: "El CUIT del ordenante es un cliente con deuda: es él quien paga." o "Es un cliente de Plenario, pero NO tiene créditos con cuotas impagas: no hay a qué imputar."
• Si no hay nada: "El banco informó “{nombre}” como ordenante. Buscá al titular del crédito."

Si el pago tenía intención y el Conciliador lo dejó en revisión, la pista principal es ese motivo: "El Conciliador lo dejó en revisión: …".

Importante: el modal no se cierra clickeando afuera (sí con la ✕, "Cancelar" o Escape) y al cerrarse siempre recarga la pantalla: el análisis ya cambió el estado en el servidor, así que lo que se ve después es lo que hay.

Buscar al titular

Solo aparece si no se identificó al cliente, o después de "↩ No es este · buscar otro". Campos "CUIT", "Documento" y "Nombre o apellido", que se combinan entre sí ("Buscá al titular del crédito, que puede no ser quien transfirió. Los criterios se combinan entre sí."); botones "Buscar" y "Limpiar"; Enter también busca. El buscador viene precargado con el CUIT del ordenante solo si no se sabe de quién es la plata.

Solo devuelve clientes con deuda (hasta 50). Con uno solo, abre directo sus créditos; con varios, muestra "Cliente", "CUIT", "Deuda" y "Elegir". Sin resultados: "Ningún cliente con deuda coincide.", y si había CUIT junto con otro criterio: "Ojo: el CUIT también está filtrando. Vaciálo si buscás por nombre."

Elegir créditos y cuotas

Elegido el cliente, aparece su línea con "↩ No es este · buscar otro" y un desplegable por crédito —"Crédito #N", "N cuota(s) · adeuda $ X"— con un contador que pasa de "Sin cuotas" a "N cuota(s) · $ X". La tabla rotula "Cuota del crédito #N", "Vence" (con "VENCIDA") e "Importe".

• Se pueden tildar cuotas de varios créditos, y se cobran juntas en un solo recibo ("Podés tildar cuotas de varios créditos: se cobran juntas en un solo recibo.").
• Dentro de cada crédito se tilda en orden: tildar una tilda las anteriores; destildar una destilda las posteriores ("Se tildan en orden desde la más vieja: Plenario cobra siempre así.").
• El tope es por monto, sobre el total: una cuota se apaga si no entra en lo recibido, descontando lo ya tildado en otros créditos (tooltip "No entra en los $ X que se recibieron (ya hay $ Y tildados en otros créditos)."). Lo ya tildado nunca se apaga.
• Preselección: solo con una intención de varios créditos el modal tilda solo, crédito por crédito y en el orden de la intención, hasta donde alcanza la plata. En los demás casos tilda el operador; si el cliente tiene un único crédito, viene desplegado.

El pie dice, en vivo, "Seleccionado $ X de $ Y" —con "(N créditos, un solo recibo)" si hay varios— más "cubre exactamente lo que entró", "sobran $ N como saldo a favor" o "se pasa $ N: Plenario cobra parcial". Sin nada tildado: "Elegí las cuotas a cobrar."

Importante: con un solo crédito, "Aplicar cobro" le manda a Plenario el crédito y el importe completo, sin lista de cuotas. Si sobra respecto de lo tildado, Plenario lo aplica a la cuota siguiente del mismo crédito (pago parcial), aunque el pie diga "sobran $ N como saldo a favor"; a cuenta corriente va solo lo que sobre después de cancelar el crédito.

Aplicar el cobro

El botón del pie dice "Aplicar cobro" y se valida al hacer clic: sin cliente, "Elegí primero el cliente al que se le aplica."; sin cuotas, "Seleccioná las cuotas a pagar: tildá al menos una cuota." Mientras aplica: "Aplicando el cobro… / Esperando la respuesta de Plenario. No cierres la ventana."

Del navegador no viaja ni un importe: solo los ids de crédito y los números de cuota. La deuda se relee en Plenario en el momento. Si las cuotas tildadas ya estaban cobradas, se toman tantas como se eligieron desde la más vieja impaga; con varios créditos queda anotado "⚠ Algunas cuotas elegidas ya estaban cobradas: se aplicó sobre las que siguen impagas." (con un solo crédito hoy no se avisa).

Bloqueos del servidor, con su texto:

Con cuotas de varios créditos, la plata se reparte en el orden tildado: si no alcanza, la última queda parcial; si sobra, el resto va a cuenta corriente. Si Plenario rechaza un cobro de varios créditos, el movimiento queda en revisión y no se reintenta solo; si rechaza el de un crédito, el movimiento vuelve a la cola y el Conciliador lo reintenta en su próxima corrida.

Importante: hay dos candados contra el doble cobro en el modal: uno mientras la llamada está en curso, y otro permanente una vez que salió bien —el botón queda "Aplicado" y muerto aunque el modal siga visible—. Como red de seguridad, a los 15 segundos la pantalla se recarga igual.

Importante: al cobrar bien, la intención mostrada pasa a Imputada si es del cliente al que se aplicó. Si el operador cambió de cliente, la intención que había reclamado el motor se libera y vuelve a Abierta.

Importante: "Aplicar cobro" y "Acreditar" del modal no mandan el aviso por mail al cliente. El mail solo lo manda el Conciliador (la agenda, "Procesar pendientes", "Conciliar" con intención y la Caja desde Conciliación).

Cuando el cliente no debe nada

Si el cliente elegido no tiene ninguna cuota impaga, el modal cambia entero: aparece "Sin cuotas impagas", el texto que explica que los $ N quedan registrados a favor del cliente en su cuenta corriente, y el botón pasa a "Acreditar en cuenta corriente" ("Se acredita a favor de {cliente}.").

Debajo, a propósito no escondidas en un menú, están las otras dos salidas, con el hint "Si no corresponde acreditarle, tenés las otras dos salidas acá abajo. Ninguna es la obvia: elegí la que pasó de verdad.":

• ↩ No es este cliente · buscar otro titular
• ↪ Devolver la plata al pagador — abre "Devolver la plata al pagador" con motivo opcional y el botón "Marcar para devolucion": el movimiento sale del circuito y queda En devolución. Requiere Conciliacion.Revertir.
• ✕ No es un pago de cartera — abre "No es un pago de cartera" con motivo y el botón "Descartar": queda registrado como Rechazada ("Movimiento descartado. Queda registrado como Rechazada, no se borró.") y se ve como Descartado en la misma Conciliación. Requiere Conciliacion.Descartar.

Al acreditar, el servidor revalida contra Plenario:

• Si ya hay constancia: "Este movimiento ya está acreditado en Plenario ({n}). No se acredita dos veces. Si querés deshacerlo, cerrá esto y usá el botón “Deshacer” de la fila."
• Si aparecieron cuotas: "{cliente} SÍ tiene cuotas impagas: corresponde cobrarlas, no acreditar. Se actualiza la pantalla para que puedas conciliarlo contra el crédito."
• Si Plenario dice que ese identificador ya se usó y la acreditación sigue viva, no acredita de nuevo: pone al día el estado con el movimiento y el asiento que ya existían.

Importante: marcar para devolución no transfiere nada. "La transferencia de vuelta la libera Tesoreria por su circuito." Después se confirma desde Devoluciones.

Marcar conciliado

Para un pago que ya se saldó fuera de CashIN —el caso típico: el cajero lo cobró por el BO antes de que CashIN lo procesara, o la transferencia llegó desde un CUIT que no permite identificarla y alguien la imputó a mano en Plenario—. No cobra, no acredita y no escribe nada en Plenario: deja la constancia y saca el movimiento de la cola.

El botón "Marcar conciliado" aparece en los cuatro estados resolubles si el usuario tiene Conciliacion.Conciliar (tooltip: "Ya se saldó fuera de CashIN (por ejemplo, lo cobraron en el BO): dejar constancia y sacarlo de la cola. No cobra nada."). Abre el modal "Marcar como conciliado" con el resumen "$ X · {quien} · dd/MM HH:mm" y la explicación "Para un pago que ya se saldó fuera de CashIN (por ejemplo, lo cobraron en el BO). No cobra ni toca nada en Plenario: deja la constancia y lo saca de la cola. Los datos son opcionales."

Botones "Marcar conciliado" y "Cancelar". Al marcar:

• Se borran las propuestas sin cobrar que había dejado el motor.
• Si había una intención Abierta o Matcheada ligada, pasa a Imputada (cumplida).
• El movimiento queda "Conciliado a mano". Si no se cargó referencia, se guarda "MANUAL" en el campo del recibo, para que todos los candados contra el doble cobro lo protejan.
• Queda en Reportes como "Conciliado a mano (fuera de CashIN)", con el usuario.
• Mensaje: "Quedó marcado como conciliado a mano ($ X). CashIN no cobró ni movió nada en Plenario."

No se puede marcar lo que ya está resuelto: "No se marcó: …" si ya estaba marcado, si lo cobró CashIN, si está acreditado, en devolución, descartado ("reactivalo primero (↶)"), con constancia del ERP o con un cobro repartido parcialmente cobrado. Solo se marcan transferencias entrantes.

Importante: un movimiento conciliado a mano no se puede Conciliar, Descartar, Excluir ni Devolver: cada camino lo bloquea y remite a "Quitar marca". El motor tampoco lo vuelve a mirar.

Importante: "Marcar conciliado" es una declaración del operador. CashIN no verifica contra Plenario que el cobro exista. Cargá el número de recibo o de movimiento: es lo que después permite auditarlo.

Quitar marca

El botón "↶ Quitar marca" aparece en las filas "Conciliado a mano" (tooltip: "Quitar la marca: vuelve a revisión para resolverlo con Conciliar. No toca nada en Plenario."). Pide confirmación —"Quitar la marca de conciliado a mano · El movimiento de $ X vuelve a revisión, para resolverlo con “Conciliar”. No toca nada en Plenario. Si el cobro ya se hizo por el BO, no lo vuelvas a cobrar desde acá."— con el botón rojo "Quitar marca". Requiere Conciliacion.Revertir.

El movimiento vuelve a revisión —no a la cola automática: el motor no lo cobra solo— y se ve como "Sin identificar" o "Identificado sin cobrar". La intención que se había dado por cumplida vuelve a Abierta (salvo que otra imputación viva la reclame). Queda en Reportes como "Se quitó la marca de conciliado a mano", con la referencia anterior. Mensaje: "Se quitó la marca. El movimiento volvió a revisión: resolvelo con “Conciliar”."

Crear intención desde Conciliación

Para un pago que ya entró y no tiene intención: el cliente transfirió sin que el cajero la armara, o transfirió alguien cuyo CUIT no permite saber a quién le paga. La intención es lo que hace que el cobro quede bien registrado: dice a qué cliente, créditos y cuotas va la plata.

El botón "Crear intención" aparece en los cuatro estados resolubles si el usuario tiene Intenciones.Crear (tooltip: "Crear la intención de este pago (la pantalla de intenciones, en un modal, buscando por el apellido del que transfirió). Al generarla, el Conciliador cobra este movimiento con esa intención."). Abre un modal grande, "Crear intención · $ X · {quien}", con la misma pantalla de Caja adentro, sin menú:

• La búsqueda viene precargada con la primera palabra del nombre del ordenante tal como lo informa el banco (si tiene 3 letras o más). Los bancos suelen mandar "APELLIDO NOMBRE", así que normalmente es el apellido; si no, cambiala y apretá "Buscar".
• El pagador viene precargado con el ordenante del movimiento: CUIT, nombre y, si el CUIT es de persona física, el documento.
• Arriba se lee el cartel "Intención para un pago que ya entró: $ X · fecha · {ordenante} (CUIT …)." con la recomendación "Si el cliente ya pagó por el BO, no generes la intención: en Conciliación usá “Marcar conciliado”."
• El botón final dice "Generar intención y cobrar".

Al generarla, la Caja crea la intención y le pide al Conciliador que procese ese movimiento. El Conciliador encuentra la intención por sus reglas de siempre (CVU, código o CUIT del pagador) y la cobra. El modal se cierra solo y aparece "Intención generada" (verde) o "Intención generada, sin cobrar" (amarillo) con el resultado del Conciliador; al apretar "Listo" se recarga la grilla.

Importante: si el usuario tiene Intenciones.Crear pero no Conciliacion.Conciliar, la intención se crea pero no se cobra: "Intención generada, pero NO se cobró: {motivo} Que la concilie alguien con ese permiso."

Importante: no cambies el CUIT del pagador que viene precargado salvo que sepas lo que hacés. Es el CUIT de quien transfirió: si se cambia por otro y el pago no entró a un CVU, el Conciliador puede no encontrar la intención y el pago queda sin cobrar.

Importante: el modal no se cierra con Escape ni clickeando afuera. Cerrarlo con la ✕ antes de generar no hace nada. Si la generación falla (falta un dato, intención duplicada), el error queda dentro del modal y se puede corregir. Evitá el botón "Limpiar" de la búsqueda dentro del modal: pierde el vínculo con el movimiento; si hace falta empezar de nuevo, cerrá y volvé a abrir.

Deshacer un cobro o una acreditación

"↶ Deshacer" (en "Cobrado en Plenario" y "Acreditado en cuenta corriente"; tooltip "Ya está conciliado: no se descarta. Deshacerlo es revertir y, si corresponde, devolver la plata.") abre dos diálogos distintos. Requiere Conciliacion.Revertir.

• Cuenta corriente → "Deshacer la acreditacion", con el tilde fijo "Revertir la acreditacion en Plenario — Genera el contraasiento y los movimientos inversos. El saldo a favor del cliente vuelve a cero." y el tilde opcional "Marcar para devolver la plata al pagador". Botón "Revertir".
• Cobro de cuotas → "Desconciliar el cobro", con el aviso "Las cuotas cobradas se revierten desde el BO. Es el unico que controla que no queden cuotas salteadas." y "Si alguna cuota sigue cobrada en Plenario, esto se cancela y te lo avisa. Cancela el cobro en el BO y volve aca." Mismo tilde opcional. Botón "Desconciliar".

Resultados: "Acreditación revertida. El movimiento volvió a la cola de conciliación.", "Acreditación revertida y movimiento marcado para devolución por $ X.", "Desconciliado. El movimiento volvió a la cola de conciliación." o "Desconciliado y marcado para devolución por $ X."

Importante: desconciliar se cancela entero si alguna cuota sigue cobrada: "Operación cancelada: la(s) cuota(s) N del crédito M siguen COBRADAS en Plenario…". Lo mismo si un cobro sigue vigente aunque la cuota figure impaga, o si el cobro no tiene registradas las cuotas que tocó. Primero se revierte en el BO, después se desconcilia acá. Si no hay respuesta: "No se pudo confirmar si se deshizo. Revisa en Plenario antes de volver a intentarlo."

Revertir la imputación (↶)

El "↶" chico (tooltip "Deshacer la imputación") aparece en las filas Descartado y en las de cuenta corriente sin constancia real (Sin deuda · por acreditar, o una acreditación simulada). Pide confirmación —"Revertir la imputación · Se borra la asociación al crédito y el movimiento vuelve a quedar pendiente de procesar."— y borra la imputación local: el movimiento vuelve a Pendiente de procesar y, si había una intención Matcheada, vuelve a Abierta. Requiere Conciliacion.Revertir.

Es la única forma de reactivar un movimiento descartado con "✕ No es un pago de cartera". Si ya hay un recibo real, se niega: "No se puede revertir desde acá: Plenario ya registró el cobro con el recibo {n}. La reversa se hace por el procedimiento del BO."

Descartar y excluir

El botón rojo "✕" de la fila abre "Excluir este movimiento" —"Sale de la conciliación y el Conciliador deja de verlo. No se borra: queda en Exclusiones y se puede reactivar."— con "Motivo (opcional)" (ejemplo: "Comisión del banco, impuesto…") y un tilde apagado por defecto: "Además, crear una regla para omitir automáticamente los que vengan iguales". Si se tilda, aparecen "Texto a excluir" (sugerido a partir del movimiento, sacando números y fechas), dónde buscarlo (Concepto, Nombre del ordenante o cualquiera de los dos) y la advertencia sobre los textos cortos. Requiere Conciliacion.Descartar.

El movimiento queda excluido: desaparece de Conciliación y aparece en Excluidos. Mensaje: "Movimiento excluido de la conciliación." y, si se creó una regla, "La regla omitió además N movimiento(s) pendiente(s)."

El descarte en lote se hace tildando filas: aparece la barra "N movimientos marcados." con "Desmarcar" y "Descartar los marcados", que pide un motivo opcional y aclara "No se crea ninguna regla." Resultado: "N movimiento(s) descartado(s). Quedan en Exclusiones y se pueden reactivar."

Importante: el descarte en lote nunca crea reglas. Una regla que diga solo "VAR" atrapa todas las transferencias de BIND, que manda "VAR" como concepto en el listado: la conciliación quedaría apagada entera. Si hace falta una regla, se crea con el ✕ de a uno o desde Excluidos.

Importante: no se excluye lo que ya está resuelto: "No se puede excluir: ya tiene recibo de Plenario ({n}). Para deshacerlo hay que revertirlo y devolver la plata desde Devoluciones.", "No se puede excluir: está conciliado a mano (se saldó fuera de CashIN)…" o "Ese movimiento ya estaba excluido."

Armar una intención de pago (la Caja)

Se entra desde Intenciones → "+ Nueva intención" (o desde "Crear intención" en Conciliación). Son tres pasos.

Paso 1 — buscar al titular

El hint aclara el universo: "Solo aparecen clientes con deuda: crédito otorgado o liquidado, sin anular ni cancelar, con cuotas impagas. Se combinan los campos que completes." La grilla muestra "{N} cliente(s) con deuda" con "Cliente", "Domicilio", "CUIT", "Documento", "Créditos", "Cuotas", "Deuda", "Vto más viejo" (en rojo si ya venció) y el botón "Ver deuda". Si la búsqueda devuelve un solo cliente, se abre su deuda directo. Arriba a la izquierda hay un solo "volver": "← Volver a la búsqueda" o "← Volver a intenciones".

Paso 2 — elegir créditos y cuotas

La cabecera del titular dice "Id Cliente N · CUIT … · N crédito(s) · deuda total $ X". Cada crédito es un panel —"Crédito #N", "Solicitud N · N cuota(s) impaga(s) · adeuda $ X"— con sus cuotas, el badge "VENCIDA" o "A VENCER" y un contador que pasa de "Sin cuotas seleccionadas" a "N cuota(s) · $ X". El hint explica la regla: "Plenario cobra siempre de la cuota más vieja a la más nueva: al tildar una, se tildan todas las anteriores." Abajo, "Total del lote: $ X", "en 1 transferencia" o "en 1 transferencia, repartida entre N créditos".

Paso 3 — el pagador y la ficha

A la izquierda, "Transferir a": la cuenta recaudadora, el CBU y "Copiar CBU" (si hay más de una cuenta habilitada, un selector por banco). A la derecha, "Qué se va a pagar", con una línea por crédito y el total. Después, "Datos de quien va a transferir":

Cierra "Generar intención", que queda inactivo hasta tildar al menos una cuota: "Se genera una sola intención por el total, con un único código: el pagador hace una transferencia y el sistema la reparte entre los créditos tildados."

Al generar, el servidor relee la deuda en Plenario y valida: al menos una cuota; CUIT del pagador de 11 dígitos; nombre del pagador; que cada crédito sea del cliente y tenga cuotas impagas; que las cuotas de cada crédito sean contiguas desde la más vieja; y que haya una cuenta habilitada para recaudar. Se crea una intención con un código de 5 dígitos (el siguiente libre entre las vivas) y su detalle por crédito, y se abre sola la ficha.

Importante: el titular y el pagador pueden ser personas distintas, y ése es justamente el caso que resuelve la intención. Cuando entre la transferencia, el motor la reconoce por el CUIT del pagador.

Importante: si el mismo pagador ya tiene una intención Abierta o Matcheada por el mismo importe total, el sistema frena: "Ese pagador ya tiene una intención abierta por el mismo importe ($X). Si entra una transferencia no se puede saber a cuál corresponde: cancelá la anterior o esperá a que se acredite."

Importante: si el pagador ya existía en CashIN, se actualizan su nombre, documento, teléfono y mail con lo último cargado.

La Caja abierta desde Conciliación

Cuando la Caja se abre desde "Crear intención", trae el movimiento: precarga el pagador, muestra el cartel del pago que ya entró y cambia el botón a "Generar intención y cobrar" (ver "Crear intención desde Conciliación"). Si el movimiento no es una transferencia entrante, lo avisa y genera la intención sin cobrar nada; si ya está resuelto (cobrado, acreditado, conciliado a mano, en devolución, devuelto o descartado), avisa "El movimiento de $ X del dd/MM HH:mm ya está resuelto en Conciliación: no hace falta una intención para él." y no lo toca. Si la Caja se abrió en una pestaña aparte en vez del modal, al generar vuelve a Conciliación filtrada por la fecha del movimiento y el CUIT del ordenante, con el resultado en un cartel.

La ficha que se le dicta al pagador

El botón "Ver datos" reabre la ficha —el mismo modal que salta solo al crearla—, titulada "Intención de pago" o "Intención de pago · N créditos". Muestra:

• El CBU con "Copiar CBU", el banco, la cuenta y el titular.
• El importe a transferir con "Copiar importe" (en formato argentino, por ejemplo 499.900,00).
• El concepto (el código) con "Copiar código".
• El estado y el vencimiento, y la tabla de créditos con la aclaración "Se aplica a estos créditos. No son pagos separados."

Si la intención sigue viva, al pie hay "Enviar por WhatsApp" (o "Enviar por WhatsApp a {tel}" si se cargó teléfono) y "Copiar el mensaje". El mensaje dice: "Hola {pagador}, para pagar transferí a: CBU … / {banco} / Cuenta … / Importe: $ X / Concepto: {código} / Es UNA sola transferencia por el total." y, con varios créditos, el detalle por crédito.

Importante: es una sola transferencia por el total. Las líneas del detalle no llevan código ni botón de copiar a propósito: cuando cada línea mostraba su código, el cajero le dictaba varios al pagador y el pagador hacía varias transferencias.

Cancelar y eliminar intenciones

"Cancelar" solo aparece sobre las Abiertas ("Cancelar la intención {código} · Deja de esperar la transferencia de {pagador} por $ X."): la saca del circuito y el motor deja de considerarla. Una Matcheada no se cancela. "Eliminar" solo aparece sobre las Canceladas (o Expiradas) y borra de verdad ("Se borra de la base y no se puede deshacer."); está bloqueado si hay un movimiento imputado contra esa intención. Los dos requieren Intenciones.Eliminar. Sin Intenciones.Crear, el botón "+ Nueva intención" se ve inactivo con el motivo y la ayuda sobre reciclar el pool del WCF.

El vencimiento de la intención

Al crear la intención se graba "Vence" = alta + 2 horas, y se muestra en la grilla y en la ficha. Pero hoy ningún proceso la pasa a Expirada, y el motor tampoco mira el vencimiento: busca entre todas las Abiertas y Matcheadas.

Importante: en la práctica, una intención queda Abierta hasta que se cobra, se cancela o se concilia a mano, y puede reclamar una transferencia que entre días después. Sigue contando en "Intenciones abiertas" del Dashboard y el filtro "Expirada" no devuelve nada. Si una intención ya no corresponde, cancelala.

Reglas de exclusión y reactivar

En Excluidos, la tarjeta "🚫 Reglas de exclusión" explica para qué son: "Movimientos que no son cobranza — comisiones, impuestos, acreditaciones de otro circuito. Si el texto aparece en el campo elegido, el movimiento se omite: no se borra, queda acá y el Conciliador deja de verlo."

Al crearla ("Crear regla") se aplica enseguida: "Regla creada. Omitió N movimiento(s) que ya estaban pendientes." La tabla de reglas muestra "Texto", "Busca en", "Descripción", "Aplicó a" (cuántos atrapó; clicable), "Estado" (Activa/Desactivada), "Activar"/"Desactivar" y el "✕" para borrarla; con el tilde se borran varias juntas ("Eliminar las marcadas"). "Aplicar a lo pendiente" corre todas las reglas activas sobre lo que está sin procesar. Las reglas también se aplican solas después de cada barrido del Recolector.

Importante: borrar o desactivar una regla no devuelve nada al circuito. "Los movimientos que ya había excluido siguen excluidos: se pueden reactivar uno por uno desde el listado de abajo."

Importante: en una instalación nueva, CashIN siembra 8 reglas de fábrica sobre el concepto: Comisión, Mantenimiento, Impuesto, Percepción, Retención, IVA, Sellado y Débito automático. Ojo con "IVA": atrapa cualquier concepto que tenga esas tres letras seguidas (por ejemplo "ACTIVA" o "Rivadavia"). Revisá su columna "Aplicó a".

El listado de excluidos muestra el "Por qué" de cada uno y permite "Reactivar" por fila ("Vuelve a la conciliación como pendiente de procesar y el Conciliador lo va a analizar en su próxima corrida.") o "Reactivar los marcados". El tilde de la cabecera marca solo lo que está a la vista: con varias páginas, se reactiva página por página. Los débitos también están en Excluidos ("Débito: no es una transferencia entrante, no es cobranza."), porque el Recolector los guarda excluidos de entrada.

Devoluciones

La pantalla Devoluciones (fuera del menú, en /Devoluciones) junta todo lo que puede terminar en una devolución y las ya hechas: "La verificación contra Plenario se hace al accionar: cada botón comprueba en ese momento qué hay realmente en el ERP antes de tocar nada." Arriba, tarjetas clicables por situación: "Sin aplicar", "Acreditación en cta. cte.", "Cobro de cuotas", "En devolución" y "Devuelta". Columnas: "Fecha", "Banco", "Importe", "Pagador", "Aplicación", "Situación" y "Acciones".

Todas requieren Devoluciones.Devolver. Devolver se bloquea si la acreditación sigue viva en Plenario o si el movimiento está conciliado a mano.

Importante: la devolución se confirma a mano. La transferencia de vuelta la ejecuta Tesorería por su circuito; cuando salió, se confirma con "✓ Confirmar devolución". Existe una confirmación automática contra el débito del extracto, pero hoy no se dispara sola (ver Notas para soporte).

Puesta en marcha: qué se configura y dónde

El orden recomendado para una instalación nueva: (1) dar de alta el banco y la cuenta en el BO de Plenario (Archivos → Bancos, Tesorería); (2) declarar los bancos en CashIN:BancosActivos; (3) configurar el ambiente y el certificado en /Cuentas y elegir la "Cuenta que recauda"; (4) configurar la aplicación de cobranza en /Configuracion con el cobro real apagado; (5) probar en Homologación con el simulador de envíos; (6) recién después prender el cobro real.

Bancos activos de la instalación

Qué bancos opera una instalación no se elige en pantalla: lo decide el parámetro CashIN:BancosActivos del appsettings.json del servidor. Acepta nombres (BIND —también "Industrial"—, Comafi, Comercio, MercadoPago) o códigos (322, 299, 432, 3), como lista o separados por coma. Si el parámetro no está, opera solo BIND.

Un banco que no está en la lista: no aparece en el menú; su pantalla responde "no encontrada" (también a los botones: "No se hizo nada: este banco no está activo en esta instalación (…)."); el Recolector deja sus cuentas afuera del barrido sin registrarlo como error (salvo que todas las cuentas activas sean de bancos inactivos: entonces el barrido queda en Error con "Las cuentas activas son de bancos que esta instalación no usa (parámetro CashIN:BancosActivos): no hay nada que pollear."); y tampoco atiende el webhook ni el alta de CVU.

Las cuatro pantallas de banco (BIND y CVU, Comafi, Banco de Comercio y Mercado Pago) muestran arriba de todo un interruptor de solo lectura: verde "Activo" o gris "Inactivo", con el aviso "Se define en CashIN:BancosActivos del appsettings del servidor". No se cambia desde la pantalla y no toca la base. Si el parámetro trae valores que no se reconocen, lo avisa: "⚠ El parámetro trae valores que no se reconocieron y se ignoraron: …. Los válidos son BIND, Comafi, Comercio y MercadoPago (o 322, 299, 432 y 3)."

Importante: el parámetro se lee al arrancar la aplicación. Para que tome un cambio hay que reciclar el pool de IIS de CashIN.

BIND y CVU: la conexión con el banco

La pantalla BIND y CVU (/Cuentas, título "Conexión con el banco") se arma de arriba hacia abajo: el estado en esta instalación; la tarjeta del banco BIND (con "· BCRA 322", el badge "Operativo" o "No operativo" y el ambiente en uso; si no es operativo, un cartel amarillo con el motivo); la tarjeta "🔔 Aviso del banco (webhook)"; el "🧪 Simulador de envíos"; y "CVU por cliente". En Producción, el simulador y la sección de CVU no se dibujan.

Los bancos se dan de alta en el BO: "Los bancos se dan de alta en el BO de Plenario (Archivos → Bancos) y se activan para CashIN acá abajo. Una vez activo el banco aparecen sus cuentas —las mismas que usa Tesorería— y elegís cuál recauda. No se carga ninguna cuenta acá: el CBU sale de Plenario." Si no hay ningún banco BIND cargado: "Sin bancos configurables".

Los errores salen en el modal "El banco no lo tomó" con el botón "Entendido"; los éxitos, como aviso flotante que se va solo. Sin Banco.Administrar no se entra a esta pantalla (ni a Comafi ni a Banco de Comercio): se va a "No tenés permiso para entrar acá".

1 · Qué ambiente configurás

Un combo con Sandbox (pruebas), Homologación y Producción (banco real); al que está en uso se le agrega "— en uso". Cambiarlo recarga la pantalla con los datos guardados de ese ambiente: se ve un solo ambiente por vez ("Cada ambiente guarda sus propias URLs, credenciales y certificado. Solo uno puede estar en uso.").

Importante: guardar es activar. El botón "Guardar {ambiente}" guarda los datos y, al final, deja ese ambiente en uso ("Al guardar, {ambiente} queda en uso."). Al guardar Producción sale siempre la confirmación "Pasar a producción": "El banco va a operar contra el banco real: el Recolector empieza a leer movimientos de verdad y el Imputador a cobrarlos."

El estado "Sin ambiente en uso" (el banco no opera por CashIN) no se elige desde el combo: solo pegando el JSON con "AmbienteActivo": "Ninguno".

2 · Con qué API habla y dónde

Importante: los rótulos de este campo están desactualizados. La opción "Sandbox / OBP" es la API WEB de BIND —la de sandbox, homologación y producción con certificado— y es la que lee las transferencias recibidas (TRANSFER y TRANSFER-CVU) en homologación y producción. Además, el alta de CVU, el webhook y el simulador de envíos solo funcionan con "Sandbox / OBP": con "PSP", el alta de CVU responde "El banco activo no es BIND: el alta de CVU es de su billetera.", registrar el webhook responde "El webhook es de BIND: con el simulador o con otro banco no hay nada que registrar.", el receptor del aviso deja "Ninguna cuenta activa está operativa contra BIND." y el simulador falla contra el banco. "PSP" es otro producto de BIND (OAuth2, sin certificado). Ver Setup de BIND.

3 · Credenciales

El badge "No operativo" y su motivo salen de validar el ambiente en uso: falta la URL de la API, falta el Bank Id, con OAuth2 falta el Client Id, el Client Secret o la URL del login, con JWT hay usuario sin URL del login, el certificado está sin su clave privada (o al revés), o el banco está inactivo en Plenario.

4 · La cuenta en el banco

La cuenta y el CBU son por ambiente y mandan: el Recolector, el webhook y el alta de CVU consultan la cuenta del ambiente en uso, y guardan cada movimiento contra la cuenta del ERP que tenga ese CBU.

La "Cuenta que recauda" es el interruptor del canal: al guardar deja habilitada solo la elegida y apaga las demás del mismo banco. Elegir "ninguna" apaga el banco para CashIN. Para habilitar una cuenta se exige que tenga CBU en Plenario ("Esa cuenta no tiene CBU cargado en Plenario: no se le puede dictar al pagador.") y que el banco esté operativo. De esa cuenta salen además el CBU que el cajero le dicta al pagador, el alta de CVU, el simulador y la insignia de ambiente.

Importante: hay tres formas de apagar BIND, de menor a mayor alcance: elegir "ninguna" en "Cuenta que recauda" (lo normal); poner el ambiente en "Ninguno" por JSON; o sacarlo de CashIN:BancosActivos (apaga el banco en toda la instalación y esconde la pantalla).

Importante: si se lee un solo tipo de transferencia, el banco contesta "no hay transferencias" para el otro y la mitad de la recaudación no se ve. Por eso no es configurable.

5 · Pruebas y ajustes avanzados

"Cuenta de origen para pruebas" hace de pagador del simulador ("Hace de pagador al transferir de prueba. Sin esto, el simulador de abajo queda apagado."). No se dibuja en Producción, y en Producción no se usa nunca. En el plegable "Ajustes avanzados" está el "User-Agent" con que CashIN se identifica ante el banco.

6 · Certificado (mTLS)

El certificado se guarda en la base, dentro de la configuración del banco y por ambiente, no como archivo en el servidor. La clave privada nunca vuelve al navegador. Si hay uno cargado se ve su ficha: "Titular", "Emisor", "Vence" (con "Vencido", "Vence en N días" si faltan menos de 30, o "De prueba") y "Huella".

Opciones de "¿Qué hacemos con el certificado?":

Antes de guardar se valida que haya certificado y clave, que sean pareja, que abran, que no esté vencido y que un certificado de prueba no se cargue en Producción. Éxito: "{ambiente}: certificado de {titular} guardado, vence el dd/MM/aaaa." Si falla, se guardan igual los datos de conexión y la "Cuenta que recauda", pero el ambiente no pasa a estar en uso: "Los datos de conexión se guardaron, pero el certificado no: …" (por ejemplo, "No se pudo abrir el PFX. Suele ser la contraseña", "El PFX no trae la clave privada", "El certificado y la clave privada no son pareja").

Importante: si en el servidor el certificado da "The system cannot find the file specified", el pool de IIS no tiene el perfil de usuario cargado. La aplicación lo reintenta sola con el almacén de la máquina; si igual falla, el mensaje lo dice: activá "Load User Profile" en la configuración avanzada del pool y reciclalo.

Guardar

Un solo botón, "Guardar {ambiente}", hace en este orden: (1) guarda los datos de conexión de ese ambiente (los otros no se tocan; contraseña y Client Secret vacíos se conservan); (2) fija la "Cuenta que recauda"; (3) aplica lo elegido para el certificado; (4) deja el ambiente en uso. El mensaje junta las partes, por ejemplo "Homologación: configuración guardada. El banco queda operativo para CashIN. · {certificado} · Ambiente en uso: Homologación.", o "…configuración guardada, pero todavía no es usable: {motivo}".

Importante: todo campo de este formulario que no viaje al guardar se guarda vacío. Solo la contraseña y el Client Secret toleran quedar vacíos sin borrarse.

Consultar cuentas en el banco

"🔍 Consultar cuentas en el banco" le pregunta al banco qué cuentas tiene, con las credenciales guardadas del ambiente que se está viendo (sirve para probar Producción antes de activarla). Es solo lectura y evita tipear a ciegas el id de cuenta y el CBU. Muestra "Cuentas en el banco" con "Id de cuenta", "CBU", "Titular", "Tipo", "Estado" y un botón "Usar" que copia id y CBU al formulario ("Usar completa los dos campos del ambiente; despues hay que guardar."). Si el banco no permite listar cuentas, consulta el CBU cargado, que confirma titular y estado pero no devuelve el id de cuenta. Corta a los 20 segundos.

Ver o pegar el JSON

El plegable "Ver o pegar el JSON (lo mismo que se edita en el BO)" muestra la configuración completa —todos los ambientes— con los secretos tapados con el marcador <<guardado - no se muestra>> ("Si dejás el marcador tal cual, se conserva lo que ya estaba guardado."). "Guardar el JSON tal cual" la reemplaza. Es la misma columna que se edita en el BO (Archivos → Bancos → Api Bank Config) y la única vía para poner el ambiente en "Ninguno".

El aviso del banco (webhook)

Con el webhook, BIND avisa apenas entra la plata en vez de esperar a la próxima corrida del Recolector: "Se registra por API: no hay que entrar al portal del banco."

Importante: el aviso no acredita. "El mensaje de BIND no viene firmado, así que CashIN no imputa con lo que dice: lo usa para ir a buscar ese movimiento al extracto en el momento. El Recolector sigue corriendo igual, como red de seguridad por si un aviso se pierde."

El receptor es propio de CashIN (/webhook/bind). La dirección pública, el código y el secreto no se escriben en pantalla: salen de la sección CashIN:Webhook del appsettings.json del servidor (ver Información técnica). La tarjeta "🔔 Aviso del banco (webhook)" muestra:

Se registra siempre contra el ambiente en uso. En Sandbox avisa "⚠ El Sandbox no soporta webhooks: acá el registro va a fallar."

"Guardar y registrar en BIND" —"Guardar es registrar: se guarda acá y se manda al banco en el mismo paso. Si el banco lo rechaza, lo cargado no se pierde y el cartel dice por qué."— no recarga la página. Éxito: "Guardado y registrado en BIND. Webhook registrado y habilitado: el banco validó la URL y le respondió 200." Error: "Los datos quedaron guardados, pero el banco NO tomó el webhook: {motivo}"; el motivo dice quién rechazó (IIS, un firewall, un proxy) y qué respondió. Si el banco no contesta en 20 segundos, se puede volver a guardar.

Si lo cargado no coincide con lo que tiene BIND, un cartel lo explica: "Lo cargado acá NO es lo que tiene registrado BIND: {diferencia} — Manda lo del banco. Para que coincidan, guardá: eso vuelve a registrarlo con estos datos."

En el bloque "Webhooks registrados en el banco — ver, probar y quitar":

• "Ver los registrados": lo que tiene BIND, con "Código", "Estado", "Eventos" y "URL", y por fila "Editar" y "Quitar" (sirve para bajar webhooks viejos con otro código). Si la consulta falla, no dice que está vacío: "Esto NO quiere decir que el banco no tenga nada registrado: quiere decir que no se pudo preguntar."
• "Probar el aviso": le pide a BIND que dispare un mensaje de prueba contra la URL registrada ("El banco disparó el mensaje de prueba."). Del lado de CashIN queda registrado el aviso y la búsqueda de un movimiento de prueba que el banco no tiene: es lo esperable.
• "Quitar del banco": lo da de baja en BIND; la configuración queda guardada para volver a registrarlo. Para dejar de recibir avisos, normalmente alcanza con apagar "Operar con webhook" y volver a guardar.

Importante: con el motor apagado, el aviso se registra pero no va a buscar el movimiento: lo trae el Recolector cuando corra. El aviso tampoco dispara el Conciliador: el movimiento queda pendiente hasta la próxima corrida o hasta "Procesar pendientes".

CVU por cliente

La sección "CVU por cliente · {banco} · {ambiente} · cuenta {cuenta recaudadora}" lista los CVU dados de alta en el ambiente en uso, con el badge "N dados de alta". Filtros: "CUIT", "Cliente, CVU o id", "Estado" (Todos · Activos · Dados de baja) y "Tipo" (Todos · Clientes de Plenario · Pagadores externos). Columnas: "CVU", "Tipo" (badge Cliente o Externo), "Id cliente", "Titular", "CUIT", "Estado" (Activo/Baja), "Alta", y "✎ Editar" / "Dar de baja" en los activos.

Importante: "Estos CVU sirven para recibir, no para enviar: BIND tiene cerrado el envío desde un CVU." Y la sección no existe en Producción: los CVU se dan de alta en Homologación o Sandbox.

Un CVU es de un ambiente

Cada CVU guarda en qué ambiente estaba en uso la aplicación cuando se dio de alta. Un CVU existe en un solo ambiente del banco: el de Sandbox no existe en Homologación. La grilla, la marca "Ya tiene" del alta, el control de CVU repetidos y los destinos del simulador muestran solo los del ambiente en uso (los CVU anteriores a esta distinción valen para todos). El Conciliador, en cambio, identifica por cualquier CVU activo, sin mirar el ambiente.

Alta para un cliente de Plenario

"+ Nuevo CVU" abre el modal "Nuevo CVU": "Se le pide el CVU a la billetera de {banco} sobre la cuenta {cuenta} ({ambiente}). El client_id que se manda es el id de cliente del ERP: BIND deriva el CVU de ese número, así que queda trazable y pedirlo dos veces devuelve el mismo." Se busca por "CUIT", "Documento", "Nombre" o "Id de cliente", tenga deuda o no (los que deben aparecen primero). Por fila, "Crear CVU" o el badge "Ya tiene".

• El cliente necesita CUIT de 11 dígitos ("BIND lo exige para el alta").
• El vínculo se guarda recién después de que el banco confirmó, y el CVU se anota también en la libreta de CBU del cliente en Plenario (descripción "CVU CashIN"), para que todo Plenario lo vea.
• Éxito: "CVU dado de alta. {cliente} → {CVU}" o "CVU reactivado (ya existía para ese cliente). {cliente} → {CVU}"
• Si el banco no contesta a tiempo: "⚠️ NO se sabe si la operación se hizo: verificá en el banco antes de reintentar."

Alta para un pagador externo

Dentro del mismo modal, "➕ No está en Plenario — dar de alta un pagador externo" es para el familiar o el empleador que paga la intención de otro: su CVU dice quién pagó; qué deuda se cancela lo dice la intención que lo nombra como pagador. Campos: "CUIT" (11 dígitos, "Lo exige BIND, no nosotros."), "Nombre y apellido" ("Como va a figurar en el banco. Sin comas.") y "Documento" (opcional). Al completar el CUIT busca la persona en Plenario y, si no está, en el padrón de AFIP. Botón "Crear CVU externo".

Importante: si ese CUIT ya es cliente de Plenario con CVU en este ambiente, se rechaza a propósito: "dos CVU para el mismo CUIT hacen ambigua la identificación, que es justo lo que el CVU viene a resolver." Y si entra plata al CVU de un externo sin intención que lo nombre, el movimiento queda en revisión.

Editar y dar de baja

"✎ Editar" permite cambiar solo el nombre del titular (5 a 41 caracteres, letras, números, punto y espacio; las comas se sacan solas) y el alias: "El número de CVU y el CUIT no se editan — es límite de BIND. Para cambiar de titular hay que dar de baja y volver a dar de alta." Primero cambia en el banco y, solo si el banco acepta, en CashIN. El alias aparece siempre vacío porque el banco no deja leerlo.

"Dar de baja" confirma "Se da de baja en el banco. La plata que llegue a ese CVU después no se va a poder identificar. Se puede volver a dar de alta: BIND devuelve el mismo número." Si el banco acepta, el CVU queda en Baja y se borra de la libreta de CBU del cliente.

Importante: el CVU es identidad. BIND lo deriva del id que se le manda: dar de baja no libera el número, y pedirlo de nuevo para el mismo cliente devuelve el mismo CVU.

Simulador de envíos

El "🧪 Simulador de envíos" ordena una transferencia de verdad contra el banco, desde la "Cuenta de origen para pruebas" hacia la cuenta recaudadora (o a un CVU), para ejercitar la conciliación sin esperar a que pague alguien. No escribe ningún movimiento: "Sale por el banco. Acá no se registra ningún movimiento: lo trae el Recolector, y después lo imputa el Conciliador."

"Mandar el movimiento" abre "Ordenando la transferencia…" ("BIND tarda unos 13 segundos en contestar."). Si el banco la acepta, espera hasta 20 intentos a que aparezca acreditada y termina en "Acreditada" ("…La trae el Recolector; si no querés esperar, corrélo a mano.") o "Todavía no acreditó". Mientras hay un envío vivo no deja mandar otro.

Importante: no la mandes dos veces. Si el banco tarda o se corta, el aviso lo dice explícitamente: "⚠️ No la mandes de nuevo." Verificá en Movimientos antes de reintentar.

Importante: en Homologación hay que elegir un CVU. La cuenta de origen de las pruebas es la misma recaudadora y el banco no deja transferir una cuenta a sí misma: "Elegí un CVU en «A nombre de quién entra»… No se mandó nada."

Importante: el Sandbox de BIND es una maqueta. Acepta la orden y la da por completada del lado de las enviadas, pero su listado de recibidas devuelve registros fijos y no lo que se mandó: el contador termina en "Todavía no acreditó" y el Recolector no trae lo simulado. Para probar el circuito completo, usá Homologación.

Importante: en Producción no se simula. El simulador no se dibuja y, si la página se abrió antes del cambio, el servidor vuelve a mirar el ambiente y se niega: "El banco está en PRODUCCIÓN: no se simulan movimientos." Si no puede leer la configuración, también se niega. La razón está en la propia pantalla: "Simular un ingreso contra una cuenta real sería fabricar plata que nunca entró, y el motor la cobraría contra cuotas de verdad."

Simulación del banco (modo maqueta)

Solo existe si la instalación no está en modo de bancos reales (parámetro CashIN:Modo distinto de "Real") y no está en Producción. La tarjeta "🧪 Simulación del banco" reemplaza al banco por un generador que inventa transferencias rotando escenarios (pago exacto de una intención, pago parcial, cliente sin intención, CUIT desconocido, sin concepto, un duplicado y un débito). Controles: "Generar movimientos automáticamente", "Un movimiento cada (segundos)", "Guardar", "Generar uno ahora" y "⟲ Resetear simulación", que borra solo lo simulado (ids con prefijo SIM-) y devuelve a Abierta las intenciones que habían matcheado.

Importante: con la simulación prendida, la plata es falsa pero el cobro que genera no: si el cobro real está habilitado, un movimiento inventado cobra cuotas de verdad. Mirá contra qué base está apuntando la instalación antes de prenderlo.

Comafi

Banco Comafi (BCRA 299) es un canal aparte de solo recolección: no transfiere, no devuelve, no da de alta CVU y no tiene ambientes, certificado, webhook ni simulador. Pantalla /Comafi ("Conexión con Banco Comafi"), visible si el banco está en CashIN:BancosActivos. Si no existe en Plenario: "Comafi no está dado de alta en Plenario… El alta del banco se hace en el back office (Archivos → Bancos)."

Botón "Guardar configuración"; si no hay nada cargado, "Cargar el sandbox de pruebas" completa los datos de demostración del banco. El guardado se mezcla con lo que ya tiene el BO: no borra claves que CashIN no conoce. Mensaje: "Configuración guardada. Comafi queda operativo para recolectar."

Qué recolecta: el extracto completo de la cuenta —acreditaciones por CBU y por CVU, débitos, comisiones, impuestos—; lo que no es cobranza entra excluido o lo sacan las reglas. Trae el CUIT y el nombre del ordenante y la descripción. Comafi no tiene CVU dedicado: la identificación sale del CUIT del ordenante y del código en el concepto.

Importante: el sandbox de Comafi también es una maqueta: contesta siempre los mismos movimientos e ignora fechas y paginado.

Banco de Comercio

Banco de Comercio (BCRA 432) es otro canal de solo recolección, con la misma estructura de pantalla que Comafi (/Comercio, "Conexión con Banco de Comercio"). Campos: "Entorno", "URL de la API — Producción" ("⚠ Producción requiere VPN además del certificado. Homologación no."), "URL de la API — Homologación", "Client Id", "Client Secret", "Secret Key (firma X-SIGNATURE)" ("🚨 No es el Client Secret. Con esta clave se firma cada consulta; sin ella el banco las rechaza aunque el token sea válido."), y las rutas del certificado de cliente y su clave con la passphrase. Si no hay configuración, "Cargar las URL del banco" deja solo las direcciones (el banco no publica credenciales de prueba).

Recolecta el extracto de la cuenta por su CBU, CVU o alias, con el nombre y el CUIT del ordenante.

Importante: la integración con Banco de Comercio está escrita contra la documentación del banco y todavía no se verificó contra el banco real. Probala en homologación antes de usarla.

Mercado Pago

Mercado Pago es el cuarto medio de solo recolección. No es un banco sino un proveedor de pagos (PSP): CashIN lo identifica con el código 3, que es el de Mercado Pago dentro de sus CVU (0000003…). Pantalla /MercadoPago ("Conexión con Mercado Pago"), visible si está en CashIN:BancosActivos ("MercadoPago" o 3).

Qué recolecta: los pagos aprobados de la cuenta de Mercado Pago, por el importe bruto (lo que pagó el cliente). El neto, con la comisión de Mercado Pago descontada, queda anotado en el concepto. Trae el nombre del pagador y su CUIT cuando Mercado Pago lo informa.

Importante: los pagos de los links de cuota que genera Plenario (los que llevan la referencia IdSolicitud,IdCrédito,IdCuota…) no se recolectan: esos los cobra el WCF por su cuenta, y traerlos a CashIN cobraría la cuota dos veces. Cada barrido avisa cuántos salteó.

Importante: la integración está escrita contra la documentación de Mercado Pago y todavía no se verificó contra una cuenta real. En la primera corrida hay que confirmar que las transferencias recibidas al CVU aparezcan entre los pagos.

Alta en una instalación: el banco "MERCADO PAGO" (código 3) lo da de alta el despliegue de la base (o Scripts/2026-10-14_MercadoPago_Banco.sql); después se carga la cuenta en Tesorería con su CVU, se elige en /MercadoPago y se agrega "MercadoPago" en CashIN:BancosActivos.

Configuración del motor y del cobro

La pantalla Configuración (/Configuracion, permiso Configuracion.Administrar) tiene los bloques "⚙ Agentes del motor", "💰 Cobro real en Plenario" (con "💸 Aplicación de cobranza" adentro), "Integraciones", "Relay del cajero" y "🔌 Conexión con el banco" (un resumen —"Hoy opera con {banco} en {ambiente}."— y el botón "Configurar el banco", que lleva a /Cuentas). Los mensajes salen como banda arriba de todo.

Agentes del motor

"Cada cuánto corre cada agente por su cuenta. El cambio aplica en el próximo ciclo, sin reiniciar."

Cada fila tiene su propio "Guardar" ("{Recolector|Conciliador}: cada N min."). En una instalación nueva los dos agentes nacen cada 60 minutos y agendados a futuro: no corren apenas arranca la aplicación.

Cobro real: los dos interruptores

Para que CashIN escriba en Plenario tienen que estar prendidas dos cosas:

Badges: la cabecera dice "COBRANDO" o "SOLO CONCILIA"; la aplicación, "ACTIVA" o "SIN COBRAR". El switch y la aplicación se guardan con el mismo botón, "Guardar cobro y aplicación". Si "Estado" es Activo y falta algo, no se guarda ("No se puede activar con estos datos: …") y el cobro real no se prende. Apagar siempre se puede.

Importante: la pantalla dice que "Habilitar el cobro real" es "el único interruptor que decide si se mueve plata", pero no es así: el "Estado" de la aplicación también tiene que estar activo. Con cualquiera de los dos apagado, el motor identifica y deja todo listo, pero no cobra.

La configuración se guarda como JSON en el parámetro de Plenario Web.CashIN.Cobros.Configuracion (la pantalla lo muestra con un botón "Copiar"). CashIN se la manda completa en cada pedido de cobro.

Modo y medio

Importante: cobrar cuotas de varios créditos en un solo recibo exige el modo "Con recibo". En "Movimientos directos" un cliente con varios créditos sin cuotas elegidas no se cobra solo: va a revisión.

Cómo se imputa

Importante: con "Las que eligió el cliente", la pantalla advierte: "⚠️ Cuando un pago cubre varios créditos, el ERP usa de la selección solo el número de cuota y no a qué crédito pertenece: puede imputar esa misma cuota de otro crédito del cliente." CashIN se protege de eso mientras el WCF del servidor no tenga publicado el cobro por crédito (ver Información técnica).

URL de la API y usuario de servicio

Importante: sin usuario de servicio, el motor no cobra nunca por agenda. El agente que corre solo no tiene un operador logueado detrás: necesita ese usuario para hablar con Plenario. Sin él, los movimientos quedan identificados sin cobrar y el motivo lo dice: "Tu sesión de Plenario venció y no hay un usuario de servicio configurado para renovarla (Configuración → Aplicación de cobranza)…". Conviene un usuario dedicado, con los permisos mínimos.

Notificaciones por mail

Cómo funciona: el mail lo arma CashIN y lo envía Plenario con su SMTP, después de que Plenario contestó; si el mail falla, la conciliación no se frena.

• Si el cobro sale bien y "Avisar al cliente" está en Sí: un solo mail, "Notificación de cobro de cuotas", a la vez al mail del cliente en Plenario, al del pagador (si su ficha tiene mail) y a las casillas internas, sin repetidos. Dice cuánto se recibió, a qué cuotas se aplicó (saldada o pago parcial) y cuánto quedó a favor en cuenta corriente. Sin la plantilla en la carpeta, va un texto plano armado por CashIN.
• Si el cobro falla y hay casillas internas: un mail solo a ellas, "CashIN — falló un cobro ({id})", con el movimiento, el cliente y el motivo.

Variables de la plantilla: @Id_Solicitud, @NroCuotas, @Importe, @Pagador, @CuitPagador, @CbuPagador, @ImporteRecibido, @ImporteAplicado, @ImporteCtaCte, @NroComprobante, @DetalleCuotas y @Fecha.

Importante: el mail solo lo manda el Conciliador (la agenda, "Procesar pendientes", "Conciliar" con intención y "Generar intención y cobrar"). No se manda desde "Aplicar cobro" ni "Acreditar" del modal de Conciliación, ni cuando el motor acredita a un cliente sin deuda.

Importante: hoy @Importe se reemplaza antes que @ImporteRecibido, @ImporteAplicado e @ImporteCtaCte, y esas tres salen mal en el mail. Hasta que se corrija, en las plantillas usá solo @Importe.

Importante: un cobro que falla por un motivo que se reintenta (cobro real apagado, sin usuario de servicio) manda el aviso interno en cada corrida. Con casillas internas cargadas, prendé el cobro real recién cuando la configuración esté completa.

Integraciones y Relay

La tarjeta "Integraciones" resume el modo de cada integración: "Banco (BIND, COMAFI, COMERCIO)" REAL ("Los movimientos vienen del banco real.") o SIMULADO, y "Plenario" REAL ("Clientes, créditos y cuotas salen por SQL de la base del ERP. El cobro depende del interruptor de arriba."). La tarjeta "Relay del cajero" es informativa; dice "4 consultas cada 30 segundos", pero el Relay real hace 6 consultas cada 20 segundos durante 2 minutos.

Caso 1 — Una intención que paga un tercero

Situación: Laura Gómez tiene un crédito con dos cuotas impagas por $ 120.000 en total. No va a pagar ella: lo va a hacer Martín Ruiz, su yerno, desde su propia cuenta.

1. Armá la intención. Entrá a Intenciones → + Nueva intención, buscá "GOMEZ" y apretá "Ver deuda". Tildá la cuota más nueva de las dos: el sistema tilda sola la anterior. El total queda en $ 120.000.
2. Cargá al pagador. En "Datos de quien va a transferir" poné el documento de Martín y apretá "Buscar": el sistema trae el CUIT y el nombre del padrón de AFIP. Agregá su teléfono y apretá "Generar intención".
3. Dictale la ficha. Se abre sola con el CBU, el importe y el código de concepto, por ejemplo 48215. Con "Enviar por WhatsApp" le llega todo armado. La intención queda Abierta.
4. Martín transfiere. Una sola transferencia por $ 120.000, con "48215" en la referencia.
5. Entra la plata. Si el webhook está activo, BIND avisa y CashIN trae el movimiento en el momento; si no, lo trae el Recolector en su próxima corrida. Si hay apuro, usá "▶ Iniciar Relay" en Movimientos.
6. El Conciliador la identifica. No hay CVU dedicado y Martín no es cliente, pero el código 48215 de la referencia apunta a la intención. (Aunque Martín no hubiera puesto el código, la intención es la única con su CUIT como pagador: la habría encontrado igual.) La intención pasa a Matcheada y se le pide el cobro a Plenario.
7. Queda el recibo. En Conciliación, el movimiento muestra a la izquierda a Martín y a la derecha "Cobrado · recibo …" en verde, con la titular Laura Gómez y las dos cuotas. En Intenciones, la intención figura Imputada. Si el aviso por mail está activo, reciben el detalle del cobro Laura (con el mail de su ficha en Plenario) y Martín, si tiene mail cargado como pagador.

Importante: si hubiera dos intenciones vivas con el CUIT de Martín y el pago no trajera el código, el motor no adivina: manda el movimiento a revisión con el motivo "2 intenciones abiertas para el CUIT …", y lo resuelve una persona.

Caso 2 — Un pago que entró sin intención

Situación: entran $ 60.000 ordenados por Carlos Pérez (el banco lo informa como "PEREZ CARLOS"). Carlos no es cliente: pagó la cuota de su madre, Ana Pérez, sin avisarle al cajero. En Conciliación el movimiento figura "Sin identificar".

1. Apretá "Crear intención" en la fila. Se abre el modal "Crear intención · $ 60.000 · PEREZ CARLOS" con la Caja adentro, ya buscando "PEREZ", y con Carlos precargado como pagador.
2. Elegí a la titular. En la lista, buscá a Ana Pérez y apretá "Ver deuda". Tildá la cuota que corresponde.
3. Apretá "Generar intención y cobrar". CashIN crea la intención y le pide al Conciliador que procese ese movimiento: lo encuentra por el CUIT de Carlos como pagador y le pide el cobro a Plenario.
4. Listo. El modal se cierra solo y aparece "Intención generada" con el número de recibo. Al apretar "Listo", la fila figura "Cobrado en Plenario".

Importante: si Ana ya hubiera pagado esa cuota por el BO, no se arma la intención: se usa el Caso 3.

Caso 3 — Un pago que ya se cobró por el BO

Situación: entran $ 45.000. Antes de que el Conciliador lo procesara, el cajero ya le había cobrado esa cuota al cliente por el BO y emitió el recibo.

1. Apretá "Marcar conciliado" en la fila.
2. Completá la constancia. En "Tipo de constancia" elegí "Recibo", cargá el número del recibo del BO y, en "Observaciones", "Lo cobró el cajero por el BO".
3. Confirmá. El movimiento pasa a "Conciliado a mano": sale de la cola, el motor no lo vuelve a mirar y queda en Reportes con tu usuario. CashIN no cobró ni escribió nada en Plenario.

Importante: si te equivocaste de movimiento, "↶ Quitar marca" lo devuelve a revisión, sin tocar Plenario.

• Mirá "De quién es", no "Quién la ordenó". El ordenante puede ser un tercero o la misma cuenta del banco emisor; lo que identifica al cliente es el CVU destino.
• Armá la intención antes de que transfieran. Es lo que hace que el cobro se registre solo y bien: dice a qué cliente, créditos y cuotas va la plata.
• Pedile al pagador que ponga el código en la referencia. No es obligatorio, pero es la señal que desempata cuando hay más de una intención.
• Si un cliente paga seguido por un tercero, dale un CVU dedicado. Es la señal más fuerte y convierte una conciliación manual en una automática.
• Cancelá las intenciones que ya no corresponden. Ninguna vence sola: una intención vieja sigue esperando y puede reclamar un pago que no es suyo.
• Si ya se cobró por el BO, marcalo como conciliado; no lo vuelvas a cobrar. Y cargá el número de recibo o de movimiento: es lo que después permite auditarlo.
• Antes de apretar "Conciliar" en un pago con intención, fijate que la intención sea la correcta. El clic cobra.
• Con el cobro real apagado, todo queda en "Identificado sin cobrar". No es un error: es el modo de prueba, y la pantalla lo avisa con un cartel.
• Si algo se cortó por timeout, no reintentes a ciegas. Verificá en el BO de Plenario si el cobro entró: el sistema deja el movimiento en revisión justamente para no cobrar dos veces.
• No mandes dos veces la misma transferencia de prueba. Si el simulador dice que sigue en segundo plano, esperá y mirá Movimientos.
• Probá en Homologación, no en Sandbox. El Sandbox de BIND no devuelve lo que se le manda.
• Revisá Excluidos de vez en cuando. Una regla demasiado corta puede estar comiéndose pagos buenos; la columna "Aplicó a" muestra cuántos atrapó cada una.
• Antes de tocar permisos, leé lo que dice la pantalla. Si un botón aparece inactivo con un motivo, ese texto dice si el ERP contestó que no o si no se le pudo preguntar.
• No copies credenciales, certificados ni contraseñas en tickets, chats o capturas. La configuración del banco vive en la base y se edita desde la pantalla.

Todos llevan el prefijo WebAppCashin. y se asignan desde la seguridad de Plenario, al grupo que corresponda.

No llevan permiso: el Dashboard, el login, la página "sin permiso", el chequeo de salud (/salud) y el receptor del webhook (/webhook/bind).

Importante: sin Banco.Administrar no se entra a las pantallas de banco: se va a "No tenés permiso para entrar acá" con el permiso que falta. No hay un modo "solo lectura".

Cómo funcionan, y las tres trampas

Los permisos los decide Plenario, no CashIN: se consultan al WCF con el token de la sesión, así que el navegador no puede mentir sobre quién es. CashIN recuerda cada respuesta 3 minutos por usuario; un "no se pudo preguntar" (ERP caído, sesión vencida) no se recuerda y se vuelve a consultar.

1. El permiso se crea solo la primera vez que alguien lo consulta… pero solo si el usuario no es administrador. Con un usuario admin el ERP contesta que sí y no crea el objeto: los permisos no aparecen en la seguridad y no hay forma de asignarlos. Para eso están los scripts de alta.
2. Nace sin ningún grupo, así que responde "no" para todos —incluido quien lo acaba de crear— hasta que alguien lo asigne desde el BO.
3. Asignarlo no alcanza. El ERP se guarda en memoria la respuesta "este usuario no tiene tal permiso" y la da por buena 30 días, sin volver a mirar la base. Hay que reciclar el pool de IIS del WCF de Plenario. Y después, hasta 3 minutos más por el caché propio de CashIN.

Importante: esconder el link del menú no alcanza como candado. Cada pantalla revalida el permiso en el servidor antes de cualquier acción, y cada acción que escribe lo vuelve a verificar: una pestaña abierta desde antes de que te lo quitaran sigue mostrando los botones, pero al apretarlos responde "No se hizo nada: …" (en la Caja, "No se generó la intención: …"). En las pantallas que usan formularios clásicos (Excluidos y el "↶" chico de Conciliación) esa respuesta se ve como texto crudo en el navegador.

Basada en el análisis del formulario real de la v14

Esta sección se relevó leyendo el código vigente de PlenarioCashIN (rama principal, octubre de 2026). Expone todo lo técnico que usa el manual para que soporte y desarrollo puedan mapear cada comportamiento.

Formularios y pantallas

Managers y clases de negocio

Procesos en segundo plano

Al arrancar, antes que todo, SeedData crea si faltan: la fila del motor apagada, los dos agentes cada 60 minutos y agendados a futuro, y —solo si la tabla de reglas está vacía— las 8 reglas de exclusión de fábrica. La aplicación no crea ni migra tablas.

El agendador, al arrancar, suelta todas las marcas de "corriendo". Después, en bucle: con el motor apagado espera 15 s y vuelve a mirar; toma los agentes activos que no estén corriendo o cuya marca tenga más de 30 minutos; calcula la próxima corrida como última + intervalo (si nunca corrió, ya); dispara los vencidos en paralelo y duerme hasta el próximo hito. El Relay, "Ejecutar ahora", "Conciliar/Procesar pendientes", "Conciliar" de una fila y el webhook no son servicios de fondo: corren a pedido.

Stored Procedures y funciones

CashIN no tiene stored procedures propios. Usa sp_getapplock / sp_releaseapplock de SQL Server para el candado de corrida del Conciliador (recurso CashIN.Conciliador, modo exclusivo, dueño la sesión, sin espera). Lo demás del ERP lo lee por SQL directo (PlenarioSqlClient) y lo escribe por el WCF: los cobros, recibos, asientos y movimientos de cuenta corriente nunca se escriben por SQL.

Endpoints que usa CashIN

"URL de cobros" es la de la configuración de cobranza; vacía, PlenarioApi:BaseUrl. Todas las respuestas del WCF vienen envueltas en {statusCode, statusMessage, content} y manda el statusCode de adentro: un HTTP 200 con 401 adentro es una sesión vencida. Las rutas de los bancos (listado y detalle de transferencias, CVU, webhooks) están documentadas en la carpeta docs/ del repositorio de CashIN.

Tablas de base de datos

Las tablas de CashIN viven en la misma base del ERP (ConnectionStrings:CashIN). Son 17 propias, con prefijo Bancos_Transferencias_ salvo la primera:

Del ERP, CashIN lee: Bancos (incluido el JSON ApiBankSetup), DefinicionCuentasBancarias (la fuente del CBU: CashIN no lo replica), Especies_Cajas, Inversores, Parametros, Clientes_CBU, y por SQL directo Clientes, Prestamos_Creditos, Prestamos_Creditos_Detalle, Prestamos_Creditos_Detalle_Cobros, Recibos y Clientes_CtaCte.

CashIN escribe en el ERP solo tres cosas: su fila de Parametros (Web.CashIN.Cobros.Configuracion), Clientes_CBU al dar de alta o de baja un CVU, y Bancos.ApiBankSetup al guardar la configuración de BIND, Comafi, Banco de Comercio o Mercado Pago (la misma columna que edita el BO). El parámetro Web.MisCreditos.MercadoPago.Config del ERP solo se lee.

Importante: el esquema es 100% del proyecto de base de datos (SSDT). La aplicación no crea ni migra tablas, ni siquiera al arrancar. Esta versión necesita la columna Ambiente de Bancos_Transferencias_Cvu: contra una base sin esa columna falla la pantalla BIND y CVU entera (arma el simulador y la grilla de CVU al cargar) y fallan el alta, la edición y la baja de CVU. Los índices únicos también vienen del deploy de la base.

Los estados por dentro

Los candados contra el doble cobro

• El índice único del extracto: el mismo movimiento del banco no entra dos veces. Además, antes de insertar se verifica que no exista otro movimiento del mismo banco con el mismo id de COELSA, sin importar la fuente: BIND devuelve un id distinto para el mismo movimiento según se lo pida por el listado o por el detalle.
• El índice único por IdMovimiento en la imputación: una transferencia produce una sola imputación.
• El campo del recibo (IdReciboPlenario): el candado real no es el estado sino tener constancia. Lo que tiene constancia (un recibo, "MANUAL", "SIN LIQUIDAR", "incierto", "parcial", "ya procesado") no se reintenta nunca.
• El ExternalTrackId como clave de idempotencia contra Plenario: {Id_Banco}:{Fuente}:{id}, donde el id es el de COELSA si existe (si no, el del banco). Si supera 50 caracteres, el id se reemplaza por un hash estable. Una reaplicación después de revertir usa uno nuevo con el sufijo :r{fecha-hora}. Plenario marca el track id recién al terminar el cobro.
• El candado de corrida: un solo Conciliador a la vez (sp_getapplock), en todos los caminos que concilian —agenda, "Ejecutar ahora", "Conciliar/Procesar pendientes", "Reprocesar", "Conciliar" con intención y "Generar intención y cobrar"—. Vive en la base, así que vale entre varias instancias de la web. El Recolector no lo toma.
• La marca EnEjecucion de cada agente, que vence a los 30 minutos.
• Los dos interruptores del cobro (CobroRealHabilitado y la configuración activa), apagados por defecto: la red por si la aplicación quedó apuntando a una base productiva.

Importante: revertir un cobro no libera el ExternalTrackId. Plenario lo sigue reteniendo; el sistema genera uno nuevo cuando corresponde reaplicar.

El Recolector por dentro

Qué cuentas recorre. Todas las de Bancos_Transferencias_Cuenta activas, salvo las de bancos que no están en CashIN:BancosActivos (se descartan sin error). Primero BIND, después los demás por código BCRA. Si dos filas del mismo banco apuntan a la misma cuenta del banco, se consulta una sola vez. Cada cuenta se aísla: si una falla, el motivo queda en el mensaje del barrido y las demás siguen. Si fallan todas, el barrido termina en Error. Al final aplica las reglas de exclusión sobre todo lo que está en Nuevo y escribe una fila en la bitácora: "{nuevos} nuevos, {dup} ya cargados (de {total} del período)", más " · ⚠️ sin leer: …" o " · ⚠️ N cuenta(s) sin pollear: …" si algo falló.

La cuenta la decide el ambiente. Para BIND, si el ambiente en uso tiene cargada la cuenta recaudadora, se consulta esa; si además tiene el CBU, ese CBU decide qué es entrante y el movimiento se guarda contra la cuenta del ERP que tenga ese CBU. Para Comafi y Comercio se usa el identificador de la fila y el CBU de DefinicionCuentasBancarias.

Qué le pide a BIND. Desde ayer hasta mañana, por headers (obp_from_date / obp_to_date; BIND los ignora en la URL). Lee los tipos del ambiente sin repetir: en Sandbox TRANSFER; en Homologación y Producción TRANSFER-CVU y TRANSFER. Por cada tipo, las recibidas (la cobranza) y las enviadas (opcional; si fallan se ignoran). Pagina de a 200 (obp_limit; BIND acepta de 50 a 200) con obp_offset = número de página, no de registro, hasta 20 páginas por tipo y sentido. El código TX019 ("no hay transferencias") es un cero legítimo. Si un tipo falla, los demás se siguen leyendo. Solo se recolectan transferencias COMPLETED. Con la API PSP, en cambio, pagina de a 50 hasta 40 páginas y no pide el detalle.

Qué dato sale de dónde. Entra (crédito) si el CBU de destino es el propio o el banco la marca como recibida; si no, es débito. El CUIT del que manda es el primer valor con forma de CUIT entre la contraparte, el origen y el concepto. El CVU destino —el que identifica al cliente— sale del crédito de origen. El concepto del listado llega casi siempre como "VAR". El id de COELSA es el de 22 caracteres alfanuméricos.

El detalle. Solo para los movimientos nuevos se pide el detalle al banco por el mismo tipo con que vino. De ahí salen la referencia real que escribió el pagador (donde viaja el código de la intención), el CBU de origen, el CUIT si faltaba y la fecha con hora. Si el detalle falla, el movimiento se guarda igual con lo del listado.

Las fechas. De las cuatro fechas que manda BIND (operación, fin, inicio y fecha de negocio, en ese orden) se descartan las anteriores al 2000 y las futuras (más de 15 minutos adelante); se convierten a hora local; gana la primera que traiga hora. Al guardar, para todos los bancos: una fecha futura se reemplaza por la hora en que CashIN lo detectó; una de hoy a medianoche, también; una de otro día a medianoche queda así. Las cuatro fechas crudas quedan en el JSON del movimiento (FechasDelBanco) solo para consulta. La hora de ingreso a CashIN es FechaImport, y las pantallas filtran por fecha del banco o de ingreso.

Débitos. Entran al extracto con el importe en positivo y el sentido "Débito", pero nacen excluidos (Ignorado, con el motivo "Débito: no es una transferencia entrante, no es cobranza."). El Conciliador solo mira créditos que sean transferencias en estado Nuevo.

Pruebas desde la propia cuenta. Si una transferencia llega a un CVU propio desde la cuenta recaudadora (una prueba), el ordenante se reemplaza por el dueño del CVU y el concepto lleva la nota "[pagador tomado del CVU: la prueba salió de la cuenta recaudadora]".

Comafi. OAuth2 sin certificado; el token dura 300 s y al vencer el banco contesta 403 (se renueva y reintenta una vez; un 403 que persiste con token nuevo significa que el producto no está contratado). Una sola fuente por cuenta: el extracto (Movimientos, por defecto; de a 750 por página, hasta 30.000) o las transferencias CVU (Transfers); nunca las dos, porque la misma acreditación vendría con otro id y entraría dos veces. Rango: desde ayer hasta ahora. La clave anti-duplicado es su conciliation_id.

Banco de Comercio. Extracto por CBU, CVU o alias, de a 200 por página; mTLS, token de 3600 s y cada consulta firmada con X-SIGNATURE. Trae el nombre y el CUIT del ordenante, el CBU de destino y el id de COELSA; el importe viene positivo con el sentido aparte.

Mercado Pago. GET /v1/payments/search (ordenado y filtrado por fecha de aprobación, de a 100 por página), con Authorization: Bearer {Access Token}. Solo pagos approved; importe bruto (transaction_amount); fecha convertida a hora argentina; CUIT del pagador solo si viene con 11 dígitos. Saltea los external_reference con el formato de los links de Plenario. La clave anti-duplicado es el id del pago.

El aviso del banco por dentro

El receptor POST /webhook/bind/{secreto?} es anónimo. Al recibir: (1) deja una fila en la bitácora (WebhookBind, con el cuerpo crudo) y contesta 200 enseguida (BIND exige el 200 en 3 segundos); (2) si es el aviso de validación (endpoint.created) no busca nada; (3) si no, en segundo plano y solo con el motor encendido, toma los identificadores del aviso —data.id, data.net_id, data.transaction_ids, data.core_id, data.origin_id— y le pide al banco ese movimiento por su id, en cada cuenta activa de BIND y por cada tipo del ambiente. El alta pasa por el mismo paso que el Recolector: misma cuenta, misma fuente, mismo anti-duplicado (incluido el de COELSA), mismo detalle, mismas reglas. Deja una segunda fila (PollWebhook) con el resultado: "Movimiento X registrado por aviso del banco.", "El movimiento X ya estaba cargado: no se duplica.", "El banco no tiene el movimiento X (todavía, o no es de estas cuentas).", etc. No reintenta: si algo falla, lo trae el Recolector.

Seguridad: si CashIN:Webhook:Secreto tiene valor, el tramo final de la ruta tiene que coincidir (comparación en tiempo fijo; como segunda opción se compara con el secreto guardado en la configuración del banco); si no coincide o falta, responde 401 y lo registra como "Rechazado". Si no hay secreto, acepta cualquier aviso siempre que haya al menos una cuenta activa. El mensaje de BIND no viene firmado: lo que autentica es el secreto y la IP de origen.

El Conciliador por dentro

Las fases de una corrida, en orden:

1. Toma el candado de corrida (si está tomado, avisa y no hace nada).
2. Corrige desincronizados: movimientos en Nuevo que ya tienen imputación pasan a procesados.
3. Pone al día los "Recibo N SIN LIQUIDAR" que el BO ya liquidó (solo lectura en Plenario).
4. Fase 1: toma los créditos-transferencia en Nuevo y sin imputación, por fecha, y los procesa de a uno, guardando cada uno por separado (un movimiento que falla no aborta los demás).
5. Registra contra qué cuotas quedó cada imputación de intención.
6. Fase 1-bis: re-resuelve las revisiones viejas de "varios créditos" que nadie tocó.
7. Fase 2: reintenta los cobros y acreditaciones identificados sin constancia del ERP.
8. Fase 3: confirma devoluciones contra débitos del extracto.

Importante: lo que en la Fase 1 queda "identificado sin cobrar" se vuelve a intentar en la Fase 2 de la misma corrida: dos intentos por corrida, y dos filas en Reportes si falla.

El paso de un movimiento. Crea la imputación en Pendiente con su ExternalTrackId y la guarda antes de cobrar; identifica (señales); si identificó, cobra o acredita; el movimiento pasa a ProcesadoCashIN. Si algo revienta, la imputación queda en revisión con "Error al imputar: {error}" y sigue con el siguiente.

Las señales, con su puntaje. CVU dedicado (+100; busca el CVU activo con cliente, sin mirar el ambiente) → CUIT del que envía (+70; solo si el CVU no dio cliente; primer cliente con ese CUIT, sin exigir deuda) → código de concepto (+100; número suelto de 5 dígitos; restringido al cliente ya conocido) → intención única del cliente (+60) → CUIT del pagador de la intención (+60; única intención viva con ese pagador). El puntaje se guarda, pero decide por reglas, no por suma. Las señales quedan en MatchSenalesJson. Si el que transfiere es él mismo cliente y ninguna intención lo nombra como pagador, la plata se le imputa a él.

Desenlaces sin intención, con el cliente conocido ("deuda" = crédito vigente, otorgado o liquidado, con alguna cuota sin fecha de cobro y saldo, que incluye punitorios e IVA de punitorios no cobrados):

El cobro repartido (intención de varios créditos). Una sola llamada a Plenario (Id_Credito = 0, el mismo track id) y un solo recibo para todos los créditos:

• Si entró exacto lo esperado: se mandan las cuotas que eligió el cajero, repartiendo el monto de cada crédito entre sus cuotas.
• Si entró distinto: se relee la deuda y se arma el pedido por orden (PedidoPorOrden): créditos en el orden de la intención y, dentro de cada uno, las cuotas que siguen impagas por su saldo real, hasta agotar la plata; si sobra, el excedente se suma a la última cuota y Plenario lo manda a cuenta corriente. Se antepone una nota: "Entraron $ X y la intención esperaba $ Y: se aplicó en orden hasta donde alcanzó…" o "…se aplicaron las N y los $ Z restantes quedan a favor del cliente en cuenta corriente."
• Guarda de cuotas "mellizas": mientras PlenarioApi:ErpFiltraPorCredito sea false, si otro crédito del cliente tiene impaga una cuota con el mismo número que una pedida, no se cobra y va a revisión (el WCF sin el cambio identifica las cuotas solo por número y la plata podría caer ahí).
• Tras cobrar, el detalle por crédito se arma con lo que Plenario dice que imputó (si no lo devolvió, con lo esperado y la nota "Detalle estimado: el ERP no devolvió las cuotas.") y la intención pasa a Imputada.

Qué constancia queda. Si Plenario cobró: el número de recibo (en modo directo, "Asiento N"), estado Imputada (o AcreditadaCtaCte si terminó acreditando), las cuotas con su id de cobro y la intención Imputada. Si falló, queda sin recibo y se reintenta en la próxima corrida, salvo estos casos, que en los cobros dejan una constancia para que no se reintente nunca solo:

La acreditación del motor (cliente sin deuda) va por el mismo CobrosCashIN, con el cliente, Id_Credito = 0 y sin cuotas. Exige cliente, los dos interruptores y la opción "Acreditar a favor en cuenta corriente". La constancia es el comprobante, "Mov. cta. cte. N" o "Asiento N", y se guardan los ids de asiento y de movimiento (los necesita la reversión). Si la acreditación falla, el motor no deja ninguna constancia —ni siquiera ante un timeout o un "ya procesado"—: queda sin recibo y la Fase 2 la reintenta (ver Notas para soporte).

Fase 2 — reintentos. Toma las imputaciones sin constancia en Conciliada o Pendiente que estén identificadas (con crédito, con intención de varios créditos, cuenta corriente con cliente, o varios créditos sin intención). Quedan afuera las revisiones, las descartadas, las cobradas, las acreditadas, las conciliadas a mano, las devoluciones y todo lo que tenga constancia. Un error en una fila deja "Error al reintentar el cobro: …" y sigue.

Fase 3 — devoluciones. Para cada imputación en devolución busca un débito del mismo banco, mismo CUIT, mismo importe, posterior a la marca y en estado Nuevo; si lo encuentra, la pasa a Devuelta. Ver Notas para soporte: hoy no encuentra nada, porque los débitos nacen excluidos.

Conciliar un solo movimiento (ConciliarMovimientoAsync). Es el Conciliador con su mismo procedimiento, sobre un movimiento. Lo usan el botón "Conciliar" cuando el pago tiene intención y "Generar intención y cobrar" de la Caja. Toma el mismo candado; no toca lo que ya está resuelto; si había una imputación sin constancia la borra con sus cuotas y líneas, libera la intención y analiza de cero; cobra en Plenario y manda el mail igual que el agente.

Analizar sin cobrar (ProcesarUnoAsync). Cuando "Conciliar" abre el modal, antes corre el análisis sin cobrar: borra la imputación anterior sin constancia, crea una nueva en Pendiente con lo identificado y deja el movimiento en Nuevo. Ver Notas para soporte: si el operador cierra el modal sin aplicar, la Fase 2 puede cobrarlo sola.

El cobro en Plenario

Todo cobro y toda acreditación —del motor o manual— pasa por CobroService, que exige los dos interruptores: CobroRealHabilitado (fila del motor, se relee en cada cobro) y la configuración de cobranza con Activo = true. La configuración viaja entera en cada pedido (el WCF cachea sus parámetros). El pedido lleva el cliente, el crédito y la solicitud (o 0), el importe que entró, la fecha de la transferencia, el ExternalTrackId y el origen (cuenta recaudadora del ERP, número de transferencia y referencia de COELSA). Con "Las que eligió el cliente" viajan las cuotas elegidas siempre que hay intención (un crédito o varios) y en el manual de varios créditos; con la opción "cuotas siguientes", detrás de las elegidas viajan las siguientes de la deuda, ordenadas para que la cuota que queda parcial sea la última que procesa el ERP. Sin intención, en un solo crédito no viaja lista y Plenario cobra de la más vieja a la más nueva.

La llamada espera hasta PlenarioApi:TimeoutCobroSegundos (300 s por defecto; generoso a propósito, porque cortar no cancela nada del lado del ERP). Si se agota, el desenlace es incierto y no se reintenta: "Se dejó de esperar a la API después de {n} segundos. ⚠ Esto NO es una respuesta de Plenario: el cobro pudo haberse aplicado igual. Verificalo en el BO antes de reintentar." Si la respuesta es una página HTML (endpoint no publicado o URL equivocada): "…NO se aplicó nada."

Con qué usuario cobra el motor (SesionPlenario): primero el token del operador logueado, si sigue vivo; si no, el usuario de servicio de la configuración de cobranza, que se loguea y reutiliza el token 20 minutos. El agente por agenda, el webhook y los mails del motor no tienen operador detrás: sin usuario de servicio, el motor identifica pero no cobra. El login del usuario de servicio usa PlenarioApi:BaseUrl y el token se usa contra la URL de cobros: si son distintas, tienen que ser la misma instalación.

Cobro por crédito (PlenarioApi:ErpFiltraPorCredito). El WCF sin el cambio de "cobros por crédito" identifica las cuotas pedidas solo por número, sin mirar a qué crédito pertenecen. Mientras el parámetro esté en false, CashIN frena los cobros de varios créditos que podrían caer en cuotas "mellizas" y los manda a revisión. Se pone en true solo cuando el WCF de ese servidor tiene publicado el cambio: con true contra un WCF viejo podría cobrar cuotas que nadie eligió. El orden de despliegue y una consulta para saber si una intención tiene cuotas mellizas están en docs/erp-cobros-por-credito/.

La auditoría

Bancos_Transferencias_OperacionLog registra cada operación sobre la plata, con diez tipos (Cobro, Acreditacion, Devolucion, Reaplicacion, ReversionCtaCte, DevolucionConfirmada, ReversionImputacion, Descarte, ConciliacionManual y QuitaMarcaManual) y tres resultados (Ok = "Aplicada", Error = "Con error", Bloqueada). En la misma tabla quedan también WebhookRegistrar y WebhookEliminar (con resultado "OK"/"ERROR") y SimulacionEnvio del simulador de envíos. Columnas: fecha, tipo, resultado, usuario ("motor" para el Conciliador, "recolector" para la confirmación automática de devoluciones), movimiento, imputación, cliente, crédito, importe, ExternalTrackId, referencia de Plenario (recibo, asiento, movimiento de cuenta corriente o la referencia manual), ids de asiento y de movimiento de cuenta corriente (los usa la reversión) y detalle (hasta 1000 caracteres). Nunca corta una operación: si no puede escribir, lo deja en el log de la aplicación.

La bitácora del banco

Bancos_Transferencias_Log no tiene una fila por llamada al banco: tiene una por barrido y dos por aviso. Es la que muestra el Dashboard en "Últimas consultas al banco".

El registro y la baja del webhook no van acá: quedan en la auditoría (OperacionLog) como WebhookRegistrar / WebhookEliminar.

Parámetros del appsettings.json

Las credenciales de los bancos no van en este archivo: viven en Bancos.ApiBankSetup del ERP. El archivo se arma para cada instalación y no se copia de otra sin revisarlo.

Importante: casi todo se lee una sola vez al arrancar. Después de editar el appsettings.json hay que reciclar el pool de IIS (y, si cambió algo del webhook, volver a "Guardar y registrar en BIND").

Importante: ConnectionStrings:CashIN y PlenarioApi:BaseUrl van de a par: CashIN concilia por la base y cobra por la API. Si apuntan a instalaciones distintas, el recibo se escribe en una base y CashIN lo busca en otra.

Instalación en IIS

• .NET 10, publicado dependiente del framework: el servidor necesita el ASP.NET Core 10 Hosting Bundle.
• La base tiene que tener el esquema de CashIN desplegado desde el proyecto de base de datos (incluida la columna Ambiente de los CVU).
• Pool de aplicación: Start Mode = AlwaysRunning, Idle Time-out = 0 y sin reciclado periódico. IIS apaga por inactividad midiendo peticiones, no trabajo: con el valor por defecto (20 minutos) mata el proceso y con él a los dos agentes. El latido a /salud ayuda, pero no reemplaza esta configuración: después de un reciclado o un reinicio, la aplicación no vuelve sola hasta la primera petición.
• Load User Profile = True en el pool, para que el certificado de BIND pueda guardar su clave privada.
• Webhook: la ruta /webhook/bind tiene que ser alcanzable desde internet por HTTPS; el firewall debería aceptar solo la IP de origen de BIND. Después de cargar CashIN:Webhook, reciclar el pool, ir a BIND y CVU con el ambiente correcto en uso (no Sandbox) y apretar "Guardar y registrar en BIND"; comprobar con "Ver los registrados" y "Probar el aviso", y mirar las filas WebhookBind y PollWebhook de la bitácora.
• La sesión de CashIN es la cookie CashIN.Sesion, de 8 horas, renovable con el uso.

Scripts y documentos para soporte

Permisos reales

Relación con otros módulos / manuales

Dónde mirar cuando algo no cierra

Notas para soporte

Comportamientos conocidos (relevados en octubre de 2026). Son límites del código vigente; conviene tenerlos presentes al atender un caso:

• Las intenciones no vencen. Se graba un vencimiento a 2 horas, pero ningún proceso las pasa a Expirada y el motor no mira la fecha. Una intención Abierta o Matcheada sigue pudiendo reclamar pagos nuevos. Hay que cancelarlas a mano.
• La confirmación automática de devoluciones no se dispara. La Fase 3 busca débitos en estado Nuevo, pero el Recolector guarda todos los débitos como excluidos. Se confirma a mano desde Devoluciones (o reactivando el débito desde Excluidos).
• Cerrar el modal de Conciliar sin aplicar no es neutro. El análisis previo deja una imputación Pendiente; si quedó identificada (con crédito, varios créditos o sin deuda), la próxima corrida del Conciliador la cobra o acredita sola.
• El mail de aviso solo sale del Conciliador: no desde "Aplicar cobro"/"Acreditar" del modal ni en la acreditación directa del motor. Y la plantilla rompe @ImporteRecibido, @ImporteAplicado e @ImporteCtaCte (se reemplaza antes @Importe).
• 🚨 La acreditación automática puede repetirse. Cuando el motor acredita en cuenta corriente a un cliente sin deuda y Plenario no contesta a tiempo (o dice que ya la procesó), el motor no deja constancia: la imputación queda sin recibo y la Fase 2 la reintenta —incluso en la misma corrida—. Si el primer intento sí se había aplicado, el cliente queda con el saldo a favor duplicado. Ante un timeout de acreditación, verificar en el BO la cuenta corriente del cliente.
• Los reintentos no tienen tope. Un cobro que falla por cobro real apagado, sin usuario de servicio o por un rechazo de negocio se reintenta en cada corrida (dos veces en la primera): suma filas "Con error" en Reportes y, si hay casillas internas, manda el aviso de error cada vez. Lo mismo la acreditación del motor con la configuración "No aplicar nada".
• Sobrante sin proveedor financiero. Según la documentación del cambio del WCF, si sobra plata y la configuración no tiene proveedor financiero, el ERP cobra las cuotas y después responde "Rechazado" por el sobrante.
• Cobro repartido: la rama de importe exacto no pasa por la guarda de cuotas mellizas; y con "La más vieja primero" la lista de cuotas no viaja y Plenario cobra de la más vieja a la más nueva de todos los créditos del cliente, aunque no estén en la intención.
• "Aplicar cobro" de un solo crédito, si falla, no deja constancia de "Recibo N SIN LIQUIDAR", "Ya procesado" ni de un cobro parcial (el Conciliador sí la deja): el movimiento vuelve a la cola y la Fase 2 lo reintenta, con riesgo de un segundo recibo colgado. Ante un error de "Aplicar cobro", revisar en el BO antes de que corra el Conciliador.
• "Procesar pendientes" (Conciliación) ante un corte de conexión dice "No se cobró ni se movió nada.", aunque la corrida pudo haber cobrado. "Conciliar pendientes" (Movimientos) lo advierte bien.
• API "Sandbox / OBP" vs "PSP": los rótulos de la pantalla están al revés de lo que hace el código (ver BIND y CVU, paso 2).
• Pantalla vs realidad: Configuración dice que "Habilitar el cobro real" es el único interruptor (son dos) y que el Relay hace 4 consultas cada 30 s (hace 6 cada 20 s); la Caja, sin cuenta habilitada, remite a "Administración → Cuentas" (hoy es "Configuración de banco → BIND y CVU"); Comafi muestra un hint sobre un interruptor "Activo" que ya no está, y Banco de Comercio menciona el script de Comafi.
• Banco de Comercio, "Ver o pegar el JSON": Secret Key, passphrase y clave privada tapadas se guardarían literalmente como el marcador. Al pegar el JSON, borrar esas claves o escribir el valor real.
• Con varios bancos recaudando, la insignia, la sección de CVU y el simulador miran la primera cuenta (la de menor id, no necesariamente BIND): si es de Comafi o Comercio, la insignia dice "Sin configurar", la sección de CVU dice "No se puede operar con CVU" ("la configuración de este banco (BCRA 299) no tiene el formato de BIND.") y el simulador toma esa cuenta como destino y falla al mandar. Si BIND no está en CashIN:BancosActivos, "Configurar el banco" y la insignia llevan a una página no encontrada.
• Comafi por extracto guarda como "CVU destino" el CBU de la cuenta: la señal "CVU dedicado" no funciona con esos movimientos.
• Webhook: el alta por aviso solo busca transferencias (TRANSFER/TRANSFER-CVU): un aviso de DEBIN no da de alta nada. Sin secreto, se acepta cualquier aviso y se atribuye al banco de la primera cuenta activa. El badge "NO COINCIDE CON BIND" puede aparecer sobre un registro correcto si el secreto del servidor y el guardado difieren, o si CashIN:Webhook:UrlPublica termina en "/" y no hay secreto (se registra con la barra y se compara sin ella).
• El Recolector no tiene candado de corrida: dos barridos simultáneos no duplican movimientos (índice único), pero el que pierde la carrera puede anotar esa cuenta como "sin pollear" en ese barrido. El segundo control, por id de COELSA, no tiene índice: un aviso del webhook y un barrido exactamente simultáneos podrían duplicar un movimiento.
• La señal "CUIT del pagador de la intención" no se limita al cliente del CVU: si el cliente del CVU no tiene intenciones vivas y quien transfiere es el pagador de una única intención de otro cliente, el pago se imputa a ese otro cliente.
• La regla de fábrica "IVA" atrapa conceptos como "ACTIVA" o "Rivadavia".
• La Caja no busca si solo se completa el Domicilio; y su botón "Limpiar", dentro del modal de "Crear intención", pierde el modo embebido y el movimiento.
• Movimientos no normaliza el CUIT del filtro (cargarlo sin guiones).
• Formularios clásicos sin permiso (Excluidos y el "↶" chico de Conciliación) muestran la respuesta del servidor como texto crudo.
• El cartel "Solo lectura" de las pantallas de banco no se ve nunca: sin Banco.Administrar no se entra.
• Bancos_Transferencias_Persona_Titular y Bancos_Transferencias_Autorizacion existen pero no se usan.

Para no equivocarse:

• Nunca se cobra por SQL directo: los cobros, recibos, asientos y movimientos de cuenta corriente los escribe el WCF.
• Un timeout no es una respuesta: el cobro pudo haberse aplicado. Verificar en el BO antes de reintentar.
• Antes de reintentar una devolución o una transferencia de prueba, verificarla por su id en el banco: el listado puede no mostrarla todavía.
• No copiar a manuales, tickets ni capturas credenciales, certificados, contraseñas de usuario de servicio, secretos del webhook ni cadenas de conexión.