Manual PSICOLE

Bienvenido al manual de usuario del sistema PSICOLE — plataforma de gestión integral del Colegio de Psicólogos.

¿Qué es PSICOLE?

PSICOLE es el sistema centralizado para la gestión de matrículas, finanzas, cursos de capacitación y autogestión de profesionales matriculados. Permite a los operadores del Colegio y a los propios profesionales realizar todos sus trámites de forma digital.

¿Por dónde empiezo?

Elegí tu perfil para ir directo a la guía de inicio rápido:

• Administrador

  ---

  Gestión completa del sistema, usuarios y configuración.

  Guía del Administrador

• Operador de Matrículas

  ---

  Alta, seguimiento y validación de solicitudes de matrícula.

  Guía del Operador de Matrículas

• Operador de Finanzas

  ---

  Gestión de pagos, recibos, cuotas y conciliación bancaria.

  Guía del Operador de Finanzas

• Operador de Cursos

  ---

  Alta y gestión de cursos de capacitación continua.

  Guía del Operador de Cursos

• Operador de Trámites

  ---

  Procesamiento de solicitudes y trámites administrativos.

  Guía del Operador de Trámites

• Supervisor de Trámites

  ---

  Supervisión y aprobación de trámites del equipo.

  Guía del Supervisor de Trámites

• Colegiado

  ---

  Portal de autogestión para profesionales matriculados.

  Guía del Colegiado

• Prestador

  ---

  Envío de órdenes de obras sociales y seguimiento de liquidaciones.

  Guía del Prestador

• Aspirante

  ---

  Solicitantes de matrícula que aún no están matriculados.

  Guía del Aspirante

Módulos del sistema

Referencia rápida

• Glosario de términos
• Matriz de permisos por rol
• Preguntas frecuentes
• Errores comunes y soluciones

🖥 Escritorio Panel de administración general del sistema

📱 Móvil Panel de administración general del sistema

Guía de Inicio Rápido — Administrador

¿Qué es este rol?

El Administrador es el rol con mayor nivel de acceso en PSICOLE. Tiene control total sobre la configuración del sistema, la gestión de usuarios y permisos, y la supervisión de todos los módulos. Es responsable de mantener la integridad operativa de la plataforma, crear y desactivar cuentas de operadores, configurar parámetros globales y auditar el comportamiento del sistema.

Este rol está reservado para el personal técnico o directivo del Colegio de Psicólogos con responsabilidad sobre la administración TI del sistema.

Acceso al sistema

• URL de login: https://psicole.app/login (o la URL interna asignada por el Colegio)
• Credenciales: proporcionadas por el equipo técnico durante la puesta en marcha; se recomienda cambiar la contraseña en el primer ingreso
• Dashboard: al ingresar verás el panel de administración con métricas globales: total de colegiados activos, matrículas pendientes, recaudación del mes, trámites en curso y estado de los jobs automáticos (CRON). Desde las tarjetas de KPIs podés saltar en un clic a los módulos clave (solicitudes de matrícula, tickets sin asignar, beneficios, mensajes internos) y desde el bloque de Acciones rápidas al Kanban de tickets, Padrón, Finanzas y Auditoría.

Capturas auditadas del inicio administrativo

El dashboard administrativo fue recapturado en escritorio y celular para validar que KPIs, accesos rápidos, buscador y barra lateral mantengan jerarquía sin solapamientos en monitores chicos y teléfonos.

Tus tareas principales

1. Crear y gestionar usuarios del sistema

La tarea más frecuente del Administrador es dar de alta o de baja a operadores del Colegio.

1. Ingresá a Administración → Usuarios.
2. Hacé clic en + Nuevo usuario.
3. Completá nombre, correo electrónico institucional y rol. No se ingresa ni se muestra una contraseña en el alta.
4. Asigná los permisos específicos si el rol lo requiere (los permisos se expresan como triplets modulo/accion/recurso, por ejemplo FINANZAS/CREATE/PAYMENT).
5. Guardá y luego usá Resetear y enviar acceso. El usuario recibe la clave temporal directamente por correo y debe cambiarla al ingresar. Si el correo no es aceptado realmente por SMTP, el acceso no cambia.

Para desactivar un usuario: buscalo en la lista, hacé clic en los tres puntos (⋮) y seleccioná Desactivar cuenta. El usuario pierde acceso inmediatamente pero sus datos históricos se conservan.

Super Admins y promoción segura

La vista de Super Admins también fue recapturada para documentar el comportamiento responsive del listado y del flujo de promoción. En celular, el botón principal ocupa el ancho disponible y el modal de confirmación queda contenido en la pantalla.

2. Configurar parámetros globales del sistema

1. Ingresá a Administración → Configuración.
2. Desde allí podés ajustar:
3. Tarifario mensual de cuotas, manteniendo CUOTA_MENSUAL como concepto oficial y cargando importes por periodo en Dinero -> Configuración -> Tarifario mensual.
4. Pasarelas de pago: actualizá credenciales, modo sandbox/producción y URLs de retorno o webhook.
5. CRON jobs: habilitá o deshabilitá las tareas automáticas (generación mensual de cuotas, envío de notificaciones de vencimiento, conciliación automática).
6. Parámetros de PDF: logotipo, datos del Colegio que aparecen en recibos y certificados.
7. Antes de ejecutar o habilitar la generación mensual, verificá que CUOTA_MENSUAL sea el único concepto mensual activo y que el período esté cargado en el Tarifario mensual.
8. Si está habilitado el CRON de lote CBU, verificá que use la misma regla que la generación manual: solo adhesiones BANK_DEBIT con CBU verificado y Debt.finalAmount como importe a debitar.
9. Guardá cada sección por separado. Los cambios críticos de pasarelas pueden requerir reinicio o redeploy según el entorno.

3. Auditar el sistema y revisar logs

1. Ingresá a Administración → Auditoría.
2. Filtrá por fecha, usuario o módulo para ver el registro de acciones.
3. Cada entrada muestra: fecha/hora, usuario, acción realizada (CREATE, UPDATE, DELETE), módulo afectado y detalle del objeto modificado.
4. Podés exportar los logs en formato CSV para reportes de auditoría interna.

4. Supervisar los CRON jobs automáticos

1. Ingresá a Administración → Tareas Automáticas.
2. Verás el estado de cada job: último tiempo de ejecución, próxima ejecución, cantidad de registros procesados y si hubo errores.
3. Si un job falló, podés relanzarlo manualmente con el botón Ejecutar ahora.
4. Los jobs críticos incluyen: generación de cuotas mensuales, recordatorios de vencimiento por e-mail y conciliación bancaria nocturna.
5. El job de lote CBU no debe ejecutarse si las cuotas del período no fueron generadas o si hay diferencias entre el lote y Debt.finalAmount.

Lo que NO podés hacer con este rol

• Operar módulos de negocio directamente como si fueras un operador (aunque técnicamente tenés acceso, el rol Admin está pensado para configuración, no para carga operativa diaria).
• Eliminar registros históricos de pagos, matrículas o trámites (el sistema no lo permite por integridad contable; solo podés anular con trazabilidad).
• Modificar el código fuente desde el panel (la configuración es a nivel de parámetros, no de código).

Flujos de trabajo típicos

Escenario 1: Alta de un nuevo operador de finanzas

1. El jefe administrativo solicita dar de alta a un nuevo empleado para el área de finanzas.
2. Ingresás a Administración → Usuarios → + Nuevo usuario.
3. Asignás el rol OPERADOR_FINANZAS y los permisos FINANZAS/CREATE/PAYMENT, FINANZAS/READ/RECEIPT, FINANZAS/UPDATE/CUOTA.
4. Guardás el usuario y ejecutás Resetear y enviar acceso.
5. El operador recibe el correo directo, ingresa con la clave temporal y debe definir una propia antes de acceder al resto del sistema.

Escenario 2: Actualización de claves de pasarela tras renovación anual

1. El proveedor notifica el vencimiento de credenciales.
2. Ingresás a Dinero → Configuración o Parámetros del Sistema, según el parámetro.
3. Reemplazás las credenciales con los nuevos valores obtenidos del panel del proveedor.
4. Guardás y reiniciás el servicio de pagos online desde Administración → Servicios.
5. Realizás un pago de prueba desde una cuenta colegiado de test para confirmar que la integración funciona.

Recursos relacionados

• Módulo de Administración de Usuarios
• Configuración Global del Sistema
• Tareas Automáticas (CRON)
• Auditoría y Logs
• Pagos Online y Pasarelas

🖥 Escritorio Bandeja de solicitudes de matrícula

📱 Móvil Bandeja de solicitudes de matrícula

Guía de Inicio Rápido — Operador de Matrículas

¿Qué es este rol?

El Operador de Matrículas es el responsable de gestionar el ciclo de vida de las matrículas profesionales en el Colegio. Revisa las solicitudes de nuevos aspirantes, valida la documentación presentada, aprueba o rechaza inscripciones, emite credenciales y mantiene actualizado el padrón de colegiados. Es el nexo entre los aspirantes que solicitan matricularse y la habilitación formal para ejercer la profesión.

Acceso al sistema

• URL de login: https://psicole.app/login
• Dashboard: al ingresar verás un resumen de solicitudes pendientes de revisión, matrículas vencidas por renovar y alertas de documentación incompleta. El panel principal muestra una cola de trabajo priorizada por antigüedad de solicitud.

Tus tareas principales

1. Revisar y procesar solicitudes de matrícula

Si una solicitud todavía no emitió matrícula y tiene un dato personal mal cargado, abrí Solicitudes de Matrícula → Ver → Editar datos. Podés corregir nombre, apellido, email, DNI, tipo de documento, CUIT/CUIL, teléfono y fecha de nacimiento. Confirmá con Guardar corrección: el cambio queda auditado y no modifica documentos, pagos ni el estado del trámite. Si la matrícula ya fue emitida, hacé la corrección desde la ficha del profesional para preservar los documentos oficiales.

Esta es la tarea central del rol. Las solicitudes llegan desde el portal del Aspirante.

1. Ingresá a Matrículas → Solicitudes Pendientes.
2. La lista muestra cada solicitud con: nombre del aspirante, fecha de solicitud, estado de la documentación y días en cola.
3. Hacé clic en una solicitud para abrir el expediente digital.
4. Revisá cada documento adjunto (título universitario, DNI, foto, constancia de CUIL, comprobante de pago del arancel de inscripción):
5. Tildá cada documento como Verificado si es legible y válido.
6. Si un documento está incompleto o ilegible, usá Solicitar corrección para enviar un mensaje automático al aspirante indicando qué debe reenviar.
7. Una vez que todos los documentos estén verificados, habilitá el botón Aprobar solicitud.
8. Al aprobar, el sistema genera automáticamente:
9. Número de matrícula (correlativo).
10. Credencial digital con código QR.
11. Notificación por e-mail al nuevo colegiado.
12. Primera cuota de matrícula anual (en coordinación con el módulo de Finanzas).

2. Gestionar el padrón de colegiados activos

1. Ingresá a Matrículas → Padrón de Colegiados.
2. Podés buscar por nombre, apellido, número de matrícula o DNI.
3. Desde la ficha de cada colegiado podés:
4. Actualizar datos personales (domicilio, teléfono, e-mail) a pedido del profesional.
5. Registrar un cambio de categoría (por ejemplo, de matrícula provisoria a definitiva).
6. Suspender o dar de baja una matrícula por resolución del Colegio (requiere ingresar el número de expediente resolutivo).
7. Emitir una nueva credencial si la anterior fue extraviada o venció.

3. Controlar vencimientos y renovaciones

1. Ingresá a Matrículas → Vencimientos.
2. El sistema muestra un calendario con las matrículas que vencen en los próximos 30, 60 y 90 días.
3. Podés lanzar un envío masivo de notificaciones a todos los colegiados con vencimiento próximo desde el botón Notificar seleccionados.
4. Para procesar una renovación: buscá al colegiado, verificá que esté al día con sus cuotas (el indicador de deuda aparece en la ficha) y hacé clic en Renovar matrícula. El sistema actualizará la fecha de vigencia automáticamente.

Lo que NO podés hacer con este rol

• Registrar o modificar pagos — eso es exclusivo del Operador de Finanzas.
• Acceder a los expedientes de trámites (habilitaciones, certificados) — eso lo gestiona el Operador de Trámites.
• Crear usuarios del sistema — es función del Administrador.
• Aprobar o rechazar devoluciones de cuotas — requiere permisos de Finanzas.
• Ver información financiera consolidada del Colegio (reportes de recaudación global).

Flujos de trabajo típicos

Escenario 1: Aspirante que completó su solicitud online

1. Recibís una notificación en el dashboard: "Nueva solicitud de matrícula — García, María José".
2. Abrís el expediente en Matrículas → Solicitudes Pendientes.
3. Revisás los 5 documentos requeridos. El título universitario está escaneado con baja resolución.
4. Hacés clic en Solicitar corrección → seleccionás "Título universitario" → escribís: "Por favor, reenvíe el título con mejor resolución (mínimo 300 DPI)".
5. El aspirante recibe el correo, reenvía el documento actualizado y la solicitud vuelve a tu cola.
6. Verificás el nuevo documento, tildás todos como válidos y hacés clic en Aprobar solicitud.
7. El sistema genera la matrícula N° 4821 y envía la credencial digital a la aspirante.

Escenario 2: Colegiado solicita duplicado de credencial

1. El colegiado llama indicando que perdió su credencial.
2. Buscás la matrícula en Matrículas → Padrón de Colegiados.
3. Verificás que la matrícula esté vigente y sin deudas.
4. Hacés clic en Emitir duplicado de credencial.
5. El sistema genera un PDF con código QR actualizado que podés descargar e imprimir o enviar por e-mail.

Recursos relacionados

• Módulo de Solicitud de Matrícula
• Gestión de Matrículas
• Credenciales y Códigos QR
• Flujo del Aspirante

🖥 Escritorio Panel de cobro de cuotas y deudas

📱 Móvil Panel de cobro de cuotas y deudas

Guía de Inicio Rápido — Operador de Finanzas

¿Qué es este rol?

El Operador de Finanzas gestiona todo el ciclo económico del Colegio: emisión y seguimiento de cuotas, registro de pagos manuales, emisión de recibos, conciliación bancaria y control de deudas. Trabaja en coordinación con DINERO, pasarelas de pago y Liquidaciones para distribuir fondos de prestadores.

Es el rol responsable de mantener la salud financiera del padrón: que cada colegiado tenga sus cuotas generadas, que los pagos estén correctamente imputados y que los recibos sean emitidos con datos válidos.

Acceso al sistema

• URL de login: https://psicole.colegiopsimza.org.ar/login (el host psicole.umdev.com.ar queda disponible como continuidad temporal).
• Dashboard: al ingresar verás indicadores clave: recaudación del mes en curso, cantidad de cuotas vencidas sin pagar, pagos online pendientes de conciliación y alertas de discrepancias bancarias. El resumen financiero se actualiza en tiempo real.

Tus tareas principales

1. Registrar un pago manual

Cuando un colegiado paga en la sede del Colegio o por un medio externo:

1. Ingresá a Finanzas → Pagos → Registrar pago manual.
2. Buscá al colegiado por nombre, DNI o número de matrícula.
3. El sistema mostrará automáticamente las cuotas adeudadas ordenadas por vencimiento.
4. Seleccioná la/s cuota/s que el colegiado está pagando.
5. Completá:
6. Monto recibido (puede incluir intereses por mora si corresponde).
7. Medio de pago (efectivo, transferencia, cheque).
8. Número de comprobante (si aplica, ej: número de transferencia bancaria).
9. Fecha de pago (por defecto es hoy, pero podés retroceder si el pago fue procesado con demora).
10. Hacé clic en Confirmar pago. El sistema imputará el pago a las cuotas seleccionadas y generará automáticamente el recibo.
11. Podés descargar el recibo en PDF para entregar al colegiado o enviarlo por e-mail con el botón Enviar recibo.

2. Gestionar cuotas del padrón

1. Ingresá a Dinero → Operaciones → Cuotas.
2. Podés filtrar por: colegiado, período, estado (pagada/vencida/pendiente/en mora).
3. Antes del RUN mensual, verificá que el tipo mensual oficial CUOTA_MENSUAL esté activo y que el período tenga el importe aprobado en el Tarifario mensual.
4. Usá Previsualizar para revisar cantidad de profesionales, cuotas a generar, importe base, descuentos por método de pago y monto total.
5. Ejecutá Generar solo cuando el total sea consistente. La generación crea deudas y cargos de cuenta corriente; no significa que el dinero ya fue cobrado.
6. Si vas a operar debito automatico, revisá que las deudas del período tengan finalAmount correcto antes de generar o enviar el lote CBU.
7. Para aplicar un descuento o bonificación: ingresá a la cuota, hacé clic en Modificar monto e ingresá el justificativo (este cambio queda registrado en la auditoría).
8. Para dar de baja una cuota por error (por ejemplo, se generó duplicada): seleccioná la cuota y usá Anular cuota. Solo podés anular cuotas que no tengan pagos imputados.

Para agosto de 2026, el tarifario versionado es: general $16.670, CBU $13.336, tarjeta $11.669 y jubilado $8.335. Julio conserva sus importes canónicos anteriores; no lo revalorices con agosto mientras su conciliación tenga bloqueos o saldo sin resolver.

2.1 Consultar la cuenta y los planes de un profesional

1. Ingresá a Matrículas -> Profesionales y buscá por nombre, DNI o matrícula.
2. Abrí la ficha y entrá en Cuenta Corriente para revisar cuotas, estado, recibos, pagos y saldos a favor.
3. Las cuotas mensuales deben verse como Cuota Mensual - Mes Año. Diferencias de texto históricas se normalizan al consultar y no implican deudas distintas.
4. Entrá en Planes para revisar acuerdos activos e históricos, avance de cuotas, próximo vencimiento y mora.
5. Usá Abrir ficha en una deuda, recibo o pago para consultar su trazabilidad. Al volver, el sistema debe reabrir el mismo profesional y la misma pestaña.
6. Si un plan histórico está cancelado o completado, se conserva como antecedente y no debe interpretarse como plan operativo.
7. Registrá una cuota sólo si el plan está ACTIVE. Si la respuesta se corta, reintentá desde la misma acción: el sistema conserva la identidad técnica del intento. Antes de iniciar uno nuevo, comprobá que PAY, recibo y cuenta corriente estén completos.
8. Un descuento especial se calcula sobre el saldo pendiente del servidor y requiere aprobación de otra persona; quien lo solicita no puede aprobarlo.
9. Si existen más de 12 cuotas mensuales vencidas, usá Solicitar descuento por pago único. La solicitud incluye todas las MONTHLY_FEE vencidas; otra persona de Tesorería la aprueba y luego se cobra el grupo completo por el importe exacto en una sola operación. No uses pago parcial, saldo a favor, efectivo ni ingreses el descuento dentro del formulario de pago.

La lectura de Cuenta Corriente y Planes no genera cobros, no modifica estados y no envía mensajes. Si una ficha no encuentra el registro, no crees un pago nuevo: volvé al perfil y verificá primero el identificador de deuda, PAY o REC.

2.2 Preparar lote CBU

1. Ingresá a Dinero → Operaciones → Débito automático.
2. Revisá adhesiones BANK_DEBIT activas, CBU verificado y cuenta activa.
3. Generá el lote del período o abrí el lote creado por CRON.
4. Controlá que el total del lote sea la suma de Debt.finalAmount de las cuotas incluidas.
5. Si el total no cuadra, no descargues ni envíes el COELSA: revisá descuentos, beneficios, método de cobro y deudas del período.
6. Descargá el archivo y envialo al banco por el canal operativo acordado.
7. Al recibir la devolución, cargá aprobados y rechazados.

En un rechazo CBU, el sistema revierte solo el descuento por débito directo. Si el profesional tenía jubilación, beneficio parental u otro beneficio aprobado, ese beneficio queda vigente en el saldo pendiente.

3. Conciliación bancaria

La conciliación bancaria permite cruzar los movimientos del extracto bancario con los pagos registrados en el sistema.

1. Ingresá a Finanzas → Conciliación Bancaria.
2. Importá el extracto bancario en formato CSV o TXT (según el formato del banco).
3. El sistema intentará matchear automáticamente cada movimiento bancario con un pago registrado, usando el monto, la fecha y el número de referencia.
4. Para cuotas mensuales, revisá que el movimiento coincida con la deuda final generada o con un ajuste contable aprobado por aumento mensual.
5. Los movimientos no identificados aparecen en la sección Pendientes de conciliación.
6. Para cada pendiente: buscá manualmente el pago correspondiente usando el buscador lateral o marcalo como Ingreso no identificado para revisión posterior.
7. Al finalizar, generá el Informe de conciliación en PDF.

3.1 Certificar un RUN mensual contra banco

Para cerrar un periodo de cuotas, trabajá con el denominador estricto: tarjeta aceptada + CBU cobrado. Usá recibos, padrones, caja y listados de prestadores como evidencia de contraste, no como movimientos nuevos si representan el mismo cobro.

1. Separá rechazos bancarios de cobros reales.
2. Validá que cada cobro tenga deuda del periodo, operación PAY, recibo y cuenta corriente.
3. Para CBU, aplicá solo si hay una transacción bancaria exacta y no vinculada a otra operación.
4. Si el match depende solo de nombre, monto parecido o padrón histórico, dejalo en cola manual.
5. Documentá el cierre con cantidad, monto, tasa de conciliación y lista de bloqueos.

En la certificación SANDBOX de mayo/junio 2026 se conciliaron 5.697 de 5.986 eventos aceptados/cobrados. Los 360 eventos sueltos originales quedaron tratados al 100%, pero 289 permanecieron sin destino estricto por falta de desempate seguro.

4. Emitir y gestionar recibos

1. Ingresá a Finanzas → Recibos.
2. Podés buscar recibos por colegiado, número de recibo, período o fecha.
3. Para reemitir un recibo (si el colegiado lo perdió): buscá el pago, hacé clic en Reemitir recibo. El sistema genera un PDF idéntico con marca de agua "DUPLICADO".
4. Para anular un recibo: ingresá el número de recibo, clic en Anular e ingresá el motivo. La anulación queda registrada y el pago vuelve al estado "pendiente de imputación".

5. Controlar órdenes y lotes de prestadores

1. Ingresá a Prestadores → Órdenes y filtrá por Obra Social, período, estado o etapa. El número de orden, la práctica, la cantidad, el precio y la fecha deben verse en la lista, el detalle y la exportación.
2. Si una orden guardada tiene un error, abrí Corregir, elegí la práctica del nomenclador y ajustá los campos necesarios. Indicá siempre el motivo.
3. Si la orden ya forma parte de una rendición y está PENDING u OBSERVED, corregila desde el detalle de esa rendición; la grilla general la bloquea para evitar totales divergentes.
4. Una orden validada o presentada sin rendición puede volver a observación al corregirse. Dentro de una rendición, la UI aún no ofrece Corregir para VALIDATED/SUBMITTED; no fuerces el cambio y registrá ese caso como brecha. Las órdenes terminales no se editan.
5. Para el cierre mensual, seleccioná campo de fecha, rango y Obra Social y ejecutá Vista previa. Generá sólo si cantidad y total coinciden con ese preview.
6. Usá la exportación de control para revisar el detalle antes de facturar. El CSV es una lectura auditada y no crea lote, factura, liquidación ni pago.

Ver Corrección operativa y control de lotes.

Lo que NO podés hacer con este rol

• Aprobar o rechazar solicitudes de matrícula — es función del Operador de Matrículas.
• Acceder al panel de administración de usuarios del sistema.
• Modificar credenciales de pasarelas de pago — eso lo hace el Administrador.
• Gestionar cursos o inscripciones — es función del Operador de Cursos.
• Aprobar trámites — es función del Operador o Supervisor de Trámites.

Flujos de trabajo típicos

Escenario 1: Colegiado paga en ventanilla con efectivo

1. El colegiado se presenta en la sede y entrega $15.000 en efectivo por 2 cuotas adeudadas.
2. Ingresás a Finanzas → Pagos → Registrar pago manual.
3. Buscás al colegiado por DNI: "28.741.963".
4. El sistema muestra 3 cuotas vencidas. Seleccionás las primeras 2 (las más antiguas, por orden de vencimiento).
5. Ingresás monto $15.000, medio "Efectivo", fecha de hoy.
6. El sistema calcula que las 2 cuotas suman $14.200 y el excedente de $800 se registra como adelanto para la próxima cuota.
7. Se genera el recibo N° 000847. Lo imprimís y se lo entregás al colegiado.

Escenario 2: Detectar y resolver una discrepancia en conciliación

1. Al importar el extracto bancario del viernes, el sistema deja 3 movimientos sin identificar.
2. Ingresás a Finanzas → Conciliación Bancaria → Pendientes.
3. Uno de los movimientos de $7.500 no matchea. Revisás la descripción: "TRANSFERENCIA GONZALEZ PEDRO".
4. Buscás en operaciones y encontrás un pago por pasarela de ese colegiado por el mismo monto registrado el mismo día.
5. Asociás el movimiento bancario a la operación PAY y lo marcás como conciliado.
6. Los otros 2 movimientos son depósitos propios del Colegio; los marcás como "Operación interna".

Recursos relacionados

• Módulo de Finanzas — Cuotas y Pagos
• Pagos Online y Pasarelas
• Conciliación Bancaria
• Módulo de Liquidaciones
• Prestadores y Órdenes
• Emisión de Recibos y PDFs

🖥 Escritorio Gestión de cursos de capacitación

📱 Móvil Gestión de cursos de capacitación

Guía de Inicio Rápido — Operador de Cursos

¿Qué es este rol?

El Operador de Cursos administra la oferta de capacitación y formación continua del Colegio. Es responsable de crear y publicar cursos, gestionar las inscripciones de los colegiados, controlar la asistencia, emitir certificados de aprobación y manejar los aranceles asociados a cada capacitación.

Este rol trabaja de forma coordinada con el módulo DINERO cuando los cursos son arancelados, ya que el pago de la inscripción se procesa a través del sistema de cuotas o una pasarela habilitada.

Acceso al sistema

• URL de login: https://psicole.app/login
• Dashboard: al ingresar verás un resumen de cursos activos, inscripciones de la semana, próximas fechas de inicio y alertas de cursos con cupo casi completo. También aparece una bandeja de solicitudes de inscripción pendientes de confirmación.

Tus tareas principales

1. Crear y publicar un nuevo curso

1. Ingresá a Cursos → Gestión de Cursos → + Nuevo curso.
2. Completá el formulario:
3. Nombre del curso y descripción detallada.
4. Modalidad: presencial, virtual o híbrida.
5. Fechas: fecha de inicio, fecha de fin y fechas de cada clase si es un curso con múltiples encuentros.
6. Cupo máximo: cantidad de inscriptos permitidos.
7. Arancel: si es gratuito o arancelado (en ese caso, ingresá monto y método de cobro: pasarela, débito automático o pago en sede).
8. Instructor/Disertante: nombre y datos del responsable del curso.
9. Puntaje de actualización: si el curso otorga créditos de formación continua, ingresá la cantidad de horas o puntos.
10. Subí el material de difusión (imagen de portada, programa del curso en PDF).
11. Hacé clic en Guardar como borrador para revisarlo antes de publicar.
12. Una vez conforme, hacé clic en Publicar. El curso aparecerá disponible en el portal de autogestión de los colegiados.

2. Gestionar inscripciones

1. Ingresá a Cursos → Inscripciones.
2. Seleccioná el curso para ver su lista de inscriptos.
3. Las inscripciones pueden venir de dos fuentes:
4. Online: el colegiado se inscribió desde su portal de autogestión. Aparece con estado "Pendiente de confirmación".
5. Manual: un colegiado solicitó inscripción por teléfono o presencialmente. Usá + Inscribir manualmente, buscá al colegiado por matrícula o DNI y confirmá.
6. Para confirmar una inscripción online: revisá si el curso es arancelado y si el pago fue registrado. Si todo está en orden, hacé clic en Confirmar inscripción. El colegiado recibe un e-mail de confirmación con los datos del curso.
7. Para cancelar una inscripción: seleccioná al inscripto y hacé clic en Cancelar. Si corresponde devolución de arancel, coordiná con el Operador de Finanzas.
8. Si el cupo se completó, el sistema cierra automáticamente las inscripciones. Podés habilitar una lista de espera desde la configuración del curso.

3. Registrar asistencia y emitir certificados

Registro de asistencia:

1. Ingresá a Cursos → Asistencia.
2. Seleccioná el curso y la fecha del encuentro.
3. Para cada participante de la lista, marcá Presente, Ausente o Tardanza.
4. Guardá la asistencia. El sistema acumula el porcentaje de asistencia por participante.

Emisión de certificados:

1. Una vez finalizado el curso, ingresá a Cursos → Certificados.
2. El sistema lista a todos los inscriptos con su porcentaje de asistencia.
3. Marcá como Aprobados a quienes cumplieron el mínimo de asistencia requerido (configurable por curso, generalmente 75%).
4. Hacé clic en Generar certificados masivos. El sistema crea un PDF personalizado para cada aprobado, firmado digitalmente con el logo y datos del Colegio.
5. Los certificados quedan disponibles para descarga en el portal de autogestión de cada colegiado y podés enviarlos masivamente por e-mail desde el mismo módulo.

Lo que NO podés hacer con este rol

• Registrar pagos de aranceles — los pagos los gestiona el Operador de Finanzas.
• Aprobar matrículas o trámites del Colegio.
• Acceder a información financiera global del Colegio (recaudación, deudas del padrón).
• Crear o modificar usuarios del sistema.
• Gestionar prestadores ni órdenes de obras sociales.

Flujos de trabajo típicos

Escenario 1: Puesta en marcha de un curso de posgrado arancelado

1. El área académica confirma que se dictará "Terapia Cognitivo Conductual — Módulo Avanzado", 4 sábados, arancel $8.000, cupo 20 personas.
2. Creás el curso en Cursos → + Nuevo curso con todos los datos, configurás el cobro por pasarela o deuda y publicás.
3. En los siguientes días, llegán 18 inscripciones online. Revisás que cada una tenga el pago confirmado desde Cursos → Inscripciones.
4. Dos inscripciones están sin pago; enviás un recordatorio automático con el botón Notificar pago pendiente.
5. Al completarse el primer encuentro, registrás asistencia: 17 presentes, 1 ausente justificado.
6. Al finalizar el cuarto módulo, generás los 16 certificados de aprobación (17 asistentes menos 1 que no alcanzó el 75% de asistencia).

Escenario 2: Gestión de un curso gratuito con lista de espera

1. Publicás un webinar gratuito con cupo de 50 personas.
2. En 2 horas se completa el cupo. Activás la lista de espera desde Cursos → Configuración del curso.
3. Una semana antes del curso, 5 inscriptos cancelan. El sistema automáticamente notifica a los primeros 5 de la lista de espera para que confirmen.
4. Confirmás los nuevos inscriptos y el cupo queda completo nuevamente.

Recursos relacionados

• Módulo de Cursos
• Emisión de Certificados
• Integración de Pagos de Aranceles
• Autogestión del Profesional — Inscripción a Cursos

🖥 Escritorio Bandeja de tickets y trámites asignados

📱 Móvil Bandeja de tickets y trámites asignados

Guía de Inicio Rápido — Operador de Trámites

¿Qué es este rol?

El Operador de Trámites gestiona los tickets y solicitudes formales que los colegiados presentan al Colegio. Recibe tickets asignados automáticamente por el sistema, los atiende dentro del plazo (SLA) establecido, y puede pedir documentación adicional, pausar, resolver o derivar al supervisor.

Al ingresar al sistema, el operador llega directamente a su Dashboard Personal — una vista de bienvenida con todas sus tareas organizadas por urgencia.

Acceso al sistema

• URL: https://psicole.app/login
• Redirección automática: al ingresar, el sistema te lleva directo a /operator/dashboard — sin pasos extra.

Mi Dashboard Personal

Ruta: /operator/dashboard

Al entrar verás un panel con encabezado en degradado que muestra tu nombre, fecha y rol, seguido de los indicadores clave de tu trabajo.

KPIs en tiempo real

Los indicadores en el encabezado muestran de un vistazo:

• Pendientes — tickets que todavía no tomaste
• En progreso — tickets que ya estás atendiendo
• Resueltos hoy — completados en el día
• Vencidos — tickets cuyo SLA ya expiró

Alerta de tickets vencidos

Si tenés tickets con SLA vencido, aparece un banner rojo al tope del dashboard para que no se te escapen.

Tickets agrupados por urgencia

Los tickets están organizados en grupos con color en el borde izquierdo:

Vista en mobile:

Kanban de Tickets

Ruta: /operator/tickets

Vista estilo tablero con columnas por estado. Cada columna muestra los tickets que corresponden a ese estado y el semáforo SLA (verde / naranja / rojo).

Vista mobile:

Detalle de un Ticket

Hacé clic en cualquier ticket (en el dashboard o en el kanban) para abrir el detalle completo.

Desde el detalle podés:

• Ver todos los datos del solicitante y la categoría
• Leer el historial de comentarios y acciones
• Cambiar el estado del ticket (tomar, avanzar, pausar, resolver)
• Agregar comentarios internos o públicos
• Si la categoría tiene un trámite vinculado, aparece el botón "Ver servicio relacionado" para ir directamente al módulo

Vista mobile:

Ciclo de vida de un ticket

PENDIENTE → ASIGNADO → EN PROGRESO → [PAUSADO] → RESUELTO → CERRADO

El semáforo SLA en cada ticket indica: - 🟢 Verde — dentro del plazo - 🟠 Naranja — menos del 25% del tiempo restante - 🔴 Rojo — SLA vencido

Alertas y notificaciones

Cuando se te asigna un ticket nuevo, recibís una notificación en la campana del header. Haciendo clic en la notificación llegás directamente al ticket.

Vista mobile:

Flujo diario típico

1. Entrás al sistema → aterrizás en Mi Dashboard
2. Revisás el banner rojo (si hay tickets vencidos, atendelós primero)
3. Revisás el grupo En Advertencia (naranja) — son los que están por vencerse
4. Trabajás los tickets En Progreso
5. Tomás tickets Pendientes según disponibilidad
6. Al resolver, cambiás el estado a Resuelto — el sistema notifica al solicitante automáticamente

Recursos relacionados

• Sistema completo de Tickets y Soporte
• Gestión del Supervisor de Trámites

🖥 Escritorio Panel de supervisión de trámites y SLA

📱 Móvil Panel de supervisión de trámites y SLA

Guía de Inicio Rápido — Supervisor de Trámites

¿Qué es este rol?

El Supervisor de Trámites tiene visibilidad completa sobre la operación: ve los tickets de todos los operadores, puede reasignar, cerrar y monitorear el cumplimiento de SLA. Además accede al dashboard de métricas con KPIs globales y a la vista kanban por operador.

Acceso al sistema

• URL: https://psicole.app/login
• Menú: Tickets → Métricas / Tickets → Gestión de Tickets

Dashboard de Métricas

Ruta: /supervisor/metrics

Vista ejecutiva con KPIs del estado completo de la operación: tickets por estado, tiempos de resolución promedio y carga por operador.

Vista mobile:

Los indicadores clave incluyen: - Total de tickets activos en el sistema - Tickets por estado (pendiente, en progreso, resueltos, vencidos) - Distribución por operador y área de trabajo - Semáforo SLA global

Kanban por Operador

Ruta: /supervisor/tickets → Tab "Por operador"

Vista kanban que agrupa todos los tickets por operador para visualizar la carga de trabajo de cada uno. Desde acá podés detectar desbalances y reasignar tickets.

Reasignar un ticket

1. Abrís el detalle del ticket
2. Clic en Reasignar
3. Seleccionás el nuevo operador disponible
4. El operador anterior y el nuevo reciben notificación automática

Semáforo SLA

El semáforo es visible en todas las vistas:

El sistema puede generar alertas automáticas al supervisor cuando se supera el SLA (configurado en Tareas Programadas).

Cerrar un ticket

Como supervisor podés cerrar definitivamente un ticket resuelto: 1. Abrís el detalle del ticket (estado RESOLVED) 2. Clic en Cerrar ticket 3. El ticket pasa a estado CLOSED — acción irreversible

El cierre automático ocurre a los 7 días de resolución (configurable en Parámetros del Sistema).

Configuración del módulo

La configuración de categorías, áreas de trabajo y parámetros es responsabilidad del Administrador. Ver:

• Categorías de Tickets
• Áreas de Trabajo
• Parámetros del Sistema — Sección TICKETS

Recursos relacionados

• Sistema completo de Tickets y Soporte
• Guía del Operador de Trámites

🖥 Escritorio Portal de autogestión del profesional

📱 Móvil Portal de autogestión del profesional

Guía de Inicio Rápido — Colegiado

¿Qué es este rol?

El Colegiado es el profesional psicólogo matriculado en el Colegio que accede al portal de autogestión para gestionar sus asuntos de manera autónoma: consultar y pagar sus cuotas, descargar recibos y certificados, solicitar trámites, inscribirse a cursos y actualizar sus datos. Este rol tiene acceso exclusivamente a su propia información — nunca puede ver ni modificar datos de otros colegiados.

Es el rol de mayor cantidad de usuarios en el sistema, ya que representa a todos los profesionales matriculados activos.

Acceso al sistema

• URL de login vigente: https://psicole.colegiopsimza.org.ar/login. https://psicole.umdev.com.ar/login permanece como alias de continuidad y rollback; no se retira durante la estabilización.
• Credenciales: número de matrícula como usuario y la contraseña establecida durante la activación de la cuenta. Si es el primer ingreso, usá el link de activación enviado por e-mail cuando fue aprobada tu matrícula.
• Dashboard: al ingresar verás un resumen de tu situación, próximos cursos y trámites en curso. El aviso rojo de deuda suma sólo cuotas realmente vencidas; una cuota abierta cuyo vencimiento todavía no llegó puede verse en Estado de Cuenta, pero no como mora. En el panel superior se muestra además una miniatura de tu credencial digital — al hacer clic se abre un modal con el QR ampliado y atajos para descargar, compartir o ver la credencial completa.

Tus tareas principales

1. Consultar y pagar tus cuotas online

1. Ingresá a Mi cuenta → Cuotas y pagos.
2. Verás el historial completo de cuotas: las pagas con fecha de pago y número de recibo, y las pendientes con su fecha de vencimiento y monto.
3. Para pagar online, seleccioná la/s cuota/s que querés abonar (podés seleccionar varias a la vez).
4. Hacé clic en Pagar deuda. Serás redirigido al checkout de la pasarela habilitada.
5. Elegí el medio disponible en el proveedor: tarjeta, QR, billetera u otro instrumento configurado.
6. Completá el pago. Al volver al portal, el sistema actualizará automáticamente el estado de las cuotas (puede demorar hasta 2 minutos en reflejarse si el banco tarda en confirmar).
7. El recibo digital quedará disponible inmediatamente en Mi cuenta → Mis recibos.

2. Descargar recibos y comprobantes

1. Ingresá a Mi cuenta → Mis recibos.
2. Los recibos se muestran ordenados por fecha. Podés filtrar por año o período.
3. Hacé clic en Descargar PDF sobre cualquier recibo para obtener el comprobante oficial del Colegio con número de recibo, datos del pago y código QR de verificación.
4. El código QR del recibo permite que terceros (obras sociales, empleadores, juzgados) verifiquen la autenticidad desde la URL incluida en el propio QR. La ruta oficial vigente es https://psicole.colegiopsimza.org.ar/verify/<código>. Los QR físicos con psicole.umdev.com.ar siguen funcionando, y el alias histórico /verificar/<código> redirige a /verify/<código> sin cambiar el código.

3. Solicitar un trámite

1. Ingresá a Trámites → Nueva solicitud.
2. Seleccioná el tipo de trámite que necesitás del menú desplegable (por ejemplo: "Constancia de matrícula vigente", "Certificado de buena conducta", "Habilitación de consultorio").
3. Completá el formulario con los datos requeridos y adjuntá la documentación solicitada (el sistema indica qué documentos son obligatorios para cada tipo de trámite).
4. Si el trámite tiene arancel, el sistema te solicitará el pago antes de confirmar la solicitud.
5. Hacé clic en Enviar solicitud. Recibirás un número de expediente y un correo de confirmación.
6. Podés seguir el estado del trámite en tiempo real desde Trámites → Mis trámites. Si el operador te solicita documentación adicional, recibirás una notificación y podrás adjuntarla desde el mismo expediente.

4. Inscribirte a un curso

1. Ingresá a Cursos → Oferta de cursos.
2. Explorá los cursos disponibles. Podés filtrar por modalidad, fecha o temática.
3. Hacé clic en un curso para ver el detalle: descripción, programa, disertante, fechas, cupo disponible y arancel.
4. Si querés inscribirte, hacé clic en Inscribirme.
5. Si el curso es gratuito, la inscripción se confirma de inmediato.
6. Si el curso es arancelado, el sistema te redirigirá a la pasarela habilitada. Una vez confirmado el pago, tu inscripción queda registrada.
7. Recibirás un e-mail de confirmación con todos los detalles del curso (links de acceso si es virtual, dirección si es presencial).

5. Actualizar tus datos personales y profesionales

1. Ingresá a Mi cuenta → Mis datos.
2. Podés actualizar: domicilio particular, domicilio profesional, teléfono de contacto y e-mail.
3. Importante: algunos cambios (como el cambio de nombre por razones legales) requieren documentación respaldatoria y se procesan como un trámite formal.
4. Guardá los cambios. Los datos actualizados se reflejan en los próximos certificados y constancias que solicites.

6. Pedir ayuda al Colegio

1. Hacé clic en el signo ? visible dentro de PSICOLE.
2. Para un colegiado o prestador se abre Soporte a Colegiados: describí la consulta y, si hace falta, adjuntá hasta cinco archivos.
3. Al enviar se muestra un número de ticket. Podés seguirlo desde Mis reportes, agregar documentación y consultar la respuesta.
4. Soporte Técnico es el canal de reporte interno del personal del Colegio. Ambos canales llegan a la misma mesa operativa, pero conservan categoría, permisos y trazabilidad diferentes.

En teléfono, el panel se adapta al área visible y al teclado. Mientras está abierto, el signo flotante deja de superponerse con el botón de envío.

Lo que NO podés hacer con este rol

• Ver información de otros colegiados — el sistema te muestra exclusivamente tu propia información.
• Modificar el monto de tus cuotas ni solicitar exenciones de pago directamente (debés solicitarlo como un trámite formal).
• Acceder a los módulos administrativos (matrículas, finanzas, cursos, trámites) en su versión operativa.
• Descargar recibos de pagos que no te correspondan.
• Aprobar o rechazar ningún tipo de solicitud.

Flujos de trabajo típicos

Escenario 1: Pagar las cuotas atrasadas y descargar un certificado para una obra social

1. Tu obra social requiere una constancia de matrícula vigente y de estar al día con las cuotas del Colegio.
2. Ingresás a Mi cuenta → Cuotas y pagos: tenés 2 cuotas vencidas.
3. Seleccionás ambas cuotas y pagás online con tu tarjeta a través de la pasarela habilitada.
4. Una vez confirmado el pago, ingresás a Trámites → Nueva solicitud → "Constancia de matrícula vigente".
5. Enviás la solicitud. En minutos recibís el PDF por e-mail y también está disponible en Trámites → Mis trámites.
6. Descargás el PDF y lo adjuntás en el formulario de la obra social.

Escenario 2: Inscripción a un curso con cupo limitado

1. Ves publicado el curso "Neuropsicología Clínica" con solo 5 lugares disponibles.
2. Ingresás a Cursos → Oferta de cursos, buscás el curso y hacés clic en Inscribirme.
3. El curso tiene arancel de $5.000. Pagás con tu tarjeta a través de la pasarela habilitada.
4. Recibís la confirmación: "Tu inscripción al curso Neuropsicología Clínica fue confirmada. Fecha de inicio: 15 de abril."
5. El certificado de aprobación estará disponible automáticamente en tu portal al finalizar el curso.

Recursos relacionados

• Autogestión del Profesional — Guía completa
• Pagos Online y Pasarelas
• Tipos de Trámites disponibles
• Oferta de Cursos
• Verificación de Documentos con QR

🖥 Escritorio Portal de carga de órdenes de obra social

📱 Móvil Portal de carga de órdenes de obra social

Guía de Inicio Rápido — Prestador

¿Qué es este rol?

El Prestador es el profesional psicólogo matriculado que, además de su membresía como colegiado, está registrado como prestador de servicios de salud mental para una o más obras sociales y/o prepagas. A través de este rol gestiona sus órdenes de atención, las presenta al Colegio para su procesamiento, administra su agenda de consultorio y cobra sus honorarios mediante el sistema de liquidaciones.

Acceso al sistema

• URL de login: https://psicole.app/login
• Dashboard: resumen de actividad — órdenes del período, monto acumulado, órdenes pendientes, alertas de órdenes rechazadas y turnos del día.

Tus tareas principales

1. Consultorio — Agenda de turnos

El Consultorio es tu agenda de sesiones. Podés programar turnos vinculados a pacientes de tu libreta y, al marcarlos como realizados, crear la orden de prestación en un clic.

1. Ir a Mis Órdenes → Consultorio.
2. Hacé clic en + Nuevo turno.
3. Completá los datos:
4. Paciente (autocomplete desde tu libreta — o ingresá el nombre libremente).
5. Obra social (se autocompleta si el paciente tiene OOSS en la libreta).
6. Fecha y hora, duración (default: 50 min), modalidad (Presencial / Virtual) y notas.
7. Al finalizar la sesión, hacé clic en ✓ Completar en la card del turno. Si el turno tenía obra social, el sistema te propone crear la orden de prestación con los datos pre-llenados.
8. Exportá tu agenda a Google Calendar con el botón Exportar .ics (cabecera de la página).

2. Cargar órdenes de atención

1. Ir a Mis Órdenes → Mis Órdenes → + Nueva Orden.
2. El campo Paciente tiene autocomplete desde tu libreta: al seleccionar un paciente se auto-completan DNI, obra social y número de afiliado.
3. Completá fecha de atención, sesiones, diagnóstico y tratamiento (los campos de diagnóstico y tratamiento sugieren valores usados anteriormente para agilizar la carga).
4. Adjuntá la orden física (JPG, PNG o PDF).
5. Guardá.

Después de guardar, revisá que el detalle muestre el número de orden, la fecha de prestación, la práctica y la cantidad correctas. Si el error se detecta cuando la orden ya fue enviada al circuito del Colegio, informalo en el mismo registro: un operador puede corregirla con motivo y auditoría. Una orden validada o presentada que todavía no integra una rendición vuelve a observación al corregirse y debe validarse otra vez. Dentro de una rendición, la corrección visible alcanza por ahora órdenes pendientes u observadas; una orden ya aceptada, pagada, rechazada o cancelada no se modifica.

3. Libreta de pacientes

La libreta centraliza los datos de tus pacientes para agilizar la carga de órdenes.

1. Ir a Configuración → Pacientes.
2. Buscar por nombre, apellido o DNI (campo de búsqueda con resultados en tiempo real).
3. Nuevo paciente → formulario con:
4. Nombre, apellido, DNI.
5. Obras sociales (podés agregar múltiples): obra social + Nº afiliado + plan (opcional).
6. Datos de contacto: teléfono, email, fecha de nacimiento, dirección, notas.
7. Importar desde órdenes: si ya tenés órdenes cargadas, el sistema puede crear automáticamente los pacientes de tu historial. Aparece un banner de importación cuando tenés pocos pacientes registrados — hacé clic en Ver preview para ver qué se importaría antes de confirmar.

4. Generar rendición mensual

Al cerrar el mes, presentá tus órdenes validadas al Colegio:

1. En Mis Órdenes, aparece un banner verde cuando tenés órdenes validadas listas para rendir: "Tenés X órdenes validadas listas para rendir este período."
2. Hacé clic en Generar rendición.
3. Revisá el resumen por obra social (cantidad de órdenes y subtotal por cada una).
4. Hacé clic en Enviar rendición al Colegio.
5. Seguí el estado desde Liquidaciones. Cuando aparezca la liquidación con el neto definitivo, cargá allí número, fecha, importe y archivo de la factura.

5. Consultar liquidaciones

1. Ir a Liquidaciones.
2. Cada liquidación muestra: período, estado, cantidad de órdenes, monto neto, factura y comprobante.
3. En una liquidación con Factura pendiente, seleccioná el archivo y completá número, fecha e importe. El importe debe coincidir con el neto liquidado.
4. Cuando el Colegio aprueba la factura y registra el pago, podés descargar el comprobante desde Ver detalle → Descargar comprobante.

6. Gestionar tu perfil de prestador

1. Ir a Configuración → Obras Sociales para ver y gestionar las obras sociales habilitadas.
2. Ir a Configuración → Datos Bancarios para actualizar tu CBU de acreditación.
3. Ir a Mi Perfil Público para actualizar lo que ven los pacientes en el directorio (bio, foto, especialidades, OOSS, modalidad de atención).

Flujos de trabajo típicos

Escenario 1: Cierre mensual con agenda de consultorio

1. Durante el mes cargaste los turnos en Consultorio.
2. Al marcar cada turno como "Completado", el sistema te propone crear la orden de prestación con los datos pre-llenados.
3. Al fin del mes ves el banner verde en Mis Órdenes: "Tenés 28 órdenes validadas listas para rendir."
4. Generás la rendición y la enviás al Colegio. La factura se presenta después, sobre la liquidación calculada.

Escenario 2: Importación inicial de pacientes

1. Ingresás al sistema por primera vez con historial de órdenes.
2. En Configuración → Pacientes aparece un banner: "Importar pacientes desde tus órdenes históricas".
3. Hacés clic en Ver preview — el sistema te muestra 35 pacientes únicos detectados en tus órdenes.
4. Confirmás la importación. Los pacientes quedan en tu libreta con sus obras sociales y números de afiliado.

Escenario 3: Rendición de factura y descarga de comprobante

1. El Colegio procesó tu liquidación de marzo 2026 por $99.750 neto.
2. En Liquidaciones ves el aviso: "Factura pendiente de subir".
3. Informás el número, fecha e importe y subís el PDF de la factura.
4. El operador la revisa desde Facturas recibidas. La aprobación no ejecuta el pago ni envía mensajes.
5. Una vez registrado el pago, descargás el PDF del comprobante y lo enviás a tu contador.

Lo que NO podés hacer con este rol

• Ver las órdenes ni liquidaciones de otros prestadores.
• Aprobar tus propias órdenes.
• Modificar una orden ya liquidada (requiere trámite de rectificación formal).
• Acceder a los módulos operativos del Colegio.

Recursos relacionados

• Módulo de Prestadores
• Sistema de Liquidaciones
• Directorio Público
• Autogestión del Profesional

🖥 Escritorio Formulario de solicitud de matrícula

📱 Móvil Formulario de solicitud de matrícula

Guía de Inicio Rápido — Aspirante

¿Qué es este rol?

El Aspirante es el profesional que completó su formación universitaria y desea matricularse en el Colegio de Psicólogos para ejercer legalmente la profesión. Es un rol temporal: existe únicamente durante el proceso de solicitud de matrícula. Una vez que la solicitud es aprobada, el usuario pasa a ser Colegiado automáticamente.

El Aspirante tiene acceso muy acotado al sistema: puede crear su cuenta, completar el formulario de solicitud de matrícula, adjuntar la documentación requerida, pagar el arancel de inscripción y hacer seguimiento del estado de su solicitud.

Acceso al sistema

• URL de registro: https://psicole.app/registro (no es el mismo link que el login de colegiados)
• Credenciales: las creás vos mismo al registrarte con tu dirección de e-mail y una contraseña.
• Dashboard: al ingresar verás exclusivamente el estado de tu solicitud de matrícula: documentos entregados, documentos pendientes, estado general del expediente y mensajes del área de matrículas.

Tus tareas principales

1. Registrarse y crear la solicitud de matrícula

Si todavía no tenés cuenta en el sistema:

1. Ingresá a https://psicole.app/registro.
2. Completá el formulario de registro inicial:
3. Nombre completo (tal como figura en tu DNI).
4. Número de DNI.
5. Número de CUIL.
6. Correo electrónico (será tu medio de comunicación con el Colegio durante todo el proceso).
7. Contraseña (mínimo 8 caracteres, al menos una mayúscula y un número).
8. Recibirás un correo de verificación. Hacé clic en el link para activar tu cuenta.
9. Una vez activada, ingresás con tu e-mail y contraseña.
10. El sistema te llevará directamente al formulario de Solicitud de Matrícula.

2. Completar el formulario de solicitud

El formulario de solicitud tiene varias secciones. Podés guardarlo como borrador y completarlo en varias sesiones.

Sección 1: Datos personales - Nombre completo, fecha de nacimiento, domicilio particular, teléfono de contacto. - Foto de perfil (formato JPG o PNG, fondo blanco, mínimo 400x400 px).

Sección 2: Datos profesionales - Universidad de egreso. - Título obtenido (Licenciado/a en Psicología, Doctor/a, etc.). - Año de egreso. - Domicilio profesional (dirección donde ejercerás, puede ser el mismo que el particular).

Sección 3: Adjuntar documentación

Esta sección es crítica. Los documentos requeridos son:

• Hacé clic en + Adjuntar al lado de cada documento y seleccioná el archivo desde tu computadora o celular.
• El sistema indica con un tilde verde cada documento correctamente cargado.

Sección 4: Pago del arancel de inscripción

1. Una vez completadas las secciones anteriores, el sistema mostrará el monto del arancel de inscripción.
2. Hacé clic en Pagar arancel de inscripción para ser redirigido al checkout de la pasarela habilitada.
3. Podés pagar con los medios que el proveedor tenga configurados para el Colegio.
4. Una vez confirmado el pago, quedará registrado automáticamente en tu solicitud.

Envío final:

1. Revisá que todas las secciones estén completas (el sistema señalará en rojo las incompletas).
2. Hacé clic en Enviar solicitud. Recibirás un número de expediente y un correo de confirmación.

3. Hacer seguimiento de tu solicitud

1. Ingresá al portal con tu e-mail y contraseña.
2. En el dashboard verás el estado actual de tu expediente:
3. Recibida: el Colegio recibió tu solicitud, está en cola de revisión.
4. En revisión: un operador está verificando tu documentación.
5. Documentación incompleta: el operador te solicita que corrijas o reenvíes algún documento. Recibirás un correo con el detalle.
6. Aprobada: tu matrícula fue aprobada. Recibirás un correo con tu número de matrícula y las instrucciones para acceder al portal como Colegiado.
7. Rechazada: la solicitud fue rechazada con el motivo indicado (podés subsanar el problema y presentar una nueva solicitud si corresponde).

4. Responder a una solicitud de corrección de documentación

Si el operador de matrículas detecta un problema con tu documentación:

1. Recibirás un e-mail con el asunto: "Solicitud de corrección — Expediente N° XXXX".
2. Ingresá al portal y en tu dashboard aparecerá un aviso naranja con el detalle de lo que debés corregir.
3. Hacé clic en Ver solicitud de corrección para leer el mensaje del operador.
4. Reemplazá el documento observado: hacé clic en Reenviar documento al lado del documento indicado y adjuntá el nuevo archivo.
5. Una vez que hayas corregido todo lo indicado, hacé clic en Confirmar corrección. El expediente volverá a la cola de revisión del operador.

Lo que NO podés hacer con este rol

• Acceder a ningún módulo del Colegio más allá de tu propia solicitud de matrícula.
• Ver el estado de las solicitudes de otros aspirantes.
• Solicitar trámites, inscribirte a cursos ni pagar cuotas — esas funciones estarán disponibles una vez que seas Colegiado.
• Modificar el arancel de inscripción ni solicitar exenciones (debés contactar al Colegio por los canales institucionales antes de iniciar la solicitud).
• Reutilizar el mismo e-mail para crear múltiples solicitudes simultáneas.

Flujos de trabajo típicos

Escenario 1: Primera solicitud de matrícula desde cero

1. Te graduaste en marzo 2026 y querés matricularte.
2. Ingresás a https://psicole.app/registro, creás tu cuenta y activás el e-mail.
3. Completás el formulario: datos personales, datos de la UBA (tu universidad), subís los 5 documentos requeridos.
4. Pagás el arancel de $12.000 con tu tarjeta de crédito.
5. Enviás la solicitud. Recibís el correo: "Solicitud recibida — Expediente N° 2026-0847".
6. A los 3 días hábiles, el operador detecta que el título subido está en baja resolución.
7. Recibís el correo de corrección. Reescaneás el título a 300 DPI y lo reenvíás desde el portal.
8. A los 2 días hábiles siguientes recibís: "Tu matrícula N° 5312 fue aprobada. Bienvenido/a al Colegio de Psicólogos."
9. Tu acceso cambia automáticamente al rol Colegiado y podés usar todas las funciones del portal.

Escenario 2: Consultar el estado de una solicitud demorada

1. Enviaste la solicitud hace 10 días hábiles y no recibiste novedades.
2. Ingresás al portal: el estado dice "En revisión". No hay alertas de corrección pendiente.
3. Revisás si llegó algún correo a la carpeta de spam — no hay ninguno.
4. Usás el botón Contactar área de Matrículas (disponible en tu dashboard) para enviar un mensaje interno al Colegio preguntando el estado.
5. Al día siguiente el operador responde: "Su expediente fue asignado a revisión, en 2 días hábiles tendrá respuesta."

Recursos relacionados

• Módulo de Solicitud de Matrícula
• Documentación requerida para matricularse
• Preguntas frecuentes del Aspirante
• Qué pasa después de ser aprobado — Guía del Colegiado

🖥 Escritorio Pantalla de inicio de sesión en PSICOLE

📱 Móvil Pantalla de inicio de sesión en PSICOLE

Autenticación y Permisos

Descripción

El módulo de Autenticación y Permisos gestiona el acceso seguro a PSICOLE mediante un esquema de doble token JWT y un modelo de control de acceso basado en roles (RBAC). Cada sesión emite un access token de 15 minutos y un refresh token de 7 días. En el navegador ambos viajan en cookies httpOnly; el refresh también se persiste en la base de datos para poder rotarlo y revocarlo. El frontend conserva en localStorage sólo la información de usuario necesaria para la interfaz, no los tokens de sesión.

El sistema combina roles base (ADMIN, operadores de Matrículas, Finanzas, Cursos y Trámites, COLEGIADO, PRESTADOR y ASPIRANTE) con roles operativos especializados, entre ellos OPERADOR_PRESTADORES. Cada ruta usa grupos de roles y capacidades explícitas; no se debe deducir acceso a un módulo sólo por el nombre visible del rol. El middleware authenticate verifica y decodifica el access token en cada request; requireRole, requirePermission y las políticas por capacidad aplican la autorización antes de que el controlador procese la solicitud.

La prueba asistida permite a roles de soporte expresamente autorizados abrir la sesión visual de un usuario final para diagnóstico y acompañamiento. El token identifica al operador real y al usuario asistido, revalida la capacidad del operador en cada request y registra inicio y fin en AuditLog. El modo vigente puede habilitar escrituras necesarias para completar el trámite asistido; cada ruta conserva su autorización propia y las operaciones que usan blockIfImpersonating() permanecen bloqueadas.

Roles con acceso

Flujo principal

Login

1. El usuario ingresa su email (normalizado a minúsculas) y contraseña en el formulario de login (POST /api/v1/auth/login).
2. El sistema busca el usuario en la base de datos e incluye el rol con todos sus permisos y los módulos operador asignados.
3. Si el usuario no existe o la contraseña no coincide (verificada con bcrypt.compare), devuelve 401 Credenciales inválidas sin revelar cuál campo es incorrecto.
4. Si el usuario existe pero está inactivo (isActive = false), devuelve 403 Usuario inactivo.
5. Ante login exitoso, se generan el access token (15 min) y el refresh token (7 días). El refresh token se persiste en la tabla refresh_tokens con fecha de expiración y ambos tokens se entregan al navegador en cookies httpOnly.
6. Se actualiza lastLogin del usuario y se incrementan las métricas de Prometheus correspondientes.
7. La respuesta conserva tokens en el cuerpo sólo por compatibilidad con clientes legados. El frontend vigente los ignora, usa withCredentials y guarda únicamente el objeto user para presentar la sesión.

Renovación de token (Refresh)

1. El cliente (frontend con Axios) detecta una respuesta 401 con el access token expirado.
2. El interceptor de Axios llama automáticamente a POST /api/v1/auth/refresh; la cookie httpOnly viaja con withCredentials, sin leer el token desde JavaScript.
3. El backend verifica firma, persistencia, vencimiento, revocación y estado del usuario.
4. Si todo es válido, rota en forma atómica access y refresh, revoca el refresh anterior y renueva las cookies. Un reuso de un refresh ya rotado revoca las sesiones activas del usuario y exige volver a iniciar sesión.
5. El interceptor reintenta el request original con las cookies nuevas. Una carrera simultánea de refresh devuelve un conflicto recuperable; un token inválido, vencido o comprometido termina la sesión.

Evidencia visual: No aplica. El refresh es transparente y no tiene pantalla propia; se valida con pruebas de rotación, reuso y carrera concurrente.

Logout

1. El usuario hace clic en Cerrar Sesión en el menú de usuario.
2. El frontend envía POST /api/v1/auth/logout con las cookies de sesión.
3. El backend marca el refresh token como revocado y conserva su trazabilidad; repetir el logout no falla.
4. El frontend borra el estado de autenticación en Zustand (authStore) y redirige al login.

Prueba asistida de usuario

1. El operador autorizado navega a Usuarios → [usuario objetivo] → Iniciar Vista Como.
2. El frontend llama a POST /api/v1/auth/impersonate/:userId.
3. El sistema verifica que el rol del solicitante esté incluido en la política de prueba asistida y que conserve la capacidad de escritura asistida.
4. Se genera un access token especial con isImpersonating, impersonatedBy, canWriteWhileImpersonating e impersonationMode. No se emite refresh token para esta sesión.
5. El audit log registra la acción IMPERSONATE_USER con IP y User-Agent.
6. El frontend muestra un banner visual de advertencia ("Estás viendo como [nombre del usuario]") durante toda la sesión.
7. Las escrituras sólo se admiten donde la ruta y las capacidades del operador las autorizan. Las rutas protegidas con blockIfImpersonating() responden 403 read-only incluso durante una prueba asistida.
8. Para terminar, el operador hace clic en Volver a mi cuenta (POST /api/v1/auth/stop-impersonation). El sistema genera tokens normales para el operador original y registra STOP_IMPERSONATION.

Cambio de contraseña

1. El usuario autenticado navega a Mi Perfil → Cambiar Contraseña.
2. Ingresa la contraseña actual y la nueva contraseña (mínimo 8 caracteres).
3. El sistema verifica la contraseña actual con bcrypt.compare antes de actualizar.
4. El hash de la nueva contraseña se genera con bcrypt (rondas configurables, por defecto 10).

Cuando el acceso fue emitido por Resetear y enviar acceso, la sesión queda marcada como temporal. Hasta completar este formulario, el frontend redirige a esta pantalla y el backend rechaza las demás operaciones con PASSWORD_CHANGE_REQUIRED. La contraseña temporal nunca se expone al operador ni se imprime en logs; al cambiarla se limpia la marca y se revocan las demás sesiones activas.

Recuperación de contraseña

1. En el login, el usuario abre Olvidé mi contraseña e informa su email.
2. PSICOLE responde siempre con el mismo mensaje, exista o no una cuenta activa, para evitar la enumeración de usuarios.
3. Si la compuerta dedicada de correo y el destinatario están habilitados en producción, se envía un enlace a /reset-password válido por una hora.
4. El enlace usa el dominio configurado específicamente para recuperación o, en su defecto, el frontend del mismo entorno.

En Sandbox no se entrega el enlace: el intento queda auditado como bloqueado. La interfaz no debe afirmar que hubo entrega real. Ver la matriz operativa de correo.

Evidencia visual pendiente. No hay un par sanitizado de las vistas de solicitud y restablecimiento; la compuerta y la expiración son controles de backend y se documentan como NO_UI hasta completar ese par.

Campos y validaciones

Reglas de negocio

Orígenes confiables y aislamiento por entorno

Las solicitudes de navegador con credenciales se aceptan únicamente si su Origin coincide exactamente con la lista de CORS_ORIGINS, separada por comas. CORS_ORIGIN se conserva como respaldo para configuraciones legadas. No se usa * junto con cookies.

• Sandbox declara sólo su propio origen. No se deben agregar dominios productivos a esa lista.
• El entorno PSICOLE declara su aplicación y el origen web autorizado para el puente puntual con el sitio institucional.
• Los clientes servidor a servidor que no envían Origin pueden continuar; su autenticación y autorización se validan por el contrato de cada endpoint.

El acceso desde WordPress es un redirect al login de PSICOLE. No es SSO: no comparte usuarios, tokens ni sesión con WordPress. La inclusión del origen institucional en producción habilita únicamente el puente previsto, por ejemplo el cierre de sesión desde el menú, y no debe copiarse a Sandbox.

Evidencia visual: No aplica. Es configuración de borde y middleware; se valida por origen permitido/rechazado y por composición separada de cada entorno.

Protección CSRF de doble envío

En login y refresh el backend rota una cookie csrfToken legible por el frontend. Para cada mutación autenticada mediante cookies, Axios refleja ese valor en X-CSRF-Token; el servidor exige que cookie y header coincidan.

Los métodos seguros y los endpoints preautenticación definidos de forma exacta tienen excepción. El bypass de /api/v1/auth/logout no cubre variantes como /api/v1/auth/logout-all-devices, que siguen protegidas. Las rutas públicas y webhooks tienen sus controles específicos; una petición Bearer pura o sin cookie de acceso no es susceptible a CSRF, aunque continúa sujeta a autenticación, autorización y validación de entrada.

Evidencia visual: No aplica. El control no tiene pantalla propia; se prueba con combinaciones de cookie/header válidas, ausentes y distintas.

Estados y transiciones

stateDiagram-v2
    [*] --> Anónimo
    Anónimo --> Autenticado : login exitoso
    Autenticado --> Anónimo : logout / token expirado sin refresh válido
    Autenticado --> Renovando : access token expirado
    Renovando --> Autenticado : refresh válido → access y refresh rotados
    Renovando --> Anónimo : refresh inválido o expirado
    Autenticado --> Impersonando : ADMIN inicia impersonación
    Impersonando --> Autenticado : stop-impersonation (vuelve al admin)
    Impersonando --> Anónimo : access token expirado (sin refresh)

Errores frecuentes

Preguntas frecuentes

¿Qué pasa si el access token expira mientras el usuario está usando el sistema? El interceptor de Axios detecta la respuesta 401 y llama automáticamente al endpoint de refresh con la cookie httpOnly. Si el refresh es válido, rota ambas credenciales y el usuario no nota la interrupción. Si el refresh venció o fue revocado, el usuario vuelve al login.

¿Los refresh tokens se invalidan al cambiar la contraseña? Sí. El cambio de contraseña revoca los refresh activos de los demás dispositivos y conserva la sesión actual cuando puede identificar su token. Para una sospecha de compromiso, Cerrar sesión en todos los dispositivos revoca todos los refresh activos.

¿Qué información queda registrada en el audit log? Cada prueba asistida registra al operador real, al usuario objetivo, el modo y la capacidad de escritura, además de IP y User-Agent. Las acciones IMPERSONATE_USER y STOP_IMPERSONATION son rastreables en Administración → Audit Log.

¿Puede un operador tener acceso a varios módulos? Sí. Un operador con rol genérico puede recibir asignaciones de módulos (OperatorModuleAssignment) que le otorgan acceso a EPICs específicos. El middleware requireModuleAccess verifica estas asignaciones en tiempo real contra la base de datos.

¿Cómo se crean los usuarios iniciales? El seed de base de datos (npm run db:seed) crea los roles del sistema y un usuario ADMIN inicial. Los demás usuarios se crean desde Administración → Usuarios o, en el caso de aspirantes, mediante el registro público en el formulario de solicitud de matrícula.

🖥 Escritorio Formulario multi-paso de solicitud de matrícula

📱 Móvil Formulario multi-paso de solicitud de matrícula

Solicitud de Matrícula

Descripción

El módulo de Solicitud de Matrícula implementa el proceso de onboarding de nuevos profesionales (UC-1.1). Un aspirante que desea colegiarse puede completar todo el trámite de forma digital, sin necesidad de concurrir físicamente al Colegio en la etapa inicial. El proceso está estructurado en un formulario multi-paso de 5 pasos con guardado automático de progreso: el aspirante puede cerrar la sesión y retomar desde el punto en que quedó.

El flujo comienza con la creación de una cuenta de usuario con rol ASPIRANTE y la verificación del email mediante un token de 24 horas. A continuación, el aspirante completa sus datos personales, académicos, carga los documentos requeridos (DNI frente/dorso, título universitario, analítico), firma la declaración jurada y abona el arancel de inscripción para enviar la solicitud. El sistema asigna un número de solicitud único con formato SOL-YYYY-XXXXXXXX.

Una vez enviada la solicitud, su estado pasa a PENDING_REVIEW y queda disponible en la bandeja de trabajo de los operadores de matrículas para su revisión. El aspirante puede consultar el estado de su solicitud en cualquier momento desde su portal de autogestión y recibe notificaciones por email ante cada cambio de estado.

Roles con acceso

Flujo principal

Paso 0 — Registro de cuenta y verificación de email

1. El aspirante accede a la URL pública de registro (/registro) e ingresa email, contraseña (mínimo 8 caracteres), nombre y apellido.
2. El sistema crea el usuario con rol ASPIRANTE y la solicitud en estado DRAFT en paso 1.
3. Se envía un email con un enlace de verificación válido por 24 horas.
4. El aspirante hace clic en el enlace (GET /api/v1/enrollment-application/verify-email/:token).
5. El sistema marca emailVerified = true y emite tokens de acceso (access + refresh) para que el aspirante continúe directamente al formulario.
6. Si el enlace venció, el aspirante puede solicitar uno nuevo desde la pantalla de login con "Reenviar verificación".

Paso 1 — Datos personales

1. El aspirante completa los datos personales obligatorios: nombre, apellido, DNI (tipo: DNI/LC/LE/Pasaporte), CUIT/CUIL, teléfono, fecha de nacimiento, género, nacionalidad y domicilio completo (calle, número, piso, departamento, código postal, ciudad, provincia).
2. El sistema valida el dígito verificador del CUIT/CUIL con el algoritmo oficial argentino.
3. Se verifica la unicidad de DNI y CUIT/CUIL contra todos los usuarios existentes.
4. El aspirante puede declarar el tipo de solicitud: PROVISORIA (título en trámite de legalización) o DEFINITIVA (título ya legalizado).
5. Al guardar, el paso avanza a 2 y los datos quedan persistidos aunque el aspirante cierre la sesión.

Paso 2 — Datos académicos

1. El aspirante ingresa: nombre de la universidad, fecha de egreso, título obtenido (ej: Licenciado en Psicología) y especialidades (selección múltiple).
2. Todos los campos son obligatorios excepto especialidades.
3. El sistema actualiza el paso a 3 al guardar exitosamente.

Paso 3 — Carga de documentos

1. El aspirante sube los archivos requeridos. Formatos aceptados: PDF, JPEG, PNG. Tamaño máximo operativo compartido: 13 MB por archivo.
2. Documentos obligatorios (sin estos no se puede enviar la solicitud):
   • DNI_FRONT — Frente del DNI
   • DNI_BACK — Dorso del DNI
   • UNIVERSITY_DEGREE — Título universitario o constancia de tramitación
   • ACADEMIC_TRANSCRIPT — Analítico de materias aprobadas
3. Documentos opcionales:
   • CRIMINAL_RECORD — Certificado de antecedentes penales
   • GOOD_CONDUCT — Certificado de buena conducta
   • PHOTO — Foto tipo carnet
   • OTHER — Documentación adicional
4. Cada documento subido queda asociado a la solicitud con su tipo, nombre original, tamaño y fecha de carga.
5. La pantalla muestra el estado de cada documento requerido (subido / pendiente) y resalta los faltantes.

Paso 4 — Declaración jurada y consentimiento

1. El sistema muestra el texto vigente de la declaración jurada de veracidad de datos y la política de privacidad.
2. El aspirante debe tildar explícitamente los checkboxes de aceptación antes de continuar.
3. Se registra la fecha y hora de aceptación.

El mismo texto se comparte con Renovación de Matrícula y puede ser actualizado desde la operación administrativa sin tocar código.

Paso 5 — Pago del arancel y envío

1. El sistema calcula el arancel de inscripción según el tipo de solicitud y muestra una boleta con número único (BOL-YYYYMM-XXXXXX).
2. El aspirante puede abonar online mediante la pasarela habilitada o presencialmente; en ese caso un operador confirmará el pago manualmente.
3. Una vez confirmado el pago, el estado de la solicitud cambia a PENDING_REVIEW y el aspirante recibe un email de confirmación con el número de solicitud.
4. La solicitud queda disponible en la bandeja de trabajo de los operadores de matrículas.

Consulta de estado (vista del aspirante)

1. El aspirante autenticado accede a Mi Solicitud desde su panel.
2. Ve el estado actual, el número de solicitud, la fecha de envío y el historial de cambios de estado con comentarios del operador.
3. Si el estado es REQUIRES_CHANGES, puede ver las observaciones del operador y subir los documentos corregidos.

Altas registradas en el padrón

El panel administrativo existente de Solicitudes de Matrícula (/admin/enrollment-applications) permite alternar entre:

Esto permite consultar altas anteriores sin inventar una solicitud retroactiva. Si la matrícula formal está APPROVED, se muestra como aprobada porque ese es el estado vigente del profesional, no una inferencia a partir de un PDF o de un formulario histórico.

Campos y validaciones

Reglas de negocio

Estados y transiciones

stateDiagram-v2
    [*] --> DRAFT : registro exitoso
    DRAFT --> DRAFT : completando pasos 1-4
    DRAFT --> PENDING_PAYMENT : formulario completo, esperando pago
    PENDING_PAYMENT --> PENDING_REVIEW : pago confirmado (online o manual)
    PENDING_REVIEW --> UNDER_REVIEW : operador toma la solicitud
    UNDER_REVIEW --> REQUIRES_CHANGES : operador solicita correcciones
    REQUIRES_CHANGES --> UNDER_REVIEW : aspirante sube documentos corregidos
    UNDER_REVIEW --> INTERNALLY_APPROVED : aprobación interna → matrícula provisoria
    UNDER_REVIEW --> REJECTED : rechazo definitivo
    INTERNALLY_APPROVED --> PENDING_MINISTRY : se eleva al Ministerio de Salud
    PENDING_MINISTRY --> APPROVED : aprobación ministerial → colegiado definitivo
    PENDING_MINISTRY --> REJECTED : rechazo ministerial

Errores frecuentes

Preguntas frecuentes

¿Puedo modificar los datos después de enviar la solicitud? Una vez enviada (estado PENDING_REVIEW), los datos ya no se pueden modificar directamente. Si el operador detecta un error, puede cambiar el estado a REQUIRES_CHANGES para que el aspirante corrija los documentos. Los datos personales solo se modifican mediante una solicitud formal al operador.

¿Qué significa solicitud de tipo PROVISORIA vs DEFINITIVA? PROVISORIA es para quienes tienen el título pero aún no han completado el trámite de legalización ante el Ministerio de Salud. DEFINITIVA es para quienes ya tienen el título debidamente apostillado o legalizado. Ambas pueden presentarse; la diferencia afecta el flujo de aprobación ministerial posterior.

¿Cuánto tiempo tengo para completar el formulario? No hay límite de tiempo para completar los pasos del formulario (la solicitud permanece en DRAFT indefinidamente). El único vencimiento es el token de verificación de email (24 horas) y la preferencia de pago online si se genera (24 horas).

¿Cómo sé si mi solicitud fue recibida correctamente? Recibirás un email de confirmación con el número de solicitud (SOL-YYYY-XXXXXXXX) cuando el pago sea confirmado y la solicitud pase a PENDING_REVIEW. También podés consultar el estado en cualquier momento desde tu portal.

¿Puedo subir más de un archivo por tipo de documento? No. Cada tipo de documento admite un solo archivo. Si necesitás reemplazar un documento ya subido, deberás subir el nuevo archivo para el mismo tipo, que sobreescribirá el anterior.

🖥 Escritorio Gestión y revisión de solicitudes de matrícula

📱 Móvil Gestión y revisión de solicitudes de matrícula

Gestión de Matrículas

Descripción

El módulo de Gestión de Matrículas (UC-1.2) es el espacio de trabajo de los operadores y administradores para revisar, aprobar, rechazar y administrar las matrículas de los psicólogos colegiados. Centraliza el ciclo de vida completo de la matrícula: desde la solicitud inicial enviada por el aspirante hasta la emisión del certificado ministerial y la credencial digital con QR.

El proceso de aprobación tiene dos fases diferenciadas: una interna del Colegio (revisión documental y aprobación con asignación de número de matrícula provisoria) y una externa (presentación ante el Ministerio de Salud y aprobación de la matrícula definitiva). La fase interna habilita al profesional a ejercer con matrícula provisoria; la fase externa le otorga la matrícula definitiva con número correlativo definitivo. Ambas fases generan documentación oficial en PDF.

Adicionalmente, el módulo gestiona modificaciones de datos solicitadas por colegiados, suspensiones y reactivaciones de matrícula, y el historial completo de cambios de estado con auditoría. La credencial digital del profesional (generada con QRCode y verificable en una URL pública) se emite automáticamente al completar la matrícula definitiva.

Roles con acceso

Flujo principal

Revisión de solicitudes (bandeja de trabajo)

1. El operador accede a Matrículas → Solicitudes Pendientes. La bandeja muestra todas las solicitudes en estado PENDING_REVIEW y UNDER_REVIEW, ordenadas por fecha de envío.
2. Cada fila muestra: número de solicitud, nombre del aspirante, tipo de solicitud (PROVISORIA / DEFINITIVA), fecha de envío y días transcurridos.
3. El operador abre la solicitud haciendo clic en su número para ver el detalle completo: datos personales, datos académicos, documentos adjuntos y estado del pago del arancel.
4. Antes de emitir matrícula, el operador autorizado puede usar Editar datos en la ficha para corregir identidad o contacto. PSICOLE valida email, DNI y CUIT/CUIL únicos, evita pisar cambios concurrentes y registra la corrección en Auditoría. Esta acción no altera pagos, documentos ni estados.
5. Si toma la solicitud para revisión, el estado cambia a UNDER_REVIEW y queda asociada a ese operador.
6. El operador visualiza cada documento en el visor integrado (PDF inline o previsualización de imagen).

Vista auditada desktop y mobile

La bandeja de Solicitudes de Matrícula fue recapturada luego de ajustar cabecera, acciones y modal de documentos. En móvil, las acciones superiores se organizan en grilla, el modal usa el ancho disponible y la carga de documentos evita desbordes laterales.

Carga manual administrativa de solicitud

Cuando una solicitud debe iniciarse desde administración, el operador puede usar Cargar solicitud manual dentro de Matrículas → Solicitudes.

El sistema crea:

• usuario aspirante verificado;
• solicitud en estado PENDING_REVIEW;
• historial de acción administrativa;
• registro de auditoría MANUAL_ADMIN_CREATED.

La solicitud manual no saltea el circuito de revisión. Luego continúa por aprobación interna, correcciones, rechazo o aprobación definitiva según corresponda.

Aprobación interna — Matrícula Provisoria (Fase 1)

1. Luego de revisar la documentación, el operador hace clic en Aprobar Internamente.
2. El sistema genera automáticamente un número de matrícula provisoria (provisionalNumber) con formato correlativo.
3. El estado de la solicitud pasa a INTERNALLY_APPROVED y el estado del profesional a PROVISIONAL.
4. Se genera el certificado para el Ministerio de Salud en PDF (usando PDFKit) con los datos del profesional y el número de matrícula provisoria.
5. El operador descarga el PDF ministerial para presentarlo ante el organismo correspondiente.
6. Se envía un email al aspirante notificando que su solicitud fue aprobada internamente y que se encuentra en trámite ante el Ministerio.

Solicitud de correcciones

1. Si la documentación es incompleta o incorrecta, el operador hace clic en Solicitar Correcciones.
2. Ingresa un comentario detallando qué documentos o datos deben corregirse.
3. El estado cambia a REQUIRES_CHANGES y se envía un email al aspirante con las observaciones.
4. El aspirante puede subir los documentos corregidos desde su portal. Al hacerlo, el estado vuelve a UNDER_REVIEW.

Rechazo de solicitud

1. Si la solicitud no cumple los requisitos y no es subsanable, el operador hace clic en Rechazar.
2. Ingresa el motivo del rechazo (obligatorio).
3. El estado cambia a REJECTED y se envía un email al aspirante con el motivo.
4. El arancel abonado queda registrado para gestión de devolución manual (no se devuelve automáticamente).

Aprobación definitiva — Matrícula Definitiva (Fase 2 — respuesta del Ministerio)

1. Una vez recibida la resolución ministerial de aprobación, el operador registra la respuesta en el sistema.
2. Ingresa el número de matrícula definitivo asignado por el Ministerio de Salud.
3. El sistema actualiza el estado de la solicitud a APPROVED y el estado del profesional a APPROVED.
4. Se genera la credencial digital del profesional:
   • Se crea un código QR único (PSICOLE-XXXXXXXXXXXXXXXX) asociado al profesional.
   • El QR apunta a la URL pública de verificación: {FRONTEND_URL}/verificar/{qrCode}.
   • El PDF de credencial digital se genera con PDFKit incluyendo foto, datos, número de matrícula y QR.
5. El profesional recibe un email con el enlace para descargar su credencial y con acceso a su portal de colegiado.
6. El rol del usuario cambia de ASPIRANTE a COLEGIADO y se habilita su acceso completo al sistema.

Verificación pública de credencial (QR)

1. Cualquier persona puede escanear el QR de la credencial del profesional con su teléfono.
2. Es redirigido a la URL pública {FRONTEND_URL}/verificar/{qrCode} (no requiere autenticación).
3. El sistema verifica el código QR y muestra los datos públicos del profesional: nombre, número de matrícula, estado (activo / suspendido), especialidades declaradas y fecha de vencimiento si aplica.

Renovación completada con originales presenciales

En una renovación, si parte de la documentación obligatoria fue presentada físicamente y no existe archivo digital, el operador puede elegir Constatar originales presenciales.

• Primero debe validar todos los archivos digitales que sí existan; una constancia nunca oculta un archivo pendiente o rechazado.
• Debe dejar una declaración de al menos 20 caracteres y, si corresponde, la referencia de expediente, libro o ticket.
• El sistema registra operador, fecha, documentos digitales aprobados y tipos faltantes cubiertos por los originales.
• No se crean adjuntos ficticios. La boleta y la aprobación vuelven a validar esta evidencia bajo bloqueo transaccional.
• La constancia no acredita el arancel ni aprueba por sí sola la renovación.

Gestión de profesionales matriculados

1. El operador accede a Matrículas → Profesionales para ver el padrón completo.
2. Puede filtrar por estado de matrícula, tipo (colegiado / prestador / aspirante), estado de pago, beneficio activo, plan de pago y búsqueda por nombre, DNI o número de matrícula.
3. Desde el detalle de cada profesional puede:
   • Ver su ficha completa (datos personales, académicos, financieros).
   • Suspender la matrícula (estado SUSPENDED) por sanción o deuda.
   • Reactivar una matrícula suspendida.
   • Registrar el fallecimiento (estado DECEASED) para casos migrados del sistema legacy.
   • Iniciar el proceso de baja voluntaria (DISCHARGED).

Filtros financieros disponibles desde el padrón:

Padrón profesional auditado

La lista de profesionales se validó como parte del barrido visual para asegurar que búsqueda, filtros y acciones no queden fuera del viewport en pantallas chicas.

Aprobación de solicitudes de modificación de datos

1. Cuando un colegiado solicita un cambio de datos desde su portal (dirección, teléfono, especialidades, etc.), el operador recibe una notificación en Matrículas → Modificaciones Pendientes.
2. El operador revisa los datos actuales vs. los datos propuestos.
3. Puede aprobar (los datos se actualizan en el sistema) o rechazar con un comentario.
4. El colegiado recibe un email con la resolución.

Campos y validaciones

Reglas de negocio

Archivo histórico de trámites

Los adjuntos históricos se incorporan en etapas para que un PDF no termine en el perfil equivocado ni cambie por sí solo un estado de matrícula o de cobro.

El inventario de respaldo es una fuente documental, no una orden de cambio. El primer corte operativo abarca 2025 y 2026 y se controla antes de extraer archivos: el inventario del 24/07/2026 registró 3.696 adjuntos privados (2.608 renovaciones, 832 débitos automáticos y el resto de otros trámites).

1. Se inventaría cada ZIP por archivo, fecha interna, tamaño, tipo de trámite y huella de archivo fuente. Esta etapa no toca la base ni copia documentos.
2. El vínculo exige matrícula, DNI/CUIT o referencia de solicitud verificable. El nombre de archivo, una carpeta o un importe aislado nunca bastan.
3. Si existe la solicitud correspondiente, el archivo se asocia a ese trámite; si no existe, puede quedar como documento privado OTHER del profesional con el origen histórico claramente indicado.
4. Los casos sin identidad única, fechas incompatibles o documentos duplicados pasan a revisión. No se crean solicitudes, renovaciones, pagos, beneficios ni cambios de vigencia por el solo hecho de importar un adjunto.
5. La repetición usa huella de origen y hash del contenido: un replay conserva el mismo registro sin duplicar archivos ni auditorías.

Desde el corte 2025-2026, cada respuesta que coincide de forma exacta por matrícula y DNI se expone en el perfil administrativo del profesional, en la pestaña Trámites → Antecedentes Históricos de Trámites. La fila indica fecha, tipo de trámite, planilla origen y cantidad de adjuntos declarada. No cambia el estado de una matrícula, beneficio, deuda o ticket.

La persona titular consulta los mismos antecedentes desde el flujo existente Mis Trámites → Historial. Allí puede contrastar el trámite informado y, cuando el vínculo físico fue verificado, abrir su adjunto privado. Esta consulta no habilita cambios de estado ni confirma una renovación por sí sola.

Un adjunto declarado puede quedar como pendiente de enlace exacto: significa que existe en la respuesta de formulario, pero todavía no reunió evidencia suficiente para asociarlo al perfil. El nombre aislado nunca basta. Un PDF o imagen física se incorpora sólo cuando coinciden: identidad exacta declarada en Forms, campo de adjunto, carpeta del trámite, nombre completo como evidencia auxiliar, archivo físico único, fecha compatible y DNI encontrado en el contenido mediante extracción de texto u OCR. Antes de copiarlo se verifica su hash SHA-256 y la repetición conserva el mismo vínculo sin duplicar el archivo. Los adjuntos verificados quedan privados y se consultan desde Trámites → Antecedentes Históricos de Trámites. Los casos que no superan todos esos controles permanecen pendientes de verificación; no se fuerzan por parecido de nombre ni se usan para aprobar renovaciones. La ampliación a años anteriores se habilita únicamente cuando el lote 2025-2026 haya pasado el mismo control de identidad, integridad de archivo e idempotencia.

La vigencia de la credencial tiene una fuente distinta y explícita: una renovación aprobada dentro del sistema o el padrón oficial certificado.

Reciprocidad visible en la ficha profesional

La pestaña existente Profesionales → perfil → Trámites reúne tres clases de evidencia sin cambiar sus estados: antecedentes históricos verificados, solicitudes de matrícula y tickets administrativos o de soporte. Cuando el registro tiene un archivo físico, la misma fila ofrece Adjuntos y lo abre mediante una descarga autenticada. La ficha no expone rutas privadas del servidor.

La ausencia de un botón de archivo significa que ese registro no tiene un documento físico vinculado; no debe reemplazarse con otro PDF por semejanza de nombre. Del mismo modo, visualizar un adjunto demuestra recepción o preservación documental, pero no convierte una solicitud en aprobada, no renueva la matrícula y no activa un beneficio.

El control repetible npm run audit:profile-document-reciprocity contrasta archivo físico, propietario, registro canónico y superficie de perfil. Es de sólo lectura y falla si encuentra archivos faltantes, identidades huérfanas o una ruptura económica en la cadena de prestadores. Una respuesta histórica, aun cuando declara un comprobante, acredita una presentación y no aprueba ni modifica una matrícula por sí misma. La auditoría audit-historical-procedure-reciprocity.mjs clasifica cada renovación contra esa vigencia sin escribir datos: sólo un ciclo sistémico verificable puede considerarse vínculo exacto; el padrón vigente se expone como certificación de vigencia actual y el resto permanece como antecedente o revisión de evidencia.

La vigencia de la credencial tiene una fuente distinta y explícita: una renovación aprobada dentro del sistema o el padrón oficial certificado. Una respuesta histórica, aun cuando declara un comprobante, acredita una presentación y no aprueba ni modifica una matrícula por sí misma. La auditoría audit-historical-procedure-reciprocity.mjs clasifica cada renovación contra esa vigencia sin escribir datos: sólo un ciclo sistémico verificable puede considerarse vínculo exacto; el padrón vigente se expone como certificación de vigencia actual y el resto permanece como antecedente o revisión de evidencia.

Estados y transiciones

stateDiagram-v2
    [*] --> PENDING : solicitud enviada y pagada
    PENDING --> PROVISIONAL : aprobación interna del Colegio
    PENDING --> REJECTED : rechazo definitivo
    PROVISIONAL --> APPROVED : aprobación ministerial + número definitivo
    PROVISIONAL --> REJECTED : rechazo ministerial
    APPROVED --> SUSPENDED : suspensión por sanción o deuda
    SUSPENDED --> APPROVED : reactivación por operador
    APPROVED --> DISCHARGED : baja voluntaria o definitiva
    SUSPENDED --> DISCHARGED : baja estando suspendido
    APPROVED --> DECEASED : fallecimiento (legacy)

Leyenda de estados del profesional:

Errores frecuentes

Preguntas frecuentes

¿Cuánto tiempo queda en estado PROVISORIA una matrícula? Una provisoria nueva tiene un vencimiento oficial de 18 meses desde Matrícula desde, salvo que el padrón indique otra fecha. El estado PROVISIONAL persiste hasta que el operador registre la respuesta del Ministerio, pero la credencial deja de estar vigente al superar Matrícula hasta. Desde 90 días antes la agenda orienta a completar el pase a definitiva; no ofrece renovación quinquenal.

¿Un profesional con matrícula PROVISORIA puede pagar cuotas? Sí. Las cuotas se generan automáticamente para todos los profesionales con estado PROVISIONAL o APPROVED según la configuración del tipo de cuota. El tipo de cuota a aplicar (mensual novel, mensual plena) depende de los atributos del profesional configurados en el FeeType.

¿Qué datos son públicos en la verificación por QR? La URL de verificación pública muestra únicamente: nombre completo, número de matrícula, estado de la matrícula, especialidades declaradas y, si aplica, fecha de vencimiento. No muestra DNI, CUIT, dirección ni datos financieros.

¿Puede el aspirante subir más documentos después de que el operador solicite correcciones? Sí. Cuando el estado es REQUIRES_CHANGES, el aspirante puede subir nuevos archivos para los tipos de documentos observados. Al guardar, el estado vuelve automáticamente a UNDER_REVIEW y el operador recibe una notificación.

¿Cómo se maneja una baja voluntaria? El operador inicia el proceso desde Profesionales → [profesional] → Registrar Baja. Se registra la fecha de baja, el motivo y el estado pasa a DISCHARGED. Las deudas pendientes al momento de la baja quedan registradas para gestión de cobro posterior. El usuario conserva acceso al sistema solo para consultar su historial.

Renovación de Matrícula

Las matrículas definitivas se renuevan en ciclos de 5 años. Las provisorias nuevas tienen una vigencia de 18 meses, pero no ingresan al trámite quinquenal: antes de vencer deben completar el pase a matrícula definitiva. La fecha que figura como Vigente hasta en la credencial es el vencimiento oficial registrado por el Colegio: no se reemplaza ni se extiende automáticamente por un cálculo estimado. El proceso de renovación es digital, con firma de Declaración Jurada y documentación respaldatoria.

Las cuatro fechas profesionales

Estas fechas tienen significados distintos y se exportan en columnas separadas:

El padrón oficial, una aprobación de alta, una renovación aprobada o una corrección administrativa auditada son fuentes válidas de vigencia. Si el vencimiento no tiene una fuente verificable, el sistema no habilita una nueva renovación hasta que Matrículas corrija el dato.

En el padrón, Matrícula desde y Matrícula hasta describen el registro de vigencia actualmente informado; no son la antigüedad histórica. La aprobación definitiva inicia su propio registro de vigencia. Para altas nuevas, la matrícula provisoria vence a los 18 meses y la definitiva vence en el cumpleaños del quinto año calendario contado desde su inicio. Una renovación conserva el día y mes del vencimiento oficial anterior y lo avanza cinco años. Si el padrón informa una fecha distinta, prevalece la fecha oficial del padrón y la diferencia queda auditada.

Certificación contra el padrón

La sincronización del padrón usa matrícula + DNI exactos para aplicar una vigencia automáticamente. CUIT y correo se usan como guardas contra perfiles duplicados, no como permiso suficiente para actualizar una matrícula.

• Una fila activa y exacta puede corregir la vigencia y avanzar un vencimiento histórico por ciclos quinquenales con confirmación explícita.
• Una baja, cancelación, fallecimiento o suspensión sólo se aplica cuando la fuente oficial lo informa expresamente para la identidad exacta.
• La mora no cambia el estado de matrícula: un profesional moroso puede seguir vigente y conservar su deuda.
• La ausencia en un archivo no implica baja. El registro queda en revisión hasta contar con evidencia oficial.
• El acceso de la cuenta es independiente de la vigencia profesional. La certificación no activa ni desactiva usuarios.
• Coincidencias parciales, cronologías inválidas, matrículas faltantes, semillas de prueba y CUIT/correos ya vinculados se aíslan en una cola de revisión; nunca se completan por inferencia.

El replay debe producir cero cambios. La certificación tampoco genera cuotas, pagos, recibos, operaciones, correos, notificaciones ni mensajes internos.

Antecedentes históricos 2025-2026

Cuando un formulario histórico coincide por matrícula y DNI, se muestra en el perfil administrativo del profesional, en Trámites → Antecedentes Históricos de Trámites. Esta sección permite revisar fecha, tipo de trámite, planilla de origen y cantidad de adjuntos declarados sin crear un ticket ni reescribir el expediente vigente.

En esa misma pestaña se distingue la vigencia formal actual de la presentación histórica. La fecha de la credencial sólo puede provenir de una renovación APPROVED o del padrón oficial certificado; un formulario histórico no equivale a una aprobación. Cuando el archivo ZIP no preserva el ID de Drive o una huella que permita identificar el PDF, el adjunto se muestra como pendiente de enlace exacto y no se asocia por nombre, monto o fecha.

Evidencia visual: No aplica. La lista contiene DNI, correo y referencias a documentos privados; no se publican capturas. La comprobación se realiza en SANDBOX con un perfil autorizado y la auditoría de reciprocidad de sólo lectura.

Flujo completo

Colegiado inicia solicitud
       ↓
Firma Declaración Jurada (obligatorio)
       ↓
Adjunta documentos (opcional)
       ↓
Genera boleta de renovación (sin vencimiento)
       ↓
Transfiere y adjunta comprobante
       ↓
Envía al Colegio → PENDING_REVIEW
       ↓
Finanzas acredita el importe exacto y emite recibo
       ↓
Operador de Matrículas revisa
    ↙         ↘
APPROVED    REQUIRES_CHANGES / REJECTED
    ↓               ↓
Nueva fecha     Colegiado corrige
de vencimiento  y reenvía

Vista del Colegiado

Acceso desde Mi Cuenta → Renovación de Matrícula (/my-matricula-renewal).

Verificar elegibilidad

Al ingresar, la pantalla muestra el estado de la matrícula:

Reglas previas al vencimiento

Los recordatorios 90/30 son elementos de agenda dentro del sistema. Este flujo no envía por sí solo correos automáticos de vencimiento.

Para una matrícula provisoria se usan los mismos umbrales 90/30/0, pero la acción de agenda es Completar matrícula definitiva y abre la solicitud de matrícula. No se ofrece una renovación quinquenal de una provisoria.

Paso 1 — Declaración Jurada

El colegiado debe:

1. Leer el texto vigente de la Declaración Jurada.
2. Marcar el checkbox "Leí y acepto la Declaración Jurada".
3. Hacer clic en "Firmar y continuar".

El texto de esta Declaración Jurada es compartido con la Solicitud de Matrícula inicial y se administra desde la operación interna del Colegio.

Paso 2 — Documentación

La renovación controla cinco tipos de documentación:

• DNI frente.
• DNI dorso.
• Constancia de CUIT/CUIL.
• Certificado de antecedentes penales.
• Foto digital.

Los archivos digitales admitidos se revisan individualmente. Un archivo pendiente, rechazado, vacío o no recuperable debe validarse o volver a cargarse; no puede ocultarse mediante una nota administrativa.

Paso 3 — Boleta, pago y recibo

El botón Generar boleta de pago crea una boleta real para la solicitud. El importe se toma exclusivamente del arancel activo MATRICULA_RENOVACION. Si esa configuración no existe, el sistema no supone un monto ni reutiliza el arancel de reinscripción.

La boleta conserva el importe y la cuenta bancaria informados al emitirla, muestra el concepto Renovación de matrícula y no tiene vencimiento. En este paso todavía no se crean pago, recibo, deuda ni movimientos de cuenta.

Después de transferir, el colegiado adjunta el comprobante e informa fecha y referencia. Finanzas revisa esa evidencia o el movimiento bancario y confirma el importe acreditado. Sólo si coincide exactamente con la boleta se registran en una única operación el pago, los movimientos compensados y el recibo con concepto RENOVACION. El recibo queda disponible para descarga después de esa acreditación.

Paso 4 — Confirmación y envío

Muestra un resumen antes de enviar:

Al hacer clic en "Enviar al Colegio" la solicitud pasa a estado PENDING_REVIEW.

Estados de la solicitud

Si el operador solicita correcciones:

El colegiado recibe un email con las observaciones. Al ingresar, la pantalla muestra el mensaje del operador y habilita los campos para corregir y reenviar.

Panel Administrativo

Acceso desde Matrículas → Renovaciones de Matrícula (/admin/matricula-renewal).

Estadísticas

El encabezado muestra:

Filtros

Historial en la misma bandeja

La pantalla administrativa de Renovaciones conserva un único listado y permite elegir el origen:

Los dos orígenes se consultan desde /admin/tramites/renovaciones; no existe una segunda pantalla ni se mezclan acciones operativas con evidencia. Un antecedente histórico puede confirmar que hubo presentación, pero no se marca como APPROVED ni modifica una fecha de vencimiento sin una renovación formal o padrón oficial certificado.

Acciones del operador

Desde el panel lateral de detalle de cada solicitud:

Cómo validar una renovación presencial

1. Abrir la renovación desde Matrículas → Renovaciones de Matrícula.
2. Revisar cada archivo digital existente y marcarlo como aprobado u observado.
3. Si faltan archivos porque los originales se presentaron en sede, elegir Constatar originales presenciales.
4. Describir qué originales se comprobaron, dónde y cuándo; agregar una referencia de expediente, libro o ticket cuando exista.
5. Confirmar la declaración con el usuario operador.
6. Continuar con boleta, acreditación y aprobación. Cada paso vuelve a validar la constancia y los documentos digitales bajo trazabilidad.

La constancia cubre únicamente tipos sin registro digital. Si existe un archivo pero está pendiente, rechazado o ilegible, el sistema mantiene el bloqueo y exige revisarlo o recargarlo.

Avisos y comunicaciones

• La agenda muestra el vencimiento desde 90 días antes y cambia su prioridad a alta cuando faltan 30 días.
• El badge de agenda cuenta el mismo evento una sola vez.
• Las comunicaciones sobre envío, aprobación, correcciones o rechazo dependen de la configuración general de notificaciones.
• Durante una operación en modo inerte no se envían correos ni avisos externos.
• La ausencia de un correo nunca modifica la vigencia ni el estado del trámite.

Débito Automático

El módulo de Débito Automático permite registrar un método de cobro mensual para las cuotas: CBU / COELSA o tarjeta de crédito. El descuento depende del método activo:

Las tarjetas de débito pueden existir como dato histórico, pero no se habilitan para nuevas adhesiones.

Vista del Colegiado

Acceso desde Mi Cuenta → Débito Automático (/my-direct-debit).

Vista en dispositivo móvil:

Adherirse al débito automático

1. Ingresar en "Mi Cuenta → Débito Automático".
2. Hacer clic en "Solicitar adhesión".
3. Completar el formulario:

1. Confirmar los datos y enviar.
2. La solicitud queda pendiente de activación por el Colegio.

Estados de la adhesión

Cambiar o cancelar el CBU

Para modificar el CBU: la pantalla permite ingresar uno nuevo. Esto genera una nueva solicitud de adhesión mientras el anterior permanece activo hasta que el nuevo sea procesado.

Para cancelar el débito: hacer clic en "Cancelar débito automático". Al cancelar, el descuento por método de cobro deja de aplicarse en el próximo período.

Panel Administrativo

Acceso principal desde Dinero → Operaciones → Débito Automático (/admin/dinero/operaciones?tool=debito).

Debito automatico en Operaciones de Dinero

La pantalla separa la gestión bancaria por CBU de la gestión de tarjetas:

Al seleccionar una adhesión, el panel de detalle muestra el profesional, matrícula, método registrado, CBU o tarjeta asociada, estado operativo, descuento aplicado y última vinculación técnica con la pasarela cuando corresponde.

Antecedentes históricos de adhesión

La pestaña Trámites de la ficha profesional también puede mostrar formularios históricos de débito automático y su adjunto privado. Estos antecedentes documentan una presentación y no activan, suspenden ni cancelan la adhesión operativa.

El vínculo físico exige una identidad única. La ruta principal usa matrícula y DNI; si el formulario no contiene DNI, se requieren simultáneamente matrícula y nombre completo en Forms, matrícula y los mismos componentes del nombre en el archivo, un único perfil compatible, carpeta y campo de origen exactos, archivo físico único y hash SHA-256 verificado. Un conflicto deja la pieza en revisión.

El corte SANDBOX del 27/07/2026 conserva 327 antecedentes de débito: 4 con archivo físico exacto y 323 pendientes de enlace exacto. Los cuatro vínculos exactos pasaron dry-run, aplicación y replay idempotente sin crear pagos, recibos, tickets, mensajes ni cambios de adhesión.

CBU y archivo COELSA

Para débitos por CBU, el flujo es bancario:

1. Revisar adhesiones CBU / COELSA activas con cuenta verificada.
2. Confirmar que las cuotas del periodo ya fueron generadas y estan pendientes o vencidas.
3. Crear el lote del período manualmente o revisar el lote creado por la tarea programada.
4. Revisar cantidad de transacciones y total del lote antes de descargar.
5. Descargar el archivo COELSA desde Lotes de Débito.
6. Enviar el archivo al banco por el canal operativo acordado.
7. Cargar la devolución del banco.
8. Conciliar aprobados y rechazados.

Los lotes COELSA no incluyen tarjetas.

Importe incluido en el lote

La generación manual y la tarea programada usan la misma regla:

El lote no recalcula descuentos sobre el importe original. Toma el saldo final de la deuda ya generada para evitar que un beneficio acumulado quede duplicado o perdido.

Ejemplo operativo:

Si el colegiado es jubilado, el ejemplo cambia: cuota original $1.000, jubilacion 50%, importe final $500. Ese caso no entra como doble descuento CBU+jubilacion.

Tarjetas y pasarela de pago

Las tarjetas de crédito no se mezclan con el lote bancario CBU. La adhesión del profesional conserva el método de cobro elegido, y la vinculación técnica con la pasarela queda separada para poder cambiar de proveedor sin rehacer la adhesión.

Hoy la pasarela puede ser NAVE, pero el diseño permite registrar otra pasarela manteniendo la adhesión del profesional y su trazabilidad.

Datos de tarjeta sin vencimiento informado

Al registrar una tarjeta de crédito, el operador debe identificar al titular con nombre y DNI válidos. La carga acepta el número completo de 13 a 19 dígitos; los últimos cuatro dígitos se conservan sólo para registros históricos ya existentes y no reemplazan la validación de una adhesión nueva.

La fecha de vencimiento es opcional. Cuando la fuente no la informa, el backend persiste el valor técnico 01/2099 para mantener compatibilidad con el modelo y la interfaz lo presenta como Sin vencimiento informado. Ese valor no es una fecha real, no amplía la vigencia de la tarjeta y no autoriza por sí solo un cobro. Un monto a cobrar debe ser mayor que cero y cumplir las guardas económicas del flujo de Dinero.

Evidencia visual: No aplica. No se publica una captura del formulario porque puede contener datos de tarjeta y de identidad. El contrato se verifica con validación de esquema, guardas de servidor y pruebas automatizadas.

Cambios administrativos de metodo de cobro

Los perfiles autorizados de Dinero o Administración pueden corregir el método de cobro desde la ficha profesional cuando corresponde. El cambio no queda moderado por el usuario final, pero debe quedar:

• visible para el profesional en su perfil;
• registrado en historial y auditoría;
• asociado al operador que lo realizó;
• notificado cuando corresponda.

¿Qué puede hacer el operador?

Filtros disponibles

• Por estado (PENDING / ACTIVE / SUSPENDED / CANCELLED)
• Búsqueda por nombre, DNI, matrícula o CBU

Flujo de activación

1. Colegiado solicita adhesión → estado PENDING.
2. Operador descarga el archivo de adhesiones pendientes para el banco.
3. Banco procesa el archivo.
4. Operador recibe confirmación del banco.
5. Operador activa las adhesiones en PSICOLE → estado ACTIVE.
6. En el próximo ciclo de facturación, las cuotas se generan con el descuento correspondiente al método: CBU 20% o tarjeta de crédito 30%.

Descuento por método de cobro automático

El descuento se aplica automáticamente al generar las cuotas de cada mes para todos los colegiados con método de cobro en estado ACTIVE, siempre que el tipo de cuota mensual permita ese descuento.

El porcentaje del descuento forma parte de la configuracion del concepto mensual y de la adhesion operativa. Para cambios masivos, validar el impacto en la previsualizacion de cuotas antes de ejecutar el RUN mensual.

Rechazos bancarios

Cuando el banco rechaza un debito, PSICOLE conserva la trazabilidad del intento y la cuota queda pendiente para gestion administrativa. En ese caso se revierte solo el descuento de debito directo. Los beneficios ajenos al CBU, como jubilacion, beneficio parental o ajustes aprobados, se mantienen.

Siguiendo el ejemplo anterior, si el banco rechaza un debito de $800 con CBU 20%, la cuota vuelve a $1.000 salvo que exista otro beneficio no CBU aprobado. Si el colegiado es jubilado, no debio entrar al lote con doble descuento; debe conservar solo la cuota final de jubilacion.

Si el profesional transfiere luego el importe base completo, el operador puede resolverlo desde Dinero -> Operaciones -> Conciliacion con Aplicar cuota completa, siempre que la transferencia y el rechazo correspondan al mismo profesional y período. Esta acción revierte sólo el descuento por método de cobro de esa cuota, vincula la transferencia y la respuesta rechazada a una única operación y no cambia la adhesión maestra. Una transferencia aislada nunca reactiva, suspende ni migra el método de cobro de períodos futuros.

El operador debe revisar:

• motivo informado por el banco;
• estado de la adhesion y cantidad de rechazos consecutivos;
• importe que queda pendiente luego del rechazo;
• si corresponde mantener, revertir o ajustar beneficios distintos del debito;
• si el rechazo debe suspender la adhesion por acumulacion de rechazos consecutivos.

Los rechazos pueden suspender automaticamente la adhesion si superan el umbral configurado.

Preguntas frecuentes

¿Cuándo se hace efectivo el débito? La fecha de débito coincide con la fecha de vencimiento de la cuota, configurada en el tipo de cuota correspondiente.

¿Qué pasa si el débito falla (fondos insuficientes)? El sistema registra el intento fallido. La cuota queda como pendiente y el operador puede gestionarla manualmente. No se aplican recargos por mora automáticos en el primer intento fallido.

¿El descuento aplica a todas las cuotas? Solo a las cuotas de tipo "regular" (cuota mensual). Los aranceles por trámites, cursos u otras cuotas extraordinarias no tienen descuento por débito.

🖥 Escritorio Operaciones de dinero con trazabilidad única

📱 Móvil Operaciones de dinero con trazabilidad única

Módulo DINERO

DINERO concentra el ciclo económico completo de PSICOLE: cuotas, pagos online, caja, conciliación bancaria, transferencias, planes de pago, débitos automáticos, liquidaciones, reintegros y auditoría. La regla operativa es simple: todo movimiento económico relevante debe poder abrirse como una operación única trazable.

Acceso

Menú admin: Dinero → Operaciones
Ruta principal: /admin/dinero/operaciones
Roles: ADMIN, operadores con módulo financiero habilitado.

Las rutas históricas de cobranza, caja, conciliación, transferencias, planes y débito redirigen a esta vista para evitar pantallas duplicadas.

Vista auditada desktop y mobile

La vista vigente de Dinero → Operaciones fue auditada en escritorio y celular. Los submódulos mantienen navegación horizontal controlada en móvil, las alertas operativas quedan dentro del viewport y las acciones principales se apilan sin superponerse.

Submódulos

Facturar cuotas, servicios AFIP y cola fiscal

La facturación fiscal post-pago se gestiona desde el circuito activo de Dinero. Las pantallas legacy de facturación fueron retiradas o redirigidas hacia Dinero → Configuración y Gobernanza del dinero para evitar duplicar operaciones.

Este apartado cubre EPIC-02UC-2.4 Facturar Cuotas (AFIP) y EPIC-08UC-8.4 Servicios AFIP: generación de comprobantes fiscales posterior al cobro, cola de reintentos, procesamiento manual controlado y alertas cuando AFIP no está disponible o no está configurado.

El flujo vigente separa dos conceptos:

Flujo operativo AFIP

1. Un pago queda aprobado y se materializa operación, pago y recibo.
2. PSICOLE encola un trabajo AfipInvoiceJob asociado al recibo o pago correspondiente.
3. La tarea programada o el botón Procesar AFIP toma trabajos QUEUED.
4. Si AFIP está configurado y disponible, el trabajo intenta obtener autorización fiscal.
5. Si falta configuración o AFIP no responde, el trabajo queda en reintento o FAILED con error visible.
6. El operador revisa la alerta y decide reintentar, corregir configuración o gestionar el comprobante por fuera según el procedimiento institucional.

Estados de la cola

Evidencia visual

La operación diaria se controla desde Gobernanza del dinero, donde aparecen la tarjeta Cola AFIP, el botón Procesar AFIP y las alertas activas.

Flujo mensual de cuotas, lote y conciliacion

El ciclo mensual de dinero se controla en cuatro momentos: valor vigente, generacion de deuda, cobro o debito, y corroboracion bancaria. El objetivo es que el importe aprobado por el Colegio llegue a una deuda concreta, a una operacion de dinero y finalmente a un movimiento bancario conciliado.

1. Definir el valor vigente. El administrador valida que CUOTA_MENSUAL este activo y que el periodo exista en el Tarifario Mensual de Cuotas. El importe base, los finales por medio de cobro y los beneficios salen de MONTHLY_FEE_TARIFF_POLICY.
2. Previsualizar la generacion. En Dinero -> Operaciones -> Cuotas, el operador selecciona tipo de cuota y periodo. La previsualizacion permite revisar cantidad de profesionales, cuotas a generar y monto total antes del RUN.
3. Ejecutar el RUN mensual. La generacion crea una deuda por profesional, periodo y tipo. Esa deuda queda con amount, discount y finalAmount; tambien se registra el cargo en cuenta corriente. Esta accion no representa dinero cobrado todavia.
4. Cobrar o preparar lote. Los pagos manuales, online, transferencias y debito automatico aplican contra las deudas abiertas. En CBU / COELSA, tanto la generacion manual como la tarea programada toman Debt.finalAmount como importe a debitar. Las tarjetas no entran al archivo COELSA.
5. Corroborar con extracto. Al cargar la extraccion bancaria, la conciliacion confirma que el dinero efectivamente ingresado o debitado coincide con una operacion PSICOLE. AUTO_APPLY_STRICT requiere importe exacto a centavos o un ajuste mensual previamente aprobado; una tolerancia amplia sólo ordena candidatos. Si hay excedente, faltante, pago parcial o descuento no configurado, el movimiento queda para revisión humana y no se marca la deuda como pagada por el total bancario.

Cómo leer la bandeja de cuotas

La píldora y el bloque Backlog operativo suman todas las cuotas mensuales reales abiertas, no sólo el mes seleccionado ni la página visible. El detalle por período explica ese total y el enlace abre la bandeja ya filtrada por pendientes.

La bandeja incorpora el selector Período económico. Elegir un mes limita filas y tarjetas de resumen a las obligaciones emitidas para ese período, aunque su vencimiento o pago hayan ocurrido en otra fecha. Todos los períodos conserva la lectura global. Los meses disponibles se obtienen del libro real y muestran la cantidad de obligaciones de cada uno.

En la bandeja:

• Pendientes abiertas incluye toda obligación impaga, esté o no vencida.
• Pendientes vencidas es un subconjunto de las pendientes abiertas cuya fecha de vencimiento ya pasó, o que conserva un estado histórico OVERDUE.
• Pendientes sin vencer es el resto de las pendientes abiertas.
• Pagadas y En plan son estados separados; una cuota cancelada no aporta saldo.
• Los totales se calculan sobre todo el resultado filtrado y no sobre los primeros 75 registros visibles.
• Las deudas marcadas como test quedan fuera del libro operativo.
• El importe emitido puede ser mayor que el saldo abierto cuando una obligación recibió un pago parcial. La diferencia debe estar respaldada por una imputación trazable; no implica una deuda duplicada.

Las cantidades del libro cambian con cada generación, pago, plan, bonificación o corrección trazable. La pantalla calcula el corte vigente y no usa totales estáticos. Para certificarlo contra Reportes, Profesionales y Prestadores se utiliza el certificado de verdad financiera, que debe devolver el mismo hash en dos lecturas y cero efectos laterales.

Una deuda conserva su estado histórico, pero la bandeja presenta una posición económica derivada común a todo DINERO: pendiente sin vencer, pendiente vencida, en plan, pagada, bonificada, cancelada o revisión de datos. Las filas con saldo cero inexplicable quedan en revisión y nunca se ofrecen a cobro, matching, débito o plan.

Valores versionados mayo-agosto 2026

Reglas certificadas:

• CBU / Caja de ahorro: 20% de descuento.
• Tarjeta de credito: 30% de descuento.
• Jubilados: 50% de descuento.
• Jubilacion excluye CBU/tarjeta: no se permite doble descuento sobre la cuota mensual.
• Cuando el período define un importe final oficial, generación y conciliación lo conservan sin volver a inferirlo a partir del porcentaje.
• El valor junio 2026 se carga como importe oficial fijo de $16.021. No debe inferirse como incremento de 2,1% sobre mayo, porque ese porcentaje no produce ese monto.
• Los valores finales de julio para CBU y tarjeta son importes oficiales. No se recalculan ni se redondean nuevamente durante la generación o la conciliación.
• Agosto se calcula con su propia entrada de tarifario. La entrada canónica de julio permanece intacta y no se reutiliza como valor de agosto.

Cuando un RUN autorizado revaloriza cuotas mensuales abiertas al tarifario vigente, actualiza la misma deuda y registra el ajuste; no crea otra cuota. Una deuda con pago, débito aprobado, saldo aplicado, asignación pagada de plan u operación PAY aprobada/conciliada queda protegida. La cuota del mes inmediatamente anterior se difiere mientras su conciliación conserve bloqueos o saldo sin resolver. Ver Revalorización segura de cuotas abiertas.

Control especifico de lote CBU

El lote de debito por CBU no es una nueva liquidacion de descuentos. Es una foto operativa de deudas ya generadas.

Si un profesional tiene una cuota original de $1.000 y CBU activo, el RUN deja una deuda final de $800 y ese es el importe del lote. Si el banco rechaza el debito, la deuda vuelve a $1.000 salvo que exista otro beneficio no CBU compatible. Si el profesional es jubilado, el RUN deja $500 por jubilacion y no aplica CBU/tarjeta sobre esa misma cuota.

Cuando una tarjeta o CBU fue rechazado y el profesional paga después por transferencia el importe base completo, la conciliación puede usar Aplicar cuota completa. La acción exige identidad, período, rechazo e importe exactos; modifica sólo esa deuda y conserva sin cambios la adhesión maestra y las cuotas futuras. No genera saldo a favor ni comunicaciones.

RUN mensual auditable de conciliacion

El cierre mensual de cuotas debe registrarse como un RUN auditable antes de aplicar conciliaciones masivas. El RUN no reemplaza las sesiones de conciliacion bancaria: las agrupa por periodo y deja constancia de fuentes, decisiones, metricas y pendientes.

Desde la aplicacion se opera en Dinero -> Operaciones -> Conciliacion -> RUN mensual. El panel permite crear un RUN PREVIEW, seleccionar el periodo, registrar extractos ya procesados como fuentes, simular decisiones y recalcular metricas. Es un panel de auditoria y control: no aplica pagos por si mismo, no modifica deudas y no envia comunicaciones.

El RUN mensual guarda:

Estados operativos:

• DRAFT: RUN creado, todavia sin decisiones completas.
• PREVIEWED: fuentes y decisiones previsualizadas, sin aplicar pagos.
• APPLIED: reglas estrictas aplicadas con idempotencia.
• CLOSED: cierre administrativo del mes.
• CANCELLED: RUN descartado sin usar como fuente de cierre.

Reglas de seguridad:

• Todo archivo debe tener tipo, rol, periodo, cantidad, monto y hash cuando exista.
• Las fuentes primarias son las que representan eventos individuales de dinero cobrado o rechazado, por ejemplo CBU y tarjeta. Extractos generales, recibos, padrones y listados de prestadores sirven como evidencia auxiliar o contraste, no como dinero nuevo por si solos.
• Un re-run debe reutilizar eventKey, marker e idempotencyKey para no duplicar operaciones.
• En SANDBOX el RUN puede previsualizar y clasificar sin enviar correos ni notificaciones.
• La accion Simular PREVIEW escribe solo MonthlyReconciliationDecision: AUTO_APPLY_STRICT, ALREADY_CLOSED, MANUAL_REVIEW, BLOCKED o EXCLUDED. No crea PaymentOperation, no emite recibos y no cambia Debt.status.
• Una reserva persistente impide dos simulaciones simultaneas del mismo RUN. El reemplazo de decisiones, metricas y manifiesto es atomico: ante error, el universo anterior permanece completo.
• El manifiesto conserva hashes SHA-256 de fuentes, eventos y decisiones. Dos PREVIEW sobre el mismo universo deben reproducir las tres huellas y mantener inalterados deudas, pagos, recibos, operaciones, saldos, mensajes, correos y tickets.
• Las PaymentOperation aprobadas por re-runs anteriores pueden cerrar un evento como ALREADY_CLOSED si existe evidencia unica por periodo, archivo, referencia y monto. Si hay ambiguedad, el evento queda BLOCKED.
• En la pantalla, Eventos tratados incluye tambien los EXCLUDED. La tasa de exito se calcula sobre eventos elegibles, es decir, tratados menos excluidos. Pendiente auditable corresponde a revision manual + bloqueados, no a todos los tratados.
• Los ajustes por aumento mensual salen de Dinero -> Configuracion -> Ajustes conciliacion (MONTHLY_FEE_RECONCILIATION_ADJUSTMENTS), no de codigo hardcodeado.
• Cuando se registra un extracto general como Galicia, el PREVIEW lo clasifica antes de matchear: cuota mensual, ajuste de periodo anterior, tramite/arancel, curso, liquidacion institucional, transferencia a clasificar o movimiento no acreditado. Solo la ruta de cuota mensual puede seguir al motor estricto de deudas; liquidaciones institucionales y egresos quedan excluidos del denominador de cuota, y tramites/cursos pasan a revision manual del concepto correspondiente.

SPTS total sandbox mayo/junio 2026

El Siguiente Paso Tecnico Sugerido para preproduccion es correr un RUN total controlado, no una aplicacion masiva. En SANDBOX se ejecuta con backend/scripts/sandbox/total-run-may-june-2026.mjs y usa como manifiesto todos los archivos de transferencias062026 mas los extractos bancarios ya procesados en la base.

El script crea o reutiliza un RUN por periodo con marker idempotente TOTAL_SANDBOX_YYYYMM_20260701. Registra todas las fuentes en MonthlyReconciliationSource y simula decisiones de conciliacion para CBU, tarjeta, transferencias y extractos procesables. Las fuentes de prestadores, padron, recibos, caja, beneficios, planes y cursos quedan como AUXILIARY o REFERENCE; no se convierten en dinero nuevo.

Salidas esperadas del SPTS:

Reglas de seguridad del SPTS:

• --apply en este script significa aplicar fuentes y decisiones auditables al RUN mensual. No crea PaymentOperation, no emite recibos y no marca liquidaciones de prestadores como pagadas.
• Los archivos transferencias-banco-*, Liquidacion*, Facturacion*, recibos, arqueos y padrones no entran como fuente primaria de cuotas. Sirven para contraste y trazabilidad.
• Si junio no tiene extracto general Galicia procesado, el gate JUNE_GENERAL_BANK_STATEMENT_MISSING queda abierto.
• Si hay liquidaciones de prestadores sin factura, el SPTS las deja visibles como pendiente operativo en el perfil del prestador. Si alguna liquidación no tiene operación PAY trazable, el gate de preproducción queda abierto aunque el RUN de cuotas mejore.
• Las filas virtuales aprobadas se materializan solamente desde Dinero -> Operaciones, con aprobacion explicita e idempotencia por origen. Luego se vincula el extracto desde la ficha PAY.

Beneficios, planes y conceptos externos

Los descuentos que modifican el importe de una cuota mensual deben quedar como regla persistente del profesional, no como correccion suelta del RUN. PSICOLE conserva dos niveles de evidencia:

Reglas operativas vigentes:

• Jubilacion: 50% sobre cuota mensual cuando la regla esta activa. No se acumula con descuento de CBU o tarjeta sobre la misma cuota.
• Maternidad/paternidad: se aplica segun periodo cubierto por la regla aprobada.
• Primera matricula: si la emision fue del dia 1 al 15, se bonifica el mes de emision y el mes siguiente; si fue del dia 16 al fin de mes, se bonifica el mes de emision y los dos meses siguientes.
• Planes de pago: la fila del plan debe quedar asociada al profesional cuando el match por nombre es suficiente. Las cuotas canceladas desde planilla se mantienen como PAID con referencia de planilla hasta que exista una operacion de dinero asociada.
• Curso Salud Colectiva: se registra como concepto externo por periodo e importe. Puede no tener profesional local, porque es un curso nacional.
• Materializacion controlada: desde Dinero -> Operaciones una fila virtual aprobada puede convertirse en operacion PAY, recibo, pago y asiento de cuenta corriente solo con aprobacion explicita del operador. La accion usa clave idempotente por origen para no duplicar y deja auditoria. Los conceptos externos en REVIEW no se materializan; si no tienen profesional local, el mismo flujo permite buscar y vincular un profesional existente antes de emitir recibo.
• Conciliacion posterior: cuando una fila virtual ya fue materializada, el siguiente paso no crea otro pago. Desde la ficha PAY en Dinero -> Operaciones, la accion Vincular extracto enlaza un movimiento bancario pendiente con esa operacion, valida importe y signo, marca el movimiento como conciliado manualmente, agrega documento de extracto, match de conciliacion y auditoria. La accion exige nota de aprobacion y clave idempotente por operacion + movimiento.

En Dinero -> Operaciones, el filtro Destino operativo permite aislar:

En un re-run sandbox de mayo/junio, el modo preview puede clasificar un movimiento abierto como AUTO_APPLY_PAYMENT_PLAN_INSTALLMENT_PREVIEW o AUTO_APPLY_EXTERNAL_CONCEPT_PREVIEW cuando hay monto, periodo y nombre suficientes. Los conceptos en estado REVIEW quedan excluidos del denominador automatico para no importar ruido. Esa clasificacion mide mejora de trazabilidad; no crea pagos, no emite recibos y no modifica deudas hasta que un operador materialice una fila virtual aprobada.

Certificacion de planes y conceptos del 18/07/2026

La fuente canónica de planes continúa siendo PAGO COLEGIACIÓN (2026) - hoja PLANES.xlsx. Dos archivos nuevos cuyo nombre comenzaba con PLANES DE PAGO fueron inspeccionados por columnas, filas y contenido antes de importar: eran respuestas duplicadas del Curso de Salud Colectiva. Por eso se clasificaron como EXTERNAL_COURSE y no se crearon planes ni cuotas de plan a partir de ellos.

El cierre dejó 90 planes reales y 215 cuotas en SANDBOX, y 91 planes reales y 218 cuotas en PSICOLE. La diferencia corresponde a un plan real creado y operado en PSICOLE; no debe sobrescribirse para forzar igualdad con SANDBOX. La reparación de estados se ejecutó en modo lectura: SANDBOX no encontró cambios y PSICOLE detectó tres filas ya correctas, sin actualizar estados ni crear pagos.

El plan real adicional de PSICOLE es PP-2026-000007, matrícula 5695: está ACTIVE, tiene tres cuotas, dos pagadas y el próximo vencimiento en octubre de 2026. No es una mora ni un error de importación. Los dos planes adicionales que podía mostrar el total anterior de la pantalla pertenecen a una cuenta de prueba en cuarentena, están cancelados y no forman parte de los 91 planes reales.

Control operativo de planes de pago

La vista existente Dinero -> Operaciones -> Planes separa el estado administrativo del plan del estado operativo de sus cuotas:

• Planes reales excluye por defecto cuentas de prueba o maquetas en cuarentena.
• Profesionales con plan cuenta personas únicas. Puede ser menor que Planes reales porque un profesional puede tener más de un acuerdo histórico o vigente.
• Acuerdos adicionales es la diferencia entre planes reales y profesionales únicos; sirve para localizar historiales repetidos sin asumir automáticamente que sean duplicados.
• Con atraso cuenta sólo planes APPROVED o ACTIVE con cuotas abiertas cuya fecha de vencimiento ya pasó.
• Por vencer muestra planes operativos sin mora que vencen dentro de los próximos diez días.
• Cuotas abiertas suma cuotas pendientes o vencidas únicamente de planes operativos.
• Incluir cuarentena permite auditar los registros de prueba sin mezclarlos con el total real.

El atraso se calcula al consultar la pantalla. La lectura no cambia PaymentPlan.status, no reescribe PaymentPlanInstallment.status, no cancela planes y no envía mensajes. Esto permite detectar demora aunque el scheduler esté inerte durante una prueba de preproducción.

Para revisar la cartera completa:

1. Abrir https://psicole.colegiopsimza.org.ar/admin/dinero/operaciones?tool=planes.
2. Dejar Estado y Tipo en todos para ver los planes reales completos.
3. Elegir Estado de cuotas -> Con atraso para aislar planes activos demorados.
4. Abrir un plan para contrastar cuotas pagadas, abiertas, importe y vencimiento más antiguo.
5. Exportar el listado filtrado cuando Tesorería necesite seguimiento. La exportación incluye cuotas pagadas, pendientes, vencidas y próximo vencimiento.
6. Activar Incluir cuarentena sólo para auditoría; esos registros no deben usarse para cobranza ni para comparar el informe real.

En Dinero -> Operaciones, las píldoras superiores muestran el backlog de cada sección, no el total histórico. Para Planes, el backlog es la suma de planes reales pendientes de revisión y planes activos con cuotas vencidas. Las cuotas abiertas y las cuotas pagadas por planilla sin operación se muestran como controles separados y no inflan el número de planes.

Pago idempotente de una cuota del plan

Desde el detalle de un plan ACTIVE, el operador puede registrar el pago de una cuota pendiente. La acción usa una clave de idempotencia y reclama la cuota dentro de la misma transacción antes de crear operación, recibo y pago.

• Si dos intentos compiten, sólo uno puede reclamar la cuota.
• Un reintento recupera el resultado existente únicamente cuando operación, recibo y pago están completos; no genera una segunda imputación.
• Si la cuota figura pagada pero faltan artefactos financieros, el sistema falla cerrado y exige revisión. No completa el pago por aproximación.
• El método y la referencia de pago quedan en la operación trazable.

Descuento especial sobre saldo pendiente

El botón Solicitar descuento crea una solicitud PENDING; no modifica el plan ni registra un cobro. El monto base se lee del plan o deuda persistidos y, en un plan parcialmente pagado, se calcula sobre importe final − total pagado. El valor enviado por el navegador no puede ampliar esa base.

El descuento debe ser positivo, no superar el saldo, incluir motivo y período y respetar los topes configurados. La aprobación requiere otro operador: quien lo solicita no puede autoaprobarlo. Sólo planes ACTIVE/APPROVED y deudas PENDING/OVERDUE admiten una solicitud nueva.

Más de 12 cuotas vencidas: descuento por pago único

Cuando un profesional tiene más de 12 cuotas mensuales vencidas, cualquier operador habilitado para cobranza puede enviar a Tesorería una solicitud por el conjunto completo de MONTHLY_FEE vencidas. Multas, cursos y otros conceptos no cuentan ni integran el grupo. El sistema toma identificadores, saldos y descuentos del servidor; no acepta una base informada por el navegador ni permite omitir una vencida para alterar el total.

1. En Cobro de Cuotas, buscar al profesional y elegir Solicitar descuento por pago único.
2. Informar monto y fundamento. La solicitud queda PENDING y todavía no cambia deuda, cuenta corriente ni recibos.
3. Otra persona con autoridad FINANCE_WRITE revisa y aprueba o rechaza. El solicitante no puede autoaprobar.
4. Una vez APPROVED, seleccionar el grupo autorizado y registrarlo mediante el cobro existente. Deben pagarse todas las cuotas del snapshot por el importe total exacto en una única operación; un subconjunto, pago parcial, aplicación de saldo a favor, monto distinto o cuota modificada falla cerrado. El medio CASH permanece bloqueado para este flujo hasta integrar su reversa atómica con Caja.

La aprobación es reversible mientras no se consumió. Al cobrar, el descuento se distribuye en centavos, queda vinculado a solicitud, operación, recibo, cuotas y ajuste de cuenta corriente, y la solicitud pasa a CONSUMED. Un replay conserva el mismo resultado; no duplica descuento ni cobro. Si se anula un recibo reversible, se restauran los importes del snapshot y la solicitud queda REVERSED.

Planes en la ficha del profesional

La ficha existente de Matrículas -> Profesionales incorpora la pestaña Planes. No crea otra cartera ni duplica el panel de Dinero: presenta, para la persona seleccionada, el mismo acuerdo y las mismas cuotas que administra Tesorería.

1. Buscar al profesional por nombre, DNI o matrícula y abrir su ficha.
2. Entrar en Planes para consultar acuerdos activos e históricos.
3. Revisar Planes activos, Con atraso, avance pagado/total y cantidad de históricos.
4. En cada acuerdo, contrastar estado administrativo, salud operativa, importe acordado, total pagado, próximo vencimiento y detalle de cuotas.
5. Volver a Cuenta Corriente para contrastar las obligaciones ordinarias, recibos y operaciones PAY vinculadas.

Los estados APPROVED y ACTIVE son operativos. Sólo ellos pueden informar cuotas abiertas, próximas a vencer o atrasadas. Los planes COMPLETED, CANCELLED o DEFAULTED permanecen visibles como historial, pero no generan nuevas cuotas operativas. La consulta calcula la mora con la fecha vigente; no reescribe el plan, no cambia cuotas y no envía comunicaciones.

Las obligaciones mensuales se muestran con una descripción canónica: Cuota Mensual - Mes Año. La normalización es de lectura para deudas históricas y de generación para cuotas nuevas; no cambia importes, pagos, recibos ni claves de trazabilidad existentes.

Los tableros operativos separan trabajo actual de historia migrada:

• Cuotas realmente vencidas cuenta sólo cuotas canónicas de profesionales activos, con saldo positivo y vencimiento cumplido. Las cuotas del mes vigente sin vencer y los registros históricos importados no inflan ese indicador.
• Tarjetas cuenta únicamente instrumentos reales pendientes de revisión. Las filas legadas sin profesional permanecen disponibles como inventario histórico, fuera del backlog diario.
• En la ficha profesional, una operación LEGACY-* muestra el período y la fecha real del pago, con la etiqueta Histórico migrado. La fecha de importación nunca se presenta como fecha de cobro.
• Los pagos parciales conservan el saldo restante y siguen visibles hasta su cancelación total; no se acreditan ni cierran por aproximación.

Desde Cuenta Corriente, Abrir ficha conserva el profesional y la pestaña de origen. La ficha de pago, recibo u operación muestra una acción para volver al mismo perfil, en lugar de regresar al listado general. Si la deuda todavía no tiene pago, se abre el libro de cuotas filtrado por su identificador interno y se ofrece el mismo regreso contextual.

Si Abrir ficha no muestra el registro esperado, no crear otro pago: verificar primero que el identificador de deuda, el número PAY o el número REC aparezcan en la URL y luego volver al perfil para revisar Cuenta Corriente. Un pago con operación siempre debe abrir la single canónica de esa operación.

Evidencia visual pública: No aplica. Esta ficha reúne identidad, matrícula, correo, deuda, recibos e importes de una persona real. La validación se realiza en SANDBOX con una cuenta autorizada y en vistas de escritorio y móvil, pero no se publican capturas con datos personales o financieros en el manual abierto.

La auditoría también verificó 384 reglas profesionales: 357 jubilatorias y 27 de primera matrícula. Los 38 antecedentes de maternidad/paternidad se conservaron como evidencia histórica o revisión (25 vencidos y 13 pendientes); ninguno se activó por inferencia. Los conceptos externos quedaron en 168: SANDBOX 52 aplicados y 116 esperados; PSICOLE 54 aplicados y 114 esperados. Estas diferencias reflejan trabajo manual real de cada entorno y no autorizan una copia destructiva.

Control recomendado antes de un nuevo RUN:

1. En Profesionales, filtrar beneficios vencidos o en revision para detectar reglas que no deben impactar mayo/junio.
2. En Dinero, revisar Planilla pagada sin operacion para separar cuotas canceladas por fuente externa de pagos ya materializados.
3. En Dinero, revisar Conceptos externos esperados y Conceptos externos en revision antes de aceptar nuevos autos del preview.
4. Para los autos aprobados, usar Materializar desde la fila virtual. Si el concepto externo no tiene profesional, usar Vincular en esa misma fila para elegir el profesional local y confirmar la emision. La nota de aprobacion es obligatoria y la accion es idempotente por cuota o concepto.
5. Abrir cada operacion PAY materializada y usar Vincular extracto solo contra el movimiento bancario pendiente correcto. No usar conciliacion rapida si la operacion ya existe, porque ese flujo crea pago y recibo nuevos.
6. Ejecutar el re-run como PREVIEW y comparar tasas contra la corrida anterior antes de cualquier aplicacion masiva.

Vincular extracto a una operacion PAY existente

Este flujo se usa cuando el pago ya existe en PSICOLE y falta unirlo con el movimiento del banco. No debe usarse para crear un cobro nuevo: el objetivo es completar la trazabilidad banco -> operacion -> recibo sin duplicar pagos.

Roles habilitados: Super Admin, Admin y operadores con permiso de escritura financiera.

Ruta operativa:

1. Entrar a Dinero -> Operaciones.
2. Abrir la ficha de la operacion PAY aprobada.
3. En la seccion Trazabilidad, usar Vincular extracto.
4. Informar el UUID del movimiento bancario pendiente y una nota de aprobacion.
5. Confirmar solo si el importe, signo y movimiento corresponden a la operacion.

Validaciones del sistema:

• La operacion debe estar APPROVED o RECONCILED, tener monto positivo y no tener extracto ya vinculado.
• El movimiento bancario debe estar pendiente de conciliacion y no asociado a otra operacion.
• El importe esperado se valida con tolerancia operativa minima.
• La accion usa clave idempotente por operacion + movimiento bancario para evitar doble vinculacion.
• Al confirmar, la operacion queda RECONCILED, el movimiento bancario queda MANUAL_MATCHED y se agregan evidencia bancaria, match de conciliacion y auditoria.

URLs de prueba en SANDBOX:

Evidencia visual: se valido en SANDBOX con capturas desktop 1440x1000 y mobile 390x844. Las capturas no se publican en el manual porque contienen nombres e importes reales de operaciones sandbox; quedan como evidencia interna del PR.

Certificacion SANDBOX mayo/junio 2026

La certificacion de cuotas de mayo y junio 2026 se hizo en SANDBOX con fuentes primarias de tarjeta y CBU, mas recibos, padrones, caja y listados de contraste. El objetivo fue probar el flujo completo RUN -> deuda -> lote/cobro -> operacion PAY -> recibo -> cuenta corriente -> banco -> conciliacion sin enviar correos ni avisos.

Resultado operativo de la prueba:

Tratamiento del remanente original de 360 eventos:

Los 71 aplicados usaron el marcador SANDBOX_REMAINING_360_CBU_PENDING_79_20260623. La verificacion exigio deuda PAID, operacion aprobada, recibo activo, pago aprobado, movimiento de cuenta corriente, asiento contable, links documentales y transaccion bancaria MANUAL_MATCHED. El replay idempotente no creo objetos nuevos.

Los 289 restantes no deben aplicarse por inferencia debil: requieren desempate de banco/emisor, migracion formal de profesional, generacion de deuda faltante o una regla operativa aprobada.

Definicion de cuota mensual certificada

En la version certificada en sandbox, la definicion de cuota mensual queda controlada por el concepto oficial, el tarifario mensual y la deuda que genera el RUN:

La cuota mensual de agosto de 2026 vence el 31/08/2026 en hora de Mendoza y no integra la mora antes del 1 de septiembre. La regla está periodizada: no modifica otros meses ni los vencimientos propios de cuotas de planes de pago.

Si para un mes nuevo se aprueba otro valor, se agrega el periodo al tarifario mensual. El RUN genera la deuda con ese importe base y los descuentos aplicables; el lote CBU toma luego el Debt.finalAmount, no vuelve a calcular el valor desde cero.

Si el período todavía no existe en MONTHLY_FEE_TARIFF_POLICY, PREVIEW y generación fallan sin crear deudas. Esta guarda evita que un mes nuevo herede accidentalmente el último importe activo de FeeType.

Cobro desde ficha profesional y caja

Cuando el operador necesita registrar un cobro manual a un profesional, puede iniciar el circuito desde la lista o ficha de profesionales.

La capacidad de cobranza está disponible para Administración, Superadministración, Supervisor de Trámites y todos los roles OPERADOR_*. Desde Dinero -> Consulta de deuda pueden buscar al profesional, consultar deudas y recibos, previsualizar la imputación y registrar pagos totales o parciales. Contador conserva consulta sin escritura y los usuarios colegiados no obtienen acceso a cuentas ajenas.

Esta autorización es acotada: no permite generar cuotas masivamente, configurar mora o descuentos, anular recibos ni aplicar saldos a favor. Esas acciones continúan reservadas a Finanzas/Administración. El cobro mantiene validación de deuda vigente, idempotencia, bloqueo transaccional, rechazo de sobrepagos, emisión de recibo y auditoría, independientemente de AUTHZ_POLICY_MODE.

En Profesionales, la acción con ícono de maletín abre el flujo de Caja para ingresar el pago correspondiente. Desde allí se registra el cobro, se imputa contra la deuda o concepto que corresponda y queda asociado a una operación de dinero trazable.

Uso operativo:

1. Buscar al profesional.
2. Abrir la acción de cobro/caja desde la fila o ficha.
3. Confirmar concepto, importe, medio de pago y caja responsable. Para efectivo debe existir una caja abierta; el servidor vincula la sesión activa CAJA_1_CENTRAL del operador.
4. Registrar el pago.
5. Revisar que quede emitido el recibo o movimiento asociado.

Este flujo se usa para cobros manuales presenciales o administrativos. Los pagos online y débitos automáticos siguen sus propios circuitos.

Un descuento no se incorpora directamente al cobro. Debe tramitarse mediante Solicitar descuento, con motivo, tope y aprobación por una persona distinta; recién el importe persistido y aprobado puede tomarse como base de pago. Para más de 12 cuotas mensuales vencidas se usa la solicitud agrupada: incluye todas las MONTHLY_FEE vencidas y sólo puede consumirse con el cobro único por el importe exacto autorizado. No admite pago parcial, saldo a favor ni efectivo.

Monto positivo obligatorio

Antes de confirmar, el total debe ser mayor que cero. La interfaz detiene un cobro de $0 y el servidor repite la misma validación antes de abrir la transacción financiera. Si todos los conceptos quedaron bonificados o la selección no tiene saldo, se revisa el descuento o se eligen otras deudas; no se emite una operación ni un recibo de monto cero.

Operación única de dinero

Cada pago, cobro, depósito, reversa o conciliación importante se representa con una PaymentOperation. Su número visible tiene formato:

PAY-2026-000001

Ese número es el punto de entrada para soporte, auditoría, conciliación y comunicación con el usuario. Desde la single se debe poder ver:

• Estado en español amable: Aprobada, Pendiente, Rechazada, Revertida.
• Canal: NAVE, transferencia bancaria, efectivo, caja, FIXED_POS, débito automático, obra social u otro.
• Propósito: cuota de matrícula, curso, trámite, plan, liquidación, cobro particular o reintegro.
• Origen e idempotencia: proveedor, referencia externa, clave idempotente y registro origen.
• Vínculos: deuda, pago, recibo, profesional, lote, caja, extracto o conciliación.
• Eventos: creación, aprobación, recibo creado, conciliación, reversa, usuario responsable y fecha.
• Impacto contable: asiento o vínculo a libro diario cuando corresponda.

Exportaciones de operaciones

Desde Dinero → Operaciones las exportaciones deben respetar los filtros activos de la vista: período, estado, canal, propósito, profesional, texto de búsqueda y demás criterios aplicados.

El botón de Excel/CSV recorre páginas adicionales con los mismos filtros, en vez de limitarse a la página visible. El corte actual admite hasta 100 páginas de 100 filas, es decir, 10.000 movimientos por descarga. Para un universo mayor se deben acotar los filtros; la interfaz todavía no avisa que alcanzó ese tope. Si no hay movimientos para exportar, la UI lo informa antes de descargar un archivo vacío.

Uso operativo:

1. Aplicar los filtros necesarios en Dinero → Operaciones.
2. Revisar el total de resultados.
3. Si el total supera 10.000, acotar período u otros filtros antes de exportar.
4. Exportar a Excel o CSV.
5. Usar el archivo como soporte de auditoría, conciliación o análisis operativo.

La exportación es de sólo lectura. Si el navegador no descarga el archivo, el operador debe conservar los filtros, revisar que existan resultados y reintentar desde la misma vista; no corresponde recrear movimientos para hacerlos aparecer en el reporte. La evidencia visual actual orienta sobre la pantalla de Operaciones, pero el estado específico de descarga queda pendiente de una captura sanitizada.

Pagos y recibos

PSICOLE distingue tres conceptos:

El dato documental autoritativo es Receipt.receiptNumber. Si un registro legado de pago conserva receiptNumber, se considera dato histórico y no debe presentarse como numeración principal.

Una operación puede vincular uno o más pagos y uno o más recibos según el caso operativo: pago de varias cuotas, curso más recargo, reversa parcial o regularización manual.

Saldos a favor y pagos parciales

Las diferencias de conciliación no se absorben con tolerancias amplias. En Dinero -> Operaciones -> Conciliación existen tres resultados controlados:

El saldo a favor no es ingreso por cuotas hasta que se aplica. Se muestra en la cuenta corriente del profesional y en el perfil administrativo con monto original, disponible, estado, nota y operación de origen. Para consumirlo, el operador abre Profesionales -> Cuenta Corriente -> Saldos a favor, pulsa Aplicar, elige una deuda y confirma la nota. La operación interna no vuelve a tocar Banco ni envía avisos.

La aplicación interna genera trazabilidad documental, pero no representa un nuevo ingreso de dinero. Por eso su recibo permanece visible y el importe no vuelve a sumarse en la métrica Total pagado.

La ficha única PAY muestra el saldo como sección activa y permite seguir la operación bancaria de origen, sus aplicaciones y las deudas alcanzadas. Mientras el saldo esté disponible se contabiliza en 2.1.4 Saldos a favor de profesionales; sólo la aplicación contra deuda lo reclasifica como ingreso.

Los estados del saldo son Disponible, Aplicado parcialmente, Aplicado y Reversado. Toda aplicación conserva idempotencia, pago, recibo, asiento, auditoría y vínculo con la deuda.

Para corregir una aplicación se anula primero su recibo: la deuda recupera el importe y el saldo vuelve a quedar disponible, sin tocar Banco ni enviar avisos. El recibo del ingreso bancario de origen sólo puede anularse cuando ya no tenga aplicaciones activas; esta secuencia evita saldos utilizables sin respaldo.

Agrupar profesionales por saldo y deuda

La vista existente de Matrículas -> Profesionales permite revisar el estado financiero sin abrir cada perfil:

• La columna Saldo a favor muestra el importe disponible para aplicar y se puede ordenar de mayor a menor o de menor a mayor.
• El filtro Saldo / deuda permite agrupar Con saldo a favor, Con deuda, Saldo cubre deuda y Sin saldo pendiente.
• La métrica Con saldo a favor abre el mismo filtro y muestra el total de profesionales con créditos disponibles.
• Si una persona tiene simultáneamente crédito y deuda, la fila muestra ambos datos: el saldo disponible en verde y la deuda en Cuota / Deuda. No se compensa visualmente ni se marca como pagada hasta aplicar el crédito.
• Un crédito Aplicado no aparece como saldo disponible. El profesional queda visible por su deuda remanente, mientras la trazabilidad completa se consulta en Cuenta Corriente.

El ordenamiento y los filtros consultan los importes consolidados del servidor, no sólo la página visible. Esto permite preparar una cola de comunicación o revisión sin modificar pagos, recibos, deudas ni enviar avisos. Antes de comunicar, el operador debe abrir el perfil y confirmar el estado y la nota auditada del saldo.

Evidencia visual: validado en SANDBOX en escritorio y viewport móvil de 390 px. No se publica una captura de esta tabla porque contiene nombres, matrículas, DNI y saldos reales del entorno de prueba.

Pasarelas y conciliación

Los pagos por NAVE u otra pasarela habilitada no reemplazan la conciliación bancaria. Se relacionan así:

1. El usuario inicia un pago desde Pagar deuda.
2. La pasarela crea una solicitud externa con referencia única.
3. PSICOLE registra o actualiza la operación PAY.
4. Cuando la pasarela aprueba, PSICOLE materializa pago, recibo y eventos.
5. Luego la pasarela liquida el dinero en una cuenta bancaria.
6. La conciliación cruza la liquidación de la pasarela y el extracto del banco.

La idempotencia evita cobrar o registrar dos veces: se controla por proveedor, referencia externa, operación interna, monto, fecha y clave idempotente del lote o extracto.

Reintegros, reversas y pagos por error

Las devoluciones no deben borrar el pago original. Se registra una operación compensatoria vinculada a la operación original.

La configuración de políticas se administra desde Dinero → Configuración, con motivo obligatorio y auditoría.

Contabilidad y libro diario

La trazabilidad del dinero no termina en el cobro. Cuando el circuito lo requiere, la operación debe dejar preparado o vinculado su impacto contable:

• cuenta o rubro operativo;
• fecha contable;
• asiento de libro diario o pendiente de generación;
• relación entre operación PAY, recibo, conciliación y contrapartida.

La regla práctica es que una conciliación correcta no debe romper la relación entre operación económica y libro diario.

Criterios de calidad operativa

• Todo estado visible debe estar en español amable.
• Toda fila de pago debe abrir una single canónica.
• Todo recibo debe abrir su documento o su operación asociada si todavía no existe vista documental separada.
• Toda conciliación debe mostrar si el dinero proviene de pasarela, banco, caja, débito o transferencia directa.
• Toda reversa debe conservar el vínculo con el movimiento original.
• Toda operación conciliada debe poder rastrearse hasta su salida contable o su pendiente contable.

🖥 Escritorio Módulo de cobro de cuotas y finanzas

📱 Móvil Módulo de cobro de cuotas y finanzas

Finanzas

Finanzas es la vista operativa del dinero diario: deudas, pagos, recibos, caja y conciliación. Para el circuito completo y la single de trazabilidad, ver Módulo DINERO.

Principios

• Un pago no debe quedar aislado: debe vincularse a una operación PAY.
• Un recibo se identifica por REC y es el documento autoritativo.
• Caja, transferencias y pasarelas deben conciliarse sin duplicar ingresos.
• Los estados se muestran en español amable.

Cobranza

La cobranza permite registrar pagos manuales o revisar obligaciones pendientes. Cuando se registra un cobro:

1. Se selecciona profesional y deuda.
2. Se informa canal: efectivo, transferencia, caja, débito, NAVE u otro.
3. Se valida que no exista una operación equivalente.
4. Se crea la operación de dinero.
5. Se emite recibo cuando corresponde.

Recibos

El recibo es el comprobante documental del cobro. Su número se genera en la entidad Receipt y no debe confundirse con identificadores internos de pago.

Caja

Caja controla sesiones diarias de ingreso y egreso. Cada apertura, movimiento y cierre queda vinculado al responsable. Si el movimiento genera pago, también debe crear operación trazable.

Flujo operativo de caja

1. Abrir una sesión de caja con responsable, caja física y saldo inicial.
2. Registrar ingresos o egresos indicando concepto, importe, medio y profesional cuando corresponda.
3. Imputar pagos contra deudas abiertas o dejar el movimiento como operación de caja identificada.
4. Emitir recibo cuando el movimiento documenta un cobro.
5. Cerrar la caja al final de la jornada con arqueo, diferencia y observación obligatoria si no cuadra.

Conciliación

La conciliación bancaria cruza tres capas:

1. Operaciones internas de PSICOLE.
2. Liquidaciones de pasarelas o lotes de débito.
3. Extractos bancarios reales.

Una transferencia directa que no pasó por pasarela también puede conciliarse; si corresponde a deuda, curso o trámite, se imputa desde la operación.

Cierre exacto por método de cobro

La corrección entre débito automático y tarjeta sólo se aplica cuando el extracto identifica de forma exacta al profesional, el período, el medio y la deuda compatible. El importe aislado, una diferencia cercana al 20% o 30% y el nombre aproximado no son evidencia suficiente.

El gate del 23/07/2026 resolvió en PSICOLE 6 movimientos exactos por $69.600,00. Cada aplicación creó una única operación, pago, recibo, vínculo bancario y movimiento de cuenta corriente mediante el servicio oficial. El replay inmediato devolvió los mismos artefactos, sin duplicar registros, crear saldos, enviar comunicaciones ni alterar otras deudas.

Otras 3 filas por $37.476,00 quedaron OPEN_AMOUNT_INFERENCE_REVIEW: el importe permite formular una hipótesis, pero no demuestra el medio. Una de ellas además contradice el método vigente del profesional. Estas filas siguen en revisión manual y no se convierten en cobro por similitud.

Un movimiento puede aparecer en más de un snapshot mensual histórico. El replay es válido si la operación ya vinculada referencia el RUN solicitado; un RUN del mismo período que nunca estuvo vinculado se rechaza. El hash del comando continúa siendo obligatorio: cambiar deuda, transacción, importe o destino produce conflicto y no recupera una operación anterior.

Evidencia bancaria OOSS en revisión

El cobro de una obra social no se confirma por nombre, cercanía de fecha o importe aislado. El control OOSS usa un manifiesto certificado y exige una transacción bancaria única, no test, abierta y coincidente en fecha, importe, referencia, titular y archivo de extracto.

Cuando la evidencia pasa esas guardas, PSICOLE registra un candidato de revisión:

Todos estos candidatos tienen revisión humana obligatoria. No pueden autoaplicarse y no crean pagos, recibos, operaciones PAY, liquidaciones, cambios de deuda, avisos ni correos. Una coincidencia exacta es evidencia; todavía no es una conciliación económica.

El apply técnico sólo escribe la cola de candidatos y debe repetirse con la misma clave funcional. El replay válido devuelve las mismas filas como NOOP y conserva sin cambios el snapshot económico. El recalculador general tampoco puede superseder estos candidatos OOSS, porque pertenecen a un manifiesto externo certificado.

En el gate SANDBOX del 23/07/2026 se registraron inicialmente 16 candidatos. La auditoría detectó que faltaba el segundo extracto Galicia de julio, que ya estaba presente en PSICOLE. La fuente completa se importó en SANDBOX por hash y clave de deduplicación: agregó 438 movimientos una sola vez y el replay agregó 0.

Con el mismo universo de fuentes, ambos entornos produjeron el mismo plan normalizado de 18 candidatos: 6 contra pagos de lote exactos y 12 contra cohortes OOSS, sin bloqueos. El apply SANDBOX creó sólo los 2 candidatos faltantes y el replay devolvió 18 NOOP. El hash normalizado entre entornos fue 6bb318f111f8274b534c58b066f93c3498b064ff00990d0d20145bda1feb7203; pagos, recibos, deudas, órdenes, liquidaciones, movimientos y comunicaciones conservaron sus conteos. Esta paridad habilita el gate productivo review-only, pero no autoriza por sí sola una conciliación económica.

La promoción review-only a PSICOLE exige cuatro confirmaciones independientes: hash semántico de la evidencia, hash funcional del plan, SHA-256 del respaldo y hash del snapshot económico inmediatamente anterior. El servicio vuelve a capturar ese snapshot dentro de la transacción serializable y aborta antes de escribir si cambió. En SANDBOX, un hash económico incorrecto falló cerrado y el hash correcto reprodujo 18 NOOP.

El gate productivo se aplicó con esas cuatro confirmaciones: creó 18 candidatos y el replay creó 0, con 18 NOOP. Todos permanecen humanos, sin operación económica, sobre transacciones pendientes y no test. El snapshot amplio de PSICOLE conservó el hash 716f573558871606d3e8a7251c936d875923496de9a141ea486fb2dafcd78da6 antes y después; no cambiaron pagos, recibos, deudas, banco, lotes, liquidaciones, órdenes ni comunicaciones.

Corrección tarifaria histórica de órdenes

El período de prestación de una orden y el período operativo del lote son datos distintos. Una orden prestada en mayo de 2025 no toma la tarifa de mayo de 2026 por estar agrupada posteriormente en un lote de ese mes. Toda corrección debe resolver primero la tarifa vigente en la fecha de prestación y demostrar por orden que cantidad, precio unitario y total explican íntegramente la diferencia.

El gate OSTV del 23/07/2026 reconstruyó una diferencia agregada de $ 187.200,00: cuatro órdenes históricas tenían una tarifa persistida de $ 4.900,00 por sesión frente a una tarifa documental de $ 16.600,00. Dos previews en SANDBOX y dos en PSICOLE produjeron el mismo hash funcional 639811d405b1eeeeb974fff37a784d4a312d922e4ff572fb510ea512509a8044. La proyección lleva a cero la diferencia entre órdenes, lote y liquidación sin modificar el bruto del lote, pago, débitos, comisión, neto, liquidaciones, facturas, operaciones o recibos.

El auditor es estrictamente de sólo lectura y rechaza --apply y --write. El cambio económico requiere otro comando, respaldo verificable, hash e identidades exactas, autorización para órdenes históricas PAID, transacción con bloqueo de filas e idempotency key. El replay debe producir cero escrituras y el auditor posterior debe conservar cero comunicaciones y gaps iguales a cero.

La corrección controlada se ejecutó únicamente en SANDBOX. Modificó las cuatro órdenes exactas, creó cuatro registros de auditoría y una clave de idempotencia. No creó ni modificó pagos, recibos, lote, pago de lote, liquidación, comisión, neto, facturas, operaciones, tickets o comunicaciones. El replay devolvió REPLAY_NOOP, sin escrituras, y dos previews posteriores clasificaron el estado como ALREADY_CORRECTED_AND_CERTIFIED, con las dos diferencias en cero y el mismo hash funcional 4c00be52c845f19cfc9bcafc3b076b6d77b06af726e5a819e938bceb718f60c8.

PSICOLE no fue modificado en este gate. La corrección productiva, si se autoriza, debe repetir el mismo circuito contra un respaldo y un preview actuales; nunca se promueve copiando datos desde SANDBOX.

Readiness de cobro OOSS después de ajustes

La preparación de un cobro OOSS compara magnitudes equivalentes. La suma bruta de órdenes se contrasta con el bruto del lote (totalAmount); la diferencia entre bruto y aceptado se contrasta por separado con los ajustes de las liquidaciones. Nunca se compara el bruto de órdenes directamente con el aceptado después de ajustes.

Si ambos controles cierran, el lote puede quedar READY_FOR_EXPLICIT_OOSS_COLLECTION_APPROVAL. Este estado sólo habilita la revisión de un operador: no confirma el cobro, no concilia el banco y no paga al prestador. Las advertencias de archivo respuesta, procedencia, factura institucional y fecha bancaria siguen visibles y deben resolverse o aceptarse individualmente antes de aprobar.

En el control SANDBOX del 23/07/2026, dos replays produjeron el mismo hash y dejaron 6/6 lotes exactos listos para revisión humana. OSTV cerró con bruto de órdenes y lote por $2.048.900,00, aceptado por $1.986.500,00, ajustes por $62.400,00 y ambos gaps en cero. Los 18 candidatos bancarios permanecieron humanos, sin decisión ni operación vinculada.

El pago a prestadores se controla en otro gate. Los seis casos continuaron bloqueados por facturas incompletas; ninguno quedó listo para pago. Los snapshots económicos antes y después fueron idénticos y PSICOLE no fue modificado.

Reversas y reintegros

Los reintegros no borran recibos ni pagos históricos. Crean una operación compensatoria con motivo obligatorio y vínculo al movimiento original.

Reporte financiero

Los reportes financieros permiten revisar ingresos, egresos, métodos de pago, cuotas, caja y evolución mensual sin modificar datos. Sirven para control administrativo, auditoría y preparación de información contable.

Este apartado cubre EPIC-04UC-4.1 Reporte Financiero: acceso a reportes, extracción de datos consistentes y lectura cruzada con caja, pasarelas, recibos y conciliación.

Ruta operativa: /admin/dinero/reportes o Dinero → Reportes.

Flujo operativo

1. Elegir período o rango de fechas.
2. Seleccionar vista: recaudación, métodos de pago, evolución mensual, caja o balance.
3. Revisar totales y desgloses.
4. Comparar contra caja, pasarelas y conciliación cuando haya diferencias.
5. Exportar el reporte si se requiere soporte externo.

Reglas de lectura

Contrato de cifras entre vistas

Las pantallas no deben compararse sin distinguir período, población y tipo de movimiento. El reporte usa estas definiciones:

Estado económico canónico

El estado guardado en la deuda conserva la historia del flujo. Para decidir qué se cobra y qué integra un indicador, PSICOLE deriva además una posición económica de sólo lectura a partir de estado, saldo, descuento, vencimiento y asignaciones de plan. Las pantallas financieras deben usar esta clasificación común:

La partición de cantidades debe cerrar siempre:

emitidas = pendientes sin vencer + pendientes vencidas + en plan + pagadas + bonificadas + canceladas + revisión de datos

Los grupos son mutuamente excluyentes. Una cuota pagada no se cuenta también como vencida aunque se haya abonado después del vencimiento. Por eso es válido que el importe pagado de un mes sea mayor que el saldo que todavía permanece vencido: son cohortes distintas del mismo universo emitido.

Cuatro unidades que no deben sumarse como si fueran iguales

Por eso, 4.766 obligaciones emitidas, 3.104 cobros externos y 3.057 imputaciones a junio no describen tres versiones del mismo contador. Un cobro puede cubrir varias obligaciones, pagar otro período, quedar como saldo a favor o corresponder a otro concepto. Del mismo modo, una obligación puede recibir pagos parciales y continuar abierta con un saldo menor.

El Balance Mensual abre en Mes seleccionado y permite cambiar a Año completo. En ambos modos separa obligaciones emitidas, cobros externos, registros de cobro aprobados y recibos activos. El total anual de cobros no debe compararse directamente con las obligaciones del año mientras existan cobros históricos o importados sin una deuda asociada: esa diferencia se muestra como cohorte separada y se audita, no se imputa automáticamente.

La vista Dinero → Operaciones → Cuotas muestra el libro global: pendientes directas y cuotas en plan son estados distintos. Por eso su total abierto se obtiene como pendientes directas + en plan. La vista Profesionales agrupa ese libro por persona y sólo sobre el padrón facturable; no debe esperarse que su cantidad de personas sea igual a la cantidad de obligaciones.

Las órdenes, rendiciones, facturas y liquidaciones de prestadores se validan en Prestadores. Una orden representa una prestación a cobrar a una obra social y una liquidación representa una obligación hacia el prestador; ninguna de las dos se suma a la recaudación colegial hasta existir el movimiento económico externo correspondiente.

Las facturas fiscales que el Colegio emite a las obras sociales se consultan en Dinero → Configuración → Facturación OOSS. Pertenecen al circuito Colegio → OOSS y no deben confundirse con las facturas que un prestador presenta al Colegio. La constancia fiscal y su CAE documentan la emisión; el ingreso se confirma únicamente mediante conciliación y una operación económica trazable.

La carga documental es idempotente: una factura nueva se registra como Enviada y un PDF agregado a una factura existente conserva su estado. Repetir el mismo lote no crea otra factura ni otro archivo. Esta carga nunca genera pagos, recibos, liquidaciones, avisos o correos; cualquier cobro de la OOSS debe continuar por conciliación y conservar su operación económica.

La cabecera de Lista de Prestadores cuenta perfiles registrados, incluidos los históricos o inactivos. El certificado financiero informa por separado los prestadores activos al corte. Por eso ambos totales pueden diferir sin que falte una persona: primero se compara la misma población y luego sus órdenes, rendiciones y liquidaciones. En el corte SANDBOX del 20/07/2026 se observaron 473 registrados y 459 activos.

Control cruzado mensual

1. En Reportes, seleccionar el mes y anotar cobros externos, obligaciones y total abierto.
2. En Operaciones → Cuotas, comprobar que pendientes directas más cuotas en plan coincidan con la posición global del libro.
3. En Profesionales, comprobar que la cantidad de profesionales y la deuda abierta correspondan al padrón facturable, no a la cartera histórica.
4. En Prestadores, comprobar órdenes por fecha de prestación y liquidaciones por período. Las facturas faltantes permanecen como cola operativa y no se infieren como pagadas.
5. Si una cifra no coincide, revisar primero alcance, período y población. La corrección se realiza en la operación o conciliación de origen, nunca editando el reporte.
6. Ejecutar el certificado de verdad financiera para los períodos revisados y conservar certification.json como evidencia del corte.

Certificación rápida y repetible

Desde el backend, el control completo se ejecuta así:

npm run audit:financial-truth -- \
  --periods=2026-05,2026-06,2026-07 \
  --replays=2 \
  --output-dir=/app/tmp/financial-truth

El certificado:

• calcula en forma independiente las posiciones de Reportes, Operaciones, Profesionales y Prestadores;
• exige que la partición económica cierre para el libro global y para cada período;
• excluye perfiles, deudas y pagos de prueba del universo operativo;
• verifica que cobros, reversas y recibos tengan la procedencia esperada;
• repite el cálculo y exige el mismo functionalHash;
• compara contadores económicos y de comunicaciones antes y después;
• devuelve PASS sólo si todos los invariantes pasan, los hashes coinciden y sideEffectDelta es cero.

El archivo certification.json es la evidencia vigente. Las cifras de capturas y ejemplos del manual son ilustrativas y no reemplazan ese corte. Si el hash cambia entre replays o aparece un delta, no se corrige ningún dato automáticamente: se detiene la validación y se investiga el proceso concurrente o la diferencia de criterio.

En la certificación SANDBOX del 20/07/2026, mayo, junio y julio pasaron 37 controles cruzados, los dos replays de cada período conservaron su hash funcional y las 20 tablas observadas tuvieron delta cero. Como control visual adicional, Cuotas filtrada por junio mostró 4.767 obligaciones: 1.710 abiertas y vencidas, 3.050 pagadas, 6 bonificadas y ninguna en revisión, exactamente igual al oráculo.

🖥 Escritorio Panel de pagos online del colegiado

📱 Móvil Panel de pagos online del colegiado

Pagos Online y Pasarelas

Pagos Online permite que colegiados, prestadores o usuarios asistidos paguen deudas desde el portal. El checkout online operativo actual se canaliza por NAVE. PSICOLE nunca almacena datos de tarjeta.

Flujo de pago

1. El usuario ingresa a Pagar deuda.
2. Selecciona una o más cuotas, cursos, trámites u obligaciones pendientes.
3. Confirma el total.
4. PSICOLE crea una solicitud en la pasarela habilitada.
5. El usuario completa el pago en el checkout externo.
6. Al volver o al refrescar estado, PSICOLE consulta la pasarela.
7. Si el pago fue aprobado, se materializan operación, pago, recibo y eventos de auditoría.

Capturas auditadas desktop y mobile

La pantalla de pagos fue recapturada en escritorio y celular para validar selección de deuda, acciones de pago y lectura de estados sin corrimientos laterales. Estas capturas reflejan la superficie vigente para el usuario final.

NAVE y otros proveedores

La pasarela visible depende de la configuración de Dinero → Configuración. En sandbox se trabaja en modo demo o entorno inerte.

Operación y recibo

Al aprobarse un pago:

• Se crea o actualiza una operación PAY-YYYY-NNNNNN.
• Se imputan las deudas incluidas.
• Se emite recibo REC-YYYY-NNNNNN cuando corresponde.
• Se registran eventos: pago aprobado, operación creada, recibo creado y usuario responsable.

El recibo documenta el cobro; la operación explica todo el recorrido.

Pagos impersonados o asistidos

Un administrador puede asistir a un usuario en el proceso de pago cuando el modo de impersonación lo permite. La pantalla debe mostrar claramente que se está actuando como otra persona y registrar:

• Administrador actuante.
• Usuario representado.
• Operación creada.
• Resultado de la pasarela.

Recuperación de pagos

Si el usuario completa el checkout pero la vuelta al sistema falla, el operador puede recuperar el estado desde la referencia externa. El sistema debe evitar duplicados usando la clave idempotente de la operación y la referencia del proveedor.

Errores frecuentes

🖥 Escritorio Conciliación bancaria y matching de pagos

📱 Móvil Conciliación bancaria y matching de pagos

Conciliación Bancaria

Descripción

La conciliación bancaria es el proceso mediante el cual el sistema compara los movimientos registrados en el extracto bancario con los pagos registrados en PSICOLE, identificando correspondencias y detectando diferencias. Este módulo permite importar extractos en formato CSV o Excel directamente desde el banco, reduciendo la carga manual y el riesgo de errores.

El motor de matching automático analiza cada transacción del extracto y busca pagos pendientes de conciliar utilizando criterios configurables: monto exacto, referencia de comprobante, fecha y datos del titular. Las transacciones que no puedan asociarse automáticamente quedan en estado "pendiente" para resolución manual por parte del operador de finanzas.

Cada proceso de conciliación se organiza en sesiones de conciliación, que agrupan un extracto importado junto con todos los emparejamientos (automáticos y manuales) realizados sobre él. Las sesiones quedan auditadas con fecha, usuario y justificación de cada decisión.

Roles con acceso

Flujo principal

1. Importar extracto bancario

1. Ir a Finanzas → Conciliación Bancaria → Nueva Sesión.
2. Seleccionar el banco de origen en el desplegable (ej. Banco Nación, Santander, Galicia).
3. Hacer clic en Subir Archivo y seleccionar el archivo .csv o .xlsx exportado desde el homebanking.
4. El sistema valida el formato del archivo; si hay errores de estructura, se muestra el detalle de las filas con problemas.
5. Confirmar el período del extracto (fecha desde / fecha hasta) y hacer clic en Importar.
6. El sistema crea la sesión de conciliación con estado ABIERTA y lista todas las transacciones importadas.

2. Matching automático

1. Desde la sesión abierta, hacer clic en Ejecutar Matching Automático.
2. El sistema procesa cada transacción del extracto y aplica las reglas de matching configuradas (ver sección de Reglas de Negocio).
3. Al finalizar, se muestra un resumen: cantidad de transacciones emparejadas, monto total conciliado y cantidad de transacciones sin match.
4. Las transacciones emparejadas automáticamente quedan en estado CONCILIADO_AUTO y el pago asociado en PSICOLE se marca como confirmado.
5. Revisar el resumen y avanzar al matching manual para las restantes.

2.1 Corroboracion del RUN mensual de cuotas

La conciliacion no genera cuotas ni modifica el tarifario. Su funcion en el ciclo mensual es corroborar que el dinero que figura en el banco coincide con lo que PSICOLE genero y cobro.

Para cuotas mensuales, el sistema revisa:

• identidad fuerte del pagador o referencia bancaria;
• deuda abierta del periodo correspondiente;
• coincidencia entre el movimiento bancario y finalAmount de la deuda;
• pagos de varias cuotas acumuladas en un mismo movimiento;
• ajustes contables aprobados cuando el pago bancario refleja un importe anterior al aumento mensual.

Si la diferencia de monto no corresponde a una regla aprobada, el movimiento queda para revision manual. La decision debe documentar si se trata de ajuste, redondeo, pago parcial, descuento no configurado, saldo a favor o ingreso no identificado.

2.2 Corroboracion de lotes CBU / COELSA

Cuando la sesion incluye movimientos relacionados con debito automatico, el operador debe cruzar tres piezas:

Para aprobados, el importe conciliado debe coincidir con debitAmount del lote. Para rechazados, no debe crearse ingreso bancario ni recibo; el sistema conserva el intento y actualiza la deuda quitando solo el descuento por debito directo. Beneficios no CBU se mantienen.

Si el movimiento bancario agrupa varios debitos, el motor puede sugerir el lote como candidato por importe agregado. Antes de confirmarlo, revisar que la cantidad de registros aprobados y rechazados coincida con la respuesta del banco.

2.3 Auditoria cruzada SANDBOX mayo-julio 2026

Para certificar un RUN mensual de cuotas, Finanzas puede ejecutar una auditoria cruzada en SANDBOX antes de replicar reglas en produccion. La prueba de mayo/junio 2026 uso como fuentes primarias:

• detalle de presentacion de tarjetas de credito de mayo;
• detalle de presentacion de tarjetas de credito de junio;
• reportes de cobros CBU de mayo y junio;
• recibos generados por el sistema, padron, caja, profesionales y listados de prestadores como contraste.

La medicion contable principal no suma todas las fuentes como si fueran movimientos nuevos, porque algunas son vistas del mismo hecho economico. El denominador estricto es: tarjeta aceptada + CBU cobrado. Los rechazos no representan dinero cobrado y se analizan aparte.

Resultado certificado en SANDBOX:

El remanente original de 360 eventos quedo tratado al 100%: 71 se aplicaron en SANDBOX, 123 ya estaban cerrados/no-PENDING, 152 quedaron como cola manual por identidad o destino insuficiente, 6 no tenian deuda PENDING compatible y 8 fueron bloqueados por regla bancaria estricta.

Regla de aplicacion segura para CBU:

1. Identidad oficial fuerte.
2. Deuda mensual PENDING del periodo y monto compatible.
3. Una unica BankTransaction exacta por referencia, CBU, credito aceptado, importe y estado PENDING.
4. Marker de SANDBOX e idempotency key por deuda + transaccion bancaria.
5. Verificacion posterior de deuda PAID, operacion aprobada, pago, recibo, asiento, cuenta corriente y links documentales.

Si falta cualquiera de esas condiciones, el movimiento queda en cola manual. No se debe crear un pago por similitud de nombre, monto aproximado o padron historico sin fuente de desempate.

Cierre dual SANDBOX / PSICOLE del 10/07/2026

El mega RUN final inventario transferencias062026/ antes de registrar fuentes. De 32 archivos de primer nivel, 28 fueron admisibles como fuente real o referencia. Se excluyeron .DS_Store y tres salidas psicole-run-* generadas por corridas anteriores. Los tres RUNs registran 36 filas de fuente deduplicadas porque las referencias aplicables se declaran dentro de cada periodo; este conteo no significa 36 archivos bancarios distintos.

Cada entorno reconoce solo su propia evidencia: el RUN no copia pagos, recibos ni operaciones entre SANDBOX y PSICOLE. SANDBOX reconoce 6.052 cierres reales previos y PSICOLE 6.047. Cualquier cierre sostenido por un pago isTestRun, un profesional isTestAccount, una operacion inactiva o evidencia incompleta vuelve a pendiente o bloqueado.

En ambos entornos el control antes/despues confirmo cero altas de Payment, Receipt, PaymentOperation, Invoice, ReceivedInvoice, Notification, EmailLog, InternalMessage y tickets. Solo aumentaron tres RUNs, 36 fuentes registradas y 9.232 decisiones auditables. PSICOLE incorporo ademas los dos extractos generales faltantes, con 438 movimientos bancarios reales y sin materializacion economica.

Julio usa un extracto Galicia parcial y no incluye todavía archivos primarios completos de CBU y tarjeta. Su tasa no debe compararse con mayo o junio ni usarse para cerrar el mes.

2.4 RUN mensual auditable

Para conciliaciones mensuales de cuotas, el operador puede organizar la evidencia en un RUN mensual auditable. Este registro agrupa las fuentes del periodo y permite medir la tasa de conciliacion sin aplicar pagos por inferencia debil.

El panel esta dentro del flujo existente: Dinero -> Operaciones -> Conciliacion -> RUN mensual. No es una ruta separada ni reemplaza las sesiones de conciliacion; funciona como tablero de cierre por periodo.

El RUN mensual se usa para:

1. Declarar fuentes primarias y auxiliares del periodo.
2. Registrar hash, cantidad y monto por archivo o fuente.
3. Ejecutar una simulacion PREVIEW sobre fuentes registradas ya procesadas, incluyendo auxiliares como extractos Galicia.
4. Clasificar eventos en AUTO_APPLY_STRICT, ALREADY_CLOSED, MANUAL_REVIEW, BLOCKED o EXCLUDED.
5. Medir tasa de exito por eventos y por monto, separando evidencia auxiliar del denominador.
6. Dejar una cola manual con motivo y proximo paso.

En esta capa, AUTO_APPLY_STRICT significa que el evento cumple condiciones para ser aplicado por el motor seguro; no habilita por si solo una aplicacion si falta idempotencia, deuda abierta compatible, transaccion bancaria unica o consentimiento operativo.

Uso del panel:

1. Seleccionar el periodo mensual.
2. Crear un RUN en modo PREVIEW.
3. Registrar los extractos procesados del periodo como fuentes del RUN.
4. Usar Simular PREVIEW para generar decisiones auditadas sin aplicar pagos.
5. Recalcular metricas para ver fuentes, eventos tratados, monto aplicado/cerrado, cola manual y bloqueos.
6. Usar el detalle de fuentes y decisiones como evidencia del cierre mensual o como cola de investigacion.

RUN operativo e historial de previews

Un período puede conservar varios previews porque cada recalculo histórico es inmutable. Para evitar que el operador elija una versión incompleta, sólo uno debe quedar marcado como RUN operativo:

1. Revisar que el RUN elegido incluya el conjunto final de extractos, lotes y fuentes del período.
2. Pulsar Usar como operativo y documentar el criterio en una nota de al menos 20 caracteres.
3. El RUN elegido queda identificado con la insignia RUN operativo.
4. Los previews DRAFT o PREVIEWED anteriores pasan a CANCELLED como históricos de sólo lectura. No se borran fuentes, decisiones ni métricas.
5. Usar Ver históricos únicamente para auditoría o comparación; no continuar conciliando sobre una versión reemplazada.

La promoción no aplica pagos ni modifica deudas. Si el RUN operativo necesita nueva evidencia, se registran las fuentes y se vuelve a simular esa misma versión; no se crea otro RUN sólo para actualizar métricas. Un RUN APPLIED o CLOSED nunca se cancela automáticamente.

El boton Registrar extractos solo vincula archivos ya cargados y procesados en conciliacion bancaria. No crea pagos, no modifica deudas, no cambia estados profesionales y no envia correos.

El boton Simular PREVIEW clasifica las fuentes registradas. Si una transaccion ya esta vinculada a una operacion, queda como ALREADY_CLOSED; si existe una PaymentOperation aprobada de un re-run previo con evidencia unica por periodo, archivo, referencia y monto, tambien queda ALREADY_CLOSED sin crear pagos nuevos; si existe un match estricto con deuda abierta del periodo y monto compatible, queda como AUTO_APPLY_STRICT; si requiere decision humana, queda como MANUAL_REVIEW; si no tiene destino suficiente, queda como BLOCKED; y si la fuente informa rechazo o exclusion, queda como EXCLUDED.

Un RUN completo puede tardar más de un minuto porque vuelve a evaluar miles de eventos. La interfaz inicia un trabajo auditable, consulta su estado y mantiene el botón ocupado hasta recibir COMPLETED o FAILED; el proxy no interrumpe la tarea. El operador debe esperar la confirmación final y no crear otro PREVIEW. Un reintento mientras el trabajo está activo reutiliza el mismo identificador, y la simulación actualiza la misma versión operativa de forma idempotente.

La reserva del trabajo se conserva en base de datos durante 15 minutos. Por eso otro navegador, una recarga o una segunda instancia del backend reconocen el mismo PREVIEW activo y no comienzan una simulación paralela. Si el proceso queda realmente abandonado, la reserva vence y el siguiente intento la recupera de forma auditada.

Cada simulación reemplaza el universo completo de decisiones dentro de una sola transacción: bloquea el RUN, verifica que la fuente pertenezca a ese RUN, elimina las decisiones anteriores, inserta el nuevo universo y actualiza métricas y manifiesto. Si cualquier paso falla o excede el tiempo permitido, toda la escritura se revierte; nunca queda una mezcla parcial de decisiones viejas y nuevas.

El manifiesto visible del PREVIEW incluye tres huellas SHA-256:

Una certificación idempotente exige dos simulaciones consecutivas con las tres huellas iguales. También compara antes y después los conteos, importes y últimas actualizaciones de deudas, pagos, recibos, operaciones, saldos a favor, mensajes, notificaciones, correos y tickets. El resultado sólo pasa cuando economicStateStable=true; certificar PREVIEW no materializa cobros.

El certificador persiste un reporte RUNNING después de cada período. Si una simulación falla, escribe FAILED con período, RUN, código de error y comparación económica antes de terminar; una ejecución larga nunca se considera aprobada por ausencia de archivo o por un log incompleto. Sólo status=COMPLETED y passed=true constituyen evidencia válida.

Antes de intentar un match de deuda, el RUN asigna una ruta operativa a cada movimiento. Esta clasificacion evita que el extracto bancario general se trate como un unico lote de cuotas.

Las resoluciones de re-run se incorporan al RUN mensual como evidencia de cierre, no como aplicacion nueva. El sistema exige que la operacion aprobada tenga pago aprobado, deuda del periodo y metadata o link documental de origen. Si aparecen varias operaciones compatibles, el evento sigue bloqueado para desempate humano.

Los perfiles isTestAccount, los pagos isTestRun y cualquier operación que sólo se sostenga en esa evidencia quedan fuera del cierre. El movimiento bancario real se conserva y vuelve a revisión sin profesional; nunca se elimina ni se reasigna automáticamente. La misma guarda aplica aunque nombre, referencia e importe coincidan con datos de un seed.

Como leer el resultado despues de Simular PREVIEW:

Dentro de Decisiones auditadas, el filtro manual se divide en Manual · con profesional y Manual · sin profesional. El primer grupo ya tiene una identidad sugerida para verificar contra deuda e importe; el segundo requiere buscar al profesional o clasificar el movimiento como ruido, liquidacion institucional u otro destino operativo. Al usar Abrir matching, el alcance seleccionado se conserva y aparece el mismo selector en Conciliacion rapida. En los casos con profesional, la identidad auditada por el RUN se muestra como candidato supervisado; no habilita la aplicacion si no se selecciona una deuda y se cumplen las guardas de importe.

Cuando una deuda ya contiene un descuento oficial, la fila muestra Base, descuento y deuda exigible. CBU/COELSA usa la regla vigente del 20% y tarjeta de crédito la del 30%, salvo una regla histórica explícita del período. Si el ingreso supera la deuda ya descontada, no se agrega un segundo descuento: se aplica la deuda exigible y el remanente se registra como saldo a favor. Si la deuda conserva el importe base y el archivo de tarjeta o CBU trae exactamente el valor oficial descontado, el motor entrega el ajuste contable aprobado y habilita el match con esa evidencia.

Para mayo de 2026, los importes de control son:

Un movimiento de tarjeta por $10.930,50 sólo puede imputarse a una deuda compatible con tarjeta 30% y con identidad suficiente. Si esa deuda ya posee una operacion aprobada, la decision del RUN queda de solo lectura y Abrir operacion lleva a la evidencia existente; no se habilita un segundo cobro.

Resultado final SANDBOX por periodo: mayo registra 4.410 eventos, 2.953 cerrados/aplicables, 479 manuales, 114 bloqueados y 864 excluidos; junio registra 4.669 eventos, 3.096 cerrados/aplicables, 705 manuales y 868 excluidos; julio parcial registra 153 eventos, 3 cerrados/aplicables, 104 manuales y 46 excluidos. La cola manual consolidada contiene 249 eventos con profesional y 1.039 sin profesional. Sumando los bloqueados, la cola pendiente completa contiene 1.402 eventos, 1.153 sin profesional.

Resultado final PSICOLE por periodo: mayo registra 2.952 cerrados/aplicables, 480 manuales y 114 bloqueados; junio 3.095 cerrados/aplicables y 706 manuales; julio parcial 107 manuales. La cola pendiente completa contiene 1.407 eventos: 251 con profesional y 1.156 sin profesional al incluir bloqueados. La diferencia neta contra SANDBOX es de cinco decisiones y debe conservarse como estado propio del entorno, no corregirse copiando operaciones.

Certificación de un rerun antes de aplicar

Una tasa de matching alta no demuestra que el RUN sea correcto. Finanzas debe separar dos gates:

El procedimiento reproducible es:

1. Inventariar las fuentes con nombre, rol, período, cantidad de eventos y SHA-256. Marcar salidas derivadas como EXCLUDED; nunca reingestarlas.
2. Guardar un snapshot recuperable y conteos de deudas, pagos, operaciones, recibos, saldos, matches, facturas y comunicaciones.
3. Elegir un baseline y congelar su universo por period + eventKey y por extracto procesado. Un archivo nuevo exige un baseline nuevo; no se compara como si fuera la misma prueba.
4. Ejecutar únicamente PREVIEW. Comparar cada transición de estado y cualquier cambio de profesional.
5. Desglosar cada AUTO_APPLY_STRICT por regla: deuda exacta, CBU 20%, tarjeta 30%, ajuste de aumento u otra regla aprobada. Un match sin regla atribuible no certifica.
6. Auditar los ALREADY_CLOSED: operación, pago, deuda, recibo, reversas, medio y asignación total del importe.
7. Repetir los conteos. Fuera de RUN, fuentes y decisiones, la diferencia debe ser cero.
8. Promover el RUN sólo si ambos gates pasan. Si pasa únicamente PREVIEW seguro, se puede investigar y exportar la cola, pero no materializar pagos.

Controles técnicos del despliegue manual:

# Dos PREVIEW consecutivos por cada RUN operativo; no aplica dinero.
npm run certify:monthly-preview-idempotency -- \
  --periods=2026-05,2026-06,2026-07 \
  --output=/app/tmp/monthly-preview-idempotency.json

# Auditoría de descuentos, beneficios, planes, saldos, prestadores y cobertura.
npm run audit:monthly-financial-integrity -- \
  --periods=2026-05,2026-06,2026-07 \
  --require-manifest=true \
  --strict-test-data=true

# Sólo ante un critical de estado de deuda de plan: generar el plan, sin aplicar.
npm run repair:payment-plan-debt-status -- \
  --target=PSICOLE \
  --periods=2026-05,2026-06,2026-07 \
  --output=/app/tmp/payment-plan-debt-status-plan.json

Antes de certificar un volumen mensual, verificar que exista el índice payments_debt_status_operation_idx. El índice sólo acelera la búsqueda de pagos aprobados por deuda y operación; no cambia importes ni estados. Su migración se ejecuta con ALGORITHM=INPLACE y LOCK=NONE. Un mantenimiento ANALYZE TABLE payments puede actualizar estadísticas, pero la consulta de cierre no depende de que el optimizador elija el índice: lo declara expresamente.

La auditoría distingue critical de warning. Un critical impide promover el RUN y requiere evidencia o reparación separada; un warning se investiga y documenta, pero no se convierte automáticamente en corrupción. En una deuda ordinaria, Debt.finalAmount representa el saldo exigible restante cuando hubo pago parcial o aplicación de crédito. En una deuda IN_PAYMENT_PLAN, en cambio, conserva la obligación congelada que el asignador usa para distribuir las cuotas del plan; el saldo restante se deriva de sus asignaciones aprobadas. La cobertura se calcula una sola vez con pagos aprobados y asignaciones de plan, sin volver a sumar la aplicación del saldo a favor que ya dejó su pago trazable.

Cierre de deudas incluidas en un plan de pago

Una deuda incorporada a un plan no se reduce manualmente con cada cuota. Permanece IN_PAYMENT_PLAN mientras la suma de asignaciones liquidadas sea menor que su obligación congelada. Cuando la cobertura llega al total exacto, pasa a PAID usando como fecha de pago la evidencia liquidada más reciente. El plan, sus cuotas, operaciones, pagos, recibos, importes y asignaciones no se reescriben durante ese cierre.

Si la auditoría detecta una deuda totalmente cubierta que todavía sigue abierta, Finanzas no debe corregirla desde la ficha ni volver a conciliar el ingreso. El procedimiento seguro es:

1. Generar un plan read-only con repair:payment-plan-debt-status para el entorno y períodos correctos.
2. Exigir cero filas bloqueadas y revisar profesional, deuda, plan, cuota pagada y operación aprobada de cada fila.
3. Aplicar únicamente el archivo congelado, con su SHA-256 y cantidad exacta autorizada, manteniendo correos, scheduler y pagos online deshabilitados.
4. Repetir el mismo apply: debe informar cero actualizaciones nuevas y todos los casos como ya aplicados.
5. Volver a ejecutar la auditoría estricta y dos PREVIEW consecutivos. La promoción sólo continúa con criticalTotal=0, hashes idénticos y estado económico/comunicacional estable.

El reparador falla cerrado ante perfiles o deudas test, planes no operativos, más de un plan por deuda, identidad cruzada, cuotas sin operación aprobada, asignación parcial, sobreasignación o evidencia modificada después de generar el plan. No crea recibos, pagos, operaciones, saldos, asientos, mensajes, correos, tickets ni transacciones bancarias.

Control SANDBOX del 12/07/2026 sobre mayo, junio y julio parcial:

Los 182 automáticos quedan explicados por regla: 11 ajustes oficiales por medio de pago (7 CBU y 4 tarjeta), 36 coincidencias exactas contra deudas que ya tenían el descuento correcto (33 CBU y 3 tarjeta), 10 ajustes aprobados por aumento mensual y 125 coincidencias exactas provenientes del extracto general. Otros 248 movimientos tienen profesional identificado, pero no una deuda exacta y elegible; permanecen manuales.

Una segunda corrida independiente (RERUN_CONFIDENCE_V2) sobre el mismo manifiesto reprodujo los 9.232 eventos sin reutilizar decisiones: cero eventos agregados o faltantes, cero cambios de estado, cero reasignaciones y cero efectos económicos o comunicaciones. Sólo se crearon 3 RUNs, 48 fuentes y 9.232 decisiones de auditoría. Esta repetición es obligatoria cuando se modifica una regla de matching: una mejora que no puede reproducirse con marker nuevo no se considera confiable.

La primera certificación encontró 62 operaciones históricas con $199.558,06 sin asignación completa: 18 conflictos explícitos CBU/tarjeta, 43 cobros automáticos contra cuotas con beneficio jubilatorio y una diferencia de redondeo en julio. El hallazgo no fue creado por el rerun. Antes de corregir se generó un plan por operación, backup completo y dry-run; la aplicación quedó limitada por identidad fuerte, match activo único con score 100, mismo profesional/deuda, un pago y recibo aprobados, asiento DRAFT, fuente real y tarifario oficial del período.

La reparación SANDBOX del 12/07/2026 resolvió los 62 casos:

• 18 deudas históricas con fuente CBU se revalorizaron al importe oficial de débito bancario 20%, actualizando pago, recibo, snapshot y asignación contable sin crear saldo artificial;
• 43 cobros sobre cuotas jubilatorias conservaron la deuda al 50% y registraron el excedente como saldo a favor;
• una diferencia bancaria de $2,56 quedó como saldo a favor de redondeo;
• se crearon 44 saldos por $171.086,56; no se generaron mensajes, correos, facturas, avisos, jobs AFIP ni nuevas transacciones bancarias;
• el segundo apply devolvió los 62 casos como alreadyApplied, sin escrituras nuevas.

Una tercera corrida independiente (RERUN_CONFIDENCE_V3) sobre el mismo manifiesto volvió a producir exactamente 9.232 eventos: 5.985 ALREADY_CLOSED, 182 AUTO_APPLY_STRICT, 1.287 manuales y 1.778 excluidos. Comparada con V2 tuvo cero eventos agregados o faltantes, cero cambios de estado, cero reasignaciones de profesional y cero efectos económicos o comunicaciones. Los 21 controles de integridad quedaron en cero y ambos gates pasaron: previewSafe=true y certifiedForApply=true.

Certificación v5 de descuentos y estado financiero del 13/07/2026

Antes de promover el refactor de conciliación se repitieron dos PREVIEW consecutivos sobre los tres RUN operativos. Mayo, junio y julio parcial conservaron exactamente sus universos y produjeron el mismo sourceUniverseHash, eventUniverseHash y decisionHash con el algoritmo monthly-reconciliation-v5. El snapshot protegido de deudas, pagos, recibos, operaciones, saldos a favor y comunicaciones no cambió.

La auditoría financiera read-only recorrió 14.311 cuotas mensuales reales y 11.373 snapshots de descuento. El desglose certificado fue:

El resultado fue passed=true, criticalTotal=0. También se verificaron 384 reglas activas, 90 planes de pago, 168 conceptos externos, 55 saldos a favor, 582 órdenes de prestadores y un solo RUN operativo por período. Una cuota con descuento pero sin DebtBenefitApplication, con dos snapshots de medio, con porcentaje distinto de 20/30 o con importe final incompatible ahora es un error crítico y bloquea la promoción.

La certificación de procedencia de extractos exige período, cantidad de eventos y SHA-256 idénticos al manifiesto congelado. Certificar una fuente no aplica pagos. En el despliegue manual se mantienen DISABLE_ALL_EMAILS=true, PSICOLE_DISABLE_EMAIL_DELIVERY=true, ENABLE_SCHEDULER=false y ONLINE_PAYMENTS_ENABLED=false; cualquier diferencia en esos interruptores cancela la prueba.

Las reparaciones de integridad se preparan por alcance independiente: benefits reconstruye snapshots o revaloriza únicamente deudas abiertas sin cobertura, y plans contrasta plan, fila, nombre y estado contra el XLSX firmado. El plan resultante congela destino, alcance, identificadores, estado previo y SHA-256. Las cantidades se derivan del entorno auditado; nunca se aceptan números hardcodeados de SANDBOX como autorización para PSICOLE. Los pagos ya realizados, las coberturas ambiguas y las filas bloqueadas quedan fuera de ambas acciones y requieren un plan económico separado.

Checklist de promoción:

1. Hacer backup de base y artefactos, con SHA-256 y ruta de rollback.
2. Ejecutar el plan de fuentes y descuentos sin --apply; debe informar cero cambios no explicados.
3. Ejecutar la auditoría estricta; criticalTotal debe ser cero.
4. Repetir dos PREVIEW por cada RUN operativo y exigir hashes iguales y economicStateStable=true.
5. Desplegar backend y frontend sin ejecutar generación de cuotas, matching económico ni envío de lotes.
6. Repetir auditoría, hashes, healthcheck, logs y prueba visual escritorio/móvil.
7. Verificar que pagos, recibos, facturas, mensajes, notificaciones, correos, tickets y transacciones bancarias no hayan aumentado por el despliegue.

No se agregan capturas individuales de la reparación porque muestran nombres, deudas, recibos y referencias bancarias. La evidencia pública reutiliza las vistas genéricas de RUN en escritorio y móvil; el detalle queda respaldado por invariantes de base, auditoría autenticada y el reporte técnico V3.

El matching abierto desde un RUN mensual conserva su período económico. La cabecera muestra de forma explícita el período activo y el alcance de deuda, por ejemplo RUN julio de 2026 · Deudas exigibles hasta julio de 2026. Sólo ofrece deudas del período del RUN o anteriores; nunca muestra una cuota futura como destino de una transferencia histórica. Si el RUN identificó al profesional pero no existe una deuda cobrable dentro de ese alcance, el panel informa esa situación y no habilita una imputación. Esto evita que una transferencia de mayo termine proponiéndose contra una cuota de julio.

La certificación falla cerrada si encuentra una fuente activa, una transacción, una decisión o una deuda vinculada con período posterior al RUN. Un movimiento de julio puede mostrar deudas impagas de mayo, junio y julio porque todas son exigibles al cierre de julio; ese mismo movimiento no puede pertenecer a un RUN de mayo.

Para revisar los bloqueados:

1. Entrar a Dinero -> Operaciones -> Conciliacion -> RUN mensual.
2. Seleccionar el periodo, por ejemplo 2026-06.
3. Elegir el RUN del historial, por ejemplo MRC-2026-06-A0C2CA4F.
4. En Decisiones auditadas, cambiar el filtro a Bloqueadas.
5. Usar Exportar CSV para descargar el listado completo del filtro activo, no solo los primeros eventos visibles. El archivo incluye operationalRoute, operationalBucket y operationalDisposition para depurar por naturaleza del movimiento.
6. Revisar cada evento por fuente, monto, referencia y motivo. Si el motivo dice Sin operacion, pago o match compatible, falta un destino unico en PSICOLE. Si dice Multiples operaciones aprobadas compatibles, requiere desempate humano antes de cerrar.
7. En bloqueados con movimiento bancario, usar Abrir matching para ir a conciliacion rapida con esa transaccion preseleccionada.

Para depurar rechazados, cambiar el filtro a Excluidas y descargar el CSV. Esos eventos conservan estado, motivo, referencia, titular y CBU de la fuente, pero no se abren para aplicar match porque el banco o la tarjeta los informo como rechazados.

Los ajustes mensuales aprobados para diferencias de cuota se administran desde Dinero -> Configuracion -> Ajustes conciliacion. El motor de candidatos lee MONTHLY_FEE_RECONCILIATION_ADJUSTMENTS, de modo que un nuevo periodo no requiere cambiar codigo para reconocer una diferencia aprobada.

Certificacion integral del 18/07/2026

Los RUNs operativos de mayo, junio y julio se reconstruyeron en modo PREVIEW con las fuentes primarias y auxiliares registradas, incluidas cuotas, CBU, tarjeta, extractos Galicia, planes, beneficios, cursos y prestadores. Cada período conserva un único RUN operativo; los RUNs anteriores permanecen como historial auditable y no compiten para aplicar decisiones.

La auditoría estricta recorrió 14.311 cuotas reales en cada entorno y confirmó ausencia de transacciones futuras, deudas futuras seleccionables, identidades de prueba, matches bancarios activos duplicados y efectos económicos creados por el PREVIEW. Dos ejecuciones consecutivas reprodujeron el mismo universo funcional. Las diferencias de manual/cerrado entre entornos corresponden a decisiones humanas ya aplicadas y no se sincronizan por fuerza.

Los marcadores vigentes terminan en 20260718_PROVIDER_PLANS_JULY_V1. La generación de julio se repitió para 4.722 profesionales elegibles: creó 0 cuotas y reutilizó 4.722 por generationKey. Durante toda la certificación permanecieron deshabilitados scheduler, correos, avisos y pagos online; no se crearon cobros, recibos, saldos ni transacciones bancarias reales.

Este cierre habilita la conciliación mensual controlada por operador. No habilita pagos automáticos a prestadores: las órdenes sin nomenclador y la cola de liquidación siguen siendo un gate independiente.

Certificacion operativa PSICOLE del 21/07/2026

El cierre total de mayo, junio y julio incorporó el segundo extracto parcial de Galicia de julio (438 créditos, sin superposición con el parcial anterior) y promovió un único RUN operativo por período. El replay de la importación insertó 0 movimientos, por lo que la fuente quedó confirmada como idempotente.

La cola manual consolidada representa $57.596.140,74. Es una cola de clasificación e imputación asistida, no deuda nueva ni dinero perdido. Las filas con profesional identificado se revisan primero; las restantes deben clasificarse como colegiación, arancel, curso, liquidación institucional, proveedor, transferencia interna o movimiento no acreditado antes de elegir un destino económico.

La certificación agregó dos guardas al PREVIEW estricto: una misma deuda no puede ser reclamada por dos movimientos del RUN y un movimiento con cualquier historial de operación económica no vuelve a presentarse como autoaplicable. Los 18 casos detectados por estas guardas quedaron en revisión manual. Dos replays consecutivos de cada período reprodujeron el mismo hash funcional y dejaron delta cero en deudas, pagos, recibos, operaciones, saldos, banco, planes, prestadores, tickets y comunicaciones.

3. Matching manual

1. En la sesión, filtrar por estado PENDIENTE para ver las transacciones sin match automático.
2. Seleccionar una transacción del extracto; el panel derecho mostrará los pagos candidatos sugeridos por similitud.
3. Revisar identidad, deuda e importe. Dentro de un RUN mensual, la única deuda del mismo período queda preseleccionada; una decisión estricta ya auditada conserva prioridad. Si hay más de una deuda posible para el período, el sistema no elige y exige selección explícita. Si la suma seleccionada coincide a centavos, hacer clic en Match.
4. Si el importe no coincide, usar la opción que corresponda dentro de la misma fila:
5. Aplicar + saldo: cancela la deuda y registra el excedente como saldo a favor disponible.
6. Pago parcial: aplica el ingreso a una sola deuda y conserva el remanente pendiente.
7. Ignorar / Excluir: excluye la transacción cuando no corresponde a un profesional.
8. Las diferencias requieren una nota de aprobación de al menos 10 caracteres.
9. Repetir hasta resolver todas las transacciones pendientes.

Pago parcial se usa únicamente cuando la identidad y el medio de cobro coinciden y el banco acredita menos que la deuda exigible por un hecho real documentado. No se usa para corregir una diferencia entre CBU 20% y tarjeta 30%, ni para volver a cobrar una decision ALREADY_CLOSED.

Resolver una cuota entre CBU 20% y tarjeta 30%

Este flujo se usa cuando el ingreso coincide exactamente con uno de los importes oficiales del período, pero la deuda conserva un método de cobro ausente, incorrecto o heredado. Está disponible en PSICOLE como acción controlada dentro del matching existente. No es una regla automática: siempre exige evidencia única, nota y aprobación humana.

La acción sólo aparece cuando el sistema puede demostrar todas estas condiciones:

• identidad global única por CUIT/DNI o nombre completo exacto;
• extracto, transacción, RUN y deuda del mismo período;
• una sola deuda mensual abierta y una sola alternativa oficial compatible a centavos;
• tarifario oficial vigente para el período;
• ausencia de jubilación, beneficio parental u otro descuento incompatible;
• un único snapshot de medio de pago y procedencia económica confiable;
• ningún conflicto entre el tipo explícito del extracto y el método propuesto.

Procedimiento del operador:

1. Abrir el movimiento desde el RUN operativo del mes y comprobar período, titular, profesional y matrícula.
2. Revisar el bloque Método 20%/30% por confirmar: base, descuento, saldo exigible y nivel de evidencia. Si el profesional tiene deudas de meses anteriores, comprobar que la fila marcada diga RUN: cuota del mismo período. Una decisión estricta existente puede señalar otra deuda; cualquier duplicado o ambigüedad exige selección manual.
3. Si la evidencia es correcta, pulsar Aplicar 20% o Aplicar 30% e ingresar una nota de al menos 10 caracteres.
4. Confirmar sólo una vez. El backend recalcula la regla bajo lock, actualiza únicamente el snapshot de esa deuda y materializa pago, recibo, operación y decisión del RUN en una transacción atómica e idempotente.
5. Verificar que el movimiento salga de la cola manual y que la ficha del profesional muestre la cuota cancelada con su medio y operación trazables.

La resolución no cambia la adhesión maestra del profesional. Si corresponde corregir el método futuro, se hace por el circuito de adhesión después de revisar la evidencia; nunca se infiere una suscripción permanente desde una sola transferencia. Si hay dos alternativas posibles, monto aproximado, identidad ambigua, beneficio concurrente, fuente test o contradicción del extracto, no aparece la acción y el caso permanece en revisión.

Si una conciliación histórica fue revertida, la operación cancelada no se borra ni se reutiliza. PSICOLE sólo permite supersederla cuando el pago está rechazado o reintegrado, el recibo está anulado, los movimientos de cuenta corriente netean cero y no existen vínculo bancario activo, saldo a favor, reversión, match confirmado, trabajo AFIP ni asiento contabilizado. En ese caso archiva la clave de fuente anterior, anula únicamente asientos DRAFT y enlaza en ambos sentidos la operación cancelada con su reemplazo. Todo ocurre dentro de la misma transacción del nuevo match. Si queda cualquier efecto económico o contable, la acción se bloquea para revisión y no modifica deuda, pago, recibo, operación ni decisión del RUN.

Antes de habilitar el piloto se ejecuta project-payment-method-resolution.mjs en modo sólo lectura. El control debe repetirse dos veces y producir el mismo resultado normalizado, con economicCountsUnchanged=true. La proyección SANDBOX del 14/07/2026 detectó 11 casos: 7 CBU 20%, 4 tarjeta 30%, 1 conflicto histórico que exige aprobación explícita y 0 desacuerdos entre el profesional/deuda del RUN y el destino calculado. La proyección no creó pagos, recibos, operaciones, saldos, notificaciones ni correos.

La promoción manual a PSICOLE repitió el mismo protocolo antes de habilitar el flag: dos proyecciones con el flag apagado, dos con el flag encendido y dos PREVIEW consecutivos para cada RUN operativo de mayo, junio y julio. Se detectaron 11 candidatos por $132.710,00 (7 CBU y 4 tarjeta), con un conflicto explícito y cero desacuerdos de destino. Ningún candidato fue aplicado durante la certificación; pagos, recibos, operaciones, deudas, saldos, notificaciones y correos conservaron sus contadores.

La auditoría de producción recorrió 14.311 cuotas mensuales y 11.373 snapshots de descuento, además de reglas de jubilación y primera matrícula, planes de pago, conceptos externos y órdenes de prestadores. El resultado fue criticalTotal=0. Los antecedentes parentales vencidos o pendientes de revisión no se activaron por inferencia. La prueba visual autenticada confirmó filtros, acciones 20%/30%, conflicto visible, deuda del período, escritorio y móvil sin desborde, sin ejecutar acciones económicas.

Después de materializar tres muestras auditadas, incluida una operación histórica cancelada y económicamente neutralizada, quedaron 8 casos por $96.795,50: 5 CBU 20% y 3 tarjeta 30%. Los siete casos no conflictivos restantes se aprobaron después, uno por uno, desde la UI: 4 CBU 20% y 3 tarjeta 30%. En total se resolvieron 10 casos por $120.218,00; cada uno creó exactamente un pago, un recibo, una operación, un match y una auditoría, sin crear saldos a favor, notificaciones ni correos.

El caso residual por $12.492,00 se mantuvo bloqueado hasta contrastar Galicia, recibos y respuestas del procesador por período. Galicia y el recibo identificaron un pago bancario de mayo; no existía tarjeta en la fuente de mayo y la tarjeta hallada en junio había sido rechazada. Con backup y aprobación explícita se reclasificó únicamente la deuda de mayo a CBU 20%. La adhesión maestra y las cuotas de junio/julio no cambiaron.

La proyección de cierre se repitió dos veces con el mismo hash normalizado 4c8ed073e07c73abb30aabedb992624db500f65bd87c66b4d0a254d4c2ed57b1, economicCountsUnchanged=true, cero casos restantes, cero conflictos y cero desacuerdos de destino. En total se resolvieron 11 casos por $132.710,00, siempre de forma individual; no existe aplicación masiva.

Una respuesta rechazada de CBU o tarjeta nunca activa el medio ni revalúa la cuota. Sólo una respuesta aceptada puede intervenir, y siempre para su propio período. Si dos métodos aceptados compiten por el mismo profesional y mes, el migrador bloquea ambos y exige revisión.

Aplicar la cuota completa después de un rechazo validado

Este flujo cubre el caso en que el procesador rechazó el débito automático de una cuota y, dentro del mismo período, el profesional pagó por transferencia el importe base completo. No es un cambio de método permanente ni un pago parcial: revierte únicamente el descuento por cobro automático de esa deuda y aplica el ingreso por el total de la cuota.

La acción Aplicar cuota completa sólo aparece cuando PSICOLE puede demostrar simultáneamente:

• identidad única y exacta por DNI/CUIT entre movimiento, profesional y deuda;
• transferencia bancaria general acreditada, positiva y pendiente;
• respuesta rechazada de CBU o tarjeta para el mismo profesional, período y deuda;
• motivo o código de rechazo conservado en la fuente primaria;
• importe transferido exactamente igual a la base oficial de la cuota;
• ausencia de otros beneficios, pagos, saldos o fuentes aceptadas incompatibles;
• RUN, movimiento y deuda del mismo período, sin procedencia test.

Procedimiento del operador:

1. Abrir el movimiento desde el RUN del período y verificar titular, DNI/CUIT, matrícula e importe.
2. Revisar la evidencia del rechazo: fecha, medio, código o motivo y fuente primaria.
3. Confirmar que Base, descuento a revertir y deuda exigible correspondan a una única cuota.
4. Pulsar Aplicar cuota completa e ingresar una nota que explique el rechazo y la transferencia posterior.
5. Verificar la operación PAY, el recibo, la cuota PAID y los dos documentos vinculados: transferencia acreditada y respuesta rechazada.

La confirmación ocurre en una única transacción idempotente. Actualiza sólo la deuda del período, elimina únicamente su snapshot de descuento por débito/tarjeta, crea un pago y un recibo por el importe base, y enlaza ambas evidencias. No crea saldo a favor, no reactiva ni suspende la adhesión maestra, no modifica cuotas futuras y no envía avisos ni correos. Si falta una condición, el caso permanece en revisión manual.

Evidencia visual: se validaron escritorio 1440x900 y móvil 390x844 en SANDBOX para ambas alternativas, incluida nota obligatoria y cancelación sin efectos. Las capturas de detalle no se publican porque contienen nombres, matrículas, importes y referencias bancarias reales; se conserva la evidencia técnica de viewport, consola e invariantes económicas.

Después de confirmar un match dentro de un RUN mensual, PSICOLE cierra solamente la decisión correspondiente y actualiza sus métricas. No vuelve a simular todas las fuentes por cada fila. La transacción resuelta desaparece de la cola y el operador puede continuar inmediatamente con la siguiente. El recálculo o la simulación completa se reserva para el control del lote, después de una tanda de decisiones.

Registrar un pago anticipado sin imputar una cuota futura

Este caso se usa cuando el RUN identifica inequívocamente al profesional, pero no existe deuda cobrable en el período del extracto. Es el caso típico de un pago de mayo que debe quedar disponible para una cuota posterior. La cuota futura se muestra sólo como referencia y no es seleccionable desde el RUN histórico.

1. Abrir el movimiento desde Dinero -> Operaciones -> Conciliación -> RUN mensual -> Manual -> Abrir matching.
2. Verificar que el candidato sea el profesional identificado por el RUN y que el panel indique Sin deuda cobrable en el período del RUN.
3. Revisar la Próxima deuda informativa sólo para orientar el seguimiento. No se imputa el movimiento contra junio/julio desde el matching de mayo.
4. Pulsar Registrar pago anticipado y confirmar que el ingreso no sea un duplicado ni un reintegro. La nota de aprobación es obligatoria.
5. El movimiento queda MANUAL_MATCHED, la decisión del RUN queda ALREADY_CLOSED y se crea un Saldo a favor abierto por el importe total recibido.
6. Para consumirlo en otro período, abrir el perfil del profesional en Cuenta Corriente -> Saldos a favor -> Aplicar, elegir la deuda abierta y confirmar la aplicación con nota. Esta aplicación interna no crea otro movimiento bancario ni envía avisos.

Reglas de seguridad: el extracto y el RUN deben compartir período de origen; sólo se acepta un crédito bancario pendiente; el profesional debe estar activo y ser cobrable; si existe deuda pendiente hasta el período del RUN, el botón no se habilita. La operación usa una clave idempotente por movimiento y profesional, crea auditoría, recibo interno y trazabilidad hacia banco, operación, pago, crédito y profesional. El recibo de saldo a favor no se envía a AFIP mientras el importe no esté aplicado a una deuda.

Si el mismo comando se reintenta por demora o doble clic, PSICOLE recupera la operación ya creada y no duplica pago, recibo ni saldo. Si el reintento cambia profesional, deuda, importe, RUN o destino económico, se rechaza como conflicto. Si se intenta usarlo con el RUN de otro mes, devuelve BANK_ACCOUNT_CREDIT_RUN_PERIOD_MISMATCH; la deuda futura permanece intacta.

Guardas de procedencia e idempotencia

Antes de materializar un match, un pago anticipado o una aplicación de saldo, PSICOLE verifica la procedencia de toda la cadena económica. La guarda no borra ni corrige datos históricos: cuando la evidencia es incompleta o de prueba, conserva el registro y bloquea la nueva acción para revisión.

Comprobar idempotencia sin aplicar dinero

El control está integrado en las dos superficies existentes de Dinero; no crea una pantalla ni un flujo paralelo:

• En RUN mensual -> Comprobar idempotencia, PSICOLE ejecuta dos veces el mismo PREVIEW con iguales fuentes y parámetros. Compara cantidades, importes, destinos, sourceUniverseHash, eventUniverseHash y decisionHash. También toma un snapshot antes y después de deudas, pagos, recibos, operaciones, saldos y comunicaciones.
• En Ficha única de operación -> Trazabilidad -> Comprobar idempotencia, realiza dos lecturas funcionales, compara la huella de la operación y sus vínculos, y busca otro comando activo cuando el origen admite una sola operación. Pagos parciales de una misma deuda no se confunden con duplicados. Las reversas múltiples se elevan a revisión humana.

Los resultados son:

La comprobación es inerte: no crea pagos, recibos, saldos, cuotas, mensajes, notificaciones ni transferencias. Un PASS confirma repetibilidad técnica; no reemplaza la revisión humana de identidad, período, importe, beneficio, plan o medio de cobro.

La acción queda bloqueada cuando ocurre cualquiera de estas condiciones:

• el movimiento bancario, la deuda, el pago o el profesional están marcados como test;
• el extracto o la metadata contienen marcadores de SANDBOX, TEST, SEED, FIXTURE, MOCK o SYNTHETIC;
• un saldo a favor proviene de un pago o movimiento de prueba;
• una cuota figura pagada sin ningún pago aprobado enlazado, o sólo tiene pagos aprobados de procedencia no confiable;
• el movimiento ya fue resuelto con otro profesional, otra deuda, otro RUN o una disposición de importe diferente.

En esos casos la interfaz muestra Revisar evidencia y deshabilita la aplicación económica. Los códigos UNTRUSTED_MONEY_PROVENANCE, UNTRUSTED_ACCOUNT_CREDIT_PROVENANCE y PROFESSIONAL_PAYMENT_PROVENANCE_REVIEW_REQUIRED identifican el motivo técnico para auditoría.

Certificar un extracto real espejado desde SANDBOX

Una marca sandbox-run no se elimina manualmente ni se ignora. Si el archivo es un extracto real que fue cargado primero en SANDBOX y luego espejado, Conciliación rápida ofrece Certificar fuente por SHA-256 sólo cuando se cumplen todas estas condiciones:

• el extracto está PROCESSED, tiene nombre no-test y pertenece al mismo período del RUN;
• el RUN operativo contiene una fuente PRIMARY o AUXILIARY NORMALIZED para ese extracto;
• la fuente pertenece a un canal financiero certificable: extracto bancario general (BANK_STATEMENT), lote CBU/COELSA (BANK_DEBIT) o liquidación de tarjeta (CREDIT_CARD);
• el hash SHA-256 del manifiesto coincide exactamente con el hash original conservado por el extracto;
• el manifiesto declara sourceOrigin=local_manifest y safeForSimulation=true;
• la cantidad de eventos coincide entre archivo, extracto y fuente;
• ningún otro extracto posee el mismo hash real.

Al confirmar, el operador ve el archivo, RUN, cantidad de movimientos, operaciones y pagos afectados, e ingresa una nota de al menos 20 caracteres. La acción certifica el extracto completo, no una fila aislada. Normaliza los flags técnicos heredados y agrega provenanceCertification a las operaciones vinculadas, preservando los marcadores legacy para auditoría. No crea pagos, no concilia movimientos y no cambia deudas. Un segundo intento devuelve la certificación existente sin duplicar cambios.

La certificación usa la misma política para Galicia, CBU/COELSA y tarjeta. El tipo de canal no reemplaza la evidencia: si nombre, período, SHA-256, cantidad de eventos, rol o estado no coinciden, la fuente queda bloqueada. Caja, recibos, padrón, prestadores y archivos de referencia no son fuentes certificables de movimientos bancarios aunque formen parte del RUN.

Después de certificar:

1. Actualizar la fila y verificar que desaparezca el bloqueo de fuente.
2. Revisar profesional, deuda, regla de descuento e importe.
3. Aplicar Match, Aplicar + saldo o Pago parcial según el hecho económico.
4. Recalcular el mismo RUN operativo y comprobar que el evento pase de bloqueado/manual a cerrado.

No se publica una captura individual de esta confirmación porque contiene titular, importe y referencia bancaria. La evidencia visual pública reutiliza la entrada al RUN en SANDBOX; la certificación queda demostrada por pruebas backend, auditoría y verificación E2E autenticada.

Cada comando económico exige una Idempotency-Key. La misma clave, el mismo operador y el mismo contenido devuelven el resultado existente; cambiar operador, cuerpo, parámetros de ruta o RUN devuelve conflicto. Si el almacén idempotente no está disponible, el backend responde 503 y no inicia el comando. Además, la operación PAY conserva un hash semántico de fuente, profesional, deudas, importe y destino para detectar reintentos incompatibles aunque cambie la clave HTTP.

La fila seleccionada, el detalle y el comando también comparten un token de contexto del movimiento. Mientras ese contexto se actualiza, la lista no avanza y los botones quedan deshabilitados. Si el movimiento cambió o el operador intenta confirmar con el detalle de otra fila, PSICOLE responde BANK_TRANSACTION_CONTEXT_STALE, conserva ambos movimientos sin cambios y exige actualizar antes de volver a revisar. BANK_TRANSACTION_CONTEXT_REQUIRED indica un cliente desactualizado que debe recargar la aplicación.

En un entorno tratado como producción, la aplicación interna requiere además ALLOW_BANK_RECONCILIATION_APPLY=true. Si falta esa habilitación, el backend responde PRODUCTION_CONSENT_REQUIRED sin crear pagos, recibos ni matches. Esta bandera no habilita correos, scheduler, débitos automáticos ni pagos online; esos circuitos mantienen sus controles independientes.

Si el resultado económico se confirmó pero falló únicamente el registro de su respuesta idempotente, la interfaz reintenta una vez con la misma clave para recuperar la operación existente. El operador no debe volver a crear el pago ni cambiar de RUN: debe esperar la recuperación o recargar la fila. Este mecanismo sólo actúa ante códigos técnicos de idempotencia; nunca reintenta automáticamente un rechazo de procedencia, importe, identidad o regla de negocio.

La transacción bancaria, el profesional y las deudas se bloquean mientras se materializa el match. El pago, recibo, operación, saldo y decisión del RUN se confirman en una única transacción de base de datos. El recálculo de métricas puede quedar como advertencia posterior, pero no modifica el resultado económico ya confirmado.

La confirmación legacy de propuestas queda deshabilitada para materialización. La ruta operativa es Conciliación rápida, que aplica las guardas, locks, idempotencia y auditoría. El aprendizaje supervisado sólo ordena candidatos: incluso una regla TRUSTED conserva los flags económicos calculados por las guardas y nunca autoriza por sí sola un pago.

La evidencia visual pública muestra la entrada al flujo en SANDBOX. La captura del bloqueo sobre un movimiento individual no se publica porque contiene titulares e importes bancarios; su validación E2E se conserva en el reporte técnico de la Fase 0.

Aprendizaje supervisado del matching

Cada match bancario confirmado por un operador registra una regla de asociacion entre la huella del movimiento y el profesional elegido. La regla no reemplaza la validacion de deuda, importe, signo ni estado del movimiento: solamente agrega evidencia para ordenar candidatos en corridas posteriores.

Los estados son:

Procedimiento recomendado para entrenar sin introducir falsos positivos:

1. Trabajar un periodo por vez desde RUN mensual -> Manual -> Abrir matching.
2. Confirmar identidad por DNI, matricula, CBU o nombre completo consistente; nunca por monto aislado.
3. Elegir la deuda o las deudas efectivamente cubiertas. Para una diferencia, usar Aplicar + saldo o Pago parcial con nota.
4. Registrar como ruido todo egreso, liquidacion institucional, gasto interno o movimiento ajeno a un colegiado.
5. Recalcular el PREVIEW y verificar que el movimiento resuelto pase a cerrado y que futuros movimientos comparables mejoren su candidato.
6. Ante una asignacion incorrecta, revertir la operacion y suspender la regla; no compensar editando estados manualmente.

Aplicar y consumir saldos a favor

Cuando una transferencia supera la deuda seleccionada, PSICOLE separa el hecho económico:

1. La deuda recibe sólo el importe que la cancela.
2. El excedente se registra como Saldo a favor, con monto original y disponible, vinculado a banco, PAY, pago a cuenta y recibo.
3. Contabilidad debita Banco por el total recibido, acredita Ingresos por la deuda y acredita el excedente en 2.1.4 Saldos a favor de profesionales.
4. El saldo queda visible en Cuenta Corriente del perfil administrativo y del profesional.
5. Desde el perfil administrativo, el operador puede pulsar Aplicar, elegir una deuda abierta y confirmar con nota. La aplicación no crea otro movimiento bancario: debita el pasivo y acredita el ingreso correspondiente.

El saldo también se informa en el candidato de Conciliación rápida. Esa indicación es contextual: no convierte el crédito en una segunda transferencia ni lo aplica automáticamente. Para consumirlo, abrir el perfil del profesional, entrar en Cuenta Corriente -> Saldos a favor, pulsar Aplicar y seleccionar una deuda abierta.

Al pasar al RUN del mes siguiente:

1. El movimiento bancario que originó el excedente permanece cerrado en su mes de origen.
2. El saldo disponible permanece en la cuenta corriente hasta que exista una aplicación aprobada.
3. Si la cuota del mes siguiente ya está pagada, no se modifica y el saldo continúa disponible.
4. Si existe una deuda abierta, el operador puede aplicarle hasta el menor valor entre saldo disponible y deuda.
5. La aplicación crea trazabilidad interna y reduce ambos saldos; no crea otra transacción bancaria ni vuelve a enseñar el mismo movimiento al matcher.

Ejemplo: un ingreso de $15.615 aplicado a una cuota de $12.492 cancela la cuota y crea $3.123 de saldo a favor. Si junio ya está pagado, el crédito no se fuerza contra junio. Puede aplicarse luego a una deuda de julio de $13.085,95, que quedaría con $9.962,95 pendiente.

La aplicación es idempotente, reduce simultáneamente el saldo disponible y el saldo de la deuda y no envía comunicaciones. Si el crédito o la deuda cambian mientras se confirma, la operación se rechaza y debe recargarse el perfil.

El recibo interno conserva la trazabilidad del dinero recibido. El excedente permanece como pasivo y no debe facturarse como ingreso por cuota mientras siga disponible. La cola AFIP vigente es simulada; cualquier integración fiscal real debe tomar el importe aplicado a deuda y excluir el saldo a favor.

Seguimiento posterior desde Profesionales

Una vez aplicada una diferencia, la cola de seguimiento se prepara desde la vista existente Matrículas -> Profesionales. La columna Saldo a favor es ordenable y el filtro Saldo / deuda permite separar créditos disponibles, deudas, créditos que cubren la deuda y cuentas sin saldo pendiente. La fila conserva la deuda en Cuota / Deuda aunque exista un crédito; sólo la aplicación aprobada cambia la deuda.

La métrica Con saldo a favor muestra cuántos perfiles tienen crédito disponible y funciona como acceso al filtro. El listado se calcula sobre el conjunto total, no sobre la página actual, por lo que sirve para revisión y eventual comunicación. La consulta no envía mensajes ni modifica operaciones: antes de contactar a un profesional, revisar su Cuenta Corriente, el estado del crédito (Disponible, Aplicado parcialmente, Aplicado o Reversado) y la nota de aprobación.

4. Cerrar sesión de conciliación

1. Una vez resueltas todas las transacciones (o decidido ignorar las irresolubles), hacer clic en Cerrar Sesión.
2. El sistema muestra el resumen final: total importado, total conciliado, total no identificado, diferencia.
3. Si la diferencia es cero o está dentro del umbral configurado, confirmar el cierre.
4. La sesión pasa a estado CERRADA y queda disponible en el historial con todos sus datos de auditoría.
5. Se genera automáticamente el informe de cierre descargable en PDF.

5. Consultar auditoría

1. Ir a Finanzas → Conciliación Bancaria → Historial de Sesiones.
2. Seleccionar la sesión a auditar y hacer clic en Ver Detalle.
3. La vista de auditoría muestra: usuario que realizó cada acción, timestamp, estado anterior y nuevo, y justificación ingresada.
4. Usar los filtros por usuario, fecha o tipo de acción para acotar resultados.
5. Exportar el log de auditoría en CSV si se requiere para revisión externa.

Campos y validaciones

Reglas de negocio

Errores frecuentes

Preguntas frecuentes

¿Qué formatos de archivo se soportan? Se soportan archivos .csv (separado por coma o punto y coma) y .xlsx. El sistema reconoce automáticamente el formato según el banco seleccionado. Si el banco no está en la lista, contactar al administrador para configurar un nuevo perfil de importación.

¿Qué pasa si el mismo pago aparece en dos extractos? El sistema detecta la transacción como duplicada durante la importación y la bloquea. Solo puede existir un emparejamiento por pago en PSICOLE. Si se requiere corregir un emparejamiento previo, el ADMIN debe revertirlo desde la sesión original.

¿Puedo conciliar pagos de pasarelas como NAVE? Sí. El pago aprobado por la pasarela crea la operación y el recibo; luego la liquidación de la pasarela debe cuadrar contra el extracto bancario. El sistema evita duplicados con referencias externas, operación PAY, monto, fecha y claves idempotentes.

¿Se puede reabrir una sesión cerrada? Solo el ADMIN puede reabrir una sesión cerrada, siempre que no existan sesiones posteriores para el mismo banco que dependan de ella. La reapertura queda auditada.

¿Qué significa "No Identificado"? Una transacción marcada como "No Identificado" es un ingreso o egreso en el extracto que no tiene correspondencia con ningún pago en PSICOLE. Debe ser investigada manualmente con el banco para determinar su origen.

🖥 Escritorio Consultorio, pacientes y agenda del profesional

📱 Móvil Consultorio, pacientes y agenda del profesional

Consultorio

Consultorio es la agenda operativa del psicólogo dentro de PSICOLE. Puede usarlo un psicólogo colegiado aunque no sea prestador, y también un prestador cuando trabaja con órdenes de obras sociales.

Acceso

Menú: Órdenes → Consultorio
Ruta: /consultorio
Roles: COLEGIADO, PRESTADOR.

Activación

El módulo puede estar activo o desactivado por profesional.

La activación no obliga a ser prestador. Un colegiado puede usarlo de forma autónoma para agenda, pacientes y cobros particulares. Si además es prestador, puede generar órdenes PSICOLE desde una sesión.

Flujo principal

1. Crear o elegir paciente.
2. Agendar turno con fecha, hora, modalidad y notas internas.
3. Configurar recordatorios y, si corresponde, exportar agenda .ics.
4. Completar sesión.
5. Generar orden de obra social o cobro particular.

Pacientes

La libreta de pacientes permite reutilizar datos en turnos y órdenes:

• Nombre y documento.
• Contacto.
• Obra social, si existe.
• Tratamientos o sesiones previas.
• Historial de órdenes y cobros asociados.

Al crear una nueva orden, el sistema debe sugerir pacientes y tratamientos ya utilizados para reducir carga manual.

Prestadores y obras sociales

Cuando el profesional es prestador, Consultorio puede terminar una sesión como orden PSICOLE. En ese caso se aplican las reglas de prestadores:

• Obra social habilitada.
• Datos de afiliado.
• Diagnóstico y nomenclador cuando corresponda.
• Adjuntos y autorización.
• Rendición posterior ante la obra social.

Si el profesional no trabaja con obras sociales cargadas en PSICOLE, puede usar Consultorio de forma autónoma con pacientes, turnos, cobros particulares y recordatorios.

Cobros particulares

Los cobros particulares forman parte del ciclo de dinero. Cuando se registran, deben crear operación trazable y, si corresponde, recibo.

El cobro no debe mezclarse con una orden de obra social salvo que el flujo indique expresamente copago, diferencia o cargo complementario.

Buenas prácticas

• Mantener un paciente único por persona para evitar duplicados.
• Registrar el turno antes de la sesión y completarlo al finalizar.
• Usar notas internas solo para gestión profesional; no incluir datos innecesarios en comprobantes.
• Revisar la agenda semanalmente para detectar turnos sin cerrar.

Cursos y Capacitación

Descripción

El módulo de Cursos y Capacitación gestiona la oferta formativa del Colegio: talleres, jornadas, seminarios y cursos de actualización profesional. Soporta tres modalidades —presencial, virtual e híbrida— con configuración independiente de cupos, aula/link de videoconferencia y cronograma de encuentros.

Las inscripciones incluyen un sistema de lista de espera automática: cuando se completan los cupos, los nuevos interesados quedan en lista y son promovidos en orden cuando se libera un lugar o se amplía el cupo. El módulo también gestiona prerequisitos (cursos anteriores o condición de matrícula activa), materiales descargables y la emisión de certificados digitales con código QR verificable públicamente.

El pago puede ser en un solo desembolso o en cuotas, con vencimientos y recargos configurables por curso. Los certificados se emiten automáticamente cuando el colegiado completa la asistencia mínima requerida y tiene el pago al día.

Roles con acceso

Flujo principal

1. Crear un nuevo curso

1. Ir a Cursos → Gestión de Cursos (/admin/courses) y usar Nuevo Curso.
2. Completar los datos generales: nombre, descripción, modalidad (presencial / virtual / híbrido), fechas de inicio y fin, cupo máximo y cupo mínimo (por debajo del cual el curso puede cancelarse).
3. En la sección Encuentros, agregar cada sesión con fecha, hora, duración y aula o link de videoconferencia.
4. En Prerequisitos, seleccionar los cursos previos requeridos y/o marcar si se requiere matrícula activa.
5. En Aranceles, configurar si el pago es único o en cuotas, ingresando monto, cantidad de cuotas y fecha de cada vencimiento.
6. En Materiales, subir los archivos que serán accesibles a los inscriptos (PDF, video, enlace externo).
7. Hacer clic en Guardar como Borrador o Publicar para que quede visible en el catálogo del colegiado.

2. Gestionar inscripciones

1. Ir a Cursos → Gestión de Cursos (/admin/courses) y abrir el curso correspondiente.
2. La lista muestra todos los inscriptos con estado (Confirmado, Pendiente de Pago, Lista de Espera, Baja).
3. Para inscribir manualmente a un colegiado: clic en Agregar Inscripto, buscar por apellido o número de matrícula, seleccionar y confirmar.
4. El sistema verifica automáticamente los prerequisitos y rechaza la inscripción si no se cumplen, indicando el motivo.
5. Si el cupo está completo, el sistema ofrece agregar al interesado a la lista de espera.
6. Para dar de baja a un inscripto: seleccionarlo, clic en Dar de Baja, indicar el motivo y si aplica reembolso.

3. Administrar lista de espera

1. En la pestaña Lista de Espera del curso, se visualizan los interesados en orden de anotación (posición 1, 2, 3…).
2. Cuando se libera un cupo (baja de inscripto o ampliación de cupo), el sistema notifica automáticamente por email al primero en la lista.
3. El interesado tiene un plazo configurable (por defecto 48 horas) para confirmar su inscripción y abonar.
4. Si no confirma en el plazo, pasa al final de la lista y se notifica al siguiente.
5. El operador puede mover manualmente a un interesado dentro de la lista ingresando justificación.

4. Registrar asistencia

1. En Cursos → Gestión de Cursos (/admin/courses), abrir el curso y seleccionar Asistencia para el encuentro del día.
2. La lista muestra todos los inscriptos confirmados con checkbox de presente/ausente.
3. Marcar la asistencia y hacer clic en Guardar Asistencia.
4. El sistema calcula automáticamente el porcentaje de asistencia acumulado de cada participante.
5. Al alcanzar la asistencia mínima configurada (ej. 75%), el participante queda habilitado para recibir su certificado.

5. Emitir certificados digitales con QR

1. Ir a Cursos → Gestión de Cursos (/admin/courses), abrir el curso y seleccionar Certificados.
2. El sistema lista los participantes que cumplen los requisitos de asistencia y pago.
3. Hacer clic en Emitir Certificados para procesarlos en lote, o en Emitir en la fila de un participante específico.
4. El certificado se genera en PDF con los datos del colegiado, nombre del curso, fecha, horas de capacitación y un código QR único.
5. El QR apunta a una URL pública de verificación donde cualquier persona puede confirmar la autenticidad del certificado.
6. El certificado queda disponible en el portal de autogestión del colegiado para su descarga.

6. Cargar y gestionar materiales

1. En Cursos → Gestión de Cursos (/admin/courses), abrir el curso y seleccionar Materiales.
2. Elegir el tipo: archivo subido (PDF, DOCX, PPTX, video) o enlace externo.
3. Ingresar el nombre del material y, opcionalmente, el número de encuentro al que corresponde.
4. Configurar la visibilidad: Libre (visible antes de inscribirse) o Solo Inscriptos.
5. Los inscriptos confirmados con pago al día pueden descargar los materiales desde su portal de autogestión.

7. Desinscripción y reembolso

Desde Mis Cursos, el usuario puede abrir el detalle de una inscripción y solicitar desinscripción cuando el curso y la política vigente lo permiten.

El sistema distingue:

La política de reembolso se configura desde Dinero → Configuración. Toda devolución debe quedar vinculada a la operación de pago original para conservar trazabilidad.

Campos y validaciones

Reglas de negocio

Errores frecuentes

Preguntas frecuentes

¿Puede un colegiado inscribirse en varios cursos simultáneamente? Sí, no hay límite de inscripciones simultáneas. Sin embargo, si dos cursos tienen encuentros en el mismo horario, el sistema muestra una advertencia (no bloquea la inscripción).

¿Cómo se manejan las cuotas vencidas? Las cuotas vencidas generan una deuda en la cuenta corriente del colegiado. Después de X días de mora (configurable), se suspende el acceso a los materiales del curso. El certificado no se emite mientras haya cuotas impagas.

¿Se puede inscribir a alguien en lista de espera directamente? Sí, el operador puede agregar manualmente a una persona en lista de espera incluso cuando hay cupos disponibles (ej. si el interesado quiere esperar por razones económicas). En ese caso queda al final de la lista con estado EN_ESPERA_VOLUNTARIA.

¿El QR del certificado funciona sin conexión a internet? No. El QR apunta a una URL del sistema PSICOLE. Para verificar la autenticidad del certificado se requiere conexión. El PDF del certificado puede descargarse y compartirse offline, pero la verificación del QR es siempre online.

¿Cómo se comunica a los inscriptos cuando se cancela un curso? Al confirmar la cancelación, el sistema envía automáticamente un correo a todos los inscriptos (incluyendo lista de espera) y procesa los reembolsos configurados. No requiere acción manual adicional del operador.

🖥 Escritorio Portal de prestadores y órdenes de obra social

📱 Móvil Portal de prestadores y órdenes de obra social

Prestadores y Órdenes de Servicio

Descripción

El módulo de Prestadores gestiona la relación entre el Colegio y los psicólogos matriculados que atienden pacientes de obras sociales. Las obras sociales derivan pacientes a los profesionales; cada atención genera una orden de prestación que el prestador carga en el sistema, presenta mensualmente al Colegio y cobra a través del proceso de liquidación.

El flujo completo cubre: carga de órdenes → validación por el operador → rendición mensual del prestador → aprobación y liquidación por el Colegio → acreditación al prestador.

Antecedentes históricos de altas de prestador

La bandeja existente de Altas de prestador incorpora dos orígenes consultables: Solicitudes del sistema y Antecedentes históricos. El segundo reúne planillas de inscripción identificadas de forma fuerte por matrícula y correo o nombre normalizado. Expone fecha, origen y cantidad de documentos declarados sin crear tickets ni cambiar el estado del perfil.

Una fila histórica no equivale a una aprobación. Sólo la aprobación del trámite formal puede activar isProvider, habilitar órdenes o generar comunicaciones. Los enlaces declarados en formularios quedan como evidencia pendiente hasta que el archivo físico, su identidad y su hash puedan verificarse; los documentos verificados se abren desde el perfil en la pestaña Prestador.

Un alta operativa y un antecedente documental responden preguntas distintas. Que isProvider esté activo permite operar como prestador, pero no prueba que exista una solicitud histórica preservada. Por eso la bandeja informa ambas coberturas sin fabricar altas retroactivas. En el corte certificado del 26/07/2026 hay 461 prestadores activos y 91 con antecedente histórico de alta; los 370 restantes conservan su estado operativo y quedan como brecha documental, no como error de rol.

La planilla histórica disponible contiene 138 respuestas distribuidas entre 2024, 2025 y el corte vigente. De ellas, 137 se identificaron de forma exacta y representan a 91 prestadores que continúan activos; también conserva altas de personas históricas que hoy no integran el padrón operativo. La respuesta restante presenta una matrícula ocupada por otra identidad y queda aislada. No existe otra planilla de altas en las fuentes revisadas que permita reconstruir los 370 antecedentes ausentes; el rol activo no autoriza a fabricar una solicitud retroactiva.

Las facturas fiscales del prestador tampoco son trámites. Se consultan en la misma ficha, dentro de Prestador, pero se almacenan como comprobantes recibidos. El corte del 27/07/2026 contiene 2.452 facturas con archivo físico en 305 perfiles; sólo 3 tienen vínculo exacto a una liquidación. El resto se preserva como evidencia fiscal sin inferir pago ni liquidación por igualdad de nombre, período o importe.

Desde el 28/07/2026 el portal propio reutiliza Liquidaciones para mostrar el inventario canónico completo de received_invoices, incluidas las facturas que todavía no tienen una liquidación exacta. La tabla distingue Sin liquidación exacta, Falta archivo y los estados fiscales reales; ya no depende sólo del campo legado invoiceUrl de una liquidación. La consulta queda limitada por el professionalId del usuario autenticado, por lo que un prestador nunca recibe facturas de otro perfil.

Esta mejora es de visibilidad y no cambia estados económicos. Una factura sin paymentSettlementId continúa REGISTERED; verla o descargarla no la aprueba, no crea una liquidación, no genera una operación PAY y no demuestra un egreso bancario. La misma evidencia canónica se usa en lista, kanban y línea de tiempo para evitar que dos vistas contradigan el estado del archivo.

Cuando una factura fiscal agrupa liquidaciones de varias OOSS del mismo período, la ficha muestra el comprobante en cada liquidación cubierta mediante asignaciones documentales explícitas. El total asignado debe cerrar exactamente contra el importe fiscal y la identidad debe ser única. Esta relación no duplica la factura, no altera el neto de las liquidaciones y no autoriza pagos; las facturas agregadas permanecen sujetas a revisión financiera.

El cruce documental amplio encontró 81 facturas con neto compatible en planillas o antecedentes bancarios (60 exactas y 21 con corrección de período). Esa compatibilidad sirve para ordenar la revisión, pero no reemplaza una liquidación canónica ni una operación bancaria vinculada. Por eso las 2.448 facturas sin relación exacta a paymentSettlement no se marcan como pagadas, aprobadas o liquidadas.

El cruce documental del 26/07/2026 confirmó la misma cobertura en SANDBOX y PSICOLE después de incorporar nuevos adjuntos de trámites: 161 perfiles con órdenes, 62 con liquidaciones y 305 con facturas presentadas. Existen 59 perfiles con 127 requerimientos de factura pendientes por $20.966.558,50. Estas métricas describen evidencia disponible y trabajo pendiente; no autorizan completar una factura, liquidación o pago por aproximación.

Qué ve cada actor y qué prueba esa vista

• El prestador consulta en Liquidaciones sus liquidaciones y el inventario paginado de facturas canónicas, vinculadas o no. También puede descargar un recibo propio que informa únicamente el neto.
• El administrador consulta la misma evidencia en Profesionales → ficha → Prestador, con las relaciones operativas necesarias para investigar el circuito.
• Finanzas conserva bruto, comisión y neto en sus vistas administrativas. La comisión del Colegio no se devuelve ni se representa en pantallas o recibos propios del prestador; no se elimina ni se recalcula.
• Abrir una factura, recibo, transferencia, ticket o trámite verifica el objeto concreto y su propietario. La autorización de una sección no permite leer un archivo perteneciente a otro profesional.

Ver una factura física demuestra recepción y trazabilidad documental. Sólo un vínculo canónico exacto demuestra su relación con una liquidación; tampoco ese vínculo, por sí solo, demuestra cobro OOSS o egreso bancario. Al 28/07/2026 el perfil puede exponer las 2.452 facturas asociadas a 305 profesionales, pero la cadena económica completa sigue bloqueada: hay 130 liquidaciones PENDING, 21 lotes sin respuesta, 20 pagos de lote sin movimiento bancario y 418 facturas institucionales sin líneas de detalle.

Roles con acceso

Módulos del portal del prestador

Consultorio — Agenda de turnos

El prestador gestiona su agenda de sesiones desde Mis Órdenes → Consultorio.

Vista semanal con turnos agrupados por día y ordenados por hora. Cada card muestra: - Hora y duración de la sesión. - Nombre del paciente. - Chip de obra social (si aplica). - Estado: Programado (azul) · Completado (verde) · Cancelado (gris) · Ausente (naranja).

Crear turno:

1. Hacé clic en + Nuevo turno.
2. Seleccioná el paciente con autocomplete desde la libreta (o ingresá el nombre libremente).
3. Completá fecha y hora, duración (default 50 min), modalidad (Presencial / Virtual) y notas.
4. Si el paciente tiene obras sociales en la libreta, el campo OOSS se muestra automáticamente.
5. Guardá.

Completar turno:

Al marcar un turno como Completado, si tenía obra social asociada el sistema propone crear la orden de prestación con los datos pre-llenados (paciente, DNI, afiliado, OOSS, fecha). El prestador confirma o ajusta los datos y guarda la orden con un clic.

Exportar agenda:

El botón Exportar .ics descarga un archivo RFC 5545 importable en Google Calendar, Apple Calendar o cualquier cliente de calendario compatible. Cada turno se exporta como evento con título, horario y descripción.

Libreta de pacientes

Repositorio personal del prestador para centralizar los datos de sus pacientes habituales y agilizar la carga de órdenes.

Funciones:

Importar desde órdenes:

Cuando el prestador tiene pocos pacientes registrados (menos de 5) y ya tiene órdenes históricas, aparece un banner de importación:

1. Hacé clic en Ver preview — el sistema analiza todas las órdenes del prestador y muestra los pacientes únicos que se crearían, con sus obras sociales detectadas.
2. Si el resultado es correcto, hacé clic en Confirmar importación.
3. El sistema reporta: X creados · Y actualizados · Z sin cambios.

Integración con órdenes:

Al crear o editar una orden, el campo Paciente tiene autocomplete desde la libreta. Al seleccionar un paciente: - Se auto-completan DNI, obra social y número de afiliado. - Si el paciente tiene múltiples obras sociales, aparece un dropdown para elegir cuál usar en la orden. - Los campos diagnóstico y tratamiento sugieren valores históricos del prestador.

Órdenes de prestación

1. Ir a Mis Órdenes → + Nueva Orden.
2. Campo Paciente con autocomplete desde la libreta.
3. Completar datos clínicos: fecha, sesiones, diagnóstico, tratamiento, adjunto (JPG/PNG/PDF).
4. Guardar.

Estados de una orden:

Rendición mensual

Al cerrar el mes, el prestador presenta sus órdenes validadas al Colegio.

Banner de alerta:

Cuando hay órdenes con estado Validada sin rendición asignada, aparece un banner verde en Mis Órdenes:

"Tenés X órdenes validadas listas para rendir este período."

Generar rendición:

1. Hacer clic en Generar rendición.
2. Revisar el resumen por obra social: cantidad de órdenes y subtotal por cada una.
3. Hacer clic en Enviar rendición al Colegio.
4. Esperar a que el Colegio genere la liquidación con el neto definitivo.
5. Desde Liquidaciones, presentar la factura correspondiente a esa liquidación.

Seguimiento:

En Liquidaciones se listan las liquidaciones con período, estado, cantidad de órdenes, neto, factura vinculada y comprobante cuando exista.

Las facturas fiscales históricas también aparecen en Profesionales → perfil → Prestador y en la lista operativa de Facturas recibidas. Un comprobante REGISTERED puede existir sin liquidación vinculada: conserva el archivo y la identidad fiscal, pero no habilita aprobación ni pago. El alcance y las guardas del archivo maestro están documentados en Liquidaciones → Ampliación del archivo maestro.

Estados de una rendición:

Flujo completo: del turno a la acreditación

PRESTADOR                         SISTEMA                        OPERADOR_FINANZAS
    │                                │                                   │
    │── Agenda turno ──────────────► │                                   │
    │── Completa turno ────────────► │ propone crear orden               │
    │── Confirma orden ────────────► │ crea ProviderOrder (PENDING)      │
    │                                │                                   │
    │                                │ ◄── valida órdenes del período ── │
    │                                │ ──► ordenes → VALIDATED ─────────►│
    │                                │                                   │
    │── banner: "X órdenes listas" ──│                                   │
    │── genera rendición ───────────►│ crea ProviderSubmission (PENDING) │
    │                                │                                   │
    │                                │ ◄── revisa rendición ─────────── │
    │                                │ ──► APPROVED ───────────────────►│
    │                                │                                   │
    │ ◄── liquidación disponible ───│ ──── genera liquidación ──────────►│
    │── presenta factura ──────────►│ vincula ReceivedInvoice           │
    │                                │ ◄── revisa/aprueba factura ────── │
    │ ◄── acreditación bancaria ────│ ──── registra pago trazable ─────►│
    │── descarga comprobante ───────►│                                   │

Flujo de revisión del operador (Rendiciones)

El OPERADOR_FINANZAS gestiona las rendiciones desde Operador → Prestadores → Rendiciones.

1. Tabla de rendiciones pendientes con: prestador, período, cantidad de órdenes, monto, fecha de envío y link a la factura.
2. Acciones por rendición:
3. Aprobar — cambia estado a APROBADA y dispara el proceso de liquidación.
4. Observar — abre un modal para ingresar una nota; el prestador ve la observación en su portal.
5. Rechazar — requiere motivo; el prestador debe corregir y reenviar.

Corregir una orden después de guardarla

El operador puede corregir una orden desde Prestadores → Órdenes o, si ya pertenece a una rendición, desde el detalle de esa rendición. El modal permite cambiar prestador, número de orden, paciente y DNI, afiliado, Obra Social, fecha de prestación, práctica, cantidad y precio unitario. Siempre exige un motivo y deja auditoría CORRECT_ORDER.

1. Abrir el detalle de la orden y elegir Corregir.
2. Buscar la práctica por código o descripción. El catálogo se limita a la Obra Social y a la vigencia de la fecha de prestación.
3. Ajustar cantidad o precio. El sistema recalcula cantidad × valor unitario; el total no se edita como un campo independiente.
4. Escribir el motivo y guardar.
5. Si la orden estaba VALIDATED o SUBMITTED, vuelve a OBSERVED para que un operador la valide otra vez. Una orden OBSERVED vuelve a PENDING.

Una orden vinculada a una rendición no se corrige desde la grilla general: debe abrirse desde esa rendición. De ese modo conserva el vínculo y el sistema recalcula el total de la rendición en la misma operación. Los estados terminales —aceptada, pagada, rechazada o cancelada— no admiten edición.

El código de la práctica se persiste con su referencia de nomenclador cuando está disponible. Para una orden legada sin referencia interna, el sistema puede resolver un único código vigente por Obra Social y fecha; si no hay coincidencia confiable, la orden queda PENDING_REVIEW. Corregir un campo no económico preserva una aprobación tarifaria existente sólo si siguen iguales la Obra Social, práctica, fecha y vigencia, cantidad, precio aplicado y referencia oficial. Cambiar cantidad, práctica, fecha, Obra Social o cualquier precio es un cambio económico y requiere nueva revisión o una excepción autorizada con motivo.

Panel del operador auditado

El panel operativo de prestadores fue recapturado en escritorio y celular para validar que pestañas, filtros, KPIs, tablas y acciones no se superpongan en resoluciones bajas. En móvil, las pestañas se desplazan horizontalmente y el contenido operativo conserva lectura vertical.

Lotes mensuales y facturacion manual ARCA OOSS

El circuito Colegio → Obra Social se revisa desde Prestadores → Lotes mensuales. Cada lote agrupa una Obra Social y un período, y permite controlar las órdenes antes de preparar la factura real en ARCA.

Control previo de ordenes

Al abrir un lote mensual, el operador puede generar el PDF del lote para revisar:

• Obra Social y período.
• Profesionales incluidos, ordenados alfabéticamente.
• Matrícula del prestador.
• Paciente, DNI y número de afiliado.
• Número de orden.
• Fecha, sesiones, valor unitario e importe.
• Subtotal por prestador y total del lote.

Este PDF sirve para auditoría interna del lote. No es una factura. La generación y regeneración normal del PDF de presentación ocurre mientras el lote está DRAFT; la acción masiva también selecciona exclusivamente borradores. Confirmar el lote exige un pdfUrl vigente, lo lleva a READY y congela el PDF revisado: un READY que ya tiene PDF y cualquier SENT rechazan reemplazarlo. Como compatibilidad acotada para datos legados, un READY cuyo pdfUrl es nulo puede recuperar manualmente el archivo una sola vez mediante CAS; no se reabre ni se migra el lote. La tarjeta, el detalle y el panel operativo muestran para ese caso el CTA Recuperar PDF faltante. La descarga del PDF vigente sigue disponible.

Control de órdenes y exportación previa a facturar

La pestaña de control reúne las órdenes sin crear lotes, facturas, pagos ni cambios de estado. Permite buscar por prestador, matrícula, paciente, número de orden, práctica u Obra Social y filtrar por estado, etapa, Obra Social, período o rango de fechas.

El detalle y el CSV muestran el número de orden y la información operativa necesaria para controlar la carga: prestador, matrícula, Obra Social, afiliado, código y descripción de la práctica, cantidad, valor unitario, valor total, fecha de prestación, estado tarifario, adjunto y vínculos a lote, presentación y rendición.

Para exportar se debe seleccionar una Obra Social y un período o rango completo. El rango máximo es de 366 días y el límite es de 50.000 filas; si el universo es mayor, el operador debe acotarlo. El archivo usa CSV compatible con Excel, separa campos por punto y coma y protege las celdas que podrían interpretarse como fórmulas. La exportación se registra en auditoría y no altera la orden.

La fecha de prestación se trata como fecha calendario de Mendoza tanto en lista como en detalle y exportación. No se convierte a la zona horaria del navegador, por lo que una prestación del 17/07 no debe mostrarse como 16/07.

Vista previa y generación con los mismos filtros

Antes de generar, el operador debe ejecutar Vista previa. La previsualización y la generación reciben el mismo rango, campo de fecha y Obra Social; el número de órdenes y el total previsualizados son el universo que se intenta materializar.

El rango puede aplicarse por:

• Fecha de carga (createdAt): opción recomendada para cierres operativos.
• Fecha de validación (validatedAt): si una orden legada no conserva esa fecha, se usa su última actualización como respaldo explícito.
• Fecha de prestación (serviceDate): selecciona por el día real del servicio.

También se puede indicar una fecha de corte de carga o limitar el cierre a una única Obra Social. Sólo participan órdenes VALIDATED, con Obra Social y todavía sin lote. La selección agrupa un lote por Obra Social y mantiene intacta la fecha de prestación: el período del lote describe el cierre, no reescribe el mes del servicio.

Si se informan al mismo tiempo un rango y una fecha de corte, el rango tiene prioridad. El campo de fecha elegido se aplica a ese rango y la fecha de corte no amplía el universo.

Si el preview da cero, el botón de generación permanece inactivo. Si los filtros cambian, se debe ejecutar otra vista previa antes de generar; no se completa un lote con datos de una consulta anterior.

La asignación o remoción de órdenes del lote es una acción del operador: el prestador no puede conectar, mover ni desvincular órdenes por su cuenta. Si edita o elimina una orden ya ligada mientras el lote sigue DRAFT, el sistema recalcula los totales e invalida los modelos/PDF para exigir una nueva revisión. Las acciones individuales o masivas del operador para validar, observar o rechazar una orden ligada usan el mismo protocolo transaccional: reclaman y actualizan el parent DRAFT e invalidan sus artefactos antes de cambiar la orden. Una vez que el lote está READY o SENT, esas mutaciones se bloquean. Las órdenes que pertenecen a una rendición continúan gestionándose desde esa rendición. El envío reclama exactamente la versión y el PDF confirmados; dos envíos concurrentes no pueden ganar.

Modelo interno para carga manual en ARCA

La acción Modelo factura ARCA OOSS genera un PDF de apoyo para que el operador copie los datos y complete la factura real manualmente en el sitio de ARCA.

El modelo prepara:

• Emisor: Colegio.
• Receptor: Obra Social.
• CUIT, domicilio fiscal y condición IVA del receptor, cuando estén cargados.
• Período facturado.
• Detalle por profesional y orden.
• Cantidad, precio unitario, importe y total.
• Campos pendientes de completar en ARCA, como punto de venta, número de comprobante, CAE y vencimiento del CAE.

Factura fiscal del Colegio a la Obra Social

Después de emitir manualmente en ARCA, el operador registra y consulta la constancia desde Dinero → Configuración → Facturación OOSS. Se reutiliza la configuración existente de Dinero; no se agrega otro módulo ni una bandeja paralela.

Cada factura institucional conserva:

• número de comprobante y período económico;
• Obra Social y CUIT receptor;
• fecha de emisión y vencimiento de pago;
• importe, CAE y vencimiento del CAE;
• PDF fiscal privado y hash SHA-256 de la fuente;
• estado y operación de pago, cuando exista una conciliación bancaria trazable.

El PDF prueba la emisión fiscal, no el cobro. Una factura respaldada por fuente no puede pasar a Pagada desde esta lista sin una PaymentOperation vinculada. Los estados históricos incompatibles quedan en revisión y no se reescriben por inferencia.

Gate documental institucional 2026

El 22/07/2026 se contrastaron 82 facturas del Colegio a OOSS contra las carpetas fiscales 2026. 81 tenían PDF, CUIT, CAE, período e importe verificables: 50 se registraron como Enviadas y 31 recibieron el PDF y los metadatos fiscales sobre su registro existente, preservando su estado previo. La factura de UNIMED abril 2026 por $55.000 permanece bloqueada porque no se encontró el PDF fiscal; no se creó una factura sustituta.

El primer gate de SANDBOX creó o completó exactamente esas 81 facturas. Dos replays posteriores devolvieron 81 NOOP, el mismo hash funcional y cero altas de pagos, recibos, operaciones, notificaciones, correos o mensajes. La vista autenticada abrió el detalle y el PDF privado sin errores de consola. Este corte sigue siendo documental: no confirma cobros de OOSS, no genera liquidaciones y no habilita pagos a prestadores.

La auditoría separó además 37 estados históricos Pagada sin operación económica vinculada. Son una cola de revisión de procedencia y no se toman como evidencia de cobro hasta conciliarlos.

Factura del prestador al Colegio

La factura que el prestador entrega al Colegio pertenece a otro circuito. Se presenta sobre la liquidación cuando el neto definitivo ya fue calculado y no se genera desde los lotes de Obra Social. La carga opcional histórica sobre ProviderSubmission queda como legado de consulta y no es la fuente canónica para autorizar pagos.

No deben mezclarse:

• Colegio → Obra Social: modelo interno, emisión manual en ARCA y constancia fiscal registrada en Facturación OOSS.
• Prestador → Colegio: factura real del prestador, registrada en received_invoices y vinculada a una liquidación.

El operador las consulta sin abrir una pantalla nueva, desde Prestadores → Liquidaciones de pagos → Facturas recibidas. La lista mensual agrupa prestador, número, fecha, período, obra social, importe, liquidación, estado y archivo; permite buscar y filtrar por estado. Una fila legada sin registro canónico se identifica como Legada: revisar y no se aprueba automáticamente. Las facturas reemplazadas permanecen como Canceladas con su archivo histórico accesible para auditoría.

Si la factura llega antes de una liquidación compatible, el operador la ve como Registrada y Sólo documental. El sistema conserva el PDF privado, la clave fiscal, el período declarado y el motivo que impide vincularla. No completa obra social, liquidación o pago por nombre o importe aislados.

El primer gate histórico registró las mismas 293 facturas reales en SANDBOX y PSICOLE: 4 de 2023, 74 de 2024, 143 de 2025 y 72 de 2026, correspondientes a 43 profesionales. La identidad quedó resuelta por evidencia fiscal y los archivos duplicados o no fiscales quedaron fuera del universo canónico.

Dentro de esas 293, sólo 3 facturas están vinculadas a una liquidación relacional exacta y continúan En revisión; el vínculo documental no confirma el cobro de la Obra Social ni habilita el pago. Otras 19 tienen respaldo documental de neto exacto, pero todavía no existe una liquidación canónica compatible. Las 271 restantes permanecen Registradas y Sin liquidación fuente. No se fuerza un vínculo por nombre, importe aislado o cercanía de período, ni se interpreta una diferencia como rechazo OOSS sin evidencia explícita.

La aplicación y el replay fueron idempotentes: se incorporaron 221 comprobantes históricos, se completaron 72 registros existentes y luego las 293 facturas devolvieron NOOP. No hubo altas de pagos, recibos, operaciones, órdenes, liquidaciones o comunicaciones.

La ampliación posterior del archivo maestro agregó 2.158 facturas certificadas de 2018–2026 en ambos entornos. El total canónico quedó en 2.451 comprobantes. Todas las altas nuevas permanecen REGISTERED: estar visibles en el perfil no implica que exista una liquidación, aprobación o pago. El replay productivo fue completamente idempotente y la descarga del PDF quedó validada mediante acceso autenticado privado.

Gate de débitos Galicia y rendición al prestador

El cruce del 22/07/2026 separa cuatro evidencias que no son intercambiables:

1. Los reportes de débito automático y tarjeta son cobranzas entrantes de cuotas colegiales. No prueban una transferencia al prestador.
2. El archivo de transferencias bancarias es una instrucción. No prueba que el banco la haya ejecutado.
3. El débito del extracto Galicia prueba un egreso bancario, pero todavía no identifica por sí solo la liquidación y la factura que lo justifican.
4. El cierre operativo exige liquidación canónica, factura vinculada y aprobada, movimiento bancario persistido y operación PAY aprobada o conciliada.

Se contrastaron 173 netos documentales por prestador/período con cinco extractos Galicia. Hubo 54 egresos exactos por identidad e importe, por un total de $15.037.755,69; 51 también están persistidos como movimientos bancarios en PSICOLE. Los otros tres pertenecen al extracto de mayo y requieren registrar esa fuente antes de continuar.

El cruce contra las bases de SANDBOX y PSICOLE produjo la misma clasificación:

Ninguna cadena está cerrada. Una de las dos liquidaciones exactas tiene factura vinculada, pero el débito bancario es anterior a la factura; la otra no tiene factura. Las dos operaciones continúan PENDING. Por lo tanto no se marcó ninguna liquidación o factura como pagada.

Para operar la cola:

1. Abrir Prestadores → Liquidaciones de pagos y seleccionar el período.
2. Buscar al prestador por matrícula o nombre y comparar el neto con el CSV de revisión.
3. Si falta la liquidación, reconstruirla sólo desde órdenes y lote aprobados.
4. Si el importe difiere, revisar la fuente que declara rechazos o ajustes. La diferencia no se etiqueta automáticamente como rechazo OOSS.
5. Revisar la factura en Facturas recibidas o en Profesionales → perfil → Prestador.
6. Registrar el pago sólo cuando factura, liquidación, banco y operación coincidan y la factura esté APPROVED_FOR_PAYMENT.

La evidencia privada está identificada como provider-payout-debit-gate-20260722. Los replays canónico y con copias duplicadas reprodujeron el hash económico 8d04f54274004fe19d811d401c1ec21c4ed310b850bcf544fb401f61a51877ae, sin pagos, recibos, cambios de estado ni comunicaciones. El hash de inventario sí cambia cuando se agregan copias y permite auditar esa diferencia sin alterar el resultado financiero.

El gate es reproducible con los comandos administrativos build:provider-payout-evidence, build:provider-payout-system-crosscheck y build:provider-payout-live-report. El primero genera evidencia documental; el segundo produce SQL de consulta con una tabla temporal; el tercero compara SANDBOX y PSICOLE y publica la cola privada. Ninguno tiene modo --apply.

El control del 27/07/2026 incorporó el detalle vivo de julio sin relajar estas reglas. Las 711 prestaciones explican el neto base de los 62 prestadores; los beneficios jubilatorios se muestran por separado y completan el pago final. Los 62/62 prestadores quedaron identificados y vinculados al renglón del libro general, pero la evidencia bancaria conserva estados diferentes: exacta, anterior a la factura, identidad triangulada, ambigua, con diferencia o ausente. Un egreso anterior a la factura ya no desaparece del auditor: queda como Revisión: egreso anterior a factura, sin candidato aplicable ni cambio de estado. Una abreviatura de nombre puede recuperar la matrícula sólo mediante el detalle de órdenes certificado; continúa requiriendo aprobación y nunca se resuelve por importe aislado.

Cuando un replay integral deja de producir un candidato abierto de esta fuente, el sistema lo marca SUPERSEDED y conserva la evidencia anterior con el motivo del recálculo. Esta limpieza sólo afecta la cola de revisión: no modifica ni desvincula pagos, recibos, deudas, órdenes, liquidaciones, facturas o movimientos bancarios. Los candidatos ya aprobados, rechazados o aplicados permanecen intactos. El preview informa cuántos candidatos abiertos quedarían obsoletos antes de ejecutar la actualización.

Preview de regularización de liquidaciones

El siguiente gate toma únicamente los 52 casos con egreso Galicia exacto y liquidación ausente o de importe distinto. Reconstruye las líneas documentales de prestación y consulta identidad, órdenes, lote, liquidación, factura y banco en una sola clasificación de sólo lectura. No crea órdenes, lotes, liquidaciones, facturas, operaciones o pagos; tampoco cambia estados ni envía comunicaciones.

El parser recuperó correctamente el período económico de las 173 rendiciones documentales. El replay conservó los mismos importes y produjo el mismo SQL tanto desde la evidencia histórica como desde la evidencia regenerada. SANDBOX y PSICOLE devolvieron el mismo hash de consulta y el mismo resultado fila por fila:

Las 52 filas suman $14.818.981,89 y contienen 568 líneas: 31 tienen una orden única, 532 no tienen orden compatible, 5 son ambiguas y sólo 20 ya están vinculadas a lote. Mayo concentra 4 casos, junio 3 y julio 45; julio explica 530 de las 532 líneas faltantes. Ninguna fila alcanzó el estado READY_SETTLEMENT_CREATE_PREVIEW, por lo que el gate no habilita un apply.

La evidencia privada está identificada como provider-settlement-repair-preview-20260722 y tiene hash semántico 586c8ef4b5c46db49254fbba0cfb277d883456a44434faed21d907a916050669. Dos reportes consecutivos reprodujeron ese hash, con paridad total entre entornos, 0 mutaciones económicas, 0 notificaciones y 0 antecedentes de débito automático usados como prueba de pago al prestador.

Este control es NO_UI: se ejecuta como auditoría administrativa y su salida contiene datos fiscales privados. No requiere capturas, ayuda contextual, onboarding ni tour. La operación humana continúa en las pantallas existentes de Prestadores → Liquidaciones de pagos, Facturas recibidas y la pestaña Prestador del perfil.

Gate por línea y disponibilidad de lote para mayo/junio

El corte específico de mayo y junio volvió a procesar los 7 egresos Galicia pendientes por $714.623,40 contra 31 líneas documentales, órdenes, lotes, liquidaciones, facturas y banco. La comparación se realiza en dos niveles: primero por línea de prestación y luego por la suma de todas las liquidaciones del prestador y período. Varias liquidaciones del mismo mes son válidas cuando pertenecen a diferentes OOSS o lotes; no deben reducirse a una sola fila ni compararse individualmente contra el neto mensual completo.

El resultado dejó 28 líneas respaldadas por una orden única o por un conjunto equivalente, 1 orden verdaderamente faltante, 1 posible desfase de período y 1 línea ambigua. De las 12 líneas respaldadas que aún no están vinculadas, 10 apuntan a lotes cuyo neto ya fue distribuido completamente entre liquidaciones existentes. Vincularlas sin reconstruir el pago OOSS duplicaría o sobredistribuiría dinero, aunque la identidad y el importe documental parezcan correctos.

Por eso el estado TARGET_BATCH_FULLY_ALLOCATED_REVIEW es un bloqueo económico obligatorio. El operador debe reconstruir primero la fuente OOSS, el pago del lote, sus débitos o rechazos explícitos y la distribución existente. El estado SET_EQUIVALENT_ORDER_GROUP_REVIEW conserva líneas duplicadas indistinguibles como conjunto y prohíbe emparejarlas arbitrariamente una a una. Ninguno de estos estados habilita UPDATE, liquidación, factura, operación PAY o cambio de estado.

SANDBOX y PSICOLE devolvieron exactamente el mismo detalle de casos, líneas y 9 lotes relevantes. Dos replays reprodujeron el hash semántico 2328f4e17a324cd800df6f067d326af03996e49fbe6d6c3f608094e3934048e8, con 0 mutaciones económicas, 0 comunicaciones y 0 antecedentes de débito automático usados como prueba de pago. La evidencia privada está identificada como provider-may-june-order-batch-gate-20260723.

Este gate también es NO_UI: endurece la auditoría previa y documenta por qué no existe todavía una reparación idempotente. Las pantallas y acciones humanas siguen siendo las existentes.

Gate bancario OOSS → Colegio → prestador

El siguiente control contrasta, sin modificar estados, la cadena económica completa:

1. lote y factura institucional de la Obra Social;
2. crédito acreditado en los extractos Galicia del Colegio;
3. liquidaciones y facturas recibidas de prestadores;
4. débito bancario que podría respaldar el pago al prestador.

El período de liquidación no obliga a que la acreditación bancaria ocurra en el mismo mes calendario. Por eso una coincidencia sólo se acepta cuando conserva el CUIT exacto de la OOSS y el importe documental coincide con un único crédito o con una única suma de créditos. El motor bloquea coincidencias por importe aislado, nombre aproximado, cercanía de fecha, movimientos reutilizados o más de una combinación posible.

Sobre 30 cohortes documentales de mayo, junio y julio por $56.224.572,02, los cinco extractos Galicia aportaron 27 créditos OOSS por $47.467.273,96. El resultado fue:

Quedaron 9 créditos OOSS sin cohorte documental inequívoca y no se reutilizó ningún movimiento. En el lado de egresos, 54 de 173 períodos de prestador tienen un débito exacto por identidad e importe, por $15.037.755,69. Aun así, mayo, junio y julio permanecen en PARTIAL_EXACT_BANK_CHAIN: ninguna cadena cuenta simultáneamente con vínculos bancarios persistidos de cobro OOSS y pago a prestador.

El gate termina en PASS_READ_ONLY_BANK_EVIDENCE_CLASSIFICATION, pero su habilitación económica permanece BLOCKED_OPERATOR_APPROVAL_AND_PERSISTED_BANK_LINKS. El siguiente paso permitido es revisar cada coincidencia exacta, aprobarla expresamente y crear vínculos bancarios idempotentes. Recién después puede evaluarse una operación económica; este control nunca crea pagos, recibos, liquidaciones, saldos, mensajes ni cambios de estado.

SANDBOX y PSICOLE devolvieron el mismo contenido normalizado. Dos replays reprodujeron el hash semántico b2728fca0d68374cb6330d037c28a732cc837b9fbd2dc0b52042c9df5c390f6f; las capturas de base antes y después conservaron sus hashes por entorno, con 0 mutaciones económicas y 0 comunicaciones.

La auditoría se ejecuta con build:provider-ooss-bank-chain-evidence. Es NO_UI, utiliza únicamente archivos y snapshots de lectura, y deja JSON, CSV y README privados para revisión. No requiere pantalla, captura, ayuda contextual, onboarding ni tour.

CUIT maestro y diferencias tarifarias del lote

El CUIT usado para identificar un crédito OOSS debe existir tanto en la fuente documental como en el maestro de la Obra Social. Completarlo es un cambio de datos maestros: exige respaldo, coincidencia exacta de ID, código y nombre, preview sin conflictos y replay idempotente. No confirma un cobro ni modifica órdenes, lotes, liquidaciones o pagos.

Si el bruto documental de una liquidación difiere de la suma de sus órdenes, el operador no debe asumir que faltan órdenes. El control compara cada número de orden, cantidad, tarifa unitaria e importe. Una tarifa histórica mal importada se clasifica como TARIFF_MISMATCH y mantiene bloqueados el lote y la cobranza hasta ejecutar un preview de corrección que recalcule:

1. importe de cada orden afectada;
2. bruto aceptado del lote;
3. comisión del Colegio;
4. neto de cada liquidación;
5. facturas y vínculos bancarios relacionados.

El preview debe explicar el 100% de la diferencia, reproducir el mismo hash en dos ejecuciones y dejar en cero órdenes faltantes, sobrantes o ambiguas. La corrección no se aplica parcialmente ni se usa para autorizar el pago al prestador. En el gate del 23/07/2026, seis CUIT maestros se normalizaron sólo en SANDBOX con replay de cero escrituras; una diferencia OSTV de $187.200 quedó explicada por cuatro órdenes con tarifa persistida distinta de la fuente.

La reparación posterior se aplicó sólo en SANDBOX sobre esas cuatro identidades exactas. Conservó su estado PAID, normalizó precio, total, período de servicio y procedencia tarifaria, y dejó intactos lote, pago OOSS, liquidación, comisión, neto, facturas y operaciones. El replay fue NOOP y dos auditorías posteriores confirmaron diferencias cero. Esto corrige la representación histórica de las órdenes; no confirma un nuevo cobro OOSS ni autoriza un pago al prestador. PSICOLE permaneció sin cambios.

El control posterior separó el bruto del lote de su aceptado después de ajustes. Las órdenes se comparan con batch.totalAmount; la diferencia entre ese bruto y batch.acceptedAmount debe coincidir con los ajustes de las liquidaciones. En OSTV, $2.048.900,00 - $1.986.500,00 = $62.400,00, exactamente el ajuste documentado. Dos replays dejaron 6/6 lotes exactos listos únicamente para aprobación humana de cobro OOSS, con los 18 candidatos todavía sin decisión ni operación económica.

Los pagos a prestadores se mantuvieron bloqueados en los seis casos por PROVIDER_INVOICES_INCOMPLETE. La disponibilidad para revisar un cobro OOSS no habilita una liquidación ni un pago al prestador; factura canónica, operación PAY y evidencia bancaria de egreso continúan siendo requisitos separados.

Trazabilidad en el perfil del prestador

El perfil del profesional muestra la trazabilidad financiera cuando el colegiado tiene isProvider activo y rol operativo habilitado. No se agrega una pantalla nueva: el bloque aparece dentro de Actividad como Prestador.

La sección resume:

La tabla de facturas está dentro de la pestaña existente Prestador. El resumen separa comprobantes presentados de obligaciones pendientes. En revisión significa que existe un vínculo documental exacto con una liquidación todavía pendiente; Registrada / Sin vínculo exacto significa que el archivo está preservado pero requiere normalización o evidencia adicional. Pendiente de presentación muestra una liquidación real que todavía no tiene factura recibida y nunca debe interpretarse como comprobante importado. Si no existen facturas ni liquidaciones, el perfil lo informa explícitamente. En móvil, el desplazamiento horizontal queda contenido dentro de la tabla y no desplaza el perfil completo.

El auditor de reciprocidad del 27/07/2026 confirmó en PSICOLE 2.451 facturas físicas asociadas sin identidades huérfanas ni diferencias de importe en los vínculos exactos existentes. Esas facturas pertenecen a 305 perfiles; por eso un prestador activo sin comprobantes puede mostrar correctamente un estado vacío. Sólo 3 de las 130 liquidaciones tienen factura canónica vinculada. Las 127 restantes son una cola documental real y no deben completarse por importe, nombre o período aproximado.

La ficha también enlaza Operaciones recientes con el historial completo de Dinero filtrado por matrícula. Ese acceso evita interpretar el resumen reciente como el universo total de pagos y transferencias del profesional.

La respuesta administrativa de perfil informa collectionCompleteness para cada colección y entrega el historial completo consultado, sin límites silenciosos de pagos, operaciones, órdenes, trámites, comunicaciones o auditoría. En modo AUTHZ_POLICY_MODE=enforce, cada bloque se entrega sólo a roles con capacidad explícita: identidad, finanzas, prestadores, trámites, formación, comunicaciones, auditoría y roles se autorizan de forma independiente. En observe se conserva la compatibilidad vigente y se registran diferencias sin bloquear a los operadores que ya están probando.

Consultar GET /users/:id/full-profile es estrictamente de sólo lectura. Si una credencial no tiene QR, la ficha informa que requiere emisión administrativa; no genera ni persiste el QR durante el GET. La emisión o regeneración continúa en su flujo administrativo auditable.

El auditor de reciprocidad falla cerrado. Una corrida sólo puede declararse CERTIFIED cuando son cero, simultáneamente: liquidaciones sin factura canónica, lotes OOSS sin respuesta, pagos de lote sin movimiento bancario y facturas OOSS sin líneas. El corte actual continúa INCOMPLETE; la corrección evita un falso PASS, pero no inventa los vínculos que todavía faltan.

El barrido integral del 23/07/2026 verificó 293/293 facturas fuente y sus archivos privados en SANDBOX y PSICOLE. Esos comprobantes pertenecen a 43 profesionales; no existe una factura para cada persona marcada como prestadora. Por eso, un perfil vacío puede ser un resultado correcto y no un error de importación.

La cobertura se clasifica sin fabricar actividad:

Los dos entornos tienen la misma cobertura: 473 prestadores, 161 perfiles con órdenes, 62 con liquidaciones y 43 con facturas presentadas. Las 130 liquidaciones incluyen 127 requerimientos sin factura aprobada por $20.966.558,50. Sólo 3 tienen documento exacto vinculado y todavía requieren aprobación humana. No se infiere estado pagado, rechazo de OOSS ni liquidación a partir de un débito bancario aproximado.

El SPTS total de mayo/junio/julio usa esta misma estructura para producir professional-traceability.csv. Ese archivo permite revisar por profesional si existen órdenes, lotes, pagos desde obra social, liquidaciones, facturas pendientes y pagos al prestador antes de cerrar preproducción.

En el cierre del 10/07/2026, PSICOLE incorporó 581 órdenes fuente del alcance mayo-julio y 125 liquidaciones reales pendientes distribuidas en 19 lotes. Las 125 conservan la factura del prestador como pendiente y no tienen operación PAY: son una cola documental, no pagos omitidos. SANDBOX conserva además históricos de órdenes y operaciones de prueba, por lo que sus totales globales no deben copiarse a producción ni usarse para inferir pagos.

Certificacion de ordenes de junio del 18/07/2026

La planilla Ordenes Junio 2026 Completo.xlsx fue procesada como fuente de órdenes, no como extracto bancario. Contenía 887 filas: 884 órdenes canónicas, 3 duplicados internos, 2 coincidencias exactas ya existentes y 2 conflictos de identidad que quedaron fuera de la importación automática. Se incorporaron 878 órdenes seguras en cada entorno; repetir el comando importó 0, confirmando idempotencia.

Después del cruce, SANDBOX y PSICOLE contienen el mismo universo por código trazable: 1.444 órdenes, 143 rendiciones y 125 liquidaciones. No se generó ninguna orden de pago a prestador. Las órdenes nuevas sin nomenclador oficial permanecen PENDING_REVIEW: el sistema no inventa un precio, una factura, una liquidación ni un pago a partir de la planilla.

El control estricto dejó 1.100 órdenes históricas pagadas por obra social todavía pendientes de una liquidación formal al prestador. Esta cifra es una cola operativa para revisar precio, rendición, factura y liquidación; no representa 1.100 pagos omitidos ni habilita una materialización masiva. Hasta resolver esa cola y aprobar el nomenclador, los pagos automáticos a prestadores continúan bloqueados.

En SANDBOX se aislaron tres PDF identificados exactamente como fixtures de prueba. Se movieron al respaldo de cuarentena, sin borrar usuarios, órdenes, documentos reales ni antecedentes. PSICOLE no tenía esos archivos activos.

Control de liquidacion integral de julio del 21/07/2026

La planilla PRESTADORES-OBRASSOCIALES-Liquidación Julio 2026.xlsx es una liquidación preparada en julio, pero sus 711 renglones de prestaciones corresponden a períodos entre febrero y mayo de 2026. Contiene 62 profesionales, 9 obras sociales y 10 facturas institucionales. El total bruto es $21.100.115,42, el aceptado $20.131.152,00 y el neto de detalle $18.118.036,69; la planilla agrega $245.942,99 de beneficios jubilatorios y llega a un neto final de $18.363.979,82.

Los 62 profesionales tienen identidad única y están marcados como prestadores en PSICOLE. La resolución canónica y los gates posteriores separan identidad, precio y efecto económico:

• 600 líneas con número de orden son candidatas nuevas y 1 línea ya está representada inequívocamente;
• 108 líneas sin número tienen afiliado y firma económica únicos. El preview propone para cada una un número LEGACY-AAAAMM-<hash> derivado del hash de fuente y la firma completa de línea;
• los 108 números, trace codes, claves canónicas e idempotency keys son únicos y no colisionan con órdenes de SANDBOX ni PSICOLE;
• 2 líneas de Poder Judicial coinciden en firma económica con una orden existente pero traen otro número; permanecen en revisión manual por posible duplicación;
• las 10 facturas institucionales todavía no existen en el registro canónico;
• las diferencias de liquidación detectadas son únicamente de redondeo, entre $0,01 y $0,08 por prestador.

La identidad sintética certificada no equivale a precio aprobado. Entre esas 108 líneas, sólo 36 tienen tarifa oficial exacta; 71 difieren del nomenclador activo y 1 no tiene nomenclador. En las 600 líneas con número, 520 tienen precio oficial exacto y 80 permanecen agrupadas en 12 excepciones tarifarias: 9 sin segunda evidencia, 1 prestación sin código canónico y 2 precios históricos incompatibles de Swiss Medical.

Por esa razón, el control continúa en preview, sin crear órdenes, facturas, liquidaciones ni pagos. No se debe hacer un cruce masivo por nombre, importe agregado o cantidad ni importar sólo una parte de una factura o lote.

El preview integral de las 708 altas potenciales ya fue ejecutado dos veces en SANDBOX y dos en PSICOLE. Cubrió las 711 líneas fuente sin huecos: 708 altas potenciales, 1 línea reutilizable y 2 posibles duplicados en revisión. No detectó colisiones de trace code, clave canónica o idempotencia y conservó delta cero en 15 familias económicas.

La proyección deja 8/17 lotes listos después de importar sus órdenes, 8 bloqueados por tarifa y 1 por posible duplicación. De las 10 facturas institucionales, 2 quedarían listas, 7 continúan bloqueadas por tarifa y 1 por posible duplicación. Las 152 líneas sin precio oficial exacto se agrupan en 13 decisiones documentales: 142 difieren del nomenclador activo y 10 no tienen nomenclador.

Este resultado certifica la integridad del preview, no la aplicación económica. economicApplyReady, la importación parcial y la aplicación automática permanecen bloqueadas hasta resolver los 13 grupos tarifarios y las dos líneas de Poder Judicial, y volver a obtener el mismo hash con todos los lotes y facturas completos.

Cola de 15 decisiones documentales

El gate siguiente convirtió las excepciones en una cola reproducible, sin crear ni modificar datos económicos. Dos ejecuciones en SANDBOX y dos en PSICOLE produjeron el mismo hash semántico y conservaron en cero los deltas de nomenclador, órdenes, rendiciones, lotes, facturas, pagos, recibos y comunicaciones.

• 11 grupos quedan AWAITING_SECONDARY_TARIFF_EVIDENCE: requieren arancel oficial o una segunda fuente independiente del mismo período;
• 2 grupos Swiss Medical quedan AWAITING_EFFECTIVE_DATE_POLICY: existen precios fuente incompatibles y debe definirse vigencia o diferencia de plan;
• 2 líneas Poder Judicial quedan REUSE_EXISTING_PENDING_OPERATOR_CONFIRMATION: coinciden en profesional, obra social, período, afiliado, prestación, cantidad e importe con una orden existente, pero el número de orden cambió.

La coincidencia económica de las dos líneas de Poder Judicial es una propuesta de reutilización, no una fusión automática. El operador debe confirmar si se trata de una reemisión; si fuera una prestación distinta, debe conservar ambas y documentar la evidencia. Hasta resolver las 15 decisiones, no se activa una tarifa, no se crea una orden y no se promueve ningún lote o factura afectado.

La evidencia auditable se conserva en provider-ooss-exception-decision-gate-20260721: incluye CSV por decisión, linaje de fuentes, precios fuente y de nomenclador, lotes/facturas afectados, cuatro replays y checksum SHA-256. Esta etapa es NO_UI: se opera como control previo al lote y no agrega una pantalla al sistema.

Estado previo que se conserva sin reescritura: 40 liquidaciones PENDING, todas sin factura recibida aprobada; 11 lotes (9 validados, 1 pagado y 1 borrador); y 10 pagos de lote (9 pendientes y 1 confirmado). Estos estados no prueban por sí solos que una liquidación individual esté pagada y no autorizan inferir una transferencia al prestador.

Importación masiva de pacientes (Admin)

El Administrador puede importar los pacientes de cualquier prestador desde el historial completo de órdenes:

• Endpoint: POST /api/v1/operator/provider-patients/bulk-import
• Body: { "professionalId": "...", "importAllHistory": true }
• Resultado: { created, updated, skipped, total }
• Para lotes grandes (más de 200 órdenes), el proceso corre en background y registra el resultado en el log de auditoría.

Directorio público del prestador

El prestador controla su presencia en el directorio público desde Mi Perfil Público:

• Activar/desactivar el perfil público.
• Completar bio, especialidades, obras sociales aceptadas, modalidad de atención, horarios y datos de contacto públicos.
• Subir foto de perfil.

Los cambios aplican de inmediato (respetando el TTL de caché del directorio: 2 minutos).

API pública del directorio

Ver documentación completa en Directorio Público.

Reglas de negocio

Precio oficial y revisión tarifaria

Las órdenes nuevas derivan su precio del nomenclador oficial de la obra social, código de prestación y fecha de servicio. El valor escrito por el formulario no reemplaza esa fuente.

• Si existe un nomenclador activo y vigente, la orden conserva el código, la versión y el precio oficial utilizado.
• Si el importe ingresado difiere, con PROVIDER_PRICING_GUARD_MODE=enforce se usa el precio oficial. Una excepción manual requiere motivo y la capacidad de Finanzas o Administración.
• Si no existe un precio confiable, la orden queda PENDING_REVIEW. No se inventa un monto ni se habilita una factura o liquidación nueva sobre esa orden.
• La corrección existente de una orden permite aprobar el precio con motivo y clave idempotente. Repetir el mismo comando recupera el resultado; cambiar el contenido con la misma clave se rechaza.
• Las órdenes históricas no se reescriben, cancelan ni cambian de estado por activar la guarda. Se presentan como cola de revisión y conservan sus liquidaciones y facturas existentes.

Durante la activación gradual, PROVIDER_PRICING_GUARD_MODE=observe calcula y registra la diferencia, conserva el precio solicitado como PENDING_REVIEW y no hace bloqueante la capacidad de aprobación: mantiene la decisión legada. Sólo PROVIDER_PRICING_GUARD_MODE=enforce aplica el precio oficial y rechaza con 403 una aprobación manual solicitada por un rol sin la capacidad tarifaria, además de bloquear órdenes pendientes en las operaciones protegidas.

Para fuentes históricas sin número de orden, un identificador sintético sólo es admisible cuando matrícula, obra social, período, afiliado, prestación, cantidad e importes forman una firma única, no existe una orden equivalente y el identificador se deriva del hash inmutable de la fuente. El preview debe probar unicidad, colisiones, idempotencia y delta cero. Aun cumpliendo identidad, una tarifa faltante o contradictoria mantiene la línea en revisión y bloquea su factura y lote.

Si dos fuentes traen la misma firma económica con distinto número de orden, el sistema no debe crear una segunda orden ni fusionarlas por sí solo. La línea queda en revisión hasta que el operador confirme reemisión o prestación distinta y deje trazabilidad del documento que respalda la decisión.

Errores frecuentes

Preguntas frecuentes

¿Puede un prestador tener pacientes con múltiples obras sociales? Sí. La libreta soporta múltiples OOSS por paciente, cada una con su número de afiliado y plan. Al crear una orden, el prestador elige cuál OOSS usar.

¿Qué pasa si el turno no tiene paciente de la libreta? El turno puede crearse con nombre libre (sin vincularlo a la libreta). Al completarlo, el sistema igualmente permite crear la orden aunque el paciente no esté registrado.

¿Cómo funciona la notificación al paciente? Si el paciente tiene email registrado en la libreta y el prestador activó la opción "Notificar al paciente" al crear el turno, el sistema envía un email automático de confirmación con fecha, hora y modalidad de la sesión.

¿Puede el prestador ver órdenes observadas? Sí. Las órdenes observadas aparecen con el motivo visible en el portal del prestador, para que pueda informar a su obra social la corrección necesaria.

🖥 Escritorio Panel de liquidaciones y comisiones a prestadores

📱 Móvil Panel de liquidaciones y comisiones a prestadores

Liquidaciones y Comisiones

Descripción

El módulo de Liquidaciones y Comisiones cubre el ciclo completo de distribución de fondos entre el Colegio y los psicólogos que operan como prestadores de obras sociales. Una vez que el operador aprueba un lote mensual de órdenes de servicio, el sistema calcula automáticamente la comisión del Colegio para cada tipo de prestación y genera los documentos de liquidación individuales.

Las comisiones son totalmente configurables: pueden definirse como porcentaje o monto fijo, diferenciadas por obra social, por tipo de prestación y con vigencias temporales (ej. una tarifa que rige solo desde el 1 de enero). Esto permite reflejar los acuerdos comerciales vigentes sin necesidad de desarrollo adicional.

La etapa final es la generación de lotes de pago: el sistema agrupa las liquidaciones aprobadas, genera la orden de transferencia bancaria consolidada y registra cada pago efectuado para su posterior conciliación. El historial de liquidaciones y los comprobantes están disponibles tanto para el operador como para el prestador desde su portal de autogestión.

Roles con acceso

Flujo principal

1. Configurar comisiones

1. Ir a Administración → Liquidaciones → Configuración de Comisiones.
2. Seleccionar la obra social para la cual se define la comisión.
3. Hacer clic en Nueva Regla de Comisión.
4. Configurar los parámetros:
5. Tipo de aplicación: porcentaje sobre el monto de la orden o monto fijo por orden.
6. Tipo de prestación: aplicar a todas las prestaciones o a un tipo específico (consulta, evaluación, informe, etc.).
7. Vigencia desde: fecha a partir de la cual aplica esta regla.
8. Vigencia hasta: opcional; si no se especifica, la regla rige indefinidamente.
9. Guardar. El sistema muestra el historial de reglas con sus vigencias para auditoría.
10. Para una obra social con múltiples reglas, el sistema aplica siempre la regla más específica vigente al momento del cierre del lote.

2. Revisión automática de liquidaciones generadas

1. Al aprobar un lote mensual desde el módulo de Prestadores, el sistema genera automáticamente una liquidación por cada prestador del lote.
2. Ir a Liquidaciones → Pendientes de Revisión.
3. Cada liquidación muestra: prestador, obra social, período, total de órdenes, monto bruto, comisión aplicada, monto neto a transferir.
4. El operador puede expandir el detalle para ver el cálculo orden por orden y verificar que la comisión se aplicó correctamente.
5. Si el cálculo es correcto, cambiar el estado a APROBADA. Si hay discrepancias, cambiar a EN_REVISION y agregar un comentario.

Facturas de prestadores y liquidaciones

La factura que emite el prestador al Colegio se gestiona sobre la liquidación, cuando el neto definitivo ya fue calculado. No se adjunta para cerrar la rendición ni se genera desde el modelo de factura de Obra Social.

El flujo canónico es:

1. Validar las órdenes del período.
2. Generar o asociar la liquidación del prestador.
3. El prestador carga la factura real desde Liquidaciones, informando número, fecha, importe y archivo.
4. El sistema registra la factura en received_invoices. Si corresponde a una sola liquidación conserva el vínculo directo; si agrupa varias OOSS del mismo prestador y período, registra asignaciones documentales explícitas contra cada liquidación. payment_settlements.invoice_* permanece sólo como espejo de compatibilidad del vínculo directo.
5. El operador la encuentra en Prestadores → Liquidaciones de pagos → Facturas recibidas, verifica archivo, identidad e importe neto y la aprueba u observa.
6. Recién con estado APPROVED_FOR_PAYMENT se habilita registrar el pago de la liquidación. La aprobación de la factura no crea por sí sola una transferencia, un recibo ni una comunicación.

Cuando el Colegio recibe una factura antes de contar con una liquidación canónica compatible, puede registrarla como documentación recibida. En ese caso queda REGISTERED, sin paymentSettlementId ni paymentOperationId. El archivo, la identidad fiscal y el motivo de bloqueo permanecen visibles, pero el registro no habilita aprobación, pago ni comunicación.

El prestador consulta todas sus facturas canónicas en la pantalla existente de Liquidaciones, aunque todavía no estén vinculadas a una liquidación. La API resuelve el propietario desde la sesión y filtra por issuerType=PROVIDER e issuerId exacto; no admite elegir otro prestador por parámetro. La vista marca las filas sin vínculo como Sin liquidación exacta y conserva por separado la existencia del comprobante y la disponibilidad de su archivo físico.

Un gate documental posterior puede vincularla a una liquidación PENDING únicamente cuando coinciden de forma inequívoca prestador, período económico, importe neto y archivo fiscal. También admite una factura agregada cuando una única combinación de liquidaciones del mismo prestador y período suma exactamente el importe fiscal. Cada asignación conserva su importe y su clave idempotente; una liquidación no puede recibir dos facturas activas por esta vía. El vínculo cambia la factura a LINKED_TO_SETTLEMENT y la expone en todas las liquidaciones cubiertas, pero no confirma el cobro de la Obra Social, no aprueba la factura y no genera una operación PAY.

La autorización de pago sigue siendo estricta: una factura agregada requiere revisión financiera de toda la composición y no puede habilitar por sí sola el pago individual de ninguna liquidación. El replay del gate debe producir cero altas y cero cambios económicos.

Estados de la factura recibida:

Contrato de privacidad para el prestador

Las respuestas y documentos propios del prestador se construyen desde un modelo de presentación separado del modelo administrativo. Exponen monto neto, período, estado, OOSS, factura y trazabilidad propia; omiten importe bruto, porcentaje de comisión e importe de comisión del Colegio. La omisión es sólo de presentación: los valores administrativos permanecen intactos y disponibles para roles financieros autorizados.

El inventario de facturas se pagina en servidor y siempre deriva el professionalId desde la sesión autenticada. No acepta otro prestador por query string. La descarga del archivo vuelve a comprobar factura, liquidación y propietario; conocer la ruta física no concede acceso.

El recibo descargable desde el portal se genera con el mismo contrato neto. No reutiliza un PDF administrativo que pueda incluir comisión. La prueba de regresión exige que payload, HTML y PDF propios no contengan claves o rótulos de bruto/comisión y que una liquidación ajena responda acceso denegado.

La pestaña Prestador también proyecta cada liquidación sin comprobante como Pendiente de presentación. Esa fila no es una factura fiscal, no tiene archivo y no crea un registro en received_invoices: identifica la obligación documental, con su período, neto y liquidación de origen. Cuando se recibe una factura real, la fila esperada deja de mostrarse y aparece el comprobante con su estado canónico. No presentada significa que el Colegio todavía no recibió el archivo; Falta archivo significa que existe un registro fiscal que debe ser revisado porque no conserva un adjunto utilizable.

El número de factura es único por prestador. El importe debe coincidir con el neto de la liquidación, con una tolerancia máxima de $ 1,00 para redondeos. Si el prestador reemplaza una factura todavía no aprobada, la anterior no se borra: queda CANCELLED, conserva su archivo histórico y el archivo vigente se refleja en la liquidación.

La lista operativa permite buscar por prestador, número de factura, período, liquidación u obra social. También filtra por Registradas sin liquidación, En revisión, Aprobada para pago, Pagada, Cancelada y Legada: revisar. Las facturas vinculadas respetan el período operativo seleccionado; las registradas sin liquidación conservan su período fiscal propio y permanecen en la bandeja documental hasta vincularse. Las filas legadas son referencias anteriores sin identidad canónica completa y nunca se aprueban automáticamente.

Gate documental histórico 2023–2026

El 22/07/2026 se cerró el inventario completo de las facturas enviadas por prestadores al Colegio. La fuente contenía 297 archivos: 3 eran copias duplicadas y 1 no era una factura. El universo canónico quedó en 293 comprobantes fiscales pertenecientes a 43 profesionales: 4 de 2023, 74 de 2024, 143 de 2025 y 72 de 2026. Cada registro conserva PDF privado, clave fiscal, hash de fuente, período económico y evidencia de identidad.

El contraste revisó además 275 planillas de órdenes, facturación y liquidaciones de OOSS, incluyendo las fuentes adicionales de mayo y junio de 2026. Después de deduplicar evidencia, 22 facturas tienen importe neto documental exacto: 13 en el período declarado y 9 con corrección de período respaldada por la fuente. Sólo 3 cuentan también con una liquidación relacional exacta y permanecen LINKED_TO_SETTLEMENT; las otras 19 siguen REGISTERED hasta que exista esa liquidación canónica. Las 271 restantes conservan el motivo Sin liquidación fuente.

Una diferencia entre factura, bruto de órdenes y neto no demuestra por sí sola un rechazo de la Obra Social. Puede corresponder a comisión, débito explícito, ajuste o diferencia de período. El sistema sólo muestra rechazo OOSS cuando una fuente lo declara; nunca lo completa por cercanía de nombre o importe.

El importador es idempotente por CUIT emisor, punto de venta, número y hash del archivo. En SANDBOX y PSICOLE incorporó 221 comprobantes históricos y completó los metadatos de las 72 facturas 2026 ya registradas. El replay posterior resolvió las 293 como NOOP: no creó pagos, recibos, operaciones, órdenes, rendiciones, liquidaciones, mensajes, correos ni avisos, y no cambió roles o estados.

El verificador independiente confirmó en ambos entornos 293/293 registros, 293/293 archivos, 43 profesionales, los mismos períodos y decisiones documentales, 0 extras y 0 problemas. La consulta se realiza en Prestadores → Liquidaciones de pagos → Facturas recibidas o en Profesionales → perfil → Prestador. El selector del panel incluye los períodos históricos con información.

Ampliación del archivo maestro 2018–2026

El 24/07/2026 se auditó el archivo histórico externo organizado por emisor. De 2.541 archivos físicos quedaron 2.360 documentos únicos después de excluir 181 copias binarias. El gate separó:

• 2.158 facturas certificadas para perfiles profesionales;
• 3 duplicados fiscales internos y 3 comprobantes ya registrados en el gate anterior;
• 117 documentos cuyo destinatario no certifica una factura de prestador al Colegio;
• 4 documentos que requieren revisión;
• 75 candidatos excluidos del subconjunto importable porque corresponden a proveedores o gastos institucionales, o porque no tienen una identidad profesional única.

La identidad se resuelve por CUIT profesional exacto. Cuando el CUIT almacenado en el perfil es incompleto o legado, se admite el DNI de ocho dígitos embebido en un CUIT individual válido con prefijo 20, 23, 24 o 27, siempre que exista un único profesional con ese DNI. No se usa nombre, carpeta, monto ni cercanía textual como única prueba de identidad.

SANDBOX y PSICOLE incorporaron las 2.158 facturas certificadas como REGISTERED, con PDF privado y hash verificado. Sumadas al archivo anterior, cada entorno conserva 2.451 facturas. El subconjunto nuevo corresponde a 282 profesionales identificados de forma inequívoca. El verificador comprobó 2.158/2.158 registros y archivos nuevos, 0 problemas y replay NOOP completo en ambos entornos. El apply agregó sólo las facturas y sus auditorías: no creó pagos, recibos, operaciones, deudas, órdenes, rendiciones, liquidaciones, mensajes, correos ni avisos.

La promoción productiva se ejecutó después de un respaldo verificable de base y archivos. El replay devolvió 2.158 NOOP y los contadores económicos y operativos conservaron delta cero. La prueba autenticada confirmó que el perfil devuelve sus facturas y que el PDF se descarga únicamente por la ruta privada protegida.

El cruce complementario de OOSS revisó 13.532 prestaciones institucionales únicas, 2.267 líneas de liquidación y 173 combinaciones prestador/período. Las coincidencias económicas son evidencia para revisión; no vinculan automáticamente una factura a una liquidación ni convierten una diferencia de importe en rechazo de OOSS.

Certificación fail-closed de la cadena económica

La certificación integral evalúa por separado cuatro coberturas obligatorias:

1. cada liquidación debe tener factura canónica;
2. cada lote mensual OOSS debe conservar una respuesta;
3. cada pago de lote debe tener movimiento bancario vinculado;
4. cada factura institucional OOSS debe conservar sus líneas de detalle.

Si cualquiera de esos contadores es distinto de cero, el resultado es INCOMPLETE y el auditor finaliza con error. Un conjunto de órdenes, importes o fechas compatibles puede ordenar la revisión, pero no sustituye estas relaciones persistidas. La certificación no corrige datos, no cambia estados y no crea pagos, recibos, operaciones o comunicaciones.

Cruce contra débitos bancarios de prestadores

El control de egresos usa el extracto Galicia, no los reportes de débito automático de colegiación. La secuencia mínima es:

neto documental → liquidación canónica → factura aprobada → débito Galicia → operación PAY aprobada/conciliada.

Un importe exacto en el banco es evidencia para revisar, no una autorización de pago. En el gate vigente se encontraron 54 egresos documentales exactos; sólo 2 tienen además una liquidación relacional del mismo período e importe y ninguna completa toda la secuencia. Las 47 filas sin liquidación y las 5 con diferencia de importe permanecen bloqueadas.

Los archivos de instrucciones bancarias tampoco sustituyen al extracto: de 21 instrucciones históricas, 16 tienen importe parcial o desactualizado y ninguna demostró por sí sola una ejecución exacta. El operador debe consultar la factura y la liquidación existentes, no crear una segunda a partir del archivo bancario.

Archivo general de liquidaciones 2026

El archivo general se usa como evidencia documental auxiliar para reconstruir la cadena prestador/período. No sustituye la liquidación canónica, la factura recibida, el extracto bancario ni la aprobación de pago.

El gate 2026 procesó 384 filas de 95 prestadores por $94.443.978,40. Encontró 42 egresos Galicia exactos con identidad suficiente. Nunca se acepta una coincidencia basada sólo en importe. La fecha bancaria tampoco puede ser anterior a la fecha de factura o, si no existe, a la fecha de liquidación.

El cruce final resolvió las 16 variantes de identidad que permanecían bloqueadas. La compatibilidad admite únicamente un prestador inequívoco y se limita a segundo nombre omitido, apellido compuesto sin espacio o una sola letra diferente en un token largo. La evidencia queda identificada con el método utilizado, siempre requiere revisión humana y nunca autoriza una liquidación o un pago automático.

La cola final contiene 76 candidatos humanos:

• 37 filas documentales con liquidación para revisar;
• 3 retenciones documentales con liquidación pero sin banco probado;
• 35 egresos exactos sin liquidación canónica del período;
• 3 egresos exactos con diferencia contra el importe persistido;
• 1 cadena con débito y liquidación individual exactos, todavía pendiente de aprobación humana.

Otras 3 filas declaradas RETENIDO contradicen un débito exacto. Esas contradicciones quedan bloqueadas y no se persisten como candidatos.

Permanecen fuera de cualquier vinculación automática 240 filas sin liquidación del sistema, 46 diferencias de importe, 19 egresos anteriores a la factura y 3 contradicciones entre estado retenido y débito bancario. No quedan identidades bloqueadas en el libro general. El estado DEPOSITADO del archivo tampoco prueba ejecución bancaria. El apply sólo persiste evidencia en MoneyAssociationCandidate; no crea ni actualiza pagos, recibos, deudas, órdenes, liquidaciones, facturas, estados o comunicaciones. El replay debe devolver 0 altas y los mismos candidatos.

Las planillas mensuales vivas de enero a mayo agregan una comprobación independiente de cuenta bancaria. Sus 262/262 filas se vincularon de forma única al libro general: 17 cuentas registradas confirmaron al prestador, 16 filas tuvieron además un débito Galicia único, 4 explicaron la relación bruto/neto por la comisión del 10% y no hubo conflictos de cuenta. En 11 filas la planilla mensual no aporta por sí sola una identidad bancaria independiente; conservan el vínculo del libro general, pero no suman evidencia para pagar. La carpeta viva no contiene planillas mensuales equivalentes de junio o julio; esos períodos continúan respaldados por el archivo general y el extracto, sin inventar una confirmación de cuenta ausente.

Para resolver un candidato, el operador debe reconstruir la secuencia: órdenes OOSS → lote/cobro OOSS → liquidación neta → factura aprobada → débito Galicia → operación PAY. Una diferencia de monto exige revisar comisión, ajustes, órdenes rechazadas documentadas o distribución entre lotes; no autoriza completar la causa por inferencia.

Auditoría de reciprocidad OOSS y prestadores

El control del 27/07/2026 separó los dos sentidos del circuito:

• OOSS → Colegio: 21 lotes mensuales y 20 pagos de lote registrados. Ninguno tiene todavía un movimiento bancario vinculado; por lo tanto el lote distribuido no prueba cobro.
• Colegio → prestador: 130 liquidaciones, 125 con operación económica asociada y sólo 3 con factura canónica. Todas continúan PENDING; una operación relacionada no equivale a pago aprobado o conciliado.
• Prestador → Colegio: 2.451 facturas físicas preservadas en 305 perfiles. Sólo los tres vínculos exactos forman parte hoy de una liquidación canónica; las demás conservan valor documental.
• Colegio → OOSS: 418 facturas institucionales registradas, 81 con PDF físico disponible. La factura documenta emisión fiscal, no acreditación.

Las dos referencias físicas rotas fueron restauradas por hash y el control posterior informa physicalMissingTotal = 0 en ambos entornos. La certificación económica completa sigue bloqueada por las cadenas sin liquidación canónica, las diferencias de importe y la ausencia de vínculos bancarios persistidos; no corresponde recalcular, marcar pagado o sustituir evidencia automáticamente.

Control de distribución del lote

Antes de vincular órdenes faltantes o reconstruir una liquidación, el control suma todas las liquidaciones del prestador y período y audita el lote OOSS de destino. Varias liquidaciones mensuales son válidas si provienen de lotes u obras sociales diferentes; la igualdad se evalúa sobre el agregado mensual y se conserva el detalle por lote.

Si el neto pagado del lote ya coincide con la suma de sus liquidaciones, el sistema clasifica cualquier nueva orden candidata como TARGET_BATCH_FULLY_ALLOCATED_REVIEW. La identidad correcta de una orden no habilita por sí sola una nueva distribución: primero debe existir evidencia de que el pago OOSS, un débito, un rechazo o una asignación previa están incompletos o incorrectos. Hasta entonces no se crea ni modifica una liquidación.

Las líneas documentales repetidas que no pueden distinguirse individualmente se validan como conjunto. El estado SET_EQUIVALENT_ORDER_GROUP_REVIEW exige igualdad de cardinalidad y firma económica entre líneas y órdenes, pero mantiene el vínculo bloqueado hasta resolver el lote. Esta regla evita elegir una fila arbitraria y mantiene la idempotencia del circuito.

Cobertura documental y confirmación bancaria del lote

El control del lote separa tres comprobaciones que no son equivalentes:

1. Cobertura documental: cada orden del lote debe corresponder a una línea de la respuesta o liquidación de la OOSS.
2. Distribución aritmética: el aceptado, los débitos explícitos, la comisión y el neto distribuido deben cerrar por lote y prestador.
3. Evidencia bancaria: el cobro de la OOSS y el pago al prestador requieren movimientos bancarios vinculados a sus operaciones económicas.

Un lote puede cerrar internamente y seguir PENDING. FULLY_ALLOCATED sólo indica que el neto registrado fue distribuido entre liquidaciones; no demuestra que la OOSS haya transferido el dinero ni que el Colegio haya pagado a los prestadores.

El gate de mayo/junio 2026 auditó 9 lotes, 984 órdenes y 92 liquidaciones en SANDBOX y PSICOLE. Todas las órdenes del sistema tienen respaldo documental y la distribución no presenta diferencias económicas; un agregado de Swiss Medical difiere $ 0,04 por redondeo de 63 líneas y queda identificado como tolerancia, no como rechazo. Sin embargo:

• 8 lotes son subconjuntos de la documentación mensual: existen 435 líneas fuente que no integran esos lotes;
• sólo Poder Judicial junio tiene cobertura documental exacta;
• los 9 pagos de lote fueron cargados con procedencia sandbox_provider_settlements_202606, siguen PENDING y declaran que no confirman extracto bancario;
• no existe un movimiento bancario vinculado al cobro OOSS ni a las 92 liquidaciones.

El gate siguiente contrastó el manifiesto certificado con las transacciones Galicia persistidas. Luego de importar en SANDBOX el segundo extracto de julio por hash y clave de deduplicación, registró 18 candidatos exclusivamente humanos: 6 apuntan a un pago de lote exacto y pendiente, y 12 conservan la evidencia contra la cohorte OOSS/período hasta completar el lote. Ninguno tiene paymentOperationId, puede autoaplicarse o cambia el estado del lote.

Poder Judicial julio se mantuvo bloqueado mientras faltó una de las dos transferencias que componen su evidencia. Con la fuente completa, SANDBOX y PSICOLE produjeron 18/18 filas funcionalmente idénticas al excluir únicamente UUID técnicos. El apply SANDBOX creó los 2 candidatos faltantes; el replay creó 0, dejó 18 sin cambios y no modificó el snapshot económico. La paridad se resolvió cargando la fuente, nunca copiando candidatos desde producción.

El primer control exacto dejó 5 cobranzas OOSS listas para aprobación humana y 1 bloqueada. La corrección histórica posterior normalizó en SANDBOX cuatro órdenes OSTV y cerró la diferencia de $187.200 sin recalcular lote, pago, comisión, neto o liquidación.

El auditor posterior compara ahora el bruto de órdenes con el bruto del lote y concilia por separado bruto - aceptado contra los ajustes. Dos replays dejaron 6/6 cobranzas exactas listas sólo para aprobación humana: OSTV cerró con $2.048.900,00 brutos, $1.986.500,00 aceptados y $62.400,00 de ajustes, sin gaps. Los seis pagos a prestadores continúan bloqueados por facturas canónicas incompletas; no se aprobó cobro, liquidación o pago alguno y PSICOLE no cambió.

Por eso no se agregan líneas faltantes a un lote ya distribuido ni se marca una liquidación como pagada. Sólo después de paridad, revisión humana y aprobación explícita corresponde vincular el cobro OOSS; reconstruir un lote complementario o corregir una distribución sigue siendo una acción económica separada, idempotente y auditada.

Los reportes de débito automático y tarjeta de colegiación son antecedentes de cobros entrantes de cuotas. Nunca se usan como evidencia del cobro de una OOSS ni del pago a un prestador.

Las capturas públicas corresponden al corte inicial 2026. La validación vigente se repitió en escritorio y móvil y abrió el PDF autenticado desde ambas rutas; no se publican capturas actuales de perfiles porque exponen datos personales y fiscales.

Si una orden figura pagada pero todavía no aparece una liquidación asociada, debe regularizarse desde el circuito de liquidaciones antes de cargar la factura. El sistema no debe permitir cargar una factura del prestador sobre una orden suelta sin liquidación formal.

3. Generar lote de pago

1. Ir a Liquidaciones → Lotes de Pago → Nuevo Lote.
2. Seleccionar el período y las liquidaciones aprobadas que se incluirán en el lote (se puede filtrar por obra social, período o prestador).
3. El sistema muestra el resumen del lote: cantidad de liquidaciones, monto total a transferir, detalle por prestador con CBU/CVU destino.
4. Revisar y hacer clic en Generar Lote.
5. El lote queda en estado GENERADO. Descargar el archivo de transferencias bancarias en el formato requerido por el banco (SEPA, TXT Bancario, etc.).
6. Procesar la transferencia desde el homebanking. Una vez acreditada, regresar al lote y hacer clic en Marcar como Pagado, adjuntando el comprobante bancario.
7. El lote pasa a estado PAGADO y cada liquidación incluida queda en estado LIQUIDADA.

4. Conciliación mensual de liquidaciones

1. Ir a Liquidaciones → Conciliación Mensual.
2. Seleccionar el mes a conciliar.
3. El sistema cruza las liquidaciones pagadas contra los débitos registrados en la cuenta bancaria del Colegio (importados desde el módulo de Conciliación Bancaria).
4. Las transferencias que coincidan quedan marcadas como CONCILIADA. Las que no coincidan quedan como PENDIENTE_CONCILIACION.
5. Resolver manualmente las pendientes, adjuntando evidencia del pago si es necesario.
6. Al cerrar la conciliación mensual, se genera el informe de cierre con los totales por obra social.

5. Consulta del historial de liquidaciones

1. En Liquidaciones → Historial, filtrar por período, prestador, obra social o estado.
2. Seleccionar una liquidación para ver su detalle completo: cada orden incluida con código de prestación, monto, comisión aplicada y monto neto.
3. Descargar el comprobante de liquidación en PDF (disponible también para el prestador en su portal).
4. El historial es permanente e inmutable: las liquidaciones cerradas no pueden editarse, solo anularse con nota de crédito si corresponde.

Campos y validaciones

Reglas de negocio

Errores frecuentes

Preguntas frecuentes

¿Se puede tener comisiones diferentes para la misma obra social según el tipo de prestación? Sí. Se pueden configurar tantas reglas como tipos de prestación existan. Por ejemplo: 10% para consultas, 8% para evaluaciones y $500 fijo por informes periciales. El sistema aplica la regla más específica vigente.

¿Cómo se maneja un error en el monto de una liquidación ya aprobada? No se puede editar una liquidación aprobada. El procedimiento correcto es anular la liquidación (genera un registro de anulación en el historial) y generar una nueva liquidación corregida. Si el lote ya fue pagado, la corrección se realiza mediante nota de crédito/débito en el próximo período.

¿El prestador recibe algún aviso cuando se genera su liquidación? No desde este circuito. La generación de liquidación, la carga y la aprobación de factura son operaciones inertes respecto de mensajería. Cualquier comunicación al prestador debe iniciarse de forma explícita desde el canal operativo correspondiente.

¿Cómo afecta el cambio de CUIT de una obra social a las liquidaciones históricas? El cambio de CUIT no modifica liquidaciones pasadas. Las liquidaciones históricas conservan el CUIT que tenía la obra social al momento del cierre del lote. El nuevo CUIT aplica solo para liquidaciones futuras.

¿Se puede liquidar a un prestador en cuotas? No. Cada liquidación mensual se paga en una única transferencia. Las cuotas no aplican al mecanismo de liquidación a prestadores, que está diseñado para pagos únicos mensuales.

🖥 Escritorio Portal de autogestión: cuenta corriente y credencial

📱 Móvil Portal de autogestión: cuenta corriente y credencial

Autogestión del Profesional

Descripción

El portal de Autogestión es la interfaz propia del psicólogo matriculado para interactuar con el Colegio sin intermediación administrativa. Disponible las 24 horas desde cualquier dispositivo, permite consultar la cuenta corriente, pagar deudas por una pasarela habilitada, descargar recibos y mantener datos personales actualizados.

El módulo está diseñado para reducir la carga operativa de las ventanillas físicas y agilizar trámites que históricamente requerían turno presencial. Los documentos generados (recibos, certificados, credencial digital) tienen validez oficial y están firmados digitalmente por el sistema.

Las solicitudes de modificación de datos (cambio de domicilio, teléfono, CUIT, especialidad declarada, etc.) no se aplican de forma inmediata sino que generan un flujo de aprobación interno: un operador de matrículas revisa los cambios y los aprueba o rechaza con un comentario. Esto garantiza la integridad del padrón de matriculados.

Dashboard: deuda vencida real y cuotas futuras

El aviso rojo del dashboard representa únicamente deuda vencida real. Para mostrarlo debe existir al menos una obligación abierta cuya fecha de vencimiento ya haya pasado. El importe y la cantidad del aviso se calculan con esas obligaciones vencidas, no con todas las cuotas abiertas.

• Una cuota del mes vigente o de un mes futuro puede verse en Estado de Cuenta, pero no debe presentarse como mora antes de su vencimiento.
• Si no hay deuda vencida, el dashboard no reutiliza un total general de deuda para fabricar un aviso rojo.
• Si una cuota futura aparece como vencida, no debe pagarse ni corregirse por inferencia: hay que informar el caso mediante el signo ? para que se revise su fecha y trazabilidad.

Evidencia operativa. El 12/08/2026 una identidad sintética de Producción, sin filas financieras, mostró Al día, sin aviso rojo ni desborde en escritorio y 390×844. Login, perfil, cuenta, agenda, documentos y tickets respondieron 200. Después de la prueba la cuenta quedó inactiva, la contraseña se rotó y se revocaron las sesiones. La captura histórica queda sólo como referencia de diseño; no se publica la captura efímera de Producción.

Perfil y autogestión en pantallas pequeñas

En teléfono, las acciones Editar perfil, Contraseña, Historial y Pagos se acomodan en filas completas, con áreas táctiles legibles. Los paneles de edición e historial usan el alto visible del dispositivo, conservan el contenido desplazable y bloquean el scroll de la página que queda detrás. Esto evita que el teclado o las barras del navegador oculten las acciones.

El profesional puede cargar documentación propia desde su perfil. La eliminación de documentación gobernada por el Colegio continúa reservada a los roles administrativos autorizados.

Evidencia visual pendiente. No existe todavía un par sanitizado que pruebe el nuevo comportamiento de perfil en 1440 px y 390 px; no se declara certificación visual hasta incorporarlo.

Cambios recientes en la vista de perfil

• Bitácora: se retiró de la vista de perfil (pestaña propia y ficha pública del profesional) y de la navegación del directorio. La funcionalidad de publicaciones quedó desactivada; ya no hay acceso desde los perfiles ni desde las rutas públicas del directorio.
• Póliza de Mala Praxis: dejó de mostrarse en el perfil permanente. Es un requisito propio de la gestión de prestadores y se administra dentro de los trámites de alta y renovación de prestadores, no como condición permanente del perfil.
• Notificaciones por WhatsApp: el selector quedó desactivado en la interfaz con el aviso "Disponibles próximamente". La preferencia guardada se conserva en la cuenta y podrá reactivarse cuando el canal esté disponible.

Evidencia visual: No aplica para este cierre. Se retiraron controles y rutas; las capturas vigentes del perfil no muestran esos elementos.

Roles con acceso

Flujo principal

1. Ver estado de cuenta y deudas

1. Al iniciar sesión, el panel principal muestra un resumen de la cuenta corriente: saldo deudor, próximo vencimiento y últimos movimientos.
2. Ir a Mi Cuenta → Estado de Cuenta para ver el detalle completo.
3. La vista lista todas las cuotas y conceptos adeudados con fecha de vencimiento, monto original, recargos por mora acumulados y total a pagar.
4. Usar los filtros por período, tipo de cuota o estado (vigente, vencida, pagada) para acotar la consulta.
5. Las cuotas próximas a vencer (dentro de los 7 días configurables) se destacan con una alerta visual.

2. Pagar online por pasarela habilitada

1. Desde el estado de cuenta, marcar las cuotas o conceptos a pagar con el checkbox correspondiente.
2. Hacer clic en Pagar Seleccionados. El sistema muestra el resumen del pago con el total que se procesará.
3. Confirmar y continuar hacia la pasarela habilitada, por ejemplo NAVE.
4. Completar los datos de pago en la interfaz externa del proveedor. PSICOLE no almacena datos de tarjeta.
5. Al recibir o consultar la confirmación aprobada, el sistema registra la operación PAY, imputa la deuda y genera el recibo REC.
6. El colegiado es redirigido al portal de PSICOLE con la confirmación del pago y el enlace para descargar el recibo.

3. Descargar recibos

1. Ir a Mi Cuenta → Mis Recibos.
2. Se lista el historial de todos los pagos realizados, con fecha, concepto, monto y número de recibo.
3. Hacer clic en Descargar en el recibo deseado para obtener el PDF oficial con membrete del Colegio y firma digital del sistema.
4. El recibo incluye un código de verificación que permite confirmar su autenticidad en el portal público del Colegio.
5. Los recibos están disponibles para descarga indefinidamente desde el historial.

4. Descargar certificados

1. Ir a Mi Cuenta → Mis Certificados.
2. El sistema lista los certificados disponibles por tipo:
3. Certificado de Matrícula Vigente: acredita que la matrícula está activa al día de la fecha.
4. Certificado de Libre Deuda: acredita que no existen deudas pendientes con el Colegio.
5. Certificados de Cursos: emitidos al completar los cursos de capacitación (con QR verificable).
6. Para certificados con validez temporal (matrícula, libre deuda), hacer clic en Generar Nuevo para obtener uno con la fecha actual. Los certificados anteriores quedan archivados.
7. Descargar el PDF. El certificado tiene validez de 30 días (configurable) y muestra la fecha de emisión.