Od ERP do podpisanego eCoC: jak CoCDesk integruje się z ERP i MES producentów pojazdów etapu 1 i etapu 2
Dane eCoC już istnieją. Trudne jest ich przekazanie.
Zanim pojazd zjedzie z linii, każde pole, którego potrzebuje eCoC, jest już wygenerowane i zatwierdzone gdzieś w Twoim stacku:
- Referencje homologacji typu oraz kody wariantu/wersji siedzą w Twoich danych podstawowych homologacyjnych.
- VIN, opcje wykonania, masy, obciążenia osi, wymiary wychodzą ze zlecenia produkcyjnego albo z konfiguratora.
- Silnik, skrzynia, klasa emisji, rodzaj paliwa są powiązane z wariantem.
- Rekordy Zgodności Produkcji (CoP) zapisuje Twój system jakości.
Problemem nie jest brak danych. Problem polega na tym, że dziś żyją one w ERP, MES i bazie homologacyjnej, i są ręcznie wyciągane, żeby wypełnić szablon IVI XML, ręcznie walidowane, ręcznie podpisywane i ręcznie wgrywane do krajowego punktu dostępowego. Dla kilku pojazdów to działa. Dla setek czy tysięcy rocznie, już nie.
Jak podpina się CoCDesk
CoCDesk został zbudowany tak, żeby konsumować dane, które już masz. W zależności od dojrzałości Twojego stacku IT używamy trzech wzorców integracji:
1. Bezpośrednia integracja API
W nowoczesnych ERP-ach i platformach MES system produkcyjny pcha rekord pojazdu do CoCDesk przez REST API albo szynę wiadomości w momencie, gdy jakość zamyka pojazd. Mapper przygotowany dla danego klienta przekłada payload na schemat IVI 2.0.
2. Drop pliku (CSV / XML / EDI)
Tam, gdzie ERP jest zbyt zamknięty, a okna change'owe są długie, CoCDesk pobiera zaplanowany eksport z obserwowanego folderu, ścieżki SFTP albo bucketa S3. Ten sam mapper, ten sam output. Wielu klientów zaczyna od tego i przechodzi na API, kiedy wartość jest udowodniona.
3. Tryb sterowany konfiguratorem
Jeśli masz konfigurator pojazdu, który już koduje, jak opcje wpływają na masy, wymiary i emisje, CoCDesk może czytać jego output bezpośrednio. To najczystszy model dla zabudów etapu 2, gdzie każda wersja nadwozia zmienia ładowność i odniesienia homologacyjne.
Typowy payload wejściowy: ID zlecenia produkcyjnego, VIN, bazowa homologacja typu, wariant + wersja, opcje wykonania, zmierzone masy, flagi CoP dla pojazdu skompletowanego.
Systemy ERP i MES, z którymi pracuje CoCDesk
Mamy dostarczone albo wycenione integracje z systemami, na których realnie pracują zabudowcy oraz producenci etapu 1 / etapu 2 w UE:
| Warstwa | Systemy, z którymi pracujemy |
|---|---|
| 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 zabudowców DACH / UE | abas ERP, proAlpha, Sage X3, SAP Business One, Comarch ERP XL |
| Realizacja produkcji / MES | Siemens Opcenter, Rockwell Plex MES, Dassault Apriso, AVEVA System Platform, Tulip |
| PLM / dane homologacyjne | Siemens Teamcenter, Dassault ENOVIA, Aras Innovator, wewnętrzne bazy homologacyjne |
Jeśli systemu nie ma na liście, model integracji jest taki sam, budujemy mapper przeciwko Twojemu kontraktowi danych. Skomplikowane są reguły biznesowe, nie sam konektor.
Przepływ danych od początku do końca
Schemat powyżej pokazuje pełną ścieżkę. Z systemu produkcyjnego CoCDesk uruchamia mapper dla danego klienta, produkuje XML IVI 2.0 zwalidowany schemą, nakłada podpis XAdES kwalifikowanym certyfikatem dostawcy z unijnej Listy Zaufania (TSL), a następnie wysyła do docelowego krajowego punktu dostępowego (NAP), wykorzystując EUCARIS retrieval tam, gdzie państwo docelowe przyjmuje złożenie przez obcy NAP.
Potwierdzenie odbioru oraz ewentualne przyczyny odrzucenia są dopisywane z powrotem do oryginalnego rekordu w Twoim ERP albo MES, czyli system produkcyjny pokazuje status eCoC obok pojazdu, a nie w osobnym arkuszu.
Etap 1 vs etap 2: wieloetapowe przekazanie pojazdu
Kształt integracji zmienia się w zależności od tego, czy budujesz pojazd bazowy, czy go kompletujesz.
Etap 1, producent pojazdu bazowego
Typowo podwozia i podwozia z kabiną. Integracja CoCDesk siedzi obok zdarzenia zamknięcia zlecenia produkcyjnego. eCoC, które wysyłasz, obejmuje pojazd niekompletny i niesie referencję bazowej homologacji typu, której będzie potrzebował następny etap.
Etap 2, zabudowca / przebudowujący
Twój eCoC musi odnosić się do wcześniejszego eCoC wystawionego przez etap 1. CoCDesk rozwiązuje to, pobierając bazowy XML eCoC przez EUCARIS retrieval (preferowane) albo przyjmując referencję bazowej homologacji typu z karty technicznej producenta podwozia. Twój eCoC etapu 2 dodaje masy pojazdu skompletowanego, typ nadwozia i konfigurację osi, a następnie ponownie podpisuje.
Problem, który eliminujemy przy przekazaniu
Rozjazd między masami i wymiarami zadeklarowanymi przez etap 1 a tym, co mierzy etap 2. CoCDesk oznacza rozbieżność i wymaga akceptacji, zanim eCoC zostanie złożone, żebyś nie dostał odrzucenia z NAP-u dlatego, że masa skompletowana przekracza masę technicznie dopuszczalną.
Jak wygląda projekt integracji
Dla typowego zabudowcy działającego na Sage X3 albo proAlpha:
- Tydzień 1, warsztat mapowania danych. Siadamy z Twoim liderem homologacji i administratorem ERP i przechodzimy schemę IVI 2.0 obok Twoich pól. Wynik: jednostronicowy kontrakt danych.
- Tygodnie 2–4, konektor zbudowany i podpięty do Twojego środowiska testowego. Generujemy testowe eCoC z przykładowych pojazdów i wysyłamy je do testowego endpointu NAP.
- Tygodnie 5–6, bieg równoległy. CoCDesk generuje eCoC obok Twojego dotychczasowego procesu; output porównywany jest pole po polu.
- Tydzień 7+, cutover produkcyjny. Ręczne generowanie eCoC zostaje wyłączone.
U producentów etapu 1 na SAP S/4HANA discovery i security review trwają dłużej, ale techniczna budowa jest szybsza, bo dane źródłowe są czystsze.
Kiedy integracja się zwraca
W praktyce realny sufit dla ręcznego wystawiania eCoC to mniej niż 50 eCoC rocznie. IVI 2.0 XML to format, którego ludzkie oko po prostu nie ogarnia, jest gęsty, głęboko zagnieżdżony i pełen wartości z code list, które wyglądają jak wymienne, a wymienne nie są. Wstukiwanie tego z palca przy jakimkolwiek sensownym wolumenie gwarantuje błędy, a każdy błąd to odrzucenie z NAP-u plus kolejny cykl podpisywania. Powyżej tego progu integracja ERP/MES przestaje być optymalizacją kosztu, staje się jedynym działającym workflow.
Drugiej rzeczy zespoły zwykle nie doceniają: integracja to nie tylko szybsze generowanie eCoC. Ponieważ to samo źródło prawdy zasila i produkcję, i homologację, usuwasz całą klasę rozjazdów między rekordami produkcyjnymi a dokumentami składanymi do organu, a to właśnie tam audyty Zgodności Produkcji robią się nieprzyjemne.
CoCDesk dla producentów etapu 1 i etapu 2
- Generowanie XML IVI 2.0 z Twojego ERP, MES albo konfiguratora
- Mappery utrzymywane per klient; aktualizacje wdrażane wraz ze zmianami schemy
- Walidacja schemy przed wysyłką, podpisany output XAdES kwalifikowanym certyfikatem QTSP
- Bezpośrednie składanie do każdego NAP-u w UE plus EUCARIS retrieval dla transgranicznego sparowania pojazd bazowy / pojazd skompletowany
- Zwrotny zapis statusu do oryginalnego rekordu w ERP albo MES
- Pełny ślad audytowy dla Zgodności Produkcji
Jeśli budujesz pojazdy etapami, wąskim gardłem przy terminie 29 listopada 2026 r. nie jest regulacja, jest nim przekazanie pojazdu między systemem produkcyjnym a organem rejestracyjnym. To przekazanie potrafimy zbudować w kilka tygodni.
Gotowi na termin eCoC?
Skontaktuj się z naszym zespołem ekspertów. Chętnie odpowiemy na wszystkie pytania i pomożemy wdrożyć system CoCDesk w Twojej firmie.