Plataforma de Star Cargo Service | Trámites y expedientes

Contexto

Star Cargo Service mueve carga marítima, aérea y terrestre entre seis países de Centroamérica. Su sitio es el primer punto de contacto comercial. Por ahí entra un importador a pedir una cotización, a consultar los corredores de consolidación o a localizar la oficina que le corresponde.

El encargo fue un cambio de marca y una plataforma nueva, no un retoque del sitio anterior. La empresa vende en mercados que no comparten idioma. Además necesitaba que lo enviado por el sitio terminara en un expediente que el cliente pudiera seguir, y no en un correo.

Problema

En el sitio anterior, los trámites estaban en un desplegable sin página propia y no aparecían en el pie. Tres de ellos no tenían ningún otro enlace. Un importador que llegaba desde un buscador no encontraba cómo pedir una cotización.

Su portal devolvía 404 en producción. Una solicitud enviada no se podía consultar después, ni por el cliente ni por el equipo, así que el seguimiento volvía al correo y al teléfono.

El idioma era el otro límite. Buena parte de los embarques viene de mercados que no hablan español, y el sitio solo atendía bien a uno de ellos.

Decisiones técnicas

El sitio anterior funcionaba, así que la opción inmediata era editar sobre él y heredar su build, sus dependencias y sus decisiones previas. El resultado habría sido el mismo sitio con otra capa de estilos.

Desde el primer día se abrió un proyecto separado, con build y dependencias propios y sin configuración compartida. Se fijó una fecha a partir de la cual el proyecto nuevo dejó de recibir código del sitio anterior.

El backend empezó como una copia y hoy es código de este proyecto, que solo se edita aquí. Sin esa fecha habrían quedado dos proyectos fusionados a medias y ninguna fuente de referencia.

Los permisos no se guardan en este proyecto. Se resuelven contra el ERP en cada petición, porque copiarlos aquí habría obligado a mantener una segunda copia sincronizada con el ERP.

Arquitectura

El sitio público sirve los cuatro idiomas con la misma estructura y el mismo contenido. Cada sección declara un tono visual, y los componentes leen las variables vigentes en el punto donde se dibujan. Así, el mismo botón sirve en una sección clara y en una oscura, sin condicionales.

Los ocho trámites del sitio se envían al ERP y quedan en un portal con sesión. El portal tiene catorce pantallas para dos audiencias. Seis son para el cliente, que sigue sus solicitudes y abre sus adjuntos. Las otras ocho son para el equipo, que recibe las solicitudes clasificadas por tipo junto a los clientes, las incidencias y las candidaturas.

El menú no está escrito a mano. Cada entrada se filtra por audiencia y por permiso, así que una opción sin permiso no se dibuja. Una cuenta sin permisos entra y no ve nada.

Los adjuntos se abren dentro del control de acceso: se comprueba el token contra el expediente, el solicitante contra su propiedad y el documento contra su carpeta. El cliente abre los suyos sin salir a un almacenamiento externo.

Resultado

El sitio está en producción en español, inglés, chino e hindi. Los clientes siguen sus solicitudes en el portal, sin llamar ni escribir para preguntar en qué estado están.

Los empleados entran con Google, y la comprobación se hace sobre el dominio firmado del token, no sobre el texto del correo. Los clientes entran por invitación de un empleado.

El conjunto de comprobaciones se define una vez y se ejecuta en dos momentos: al fusionar un cambio y al desplegar. Comprueba:

• los tipos y las pruebas;
• un tope de advertencias que no puede subir sin una justificación en el commit;
• que los cuatro idiomas tengan exactamente las mismas claves de traducción;
• que la política de seguridad de contenido siga activa.

El despliegue termina con una prueba de humo contra el sitio publicado.

Lo que aprendí

Heredar código del sitio anterior obligaba a aplicar cada mejora dos veces. Además, cualquier diferencia entre los dos parecía un error de sincronización y no una decisión.

La fecha de corte quitó esa ambigüedad, porque desde ese día el sitio anterior es una referencia y no una fuente de cambios. En una migración conviene fijar esa fecha al principio, antes de que existan dos versiones de la misma corrección que reconciliar.