Studiu de caz

Platforma logistica de dispecerat

Sistemul care tine logistica de livrare a unui grup de materiale de constructii cu mai multe divizii, in Irlanda si Marea Britanie. Sta intre ERP-ul grupului si toti cei care ii misca marfa: dispeceri, transportatori si soferii lor, operatorii care incarca in curte, comerciantii care isi asteapta livrarea. L-am construit si extins ca inginer senior, white-label printr-o agentie partenera.

Anonimizat sub NDA: produsul apare aici ca „Meridian”, cu clienti si transportatori fictivi.

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

Problema

Comenzile stau in ERP, dar marfa e miscata de transportatori terti, incarcata de operatori in curte si primita de comercianti care vor sa stie unde le e comanda. Nimic nu lega partile astea, iar legatura cu ERP-ul trecea printr-un mainframe mostenit cu fisiere CSV prin FTP. Ce s-a cerut: un singur loc unde o livrare e planificata, expediata, dovedita si facturata.

Dashboard operational cu contoare de comenzi si load-uri, statusuri pentru transportatori si soferi, ultimele livrari si un panou de acceptare a load-urilor cu limite de timp. — [fig. 1] Dashboardul operational: statistici curente, status transportatori si soferi proprii, ultimele livrari si acceptarea load-urilor cu limite de timp.

Ce am construit

Un hub logistic central pe Laravel, organizat in jurul load-ului.

Dispecerii grupeaza geografic comenzile de vanzare in load-uri, ofera fiecare load unui transportator cu sofer, camion si remorca alocate, apoi il urmaresc de la pick la cantar si livrare. Proof-of-delivery se captureaza la sosire, iar facturarea vine din load-urile efectiv rulate.

Ecranul Loads Planning: carduri grupate pe date, fiecare cu bare de umplere pe greutate si volum, numar de opriri si o sugestie de camion. — [fig. 2] Loads Planning. Panoul de carduri grupate pe date: barele de capacitate W | V care determina sugestia rigid vs trailer-truck, numarul de opriri, o eticheta de off-sell si actiunea de alocare sau editare.

Un nucleu, patru roluri

Divizii, roluri si ce se intampla cand un sofer n-are semnal.

Un singur codebase deserveste trei portaluri de divizie, cu API-uri pentru patru roluri de client (sofer, transportator, picker si comerciant) consumate de aplicatii native companion, cu notificari in timp real si chat pe load.

Soferii iesiti din semnal isi inregistreaza livrarile offline si le sincronizeaza la reconectare.

Un nucleu Laravel modular, nu microservicii: API-uri pe rol, captura care merge si offline si un strat de ERP care poate fi reincercat in siguranta.

Doua ecrane de telefon ale aplicatiei soferului: lista de opriri a load-ului zilei, cu un banner de offline, si un ecran de proof-of-delivery cu linii de produs, semnatura si locuri pentru poze. — [fig. 3] Aplicatia soferului. Lista de opriri a zilei, cu bannerul cozii offline, si proof-of-delivery per firma: linii de produs, semnatar, semnatura, poze POD si paleti returnati. Sincronizate in lot cand soferul revine in semnal.

Migrarea legaturii cu ERP-ul

Un mainframe care schimba fisiere CSV prin FTP, inlocuit fara o comutare dintr-o data.

Am inlocuit schimbul de fisiere CSV prin FTP de pe mainframe cu o integrare REST in Microsoft Dynamics 365 Business Central: poate fi reincercata in siguranta si a fost comutata in etape, nu dintr-o data.

A fost livrata cu documentatie API si un set de cazuri de test, predate partenerului de implementare ERP al clientului. Ingineri care nu aveau sa deschida niciodata acest cod trebuiau sa o poata citi si testa.

Ai de preluat o integrare ca asta? O analiza cu pret fix a ce ai deja, in scris, in 1–3 zile, inainte sa se angajeze cineva la o migrare.

Citeste despre audituri

Monitor de integrari cu trei importuri batch, cadenta si numarul de erori, o coada de fisiere netrimise cu numarul de incercari si un feed de notificari de import. — [fig. 4] Monitorul de integrari. Realitatea batch pe fisiere: cadenta de import la cinci minute, fisierele cu erori, coada UNSENT de reincercari cu numarul de incercari si taskurile programate din spate.

Ce s-a schimbat

O singura imagine a livrarii: planificata, expediata, cantarita, dovedita si facturata intr-un singur sistem, pe trei portaluri de divizie.
Legatura ERP: de la oarba la observabila: autentificata, sigura la reincercare si comutata in etape, in loc de dintr-o singura miscare.
POD-urile pe hartie nu mai stau in torpedou, per firma: semnatura, poza si paleti returnati, capturate offline pe teren si atasate comenzii pe care o vede biroul.

Ai un sistem ca asta de construit sau de preluat?

Spune-mi ce coordonezi si unde e: la zero, in plina desfasurare sau predat de la altcineva.

Rezerva un apel gratuit Incepe o discutie

Sau scrie-mi direct: office@ecdevlabs.com