Reporte de Incidencias de Comercio Exterior Documento de definición técnica · Versión 1.0 · Agosto 2026
| Campo | Valor |
|---|---|
| Nombre | RICE — Reporte de Incidencias de Comercio Exterior |
| Naturaleza | Plataforma de captura estructurada, seguimiento y análisis de incidencias aduaneras |
| Canales | Navegador web y aplicación Android |
| Modos de operación | Importación y Exportación, con formularios, catálogos e indicadores separados |
El sistema no tiene un usuario único. Distingue cuatro perfiles en el modelo de datos, cada uno con alcance distinto:
| Perfil | Quién es | Qué hace en el sistema | Frecuencia esperada |
|---|---|---|---|
| Empresa | Representante o administrador de una entidad con NIT registrado | Reporta incidencias, emite códigos de vinculación para su personal, consulta el histórico de su empresa | Por evento |
| Empleado | Persona vinculada a una empresa mediante código | Reporta y da seguimiento a incidencias en nombre de la empresa a la que está vinculado | Por evento |
| Operador de comercio exterior | Importador, exportador, productor, distribuidor, agente aduanero, gestor aduanal o transportista | Reporta incidencias a título propio y consulta antecedentes públicos | Variable |
| Administrador | Personal institucional | Administra catálogos (entidades, sub-entidades, tipos de problema), consulta indicadores agregados | Diaria |
RICE convierte el reporte de una incidencia de comercio exterior, hoy disperso en correo, llamada telefónica y trámite presencial, en un registro estructurado, trazable y agregable.
Se diferencia de un buzón de quejas por su modelo de captura: los campos que deben compararse entre casos se toman de catálogo cerrado (entidad interviniente, aduana, país de origen, país de procedencia o destino, capítulo y fracción del Sistema Arancelario Centroamericano, condición de perecedero, frecuencia), y solo lo que describe el hecho particular queda en texto libre (problema, descripción técnica, solución aplicada).
Cada caso queda además amarrado al documento aduanero que lo origina, número correlativo en importación, número de póliza en exportación, lo que, potencialmente, permitiría cruzarlo con los sistemas existentes de la autoridad.
Reportar incidencias que afectan operaciones de importación y exportación, hacia la autoridad competente, en un formato que permita analizarlas.
| # | Objetivo | Verificable por |
|---|---|---|
| 1 | Capturar cada incidencia con clasificación arancelaria, entidad interviniente y aduana tomadas de catálogo | Proporción de campos de catálogo sobre campos libres en el formulario |
| 2 | Mantener la conversación sobre un caso dentro del expediente entre usuarios, no en canales dispersos | Casos con al menos un comentario registrado / casos totales |
| 3 | Convertir casos resueltos en antecedente consultable por otros usuarios | Casos con solución registrada y marcada como pública |
| 4 | Separar el análisis de importación y exportación sin mezclar sus dimensiones | Existencia de catálogos e indicadores independientes por modo |
| 5 | Producir indicadores agregados por periodo sin trabajo manual de normalización | Cruces disponibles en el módulo de indicadores |
Diagrama ancla del sistema. Todo lo demás es un acercamiento a una de estas seis etapas.
Dato que deja cada etapa:
| Etapa | Dato aprovechable |
|---|---|
| Reportar | Fecha del problema, empresa (NIT), documento aduanero, costo adicional, frecuencia |
| Clasificar | Entidad y sub-entidad, aduana, país de origen y de procedencia/destino, capítulo y fracción SAC, perecedero |
| Notificar | Momento en que la parte responsable toma conocimiento |
| Conversar | Historia de la gestión, atribuible y fechada |
| Resolver | Solución aplicada y si queda visible como antecedente |
| Consultar | Uso efectivo del acervo: qué se busca y con qué frecuencia |
| Capa | Implementación actual |
|---|---|
| Cliente | Angular 21 + Ionic 8, renderizado en servidor; empaquetado nativo con Capacitor 8 (Android e iOS) |
| Identidad | Proveedor gestionado con verificación por correo y rol embebido como claim en el token — la autorización no requiere consulta adicional a base de datos |
| API | REST sobre funciones gestionadas, región us-central1 |
| Modelo de datos | Relacional. Las interfaces del cliente exponen claves foráneas numéricas y relaciones nombradas (entityId, SACChapterId, entryCustomId, Incident ↔ IncidentComment), patrón propio de un ORM relacional, no documental |
| Tiempo real | Un documento por incidencia en base documental, usado solo como señal de actualización del hilo de comentarios |
| Push | Servicio multiplataforma de terceros |
| Gráficas | Biblioteca de visualización en el cliente; agregación calculada en el servidor |
| Hosting | Alojamiento estático con reescritura a index.html |
| Componente | Acoplamiento | Sustitución |
|---|---|---|
| Base relacional | Bajo | Volcado y restauración estándar. Sin cambio de código si se mantiene el motor |
| API sobre funciones | Bajo | Reempaquetado del handler. La lógica de negocio no cambia |
| Alojamiento estático | Nulo | Archivos estáticos. Cualquier CDN sirve |
| Identidad | Alto | Cambia el SDK del cliente y la emisión de claims. Migración de credenciales requiere plan (los hashes no siempre son exportables) |
| Tiempo real | Medio | Sustituible por WebSocket gestionado o por sondeo. Uso actual es marginal (una señal por caso), lo que abarata el cambio |
| Push | Nulo | Ya es un tercero independiente de la nube |
publicSolution) e identidad del reportante (publicUser).Cruces disponibles, cada uno con gráfica y tabla de conteo, acotables a mes o año:
| Modo importación | Modo exportación |
|---|---|
| Resumen del periodo | Resumen del periodo |
| País de procedencia | País de destino |
| País de origen | País de origen |
| Tipo de problema (por entidad) | Tipo de problema (texto) |
| Aduana de ingreso | Aduana de salida |
| Capítulo SAC | Capítulo SAC |
| Mercancía perecedera | Mercancía perecedera |
| Entidad interviniente | — |
| Frecuencia de repetición | Frecuencia de repetición |
| Casos con solución registrada | Casos con solución registrada |
Separar la operación del análisis. Son dos cargas de trabajo con requisitos opuestos:
| Operación (OLTP) | Análisis (OLAP) | |
|---|---|---|
| Patrón de acceso | Muchas escrituras pequeñas, lecturas por clave | Pocas consultas, lecturas masivas por columna |
| Latencia exigida | Milisegundos | Segundos |
| Volumen consultado | Un caso | Todo el histórico |
| Optimización | Filas, índices | Columnas, compresión |
Forzar ambas sobre el mismo motor degrada las dos: los reportes bloquean la operación, y los índices que sirven a la operación no sirven al reporte.
Por qué este patrón y no un almacén analítico dedicado:
Un almacén analítico clásico (motor columnar aprovisionado) cobra por capacidad reservada, esté o no en uso. En un sistema donde los indicadores se consultan por evento, no continuamente, eso significa pagar 720 horas al mes por un recurso usado quizá 5.
El patrón de archivos columnares en almacenamiento de objetos + motor de consulta sin servidor invierte la ecuación: el costo en reposo es únicamente el almacenamiento (céntimos por gigabyte-mes), y el cómputo se cobra por consulta ejecutada. Con el volumen esperado de una plataforma de incidencias aduaneras nacionales, el histórico completo cabe holgadamente en el rango de unidades de gigabytes.
Este patrón existe en los tres proveedores mayores con nombres distintos. La arquitectura no cambia; cambia el nombre del servicio.
Especificación neutral. Sirve para evaluar cualquier oferta:
| # | Capacidad requerida | Criterio de aceptación |
|---|---|---|
| C-1 | Base relacional gestionada | Respaldo automático, recuperación a punto en el tiempo, cifrado en reposo. Escalable verticalmente sin migración |
| C-2 | Cómputo sin servidor para el API | Sin costo en ausencia de tráfico. Arranque en frío bajo 2 s |
| C-3 | Identidad gestionada | Verificación por correo, recuperación de contraseña, atributos personalizados en el token (rol), y exportación de usuarios |
| C-4 | Almacenamiento de objetos con clases de acceso | Transición automática a clase de archivo para datos con más de 24 meses |
| C-5 | Catálogo de metadatos y motor SQL sin servidor | Consulta directa sobre formato columnar abierto. Cobro por volumen escaneado o por consulta, no por capacidad reservada |
| C-6 | Orquestación de carga programada | Ejecución diaria. Reintento ante fallo. Alerta a operador |
| C-7 | Distribución de contenido | Certificado gestionado, caché por huella de archivo |
| C-8 | Notificación push | Android e iOS desde un mismo envío |
| C-9 | Registro y auditoría | Retención mínima de 12 meses de accesos y cambios |
| C-10 | Residencia y salida de datos | Formatos abiertos y estándar. Sin cargo prohibitivo por retirar los datos |
Ordenadas por impacto:
Qué cobra por estar encendido y qué cobra por usarse:
| Componente | En reposo | Con uso |
|---|---|---|
| Almacenamiento de objetos | Bajo, proporcional a GB | Despreciable |
| Base relacional gestionada | Fijo — es la única partida fija relevante | Marginal |
| Cómputo del API | Nulo | Por invocación y duración |
| Motor de consulta analítica | Nulo | Por volumen escaneado |
| Catálogo de metadatos | Bajo o nulo | Por rastreo |
| Distribución de contenido | Nulo | Por transferencia |
| Identidad | Nulo o por usuario activo | Por usuario activo |
Conclusión de costo: con este diseño, la base relacional es la única partida con costo fijo mensual significativo. Todo lo demás tiende a cero sin uso. Si esa partida resulta inaceptable, existen motores relacionales que escalan a cero, a cambio de latencia de arranque en frío — es una decisión a tomar con datos de uso reales, no de antemano.
La incidencia de exportación es una entidad paralela con dimensiones propias (país de destino, aduana de salida).