RETE · PORTALE LOGISTICO
Il vostro spedizioniere vi aggiorna via e-mail. Il team di dispatch inserisce i milestone in un foglio condiviso che qualcuno si dimentica sempre di aggiornare. Le date di sdoganamento arrivano come screenshot PDF. I listini tariffe risiedono in una cartella SharePoint. Quando il container slitta, lo scoprite dall'importatore che chiede spiegazioni. Il vostro «record di spedizione» è una finzione ricostruita da tre caselle di posta e un WhatsApp.
Il Portale logistico in TradeOS è un cockpit brandizzato in cui i vostri spedizionieri, broker e vettori lavorano direttamente — stesso database, limitato a ciò che devono vedere. L'Inbox strutturata sostituisce le e-mail ad hoc. I milestone reali si ancrano a vere macchine a stati. Dogana, dispatch, fatturazione e conversazioni, tutto su un unico record. Identità multi-tenant: un login, molti workspace operatore, ciascuno isolato. Gratuito per il fornitore. Non sostituisce un TMS.
Prenota una demoVedi i prezzi →
Sezioni del portale
7 · inbox, spedizioni, dispatch, fatture e 3 altre
Modalità logistiche
Mare, aereo, camion, ferrovia, espresso e 3 altre
Identità multi-tenant
Un login, molti workspace operatore
Costo per lo spedizioniere
$0 · l'operatore paga TradeOS
La vera Home Dashboard — striscia di benvenuto, widget mappa del mondo con le spedizioni attive nelle rispettive posizioni, coda azioni a due colonne. Una singola chiamata backend (GET /portal/logistics/home) restituisce tutto. Il chrome del brand dell'operatore (logo, colore, etichetta del workspace) viene renderizzato dalle impostazioni tenant dell'operatore.
LA MILESTONE CHE NON SI AGGIORNA MAI
Lo spedizioniere è competente. Il broker è rapido. La pagina di tracking del vettore esiste. Niente di tutto ciò è utile quando il sistema di registrazione di una singola spedizione è distribuito tra tre caselle di posta, due fogli di calcolo, una cartella SharePoint e un gruppo WhatsApp in cui nessuno si trova nello stesso fuso orario.
01 · LE MILESTONE VIVONO IN UN FOGLIO DI CALCOLO CONDIVISO
Il vostro spedizioniere aggiorna un Google Sheet a una cadenza diversa rispetto all'importatore che vi sollecita. Il team operativo ha due fonti di verità — il foglio di calcolo e la pagina di tracking del vettore — e divergono di tre giorni. Nel momento in cui riuscite a ottenere la risposta, il container ha già superato la dogana senza che nessuno se ne sia accorto.
02 · GLI AGGIORNAMENTI DOGANALI VIVONO NEI THREAD DI POSTA ELETTRONICA
Lo spedizioniere doganale è rapido, ma il suo canale è la casella di posta che aveva aperta in quel momento. La notifica di svincolo arriva come allegato PDF. Voi la inoltrate alla contabilità, che non riesce a trovare il numero di dichiarazione perché è dentro lo screenshot. La spedizione parte con tre giorni di ritardo perché nessuno sapeva che fosse stata sdoganata.
03 · UNO SPEDIZIONIERE, QUINDICI PORTALI
Configurate «il vostro» portale e chiedete allo spedizioniere di accedere per aggiornare le milestone. Ne ha uno per ogni cliente. Non ne controlla nessuno con regolarità. I vostri dati diventano obsoleti nel momento in cui chiude la scheda del browser. Il portale diventa un sistema che lo spedizioniere tratta come un onere — finché non lo tratta più affatto.
7 SEZIONI · UN SOLO PORTALE
Dati reali LOGISTICS_NAV.flatLinks da client/src/lib/navConfig.ts. La barra di navigazione mobile inferiore utilizza i primi quattro elementi: Home · Inbox · Spedizioni · Dispatch.
Striscia di benvenuto + mappa del mondo con le Spedizioni attive + coda azioni a 2 colonne (Needs Response, A rischio, Today, Money). Un'unica chiamata backend restituisce tutti i dati.
La coda di risposta strutturata. 3 sotto-schede (prenotazioni, RFQs, contestazioni), ciascuna con le sezioni «Needs Action», «Awaiting Response» e «Recently Decided». Le controfferte inevase vengono promosse automaticamente dopo 48 ore.
5 schede — Tracking, Contenitori, Costi, Dogana, Storico. Un'unica chiamata backend (/shipments/overview/all) restituisce tutti i dati; le schede ne sono proiezioni.
Macchina a 11 stati per il trasporto su gomma. assigned → accepted_by_driver → en_route_to_pickup → arrived → loaded → departed → en_route_to_delivery → arrived → unloaded → completed (+ ramo di fallimento). Completamento subordinato al POD.
Listini con data di validità iniziale / finale / versione / sostituito da. Supplementi per riga, fasce di volume, tariffa minima. Import massivo da 1 a 500 righe in modalità atomica.
Macchina a 10 stati. 3 tipologie: per spedizione, consolidato mensile, ad hoc. Ramo contestazione con tracciamento della risoluzione.
Messaggistica a thread circoscritta alla singola connessione operatore. Collegata a un'entità (prenotazione, RFQ, spedizione, fattura). Notifiche tramite la stessa infrastruttura degli altri portali.
LA CASELLA · 1.252 RIGHE DI UI
Tre tipi di flusso condividono un'unica coda perché, dal punto di vista dello spedizioniere, sono tutti equivalenti: «risposta strutturata, pressione temporale, sono io il collo di bottiglia» — richieste di prenotazione, RFQ e contestazioni di fattura. La superficie Inbox li raccoglie in un'unica coda con moduli di azione inline, in modo che il percorso principale non richieda alcuna navigazione.
5 preventivi inviati · decisione dell'operatore in attesa · più vecchio 18h
2 preventivi vinti · 1 preventivo perso · espandi per visualizzare
SPEDIZIONI · 5 SCHEDE · UNA SOLA CHIAMATA BACKEND
La superficie di lavoro principale dello spedizioniere. GET /portal/logistics/shipments/overview/all restituisce tutto in un'unica chiamata; la pagina mantiene i dati in memoria e li proietta per scheda. Nessun fan-out dal browser, nessun ricaricamento per scheda.
Mappa mondiale + elenco con stato, rotta, ultima tappa e eccezioni aperte. Clic su una riga → espansione contestuale con la cronologia completa delle tappe e le eccezioni aperte per quella spedizione.
Ogni container di ogni spedizione, con tipo, utilizzo (CBM / peso rispetto al massimo del container), numero di sigillo e data di carico. La vista «cosa è caricato dove».
Ricavi per spedizione dalle fatture, importo pagato, saldo residuo. Totali aggregati in cima. Accesso al dettaglio fattura da qualsiasi riga.
Dichiarazioni doganali per spedizione: giurisdizione (ISO 3166), tipo di dichiarazione (import/export/transit), stato (macchina a 7 stati), numero di dichiarazione, codici HS dichiarati. Totali aggregati sdoganato/in sospeso/bloccato in cima.
Unione cronologica di eventi, tappe ed eccezioni su tutte le spedizioni di questo spedizioniere. Feed ordinato per tempo. La superficie del registro di audit.
MACCHINE A STATI · APPLICATE NEL DB
Ogni workflow dispone di una state machine esplicita — tipi enum Postgres o vincoli CHECK. Le regole di transizione a livello di service layer validano quali stati possono evolvere verso quali altri. Nessuna stringa magica, nessuno stato lato interfaccia.
PRENOTAZIONE · 6 STATI
Stati terminali: rifiutata · annullata · scaduta. L'accettazione crea la spedizione collegata.
RFQ · 7 STATI
Rami: persa · rifiuto di quotare · scaduta · ritirata. Il backend impone una sola offerta in sospeso per RFQ.
SPEDIZIONE · 11 STATI
Qualsiasi stato attivo può transitare in failed con l'indicazione di un motivo. Il completamento richiede la previa acquisizione del POD (bloccato da tooltip nell'interfaccia).
FATTURA · 10 STATI
Rami: scaduta · contestata · stralciata. Tre tipi di fattura: per spedizione · consolidata mensile · ad hoc.
SDOGANAMENTO · 7 STATI
Rami: sospesa (documenti / pagamento / ispezione in attesa) · in verifica (la dogana ha posto un quesito) · respinta (terminale). Per giurisdizione × tipo di dichiarazione.
ECCEZIONI · 3+3 ENUM
Severità × stato. Lo stato avanza secondo aperto → in gestione → risolto. Distinto dalle milestone — dichiarata, mitigazione tracciata, risoluzione verificata in audit.
8 MODALITÀ LOGISTICHE · MODELLI DI MILESTONE PER MODALITÀ
L'enum logistics_mode prevede otto valori, ciascuno con il proprio template di milestone per modalità (validato lato server, non tramite enum DB, così i nuovi milestone possono essere aggiunti senza ALTER TYPE).
UN SPEDIZIONIERE · MOLTI OPERATORI
Uno spedizioniere che serve Pendrew Energy, AcmeCorp, BioMed Global e altri sette clienti dispone di una sola riga utente, un solo accesso e dieci spazi operatore tramite la tabella external_memberships (migrazione 121). Si passa da uno all'altro con un clic. Prenotazioni, listini tariffari, milestone, fatture e conversazioni di ciascun operatore sono isolati per connection_id — non esiste alcun percorso API attraverso cui i dati si propaghino tra gli operatori.
Le credenziali API del vettore risiedono al livello external_organization (migrazione 289) — configurate una sola volta, cifrate tramite il plugin KMS e riutilizzate in ogni spazio operatore gestito.
RISERVATEZZA · ARCHITETTURA
Architettura, non un accordo verbale. Vero redactFor(entity, row, viewerRole) in server/src/modules/portal-shell/redaction.ts — lo stesso schema dei portali fornitori e Clienti.
SCOPE PER CONNESSIONE
Non esiste alcun percorso attraverso l'API del portale logistica che si propaghi tra operatori. Gli accessi inter-operatore restituiscono 404 (non 403), in modo che l'esistenza della risorsa rimanga nascosta — verificato nella suite di test del proiettore (portal-logistics/__tests__/projector.test.ts).
OSCURAMENTO A LIVELLO DI CAMPO
Prezzo di acquisto, prezzo di vendita, margine, base di costo — rimossi prima che la riga lasci il database. Le funzioni redactShipmentForClient e redactFor('shipment', raw, 'logistics') applicano questa regola. L'eccezione riguarda il BOL: i dati del consegnatario richiesti per legge compaiono nel documento BOL, disciplinati dalla visibilità definita dagli Incoterms (sezione successiva).
RISERVATEZZA DEI NOLI
I listini dei noli sono limitati per logistics_connection_id. Il Marketplace tariffario lato operatore serve a confrontare i fornitori (funzionalità Solo+), non il contrario — gli spedizionieri non possono verificare «chi ottiene condizioni migliori delle mie». I risultati delle RFQ (vinte / perse) sono comunicati allo spedizioniere interessato, ma non vengono mai aggregati tra spedizionieri.
INCOTERMS · CONFIGURAZIONE VISIBILITÀ
Il JSON visibility_config della connessione (colonna migrazione 122; documentazione dello schema in 291) definisce la visibilità per Incoterm per origine e destinazione — paese / porto / città / factory_name / factory_address / full_address. Sono incluse anche le sostituzioni per Incoterm e le sostituzioni delle etichette.
DDP · CIF · CFR
L'identità del produttore viene astratta nei documenti di spedizione. Lo spedizioniere vede l'indirizzo dell'operatore come origine; le impostazioni del tenant dell'operatore controllano il campo speditore del BOL. Il nome del produttore non viene mai mostrato allo spedizioniere, salvo esplicita sostituzione.
FOB · EXW · FCA
Il produttore è lo speditore legale sul BOL in quanto vi è tenuto per obbligo normativo. Il nome del produttore e l'indirizzo di ritiro sono visibili allo spedizioniere; la visibility_config può comunque limitare ciò che vede il cliente a valle dell'operatore (la redazione nel portale clienti si applica separatamente).
AUTISTA · PWA
Gli autisti installano il Portale logistico nella propria schermata home — manifest.webmanifest + service worker — effettuano l'accesso una sola volta e visualizzano la coda di dispatching filtrata sugli incarichi in cui risultano autista assegnato. Nessuna tariffa, nessuna fattura, nessun'altra spedizione. Le tappe acquisiscono coordinate GPS (latitudine/longitudine) e caricamenti fotografici; il POD richiede firma, nome e qualifica del firmatario prima che la transizione verso completed sia consentita.
Per ogni evento vengono registrati sei valori di sorgente della tappa: user (inserimento manuale ops), driver (acquisizione mobile), carrier_api, ocr, scheduled_auto_advance, operator_override. La tabella delle tappe è append-only — UPDATE viene rifiutato dal trigger; le correzioni inseriscono nuove righe con supersedes_milestone_id che punta al record originale.
Le transizioni automatiche guidate da geofence, la pipeline OCR per il caricamento del BOL e le app native iOS e Android sono nella roadmap — l'enum della sorgente delle tappe riserva già i relativi slot.
ACCESSO PER LIVELLO · 15 FUNZIONALITÀ
Il registro tier_features effettivo (migrazione 291) definisce quindici gate di funzionalità del portale logistico. I fornitori di servizi logistici non vedono mai un paywall; il tier dell'operatore collegato determina ciò che è disponibile nel vostro workspace per quell'operatore.[Roadmap] I tag indicano le funzionalità la cui chiave tier_feature esiste ma la cui implementazione è prevista dopo il lancio.
Roadmap = chiave tier_features registrata nella migrazione 291 (vedi db/migrations/291_logistics_tier_features_and_visibility_overrides.sql); l'implementazione di motore, aggregazione e UI verrà rilasciata post-lancio secondo la Logistics Spec §19, §14, §25.
SULLA ROADMAP
La v1 include sette sezioni, sei macchine a stati, un registro dei traguardi in sola aggiunta, identità multi-tenant, redazione a livello di campo, visibilità guidata dagli Incoterms e tier gating su quindici chiavi di funzionalità. Diverse funzionalità che il team marketing vorrebbe già rivendicare sono segnalate onestamente come roadmap.
01
La migrazione 290 distribuisce lo schema della tabella consolidation_groups. Il motore di suggerimento che popola questa tabella è un processo in background post-lancio; l'interfaccia v1 non espone ancora nulla. Chiave di funzionalità di tier logistics.ai_consolidation_suggestions registrata per Business+.
02
Chiavi di funzionalità di tier logistics.cross_tenant_insights e logistics.network_reputation_display registrate per Business+. Il motore di aggregazione e la soglia anti-inferenza a ≥3 operatori saranno disponibili dopo il lancio.
03
Il consolidamento cross-operatore richiede meccanismi di consenso non ancora definiti. La migrazione 290 lo rimanda esplicitamente — «intentionally NOT modelled here». Chiave di funzionalità di tier riservata.
04
Il valore enum della sorgente milestone 'ocr' è registrato; il servizio OCR che acquisisce un'immagine del BOL, estrae i campi contenitore / nave / sigillo / viaggio e pubblica il milestone corrispondente è post-lancio.
05
Le transizioni di stato del dispatch all'ingresso/uscita dal geofence (arrived_at_pickup, arrived_at_delivery) non sono ancora implementate. La v1 acquisisce il GPS nel momento in cui l'autista conferma il milestone; l'avanzamento automatico tramite geofence è previsto in seguito.
06
Registro integrazioni v1: project44 (live), Freightos Baltic / Xeneta / Drewry / MarineTraffic / Vizion (tariffe di nolo + visibilità AIS). Le integrazioni dirette con Maersk / MSC / CMA CGM / ONE / HMM / Hapag-Lloyd, IATA Cargo IQ per il trasporto aereo e FedEx / UPS / DHL / USPS per l'espresso su strada saranno collegate man mano che le API sottostanti vengono abilitate. logistics_carrier_api_credentials.carrier_name è un campo TEXT libero, pertanto l'aggiunta di un vettore non richiede modifiche allo schema.
07
La PWA è l'interfaccia autista v1 (manifest + service worker attivi in client/public/). Le app native con autenticazione biometrica, API fotocamera native e notifiche push sono post-lancio.
08
La tabella logistics_carrier_api_credentials dispone di una colonna last_polled_at. Il job pianificato che interroga ciascun vettore connesso secondo la propria cadenza (giornaliera per il marittimo, oraria sulle tratte aeree critiche, ogni 12h per il ferroviario) è post-lancio.
FAQ
No. Non siamo in concorrenza con CargoWise, Magaya, Descartes né Project44. Siamo il livello di coordinamento tra il vostro TMS e l'operatore che vi ha incaricato. Mantenete il vostro TMS per le operazioni interne; utilizzate il Portale logistico per il workflow lato operatore che esiste al di fuori di esso — le prenotazioni avviate dall'operatore, la visibilità sulle milestone di cui l'operatore necessita, le dichiarazioni doganali sulle Spedizioni dell'operatore, i listini tariffari e gli RFQ che l'operatore consulta, e le fatture di trasporto che l'operatore salda. L'integrazione TMS per gli operatori con CargoWise / Magaya / Descartes è disponibile nel tier Enterprise.
Inviate un CSV dei vostri principali spedizionieri e una Spedizione aperta. Predisporremo un Portale logistico in sandbox con il branding del vostro tenant, la vostra lista di spedizionieri come external_organizations, e guideremo un vero spedizioniere attraverso l'accettazione di un RFQ, la pubblicazione delle milestone, la dichiarazione doganale e l'emissione di una fattura. Nessun dato dimostrativo. I vostri spedizionieri, la vostra Spedizione.