Informe de avance — Integración Soterex
Para: Magui · Diego Sánchez · Teresa Ortiz (CIS-EC) De: Carlos San Martín (CIS-AR) Fecha: 2026-08-07 Alcance: respuesta a los pedidos de la revisión del 5 de agosto y del mail de Magui del 7 de agosto.
Resumen
Se implementaron todos los cambios que salieron de la revisión del módulo de caja, y la mayor parte de lo que llegó en el mail con los tres adjuntos. Quedan tres definiciones de ustedes y dos puntos donde tomamos un camino distinto al del material enviado — los dos están explicados abajo, con el motivo, para que puedan confirmarlos o corregirnos.
En el medio se detectaron y corrigieron cuatro errores propios que afectaban plata o accesos, y que conviene que conozcan porque cambian lo que el sistema hacía hasta ahora.
1. Lo pedido por Diego en la revisión del 5 de agosto
Los siete puntos están implementados y probados.
| Lo que pediste | Estado |
|---|---|
| El prefondeo en tres capas — Holding, País y Caja, con la Holding quedándose la comisión | ✅ Implementado |
| Que el pago consulte solo la caja operativa — "que me consulte en la caja operativa y listo" | ✅ Implementado. Si el país está en cero porque la transferencia está en trámite, el pago se hace igual |
| Que el saldo del país pueda quedar negativo | ✅ Se muestra en rojo, con la aclaración de que es la deuda pendiente y no un error |
| Sacar la autorización del Supervisor para abrir y cerrar caja | ✅ La apertura la hace el operador con su propia sesión |
| Que el saldo inicial se herede del cierre anterior, automático y no editable | ✅ La pantalla muestra el saldo heredado y explica que las diferencias van por ajuste |
| Motivos de fondeo y ajuste en lista cerrada | ✅ Fondeo: Fondeo inicial, Blindado, Transferencia financiero, Otro. Ajuste: Faltante de arqueo, Sobrante de arqueo, Otro. Solo "Otro" habilita descripción libre |
| Que fondear de más avise pero no bloquee — "una alerta más que un validador" | ✅ El fondeo se registra igual y aparece un aviso persistente |
Además, el desglose que pediste sin pedirlo
En la reunión repetiste tres veces la misma idea — "ahora tengo 80 en el banco y 20.000 en cajas" — y Teresa llegó a la misma pregunta por separado. La pantalla de Prefondeo País ahora muestra tres cifras, no una:
Saldo del país 100.000,00 USD
├─ Distribuido en cajas 20.000,00 USD
└─ Disponible para distribuir 80.000,00 USDSin eso, el saldo del país no respondía la única pregunta que importa al momento de repartir.
2. Lo pedido por Teresa
| Lo que definiste | Estado |
|---|---|
| Guatemala paga en dólares — no hay autorización para cambio de divisa | ✅ La moneda de pago es configurable por país. Con Guatemala en dólares, el sistema ya no exige tener un tipo de cambio cargado |
| El cambio de moneda queda para un MVP2 | ✅ El módulo de tipo de cambio queda construido y sin usar. El día que llegue la autorización se activa con un switch, sin migrar nada |
| CIS EC administra la caja de CIS GT | ✅ Contemplado en el modelo de permisos |
Una precisión sobre el punto de la moneda: el sistema guarda en qué moneda se registró cada movimiento. Eso significa que cuando Guatemala pase a operar en quetzales, el histórico en dólares no se reinterpreta ni se mezcla en el saldo. Era la opción más cara de las tres que evaluamos y se eligió por eso.
3. Lo pedido por Magui en el mail del 7 de agosto
Requerimiento 1 — Columnas del reporte al regulador
⏳ Analizado, no implementado todavía. Se relevaron las 48 columnas del reporte y las 36 que se quedan, con su origen. De esas, catorce las carga CIS en ventanilla y no existían en el sistema: dirección, ciudad, provincia, tipo y número de identificación, país de la identificación, teléfono y mail adicionales, medio de pago, cuenta bancaria y notas.
✅ Esos catorce campos ya se pueden cargar desde la pantalla de pago — que era el pedido concreto de "si Soterex no envía la columna por la API, incluir los campos en la pestaña del pago".
Lo que falta es el reporte en sí, exportable a Excel. Es la próxima entrega grande.
Requerimiento 2 — Tabla de comisiones por país
⚠️ No implementado, a propósito. Ver el punto 5 de este informe: creemos que hay una diferencia de criterio que conviene resolver antes de construirlo.
Requerimiento 3 — Especificación del módulo de caja
✅ Recibida e implementada, con las salvedades del punto 5.
Requerimiento 4 — Formato de la papeleta
✅ Implementada sobre el modelo Word que enviaron, en ticket de 58 mm para impresora térmica de mostrador. Se respetaron el orden, los rótulos y el texto legal exactos del modelo.
Se genera al momento del pago y es reimprimible: volver a pedirla dentro de un mes devuelve exactamente el mismo comprobante, con la fecha del pago y no la de impresión.
Dos cosas del modelo quedaron sin resolver, y las dejamos afuera antes que inventarlas:
- "TRANSACCIÓN FIJA: SI / NO" — no aparece en el reporte, ni en las hojas de tesorería, ni en el análisis funcional. No sabemos qué representa.
- El teléfono de servicio al cliente figura como
XXXXXXXXXXX. Hoy se imprime un guión, porque una cadena de equis en un comprobante real parecería un error.
Requerimiento 5 — Flujo de los documentos del pago
✅ Implementado. Se guardan los nueve tipos que definieron:
| Pago en efectivo | Se suman con transferencia bancaria |
|---|---|
| Carta de Soterex | Formulario de enrolamiento |
| Identificación (anverso y reverso) | Cartola bancaria |
| Foto del cliente con la identificación — opcional | Solicitud de pago por transferencia |
| Papeleta firmada | Confirmación de acreditación |
Se aceptan fotos, escaneos o PDF, como pidieron.
El pago no se bloquea si faltan soportes. La transacción queda pagada y marcada como incompleta, y los documentos se pueden completar después desde su ficha. Fue una decisión deliberada: la plata ya se entregó en el mostrador, y frenar el registro por un escaneo faltante dejaría la caja descuadrada contra la realidad física.
El formulario de enrolamiento se sube escaneado, no lo emite el sistema. Evaluamos generarlo —como sugería el mail— pero el modelo pide género y estado civil, que no existen en el sistema ni vienen en el reporte. Si les interesa que se emita, hay que definir de dónde salen esos dos datos.
4. Cambios que hicimos y conviene que conozcan
Al revisar el material apareció algo que no estaba modelado y que cambia la operación en ventanilla.
El PIN de la carta: por qué el sistema no lo pide
La carta al beneficiario dice: "En la ventanilla, proporcione el PIN de Pago. Este código es necesario para entregar los fondos". Al leerlo, lo tomamos como un dato de seguridad aparte que nos faltaba modelar.
No lo es: el PIN de Pago es el mismo número de transacción, impreso dos veces en la carta —una con el prefijo C- y otra sin él. El número lo genera nuestro sistema y se lo informa a Soterex, que lo imprime.
Llegamos a implementar una verificación —el operador tipeaba el PIN y el pago no se habilitaba hasta que coincidiera— y la sacamos al probarla. Siendo el mismo número, cuando el operador busca por número de transacción la pantalla le pedía volver a escribir lo que acababa de escribir. Un paso que no verificaba nada.
Si en la operación real aparece el caso de dos beneficiarios con nombres parecidos, se puede reponer de una forma que sí aporte: pedirlo sólo cuando el operador llegó por búsqueda de nombre, que es el único camino donde no vio el número antes. Díganos si les pasa.
El buscador cambió bastante
A pedido de la operación:
- Busca por parte del nombre o del apellido, no hace falta el nombre completo.
- El número de transacción se encuentra sin los ceros de la izquierda:
26encuentra a0000000026. - Muestra hasta 15 coincidencias en una lista para elegir.
- Alcanza todas las transacciones del país, incluidas las que pagó otro operador — necesario para poder "corroborar soportes del pago", como pide la especificación del módulo de caja.
Nota de seguridad. Los dos últimos cambios amplían lo que un operador puede consultar del padrón de beneficiarios de su país. Se mantienen el límite de consultas por minuto y el registro de auditoría de cada búsqueda, incluidas las que no devuelven nada. Lo dejamos marcado como el primer punto a revisar en la auditoría de seguridad, antes de salir a producción.
Cuatro errores propios corregidos
Aparecieron al escribir la documentación funcional y al probar en pantalla. Los enumeramos porque tres afectaban plata o accesos:
- Permisos de caja que no acotaban por sucursal. Un operador asignado a una sucursal podía operar la caja de otra —abrir, cerrar, fondear, ajustar— si conocía su identificador. No aparecía en pantalla, pero el sistema lo permitía.
- Pagos entre países. Un usuario con acceso a dos países podía pagar una transacción de uno descontando la caja del otro, y al tipo de cambio del otro.
- Historial de caja truncado en silencio. Con más de 25 movimientos, la pantalla mostraba solo los primeros sin ningún aviso de que había más.
- Dos operaciones simultáneas de la misma persona podían dejar indefinido de qué caja salía la plata.
5. Dos puntos donde tomamos un camino distinto al del material
Los planteamos abiertamente porque no los resolvimos por nuestra cuenta: en los dos casos hay información contradictoria entre lo que se definió en la reunión y lo que muestran las planillas.
5.1 El saldo del país cuando se reparte plata a las cajas
En las planillas, mandar 5.000 de CIS Guatemala a un PDV baja el saldo del país de 25.000 a 20.000.
En el sistema el saldo del país no baja: mover plata a una caja se trata como distribución, no como gasto. El país solo baja cuando se paga una transacción. Es lo que se definió en la reunión del 5 de agosto.
Los dos criterios son correctos, pero dan números distintos y alguien los va a comparar. Con el nuestro, el saldo es el total contable; con el de las planillas, es lo que queda en el banco. Por eso agregamos el desglose de tres cifras: para que las dos lecturas estén a la vista.
Necesitamos que confirmen cuál rige.
5.2 Quién calcula la comisión
El requerimiento 2 pide una tabla de comisiones por tramos, editable, para calcular lo que Soterex le paga a CIS.
El sistema toma la comisión de lo que devuelve Soterex en cada transacción, y CIS no la edita. Fue una decisión de julio, basada en que la especificación de la API muestra ese valor como un dato que Soterex calcula y envía.
Si el valor que manda Soterex es el bueno, la tabla no tiene consumidor. Si no lo es, hay que construir el motor de comisiones — y para eso hace falta la tabla real, que no vino en los adjuntos.
Necesitamos que confirmen cuál de las dos cosas es.
6. Lo que esperamos de ustedes
| # | Qué | Quién |
|---|---|---|
| 1 | El modelo del saldo del país (punto 5.1) | Teresa / Diego |
| 2 | Quién calcula la comisión, y la tabla de tramos si corresponde (punto 5.2) | Magui / Teresa |
| 3 | Qué representa "TRANSACCIÓN FIJA" en la papeleta | Magui |
| 4 | El teléfono de servicio al cliente para la papeleta | Magui |
| 5 | Si existe la figura de pago con transferencia bancaria o se deja solo efectivo | Teresa |
| 6 | Con qué escenario de tesorería se arranca (1 o 2) | Teresa |
| 7 | Si Soterex va a informar el prefondeo por la API o se carga a mano | Soterex |
7. Qué sigue de nuestro lado
- Reporte al regulador — las 36 columnas, exportable a Excel. Es el compromiso más concreto que queda abierto.
- Alertas de reposición al 30% del saldo prefondeado, con el porcentaje configurable, en cada nivel.
- Pruebas funcionales completas con ustedes, antes de habilitar el ambiente de prueba.
- Auditoría de seguridad, con foco en el manejo de los documentos de identidad y en el alcance del buscador.
- Conexión real con Soterex — sigue pendiente la reunión técnica y las credenciales del ambiente de prueba de ellos. Además queda sin resolver cómo llega al sistema una cancelación iniciada por Soterex, que es la única pieza del circuito que todavía no tiene respuesta.
Sobre el ambiente de prueba: la infraestructura está definida pero todavía no está creada. Vamos a coordinar esa puesta en marcha por separado.
Cualquier punto que necesiten ampliar, lo vemos en una llamada.