Resumen del alcance — Pago con documentos

Análisis Funcional: Pago con documentos — parte 1 de 5. Índice · Siguiente: El flujo del pago →

Este paquete cubre todo lo que ocurre en el mostrador cuando un beneficiario viene a cobrar un giro de Soterex: cómo se lo identifica, qué se le pide, qué datos carga el operador, qué papel se imprime y firma, y qué escaneos quedan guardados contra la transacción.

Lo que pasa con la plata —de qué caja sale, contra qué prefondeo se descuenta— vive en el Módulo Caja. Lo que pasa con la transacción como registro —cómo llega, qué estados tiene, quién la puede ver— vive en el Análisis Funcional original.

0.1 Qué problema resuelve y para quién

Hasta E4b, pagar era un botón. El operador buscaba el MTCN, confirmaba, y la transacción pasaba a PAID. Eso alcanzaba para el control interno, pero no alcanza para el regulador ni para una auditoría.

El material de CIS-EC del 2026-08-07 lo dejó explícito en dos requerimientos:

"Si Soterex no envía la columna por la API, favor incluir los campos en la pestaña del pago de la tx (Módulo Cajero)" — requerimiento #1, hoja Requerimientos.

"Permitir guardar en c/tx los siguientes documentos: la carta que envía Soterex, la identificación del cliente (anverso y reverso), foto del cliente con la identificación junto al rostro, la papeleta firmada por el cliente y el operador" — requerimiento #5.

Traducido: de las 36 columnas que quedan en el reporte transaccional de CIS, una parte no la manda Soterex — la tipea el cajero mientras el cliente está enfrente, porque es el único momento en que esa información existe. Y el respaldo de que el pago ocurrió no es el registro en la base: es un legajo de escaneos que hay que poder mostrar meses después.

Los tres destinatarios reales de este módulo:

Quién	Qué necesita
El operador de ventanilla	Un flujo que no lo frene: si el cliente ya se llevó la plata, poder registrar el pago aunque le falte un escaneo.
Cumplimiento / el regulador	Las 36 columnas completas y el legajo documental de cada transacción.
Auditoría interna	Saber quién miró el documento de identidad de quién, y cuántas veces se reimprimió una papeleta.

0.2 Qué incluye

Capacidad	Estado
Verificación del PIN de la carta antes de habilitar el pago	❌ Se implementó y se sacó el 2026-08-10 — ver §1.2
13 campos nuevos en la transacción, 11 de ellos cargados en ventanilla	✅ Implementado
Medio de pago: efectivo o transferencia bancaria	✅ Implementado
Catálogo de 9 tipos de soporte documental, con obligatoriedad por medio de pago	✅ Implementado
Completitud derivada — "pagada pero incompleta" sin agregar un estado nuevo	✅ Implementado
Descarga auditada de cada documento, sin URL directa, acotada por PDV	✅ Implementado
Papeleta en PDF de 58 mm, reimprimible, réplica del modelo Word del cliente	✅ Implementado
Formulario de enrolamiento generado por el sistema	📋 Sin implementar — hoy se sube escaneado
Reporte regulatorio de 36 columnas	📋 Sin implementar — entrega propia; E5a le deja los datos

0.3 Qué explícitamente NO incluye

• No hay wizard de pasos obligatorios — para los nueve documentos post-pago. El plan v2 hablaba de un "wizard de tres uploads"; lo que se construyó para esos nueve tipos (después de pagar) es un formulario y un stepper visual (1, 2, 3...) — desde 2026-09-11 dibujado como pasos numerados en vez de una lista plana, pero puramente decorativo: se completa en cualquier orden y en cualquier momento, incluso días después, nunca hay un paso bloqueado ahí. Los tres documentos previos al pago (Carta + identificación) son la excepción, desde el 2026-09-12 — ver el punto siguiente y ADR-008.
• El pago se bloquea solo por Carta + identificación (anverso y reverso) — el resto de los datos y documentos, no. Hasta el 2026-09-12 esto decía "el pago nunca se bloquea"; Carlos pidió invertirlo para esos tres tipos específicamente, porque son lo que el operador tiene que cotejar contra el beneficiario antes de entregarle la plata. Ver §1.4 — la razón original (no frenar el registro después de que la plata salió del cajón) sigue vigente para todo lo demás, y es exactamente por eso que la Papeleta firmada —que no puede existir todavía— sigue sin bloquear.
• No hay borrado de documentos. No existe endpoint de baja: un soporte contable no se borra. Un escaneo mal tomado se reemplaza subiendo otro del mismo tipo, y el anterior queda (backend/routes/api.php:58-69, sin ruta DELETE).
• No hay entidad Cliente. El material dice que los cuatro documentos de transferencia van "por una sola vez" por cliente, pero no hay nada que agrupe transacciones de la misma persona: hoy se piden por transacción. Ver Preguntas Abiertas #4.
• No se guarda el PDF de la papeleta. Se genera al vuelo cada vez. Ver §3.4.
• No hay género ni estado civil, que el formulario de enrolamiento pide y el reporte no. Ver Preguntas Abiertas #6.
• No hay conversión de moneda. El cliente confirmó que el cambio de moneda va a MVP2, así que la papeleta imprime tasa 1.00000000 y los tres montos iguales (backend/app/Services/PapeletaService.php:70-76).

0.4 Reglas de negocio de más alto nivel

#	Regla	Estado	Fuente
R1	El PIN de la carta es el MTCN. No es un dato aparte y no se guarda en una columna propia	✅	Decisión de Carlos, 2026-08-07
R2	No se pide el PIN. Siendo el MTCN, por el camino habitual —buscar por número— el operador tenía que retipear lo que acababa de tipear	✅	Probado por Carlos y sacado el 2026-08-10 · §1.2
R3	El pago se bloquea solo por Carta + identificación (anverso y reverso) — el resto de los datos y documentos, no	✅	Hoja Módulo caja fila 14 · §3 del diseño técnico de E5a · modificado por ADR-008 el 2026-09-12 — ver §1.4
R4	"Pagada pero incompleta" no es un estado: se deriva de los documentos que tiene contra los que su medio de pago exige	✅	§1.3 del diseño técnico de E5a
R5	La selfie es opcional y nunca afecta la completitud	✅	Hoja Módulo caja fila 18: "DESEABLE, no es obligatorio"
R6	Con transferencia bancaria se suman cuatro documentos obligatorios	✅	Hoja Módulo caja filas 20-24
R7	Los documentos son PII sensible: nunca se sirven por URL directa, se acotan por PDV y cada acceso queda auditado	✅	§2 y §4 del diseño técnico de E5a
R8	Un documento no se edita ni se borra. Reemplazarlo es subir otro; el anterior queda	✅	TransactionDocument::$timestamps = false
R9	Una transacción ya pagada se sigue mostrando en la búsqueda, con sus soportes, para corroborarlos	✅	Hoja Módulo caja fila 11
R10	La papeleta es reimprimible y siempre sale idéntica: muestra la fecha del pago, no la de impresión	✅	PapeletaService.php:61-62

0.5 Actores

Actor	Qué hace acá	Permiso
Operador de ventanilla (Backoffice)	Identifica al cliente contra la carta, paga, completa los datos, sube los soportes, imprime la papeleta. Es quien tiene el documento de identidad en la mano.	transacciones E sobre su país y su PDV
Supervisor	Revisa qué transacciones quedaron incompletas y con qué soportes. Puede completarlas.	transacciones E
Cumplimiento (CIS-EC)	Consume los datos en el reporte regulatorio. No opera en esta pantalla.	⚠️ No es un rol del sistema — ver Módulo Caja §0.5
Auditoría	Lee TRANSACTION_DOCUMENT_VIEWED y PAPELETA_GENERATED en el módulo de Auditoría.	auditoria L

Ojo con el permiso. Ver y descargar los soportes no va con transacciones:read sino con transacciones:write (backend/routes/api.php:61-69). No es un descuido: desde E2, el rol Backoffice tiene la lectura general de transacciones apagada a propósito —opera solo por la pantalla Pago— así que exigirle read le habría cerrado la puerta a sus propios documentos.

0.6 Glosario del dominio

Término	Qué es
Carta	El documento que Soterex le envía al beneficiario avisándole que tiene un giro para cobrar. Trae el MTCN, el PIN de pago y el plazo de retiro. Es el primer soporte que se escanea.
MTCN	Money Transfer Control Number. El número de control de la transacción. Lo genera la app al recibir la nota de Soterex y se lo responde; Soterex lo imprime en la carta.
PIN de pago	Es el mismo MTCN, impreso en la carta sin el prefijo C-. La app no lo pide: ver §1.2.
Soporte (o documento)	Cada archivo escaneado o fotografiado que respalda el pago. Nueve tipos posibles, PDF/JPG/PNG, hasta 10 MB.
Papeleta	El comprobante que se imprime al pagar, firman el cliente y el operador, y vuelve escaneada como soporte.
Formulario de enrolamiento	Alta del beneficiario para giros no presenciales. Solo aplica a pagos por transferencia bancaria. Hoy se sube escaneado.
Cartola bancaria	El extracto de cuenta que prueba la titularidad del beneficiario. Solo con transferencia.
Medio de pago (delivery_type)	EFECTIVO o TRANSFERENCIA. Determina qué documentos son obligatorios. Columna AA del reporte.
Documentación completa	Booleano derivado, no almacenado: si están todos los tipos obligatorios para el medio de pago de esa transacción.
Pagada pero incompleta	Transacción PAID cuya documentación no está completa. No es un estado — es la conjunción de dos hechos. Ver §2.4.
Reporte regulatorio	El informe de 36 columnas que CIS le presenta al regulador. Todavía no existe; E5a le deja los datos que le faltaban.

0.7 Cómo sigue

El flujo del pago reconstruye la ventanilla paso a paso, tal como la describió el cliente en la hoja Módulo caja, y explica las dos decisiones que más definen el módulo: qué es realmente el PIN (y por qué no se pide), y por qué el pago no se frena aunque falte documentación.

---

Análisis Funcional: Pago con documentos — parte 1 de 5. Índice · Siguiente: El flujo del pago →