Müşteri Kartında VKN, TCKN ve IBAN Nasıl Doğrulanır
Müşteri kartındaki VKN, TCKN ve IBAN alanlarında iki ayrı kontrol vardır ve karıştırılmamalıdır. Biçim doğrulaması, numaranın kendi içinde tutarlı olup olmadığını yazılımın kendi içinde, hiçbir servise çıkmadan söyler. Gerçeklik doğrulaması, o numaranın gerçekten o kişiye veya firmaya ait olup olmadığını söyler ve bunun için dış bir servise sormak gerekir. Yazılım ilkini her zaman yapabilir, ikincisini ancak bir entegrasyon varsa yapabilir.
Bu ayrımı kurmayan yazılımlarda iki uç hata görülür. Ya hiçbir kontrol yoktur ve cari karta on hane yerine dokuz hane girilir, fatura kesilirken iş durur; ya da yazılım her kayıtta dış servise sorar, servis yavaşladığında müşteri kaydı hiç açılamaz. Doğru kurulum ikisinin arasındadır: biçim kontrolü kayıt anında zorunlu, gerçeklik kontrolü belge kesme anında ve mümkünse arka planda.
Biçim doğrulaması nerede biter?
Biçim doğrulaması üç soruyu yanıtlar: alan doğru uzunlukta mı, yalnızca izinli karakterleri mi içeriyor, kendi içindeki sağlama basamağı hesapla uyuşuyor mu? Üçüncüsü en değerlisidir çünkü basit yazım hatalarını — iki rakamın yer değiştirmesi, bir hanenin eksik kalması — servise hiç çıkmadan yakalar.
Vergi kimlik numarası on hanedir ve son hanesi, önceki hanelerden hesaplanan bir sağlama basamağıdır. T.C. kimlik numarası on bir hanedir, sıfırla başlamaz ve son iki hanesi önceki hanelerden ağırlıklı toplamla hesaplanır. IBAN ise harf ve rakamdan oluşur, ülke koduyla başlar, uzunluğu ülkeye göre sabittir ve baştaki iki rakam tüm dizge üzerinden hesaplanan bir sağlama değeridir. Üçünün ortak özelliği şu: numaranın içinde kendini kontrol eden bir hane vardır, yazılım o haneyi yeniden hesaplayıp karşılaştırır.
Bu kontrollerin bir kez yazılıp her yerde kullanılması gerekir. Aynı doğrulama müşteri kartı ekranında, toplu veri yükleme işinde, API ucunda ve sipariş formunda ayrı ayrı yazılırsa dördü zamanla birbirinden ayrışır: ekran kabul eder, API reddeder, aynı numara için iki farklı sonuç çıkar.
Alan alan hangi kontrol yapılır?
| Alan | Yazılımın kendi içinde | Dış servis gerektiren |
|---|---|---|
| VKN | Hane sayısı, yalnız rakam, sağlama basamağı | Unvan ve vergi dairesi eşleşmesi |
| TCKN | Hane sayısı, sıfırla başlamama, sağlama basamakları | Ad soyad ve doğum yılı eşleşmesi |
| IBAN | Uzunluk, karakter kümesi, ülke kodu, sağlama değeri | Hesap sahibinin adı, hesabın açık olması |
| Vergi dairesi | Listeden seçilmiş mi | Numarayla uyumlu mu |
| E-posta | Biçim ve alan adı yazımı | Adresin teslim alıp almadığı |
| Telefon | Ülke kodu, hane sayısı, boşluk temizliği | Hattın aktif olması |
Normalleştirme: doğrulamadan önce gelen adım
Kullanıcı IBAN'ı boşluklu yazar, bazen başındaki ülke kodunu yazmaz, bazen küçük harf kullanır. Vergi numarasını tire ile ayırarak yazan da olur. Doğrulamadan önce alanın normalleştirilmesi — boşluk ve tire temizliği, harflerin büyütülmesi, görünmez karakterlerin atılması — hatalı sanılan kayıtların çoğunu ortadan kaldırır.
Normalleştirme kuralı tek yönlü olmalı: veritabanına yazılan değer her zaman normalleştirilmiş biçimdedir, ekranda okunabilirlik için gruplanarak gösterilir. Tersi yapılırsa, yani boşluklu biçim saklanırsa, aynı IBAN iki farklı yazımla iki kayıt olarak girer ve mükerrer kontrolü işe yaramaz. Aynı kural VKN ve TCKN için de geçerlidir: alan metin olarak saklanır ama içinde yalnızca rakam bulunur. Bu alanları sayı tipinde saklamak, baştaki sıfırların kaybolmasına yol açar.
Hatalı kayıt ne olmalı: engelle, uyar, işaretle
Her hatalı değer kaydı engellemek zorunda değildir. Üç ayrı davranış vardır ve hangisinin kullanılacağı alanın işe etkisine göre seçilir.
- Engelle. Sağlama basamağı tutmayan VKN, TCKN veya IBAN kaydedilmez. Bu değerler matematiksel olarak geçersizdir; kaydetmek hiçbir işe yaramaz, yalnızca hatayı ileri taşır.
- Uyar ama kaydet. Alan boş bırakılmışsa ya da dış servis o an yanıt vermiyorsa kayıt açılır, alan eksik olarak işaretlenir. Satışın durmaması gerekir; eksiklik belge kesme anında engele dönüşür.
- İşaretle ve listeye al. Dış servis numaranın geçerli ama unvanın farklı olduğunu söylüyorsa kayıt doğrulanmadı durumunda kalır ve bir kontrol listesine düşer. Bu liste veri kalitesi işinin somut çıktısıdır.
İkinci ve üçüncü davranış için kayıtta bir alan daha gerekir: doğrulama durumu ve son doğrulama tarihi. Bu iki alan olmadan hangi müşterinin numarasının kontrol edildiği bilinemez, her belge kesiminde yeniden sorulur.
Toplu yükleme ve entegrasyon tarafı
Doğrulama en çok toplu veri yüklemede ve dış sistemlerden gelen kayıtlarda işe yarar. Burada kural şudur: doğrulama yüklemenin tamamını reddetmek için değil, hatalı satırları ayırmak için kullanılır. Yükleme sonunda iki liste çıkar, geçenler ve geçmeyenler; geçmeyenler hangi alanda hangi kontrolün başarısız olduğunu satır numarasıyla gösterir.
Dış sistemden gelen kayıtlarda bir ayrıntı daha var. Gelen numara geçersizse kaydı sessizce atlamak, farkın hiç görülmemesine yol açar. Doğru davranış kaydı karantinaya almak: veri gelmiştir, saklanmıştır, ama müşteri kartı olarak kullanıma açılmamıştır. Böylece hem veri kaybı olmaz hem hatalı numara faturaya gitmez.
Özet
Biçim kontrolü ucuzdur, her zaman ve her girişte yapılır; gerçeklik kontrolü pahalıdır, belge kesme anında ve arka planda yapılır. Alanlar normalleştirilmiş biçimde, metin tipinde saklanır. Geçersiz sağlama basamağı engellenir, eksik veri uyarı üretir, uyuşmayan unvan listeye düşer. Doğrulama kodu tek yerde yazılır ve ekran, API ile toplu yükleme aynı kodu kullanır.
KAV Yazılım, cari kart ve belge tarafını birbirine bağlayan entegrasyonlarda bu kontrolleri tek noktada kurar; veri kalitesi sonradan temizlenen bir iş değil, giriş anında kurulan bir düzendir.
Sık sorulan sorular
Sağlama basamağı doğru olan bir VKN gerçekten var demek mi?
VKN ve TCKN alanları veritabanında sayı olarak mı saklanmalı?
IBAN boşluklu mu saklanmalı?
Dış doğrulama servisi yanıt vermezse müşteri kaydı açılmasın mı?
Toplu yüklemede bir satır geçersizse tüm dosya reddedilmeli mi?
- cari hesap
- entegrasyon
- veri doğrulama
- veri kalitesi
- veri modeli
