Navision’ı Türkiye’de Kurmak: KDV Oranını Girmek Yerelleştirme Değildir

Denizli’deki bir tekstil fabrikasında muhasebeci olarak çalışan Ahmet Bey’i düşünün. 2001 yılının başında fabrika sahibi ona şunu söyledi: ‘Navision alıyoruz, stok, fatura, muhasebe hepsini bu programda tutacağız.’ Ahmet Bey tek bir soru sordu: ‘Bu program Türkiye’de nasıl çalışacak?’ O soru o gün yanıtsız kaldı. Firma yaklaşık 168 çalışanıyla iplik ve kumaş üretiyordu; ürünlerin bir kısmı yurt dışına gidiyordu, kalan kısmı iç piyasaya. Muhasebesi karmaşıktı: farklı KDV oranları, stopaj kesintileri, ay sonunda kapatılması gereken hesaplar ve her satış için sıralı fatura numarası. Navision bu karmaşıklığı çözebilirdi — ama ancak doğru kurulursa. Yanlış kurulursa, kağıt defterden bile daha tehlikeli bir düzensizlik yaratırdı. Bu yazıda o farkı anlatacağım. Navision’ı Türkiye için yerelleştirmek, KDV oranını girmekten ibaret değildir; Türk Tek Düzen Hesap Planı’nı ve Vergi Usul Kanunu’nun fatura düzeni kurallarını programın çekirdeğine yerleştirmeden kurulan sistem güvenilmez hale gelir. Bu bir tercih meselesi değil; teknik bir zorunluluktur.Önce şunu anlamak gerekiyor: Navision, Hollandalı bir yazılım firmasının geliştirdiği bir muhasebe ve stok programıdır. Kuzey Avrupa muhasebe mantığına göre tasarlanmıştır. Stok takibini, satış faturalarını ve genel muhasebe kayıtlarını birbirine bağlayan bir yapısı vardır. Bu yapı iyi kurulduğunda çok işe yarar; muhasebeci her satışı ayrı ayrı deftere yazmak zorunda kalmaz, program ilişkileri otomatik kurar. Ancak programın içindeki hesap planı — yani her gelir ve giderin kayıt altına alındığı numaralı liste — Türkiye’ye özgü değildir. Türkiye’de devlet, tüm firmaların Tek Düzen Hesap Planı’nı (TDHP) kullanmasını zorunlu kılmaktadır. Bu plan, 1 ile 9 arasında numaralandırılmış hesap gruplarından oluşur ve Vergi Usul Kanunu’na (VUK — devletin muhasebe tutma kurallarını belirleyen temel yasa) dayanır. Navision’ın orijinal hesap planı bu yapıya uymaz. Dolayısıyla programı kurmadan önce bu planı baştan yazmak zorundasınızdır. Bu adımı atlayan her proje, ilerleyen aylarda muhasebe raporlarının vergi dairesine verilecek beyannamelerle eşleşmediğini fark eder ve büyük bir düzeltme dönemi başlar.İkinci büyük sorun KDV’nin hesaplanma ve takip edilme biçimidir. Türkiye’de KDV (Katma Değer Vergisi) her ay beyan edilir. Aylık dönemde kesilen ve ödenen KDV’lerin doğru tarihlerle kayıtlara geçmesi şarttır. Navision’ın orijinal yapısında KDV mantığı farklı çalışır; bazı sürümlerde vergi dönemleri aylık değil üç aylık kurgulanmıştır. Bunu Türkiye koşullarına uyarlamak gerekir. Bunun yanı sıra Türkiye’de bazı ödemelerde stopaj (belirli ücret, kira veya hizmet ödemelerinden kesilen vergi) uygulanır ve bu kesintilerin muhasebede ayrı hesaplara işlenmesi zorunludur. Navision bu hesapları varsayılan olarak oluşturmaz. Denizli’deki tekstil firmasında ilk üç ayda stopaj hesaplarının TDHP’ye uygun olarak kurulmaması yüzünden yıl sonu beyannameleri için ek düzeltme yapılmak zorunda kalındı. Bu düzeltme hem zaman hem de ek danışmanlık maliyeti demekti. Eğer bu ayrıntılar kurulum aşamasında konuşulsaydı, sorun hiç doğmazdı.Üçüncü sorun, fatura seri numarası ve belge düzenidir. Türkiye’de bir satış faturasının seri numarası (önceden matbu, sıralı ve tutarlı) VUK’a göre düzenlenmelidir. Bir numarayı atlamak veya sıra dışı kullanmak vergi incelemesinde sorun yaratır. Navision’da fatura numaralandırma sistemi ayarlanabilir bir yapıya sahiptir, ama Türk mevzuatına uygun olarak ayarlamak için ayrıca zaman ayrılması gerekir. Bunun yanı sıra bazı işlemlerde programın ürettiği çıktılar (basılı faturalar ve irsaliyeler) Türk vergi formalarının görsel düzeniyle eşleşmez. Bu görsel uyum da ayrıca düzenlenmelidir. Denizli’deki firmada satın alma departmanı ilk birkaç haftada programdan aldıkları irsaliyelerin taşıma şoförlerine göstermek için yeterli olmadığını fark etti — çünkü formdaki alanlar Türk gümrük ve nakliye mevzuatının gerektirdiği bilgileri içermiyordu. Bu küçük gibi görünen sorun, günlük operasyonu fiilen durdurabilirdi.Veri aktarımı ve eleman alışkanlıkları da göz ardı edilemez. Firma eski bir yerel muhasebe programından Navision’a geçiyordu. Eski programdaki veriler — bakiyeler, açık faturalar, stok miktarları — yeni sisteme taşınmalıydı. Bu aktarım için ODBC bağlantısı (iki farklı programın birbirinden veri okumasını sağlayan teknik bir köprü) kullanıldı. Ancak eski programdaki cari hesap kodları Navision’ın beklediği formata uymadığından birkaç yüz satır veriyi elle düzeltmek gerekti. Bu süreç projenin en çok zaman alan kısmı oldu; kimse başta planlamıştı. Teknik aktarımın yanı sıra muhasebe elemanlarının programa alışması 9 haftadan fazla sürdü. 2001 yılında Türkiye’deki pek çok muhasebeci elle veya daha basit yerel yazılımlarla çalışıyordu. Navision’ın menü yapısı ve çalışma mantığı onlar için yeniydi. Eğitim olmadan kullanım hataları kaçınılmazdı ve bazı hatalar sonradan düzeltilmesi çok zor kayıtlara yol açıyordu. Eğitim süresi bütçeye katılmamıştı; ama bu süre danışmanlık saatini doğrudan artırdı.Bütün bu zorlukların farkında olmak önemlidir, ama bir de gerçekçi sınır koymak gerekir. 2001 yılında Türkiye’de Navision’ı gerçek anlamda yerelleştirebilen, yani Türk vergi mevzuatını derinlemesine bilen ve aynı zamanda programın teknik altyapısını anlayan kişi sayısı son derece azdı. Bu uzmanlığa sahip distribütörler (programı satan ve kuran yetkili şirketler) çok azdı. Bazı firmalar bu nedenle yarı yerelleştirilmiş bir yapıyla çalışmak zorunda kaldı. Örneğin B formu — belirli dönemlerde vergi dairesine verilen alış ve satış bildirimi — bazı firmalarda programdan otomatik alınamadığı için hâlâ elle dolduruluyordu. Yıl sonu envanter sayımı programın dışında kağıda yapılıp sonradan elle giriliyordu. Bu eksiklikler programın temel değerini yok etmiyordu; fatura ve stok takibi yine de elle tutulandan çok daha düzenli yürüyordu. Ama başlangıçtaki vaatlerle gerçek arasında belirgin bir mesafe kalıyordu. Bunu önceden konuşmak, müşteriyi hayal kırıklığından koruyan tek yoldur.Navision kurmayı düşünen ya da kurulumunu denetleyecek olan bir yöneticiye şunu söylerim: önce üç somut soruyu sorun, imzalamadan önce. Distribütör Türk Tek Düzen Hesap Planı’nı bu programda daha önce kurdu mu ve referans verebilir mi? KDV beyan dönemleri, stopaj hesapları ve fatura seri numarası takibi için somut, çalışan bir demo gösterebilir mi? Eğitim maliyeti ve veri aktarım süreci ayrıca fiyatlandırıldı mı, yoksa ‘kurulum ücretine dahil’ deyip geçiyor mu? Bu üç soruya tatmin edici yanıt geliyorsa görüşmeye devam edin; gelmiyorsa başka bir referans firmayı yerinde ziyaret edin. Denizli’deki Ahmet Bey, kurulumun üzerinden 9 hafta geçtikten sonra programı artık gerçekten kullanabiliyordu — ama bu 9 hafta ve beklenmedik ek maliyetler baştan planlanmış değildi. Program iyiydi; sorun programda değildi. Sorun, yerelleştirmenin ne anlama geldiğini baştan net konuşmamaktı.