Un agente de carga transfronterizo vive de un margen: vende un flete a su cliente, compra la capacidad a un transportista, y la diferencia es su negocio. Todo lo demás existe para proteger ese margen.
Cada carga acumula cargos en dos monedas, de tres orígenes distintos, con impuestos y retenciones que aplican de forma asimétrica según el tipo de cargo.
Y encima hay que emitir el comprobante fiscal correcto ante la autoridad mexicana, con el complemento obligatorio de transporte de mercancías — cuyos datos los tiene un tercero, el transportista, que unas veces manda un archivo estructurado y otras solo un PDF escaneado.
Si el margen no está bien calculado al centavo, la empresa no sabe si está ganando. Si el comprobante no está bien emitido, no puede cobrar.
Una plataforma completa de gestión de transporte y facturación electrónica, construida por entero a la medida y sin framework de terceros. No es un producto adaptado: cada regla del negocio está modelada como el negocio la vive. Es el sistema más grande y exigente que hemos construido.
Cada carga congela su propio tipo de cambio y cada cargo se acumula simultáneamente en las dos monedas. Los impuestos los calcula el motor de base de datos, así que ninguna ruta de la aplicación puede dejar el ingreso inconsistente.
Sube su evidencia de entrega y su propia factura, consulta su historial y —esto importa— ve exactamente por qué se le rechazó algo. El equipo de cuentas por pagar deja de ser un centro de llamadas.
Cualquier cambio de dinero sobre una carga ya facturada genera automáticamente un ticket con la foto financiera de antes y después, que alguien autorizado tiene que resolver. No hay forma de que un ajuste pase inadvertido.
Cada uno es un problema de negocio real que solo se resuelve con decisiones de ingeniería correctas.
El complemento obligatorio de transporte de mercancías se arma con datos que emite el transportista. A veces entrega el archivo estructurado; a veces, solo un PDF escaneado. Y la autoridad fiscal valida con literalidad absoluta.
Análisis determinista del archivo cuando existe, y extracción con IA multimodal cuando solo hay un PDF. Ambos producen exactamente la misma estructura.
Los dos caminos desembocan en la misma pantalla de revisión, y la emisión aborta si una persona no ha aprobado antes la extracción.
Un valor debe ir acentuado; los datos que se validan contra el catálogo oficial casi nunca vienen en el documento del transportista y hay que derivarlos; y un campo ausente no es lo mismo que uno vacío.
El cliente de facturación fuerza el entorno de pruebas cuando detecta que corre en una máquina local, aunque el código pida producción.
Cada una de esas particularidades corresponde a un error de producción que ya no vuelve a ocurrir.
Tres orígenes de cargo, dos monedas, impuestos y retenciones asimétricos. El margen tiene que ser correcto y consultable en cualquier reporte, en cualquier momento.
Calculados como columnas generadas, no en la aplicación: es imposible que una ruta los deje inconsistentes.
Congelado en la operación, no un valor global que cambie el histórico al recalcular.
Cada cargo se convierte y acumula en ambas monedas, para que los totales estén siempre completos en las dos.
Solo los cargos de transportista en estado aceptado cuentan como costo. Los pendientes, rechazados y contraofertados, no.
El margen dejó de ser una hoja de cálculo que alguien cuadra a fin de mes.
El margen se calculaba con una vista que unía y agrupaba todas las tablas de cargos. Con decenas de miles de cargas, cualquier reporte financiero pagaba ese costo.
El resumen se precalcula en una tabla dedicada, con una aceleración declarada de unas cincuenta veces.
La vista original se sustituyó por un envoltorio ligero que mantiene el mismo contrato de columnas: ningún consumidor existente tuvo que cambiar.
Materializar introduce riesgo de desfase, así que se escribieron dos procesos: uno detecta y repara desviaciones, otro contrasta la tabla contra la vista original.
Es la respuesta correcta a «lo materializamos, ¿y si se desincroniza?».
Una interfaz que dispara muchas peticiones por pantalla acabó serializándose sola, y el sistema agotaba conexiones de base de datos sin motivo aparente.
PHP bloquea el archivo de sesión, así que todas las peticiones simultáneas del mismo usuario hacían cola. Se libera antes de ejecutar el controlador, con primitivas que lo reabren solo el instante necesario para escribir.
Cada apertura dentro de la misma petición dejaba otra conexión viva en el proceso servidor. Se resolvió con una única instancia por petición y un cierre deliberadamente vacío.
Ambos hallazgos están comentados en el código y recogidos en el manual de estilo del proyecto — que es lo que hace mantenible una decisión contraintuitiva.
Dos problemas invisibles en desarrollo que solo aparecen con carga real.
Cuentas por pagar recibe miles de evidencias y facturas en PDF de calidad variable, y tiene que verificar a mano que folio, importe y razón social coincidan con el sistema.
Un modelo lee el documento y extrae los campos, sea cual sea su calidad.
El sistema muestra lo que dijo la IA junto a lo que dice la base, con veredictos calculados: ¿coincide el folio?, ¿el importe?, ¿cuánto se parece la razón social?
Para las evidencias, primero se determina si el documento es realmente lo que dice ser; solo entonces se evalúa si tiene sello y firma.
No se paga dos veces por leer el mismo documento.
Decide la persona. La IA solo prepara la decisión.
Los cambios de estado se disparan desde el panel, desde el portal de transportistas, desde procesos automáticos, desde la API pública y desde la instalación hermana. Cualquier aviso construido en el endpoint pierde eventos.
Un disparador en la base de datos encola todo cambio de estado, venga de donde venga. Es el único mecanismo que garantiza cobertura total.
La urgencia de cada aviso sube en función de las horas hábiles transcurridas, calculadas por una función de calendario laboral implementada en el propio motor.
Avisos dentro de la aplicación, actualización en vivo de las pantallas abiertas, y mensajería del equipo con canal propio por cliente.
Es un acuerdo de nivel de servicio codificado en la base de datos.
Todo lo de esta lista existe en producción, en sistemas que sostienen operación real.
Ver todos nuestros serviciosQuantum Ideas nos encargó tres sistemas para tres negocios que no se parecen en nada. Recórrelos, o vuelve a la visión de conjunto.
Si algo de lo que acabas de leer se parece a lo que vives todos los días, hablemos. La primera conversación es de diagnóstico, no de venta.