Soterex — CIS Latam

Appearance

Preguntas Abiertas (a resolver antes de aprobar el PRD) ​

Análisis Funcional: Integración Soterex — parte 7 de 8. ← Secuencias de Pantalla · Índice · Siguiente: Señales de Handoff →

  1. Campos faltantes en SendRequest — 📌 QUEDA PENDIENTE (no bloqueante, a definir más adelante): el Excel actual incluye "fecha de nacimiento" y "número de registro de extranjero" que no están en el spec del PDF (SendRequest v1.4). El cliente decidió (2026-07-24) dejarlo pendiente de averiguar y no bloquear el avance del análisis por esto. Queda anotado para retomar antes de cerrar el PRD o, a más tardar, antes de que backend-dev defina el modelo de datos de la transacción.

  2. Contradicción push vs. cron/pull — ✅ RESUELTO (2026-07-24): confirmado por el cliente que la WebApp llama a SendRequest desde un cron cada 30 minutos (modelo pull, no webhook-push de Soterex). Queda actualizada en User Flows y Diagramas de Actividad.

    2b. Sigue abierta (⚠️ bloqueante para el architect): si la WebApp es quien llama a tokenC2P, SendRequest y Cancel hacia Soterex, y Notifications es el único canal WebApp → Soterex confirmado, ¿cómo llega a la WebApp una cancelación iniciada por Soterex? Opciones a confirmar con el cliente: (a) el mismo cron de 30 min que trae transacciones nuevas también trae cancelaciones marcadas por Soterex en esa respuesta, (b) existe un endpoint adicional no documentado en este PDF para consultar cancelaciones, o (c) en la práctica Soterex nunca cancela por su cuenta y la bidireccionalidad es solo conceptual (a validar).

  3. Regla de comisión — ✅ RESUELTO (2026-07-24): la comisión es editable por país, se configura en ABM Países.⛔ RESPUESTA INVALIDADA (2026-07-31, ver ADR-005): la comisión no es editable por CIS. La calcula y la devuelve Soterex, granular por transacción (fee en la respuesta de SendRequest) — no viaja en el request, CIS no puede fijarla. El campo commission_pct de ABM Países se eliminó: nunca reflejó la realidad (convivía desconectado del fee real desde el día 1). Además la comisión es información restringida desde el 2026-07-25 (ver §2.5 de Roles y Permisos). Precisión (2026-08-05, ADR-007): la comisión descuenta solo del Prefondeo Holding. Ni el prefondeo del país ni la caja la ven — se liquida a fin de mes entre la Holding y Soterex.

  4. Alcance del saldo de prefondeo — ✅ RESUELTO (2026-07-24): es un pool único por país.⛔ RESPUESTA SUPERADA (2026-08-05, ver ADR-007): el contrato nuevo mete a la Holding entre Soterex y el país, así que el prefondeo pasa a tener tres capas: Holding (global, descuenta principal + comisión), País (por país, solo principales, admite saldo negativo) y Caja operativa (por caja de PDV). El pool "único por país" que respondía esta pregunta es, en el modelo nuevo, el de la Holding. El reporting desagregado por PDV que menciona la pregunta #11 no cambia.

  5. Quién puede cambiar estado a PAID y quién puede cancelar — ✅ RESUELTO (2026-07-24): confirmado que es editable, gobernado por la matriz de Roles y Permisos configurable (ver Matriz de Roles y Permisos). No es una regla fija de negocio. Queda el seed inicial documentado en la tabla 2.1 (con ⚠️ porque el seed exacto por defecto aún no fue confirmado, pero eso ya no bloquea el análisis — es solo un valor de configuración inicial).

    5b. Sigue abierta (menor): si la dependencia adicional Escribir requiere Leer (sugerida por el Product Owner) debe aplicarse igual que Borrar→Escribir. No bloqueante.

  6. Formato de reportes contables — ✅ RESUELTO (2026-07-24): debe ser un formato estándar que refleje todos los tipos de movimiento (transacciones y asientos de prefondeo) con un resumen de cada request. (Sigue pendiente, no bloqueante: si necesita exportación a Excel/PDF — a confirmar con ui-engineer/backend-dev en la siguiente etapa.)

  7. Datos de la entidad Estación/PDV — ✅ RESUELTO (2026-07-24): el identificador es el código interno de sucursal. Además de los campos habituales (nombre, país, dirección, responsable), se agrega mail de notificaciones, con soporte para más de un mail por estación, y las notificaciones deben ser editables (se puede configurar cuáles eventos disparan mail a cuáles direcciones).

  8. Timeout de sesión — ✅ RESUELTO (2026-07-24): modelo de 3 niveles — valor global por defecto, con posibilidad de override por rol y override por usuario (el más específico prevalece).

  9. Alcance de SSO — ✅ RESUELTO (2026-07-24): el cliente hoy usa Microsoft 365 con dominio propio, pero para el MVP1 el login es solo usuario/contraseña (usuario = mail). SSO Google y SSO Microsoft/O365 quedan confirmados para una fase posterior, no MVP1.

  10. Acceso a logs de auditoría — ✅ RESUELTO (2026-07-24): acceso para Supervisor y Admin (no exclusivo de Admin).

  11. Definición de indicadores del dashboard — ✅ RESUELTO (2026-07-24): cantidad de transacciones pagadas con filtro de rango de fechas, por PDV y por país; comparativa entre países; comparativa de un PDV contra varios PDVs; ranking de PDVs; totalizadores por país. (Reemplaza a la idea original de "velocity" — no se pidió tiempo promedio a PAID/CANCELLED, sino estos indicadores de volumen y comparación.)

  12. Idempotencia de SendRequest — ✅ RESUELTO (2026-07-24): el cliente confirmó que la validación nativa de la API (error 2001 "Duplicate transaction number") es suficiente, no se necesita lógica adicional en la webapp.

  13. Aislamiento multi-país — ✅ RESUELTO (2026-07-24): los usuarios pueden ser multipaís — un mismo usuario puede tener rol Admin en un país y Supervisor o Backoffice/PDV en otro. Un Supervisor puede estar a cargo de más de un PDV. Todo esto debe ser editable desde ABM Asignación de Roles Multipaís/PDV (ver Matriz de Roles y Permisos).

13b. Nueva pregunta derivada (⚠️ abierta, menor): ¿un Supervisor puede estar a cargo de PDVs de más de un país a la vez, o sus PDVs asignados siempre pertenecen al mismo país en el que tiene el rol Supervisor? Se asumió esto último por simplicidad, a confirmar.

  1. Qué PDV se graba si el usuario tiene más de uno asignado (o ninguno, ej. Admin) — ✅ RESUELTO PARCIALMENTE (2026-07-25): opción (a) implementada — "PDV activo" explícito (role_assignments.default_station_id), configurable por asignación, con prioridad sobre el PDV único del alcance. No cambia qué puede leer el usuario (Admin sigue viendo todo el país), solo qué PDV se graba al resolver. Confirmado con Admin: quedó configurado en GT-CAP-001 (Ciudad de Guatemala — Central) a pedido del cliente, tras detectar en uso real que pagar como Admin dejaba la transacción sin PDV asignado. Sigue abierto (menor, no bloqueante): Backoffice/Supervisor con 2+ PDVs y sin PDV activo configurado todavía caen en null al resolver — el mecanismo ya existe, falta decidir si se les configura un default también o se les pide elegir al resolver.

    Nota (2026-07-27): una sesión distinta había reescrito este punto como si siguiera abierto, sin el mecanismo ya implementado — restaurado acá; el contenido de esa reescritura (Backoffice con 2+ PDVs sin default) ya estaba cubierto por el "Sigue abierto" de arriba, no era una pregunta nueva.

Resumen — solo quedan bloqueantes reales para el PRD: ​

  • #2b (mecanismo de cancelación iniciada por Soterex) — bloqueante para el architect.
  • #13b (alcance país de los PDVs de un Supervisor) — menor, no bloqueante.
  • #1, #5b, #6 (exportación) — quedan como pendientes menores, no bloqueantes, a resolver en paralelo con el PRD.

← Secuencias de Pantalla · Índice · Siguiente: Señales de Handoff →

Documentación viva — se actualiza junto con el código, no es un anexo aparte.

CIS Latam × Soterex