Motor de Cobranzas Plenario Collections

Plenario Collections es el motor que organiza y ejecuta la cobranza automática de cuotas de préstamos. Lee la cartera de Plenario, determina qué cuotas son elegibles, aplica políticas de cobranza, arma una agenda de intentos, controla límites de presión y envía las operaciones al proveedor correspondiente. También observa los webhooks, concilia resultados y mantiene alertas, historial y auditoría.

El circuito de cobranzas soporta Mobbex y Pagos360. Incluye herramientas para administrar suscripciones Mobbex, adhesiones CBU, links de pago, respuestas de proveedores, políticas, scoring, franjas horarias, simulaciones y consultas de clientes, solicitudes y créditos.

La solución contiene además un submódulo de Pagos para transferencias salientes con políticas, aprobación, selección de cuenta origen, agenda e historial. Este submódulo debe considerarse separado del circuito de cobro de cuotas.

Importante: la disponibilidad real depende de la configuración, las credenciales y los proveedores habilitados en cada instalación. En el código relevado, Comafi tiene una implementación configurable cuyos endpoints deben confirmarse contra la documentación contractual; Comercio y MercadoPago permanecen implementados como proveedores stub. No deben habilitarse como productivos sin completar y validar sus integraciones.

1. Abrí la aplicación - ingresá a la URL de Plenario Collections definida para tu ambiente.
2. Iniciá sesión - usá tus credenciales de Plenario. La aplicación valida el usuario mediante la API de Plenario y crea o actualiza su registro local.
3. Usá el menú lateral - las funciones se agrupan en Dashboard, Cobros, Pagos, Consultas y Administración.

Las rutas principales son:

Estado general del motor

La pantalla Configuración muestra el estado del planificador y del ejecutor, sus últimas corridas y el último error. Desde allí se administran los parámetros operativos persistidos en Cob_Motor_Estado.

Políticas de cobranza

Una política define qué cartera toma, cómo calcula los importes y cuándo intenta cobrar. Las políticas se evalúan por Prioridad ascendente; si ninguna coincide, puede aplicarse la marcada como default.

La edición permite configurar:

• Datos generales: nombre, descripción, prioridad, estado, vigencia, versión y modo de consolidación.
• Segmentación: comercializadores, entidades, líneas, sucursales y rango de días vencidos.
• Exclusiones: fallecidos, prejudiciales, judiciales, bajas y clientes bloqueados.
• Programación: días fijos, días hábiles, frecuencia, franjas y feriados.
• Intentos: orden, tipo de cálculo, valor, importe mínimo/máximo y espera.
• Límites: máximos diarios, semanales y mensuales, horario y ejecución en fines de semana o feriados.
• Respuestas: acción automática frente a códigos del proveedor.
• Scoring: pesos para priorizar la cartera.

Importante: una política nueva entra en ramp-up durante los primeros 7 días y procesa el 20% superior por scoring, salvo que se desactive el control. Validá la política con Preview, Dry Run, Simulador y Asignaciones antes de habilitarla para toda la cartera.

Medios de cobro e integraciones

Usuarios y roles

El primer inicio de sesión crea al usuario local como Operador. Un Admin puede cambiar su rol o activación desde Usuarios. El cambio se refleja en el próximo inicio de sesión porque el rol se guarda en la cookie.

El Dashboard resume el estado operativo y permite detectar rápidamente si el motor está funcionando.

Los usuarios con política AdminOrSupervisor pueden:

• Encender o apagar el motor.
• Ejecutar el planificador manualmente.
• Ejecutar el ejecutor manualmente.
• Ejecutar el procesador de hooks.
• Destrabar el motor.
• Resetear la agenda, con confirmación reforzada cuando la operación es forzada.

Cómo funciona el ciclo automático

1. Planificación - a las 07:00, PlanificadorService verifica que el motor esté encendido y recorre la cartera elegible.
2. Asignación de política - PoliticaEngine evalúa filtros y prioridad; el scoring y el ramp-up determinan qué cuotas ingresan.
3. Agenda e intentos - crea o actualiza Cob_Agenda y genera Cob_Intento en estado Pendiente.
4. Control de presión - EjecutorService consulta límites, horarios, bloqueos y frecuencia antes de enviar.
5. Validación pre-cobro - relee la cuota. Si ya fue cobrada o no tiene saldo, cancela el intento sin llamar al proveedor; si el saldo bajó, ajusta el monto.
6. Cobro - resuelve IProcesadorPagos para Mobbex o Pagos360 y ejecuta la operación.
7. Resultado - aprueba, rechaza, reprograma, pausa, cancela o deriva a gestión manual según la respuesta.
8. Webhook y conciliación - observa notificaciones de Mobbex, procesa webhooks propios y ejecuta la conciliación diaria de Pagos360.
9. FIFO - al completar una cuota agenda la siguiente cuota exigible del mismo crédito, si corresponde.

Agenda de cobro

Muestra cada cuota asignada a una política, monto original, monto restante, estado, próxima ejecución e intentos relacionados. Se puede filtrar por estado, política, fechas de asignación, solicitud, crédito y documento.

Cartera

Permite consultar cuotas elegibles y exportarlas. Los filtros incluyen texto libre, comercializador, entidad, línea, días vencidos, saldo mínimo y exclusión de fallecidos o judiciales.

Historial

Concentra los intentos enviados y sus respuestas. Permite revisar transacciones, códigos, importes y acciones aplicadas. Para Mobbex incluye operaciones manuales de reintento, marcar pagada, suspender o activar suscripción y devolución, sujetas al rol operativo.

Consultas de clientes y créditos

La navegación es Cliente -> Solicitud -> Crédito. El detalle de crédito muestra:

• Total, cobrado, saldo y cantidad de cuotas impagas o vencidas.
• Datos de cada cuota.
• Hooks Mobbex aprobados imputados a cada cuota.
• Logs de ejecuciones Mobbex asociados a la solicitud.
• Estado de procesamiento observado sin modificar las tablas funcionales de Plenario.

Alertas, reportes y auditoría

• Alertas registra errores técnicos, rechazos relevantes, ajustes pre-cobro y situaciones que requieren revisión.
• Reportes ofrece indicadores por período.
• Auditoría permite filtrar por entidad, identificador, acción, usuario y fechas, y exportar resultados.

Submódulo Pagos

Administra transferencias salientes: pendientes de aprobación, agenda, intentos, políticas, proveedores y saldos. Incluye selección de cuenta origen y una base para aprobación dual.

Importante: no confundir Cobros con Pagos. Cobros intenta percibir cuotas de clientes; Pagos ordena transferencias salientes. La interfaz del submódulo Pagos está presente, pero la preparación productiva de cada proveedor debe verificarse por separado.

Importante: la tabla refleja la intención declarada en los atributos del código. En varias Razor Pages, el atributo [Authorize] está aplicado al método handler (OnPost...) y el compilador emite MVC1001: ese atributo no se aplica a handlers individuales. En esos casos, la protección efectiva puede quedar reducida a la política de la clase PageModel. Hasta corregirlo y probarlo, no se debe asumir que todos los permisos de acción de esta tabla están efectivamente forzados.

Crear y validar una política antes de automatizar cobranzas

1. Abrí Políticas - ingresá a Cobros -> Políticas y elegí Nueva política.
2. Definí el alcance - cargá nombre y prioridad; seleccioná comercializadores, entidades y líneas.
3. Protegé la cartera - activá las exclusiones de fallecidos, prejudiciales, judiciales, bajas y bloqueados que correspondan.
4. Definí los intentos - configurá importes o porcentajes, cantidad de intentos y días de espera.
5. Configurá límites - fijá máximos diarios, semanales y mensuales, además de la franja horaria.
6. Guardá sin ampliar riesgo - mantené el ramp-up activo.
7. Revisá Preview y Dry Run - comprobá la política y la cartera que tomaría.
8. Compará en el Simulador - contrastá el resultado contra otra política si corresponde.
9. Revisá Asignaciones - verificá qué política recibe cada cuota y detectá agendas desfasadas.
10. Ejecutá el planificador - desde Dashboard, un Supervisor o Admin puede iniciar una corrida manual.
11. Controlá Agenda y Alertas - verificá los intentos creados antes de dejar la operación automática.

Resolver una cuota pagada por fuera antes del débito

1. El ejecutor relee la cuota justo antes de llamar al proveedor.
2. Si Fecha_Cobro está informada o el saldo es cero, cancela el intento.
3. Completa la agenda con el motivo de cobro externo.
4. Genera una alerta informativa y continúa el FIFO con la próxima cuota.
5. No envía el débito a Mobbex o Pagos360, evitando un cobro duplicado.

• Probá toda política con Preview, Dry Run, Simulador y Asignaciones antes de activarla.
• Mantené el ramp-up salvo durante una prueba controlada y documentada.
• Revisá primero Dashboard, Alertas y el mensaje de último error cuando el motor no avance.
• Si hay intentos pendientes, comprobá motor encendido, ventana horaria, bloqueos, límites, suscripción y saldo real.
• En modo observador, no uses Mobbex_Hooks.Procesada para saber si Collections ya vio un hook; consultá Cob_Mobbex_Hooks_Observados.
• Tratá las fechas FechaHora* del motor como UTC en base y hora local en pantalla.
• No edites manualmente tablas Cob_* o Pag_* para destrabar una operación sin respaldo y análisis de relaciones.
• No habilites Comercio o MercadoPago como proveedores de pagos salientes mientras sigan siendo stub.
• No copies credenciales, tokens ni cadenas de conexión en tickets, manuales o capturas.
• Antes de una conciliación manual de Pagos360, verificá fecha, tipo de reporte y ambiente.

La aplicación no usa strings IsAllowedObject ni KeyLicences de WinForms. Usa roles locales y políticas ASP.NET Core. Los nombres siguientes son los strings exactos configurados en Program.cs.

Importante: el rol se guarda en la cookie de autenticación con vigencia de 8 horas y expiración deslizante. Un cambio de rol o activación toma efecto en el próximo login.

Advertencia de seguridad: ASP.NET Core Razor Pages no admite autorización por handler mediante [Authorize]. El build relevado emite MVC1001 para esos atributos. Por ejemplo, si una PageModel tiene Lectura y su OnPost... declara AdminOrSupervisor, la política del handler puede no aplicarse. Verificar y corregir la autorización a nivel de página, convención o filtro antes de considerar segura la separación de funciones.

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

En este proyecto las interfaces reales son páginas Razor ASP.NET Core, no formularios WinForms. El relevamiento se realizó sobre el código del commit 0e1957e6d2786d1c03ac37192d4dfb9edd361697.

Formularios y pantallas

Managers y clases de negocio

Servicios automáticos

Endpoints

Stored Procedures y funciones

No usa Stored Procedures propios para la operación del motor. El acceso a datos es EF Core 8 mediante CobranzasDbContext. Las consultas complejas se expresan con LINQ y SQL generado por EF. Las tablas funcionales de Plenario están marcadas ExcludeFromMigrations; las migraciones del proyecto crean y modifican solamente el esquema del motor.

Tablas de base de datos

Tablas funcionales de Plenario e integraciones

Tablas del motor de cobranzas

Tablas del submódulo Pagos

Permisos reales

No se encontraron permisos IsAllowedObject ni KeyLicences en este repositorio.

Relación con otros módulos / manuales

Notas para soporte

• Las entidades de tablas Plenario contienen campos bool? y proyecciones defensivas porque existen filas legacy con NULL. No volverlos no-nullable sin sanear la base.
• Las fechas FechaHora* se almacenan en UTC y se muestran con ToLocalTime().
• En modo observador, Collections no debe escribir Mobbex_Hooks.Procesada ni Mobbex_Hooks_Cobros.
• Los BackgroundService singleton crean scopes para consumir EF y servicios scoped. No inyectar un scoped directamente en un singleton.
• ProveedorTransaccionalFactory debe permanecer scoped porque consume IEnumerable<IProveedorTransaccional> scoped.
• Las migraciones se aplican automáticamente al arrancar. Un error se registra como crítico, pero la aplicación continúa para servir la página de error.
• Los controladores webhook expuestos deben protegerse y validarse según la configuración del proveedor; el endpoint ping es solo diagnóstico.
• El build emite múltiples advertencias MVC1001: [Authorize] no se aplica a handlers Razor individuales. Es un riesgo real de autorización; mover la protección a PageModels separadas, convenciones o filtros y agregar pruebas de acceso por rol.
• La suite relevada compila y ejecuta 43 pruebas, pero falla PresionServiceTests.Bloqueo_RechazaYDesbloqueoManual_Libera: esperaba que un bloqueo rechazara la operación y recibió Permitido = true. Revisar aislamiento/fecha del test y la lógica de PresionService antes de confiar en ese escenario.
• Los timeouts HTTP son de 30 segundos para Mobbex, Plenario, Pagos360 y MercadoPago; 45 segundos para Comafi y Comercio.
• ComafiProvider usa endpoints configurables porque los paths definitivos no estaban confirmados al momento del relevamiento.
• ComercioProvider y MercadoPagoProvider heredan de ProviderStubBase: verificar contra binario instalado y no usar en producción hasta implementar la API real.
• La documentación previa menciona una pantalla pendiente de hooks observados y parámetros Ola 7; contrastar siempre la versión desplegada con este commit.
• La cadena de conexión y las credenciales de proveedores son datos sensibles y no deben incorporarse al manual publicado.