Preguntas Abiertas — Pago con documentos
Análisis Funcional: Pago con documentos — parte 5 de 5. ← La papeleta · Índice
Lo que el cliente todavía no definió, más lo que se resolvió por criterio del equipo y nunca se validó. Mismo formato que las Preguntas Abiertas del Módulo Caja y las del análisis original: numeradas, con estado y fecha, y sin redondear como cerrado nada que no lo esté.
Estados: ✅ RESUELTO · ⚠️ ABIERTA · 📌 PENDIENTE NO BLOQUEANTE
4.1 Abiertas
1. ¿Qué es "TRANSACCIÓN FIJA: SI / NO"? — ⚠️ ABIERTA (2026-08-07). No bloqueante.
El modelo Word de la papeleta imprime, en la misma línea que la moneda y la tasa de cambio:
MONEDA A PAGAR: USD TASA CAMBIO: 1.00000000 TRANSACCIÓN FIJA: SI / NOLas dos opciones aparecen visibles, como si el operador debiera tachar una a mano o el sistema imprimir solo la que corresponde.
Nadie sabe qué significa. No hay ninguna otra mención en las tres hojas del Excel, no hay una columna equivalente entre las 48 del reporte, y no existe nada parecido en el modelo de datos ni en lo que manda Soterex por API.
La hipótesis más razonable —y es solo eso— es que marque si el monto en destino quedó fijado al momento de emitir el giro o si se convierte a la tasa del día de cobro. Encajaría con estar al lado de la tasa de cambio, y sería irrelevante hoy porque el cambio de moneda se difirió a MVP2. Pero también podría ser un concepto de tarifa, o un resabio de una plantilla vieja.
Se omitió de la papeleta antes que imprimir un rótulo cuyo significado nadie puede explicarle al cliente que la está firmando.
Qué hace falta: que CIS-EC diga qué es. Si es lo que suponemos, probablemente no vuelva hasta MVP2. No bloquea porque la papeleta ya cumple su función sin ese campo.
2. ¿Cuál es el teléfono de servicio al cliente? — ⚠️ ABIERTA (2026-08-07). No bloqueante.
Los dos modelos Word —la papeleta y el formulario de enrolamiento— cierran con la misma línea:
"Para contactarse con servicio al cliente llame gratis al: XXXXXXXXXXX"
El cliente mandó la plantilla sin completar el número. Once equis no son un formato: son un marcador.
Cómo está resuelto hoy: la app lo lee de la configuración (app.customer_service_phone) y, si está vacía, imprime un guión (backend/app/Services/PapeletaService.php:77). Es decir, la papeleta sale con una línea que dice "llame gratis al: —".
Qué hace falta: el número, y una definición sobre si es uno solo o uno por país. Guatemala y Ecuador operan mercados distintos; un 1-800 de Ecuador impreso en un ticket guatemalteco no sirve de nada. Hoy la configuración es global — si la respuesta es "por país", hay que moverla a la tabla de países.
No bloquea la entrega, pero sí bloquea imprimir papeletas de verdad en producción: un comprobante que el cliente firma no puede salir con un guión donde va un teléfono.
3. ¿Existe la figura de pago con transferencia bancaria? — ⚠️ ABIERTA (2026-08-07). Definición de Teresa.
Es la pregunta más grande del paquete, y viene arrastrada del análisis del material de CIS-EC (§3.4 y punto #3 de "lo que sigue sin definirse").
El material la describe con detalle: la hoja Módulo caja fila 12 pide "seleccionando el medio de pago correcto: efectivo, transferencia bancaria", la columna AA del reporte pide "un box para escoger el medio de pago", la fila 20 lista los cuatro documentos adicionales, y la columna AB pide los datos de cuenta bancaria. Pero el propio material deja la pregunta abierta: Teresa tiene que confirmar si la figura existe o si se deja solo efectivo.
Cómo está resuelto hoy: se implementó completa. delivery_type acepta EFECTIVO y TRANSFERENCIA, el selector está en el formulario, la cuenta bancaria aparece solo con transferencia, y los cuatro documentos extra entran en el cálculo de completitud.
Se implementó aunque esté sin confirmar porque el costo de tenerla y no usarla es una opción de más en un <select>. El costo de no tenerla y necesitarla es rehacer el modelo de completitud documental.
Qué falta además, si la respuesta es que sí: una segunda pregunta que el material no responde y que es de lógica de plata —
¿Un pago por transferencia bancaria descuenta la caja física?
Todo el Módulo Caja asume efectivo: cada pago descuenta la caja que abrió el operador. Si el dinero sale de una cuenta bancaria y no del cajón, no debería descontar nada de la caja — pero eso no está dicho en ningún lado, y hoy la app descuenta igual.
Es un descuadre latente: si mañana se paga una transferencia con el módulo Caja encendido, la caja va a reportar menos efectivo del que físicamente tiene. Esta parte sí bloquea el uso real de transferencias en Guatemala.
4. Los cuatro documentos de transferencia van "por una sola vez por cliente", pero no existe la entidad Cliente — ⚠️ ABIERTA (2026-08-07). No bloqueante.
El material es explícito en la fila 20 de la hoja Módulo caja:
"Pago con tx bancaria: a los documentos anteriores se suman los siguientes, por una sola vez" — formulario de enrolamiento, cartola de banco, solicitud de pago con transferencia, y mail de confirmación de acreditación.
"Por una sola vez" significa por cliente, no por transacción: un beneficiario que se enrola una vez no tiene que volver a presentar su formulario de enrolamiento ni su cartola bancaria en cada giro. Es lo razonable — son documentos de alta, no de operación.
El problema: el modelo de datos no tiene ninguna entidad que agrupe transacciones de la misma persona. Una transacción trae nombre, apellido, mail, teléfono y fecha de nacimiento como campos sueltos; no hay un Cliente con id propio al que colgarle documentos reutilizables.
Cómo está resuelto hoy: los cuatro se piden por transacción. Está anotado en el propio modelo:
// backend/app/Models/TransactionDocument.php:57-62
/**
* Se suman cuando el pago es por transferencia bancaria. El material
* aclara que van *"por una sola vez"* por cliente — pero como todavía no
* existe una entidad Cliente que los agrupe, por ahora se piden por
* transacción.
*/O sea que la app le va a pedir al operador que suba el mismo formulario de enrolamiento en cada giro del mismo beneficiario. Funciona, pero es trabajo repetido, y el operador lo va a notar antes que nosotros.
Qué hace falta: decidir si se crea una entidad Cliente —con la pregunta no trivial de cómo se identifica unívocamente a una persona entre transacciones: ¿por número de identificación? ¿por número más país emisor?— o si se acepta la duplicación. La decisión depende de cuánto volumen de clientes recurrentes con transferencia haya, que hoy nadie sabe porque la figura ni siquiera está confirmada (#3).
No bloquea: la completitud funciona igual, solo pide de más.
4.2 Pendientes no bloqueantes
5. El reporte regulatorio de 36 columnas todavía no existe — 📌 PENDIENTE (2026-08-07).
E5a agregó los campos para ese reporte, pero el reporte es una entrega propia que no está en ningún plan cerrado. El mapeo completo columna por columna vive en un adjunto del mail de Maggie (Soterex - Reporte completo.xlsx, hoja Request Pilot List) que no está en el repositorio por contener 2.957 transacciones reales con datos personales de personas migrantes.
Qué hace falta: traducir ese mapeo a un documento propio, sin datos personales, antes de implementarlo. Mientras tanto, hay un riesgo silencioso: nadie verificó columna por columna que los 13 campos que se agregaron cubran efectivamente todo lo que falta. Los que el análisis identificó y no se agregaron son Payer Name, Transaction Status - Update, Additional Notes y Paid at Branch City/State.
6. Género y estado civil: ¿se agregan al modelo? — 📌 PENDIENTE (2026-08-07).
El formulario de enrolamiento los pide. El reporte regulatorio no. Soterex no los manda.
La decisión depende enteramente de si el formulario se genera desde el sistema (como sugirió el cliente en la fila 21) o se sigue subiendo escaneado. Hoy se sube escaneado, así que los dos campos no hacen falta. Ver §3.8.
Qué hace falta: confirmar si CIS-EC quiere que la app emita el formulario. Si la respuesta es sí, se agregan los dos campos al formulario de datos del pago; si es no, no se agregan nunca.
7. La protección de los documentos es detectiva, no preventiva — 📌 PENDIENTE (2026-08-07). Para la auditoría de seguridad.
Lo implementado en §2.5 cubre lo esencial: sin URL directa, alcance por PDV, cada acceso auditado, sin borrado, path generado por el servidor. Es sólido para el flujo normal.
Lo que no cubre, y conviene que quede escrito antes de que la auditoría de seguridad lo encuentre:
- No hay política de retención ni expiración. Los documentos de identidad se guardan indefinidamente. Para datos de personas migrantes, "para siempre" es una decisión, no un default neutro.
- No hay cifrado a nivel aplicación sobre el contenido. Se confía en el cifrado at-rest de S3, que protege contra el robo del disco, no contra credenciales comprometidas.
- Cualquier operador con
transacciones:writeen su PDV puede descargar cualquier documento de ese PDV. La auditoría registra quién miró qué; no impide que mire. - La tabla de auditoría crece con cada preview. Abrir la ficha de una transacción y mirar sus cuatro soportes escribe cuatro registros. No es un problema hoy; a volumen puede serlo.
Qué hace falta: que esto entre explícitamente en el alcance de la auditoría de seguridad pendiente del plan, con una definición de retención acordada con CIS-EC.
8. Cambiar el medio de pago cambia la completitud retroactivamente — 📌 PENDIENTE (2026-08-07). Sin validar con el cliente.
Una transacción marcada como completa en efectivo pasa a incompleta apenas se cambia su delivery_type a transferencia, porque los cuatro documentos adicionales entran en juego (ver §2.3).
Es el comportamiento correcto —los documentos efectivamente hacen falta— pero nadie se lo validó al cliente, y en pantalla se ve como un badge que pasa de verde a naranja sin que el operador haya tocado ningún documento.
Qué hace falta: confirmar que se espera ese comportamiento, y evaluar si hace falta un aviso explícito al cambiar el medio de pago sobre una transacción ya pagada. Es un cambio de UX chico si la respuesta es sí.
4.3 Resueltas
9. ¿El PIN de pago es un dato separado del MTCN? — ✅ RESUELTO (2026-08-07): es el mismo dato.
El análisis del material había concluido que el "PIN Number" de la carta era un control de seguridad que no teníamos modelado, y el primer borrador del diseño técnico agregaba una columna pin a transactions.
Resolución (Carlos, 2026-08-07): no son dos datos. La app genera el MTCN y se lo responde a Soterex, que lo imprime en la carta del beneficiario, donde aparece dos veces — MTCN: C-5436014032 y Payment PIN: 5436014032. Se verifica contra el MTCN tolerando el prefijo C-, y no se agregó ninguna columna.
Consecuencia (revisada el 2026-08-10): se implementó una verificación y se sacó al probarla. Buscando por número de transacción —el camino habitual, porque el cliente llega con la carta— pedía retipear el número que se acababa de tipear. Sólo aportaba algo por el camino de búsqueda por nombre; si ese escenario aparece en la operación real, se puede reponer acotado a ese caso. El razonamiento completo está en §1.2.
10. ¿"Pagada pero incompleta" es un estado nuevo? — ✅ RESUELTO (2026-08-07): no, se deriva.
El cliente lo planteó como posibilidad a evaluar (hoja Módulo caja, fila 14).
Resolución: status no cambia. La completitud se deriva de los documentos que la transacción tiene contra los que su medio de pago exige, y se expone como documentacion_completa más la lista de faltantes. Las tres razones están en §2.4.
11. ¿El pago se bloquea si faltan documentos? — ✅ RESUELTO (2026-08-07): no.
Resolución: no se bloquea, ni por documentos ni por datos. La plata ya se entregó en el mostrador; frenar el registro no evita el problema, lo convierte en un descuadre de caja contra la realidad física. Ver §1.4.
Análisis Funcional: Pago con documentos — parte 5 de 5. ← La papeleta · Índice