Vom ERP zum signierten eCoC: Wie CoCDesk sich in ERP- und MES-Systeme von Stufe-1- und Stufe-2-Fahrzeugherstellern integriert
Die eCoC-Daten existieren bereits. Die Übergabe ist das Problem.
Wenn ein Fahrzeug Ihre Linie verlässt, ist jedes Feld, das ein eCoC braucht, längst irgendwo in Ihrem Stack erzeugt und freigegeben worden:
- Typgenehmigungsreferenzen sowie Varianten- und Versionscodes liegen in Ihren Homologations-Stammdaten.
- FIN, Ausstattung, Massen, Achslasten, Abmessungen kommen aus dem Produktionsauftrag oder dem Konfigurator.
- Motor, Getriebe, Emissionsklasse, Kraftstoffart sind an die Variante gekoppelt.
- Aufzeichnungen zur Übereinstimmung der Produktion (CoP) schreibt Ihr Qualitätssystem.
Das Problem ist nicht, dass die Daten fehlen. Das Problem ist, dass sie heute in ERP, MES und Homologationsdatenbank liegen — und von Hand herausgezogen werden, um eine IVI-XML-Vorlage zu befüllen, von Hand validiert, von Hand signiert und von Hand in den nationalen Zugangspunkt hochgeladen werden. Bei wenigen Fahrzeugen funktioniert das. Bei mehreren hundert oder tausend pro Jahr nicht.
Wie sich CoCDesk anschließt
CoCDesk ist dafür gebaut, die Daten zu konsumieren, die Sie ohnehin schon haben. Je nach Reifegrad Ihres IT-Stacks nutzen wir drei Integrationsmuster:
1. Direkte API-Integration
Bei modernen ERPs und MES-Plattformen übergibt das Produktionssystem den Fahrzeugdatensatz per REST oder Message Bus an CoCDesk, sobald die Qualität den Bau freigegeben hat. Ein kundenspezifischer Mapper überführt das Payload in das IVI-2.0-Schema.
2. Datei-Drop (CSV / XML / EDI)
Wo das ERP zu restriktiv ist oder Change-Windows lang sind, holt CoCDesk einen geplanten Export aus einem überwachten Ordner, SFTP-Pfad oder S3-Bucket. Gleicher Mapper, gleiches Ergebnis. Viele Kunden starten so und steigen später auf die API-Integration um.
3. Konfigurator-getriebener Modus
Wenn Sie einen Fahrzeugkonfigurator haben, der bereits abbildet, wie Optionen Massen, Abmessungen und Emissionen verändern, kann CoCDesk dessen Output direkt lesen. Das ist das sauberste Modell für Stufe-2-Aufbauten, bei denen jede Karosserievariante Nutzlast und Genehmigungsreferenzen verändert.
Typisches Eingangspayload: Produktionsauftrags-ID, FIN, Basistypgenehmigung, Variante + Version, Bauoptionen, gemessene Massen, CoP-Kennzeichen des fertiggestellten Fahrzeugs.
ERP- und MES-Systeme, mit denen CoCDesk arbeitet
Wir haben Integrationen gegen die Systeme ausgeliefert oder konzipiert, die Aufbauhersteller sowie Stufe-1- und Stufe-2-Hersteller in der EU tatsächlich betreiben:
| Ebene | Systeme, mit denen wir arbeiten |
|---|---|
| Tier-1- / OEM-ERP | SAP S/4HANA, Oracle Fusion Cloud ERP |
| Mittelstands-ERP Automotive | Infor CloudSuite Automotive, Plex (Rockwell), DELMIAworks (Dassault Systèmes), Microsoft Dynamics 365 F&O, IFS Cloud, Epicor Kinetic |
| DACH- / EU-Aufbauhersteller-ERP | abas ERP, proAlpha, Sage X3, SAP Business One |
| Produktionssteuerung / MES | Siemens Opcenter, Rockwell Plex MES, Dassault Apriso, AVEVA System Platform, Tulip |
| PLM / Typgenehmigungsdaten | Siemens Teamcenter, Dassault ENOVIA, Aras Innovator, eigene Homologationsdatenbanken |
Wenn ein System nicht auf der Liste steht, ist das Integrationsmodell dasselbe — wir bauen einen Mapper gegen Ihren Datenvertrag. Die komplexe Stelle sind Ihre Geschäftsregeln, nicht der Konnektor.
Der End-to-End-Datenfluss
Das Diagramm oben zeigt den vollständigen Pfad. Aus dem Produktionssystem führt CoCDesk den kundenspezifischen Mapper aus, erzeugt ein schemagültiges IVI-2.0-XML, bringt eine XAdES-Signatur eines qualifizierten Vertrauensdiensteanbieters auf der EU-Vertrauensliste auf und übermittelt an den zuständigen nationalen Zugangspunkt (NAP) — bei Bedarf per EUCARIS-Abruf, sofern der Bestimmungsmitgliedstaat die Einreichung über einen ausländischen NAP akzeptiert.
Die Empfangsbestätigung und etwaige Ablehnungsgründe werden in den auslösenden Datensatz in Ihrem ERP oder MES zurückgeschrieben — der eCoC-Status erscheint also neben dem Fahrzeug im Produktionssystem, nicht in einer separaten Tabelle.
Stufe 1 vs. Stufe 2: Die Übergabe zwischen mehreren Bauphasen
Die Form der Integration ändert sich, je nachdem, ob Sie das Grundfahrzeug bauen oder es fertigstellen.
Stufe 1 — Grundfahrzeughersteller
Typischerweise Fahrgestelle und Fahrgestelle mit Fahrerhaus. Die CoCDesk-Integration sitzt am Abschluss-Event des Produktionsauftrags. Das eCoC, das Sie einreichen, deckt das unvollständige Fahrzeug ab und führt die Basistypgenehmigungsreferenz mit, die die nächste Stufe braucht.
Stufe 2 — Aufbauhersteller / Umrüster
Ihr eCoC muss das vorgelagerte eCoC der Stufe 1 referenzieren. CoCDesk löst das, indem es entweder das Basis-eCoC-XML per EUCARIS-Abruf bezieht (bevorzugt) oder die Basistypgenehmigungsreferenz aus dem Datenblatt des Fahrgestellherstellers übernimmt. Ihr Stufe-2-eCoC ergänzt die Massen des fertiggestellten Fahrzeugs, den Aufbautyp und die Achskonfiguration und wird neu signiert.
Der Schmerz, den wir an der Übergabe beseitigen
Abweichungen zwischen Massen und Abmessungen, die Stufe 1 deklariert hat, und dem, was Stufe 2 misst. CoCDesk markiert die Abweichung und verlangt eine Freigabe, bevor das eCoC übermittelt wird — damit Sie keine NAP-Ablehnung kassieren, weil die fertiggestellte Masse die technisch zulässige Masse übersteigt.
Wie ein Integrationsprojekt aussieht
Für einen typischen Aufbauhersteller, der auf Sage X3 oder proAlpha läuft:
- Woche 1 — Datenmapping-Workshop. Wir setzen uns mit Ihrem Homologations-Lead und ERP-Admin zusammen und gehen das IVI-2.0-Schema gegen Ihre Felder durch. Ergebnis: ein einseitiger Datenvertrag.
- Wochen 2–4 — Konnektor gebaut und gegen Ihr Testsystem ausgerichtet. Wir erzeugen Test-eCoCs aus Beispieldaten und übermitteln an den NAP-Testendpunkt.
- Wochen 5–6 — Parallelbetrieb. CoCDesk erzeugt eCoCs neben Ihrem bestehenden Prozess; die Ausgabe wird Feld für Feld verglichen.
- Ab Woche 7 — produktiver Cutover. Die manuelle eCoC-Erzeugung wird abgeschaltet.
Bei Stufe-1-Herstellern auf SAP S/4HANA dauern Discovery und Security-Review länger, der technische Bau ist dafür schneller, weil die Quelldaten sauberer sind.
Ab wann sich die Integration rechnet
In der Praxis liegt die realistische Obergrenze für manuelle eCoC-Erzeugung bei weniger als 50 eCoCs pro Jahr. IVI-2.0-XML ist kein Format, das für das menschliche Auge gemacht ist — es ist dicht, tief verschachtelt und voller Codelisten-Werte, die austauschbar aussehen, es aber nicht sind. Eine händische Erfassung in irgendwie nennenswertem Volumen produziert zwangsläufig Fehler, und jeder Fehler bedeutet eine NAP-Ablehnung plus einen erneuten Signaturzyklus. Oberhalb dieser Schwelle ist die ERP/MES-Integration keine Kostenoptimierung mehr — sie ist der einzige Workflow, der trägt.
Was Teams ebenfalls unterschätzen: Die Integration geht nicht nur um schnellere eCoC-Erzeugung. Weil dieselbe Datenquelle Produktion und Homologation speist, eliminieren Sie auch eine ganze Klasse von Abweichungen zwischen Ihren Produktionsdaten und den Dokumenten, die Sie der Behörde einreichen — und genau dort wird es bei CoP-Audits regelmäßig unangenehm.
CoCDesk für Stufe-1- und Stufe-2-Hersteller
- IVI-2.0-XML-Erzeugung aus Ihrem ERP, MES oder Konfigurator
- Kundenspezifische Mapper; Updates werden ausgerollt, wenn sich Schemata ändern
- Schemaprüfung vor der Einreichung, signierte XAdES-Ausgabe mit QTSP-Zertifikat
- Direkte Einreichung an jeden EU-NAP, plus EUCARIS-Abruf für die grenzüberschreitende Verknüpfung von Basis- und fertiggestelltem Fahrzeug
- Status-Rückschreibung in den auslösenden ERP- oder MES-Datensatz
- Vollständiger Audit-Trail für die Übereinstimmung der Produktion
Wenn Sie Fahrzeuge in Stufen bauen, ist der Engpass bis zum Stichtag 5. Juli 2026 nicht die Regulierung — es ist die Übergabe zwischen Ihrem Produktionssystem und der Zulassungsbehörde. Diese Übergabe können wir in Wochen bauen.
Nächster Artikel
eCoC in der EU: Lagebericht
Bereit für die EU-eCoC-Einführung?
Buchen Sie eine kostenlose Demo und sehen Sie, wie COCDesk Ihren eCoC-Prozess in jedem EU-Mitgliedstaat einsatzbereit machen kann.