Bir sigorta acentesi yazılımında tarih, en çok kullanılan veri türlerinden biridir. Poliçe başlangıç ve bitiş tarihleri, teklif geçerlilik süreleri, taksit vade tarihleri, yenileme hatırlatmaları ve raporlama dönemleri tarih bilgisine dayanır. Tarih ve saat hesapları basit görünse de yazılım geliştirmenin en sık hata üreten alanlarından biridir. Bir günlük kayma, bir müşteriye yanlış günde hatırlatma gönderilmesine, bir poliçenin raporda yanlış ayda görünmesine ya da bir teklifin süresi dolmadan geçersiz sayılmasına yol açabilir. Bu yazıda acente yazılımlarında sık görülen tarih tuzaklarını ve bunlardan kaçınma yollarını ele alıyoruz.
Tarih ile zaman damgası aynı şey değildir
İlk ve en temel ayrım, yalnızca tarih içeren bilgiler ile belirli bir anı gösteren zaman damgaları arasındadır. Bir poliçenin bitiş tarihi iş açısından bir takvim günüdür; bir kullanıcının sisteme giriş yaptığı an ise saat ve dakikasıyla birlikte belirli bir andır. Bu iki bilgi aynı türde saklandığında sorunlar başlar. Örneğin yalnızca tarih olması gereken bir alan, gece yarısı saatine sahip bir zaman damgası olarak saklanırsa ve sistem bu değeri farklı bir saat dilimine çevirirse, tarih bir gün geriye kayabilir. Bu nedenle veri modelinde iş tarihleri için yalnızca tarih tutan alanlar, olaylar için ise saat dilimi bilgisiyle birlikte zaman damgası kullanılmalıdır.
Saat dilimi tutarlılığı
Bir acente yazılımının bileşenleri farklı saat dilimi ayarlarıyla çalışabilir: Veritabanı sunucusu, uygulama sunucusu, zamanlanmış görevleri çalıştıran servis ve kullanıcının tarayıcısı ya da mobil cihazı. Bu bileşenlerden biri farklı bir varsayılan saat dilimiyle çalıştığında, aynı an farklı yerlerde farklı tarih olarak görünebilir. Bunu önlemenin yaygın yolu, zaman damgalarının sistem içinde tek bir standart saat diliminde saklanması ve yalnızca kullanıcıya gösterilirken yerel saate çevrilmesidir. Sunucuların ve veritabanının saat dilimi ayarları da açıkça yapılandırılmalı, varsayılana bırakılmamalıdır.
Gün sınırı: Bitiş tarihi dahil mi?
Poliçe bitiş tarihleriyle ilgili en sık karışıklık, bitiş gününün kapsama dahil olup olmadığıdır. Poliçelerin başlangıç ve bitiş saatleri ilgili sigorta şirketinin ve branşın koşullarına göre belirlenir; yazılım bu bilgiyi kendi varsayımıyla değiştirmemelidir. Sigorta şirketinden veya entegrasyondan gelen başlangıç ve bitiş bilgileri, saat bilgisi varsa saatiyle birlikte olduğu gibi saklanmalı, ekranda da bu şekilde gösterilmelidir. Yazılımın kendi hesapladığı süreler, örneğin "bitişe kalan gün" gibi göstergeler için ise hesaplama kuralı açıkça tanımlanmalı ve tüm ekranlarda aynı kural kullanılmalıdır.
Ay sonu ve artık yıl
Tarihe ay veya yıl eklemek de tuzak içerir. Ayın son gününe bir ay eklendiğinde sonuç, hedef ayın gün sayısına göre farklı davranabilir. Şubat ayının son günlerinde başlayan bir poliçe için bir yıl sonrasının hesaplanması, artık yıllarda beklenmedik sonuçlar verebilir. Taksit planları oluşturulurken her ayın aynı gününe vade koymak, kısa aylarda sorun çıkarır. Bu hesaplamalar için dilin veya çatının sağladığı güvenilir tarih kütüphaneleri kullanılmalı, elle gün ekleyerek hesap yapılmamalıdır. Bu tür uç durumlar mutlaka otomatik testlerle güvence altına alınmalıdır.
Zamanlanmış görevler ve hatırlatmalar
Yenileme hatırlatmaları ve taksit bildirimleri genellikle her gün belirli bir saatte çalışan zamanlanmış görevlerle oluşturulur. Bu görevlerde iki yaygın hata görülür. Birincisi, görevin çalıştığı sunucunun saat diliminin farklı olması nedeniyle hatırlatmanın beklenenden farklı bir saatte, hatta farklı bir günde gönderilmesidir. İkincisi ise görevin bir gün çalışmaması durumunda o günün hatırlatmalarının tamamen atlanmasıdır. Zamanlanmış görevlerin "bugün" yerine "son başarılı çalışmadan bu yana" mantığıyla çalışması ve aynı hatırlatmanın iki kez gönderilmesini önleyen bir kontrol içermesi, bu riskleri azaltır.
Tarih biçimleri ve kullanıcı girişi
Kullanıcıların tarih girdiği alanlarda biçim belirsizliği hatalara yol açar. Gün ve ay sırasının farklı yorumlanması, özellikle ayın ilk günlerinde fark edilmeden yanlış kayıt oluşturabilir. Tarih alanlarında takvim seçici kullanılması, yazılan tarihin kullanıcıya açık biçimde gösterilmesi ve sistem içinde standart bir biçimle saklanması bu belirsizliği ortadan kaldırır. Dışa aktarılan raporlarda ve entegrasyonlarda da tarih biçimi açıkça belirtilmeli, uluslararası standart biçimler tercih edilmelidir.
Entegrasyonlardan gelen tarihler
Sigorta şirketi entegrasyonlarından gelen tarih bilgileri farklı biçimlerde ve bazen saat dilimi bilgisi olmadan gelebilir. Her entegrasyon için gelen tarihin nasıl yorumlanacağı belgelenmeli, dönüşüm tek bir yerde yapılmalı ve dönüşümün doğruluğu örnek verilerle test edilmelidir. Bir entegrasyondaki tarih yorumunun değişmesi, yalnızca o entegrasyondan gelen poliçelerin bitiş tarihlerini etkileyebileceği için bu tür hatalar fark edilmesi zor hatalardır.
Test stratejisi
Tarih hatalarının önemli bir kısmı yalnızca belirli günlerde ortaya çıkar: Ay sonları, yıl dönümleri, artık yıllar ve gece yarısına yakın saatler. Bu nedenle testlerde sistem saatinin kontrol edilebilmesi, yani testin "bugün" değerini belirleyebilmesi önemlidir. Kodun doğrudan sistem saatini okumak yerine bir saat servisi üzerinden çalışması, testlerde farklı tarihlerin kolayca denenmesini sağlar. Kritik tarih hesapları için uç durumları kapsayan bir test listesi oluşturulmalı ve her değişiklikte bu testler çalıştırılmalıdır.
Acente açısından etkisi
Tarih hataları teknik görünse de sonuçları doğrudan müşteriye yansır. Yanlış günde gönderilen bir yenileme hatırlatması, yanlış ayda görünen bir poliçe veya süresi yanlış hesaplanmış bir teklif, hem müşteri deneyimini hem de acentenin raporlarına duyduğu güveni etkiler. InsureHub, sigorta acentelerine yazılım sağlayan bir platform olarak poliçe tarihlerini entegrasyondan geldiği haliyle saklamayı, zaman damgalarını tutarlı bir saat dilimiyle yönetmeyi ve tarih hesaplarını otomatik testlerle doğrulamayı geliştirme sürecinin bir parçası olarak ele alır.
Sonuç
Tarih ve saat hesapları, acente yazılımlarında küçük görünen ama etkisi büyük hataların kaynağıdır. Tarih ile zaman damgasını ayırmak, saat dilimini tutarlı yönetmek, gün sınırlarını açıkça tanımlamak, güvenilir kütüphaneler kullanmak, zamanlanmış görevleri dayanıklı kurmak ve uç durumları test etmek bu hataların çoğunu önler. Acente yazılımının poliçe ve yenileme takibini nasıl yönettiğini görmek için demo talep sayfasından bize ulaşabilirsiniz.