Estudio de caso

Plataforma de despacho logístico

El sistema que lleva la logística de salida de un grupo de materiales de construcción con varias divisiones, en Irlanda y el Reino Unido. Se sitúa entre el ERP del grupo y todos los que mueven su mercancía: despachadores, transportistas y sus conductores, los operarios del patio de carga, comerciantes que esperan su entrega. Lo construí y lo amplié como ingeniero senior, white-label a través de una agencia asociada.

Anonimizado bajo NDA: el producto aparece aquí como «Meridian», con clientes y transportistas ficticios.

Laravel 12PHP 8.3+MySQLBladeVue 3Bootstrap 5Laravel PassportDynamics 365 Business CentralAzure Blob StoragePusherBitbucket CI

El problema

Los pedidos viven en el ERP, pero la mercancía la mueven transportistas externos, la cargan los operarios del patio y la reciben comerciantes que quieren saber dónde está su pedido. Nada unía a esas partes, y la conexión con el ERP pasaba por un mainframe heredado con archivos CSV por FTP. Lo que se pidió: un solo sitio donde una entrega se planifica, se despacha, se acredita y se factura.

Dashboard operativo con contadores de pedidos y loads, etiquetas de estado de transportistas y conductores, últimas entregas y un panel de aceptación de loads con plazos de vencimiento. — [fig. 1] Dashboard operativo: estadísticas actuales, estado de transportistas y conductores propios, últimas entregas y la aceptación de loads por parte del transportista, con plazos de vencimiento.

Qué construí

Un hub logístico central sobre Laravel, organizado alrededor del load.

Los despachadores agrupan geográficamente los pedidos de venta en loads, ofrecen cada uno a un transportista con conductor, camión y remolque asignados, y lo siguen desde el picking hasta la báscula y la entrega. El proof-of-delivery se captura a la llegada, y la facturación sale de los loads efectivamente realizados.

Pantalla Loads Planning: tarjetas agrupadas bajo encabezados de fecha, cada una con barras de llenado de peso y volumen, número de paradas y una sugerencia de camión. — [fig. 2] Loads Planning. El tablero de tarjetas agrupadas por fecha: las barras de capacidad W | V que determinan la sugerencia de camión rígido o con remolque, el número de paradas, una etiqueta de off-sell y la acción de asignar o editar.

Un núcleo, cuatro roles

Divisiones, roles y qué pasa cuando un conductor se queda sin señal.

Un solo codebase da servicio a tres portales de división, con API para cuatro roles de cliente (conductor, transportista, operario de patio y comerciante) que consumen apps nativas complementarias, con notificaciones en tiempo real y chat por load.

Los conductores que se quedan sin señal registran sus entregas offline y las sincronizan al reconectarse.

Un núcleo Laravel modular en lugar de microservicios: API acotadas por rol, captura que sigue funcionando offline y una capa de ERP que se puede reintentar sin riesgo.

Dos pantallas de teléfono de la app del conductor: la lista de paradas del load del día, con un banner de offline, y una pantalla de proof-of-delivery con líneas de producto, firma y huecos para fotos. — [fig. 3] App del conductor. La lista de paradas del día, con el banner de la cola offline, y el proof-of-delivery por empresa: líneas de producto, el firmante, la firma, fotos POD y palets devueltos. Se sincroniza en lote en cuanto el conductor vuelve a tener señal.

Migrar la conexión con el ERP

Un mainframe que intercambiaba archivos CSV por FTP, sustituido sin un cambio de un día para otro.

Sustituí el intercambio de archivos CSV por FTP desde el mainframe por una integración REST contra Microsoft Dynamics 365 Business Central: se puede reintentar sin riesgo y se migró por etapas, no de un salto.

Se entregó con documentación de la API y un conjunto de casos de prueba, que pasaron al partner que implementaba el ERP del cliente. Ingenieros que nunca iban a abrir este codebase tenían que poder leerla y probarla.

¿Tienes que heredar una integración como esta? Un análisis a precio fijo de lo que ya tienes, por escrito, en 1–3 días, antes de que nadie se comprometa a una migración.

Lee sobre las auditorías

Monitor de integraciones con tres importaciones en lote, su cadencia y su número de errores, una cola de reintentos con los archivos sin enviar y sus intentos, y un feed de notificaciones de importación. — [fig. 4] Monitor de integraciones. La realidad del lote de archivos: cadencia de importación de cinco minutos, archivos con errores, la cola de reintentos UNSENT con el número de intentos y las tareas programadas que hay detrás.

Qué cambió

Una sola vista de la entrega: planificada, despachada, pesada, acreditada y facturada en un solo sistema, en tres portales de división.
La conexión con el ERP: de ciega a observable: autenticada, segura al reintentar y migrada por etapas, en lugar de en un solo salto.
Los POD en papel dejaron de vivir en la guantera, por empresa: firma, foto y palets devueltos, capturados offline en campo y adjuntados al pedido que ve la oficina.

¿Tienes un sistema así que construir o heredar?

Cuéntame qué estás coordinando y en qué punto está: desde cero, a medio camino o heredado de otra persona.

Reserva una llamada gratuita Empecemos a hablar

O escríbeme directamente: office@ecdevlabs.com