DOLAR
EURO
ALTIN
BIST
Adana Adıyaman Afyon Ağrı Aksaray Amasya Ankara Antalya Ardahan Artvin Aydın Balıkesir Bartın Batman Bayburt Bilecik Bingöl Bitlis Bolu Burdur Bursa Çanakkale Çankırı Çorum Denizli Diyarbakır Düzce Edirne Elazığ Erzincan Erzurum Eskişehir Gaziantep Giresun Gümüşhane Hakkari Hatay Iğdır Isparta İstanbul İzmir K.Maraş Karabük Karaman Kars Kastamonu Kayseri Kırıkkale Kırklareli Kırşehir Kilis Kocaeli Konya Kütahya Malatya Manisa Mardin Mersin Muğla Muş Nevşehir Niğde Ordu Osmaniye Rize Sakarya Samsun Siirt Sinop Sivas Şanlıurfa Şırnak Tekirdağ Tokat Trabzon Tunceli Uşak Van Yalova Yozgat Zonguldak
İstanbul 23°C
Az Bulutlu

E-Defter Bildirim Programı ve Elektronik Defterlerin Gelir İdaresi Başkanlığına Yüklenmesi

Mustafa Özbay Ekonomist-CFO
Mustafa ÖZBAY, 1972 yılında Trabzon ili Çaykara İlçesi Yeşilalan Köyünde doğdu. İlk öğrenimini Bursa, Orhangazi, Örnekköy İlkokulunda, Orta öğrenimini ise Orhangazi Lisesi’nde tamamladı. Uludağ Üniversitesi , İİBF, Maliye Bölümünden Ekonomist ünvanlıyla mezun oldu. Askerlik görevini 1997 Yılında Siirt-Eruh'ta Asteğmen rütbesiyle, operasyon tim komutanı olarak gerçekleştirdi. 1999 Yılında İstanbul’a yerleşti ve sektöründe öncü bir sanayi kuruluşunda muhasebe yardımcı elemanı olarak işe başladı. Bu firmada sırasıyla muhasebe uzmanı, muhasebe şefi, finans şefi, muhasebe müdürlüğü ve halen devam etmekte olduğu Mali İşlerden Sorumlu Genel Müdür Yardımcılığı görevlerinde bulundu. Meslekteki  tecrübesini ilk kez 2004 yılında yayınlanan ve büyük ilgi gören “Tüm Yönleriyle Uygulamalı İhracat Muhasebesi” kitabında  meslektaşlarıyla paylaştı. Özbay, evli ve Taha Utkan, Safa Ersan, Neşe Berrin adında üç çocuk sahibidir.

Bilindiği üzere, 3 No.lu Elektronik Defter Genel Tebliği ile birlikte gelen değişikliklerle beraber e-Defter dosyaları ile bunlara ilişkin berat dosyalarının ikincil kopyalarının özel entegratörlerin ya da Başkanlığın bilgi işlem sistemlerinde 01.01.2020 tarihinden itibaren asgari 10 yıl süre ile muhafaza edilmesi zorunluluğu getirilmiştir. Elektronik defterlerin görücüye çıkmasına çok az bir süre kaldığı şu günlerde henüz yeterlilik sağlayan Saklamacı Kuruluş bulunmadığından, ilk saklama zorunlu olarak Gelir İdaresi Başkanlığının sistemlerinde gerçekleşecektir.

Başkanlık tarafından elektronik defterlerin aktarımına ilişkin olarak E-defter Saklama Kullanıcı kılavuzu hazırlanmış olup aktarım süreci bu kılavuzda ayrıntılı olarak açıklanmıştır[1]. Kılavuz incelendiğinde aktarım sürecinde mükelleflerden E-Defter Bildirim Programı isimli bir programı kurmalarının istendiği görülmektedir. Bu yazımızda hem bu aktarım sürecini hem de bu aktarım programını hem hukuki hem de teknik boyutuyla ele alalım istedik. Teknik kısmı mümkün olduğunca açık olarak yazmaya çalıştım. Ancak işin hukuki boyutuyla daha çok ilgilenen okuyucuların bir sonraki başlığa atlayarak işin hukuki boyutuyla okumaya devam edebileceklerini hatırlatmadan geçmeyelim.

Yeterince Elektrik Alamadık

Eski yazılarıma denk gelmişseniz Başkanlığı yeni teknolojileri benimsememe konusunda eleştirdiğimi mutlaka görmüşsünüzdür. Buna karşın E-defter Bildirim Programında kullanılan Electron.js Framework’ünün beni bile şaşırttığını bilmenizi isterim. Bu teknolojiyle yapılan uygulamalara Whatsapp masaüstü uygulamasını örnek gösterebiliriz[2]. Oldukça popüler bu teknoloji, yazılımın ön tarafında çalışan(frontend) ve iyi bir javascript altyapısına sahip yazılımcıların çapraz platform(cross platform) yani farklı işletim sistemlerinde çalışabilen masaüstü uygulamalar yazmasına imkân veren bir çerçevedir.

Eğer bu program devlet kurumunda çalışan yazılımcılarımız tarafından yazılmışsa ve kurum dışına havale edilmemişse, kararda emeği geçen ve kodlayan herkesi peşinen tebrik ederim. Bu durumda aşağıda sıralayacağım başlıklardan birinci başlığı yok sayarak okumaya devam edebilirler. Geri kalan başlıklar her koşulda programı gördükten sonraki endişelerimi barındırdığından dikkatle okumalarını tavsiye ederim.

1. Eğer bu yazılım kurum dışına, yani özel sektöre yazdırılmışsa ki bazı yerlerde yazılımı kodladığını düşündüğüm bir şirketin adı açık bir şekilde görülmektedir:

Vergi Denetim Kurulu Başkanlığında bu yazılımla aynı işi yapan başka bir program yıllarca önce yazılmış, beş seneden fazla sürede hatalarından arındırılmış, sahada aktif bir şekilde en hacimli inceleme ve veri aktarımlarında kullanılmış, 300 bin satırdan fazla kod satırına ulaşmış, devlet tarafından hali hazırda maliyetine katlanılmış ve hazır bir ürün olarak her toplantıda benim tarafımdan idari kararı verebilecek makamlara önerilmiştir. Bu program tüm yazılımcıları ile beraber Bilgi Teknolojileri Genel Müdürlüğüne devredilmiştir. Genel Müdürlüğün kuruluş amaçlarından birisi kaynak israfının engellenmesi olmasına karşın neden başka bir yazılımın kullanılması tercih edilmiştir?

Bazılarını yakinen tanıdığım, Gelir İdaresi Başkanlığı ve Vergi Denetim Kurulu Başkanlığından devralınan yazılımcıların önemli bir kısmı yeterince bilgiye sahip nitelikli kişilerdir. Bir fırsat verilmesi durumunda bu tarz bir yazılımı rahatlıkla çıkarabilecek bu kişilere neden bir şans verilmemiştir?

Bu tarz bir program, eğer ki alternatifi özel sektöre yazdırılmasıysa, benim ve şahsen tanıdığım birkaç müfettişin bireysel yeteneği ile bile ayrı ayrı birkaç kez yazılabilecek nitelikteyken ve e-defterle denetim tecrübemiz bir denetim programının yazılması kadar ortadayken neden bir telefonla bile fikrimize ihtiyaç duyulmamıştır?

Kendi araştırmalarımda bulamadığım için sormakta fayda görüyorum programı yazan firmanın alandaki referansı nasıl değerlendirilmiştir? E-defter ve belgeye ilişkin teknolojileri hangi kurumlarda hayata geçirmiştir veya en azından farklı kurumlardaki başarılarına hangi örnekler gösterilebilir?

2. Teknoloji konusundaki gelenekçi tutumu nedeniyle bizzat benim tarafından eleştirilse bile ihtiyaç çapraz platform desteği ise java dilindeki kamu uygulamalarında Gelir İdaresi Başkanlığı dünyadaki sayılı kurumlar arasında gelmektedir. Java ufak ayarlarla hali hazırda çapraz platform ürünler vermekte ve dünyadaki birçok işletim sistemi bu dili desteklemektedir. E-defterin doğrulanması ve aktarımı gibi mükellefe hitap eden sorunlu bir başlıkta Java oturmuş yapısı, kütüphaneleri ve Başkanlığın deneyimi ile daha doğru bir tercih olabilecekken electron.js ileriye dönük sorunlara neden olabilecek riskli bir tercihtir,

3. Electron.js, javascript temelli bir teknoloji olup javascript oldukça dinamik bir dildir. Electron.js ise bunun niş uygulamalarından birisidir. Genel Müdürlükte ve başkanlıkta toplanan yazılımcıların önemli bir kısmı uygulama arkasında (backend) bilgiye sahipken bildirim programının güncellemesi için ilerleyen zamanlarda ciddi bakım maliyetleri devreye girebilir,

4. Yükleyici dosya internetten indirilmektedir ve herhangi bir şekilde imza edilmemiştir. Yükleyici çalıştırıldığında bilinmeyen kuruluş uyarısı dönmektedir. Profesyonel yazılımda üretilen ve özellikle kamuya dağıtılan kodlar elektronik olarak imza edilir. Böylece programın kaynak koduna müdahale edilmediği ve programın yayıncısı garanti edilmektedir. Hacker dediğimiz arkadaşların en sevdiği iş bu yükleyici dosyaların kodlarına müdahale edilerek sistemlere sızılması ve bilgi çalınmasıyken, Başkanlığının bu programı bu şekilde dağıtması makul bir tercih değildir.

5. Bu yükleyicinin her bilgisayarda çalışması garanti edilemeyecektir. Gerçekleştirdiğim testlerde 4’te 3 başarı kaydedilmiştir,

6. Yükleyici dosyanın hacmi 200 MB, kurulu dosya hacmi 600 MB civarı olup başkanlığın sistemlerinden yüklenmektedir. Bu hacmin kayda değer bir kısmı tarayıcı ve arka plandaki lokal sunucuya aittir. Electron.js uygulamaları bağımsız programlar gibi davransa da pencereye gömülü tarayıcıdan başka bir şey değildir. Programın arayüzü bu yüzden bir web sayfasına benzemektedir. Ağır çalışmakta ve hatırı sayılır bir kaynak tüketmektedir.

7. Referans bir üründen yola çıkacak olursak boyutu terrabyteları bulabilen hacimli dosya transferi, xml parse ve validasyon işlemi için yazılmış kaç adet electron.js uygulaması gösterilebilecektir.

8. Program açıldığında ortaya çıkan logo electron.js temel logosu olup Gelir İdaresi Başkanlığının logosuyla değiştirilmelidir,

9. Programın kaynak kodunda kodlar yoruma düşülerek yer yer akıştan çıkarılmış olup production dediğimiz nihai üründe bu kısımların kullanıcıya gösterilmesi doğru değildir,

10. Bu başlıktaki sorum 10 puanlık uzmanlık sorusudur. Electron.js de kaynak kod javascript kodlarıdır. İster asar dosyasına yazılsın, ister küçültülsün(minify) ister okuması güçleştirilsin (uglify) derlenebilir bir dilden çok daha kolay okunabilen, iş mantığının apaçık olduğu bir yapıya sahiptir. O exe dosyası basit bir kabuktan(wrapper) başka bir şey değildir. Kamu düzeyindeki(government level) yazılımlarda eğer güven problemi varsa derlenebilir diller kodun geriye derlenmesini ve okunmasını zorlaştıracak tekniklerle (obfuscation) harmanlarak kullanılmaktadır. Bu programdan sadece aktarım yapması beklense bu tercih mazur görülebilir. Buna karşın bu programdan şema şematron kontrolü yapması, defter parçasında değişiklik olup olmadığının kontrolü, beratın son alınan berat olup olmadığının kontrolü, boyut kontrolü ve berat ve defterdeki imza değerlerinin eş olup olmadığının kontrolü beklenmektedir. Kaynak kodu bu şekilde apaçık ortadayken bu koda müdahale edilerek örneğin şematrondan kalan veya içeriğiyle oynanmış bir defter parçası bu sınamadan geçmiş gibi gösterilip Başkanlık sistemlerine yüklenebilir bilir mi?

Yukardaki 10 başlığa bir 10 başlık daha ekleyebiliriz. Ama uzatarak zaten teknik olan bir konuda okuyucularımızı sıkmak istemem. Eğer birinci başlıktaki varsayımım doğru değilse geri kalan 19 başlıkta biz kamu çalışanları olarak diğer başlıkların üstesinden geliriz. Ben bunu kendi mevcut iş yüküme ek bir mesai de dahil olmak üzere taahhüt ederim. Varsın geceleri bir iki saatte bu işe ayrılsın. Eğer birinci başlıktaki teorim doğruysa bunu da kendi yazdığımız programı önerdiğimde “ne gerek var biz daha iyisini yazarız, en iyisini yazarız” diyen vicdanların muhakemesine bırakıyorum. Çünkü devlet için bir kuruşun değerli olduğu bir dönemden geçiyoruz.

Kendi Diktiğin Ağacın Meyvesini Yemek

Yıllarca sadece beratları toplayan Gelir İdaresi Başkanlığının ilk defa defterlerin kendisiyle bu denli muhatap olacağı günler bizleri beklemektedir. Sahada denetim tarafında mücadele ettiğimiz yıllar itibariyle kendisini neyin beklediğini çok iyi bilen kişilerden biri olarak işin hukuki boyutuyla ilgili aşağıdaki soruları yöneltmek isterim:

1. E-defter bildirim programının defterleri yüklemeden önce defterler üzerinde şema ve şematron kontrolleri yapması ve başarılı olmayan defterleri yüklememesi beklenilmektedir. Peki, başarılı olmayan defterlerde bu defterlerin birinci dereceden sorumlusu ve üreticisi olan entegratör firmalara veya entegrasyonu tercih eden firmalara bir ceza uygulanması düşünülmekte midir? Ceza uygulanırsa bu uygulamalar bir istatistik olarak kamuoyuyla paylaşılacak mıdır?

2. E-defter bildirim programından beklenen kontrollerden birisi de defter parçasının değişip değişmediğinin kontrol edilmesidir. Diyelim ki birkaç defter parçası bu sınamadan kalmıştır. Bu durumda mükellefin defter içeriğiyle oynadığı Başkanlık nezdinde hasıl olacak ve yani Başkanlığın bilgisine girecektir. Başkanlık bu durumu nasıl değerlendirmektedir? Aynı defterin tekrar üretilip berat alınmasının mümkün olmadığının açık olduğu bu senaryoda eski tecrübelerimiz Başkanlığın resmi yazılarımıza dönüş yaparak durumun müfettişler tarafından değerlendirmesi gerektiğini istediği bir senaryoya işaret etmektedir. Apple’ın telefon yazılım hatasını bildiren teknik servis veya kullanıcıya onu da sen değerlendir demesi gibi bu ilginç senaryoda müfettişin sorduğu soru aslında müeyyidenin ne olduğudur. Buna hala resmi bir açıklama getirilmemiştir. Başkanlık aynı şekilde bu kişileri incelemeye sevk edip müfettiş değerlendirsin mi diyecektir yoksa sonunda müeyyidenin ne olduğuna kendisi mi karar verecektir?

3.Toplanan defterler Başkanlık tarafından sadece saklanacak mıdır yoksa xml kodlarından ayrıştırılarak veritabanına mı yazılacaktır? Ayrıştırılan bu veriyle herhangi bir analiz yürütülecek midir? Eğer veritabanına yazma gibi bir senaryo varsa, müfettişlerin zahmetsiz bir şekilde bu veriyi Başkanlıktan alması ve mükellefin durumdan haberdar edilmesi mükellefin de tercih ettiği bir senaryoda ne kaybettirir? Ayrıca verilerinin işlendiği açıklık anlamında mükelleflerle paylaşılmalı mıdır?

4. Şema, şematron, değişmezlik, imza eşliği ve son berat kontrolünün e-defter bildirim programı tarafından yapıldığı ve Başkanlığın bunların sıhhati konusunda iddialı olduğu bir durumda aynı kontrollerin müfettişler tarafından yapılması gereksiz olacağından bize göre defter ve beratların özet değerlerinin Vergi Denetim Kurulu Başkanlığı ile paylaşılması ve bu değerlerin kontrolü yeterli olacaktır. Bu bilginin veya dosyaların nasıl paylaşılacağına ilişkin bir politika belirlenmiş midir?

5. Programın ne lisansında ne de başka bir yerinde veri kaybına ilişkin sorumluluk reddine ve dosyaların mutlaka yedeklenmesine ilişkin bilgilere yer verilmiştir. Programın gerçekleştirdiği işlemlerin önemli bir kısmı I/O işlemleri olmakla beraber bu işlemler veri kaybına oldukça müsaittir. Yedeği alınmayan bir defter parçasında veri kaybı meydana geldiğinde Başkanlık kendi yazdığı programla mükellefin defterini zayi ederek akla zarar bir olaya imza atacağını değerlendirmemiş midir?

6. Tercih edilen program güncelleme almakta, en azından hatalar için sabit diskte log tutmakta, internet erişimine açık bir şekilde uzak sunucuyla konuşmaktadır. Bugün birçok firma ticari sırlarının çalınmasından endişe etmektedir. Kötüye kullanım yazılım ekibindeki art niyetli bir kişi veya kullanılan üçüncü parti bir kütüphanenin sahibi üçüncü kişi tarafından gerçekleştirilebilir. Bu yüzden devlet seviyesindeki yazılımlar hem güvenilir kişilere yazdırılmalı, hem satır satır tüm kodları test edilmeli ve kötüye kullanıma karşı irdelenmeli, hem de veri yönetim, güncelleme ve internet erişim politikaları kullanıcıyla paylaşılmalıdır. Ancak bu şekilde ilgili firmadaki bilişim ekibi programa karşı bir güvenlik politikası geliştirebilir. Bu bilgiler kılavuz veya programın neresindedir?

Ben yazı yazmaya başlayalı bir seneden fazla olmuş. Yazılarımızda uygun bir dilde çözüm önerisi de sunarak pek çok konuyu değerlendirdiğimizi gördünüz. Yazılarımı takip ediyorsanız bu söylediklerimizin pek çok kez karşılık bulduğuna da şahit olmuşsunuzdur. Çözüm üretilen her başlıkta kazanan yine bir bütün olarak mali idaremizin kendisi, mali alanın güzide çalışanları ve Türk mali yaşamının kendisidir. Şu bir gerçek ki özeleştiri olmadan bir adım ileri gidemeyiz. Bugün bu yazıda haksız olup olmadığı mı da yine zaman gösterecektir. Bu konuda üzücü olan tek şey bu yazıya dökülen her şeyin, diğer yazılarda olduğu gibi, henüz yazılmadan önce ilgililerin bir telefon kadar uzağında oluşudur. Örneğin kılavuzun yayın tarihi 9 Ekim olmasına karşın biz Aralık ayının sonunda uygulamanın arifesindeyiz. Ne öncesinde ne sonrasında ne de idarecilik yaptığımız yıllarda o telefon hiç çalmamıştır. Onun için bu yazımı bir Jules Verne’den bir sözle tamamlamak isterim. “Kibir, iyilik için yaratılmış bir meleği yok etti. İnsanoğlunun kaderinin tosladığı engeldir o.”


[1] GİB, E-defter Saklama Kullanıcı Kılavuzu, http://edefter.gov.tr/dosyalar/kilavuzlar/e-Defter_Saklama_Kullanici_Kilavuzu.pdf, Son Erişim 25.12.2020

[2] Electron.js, Electron.js ile yazılan diğer uygulamalar, https://www.electronjs.org/apps, Son Erişim 25.12.2020

25.12.2020

 

 

Kaynak: www.MuhasebeTR.com

http://www.muhasebetr.com/yazarlarimiz/erhanselim/053/

YORUMLAR

Henüz yorum yapılmamış. İlk yorumu yukarıdaki form aracılığıyla siz yapabilirsiniz.