Yazılımda Çoklu Para Birimi ve Kur Yönetimi Nasıl Kurulur

Birden fazla para biriminde çalışan bir işletmede yazılımın asıl işi kur çevirmek değil, her tutarın hangi para biriminde olduğunu ve hangi anın kuruyla sabitlendiğini kaydetmektir. Bu iki bilgi kaydın üstünde durmadığında raporlar birkaç ay içinde birbirini tutmaz ve sorun artık düzeltilemez, çünkü geçmişin kuru geri getirilemez.

Aşağıda para biriminin veri modelinde nasıl saklandığını, kurun hangi anda sabitlendiğini, yuvarlama kurallarını, kur kaynağının yönetimini ve kur farkını ele alıyoruz. Gerçek kur ya da oran değeri vermiyoruz; konu mekaniktir.

Her tutar para birimiyle birlikte saklanır

Temel tek bir kuralda özetlenir: bir tutar alanı asla tek başına durmaz, yanında hangi para biriminde olduğunu söyleyen bir alan bulunur. Veri modelinde "tutar" diye bir kolon değil, "tutar + para birimi" diye bir ikili vardır.

Bu kural ihlal edildiğinde tek bir tutar kolonuna kiminin dövizi, kiminin yerel para birimini yazdığı karışık bir veri kümesi oluşur. Böyle bir kolonda toplam almak anlamsızdır; daha kötüsü hangi satırın hangi birimde olduğu yalnızca hatırlanan bir bilgiye dönüşür ve kayıt başkasının eline geçtiğinde çözülemez. Benzer bir hata, para birimini belge başlığında tek bir yere yazıp satırların hepsini aynı birimde varsaymaktır.

Pratik model şöyledir: tanımlı para birimleri ayrı bir listede tutulur, her tutar alanı bu listeye bağlanır ve raporlama için ikinci bir karşılık alanı saklanır. Bu kararlar projenin başında alınır; tutar alanlarının yapısını sonradan değiştirmek geçmiş kayıtların tamamını yeniden yorumlamayı gerektirir.

Belge para birimi ile raporlama para birimi

Belge para birimi, o belgenin müşteriyle ya da tedarikçiyle anlaşılan birimidir; belgenin üzerinde yazan birim budur ve belge ömrü boyunca değişmez. Raporlama para birimi ise işletmenin kendi içinde her şeyi topladığı ve karar verdiği tek birimdir.

Doğru kurgu, her belgenin kendi biriminde saklanması ve raporlama birimine çevrilmiş karşılığının da kayda yazılmasıdır. Böylece iki soru birbirini bozmadan cevaplanır: müşteriye kaç döviz tutarında belge düzenlendi, işletme bu satıştan kendi biriminde ne elde etti? Üçüncü bir birim gerekirse doğru yol kolon çoğaltmak değil, saklanan kurlardan hesaplanabilir bir raporlama katmanı kurmaktır.

Kur hangi anda sabitlenir

Tasarımın en belirleyici sorusu budur ve cevabı yazılımın değil işletmenin kararıdır. Yazılımın görevi, seçilen kararı tutarlı uygulamak ve hangi anın kurunun kullanıldığını kayda yazmaktır.

Aynı işletme farklı akışlarda farklı tercih yapabilir: satışta sipariş anı, alışta tedarikçinin dayattığı an geçerli olabilir. Bu nedenle yazılım tek bir kuralı gömmek yerine akış bazında tanımlanabilir bir kural taşımalı ve "bu tutar hangi kurla oluştu" sorusunun cevabı her belgede görünmelidir.

İşlem anındaki kur kaydın üstüne yazılır

Bu, tasarımın en önemli tek maddesidir: kullanılan kur işlem anında belgenin üstüne yazılır, sonradan kur tablosundan hesaplanmak üzere bırakılmaz. Çünkü sonradan hesaplayan bir sistemde geçmiş belgeler değişken hâle gelir; bugün alınan bir rapor ile aynı raporun eski çıktısı farklı sayılar gösterir. Mutabakat yapılamaz ve kimse hangi sayının doğru olduğunu bilemez.

Kaydın üstünde en az şunlar durmalıdır: belge para birimi, kullanılan kur, kurun hangi tarih ve saate ait olduğu, kurun kaynağı ve raporlama birimine çevrilmiş karşılık tutar. Bu beş bilgi varsa belge kendi kendini açıklar ve yıllar sonra bile aynı sonucu verir.

Alış, satış ve çapraz kur

Tek bir "kur" alanı pek çok işletme için yetersizdir. Döviz alırken ve satarken uygulanan kurlar farklıdır; yazılımın hangi işlemde hangisini kullanacağı tanımlı olmalıdır ve bu seçim her akış için ayrı yazılır.

Çapraz kur, iki dövizin birbirine çevrilmesi gerektiğinde ortaya çıkar; çoğu kaynak dövizleri yerel para birimi karşısında yayımladığı için aradaki oran bunlardan hesaplanır. İki tuzak vardır: ara adımda yuvarlama yapılırsa hata büyür, bu yüzden yuvarlama yalnızca son adımda yapılır; çapraz kurun hangi iki kurdan üretildiği kaydedilmezse sonradan hesabın nasıl çıktığı gösterilemez.

Yuvarlama, hassasiyet ve kuruş farkları

Para hesaplarında kayan noktalı sayı tipleri kullanılmaz; ikili tabanda çalıştıkları için ondalık kesirleri birebir temsil edemez ve binlerce satırlık toplamlarda gözle görülür sapma üretirler. Para için ondalık tabanlı sabit hassasiyetli bir tip ya da en küçük birimi tam sayı olarak tutan bir yaklaşım kullanılır.

Hassasiyet tek bir seviyede tutulmaz. Birim fiyat, kur ve satır tutarı için gereken basamak sayısı farklıdır; kur genellikle fiyattan fazla basamak gerektirir. Her alanın hassasiyeti ayrı kararlaştırılır ve veri modelinde sabitlenir. Yuvarlamanın nerede yapıldığı da sonucu değiştirir; kural yazılı olmadığında aynı belgenin iki ekranında iki farklı toplam görünür.

• Satırların tek tek yuvarlanıp toplanması ile toplamın bir kez yuvarlanması farklı sonuç verir; biri seçilir ve her yerde aynı uygulanır.
• Ara hesaplarda yuvarlama yapılmaz; yuvarlama yalnızca gösterilen ve belgeye yazılan son adımda yapılır.
• Kuruş farklarının nerede birikeceği belirlenir: satır toplamı ile belge toplamı arasında kalan fark bir yere yazılmalıdır.
• Gösterim yuvarlaması ile hesap yuvarlaması ayrılır; ekranda iki basamak göstermek veritabanında iki basamak tutmak değildir.
• Taksitli ya da bölünmüş tutarlarda bölme artığının hangi parçaya eklendiği kural olarak yazılır.

Vergi ve iskonto hangi birim üzerinden hesaplanır

Doğru sıra, bütün ticari hesabın belge para biriminde yapılıp sonucun raporlama birimine çevrilmesidir: iskonto belge biriminde satır tutarına uygulanır, vergi matrahı belge biriminde oluşur, vergi orada hesaplanır ve çevirme ancak bu hesap tamamlandıktan sonra yapılır.

Tersi sıra iki sorun doğurur: müşteriye verilen belgedeki sayılarla sistemdeki sayılar tutmaz, ayrıca çevirme ve yuvarlama iki kez araya girdiği için kuruş farkları çoğalır. İskonto sırası da yazılı olmalıdır: satır iskontosu, belge iskontosu ve varsa kampanya indiriminin hangi sırayla ve hangi matrah üzerine uygulandığı tek bir kural olarak tanımlanır. Vergi mevzuatının kuralları mali danışmanla netleştirilir; yazılımın görevi belirlenen sırayı her ekranda aynı uygulamaktır.

Kur kaynağı ve kaynağa ulaşılamadığında

Kur, sistemde birden fazla yerden girilmemelidir. Tek bir kaynak tanımlanır, kurlar oradan alınıp kur tablosuna yazılır ve bütün modüller bu tablodan okur; iki ayrı yerden kur girilen sistemlerde iki modülün aynı belgeye farklı karşılık üretmesi kaçınılmazdır.

Kaynağa ulaşılamadığında ne yapılacağı da önceden kararlaştırılır, çünkü bu durum mutlaka yaşanır. Üç seçenek vardır: işlemi durdurmak, son bilinen kuru kullanmak ya da kullanıcıdan elle kur istemek. Pratikte en işler çözüm, son bilinen kuru kullanıp bunu kayda açıkça işlemektir.

• Kullanılan kurun hangi tarihe ait olduğu belgede görünür; güncel olmadığı saklanmaz.
• Kur kaynağı ve "güncel mi, son bilinen mi" bilgisi kayda yazılır.
• Kaynak erişilemez kaldığı süre bir eşiği geçtiğinde sorumluya uyarı gider.
• Kaynak geri geldiğinde geçmiş belgeler kendiliğinden güncellenmez; düzeltme ayrı bir kayıtla yapılır.
• Elle girilen kurlar işaretlenir ve kimin girdiği kaydedilir.

Kur farkı raporlarda ayrı görünür

Dövizli çalışan bir işletmede kârın bir kısmı ticari faaliyetten, bir kısmı kur hareketinden gelir. İkisi aynı satırda toplandığında satışın kârlı mı olduğu, yoksa kurun mu kazandırdığı anlaşılamaz.

Bu yüzden kur farkı ayrı bir kalem olarak gösterilir ve iki yerde doğar. Gerçekleşmiş fark, bir alacak ya da borç kapandığında işlem kuruyla tahsilat kuru arasındaki farktan oluşur. Gerçekleşmemiş fark ise açık bakiyelerin rapor tarihindeki kurla değerlenmesinden çıkar ve her gün farklı bir sayı verir. İkisinin ayrı gösterilmesi, açık bakiyelerden doğan dalgalanmanın gerçek kârla karışmasını önler. Ayrıca her kur farkı satırı kaynak belgeye bağlanabilmelidir; tek bir toplam olarak duran kur farkı doğrulanamaz.

Çok para birimli fiyat listeleri

Fiyat listeleri iki yoldan biriyle kurulur ve bu seçim güncelleme düzenini belirler. Birinci yol her para birimi için ayrı fiyat tutmaktır: liste sabittir ve müşteri için öngörülebilirdir, ama kur hareket ettiğinde elle güncellenmesi gerekir; güncellenmediğinde eski fiyattan satış yapılır. İkinci yol tek bir ana birimde fiyat tutup diğerlerini kurla hesaplamaktır: liste kendiliğinden güncel kalır, fakat müşteri fiyatı her gün değişir.

Hangi yol seçilirse şu noktalar kurala bağlanır: listenin hangi tarihten itibaren geçerli olduğu, güncellemenin bekleyen teklif ve siparişleri etkilemeyeceği, fiyat değişiminin kayıt izinin tutulacağı ve listeye bağlı iskontoların hangi birim üzerinden hesaplandığı. Özellikle ikincisi önemlidir: açık belgeler kendi sabitlenmiş fiyatını korumazsa müşteriye verilmiş bir teklif, kimse dokunmadan değişir.

Kısa kontrol listesi

• Her tutar alanının yanında para birimi bilgisi var mı; tek kolonda karışık birim duruyor mu?
• Belge para birimi ile raporlama para birimi ayrı mı tutuluyor?
• Kurun hangi anda sabitlendiği akış bazında yazılı mı?
• Kullanılan kur, tarihi ve kaynağı kaydın üstünde duruyor mu?
• Alış, satış ve çapraz kur ayrımı tanımlı mı; çapraz hesapta ara yuvarlama yapılıyor mu?
• Yuvarlamanın hangi adımda yapıldığı ve kuruş farkının nereye yazıldığı belirli mi?
• İskonto ve vergi belge para biriminde mi hesaplanıyor, çevirme en sonda mı yapılıyor?
• Kur tek bir kaynaktan mı alınıyor; kaynak erişilemediğinde ne yapılacağı yazılı mı?
• Gerçekleşmiş ve gerçekleşmemiş kur farkı raporlarda ayrı mı görünüyor?
• Fiyat listesi güncellemesi açık belgelerin fiyatını değiştiriyor mu?

KAV Yazılım, dövizli çalışan işletmeler için geliştirdiği özel yazılımlarda para birimi ve kur kurallarını veri modelinin başında tanımlar; geçmiş belgeler değişmez kalacak biçimde kurulur.