Para qué existe

Comercial sabía quién facturaba más, pero no quién dejaba margen. No es la misma lista: hay clientes de mucho volumen que operan cerca de cero y clientes chicos que sostienen el resultado.

• Concentración de cartera. Cuánto del ingreso depende de los cinco primeros clientes. Es una medida de riesgo, no de éxito.
• Clientes en pérdida. Los que facturan y aun así dejan margen negativo, con el detalle para ir a renegociar tarifa con el caso en la mano.
• Promedio por embarque y mix por modo de transporte y por oficina.
• Tránsito planeado contra real, para saber si lo que se le promete al cliente se parece a lo que pasa.

Se lee en cuatro pestañas: el consolidado de las dos entidades, cada entidad por separado en su moneda funcional, y un checklist de avisos para el cierre por festividad — a quién ya se le avisó, quién lo marcó y cuándo.

El comparativo de tránsito viene con el porcentaje de cobertura pegado al promedio, porque un promedio calculado sobre la mitad de los datos no es un promedio y esconderlo invita a tomar una decisión sobre aire.

De dónde salen los datos

La fuente principal es un reporte distinto al del resto de la suite, y por eso tiene sus propias carencias: no trae fecha de posteo ni fechas reales de tránsito, solo las estimadas. El dashboard completa lo que falta cruzando contra los otros dos webhooks — la fecha de facturación contra cuentas por cobrar, y el tránsito real contra el feed de embarques.

Que el dato venga de dos fuentes distintas no se esconde: el planeado y el real se etiquetan distinto en la interfaz, porque comparar dos cosas que no se midieron igual es justo donde se cuelan las conclusiones falsas.

Decisiones de construcción

• El checklist de avisos agrupa por nombre de cliente, no por código. El mismo cliente factura con código distinto en cada entidad; agrupar por código le manda dos avisos del mismo cierre por festividad y lo hace parecer desorganizado.
• Solo entran los jobs con dinero reconocido. Los que siguen abiertos no tienen margen todavía, y meterlos en un promedio de rentabilidad lo tira hacia abajo sin que nadie haya hecho nada mal.
• El margen se reparte entre las facturas del embarque. Si un embarque genera tres pólizas de costo y a cada una se le carga el costo completo, el margen sale negativo en todos lados. Va un tercio por factura.
• El periodo se filtra por fecha de posteo, no por fecha de salida. Es la base contable, la misma que usa el dashboard financiero, para que los dos digan lo mismo. Los pocos embarques sin factura caen a su fecha estimada de salida y la celda lo dice, en vez de fingir que es lo mismo.
• El tipo de cambio se consulta solo, con dos respaldos y con override manual. Se muestra en pantalla qué valor se usó y de dónde salió: una cifra consolidada en pesos sin decir a qué tipo de cambio no se puede auditar.
• Las operaciones que nacen fuera del ERP se marcan, no se ignoran. Desde julio de 2026 parte del terrestre doméstico se levanta como reserva de transporte directa y nunca aparece en el reporte de origen. Entran como fila propia, con una etiqueta que avisa que no son un embarque normal.
• Sin framework y sin npm, como el resto de la suite: un HTML autocontenido que se sube al portal interno.

Qué es distinto en esta demo

Mismo archivo de producción, capa de datos sustituida por un generador determinista: misma semilla, mismos números para cualquiera que abra el enlace. Las fechas sí son relativas al momento en que se abre, porque un dashboard operativo congelado en una fecha vieja no demuestra nada.

• Clientes, montos y volúmenes son inventados; la marca también.
• El checklist de avisos sí funciona: lo que marques se guarda durante la sesión y se pierde al recargar.
• Exportar a Excel está desactivado: el visor no da permiso de descarga.