Vai al contenuto principale

Case study · Logistica · Sdoganamento · Web

EasyTrain — calcolatore di costi merci Laravel + React

Pubblicato il · Aggiornato il · A cura di YuSMP Group Engineering

Come abbiamo realizzato un calcolatore di costi di trasporto merci in produzione — live sul web, gestito da una società di logistica che elabora centinaia di righe di specifica di sdoganamento per richiesta — costruito su Laravel e React con un modello di accesso a quattro ruoli, un motore di completamento automatico a tre scenari e una base di conoscenza self-learning che comprime i tempi di calcolo a ogni nuova richiesta. Audit-ready per il pubblico degli Stati Uniti e dell'Unione Europea con gestione dei dati allineata a GDPR e CCPA fin dal primo giorno.

SettoreLogistica · Sdoganamento · Web
Anno progetto2020
Tipo di ingaggioPrezzo fisso + supporto
EasyTrain calcolatore di costi di trasporto merci — login operatore su Laravel + React, workflow di sdoganamento US ed EU

Il brief — un calcolatore logistico che regge all'audit operatore

Il team operativo di EasyTrain gestiva a mano le richieste di sdoganamento merci in entrata, ogni giorno, su richieste che contenevano decine o centinaia di righe di specifica — codici HS, attribuzioni di marchio, classe IVA, paese di origine, nomi di prodotto. Il lavoro di calcolo era ripetitivo, il tempo di risposta al cliente era visibilmente penalizzato dalla ricerca manuale, e la conoscenza istituzionale esistente viveva in fogli di calcolo e nelle teste dei calcolatori senior. Abbiamo costruito EasyTrain da principi fondamentali come applicazione web che trasforma la storia accumulata delle richieste in una base di conoscenza: una UI operatore leggera in React, un piano di controllo Laravel che gestisce identità, permessi per ruolo e il motore di predizione, e un flusso di completamento automatico a tre scenari che trasforma le corrispondenze storiche complete in chiusure automatiche con un clic e quelle parziali in moduli pre-compilati che un calcolatore può completare in secondi. La piattaforma è gestita da una società di trasporti e logistica ed è posizionata per il pubblico US ed EU con conformità GDPR e CCPA fin dal primo giorno.

Punti salienti del progetto

Piano di controllo Laravel in PHPConsole operatore ReactMotore completamento automatico a tre scenariControllo accessi a quattro ruoliBase di conoscenza storica self-learningInserimento bulk righe di specificaEvidenziazione campi compilati automaticamenteLancio US & EU · Conforme GDPR + CCPA

I numeri del progetto

Uno snapshot di ciò che il progetto EasyTrain ha consegnato attraverso la console operatore web e il portale admin Laravel per il pubblico US ed EU.

3scenari di completamento automatico — corrispondenza completa, parziale, assente — ognuno con il proprio percorso UI
4 ruolinel modello di accesso — calcolatore, specialista nomenclatura, manager, amministratore — con assegnazione multi-ruolo
100sdi righe di specifica per richiesta di sdoganamento in entrata — il carico di lavoro per cui è stato costruito il motore di completamento automatico
0re-inserimenti manuali di tuple codice HS / marchio / paese già viste — il completamento automatico le porta avanti
1console operatore — SPA React servita da una route Laravel, nessun client nativo da mantenere
8–12 sett.finestra di consegna tipica per un portale operatore logistico B2B comparabile su Laravel + React
Login operatore EasyTrain — controllo accessi Laravel + React con ruoli calcolatore, specialista nomenclatura, manager e amministratore

Perché Laravel + React invece di un CRM generico o uno strumento SaaS

La decisione sullo stack domina ogni altra scelta architetturale in un portale operatore logistico B2B. Abbiamo scelto Laravel sul backend e React sul frontend perché i trade-off si allineano in modo pulito con un workflow specifico di dominio che un CRM generico non riesce a modellare. Laravel include un modello di permessi collaudato, worker per le code, osservabilità di livello Horizon e una storia di tooling admin proprietario (Nova, Filament) che uno strumento SaaS sostituisce con primitive del fornitore. React permette alla console operatore di comportarsi come un'applicazione desktop — modifica bulk delle righe, navigazione da tastiera, evidenziazione visiva dei campi compilati automaticamente — senza la penalità di latenza di un form builder low-code.

Le piattaforme CRM generiche — quelle che cercano di assorbire ogni workflow B2B in un singolo object model — sono state eliminate presto: il modello di accesso a quattro ruoli (calcolatore, specialista nomenclatura, manager, amministratore) non si mappa in modo pulito sulle primitive CRM di lead / contatto / opportunità, e il pattern di inserimento bulk con completamento automatico a tre scenari avrebbe richiesto codice personalizzato che avrebbe interrotto il percorso di aggiornamento SaaS a ogni versione minore. Scegliere Laravel + React ha significato che l'intero stack — console operatore, piano di controllo, base di conoscenza — è aperto, citabile e gestibile da un piccolo team di prodotto end-to-end.

Laravel + React vs CRM generico vs strumento SaaS — confronto rapido
Dimensione Laravel + React (EasyTrain) CRM generico Strumento SaaS
Modellazione del dominioDi primo livello — oggetti riga di specifica, modello a quattro ruoli, motore a tre scenariPrimitive lead / contatto / opportunitàLimitato al metamodello del fornitore
Modello di permessiPrimitive di ruolo / policy di primo livelloPreset ruolo / profilo CRMSolo preset del fornitore
Modifica bulk righeGriglia React di livello desktopSpesso scomoda — un record alla voltaLimiti del form builder low-code
Completamento automatico / predizioneMotore deterministico su misura sulla base di conoscenzaAdd-on o marketplace“AI” del fornitore — opaca
Registro di controlloCatena di custodia completa per ogni scrittura di tupleLog di audit controllato dal fornitoreLog di audit controllato dal fornitore
Time to MVP8–12 settimane tipiche3–6 settimane per la versione standard2–4 settimane ma vincolato al fornitore
Flessibilità a lungo termineOpen source — piena estensibilitàIl percorso di aggiornamento CRM limita la personalizzazioneLa roadmap del fornitore detta il ritmo

Stack references: Laravel documentation, React documentation, WCO Harmonized System nomenclature.

Dashboard richieste in lavorazione EasyTrain — pipeline richieste su Laravel con schede di stato e operazioni bulk

Console operatore — React, la pipeline richieste e l'inserimento bulk specifiche

La console operatore React è costruita come applicazione single-page servita da una route Laravel. L'intera superficie esposta all'operatore si riduce a un piccolo insieme di stati — richieste in lavorazione, richieste chiuse, nuova richiesta, revisione base di conoscenza — e ogni card è un singolo target di tap che porta al flusso corrispondente. La dashboard delle richieste in lavorazione mostra le richieste di sdoganamento in entrata con il loro ID, la data di creazione e un'azione chiara “Apri”. L'inserimento bulk delle specifiche si trova nella vista di dettaglio della richiesta, con navigazione da tastiera, supporto per incolla-da-foglio-di-calcolo ed evidenziazione visiva di ogni cella pre-popolata dal motore di completamento automatico.

Il pannello di inserimento bulk è dove la maggior parte dei prodotti logistici B2B sotto-investe, e dove abbiamo dedicato uno sforzo ingegneristico sproporzionato. Ogni operatore dispone di un archivio completo delle proprie richieste gestite con timestamp, ID richiesta e valori risolti per ogni riga di specifica. Gli operatori in California, New York, Texas, Florida e Washington negli US, e quelli nei Paesi Bassi, Germania, Francia, Irlanda e Svezia nell'EU, vedono esattamente la stessa interfaccia in inglese. La superficie React end-to-end è consegnata come parte della nostra practice di sviluppo di applicazioni web.

Motore di completamento automatico a tre scenari EasyTrain — corrispondenza completa chiude automaticamente, parziale pre-compila, assente torna all'inserimento manuale

Motore di completamento automatico a tre scenari — completo, parziale, assente

Il motore di completamento automatico è il componente operativamente più prezioso del prodotto, e percorre tre percorsi distinti. Una corrispondenza completa — ogni riga di specifica della richiesta in entrata si mappa in modo pulito su una tuple già risolta nella base di conoscenza — chiude la richiesta automaticamente e la instrada al ruolo manager per l'approvazione. Una corrispondenza parziale pre-compila ogni riga per cui esiste una tuple storica, evidenzia le celle risolte nell'UI affinché il calcolatore possa vedere a colpo d'occhio cosa ha compilato il sistema, e lascia le righe rimanenti al lavoro manuale di nomenclatura. Uno scenario senza corrispondenza ritorna al percorso di inserimento manuale che il team aveva prima di EasyTrain — ma ogni chiusura riuscita aggiunge nuove tuple alla base di conoscenza, così la quota di mancate corrispondenze diminuisce nel tempo.

Dietro la superficie operatore, le code Laravel gestiscono il lavoro più lento — ricerche bulk nella base di conoscenza su centinaia di righe di specifica per richiesta, re-indicizzazione su nuove risoluzioni e notifiche fan-out ai ruoli di calcolatore e specialista nomenclatura quando una richiesta cambia stato. Il modello di permessi a quattro ruoli (calcolatore, specialista nomenclatura, manager, amministratore) mantiene basso il raggio d'azione di un ruolo assegnato erroneamente, e un singolo operatore può tenere più ruoli per deployment in team ridotti. L'intero motore è stato costruito con l'estensibilità in mente: aggiungere una nuova dimensione di specifica, un nuovo ruolo o un nuovo criterio di chiusura automatica è una modifica di configurazione contro il servizio regole, non una release di codice.

Base di conoscenza self-learning EasyTrain — archivio storico richieste su Laravel, postura audit-ready, conforme GDPR + CCPA

Base di conoscenza, predizione self-learning e postura audit-ready

La postura self-learning di EasyTrain è stata una decisione architetturale prima di essere un'affermazione di marketing. La base di conoscenza è un archivio strutturato di tuple di specifiche storiche — codice HS, marchio, paese di origine, nome prodotto, classe IVA, categoria risolta — indicizzate per richiesta di provenienza. Ogni richiesta chiusa aggiunge nuove tuple all'archivio, e ogni nuova richiesta in entrata viene confrontata con l'archivio tramite una ricerca deterministica che il team operatore può ragionare, controllare e sovrascrivere. Non c'è nessuna scatola nera ML opaca né rischio di deriva del modello: il sistema è onestamente un indice predittivo deterministico sul lavoro storico dell'azienda.

L'identità dell'operatore è deliberatamente separata dalla base di conoscenza. Il modello di permessi admin a quattro ruoli mantiene il diritto di mutare le tuple storiche isolato al ruolo amministratore, e le policy infrastructure-as-code applicano gli invarianti di audit — qualsiasi pull request che introduca un bypass del controllo dei ruoli, una scrittura di tuple non registrata o un identificatore di lunga durata nel piano di predizione fa fallire la CI. La postura è costruita per allinearsi agli obblighi GDPR per gli utenti nell'Unione Europea e agli obblighi CCPA / CPRA per gli utenti in California e negli Stati Uniti — e per rendere una futura revisione di idoneità indipendente un esercizio documentale, non un intervento architetturale.

Postura di conformità: Conforme al GDPR · Pronto per ISO 27001 · SOC 2 Type II in corso · Compatibile HIPAA · CCPA riconosciuto.

Metodologia di consegna

Un progetto in cinque fasi che ha portato EasyTrain dalla specifica di prodotto alla produzione per gli utenti negli Stati Uniti e nell'Unione Europea.

Fase 1

Discovery e requisiti

Interviste sul workflow operatore, definizione dei quattro ruoli (calcolatore, specialista nomenclatura, manager, amministratore), specifica del completamento automatico a tre scenari, mappatura postura GDPR + CCPA.

Fase 2

Stack e piano di controllo

Scheletro piano di controllo Laravel, scaffold console operatore React, modello permessi a quattro ruoli, schema base di conoscenza, servizio regole motore a tre scenari.

Fase 3

Sviluppo piattaforma

Dashboard React richieste in lavorazione, griglia inserimento bulk righe di specifica, evidenziazione completamento automatico, console admin Laravel, applicazione permessi consapevole dei ruoli.

Fase 4

Hardening audit-ready

Policy infrastructure-as-code che bloccano regressioni di bypass del controllo ruoli, mutazione base di conoscenza riservata all'amministratore, coda anti-frode per comportamenti operatore insoliti, scaffolding per idoneità terze parti.

Fase 5

Lancio e telemetria

Lancio web nelle regioni US ed EU, runbook operatore per i quattro ruoli, dashboard di monitoraggio sull'API di trading e i worker delle code, supporto post-lancio.

Assegnazione multi-ruolo, approvazione manager e il ponte di autorizzazione

Lo strato operativo di EasyTrain è stato costruito per mantenere la piattaforma estensibile verso un futuro multi-tenant e multi-regione senza una riscrittura v2. Il servizio di autorizzazione supporta già più assegnazioni di ruolo per operatore, il modello di permessi admin isola già i privilegi dell'amministratore dall'approvazione del manager e dal throughput del calcolatore, e l'infrastruttura delle code gestisce già il re-indicizzazione ritardata della base di conoscenza e la distribuzione delle notifiche. La roadmap pubblicata aggiunge un deployment multi-tenant dove una holding logistica capogruppo può ospitare più società sussidiarie su un'istanza EasyTrain con basi di conoscenza isolate, un'API pubblica per l'integrazione EDI diretta con gli ERP dei clienti, una dashboard di analisi più approfondita con throughput del calcolatore e trend dei tassi di risoluzione, e un modulo di esportazione dell'audit che mostra ogni evento di scrittura di tuple in un singolo download — ognuno stratificato sul piano di controllo Laravel esistente anziché come stack separato. All'interno del piano operatore, tutto ciò che scorre è un token di sessione opaco di breve durata; la base di conoscenza non vede mai la superficie di identità dell'operatore anche se compromessa. Il modello a quattro ruoli, il flag di assegnazione multi-ruolo e il passaggio di approvazione del manager leggono tutti dallo stesso record di autorizzazione, così uno stato operatore singolo si risolve in modo pulito attraverso la console, il portale admin e l'eventuale API pubblica. L'intero sottosistema è stato costruito con l'estensibilità in mente: aggiungere un livello B2B, una vista multi-tenant o un endpoint partner EDI è una modifica di configurazione contro il servizio di autorizzazione, non una release di codice.

Lancio negli Stati Uniti e nell'Unione Europea

EasyTrain è stato lanciato sul web con la console operatore attiva negli Stati Uniti e nell'Unione Europea. La build in lingua inglese serve operatori in California, New York, Texas, Florida e Washington negli US, e operatori nei Paesi Bassi, Germania, Francia, Irlanda e Svezia nell'EU, senza una codebase separata per regione. I flussi di consenso sono consapevoli della regione al livello client: gli operatori nell'EU e nello SEE ricevono una schermata di consenso granulare in stile GDPR con toggle separati per eventuali analytics opzionali del prodotto; gli operatori in California ricevono un'informativa in stile CCPA sul “Non vendere né condividere le mie informazioni personali” nello stesso flusso. Le pratiche di gestione dei dati sono allineate al GDPR per gli utenti europei e al patchwork sulla privacy degli stati USA — CCPA / CPRA (California), VCDPA (Virginia), CPA (Colorado), CTDPA (Connecticut), UCPA (Utah), TDPSA (Texas) e Oregon CPA. Poiché l'architettura del registro di controllo dell'operatore documenta ogni scrittura di tuple di cui il patchwork si occupa maggiormente, la conformità regionale si riduce a divulgazione onesta anziché a segregazione dei dati per giurisdizione.

Il deployment Laravel è stato distribuito nelle regioni cloud EU e US in parallelo, con i worker di ogni regione provisionati in modo identico da immagini immutabili. Il servizio di matching che risolve il completamento automatico a tre scenari per richiesta esegue worker stateless che possono essere vincolati alle regioni EU o US indipendentemente per futuri impegni di residenza dei dati. L'informativa sulla privacy in-app è stata redatta per documentare esattamente l'architettura sopra descritta, citando direttamente gli obblighi GDPR e gli obblighi CCPA della California. Il team di ingegneria dietro il progetto opera su CET e lavora in orario CET con sovrapposizione con la costa est degli Stati Uniti (9:00–13:00 ET) per stand-up, coordinamento del rollout operatore e risposta agli incidenti — il fuso orario che permette a un team di prodotto US e a un team di ingegneria EU di condividere quattro ore di sovrapposizione live ogni giorno.

Stack tecnologico e roadmap

PHPLaravelLaravel QueuesLaravel HorizonLaravel PoliciesReactTypeScriptVitePostgreSQLRedisElasticSearchNginxDockerKubernetesTerraformPrometheusGrafana

La roadmap attiva di sviluppo software su misura per EasyTrain include un deployment multi-tenant per holding logistiche capogruppo, un'API pubblica per l'integrazione EDI diretta con gli ERP dei clienti, una vista di analisi più approfondita con throughput del calcolatore e trend dei tassi di risoluzione, e un modulo di esportazione dell'audit che mostra ogni evento di scrittura di tuple in un singolo download. Un livello B2B con gestione del team e SSO è pianificato per i casi d'uso di logistica enterprise US ed EU, con il sottosistema di autorizzazione già strutturato per l'assegnazione multi-sede. I piani infrastrutturali includono ulteriore automazione della console admin, un harness di verifica continua interno sugli invarianti di controllo dei ruoli e una futura valutazione di idoneità indipendente inserita nella roadmap Cloud & DevOps.

Realizzate qualcosa di simile — contattateci

Se state pianificando un portale operatore logistico B2B, un prodotto di automazione dello sdoganamento o qualsiasi applicazione web dove il registro di controllo e l'accesso per ruolo devono resistere a una revisione esterna per il pubblico US ed EU, abbiamo consegnato questo stack end-to-end e possiamo ridurre significativamente la timeline di sviluppo. Il team di ingegneria dietro di esso si trova all'interno di YuSMP Group. Lavoriamo a prezzo fisso per MVP ben definiti e con team di sviluppo dedicati per la consegna continuativa, con giornata lavorativa CET e sovrapposizione garantita con la costa est degli Stati Uniti (9:00–13:00 ET) per stand-up, demo e risposta agli incidenti.

Prenota una discovery call Scopri i servizi software enterprise

Domande frequenti

Quanto costa realizzare un calcolatore di costi di trasporto merci come EasyTrain?

Un MVP di portale operatore logistico B2B che copre una console web React, un piano di controllo Laravel, un modello di permessi a quattro ruoli, un motore di completamento automatico a tre scenari e una base di conoscenza storica costa in genere €70k–€160k. Aggiungendo deployment multi-tenant, un'API EDI pubblica, analisi più approfondite e un modulo di esportazione dell'audit si arriva a un prodotto completo per €200k–€420k. I principali fattori di costo sono il modello di permessi a quattro ruoli, lo schema della base di conoscenza e il piano di migrazione, nonché il coordinamento del rollout operatore attraverso i workflow di calcolatore, specialista nomenclatura, manager e amministratore.

Perché usare Laravel + React per un portale logistico B2B invece di un CRM generico?

Laravel include un modello di permessi collaudato, worker per le code, osservabilità tramite Horizon e una storia di tooling admin proprietario che un CRM generico sostituisce con primitive del fornitore che non si mappano in modo pulito su un workflow a quattro ruoli di calcolatore / specialista nomenclatura / manager / amministratore. React permette alla console operatore di comportarsi come un'applicazione desktop — modifica bulk delle righe, navigazione da tastiera, evidenziazione visiva dei campi compilati automaticamente — senza la penalità di latenza di un form builder low-code. Per un workflow specifico di dominio come l'inserimento di specifiche di sdoganamento, Laravel + React è la scelta a rischio inferiore.

Come si costruisce una base di conoscenza self-learning per un prodotto logistico B2B?

Una postura self-learning difendibile è una decisione architetturale, non un'affermazione di marketing. La base di conoscenza è un archivio strutturato di tuple di specifiche storiche — codice HS, marchio, paese di origine, nome prodotto, classe IVA, categoria risolta — indicizzate per richiesta di provenienza. Ogni richiesta chiusa aggiunge nuove tuple all'archivio, e ogni nuova richiesta in entrata viene confrontata con l'archivio tramite una ricerca deterministica che il team operatore può controllare e sovrascrivere. Non c'è nessuna scatola nera ML opaca né rischio di deriva del modello — il sistema è onestamente un indice predittivo deterministico sul lavoro storico dell'azienda.

Quali sono le regole GDPR e CCPA per i portali operatori logistici B2B?

Per gli operatori nell'Unione Europea e nello SEE, il GDPR richiede un meccanismo di consenso granulare, un'informativa sulla privacy chiara e una base documentata per qualsiasi trattamento dei dati collegati all'operatore. Per gli operatori in California, CCPA / CPRA richiede un'informativa sul “Non vendere né condividere le mie informazioni personali” e il diritto alla cancellazione — con Virginia VCDPA, Colorado CPA, Connecticut CTDPA, Utah UCPA, Texas TDPSA e Oregon CPA che aggiungono aspettative analoghe stato per stato negli Stati Uniti. Un'architettura di registro di controllo che documenta ogni scrittura di tuple è il modo più pulito per rendere la conformità regionale gestibile per un portale B2B.

Quanto tempo occorre per realizzare un calcolatore di costi merci sul web?

Un MVP mirato con Laravel + React, un modello di permessi a quattro ruoli, un motore di completamento automatico a tre scenari, una base di conoscenza storica e una console operatore richiede in genere 8–12 settimane. Aggiungere un deployment multi-tenant, un'API EDI pubblica, analisi più approfondite e un modulo di esportazione dell'audit richiede ulteriori 6–10 settimane. La fase di hardening audit-ready — invarianti di controllo dei ruoli applicati in IaC, mutazione della base di conoscenza riservata all'amministratore, valutazione di idoneità di terze parti — è frequentemente sottostimata e dovrebbe essere preventivata in 3–5 settimane di lavoro dedicato.

Condividi questo caso

LinkedIn X

Pianifica un progetto simile

Prenota una discovery call

Richiedi una proposta

Condividi qualche dettaglio e un consulente senior risponderà entro un giorno lavorativo.

Preferite parlare direttamente? ☎ Call +374 44 871 811 ✉ sales@yusmpgroup.com