E-Defter Finansal Raporlama Yazılımı ve Karşılaşılan Zorluklar Salih Bayar 1,2, M. Görkem Ülkar 1,3, S. Rıdvan Kuzu 1,3 1 İdea Teknoloji Çözümleri Ar-Ge Merkezi, İstanbul 2 Boğaziçi Üniversitesi, Bilgisayar Mühendisliği Bölümü, İstanbul 2 Boğaziçi Üniversitesi, Elektrik Elektronik Mühendisliği Bölümü, İstanbul salih.bayar @ideateknoloji.com.tr, gorkem.ulkar@ ideateknoloji.com.tr ridvan.kuzu@ ideateknoloji.com.tr Özet: E-Defter, Vergi Usül Kanunu'nda belirtilen işletmelerin (Ör. Yağ lisansına sahip firmalar ve bu firmalarla alışveriş yapan diğer firmalar) tutmak zorunda olduğu, dosya boyutları şirket büyüklüğüne göre değişen ama çoğunlukla çok büyük olan yevmiye ve defter-i kebir' lerin elektronik ortama aktarılması, düzenlenmesini ve doğrulanmasını sağlayan bir projedir. E-Defter projesindeki en büyük sıkıntı, dosya boyutlarının, çok büyük olması ve dolayısıyla bu defterleri işlemenin zorluğudur. Bu makalede, bu defterleri işlemede kullanılan teknolojiler (XML, XSLT, XPATH vb.), projenin arayüz tasarımı ve defter işlemedeki zorluklar ve yapılması gerekenler detaylı bir şekilde ele alınmıştır. Anahtar Sözcükler: E-Defter, XML, XSLT, XSD, HTML, Şematron Challenges in the Design of E-Ledger Financial Software Abstract: E-ledger is the whole of electronic records that cover information which is required to be included in books that shall be kept pursuant to Tax Procedural Law and/or Turkish Commercial Code notwithstanding formal provisions. Taxpayers that hold mineral oil license and ones that produce, construct or import tobacco, tobacco products, alcohol and taxpayers which have certain amounts of turnover among those purchasing product from them in 2011 calendar year are obliged to use e-ledger in 2014. The most challenging problem in the e- ledger project is the file size of both journal and ledger books. Since both files can be very large, it is difficult to handle these books efficiently. This article describes the technology used in processing these books (XML, XSLT, XPath and so on.), difficulties and interface design in detail. Keywords: E-Ledger, XML, XSLT, XSD, HTML, Schematron
1. Giriş E-Defter, işletmelerin tutmak zorunda olduğu yevmiye ve büyük defterlerin Gelir İdaresi Başkanlığınca (GİB) belirlenmiş olan Extensible Business Reporting Language (XBRL) formatında elektronik ortamda hazırlanması ve saklanmasını içeren düzenlemelerdir. E-Defter düzenlemesinin hem işletmeler hem de kontrollerin yapan düzenleyici birimler açısından birçok avantajı bulunmaktadır [1]. GİB onaylı VisionPlus e- Defter projesi ile hem gereken şartları sağlayan hem de işletmeler için kolay kullanımlı bir program tasarlanması amaçlanmıştır. Bu projenin birçok bileşenden oluşması hem geliştirme hem entegrasyon aşamalarında zorluklar doğurmuştur. Makalede VisionPlus e-defter uygulaması sistem yapısı ile zorluktanlardan seçilenler aktarılmıştır. 2. VisionPlus E-Defter Genel Yapı VisionPlus e-defter uygulaması GİB tarafından belirlenmiş istemler ile İdea Teknoloji Çözümleri elektronik finansal uygulamalar departmanı tarafından belirlenmiş ekstra istemler üzerine geliştirilmiştir. Ayrıca kullanıcılar açısından birçok avantajı olan mizan raporu sunabilme özelliği eklenmiştir. 2.1. E-Defter oluşturma adımları E-defter uygulaması Java diliyle yazılmış olup, kullanıcının yerelinde çalışması ve kolayca güncellenebilmesi adına Java Applet olarak sunulmuştur. Defter girdilerinin genelde büyük boyutlu olması dolayısıyla sunucuya aktarılmaları ve sunucuda işlenilmesinden kaçınılmıştır. Uygulama başlangıcında gerekli parametreler sunucudan yerele çekilir, işlem sonunda bir sonraki kullanım için önemli olan parametreler sunucuya aktarılır. Şekil 1. de kullanıcı ara yüzü VisionPlus e-defter uygulamasında gereken girdi işletmelerin kullanmış olduğu muhasebe programları çıktılarıdır. Çıktı olarak değişik yapıdaki dosyaların desteklenmesi, dolayısı ile birçok muhasebe defteri programına kolayca entegre olabilme projenin ana hedeflerinden biri olarak belirlenmiştir. Uygulamanın girdileri olan finansal veriler comma separated values (CSV) yapısında, tablo (.xls veya.xlst) yapısında, düz metin (.txt) veya her hangi bir yapıdaki XML dosyası biçiminde olabilir. Bu girdiler ilk olarak önceden belirlenmiş VisionPlus e- Defter XML yapısına çevirilir. Önişleme adı verilen bu aşama sonunda farklı formattaki girdiler anlaşılabilirliği üst düzeyde olan ve GİB nın istediği XBRL yapısı baz alınarak belirlenmiş olan VisionPlus XML yapısına dönüştürülür. Verilerden hem büyük defter hem de yevmiye defteri için XML dosyaları oluşturulur. Bu aşamadan sonra eğer gerekiyorsa XBRL defter çıktıları maksimum 200 MB olacak şekilde parçalanır. Bu aşama detaylı olarak bir sonraki başlıkta anlatılmaktadır. VisionPlus XML yapısındaki defter verileri XSLT dosyası aracılığı ile istenen XBRL yapısına dönüştürülür. Verilerin XSLT ile uygun alanlara eşlenmesi sonucunda oluşan XBRL dosyası kullanıcının arayüzden komutu üzerine dijital imza ile imzalanır. Daha sonraki aşamada hem yevmiye hem de büyük defter için defter oluşturma bilgisini içeren berat dosyaları oluşturulur. Berat dosyaları da imzalanır, defterler ile birlikte yapısal ve anlamsal kontrole girer. En son aşama kullanıcının kontrolden geçmiş berat dosyalarını web service aracılığı ile GİB e aktarmasıdır. GİB in onayladığı ve imzaladığı beratlar VisionPlus veritabanında saklanır. Onaylı berat ile kullanıcının o aydaki işlemini tamamladığı anlaşılır. 2.2. Mizan oluşturma adımları Mizan aylık ve finansal dönemin başlangıcından itibaren hesapların finansal özetini sunan raporlardır [2]. Bu raporlar ile kullanıcılar kolay ve etkili bir şekilde hesaplarını izleyebilmekte ve defterlerin
muhasebe açısından anlamlı olup olmadığı kontrollerini yapabilmektedirler. Bir bakıma defter özeti olan mizan raporu ile işletmeler ana ve alt hesaplardaki borç-alacak durumlarını ve bakiyelerini yıllık ve aylık bazda takip edebilmektedir. Mizan raporu sunabilme özelliği GİB e-defter uyumu için zorunluluk olmamakla beraber VisionPlus e- Defter uygulamasına kullanıcıya sunduğu avantajları sebebiyle dahil edilmiştir. İlk olarak güncel ayın büyük defterinden mizan için gereken ana ve alt hesap bilgileri tutarları ile birlikte çekilerek uygun veri yapısı ile hafızada tutulur [2]. Burada yıllık döneme ait kümülatif değerler yerine de güncel ayın bakiye ve tutar bilgileri yazılır. Şekil 1. Vision Plus E-Defter Kullanıcı Ara Yüzü Uygulama bir sonraki adımda kullanıcı bilgisayarında XML yapısında tutulan bir önceki aya ait mizan raporunu bulmaya çalışır. Raporun bulunmadığı takdirde sunucudan kullanıcıya ait mizan raporu ister. Sunucuda da bulunmaması halinde mizan ilk parça olarak düşünülerek uygun yerel dosya altına XML olarak kaydedilir ve sunucuya gönderilir. Eğer bir önceki mizan varsa hesapların kümülatif değerleri bir önceki mizanın kümülatif değerleri ile toplanarak güncellenir ve tekrar XML olarak kaydedilir. XML formatındaki mizan raporunun görüntülenmesi için XSLT, CSS ve JavaScript kullanılmıştır [2]. 3. E-Defter Zorluklar VisionPlus e-defter birçok farklı bileşenden oluşmaktadır. Java ve.net web teknolojilerinin birlikte kullanılması, işlenecek dokümanların XML ve CSV gibi farklı formatlarda olması, bu dokümanların manuel ya da çeşitli entegrasyon servisleri aracılığı ile ERP uygulamalarından alınabiliyor olması, ayrıca üretilecek çıktıların XBRL formatında kriptografik olarak seri imzalar aracılığı ile değişmezliğinin garanti altına alınması, veri değişmezliğini kontrol edecek doğrulama araçlarına ihtiyaç duyulması gibi bir çok farklı yaklaşımın bir arada olması ile entegre bir çözüm özelliği taşımaktadır. Bu modüler çeşitliliğin ve entegrasyonunun farklı
adımlarında karşılaşılan zorluklar aşağıda anlatılmıştır. 3.1- Defter parçalama GİB XBRL formatındaki defterlerin 200MB boyutunu aşmamasını istemektedir. Buna göre defterlerin parçalanması ve parçaların sırasıyla isimlendirilmesi gerekmektedir. E- Defter CSV den VisionPlus özel şablon XML e ve bu XML den XBRL e dönüştürülürken boyutu büyükmektedir. Defter verisinin 200 MB dan küçük XBRL formatında defter üretecek şekilde bölünmesi gerekmektedir. Yürütülen test çalışmaları sonucu 10 Mb lık CSV defter verisinin 25,2 MB lık VisionPlus XML dosyasına dönüştüğü, bu dosyanın da 97 MB a dönüştüğü görülmüştür [3]. Bu testlerin sonuçlarına göre bölütleme katsayısı belirlenip azami CSV boyutuna karar verilmiştir. CSV girdileri bu azami boyuta göre parçalara ayrılıp son aşamada oluşacak XBRL dosyasının 200 MB tan büyük olmaması garanti altına alınmaya çalışılmıştır. Defter bölütlemede karşılaşılan bir başka sorun da defter alanlarının sabit olmasına rağmen serbest metin alanlarının uzunluklarının firma bazında değişiklikler göstermesidir. Bu zorluğu aşmak için daha önce önerdiğimiz bildiride [3] de belirttiğimiz gibi üstsel ağırlıklı hareketli ortalama yöntemi ile bölütleme katsayısı firma bazında özellleştirilmiştir. Bu yöntemin XBRL maksimum sınırı olan 200 MB ı aşmamayı garanti etmektedir. Ancak bu yöntemde, parçalı defterlerin CSV boyutları aynı olmasına rağmen XBRL boyutları 160 MB ile 200 MB arasında sapma göstermiştir. Bu sapma araştırıldığında, aynı satır sayısına sahip iki defter parçasının farklı yevmiye sayılarına sahip olmasından kaynaklandığı görülmüştür. Her yevmiye maddesi için XBRL üretiminde standart bir başlık bilgisi eklendiği için, başlık boyutunun da sapmanın giderilmesi için hesaba katılması gerekliliği doğmuştur. Ağırlıklı hareketli ortalama yönteminin satır sayısı temelli hesapladığı bölütleme katsayısına, yevmiye başlık ortalama başlık boyutunun da dahil edilerek algoritmanın güncellenmesi ile bölütlenen defterler arasındaki boyut varyasyonu 7 MB a kadar indirilmiştir. 3.2- Parçalı defterlerde mizan üretimi Aylık defterler GİB'in belirlemiş olduğu 200 MB lık XBRL boyutuna uyma zorunluğundan bölündüğü gibi; kullanıcılar ay içerisinde belirli tarihler arasındaki kayıtları içeren defterleri yükleyebildiğinden isteğe bağlı olarak da parçalı defter oluşturulabilir. Örneğin kullanıcı sadece 1 Nisan ile 17 Nisan arası kayıtları içeren defter yükleyebilir. Eğer kullanıcı ay kapatılma seçeneğini arayüzden seçmediyse uygulama bu ayın devamında defter bekleyecektir. Bu süreç ileride detaylı anlatılmaktadır. Önceden bahsedildiği üzere önceki mizan raporları XML dosya olarak kullanıcı yerelinde tutulmaktadır. Yerelde tutulacak dosyalarda vergi kimlik numarası ve ay bilgisi dosya adı içerisinde yer almaktadır. Önceki ay mizan raporunun kümülatif alanı ile güncel ayın bakiyeleri toplanarak güncel ayın kümülatif değerlerinin bulunması gerekmektedir. Ancak aynı ay içerisinde defter parçalanmış ise sadece kümülatif değerlerin değil aylık değerlerin de toplanması gerekmektedir. Ayrıca ay kapatılmamış defterler için dosya adına defter başlangıç ve bitiş tarihinin eklenmesine karar verilmiştir. Aylar arası kümülatif değerlerin toplanması için CumulateTBMap, aynı aydaki parçaları toplamak için CumulateTBMapinSameMonth metotları yazılmıştır.
3.3- Defter Döneminin Belirlenmesi Parçalı defterlerin dönem bilgisinin belirlenmesinde uyulması gereken çeşitli standartlar söz konusudur [4]. Bu standartlardan doğan zorunluluklar: a. Parçalı defterde ilk defter ayın ilk gününe dair bir yevmiye içermese de her zaman ayın birinden başlamalıdır. b. Birbirini takip eden defterlerden ikincisinin açılış tarihi ilkinin kapanış tarihine eşit ya da bir gün sonrası olmalıdır. i. Defter parçaları aynı güne ait veriler içeriyorsa ilkinin kapanış tarihi ile ikincisinin kapanış tarihi eşit olur. ii. İkinci defter ilk defterin kapanış tarihinden bir gün veya daha sonrasına ait veri ile başlıyorsa ikinci defterin başlangıç tarihi ilk defterin kapanışından bir gün sonrası olarak belirlenmelidir. c. Parçalı defterlerin sonuncusu dönem kapanışı yapılacaksa, ay sonuna ait yevmiye maddesi içermese dahi kapanış tarihi olarak ayın son gününe eşitlenmelidir. d. Parçalı defterlerin sonuncusu dönem kapanışı yapılmadıysa defter kapanış tarihi, mevcut yevmiyelerinin sonuncusunun tarihini eşit olur. Bu zorunlukların çözümü için aşağıdaki iş akış diyagramına göre yazılım geliştirilmiş ve diyalog pencereleri içeren kullanıcı ara yüzü tasarlanmıştır. dönemtarihi sondeftertarihi ilkyevmiyetarihi ilkyevmiyetarihi >= dönemtarihi ilkyevmiyetarihi = sondeftertarihi ilkyevmiyetarihi > sondeftertarihi Defter önceki parçalara ait tarihli yevmiye içeriyor, önceki parçalar ezilsin mi? dönemaçılıştarihi = dönemtarihi UYARI İlgili döneme ait işlem yapılamaz dönemaçılıştarihi = sondeftertarihi dönemaçılıştarihi = sondeftertarihi+1 Şekil 2. Defter Açılış Tarihi Belirleme AySonuTarihi SonYevmiyeTarihi SonYevmiyeTarihi = AySonuTarihi UYARI İlgili deftere ait işlem yapılamaz dönemkapanıştarihi = AySonuTarihi Dönem Kapatılsın mı? dönemkapanıştarihi = SonYevmiyeTarihi dönemkapanıştarihi = AySonuTarihi Şekil 3. Defter Kapanış Tarihi Belirleme
4. Sonuç Bu makalede Gelir İdaresi Başkanlığınca onaylanmış Vision Plus E-Defter uygulaması genel yapısı, mizan raporu oluşturma eklentisi ve bileşenlerin geliştirme ile entegrasyon adımlarında ortaya çıkan zorluklardan bazıları anlatılmıştır. E-Fatura süreci ile başlayan elektronik finansal uygulamalar alanındaki deneyimlerin bu çalışma ile devam etmesi ve sektörle paylaşılması 5. Kaynaklar [1] Pinsker, R, Li, S. (2008). Costs and benefits of XBRL adoption: Early evidence Communications of the ACM, 51(3), 47-50 [2] Pinsker R. (2003). XBRL awareness in auditing: a sleeping giant?. Managerial Auditing Journal 18(9), 732-736 [3] Ülkar, M. G., Bayar, S., (2014) E-Defter Uygulaması Kapsamında Çok Bileşenli Finansal Raporlama Yazılımı Geliştirme Deneyimleri., Ulusal Yazılım Mühendisliği Sempozyumu 2014, 796-801 [4] Ülkar, M. G., Bayar, S., (2014) E-Defter Mizan Raporu Uygulaması Geliştirme Deneyimleri., TBD 31. Ulusal Bilişim Kurultayı 2014, 65-70l [5] Gelir İdaresi Başkanlığı, (2014) e-defter Teknik Kılavuz, 11, http://edefter.gov.tr/dosya/e-defterpaketi.zip