EUCARIS ICM 3.1: nowe obowiązkowe pola eCoC, ostrzejsze kontrole i dlaczego nieśledzone zgłoszenia będą odrzucane
Moduł kontrolny IVI (ICM) to zestaw reguł walidacji publikowany przez EUCARIS, który krajowe punkty dostępowe stosują do każdego przychodzącego eCoC w formacie IVI 2.0. Jeśli plik XML nie spełnia choćby jednej reguły, zgłoszenie jest odrzucane i pojazdu nie da się zarejestrować na podstawie tego rekordu. Wersja 3.1 ukazała się 28 września 2026 r., trzy tygodnie po wersji 3.0 z 5 września.
Co zmienia wersja 3.1
Wydanie z 28 września jest niewielkie, ale każdy jego punkt może zamienić dotąd akceptowany plik w odrzucony:
- Nowy XSD IVI 2.0 z rozszerzoną listą wartości ExhaustEmissionLevel. Pliki generowane według poprzedniego schematu mogą nie przejść walidacji schematu.
- PoweredAxle jest teraz obowiązkowe dla kategorii pojazdów M, N, T i C.
- Poprawiono regułę LoadableAxleIndicator: wskaźnik musi mieć wartość N, gdy NumberOfAxles jest mniejsze niż 2 (wcześniej: mniejsze lub równe 2).
- InServiceMaximumPermissibleLadenMassAxle nie może już występować samodzielnie. Wymaga teraz InServiceMaximumPermissibleLadenMassAxleCountry albo InServiceMaximumPermissibleLadenMassAxleTrafficRegulation.
- BodyWorkTable nie może już zostać pominięta, gdy reguły czynią jej pola obowiązkowymi. W tych samych warunkach sama tabela musi być obecna.
A trzy tygodnie wcześniej, w wersji 3.0
Wersja 3.0 z 5 września była większym wydaniem, wynikającym z dyskusji o pojazdach wieloetapowych w grupie roboczej EReg:
- Ponad 50 pól dotyczących osi, wymiarów, oznaczeń, przetworników energii i klasy pojazdu stało się obowiązkowych wyłącznie dla pojazdów kompletnych (StageOfCompletion = C). Ułatwia to zgłoszenia pojazdów niekompletnych i skompletowanych, ale zmienia też, jakie pola musi zawierać pojazd kompletny.
- Kontrola numeru homologacji dla pojazdów wieloetapowych wróciła do pierwotnej postaci: PreviousStageTypeApprovalNumber musi różnić się od TypeApprovalNumber.
- ActualMass musi być mniejsza lub równa TechnicallyPermissibleMaximumLadenMass dla kategorii M, N, O i L. Dodano brakujące „lub równa”.
- TyreFittedProductionIndicator musi mieć wartość dla każdej opony.
- VehicleIdentificationNumber dla kategorii T, C, R i S (rozporządzenie 167/2013) może teraz zawierać litery I, O i Q.
- Zero nie jest już akceptowane w technicznych polach numeracyjnych: ManufacturerStageNumber, GearNumber, FinalDriveNumber, AxleNumber, TyreNumber i ośmiu innych.
- Poprawki ścieżek zagnieżdżenia reguł R214 i R215, położenia CategoryHybridElectricVehicle, zamienionych poziomów TypeINox i TypeINmhc oraz błędu strefy czasowej w kontroli daty produkcji.
Dziewięć wydań w siedem miesięcy
To nie jest jednorazowa zmiana. Odkąd ICM zyskał informację o wersji w lutym 2026 r., przeszedł od 2.3 przez 2.4, 2.5, 2.6, 2.7, 2.8, 2.9 i 3.0 do obecnej 3.1. Wcześniejsze wydania również dodawały treści obowiązkowe: AxleAirSuspensionOrEquivalentIndicator stał się obowiązkowy dla kategorii O, dodano MechanicalCouplingCanBeFittedApprovalMark i ApprovalNumber, dodano SignerName, TestFamilyIdentifierValue zyskał kontrolę formatu, a nowy XSD IVI 2.0 z 10 czerwca zastąpił poprzedni schemat.
W praktyce zestaw reguł zmienia się mniej więcej raz w miesiącu, a to, co uznaje się za pole obowiązkowe, jest celem ruchomym. Integracja zbudowana raz pod daną wersję ICM jest poprawna tylko do kolejnego wydania.
Odrzucenie, nie ostrzeżenie
Krajowy punkt dostępowy nie przyjmuje pliku, który nie spełnia reguły ICM. eCoC, które przeszło w sierpniu, może zostać odrzucone w październiku bez żadnej zmiany po stronie producenta. Dla producenta generującego XML IVI z szablonu, narzędzia konwertującego lub własnego skryptu napisanego pod starszą wersję ICM pierwszym sygnałem jest zwykle odrzucenie w NAP, a czasem pojazd zatrzymany w wydziale komunikacji.
Rośnie też koszt pomyłki. Jak opisaliśmy w artykule oharmonogramie KBA dla IVI 2.0, od wersji 2.x przesłanych rekordów nie można już usuwać; jedynym rozwiązaniem jest rekord korygujący. Poprawny plik za pierwszym razem ma większe znaczenie niż kiedyś.
Jak CoCDesk obsługuje wydania ICM
Nadążanie za ICM jest częścią tego, co robi CoCDesk, a nie zadaniem naszych klientów:
- Śledzimy każde wydanie ICM i XSD od EUCARIS i szybko po publikacji wdrażamy nowe reguły do silnika walidacji platformy, dzięki czemu CoCDesk waliduje według zestawu reguł, który faktycznie działa w krajowych punktach dostępowych.
- Każde eCoC jest sprawdzane według aktualnego zestawu reguł ICM i XSD, zanim opuści Twój system. Niekompletny lub niezgodny plik nigdy nie jest wysyłany, więc nigdy nie jest odrzucany.
- Nowe pola obowiązkowe są widoczne w interfejsie: pole jest podświetlone, a reguła wyjaśniona, więc Twój zespół wie dokładnie, co uzupełnić i dlaczego.
- Gdy pole staje się obowiązkowe, jest mapowane raz z Twojego ERP, MES lub danych homologacyjnych. Nikt nie edytuje XML ręcznie.
- Logika StageOfCompletion z wersji 3.0 jest stosowana automatycznie, więc pojazdy niekompletne, skompletowane i kompletne są walidowane według właściwego podzbioru reguł.
- Każde zgłoszenie zachowuje opatrzony znacznikiem czasu zapis wersji reguł, według której było walidowane, gotowy na kontrole zgodności produkcji.
Czy Twój proces eCoC jest gotowy na ICM 3.1?
Jeśli Twoje eCoC powstają z szablonu, konwertera lub skryptu, wersja 3.1 to dobry moment, żeby je sprawdzić. Umów demo na żywo, a przepuścimy Twoje dane pojazdów przez aktualny zestaw reguł.
Umów demo na żywoMasz pytania o 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.