Fonte attendibile
Campo, sistema sorgente, responsabile e conflitti tra ERP e TMS.
Integrazione TMS / ERP
Integra eCMR ed eFTI con il tuo TMS o ERP esistente.
Il valore non è copiare campi tra due API. È sapere quale sistema possiede ogni dato, quando cambia, quale fornitore lo riceve e quale prova dimostra che il flusso funziona.
Architettura proposta
Un livello interno, non un nuovo standard chiuso.
ERP / TMS / WMS→Fonte e mapping versionato→Preflight→eCMR / eFTI
Il modello canonico serve alla normalizzazione interna. L’output deve rispettare l’interfaccia e la versione del fornitore selezionato.
Cosa testare
Il connettore deve sopravvivere ai cambiamenti.
Contratto esplicito
Versione del mapping distinta da versione API del fornitore e profilo della regola.
Errore attribuibile
ID di correlazione, esito, retry, proprietario dell’errore e caso negativo.
Caso di prova
La spedizione non coincide sempre con un solo documento.
Prendi un viaggio con più consegne: il TMS conosce l’itinerario, l’ERP possiede il riferimento d’ordine e il vettore aggiunge il numero del veicolo. Un controllo utile non si ferma a “campo presente”: verifica a quale consegna appartiene, chi può cambiarlo e se il dato è arrivato prima della firma. Se due sistemi forniscono valori diversi, il risultato richiede revisione invece di scegliere automaticamente una fonte.
Per una release servono fixture di successo e di errore: campo mancante, riferimento incompatibile, provider che cambia schema, risposta asincrona e retry. Ogni risultato deve essere ricondotto alla versione del contratto e del mapping usata nel test.
Stato
Non ancora disponibile come integrazione produttiva.
La proposta è software-only. Non include un workshop obbligatorio, un’implementazione personalizzata pronta all’acquisto o un connettore universale già testato.
Percorso commerciale previstoGestionale esistente
eCMR senza cambiare ERP, TMS o WMS.
Pubblicato e verificato il . Informazioni generali, non consulenza legale.
La scelta architetturale è mantenere le funzioni operative nei sistemi che già le gestiscono. ERP, WMS e TMS alimentano un modello interno con riferimento della fonte, significato del campo e versione. Da quel modello si prepara l’output per un provider specifico. Normalizzare internamente non significa imporre un nuovo formato proprietario ai partner.
L’ERP può conoscere ordine e anagrafiche, il WMS il carico effettivo e il TMS viaggio e consegne. È un esempio di distribuzione delle fonti, non una mappa valida per ogni impresa. Se due sistemi divergono, una regola di ownership approvata o una revisione deve risolvere il conflitto; la data più recente non è sempre la fonte attendibile.
Separa schema sorgente, mapping e contratto del provider. Un cambiamento dell’API può richiedere un adattatore diverso senza riscrivere tutti i campi del gestionale. Conserva anche le informazioni non rappresentabili nell’output, invece di perderle in una conversione apparentemente valida.
Rilascio
Quattro prove prima della connessione reale.
- Valori e relazioni: una consegna deve mantenere parti, unità e riferimenti corretti.
- Permessi: una parte non può vedere dati di altri destinatari.
- Versioni: firma e modifica restano collegate al contenuto esatto.
- Recovery: timeout e duplicati non generano nuove operazioni senza verifica.
SAP, Dynamics, Sage e Oracle indicano sistemi possibili nell’ICP, non connettori supportati dal nostro progetto. Per dichiarare compatibilità servono accesso autorizzato, versione e risultati del test. Le guide sono disponibili oggi; la connessione produttiva descritta è un obiettivo in preparazione.
Checklist del contratto API Errori di mapping da provareQuadro tecnico
Accesso dei sistemi e versioni da verificare.
Le specifiche funzionali eFTI disciplinano anche l’accesso dei sistemi aziendali e la gestione dei dati della piattaforma. Sono il contesto del percorso proposto, non un’attestazione della nostra architettura o di compatibilità del gestionale. Fonte: regolamento 2025/2243, articoli 4 e 8.