Neden preflight şart: sefer bildirimi hatayı büyütür
U-ETDS sefer bildirimi gönderilmeden önce yapılacak kontrol, reddi tek seferde önler. Transfer seferlerinde en sık problem, gönderilen kayıtların birbiriyle tutarsız olmasıdır: örneğin yolcu bilgisi doğru görünürken araç plaka formatı veya şoför TCKN/kimlik doğrulaması uyumsuz çıkar. Sistem, alanları tekil doğruların yanında belge–sefer–konum ilişkisini de kontrol eder. Bu yüzden “gönder” tuşuna basmadan önce preflight ile her alanı, U-ETDS şema formatına ve sahadaki operasyona uygun hale getirmeniz gerekir. Amaç, veri setini tek bir kaynaktan ve aynı kurallarla üretmektir. Böylece reddin nedeni belirsiz kalmaz; aksiyon planı netleşir.
Ne kontrol edilecek: belge alanları (referans ve tarih)
Belge tarafında kontrol edeceğiniz başlıklar genellikle en hızlı reddedilen gruptur. Önce belge türü ve belge numarasını U-ETDS beklenen formatla eşleştirin; boşluk, tire veya fazla karakter bırakmayın. Ardından belge tarihini kontrol edin: işlem saatiyle uyumsuz, geleceğe dönük veya yanlış saat diliminden türetilmiş tarih reddedilebilir. “Transfer seferi” ile ilişkilendirilen referansın benzersiz olup olmadığını doğrulayın; aynı gün içinde tekrar edilen yanlış referans, sistemin yanlış eşleme yapmasına yol açar. Neptün Transfer tarafında preflight ekranında belge bölümünü tek bir doğrulama adımıyla okuyun; manuel kopyala-yapıştır yapılan senaryolarda referans uyuşmazlığı yaşanır. Son olarak belge alanlarını loglayın ki reddedilince hangi alanın değiştirildiği anlaşılabilsin.
Yolcu doğrulaması: isim/kimlik ve çoğul kayıt mantığı
Yolcu alanları genellikle “görsel olarak doğru” olup teknik olarak sorun çıkarır. Ad ve soyad alanlarında özel karakter, noktalama ve Türkçe harf dönüşümü (İ/ı, Ğ, Ş vb.) kontrol edilmelidir. Kimlik doğrulamasında TCKN/uygun kimlik alanını boş bırakmayın; format dışı uzunluk veya baştaki sıfırların kaybolması reddedebilir. Yolcuya ait doğum yılı gibi alanlarda gün/ay karışması sık görülen bir durumdur; tarih alanlarını tek bir veri kaynağından üretin. Birden fazla yolcu kaydı varsa seferin toplam yolcu sayısıyla liste boyutunun birebir uyumunu kontrol edin. Ayrıca biniş/iniş konumu ile yolcu profili (ör. özel durum) arasında çakışma var mı bakın; bazı sistemlerde yolcuya bağlı alanlar konum/planla eşleşmezse hata üretir. Preflight sırasında “yolcu doğrulama” sonucunu satır satır raporlayın; tek hata varsa tüm seferi engelleyin, kullanıcıya net gerekçe verin.
Araç ve plaka: format, tip ve sefer uyumu
Araç alanlarını kontrol etmezseniz reddin sebebi doğrudan “seferle eşleşmeyen araç bilgisi” olarak dönebilir. Plaka bilgisinde beklenen formatı kullanın: harf–rakam sırası, boşluk kullanımı ve ülke kodu gibi ekler doğru olmalı. Plaka alanına manuel ekleme yapılıyorsa, sonradan eklenen fazlalık karakterleri temizlemek için standartlaştırma kuralı uygulayın. Araç tipini (örn. taksi/servis vb.) sefer tipine uygun seçtiğinizi doğrulayın; farklı menülerden seçildiğinde yanlış tip “şema uygun ama semantik olarak yanlış” hatası üretebilir. Araç ruhsat/kimlik alanları varsa doğru uzunluk ve karakter setiyle geldiğini kontrol edin. Preflight adımında araç–şoför eşleşmesini de kontrol edin: aynı sefer için farklı araç/şoför eşlemesi varsa hangi kombinasyonun gönderileceği netleşmelidir. En sık görülen hata, sefer oluşturulduktan sonra araç değiştirilip U-ETDS öncesi alanların güncellenmemesidir.
Şoför: kimlik, lisans/ek alanlar ve atanma durumu
Şoför bölümünde en kritik konu, kimlik alanlarının format doğruluğu ve sefer atamasının güncel olmasıdır. TCKN/kimlik numarası alanında boşluk, ilk sıfır kaybı ve uzunluk farklarını yakalayın. Ad soyad alanlarında karakter seti standardını koruyun; farklı kaynaklardan gelen veriler Türkçe karakterleri farklı kodlamayla taşıyabilir. Şoföre ait varsa ehliyet/sertifika bilgisi gibi alanlarda tarihlerin geçerlilik kontrolünü yapın; bildirilen sefer tarihiyle çakışmayan bitiş tarihi reddedilebilir. Ayrıca şoför atanma statüsünü doğrulayın: “planlandı” ile “aktif olarak bildirilecek” ayrımını preflight’ta aynı mantıkla kullanın. Neptün Transfer tarafında şoförü değiştirdiğinizde, sefer gönderimi öncesi hangi kaydın son halini aldığını kontrol eden bir karşılaştırma adımı ekleyin. En yaygın operasyon hatası, sistemde atanmış görünen şoförün U-ETDS öncesi şablonda eski kalmasıdır; preflight bunu yakalamalıdır.
Konum ve sefer bildirimi: D2 mantığıyla başlangıç-bitiş kontrolü
Konum alanları U-ETDS’te çoğu zaman en görünmez reddi üretir. D2 mantığında başlangıç ve varış bilgileri, aktarım güzergâhıyla tutarlı olmalı. Şehir/ilçe veya koordinat alanlarını gönderiyorsanız format ve sınır kontrolü yapın: enlem-boylam ters dönmesi, metin olarak gönderilen sayılar veya gereksiz yuvarlama sorun çıkarabilir. Saha operasyonunda “yaklaşık” verilen konumlar varsa, U-ETDS için gerekli minimum doğrulukla geldiğini doğrulayın. Ayrıca seferin başlangıç saatiyle konumun zaman uyumu kontrol edilmelidir; özellikle birden fazla duraklı planlar varsa ana başlangıç-bitiş hangi kurala göre seçiliyor net olmalı. Preflight ekranında konumu iki ayrı blok halinde gösterin: “Sefer başlangıç” ve “Sefer varış”. Kullanıcıdan önce bu iki bloğu onay aldırın; tek blokta karma bilgi toplamak, hata ayıklamayı zorlaştırır. “Son durak” ile “bildirilen varış”ın farklı olabildiği senaryoları özellikle ele alın.
Neptün Transfer preflight ekranı: karar ölçütleri ve hata raporu
U-ETDS öncesi kontrolün işe yaradığı yer, kullanıcının tek bir ekranda “gönderemem neden?” sorusunu anında görmesidir. Preflight’ta karar ölçütlerini kural tabanlı çalıştırın: Örn. belge referansı boşsa gönderme; kimlik numarası doğrulanmıyorsa satırı işaretle; plaka formatı şablona uymuyorsa engelle; başlangıç-varış konumu çakışıyorsa bildirimi durdur. Hata raporunu tek satırlık özet yerine alan adı + beklenen kural + mevcut değer şeklinde üretin. Ayrıca “düzeltip yeniden dene” akışı verin: kullanıcı düzeltme yaptıktan sonra preflight sonucunu otomatik yenileyin; eski sonucu saklamayın. Günlük operasyonda sık yapılan hata, preflight sonucunu sadece “var/yok” gibi göstermektir; oysa hangi alanda hata olduğu bilinmeden düzeltme yapılmaz. Son olarak reddedilmiş bir bildirimi yeniden göndermeden önce aynı sefer için son veriyi çektiğinizi doğrulayın. Bu, güncelleme gecikmesi kaynaklı çarpışmaları azaltır.
Sık reddedilme senaryoları: hızlı tanı ve önleyici önlemler
Pratikte en sık karşılaşılan reddetme nedenleri belirli kalıplara döner. En öne çıkanlar; tarih formatı uyumsuzluğu, kimlik numarası uzunluk/karakter hatası, plaka boşluk/tire farkı, yolcu sayısı ile liste boyutu tutarsızlığı ve başlangıç-varış konumunun D2 eşleşmemesidir. Ayrıca şoför-atama güncellenmediğinde “seferle eşleşmeyen şoför” raporu alınır. Önleyici olarak preflight’ta alanlar arası çapraz kontrol ekleyin: sefer başlangıç saati ile şoför atama saati arasında bariz uyumsuzluk varsa uyarı üretin; araç değiştiyse araç–plaka bölümünü yeniden doğrulayın. Log tutarak her gönderim öncesi ham veri snapshot’ı saklayın; böylece reddin hangi kaynaktan türediği anlaşılır. Son adımda kullanıcıya sadece hata vermeyin; hangi bölümün açılacağını ve nasıl düzeltilmesi gerektiğini belirtin. Bu yaklaşım, tekrar tekrar manuel deneme yapmayı bırakmanızı sağlar.
Uygulama sonrası kontrol listesi
- Mobil görünüm, form ve WhatsApp yönlendirmeleri test edilir.
- Title, description, canonical ve sitemap kayıtları kontrol edilir.
- Kırık link, hatalı görsel ve boş CTA alanı bırakılmaz.
- İçerikler gerçek hizmet kapsamıyla uyumlu kalır.