Dal tuo ERP a un eCoC firmato: come CoCDesk si integra con gli ERP e MES dei costruttori di veicoli di stadio 1 e stadio 2
I dati dell'eCoC esistono già. Il difficile è il passaggio di consegne.
Quando un veicolo esce dalla tua linea, ogni campo richiesto da un eCoC è già stato generato e approvato da qualche parte nel tuo stack:
- Riferimenti di omologazione e codici variante/versione stanno nei tuoi dati anagrafici di omologazione.
- VIN, opzioni di costruzione, masse, carichi per asse, dimensioni escono dall'ordine di produzione o dal configuratore.
- Motore, trasmissione, classe di emissioni, tipo di carburante sono legati alla variante.
- I record di Conformità della Produzione (CoP) li scrive il tuo sistema qualità.
Il problema non è che i dati non esistano. Il problema è che oggi vivono nell'ERP, nel MES e nel database di omologazione — e vengono estratti a mano per compilare un template IVI XML, validati a mano, firmati a mano e caricati a mano sul punto di accesso nazionale. Per una manciata di veicoli funziona. Per centinaia o migliaia all'anno, no.
Come si collega CoCDesk
CoCDesk è costruito per consumare i dati che già hai. A seconda della maturità del tuo stack IT, usiamo tre modelli di integrazione:
1. Integrazione API diretta
Per ERP e MES moderni, il sistema di produzione invia il record veicolo a CoCDesk tramite API REST o message bus non appena la qualità chiude il veicolo. Un mapper specifico per cliente converte il payload nello schema IVI 2.0.
2. Drop di file (CSV / XML / EDI)
Quando l'ERP è troppo vincolato o le finestre di change sono lente, CoCDesk preleva un export schedulato da una cartella sorvegliata, un percorso SFTP o un bucket S3. Stesso mapper, stesso output. Molti clienti partono di qui e passano all'integrazione API una volta dimostrato il valore.
3. Modalità pilotata dal configuratore
Se hai un configuratore veicolo che già codifica come le opzioni impattano su masse, dimensioni ed emissioni, CoCDesk può leggerne direttamente l'output. È il modello più pulito per le costruzioni di stadio 2, in cui ogni variante di allestimento cambia portata e riferimenti di omologazione.
Payload in ingresso tipico: ID ordine di produzione, VIN, omologazione di base, variante + versione, opzioni di costruzione, masse misurate, flag CoP del veicolo completato.
ERP e MES con cui lavora CoCDesk
Abbiamo consegnato o dimensionato integrazioni contro i sistemi che gli allestitori e i costruttori di stadio 1 / stadio 2 dell'UE effettivamente usano:
| Livello | Sistemi con cui lavoriamo |
|---|---|
| ERP Tier-1 / OEM | SAP S/4HANA, Oracle Fusion Cloud ERP |
| ERP automotive mid-market | Infor CloudSuite Automotive, Plex (Rockwell), DELMIAworks (Dassault Systèmes), Microsoft Dynamics 365 F&O, IFS Cloud, Epicor Kinetic |
| ERP per allestitori DACH / UE | abas ERP, proAlpha, Sage X3, SAP Business One |
| Esecuzione di produzione / MES | Siemens Opcenter, Rockwell Plex MES, Dassault Apriso, AVEVA System Platform, Tulip |
| PLM / dati di omologazione | Siemens Teamcenter, Dassault ENOVIA, Aras Innovator, database di omologazione interni |
Se un sistema non è in elenco, il modello di integrazione è lo stesso — costruiamo un mapper contro il tuo contratto dati. La parte complessa sono le tue regole di business, non il connettore.
Il flusso dati end-to-end
Il diagramma sopra traccia il percorso completo. Dal sistema di produzione, CoCDesk esegue il mapper specifico per cliente, produce un XML IVI 2.0 validato a schema, applica una firma XAdES di un prestatore di servizi fiduciari qualificato presente nella Lista di Fiducia dell'UE e invia al punto di accesso nazionale (NAP) di destinazione — usando il recupero EUCARIS quando lo Stato membro di destinazione accetta l'invio tramite un NAP estero.
La ricevuta e gli eventuali motivi di rigetto vengono riscritti nel record di origine del tuo ERP o MES — così il sistema di produzione mostra lo stato dell'eCoC accanto al veicolo, non in un foglio di calcolo a parte.
Stadio 1 vs stadio 2: il passaggio di consegne multi-stadio
La forma dell'integrazione cambia a seconda che tu costruisca il veicolo base o lo completi.
Stadio 1 — costruttore del veicolo base
Tipicamente telai e telai cabinati. L'integrazione CoCDesk si colloca accanto all'evento di chiusura dell'ordine di produzione. L'eCoC che invii copre il veicolo incompleto e porta con sé il riferimento di omologazione di base che servirà allo stadio successivo.
Stadio 2 — allestitore / trasformatore
Il tuo eCoC deve riferirsi all'eCoC a monte emesso dallo stadio 1. CoCDesk gestisce questo ricevendo l'XML eCoC di base tramite recupero EUCARIS (preferito) o accettando il riferimento di omologazione di base dalla scheda tecnica del costruttore del telaio. Il tuo eCoC di stadio 2 aggiunge le masse del veicolo completato, il tipo di carrozzeria e la configurazione degli assi, poi rifirma.
Il dolore che eliminiamo al passaggio di consegne
Le derive di massa e dimensione tra ciò che lo stadio 1 ha dichiarato e ciò che lo stadio 2 misura. CoCDesk segnala la divergenza e richiede una conferma prima dell'invio dell'eCoC — così non incassi un rigetto del NAP perché la massa completata supera la massa tecnicamente ammissibile.
Com'è fatto un progetto di integrazione
Per un allestitore tipico che gira su Sage X3 o proAlpha:
- Settimana 1 — workshop di mapping dati. Ci sediamo con il tuo responsabile omologazione e l'amministratore ERP e percorriamo lo schema IVI 2.0 confrontandolo con i tuoi campi. Output: un contratto dati di una pagina.
- Settimane 2–4 — connettore costruito e puntato sul tuo ambiente di test. Generiamo eCoC di test a partire da veicoli campione e li inviamo all'endpoint di test del NAP.
- Settimane 5–6 — esecuzione in parallelo. CoCDesk genera eCoC accanto al tuo processo esistente; l'output viene confrontato campo per campo.
- Settimana 7 in poi — cutover in produzione. La generazione manuale degli eCoC viene dismessa.
Per i costruttori di stadio 1 su SAP S/4HANA la fase di discovery e la security review durano di più, ma la realizzazione tecnica è più rapida perché i dati sorgente sono più puliti.
Quando l'integrazione si ripaga
Nella pratica, il tetto realistico per la generazione manuale di eCoC sta a meno di 50 eCoC all'anno. L'XML IVI 2.0 non è un formato pensato per l'occhio umano: è denso, profondamente annidato e pieno di valori di code list che sembrano intercambiabili ma non lo sono. Digitarlo a mano per qualsiasi volume serio garantisce errori, e ogni errore è un rigetto del NAP più un nuovo ciclo di firma. Sopra quella soglia, l'integrazione ERP/MES smette di essere un'ottimizzazione di costo: è l'unico flusso che regge.
L'altra cosa che i team sottovalutano: l'integrazione non riguarda solo la velocità di produzione degli eCoC. Poiché la stessa fonte di verità alimenta produzione e omologazione, si elimina anche un'intera classe di discrepanze tra i tuoi record di costruzione e i documenti che invii all'autorità — esattamente il punto in cui gli audit di Conformità della Produzione si fanno tesi.
CoCDesk per i costruttori di stadio 1 e stadio 2
- Generazione di XML IVI 2.0 dal tuo ERP, MES o configuratore
- Mapper mantenuti per cliente; gli aggiornamenti vengono distribuiti al cambiare degli schemi
- Validazione di schema prima dell'invio, output XAdES firmato con certificato QTSP
- Invio diretto a ogni NAP UE, più recupero EUCARIS per l'accoppiamento transfrontaliero veicolo base / veicolo completato
- Riscrittura dello stato nel record ERP o MES di origine
- Pista di audit completa per la Conformità della Produzione
Se costruisci veicoli per stadi, il collo di bottiglia per la scadenza del 5 luglio 2026 non è la normativa: è il passaggio di consegne tra il tuo sistema di produzione e l'autorità di immatricolazione. Possiamo costruire quel passaggio in poche settimane.
Articolo successivo
eCoC nell'UE: aggiornamento della situazione
Pronto per l'avvio dell'eCoC nell'UE?
Prenota una demo gratuita e scopri come COCDesk può rendere il tuo processo eCoC pronto per la produzione in ogni Stato membro dell'UE.