E-Pin Satış Sistemi Kurulumunda Zaman Dilimi ve Para Birimi Ayarını Yanlış Yapan Herkes Aynı Sessiz Parayı Kaybediyor: İşte Kimsenin Anlatmadığı Ayar Sırası

Çoğu kişi e-pin satış sistemi kurulumunun en kritik adımının ödeme geçidi entegrasyonu olduğunu sanır. Oysa sahada onlarca bayinin defterini açtığında karşına çıkan tablo tamamen farklı: para sızıntısının büyük kısmı, kurulumun ilk on dakikasında hızlıca geçiştirilen iki kutucuktan doğuyor. Zaman dilimi ve para birimi. İkisi de "sonra hallederiz" diye atlanır, ikisi de aylar sonra faturayı kesmeye gelir.

Bunu ilk kez fark ettiğin an genelde şudur: gün sonu raporu ile ödeme sağlayıcının ekstresi tutmaz, kampanya gece yarısı bitmesi gerekirken üç saat erken kapanır, ya da müşteri 149 TL'ye aldığı kodun faturasında 152 TL görür. Sen kodunu, stoğunu, panelini suçlarsın. Aslında sistem tam olarak ona söylediğin şeyi yapmaktadır. Bu yazıda, bir e-pin scripti kurarken zaman ve para eksenini nasıl tek bir doğruluk kaynağına bağlayacağını, hangi ayarın hangisinden önce yapılması gerektiğini ve Pinova gibi lisanslı bir e-pin satış yazılımı üzerinde bu mimarinin nasıl kurulduğunu adım adım açıyorum.

Zaman dilimini "görüntü ayarı" sanmak neden bu kadar pahalı?

Zaman dilimi bir görüntü tercihi değil, bir veri sözleşmesidir. Bir siparişin ne zaman oluştuğu bilgisi; kampanya geçerliliği, iade süresi, stok rezervasyon ömrü, cron ile çalışan otomatik teslimat kuyruğu ve muhasebe dönemi kapanışı gibi birbirinden bağımsız beş mekanizma tarafından okunur. Bu beş mekanizma farklı saat referansları kullanıyorsa, sistem kendi içinde çelişir.

Klasik senaryo şu: sunucu saati UTC, veritabanı oturumu sunucudan miras alıyor, uygulama katmanında ise Europe/Istanbul tanımlı. Panelde sipariş 14:20 görünür, veritabanında 11:20 yazar. Sen "bugünün satışları" sorgusunu veritabanı tarihine göre çalıştırdığın an, gece 21:00'dan sonraki tüm satışlar bir sonraki güne kayar. Ay sonunda o üç saatlik dilim, kapanan dönemin dışında kalır ve rakamların bir daha asla tutmaz.

Doğru kurgu şudur: depolama her zaman UTC, sunum her zaman yerel. Veritabanına yazılan her damga tek ve tartışmasız biçimde UTC olur; kullanıcıya, rapora ve e-postaya giden her tarih sunum anında yerel saate dönüştürülür. Bu ilkeyi bir kez oturtursan, yarın yurt dışına bayi açsan bile hiçbir şeyi bozmadan ilerlersin.

Kurulum sırasında hangi ayar hangisinden önce gelir?

Sıralama önemlidir, çünkü sonraki adımlar öncekinin varsayımını miras alır. Yaygın hata, ürünleri ve fiyatları girdikten sonra para birimi ayarına dokunmaktır. O noktada veritabanında zaten bir para birimi varsayımıyla yazılmış yüzlerce satır vardır ve geriye dönük dönüşüm neredeyse her zaman kayıplı olur.

İşleyen sıra şöyle: önce sunucu ve veritabanı saatini UTC'ye sabitle. Sonra dijital ürün satış scripti tarafında görüntüleme zaman dilimini Europe/Istanbul olarak tanımla. Ardından temel para birimini seç ve bunu bir daha değiştirmeyeceğin bir karar gibi ele al. Sonra ek para birimlerini, kur kaynağını ve yuvarlama politikasını ekle. En son ürünleri, paketleri ve kampanyaları gir. Cron görevlerini ise tüm bunlar bittikten sonra kur, çünkü cron kendi saatiyle çalışır ve uygulamanın varsayımını bilmez.

Temel para birimi kararı gerçekte neyi belirliyor?

Temel para birimi, sistemin muhasebe dilidir. Tüm kâr hesabı, bayi bakiyesi, komisyon ve iade bu birim üzerinden yürür. Türkiye'de satış yapıyorsan ve tahsilatın büyük kısmı TL ise temel birimin TL olmalıdır. Tedarikçin sana dolar ya da euro üzerinden kesiyorsa, bu bir temel birim sorunu değil, bir maliyet dönüşümü sorunudur ve çözümü ayrı bir alanda tutulan alış kuru kaydıdır.

Burada sıkça görülen tuzak, tedarikçi para birimini temel birim yapmaktır. Bunu yaptığın anda müşteriye gösterdiğin her fiyat anlık kura bağlı hale gelir; sepete atılan ürünün fiyatı ödeme adımında değişir, terk oranı yükselir ve iade taleplerinde kur farkı tartışması başlar. Doğru yaklaşım, satış fiyatını temel birimde sabitlemek, maliyeti ayrı tutmak ve marjı periyodik olarak yeniden hesaplamaktır. İyi bir epin yazılım altyapısı bu iki ekseni birbirine karıştırmadan saklar.

Ek para birimi göstermek istiyorsan bunu bilgilendirici bir dönüşüm olarak sun ve tahsilatı hangi birimde yaptığını açıkça yaz. Böylece hem kullanıcı beklentisini yönetmiş olursun hem de ödeme sağlayıcının ekstresiyle mutabakatın tek satırda çözülür.

Yuvarlama politikası sessiz kâr sızıntısını nasıl açıyor?

Kur dönüşümünde ortaya çıkan kuruş artıkları tek satışta önemsiz görünür. Günde dört yüz işlem yapan bir panelde aynı artık, ayda kayda değer bir tutara ulaşır. Kritik olan yuvarlamanın nerede yapıldığıdır: kalem bazında mı, sepet toplamında mı, yoksa ödeme isteğinde mi? Üç yerde farklı davranırsan ödeme sağlayıcıya gönderdiğin tutar ile kendi kaydın arasında birkaç kuruşluk fark oluşur ve bazı geçitler bu farkı doğrulama hatası olarak reddeder.

Politikayı tek bir yerde tanımla, tek bir yerde uygula. Fiyatları psikolojik eşiklere oturtmak istiyorsan bunu dönüşüm sonrası otomatik yuvarlama ile değil, doğrudan satış fiyatı olarak gir. Dönüşümü yalnızca bilgilendirme amaçlı alanlarda kullan. Ayrıca kurları geçmişe dönük kayıtla sakla; bir siparişin hangi kurla oluştuğunu altı ay sonra kanıtlayamıyorsan iade ve itiraz süreçlerinde savunmasız kalırsın.

Kurulum sonrası neyi test etmeden canlıya çıkmamalısın?

Ayarları yapmak yeterli değil; davranışı görmek gerekir. En verimli yöntem, gerçek bir senaryoyu uçtan uca tetiklemek. Gece 23:45'te biten bir kampanya oluştur, 23:50'de sipariş dene. Kampanya kapandıysa saat ekseni doğrudur. Küçük tutarlı bir gerçek ödeme al, ödeme sağlayıcı panelindeki tutarı kendi kaydınla karşılaştır. Kuruş farkı varsa yuvarlama politikan üç yerde farklı çalışıyor.

Ardından haftalık raporu iki yöntemle çıkar: bir kez uygulama üzerinden, bir kez doğrudan veritabanından. İki rakam eşit olmalı. Eşit değilse sorgunun okuduğu tarih alanı ile sunum katmanının dönüştürdüğü alan aynı değil demektir. Bu kontrolü yapmadan reklam harcamasına başlamak, ölçemediğin bir kanala para dökmek anlamına gelir.

Bu ayarların hepsini tek panelden yönetmek mümkün mü?

Mümkün, ama yazılımın bu ayrımı mimari düzeyde yapmış olması gerekir. Pinova'da zaman ekseni ile para ekseni birbirinden bağımsız iki yapılandırma alanı olarak tutulur: depolama UTC sabittir, sunum zaman dilimi tek yerden değişir, temel para birimi kilitlenir, ek birimler ve kur kaynağı ayrı tanımlanır, yuvarlama politikası merkezi bir kural olarak uygulanır. Böylece ölçek büyüdüğünde her yeni ödeme geçidi veya bayi kanalı aynı sözleşmeyi miras alır.

Kendi geliştirdiğin veya ucuz bir e-pin satış scripti ile yola çıktıysan, bu ayrımın olup olmadığını anlamanın en hızlı yolu tek bir soruyu sormaktır: aynı siparişin tarihini iki farklı ekranda karşılaştırdığında fark çıkıyor mu? Çıkıyorsa mimari tek kaynaklı değil ve ölçek büyüdükçe sorun katlanır. Özellik listesini incelerken bu iki ekseni ayrı ayrı yönetip yönetemediğine bakmayı alışkanlık haline getir.

Zaman dilimi ve para birimi, kurulumun en sıkıcı ama en kalıcı iki kararıdır. Doğru kurulduğunda bir daha hiç konuşulmaz; yanlış kurulduğunda her ay yeni bir tartışma çıkarır. Bu iki eksenin panelde nasıl ayrı ayrı yönetildiğini kendi gözünle görmek istersen canlı demo üzerinden ayar ekranlarını gez, ardından paket seçeneklerini karşılaştır.