eCoC Gönderimi Reddedildiğinde: XML, ICM ve İmza Kontrolleri

eCoC gönderimi başarısız olduğunda incelemeye alıcının yanıtı ve gerçekten gönderilen dosyayla başlayın. Eksik XML alanı, tutarsız araç değeri, imza sorunu ve erişilemeyen servis farklı çözümler gerektirir. Aynı dosyayı nedenini anlamadan tekrar yüklemek, ilk sorunu görünmez hale getirebilir ve hangi kaydın alıcıya ulaştığını belirsizleştirebilir.

Bu rehber, AB ve UK üretici ekipleri için bir inceleme sırası önerir. Buradaki örnekler resmî hata kodları değildir; sorun türlerini açıklamak için hazırlanmıştır. Gerçek yanıt metni, kural referansı ve kullanılan şema sürümü ilgili olay kaydında korunmalıdır. Resmî kaynaklar 16 Ekim 2026 tarihinde kontrol edildi.

Önce dosyanın alıcıya ulaşıp ulaşmadığını belirleyin

VIN veya şirket içi araç referansını, gönderim saatini, ortamı, istek kimliğini, dosya sürümünü ve yanıtın tamamını kaydedin. Süreçte dosya özeti kullanılıyorsa gönderilen dosyanın özetini de saklayın. Açık bir ret yanıtı mı, kimlik doğrulama sorunu mu, bağlantı kesintisi mi, yoksa iş sonucunun gelmemesi mi söz konusu? Zaman aşımı, alıcının kaydı reddettiğini veya hiç saklamadığını tek başına göstermez.

Sonucu belirsiz bir gönderimi tekrarlamadan önce servisin durum sorgulama veya mükerrer kayıt prosedürünü uygulayın. Tekrar gönderim uyarısını aşmak için yeni araç kimliği üretmeyin. Kullanılacak referans ve düzeltme yöntemi, alıcının dokümantasyonuna göre belirlenir. NAP gönderim sürecinde imzalı dosya ile alıcı yanıtının aynı üretici kaydına bağlanması bu nedenle önemlidir.

Her başarısızlığı XML hatası olarak değerlendirmeyin

XSD kontrolü, dosyanın belirli bir şemaya yapısal uygunluğunu değerlendirir. Araç için beyan edilen her kütlenin, yakıt bilgisinin veya onay referansının doğru olduğunu kanıtlamaz. RDW, IVI Checking Module kontrollerinde teknik tutarlılık ve zorunlu bilgilerin değerlendirildiğini, hata durumunda düzeltilmiş kaydın tekrar sunulması gerektiğini açıklıyor. Tek bir “doğrulandı” etiketi yerine çalıştırılan kontrolleri açıkça kaydedin.

Şema hatasını alan ve eşleme düzeyinde inceleyin

Dosyanın, alıcının istediği şema revizyonunu kullandığını doğrulayın. Yalnızca “IVI 2.0” ifadesi bütün şema paketini veya ulusal koşulları tanımlamayabilir. Hata mesajındaki alanın çevresindeki yapıya da bakın. Eksik görünen bir alanın nedeni boş hücre değil, yanlış üst eleman, ad alanı veya sıra olabilir. Bu ayrım yapılmadan kaynak veride değişiklik yapmak yeni tutarsızlıklar doğurabilir.

Örnek olarak kaynak sistemin kütleyi “3,500 kg” biçiminde verdiğini düşünelim. Hedef alan ise belirtilen birimde sayısal değer bekliyor olsun. Kaynağın sayı gösterimini ve aktarım kuralını netleştirin. Virgülün ondalık ayıracı olduğu bir veride noktalama işaretlerini doğrudan silmek anlamı değiştirir. İlk değer, dönüşüm kuralı ve düzeltilmiş çıktı birlikte saklandığında aynı hatanın sonraki üretim grubunda tekrarlanması önlenebilir.

ICM bulgusunu araç konfigürasyonuyla birlikte okuyun

Alıcı ICM kuralları uyguluyorsa kural kimliğini ve mesajın tamamını saklayın. Tek bir değeri değiştirmeden önce kategori, güç aktarma sistemi, onay sürümü ve ilişkili alanları inceleyin. Bir değer tek başına makul görünürken aynı kaydın başka bir bölümüyle çelişebilir. Kontrol, geçerli IVI dokümantasyonu ve ilgili alıcının koşullarıyla birlikte yürütülmelidir.

Sorunu teknik bilginin sahibine atayın. Bilgi işlem ekibi eşleme hatasını düzeltebilir; ancak sırf bir kural geçsin diye yeni mühendislik değeri seçmemelidir. Onaylı konfigürasyon ile üretim kaydı uyuşmuyorsa, yeniden imzalamadan önce homologasyon veya mühendislik incelemesi gerekir. IVI XML doğrulama süreci, bu kararın dosyayla ilişkisini korumalıdır.

İmza kimliği ile gönderim yetkisini ayırın

Alıcının güncel imza koşullarını, sertifikanın temsil ettiği kişi veya kuruluşu ve beklenen XML profilini doğrulayın. Bağlantı için kullanılan kimlik bilgileriyle belgeyi imzalayan sertifika farklı görevler üstlenebilir. Hesabın dosya yükleyebilmesi, belirli bir XML kaydını kimin imzaladığını göstermez. İmzalanmış içerik değiştiğinde imza doğrulaması etkilenebilir; düzeltilmiş aday dosya kontrollü süreçte yeniden üretilip imzalanmalıdır.

Alıcıların aynı kontrolleri yaptığını varsaymayın. VCA'nın güncel rehberi, dijital imzanın varlığıyla sertifika ve anahtarın ek doğrulamasını ayrı açıklıyor. Bir servisin mevcut kontrollerinden geçen dosya başka bir servis için de uygun sayılmaz. XML imzalama düzenini hedef kanalın gerçek koşullarıyla değerlendirin.

Örnek: ilk gönderimi belirsiz kalan kaydın düzeltilmesi

Üretici imzalı kaydı gönderirken bağlantı zaman aşımına uğrasın. Operatör daha sonra bir üretim değerinin yanlış olduğunu fark etsin. Ekip önce ilk dosyanın alıcıya ulaşıp ulaşmadığını belirlemelidir. Ulaştıysa düzeltme süreci, ulaşmadıysa servisin izin verdiği yeni gönderim yöntemi gerekebilir. Bu durum çözülmeden değiştirilmiş dosyayı yüklemek, teknik tekrar denemeyle iş verisi düzeltmesini birbirine karıştırır.

İlk deneme, durum incelemesi, yetkili veri değişikliği, yeni kontrol sonucu ve yeniden imzalanmış çıktı birlikte kaydedilir. Son gönderimin alıcı yanıtı da aynı zincire eklenir. EUCARIS, AB paylaşımındaki düzeltme bildirimlerini açıklar; üretici ise seçtiği NAP'ın özel düzeltme talimatını izler. Yeni yüklemenin önceki kaydı otomatik olarak değiştirdiği varsayılmamalıdır.

Sorunu hangi kanıtla kapatacağınızı belirleyin

Her olayda düzeltmenin sorumlusunu ve kapanış ölçütünü yazın. Yapısal olarak geçerli dosya, şema sorununu kapatabilir; belirsiz kalan teslimi kapatmaz. Alıcı sonucu ve gerekiyorsa sonraki sistemde erişim kontrolü araç kaydında tutulmalıdır. Tekrarlayan sorunların kısa bir kaydı, eşleme hatasının yalnızca bir VIN için değil etkilenen bütün araç ailesi için giderilmesini sağlar.

Electronic COC Platform oluşturma, doğrulama, imzalama, gönderim ve yanıt takibini ilişkilendirir. Teknik incelemeye hassas verileri temizlenmiş reddedilen dosyayı, tam yanıtı ve alıcının şema referansını getirin. Bu üç bilgi, yalnızca “yükleme başarısız” yazan bir ekran görüntüsünden çok daha somut bir inceleme sağlar.