Özet. E-Belgeler günümüzde şirketler tarafından yaygın olarak kullanılmaktadır. Bu makalede işletmelerde oluşturulan ham haldeki (ör. csv, xml, txt, xls, xlsx formatları) e-Belgelerin yine işletme tarafında işletilmesi, yazdırılması ve sunucu vasıtasıyla karşı tarafa gönderilmesi ele alınmaktadır. E-Belge örneği olarak, günümüzde işletmeler tarafından kullanılmak zorunda olan e-Fatura belgeleri üzerinde çalıştık. Önerdiğimiz çözüm, e-Fatura dönüşüm ve yazdırma işlemlerinin en kısa zamanda ve ağ trafiğini asgari seviyeye indirecek şekilde mükellefin yerelinde yapma esasına dayanmaktadır. Geliştirdiğimiz yazılım ilk olarak ham haldeki e-Fatura'yı görüntülenebilir (ör. html) ve ardından yazdırılabilir biçime (ör. pdf formatı) dönüştürmektedir. Yine bu çalışma kapsamında e-Fatura belgesinin bir yazıcı aracılığıyla çıktısı alınıp, gerektiğinde işletmenin belirli müşterilerine yazdırılabilir ve görüntülenebilir hali e-posta aracılığıyla gönderilmektedir. Çalışma kapsamında e-Fatura belgesinin aynı zamanda uzakta bulunan sunucuya gönderilip, orada arşivlenmesi de anlatılmaktadır. Yazılım yaşam süresi boyunca XML, XSLT, XPATH, XSD, Schematron, HTML5, Java ve SQL gibi teknolojiler kullanılmıştır. Kullanıcı tarafındaki yazılımlar, kullanıcı bilgisayarında koşmayıp, ayrı bir UNIX tabanlı gömülü sistem üzerinde çalışmaktadır. Yapılan performans testlerine dayanarak, işleme, gönderim, yazdırma için bir çok metod arasından uygun yöntemler seçilerek, bu yöntemler arasındaki performans farklılıkları bu çalışmada detaylı olarak incelenmiştir.
Usül Kanunu (VUK) Genel Tebliği ile 2010 yılında e-Fatura uygulaması hizmete alınmıştır. Nisan 2014 itibari ile 421 no.lu VUK Genel Tebliğinde belirtilen firmaların kullanması zorunludur. E-Fatura aynı zamanda, ilgili yetkili kurum ve merciler için mükelleflerden vergi toplama kolaylığı sağlayıp, alıcılar ve satıcılar arasındaki fatura kesme ve alma işlemlerini hızlandırma ve fatura işlemlerindeki maliyetleri düşürme amaçlı bir uygulamadır.
E-Fatura uygulaması kapsamında, alıcı ve fatura kesen taraf e-Fatura sisteminde olmalıdır. E-Fatura kapsamında 20.000 civarında kayıtlı kullanıcı bulunmakta olup, Türkiye’de yıllık minimum 5.8 milyar adet e-Fatura beklentisi vardır [1]. E-Fatura uyguluması sayesinde, kağıt faturaya kıyasla fatura oluşturmada %57 tasarruf, alımda %62 tasarruf sağlanmaktadır [2]. 2008 yılından 2011 yılı Mayıs ayına kadar Elektronik Fatura Kayıt Sistemi (EFKS) ve e-Fatura ile 1,28 milyar adet fatura elektronik ortamda kaydedilmiş olup, 218,5 milyon TL tasarruf sağlanmıştır [3].
E-Arşiv Fatura, VUK uyarınca kâğıt ortamında düzenlenmek, muhafaza ve ibraz edilmek zorunluluğu bulunan faturanın, 433 sıra numaralı VUK Genel Tebliğinde yer alan şartlara uygun olarak elektronik ortamda düzenlenmesi ve ikinci nüshasının elektronik ortamda muhafaza ve ibraz edilmesine imkân sağlayan uygulamadır. Zorunluluk, internet üzerinden mal ve hizmet satışı yapan ve 2014 yılı gelir tablosu brüt satış hasılatı tutarı 5 milyon lira ve üzerinde olan mükellefler için geçerlidir.
Şekil 1: E-Arşiv Şimdiki Anlayış
E-Arşiv kullanıcıları fatura düzenlerken alıcı tarafın durumunu dikkate almak durumundadır. Fatura düzenlenen mükellef e-Fatura uygulamasına kayıtlı ise faturalar e-Fatura sistemi ile oluşturulup yollanacak ve muhafaza edilecektir. Alıcı taraf e-Fatura uygulamasına kayıtlı değil ise faturalar elektronik olarak oluşturulacak, elektronik olarak arşivlenecek ancak kağıt olarak iletilecektir. Geliştirilen proje özellikle bu gerekliliğe uygun olarak tasarlanmıştır.
E-Arşiv uygulamasına geçecek olan e-Fatura mükellefleri güncel durumda ham haldeki faturalarını işlenmek üzere özel entegratör sunucusuna göndermektedirler. Bu veriler sunucuda işlenir, Universal Business Language (UBL) [4] formatına çevirilir. Mükellef işlenen faturayı yazdırmak istediği takdirde e-Fatura sunucuda görüntülenebilir formata çevirilir ve bu formattaki dosya yazdırılmak üzere mükellef yereline indirilir. İndirilen bu dosya logolar da içermektedir ve sunucuya gönderilen ham hale göre dosya boyutu önemli ölçüde (yaklaşık 12-15 kat) artmıştır. Veri boyutu büyümesi ile çok sayıda fatura basımında önemli miktarda gecikme meydana gelip, ağ problemleri nedeniyle sürekli hizmet verememe durumu söz konusudur. Dolayısıyla, iş akışlarının gecikmesi kaçınılmazdır.
Şekil 1’de bugünkü e-Fatura sistemi üzerine inşa edilmiş e-Arşiv uygulaması gösterilmektedir. Faturalar sunucuda işlenmekte ve boyutu büyümüş olan formattaki yazdıralabilir dosyalar istemciye indirilmektedir. Yukarıda anlatılmış olan problemlere neden olan bu sistem yerine makale konusu Digital Invoice Printing Instrument (DIARIST) sistemi önerilmektedir. Makale DIARIST sistem modelini, performans testlerini ve kazanılan deneyimleri anlatarak devam edecektir. 2
DIARIST Sistem Modeli
Şekil 2: DIARIST Sistemi Şekil 1’de anlatılan sistem özellikle toplu fatura basımı gerektiği durumlarda verimli değildir. Önerilen çözüm, e-Fatura dönüşüm ve yazdırma işlemlerinin en kısa zamanda ve ağ trafiğini asgari seviyeye indirecek şekilde mükellefin yerelinde yapma esasına dayanmaktadır. Ayrı bir cihaz oluşturarak kullanıcı bilgisayarı yazılım ve donanımından bağımsız olması amaçlanmıştır. Hazır gömülü kart kullanacak cihaz kullanıcı bilgisayarı ile yazıcısı arasına entegre edilecek ve e-Fatura dönüşümünden, yazıcıya baskı formatı haline gelmiş faturaların gönderilmesinden ve faturaların düşük boyutlu işlenmemiş hallerinin arşivlenme amacı ile sunucuya gönderilmesinden sorumludur. Şekil 2’de önerilen sistem modeli gösterilmektedir. Önerilen çözüm e-Fatura yazdırma işlemini kullanıcı tarafında çözen, olası internet kesintisi ve sunucu arızalarında hizmet vermeye devam edebilen, sunucu yükünü zamana yayan, sunucuyla gereksiz haberleşmeyi ortadan kaldıran bir sistemdir.
Cihazda entegre halde bulunan 3G modem ile kullanıcı ağından bağımsız iletişim sağlanabilmektedir. Sunucuya cihazdan ham fatura yanı sıra dönüşüm raporları, varsa hata bildirimi ve belge numara isteği gönderilir. Sunucu klasik yöntemde her e-fatura’nın işlenmiş halini gönderirken, DIARIST yaklaşımında sadece gerektiği zaman güncel yazılım/dönüştürücü ve cihazda kullanılacak belge numaralarını gönderir. Sunucudan cihaza olan bu iletişim e-fatura oluşturma sürecinden bağımsız olduğu için iş akışını olumsuz etkileyen durum ortadan kaldırılmıştır.
Şekil 3: DIARIST Cihazı Yazılım Akış Diyagramı Şekil 3’de DIARIST cihazı yazılım akış diyagramı verilmiştir. Alıcı taraf faturanın yazdırılmasını istiyor ise fatura cihazda işlenir ve yazdırılır. Faturanın ham hali arşivlenme amacı ile ayrıca sunucuya aktarılmaktadır. Fatura e-posta olarak alıcıya iletilecek ise faturanın ham hali başta sunucuya gönderilir, fatura sunucuda işlenir ve alıcıya e-posta olarak iletilir.
Fatura işleme yazılımı yukardan-aşağı (top-down) dizayn metodolojisi kullanılarak geliştirilmiştir. Yazılımın modüler, ekip çalışmasına uygun ve anlaşılır olabilmesi amacı ile bu yapı seçilmiştir. Şekil 4’de önerilen DIARIST sistemine ait yazılım blok diyagramı verilmiştir.
Şekil 4: DIARIST Cihazı Yazılım Blok Diyagramı
Yapılan modüler tasarıma göre kullanıcıdan gelen ham veri ilk olarak etiket boyutu küçük olan ve veri artıklığı içermeyen yapıdaki XML dosyasına dönüştürülür. Sonraki aşama Gelir İdaresi Başkanlığı’nca istenen Universal Business Language (UBL) formatına dönüşümdür. Bu dönüşümün XSLT dosyası kullanılarak gerçekleştirilmesi planlanmıştır. Böylece olası format güncellemesi ana programda geliştirme gerektirmeyecek, sadece XSLT dosyası güncellenecektir. Yapısal ve anlamsal kontroller de ayrı modüller olarak düşünülmüştür. Sonraki aşama kontrollerden geçmiş e-faturanın yazdırılabilir formata dönüşümüdür. En son aşama faturanın yazıcıya gönderilmesidir. Bu aşamaların durum bilgileri raporlama servisi tarafından kullanıcı bilgisayarına ve sunucuya gönderilir. 3
Özellikle perakende sektöründe e-Arşiv kullanacak olan mükellefler için eFatura bastırma hızı önemlidir. Yazdırma işlemini etkin yapabilmek için farklı metotlar ve DIARIST cihazı için farklı donanımlar kullanılmıştır: – JavaxPrint ile ApachePDFBox – Lp komutu ile WKHTMLTOPDF
Kullanılan bu araçların performansları Tablo 1’ deki gibidir:
Yapılan performans testleri sonucunda, ODROID-XU3 donanım platformu ile “LP-komut” metodu en uygun ve en etkin seçenek olarak belirlenmiştir. Bu yaklaşımda ODROID-XU3 platformunda koşan yazdırma servisi rutini, html halde bulunan e-Fatura belgesinin harici bir araç olan “WkhtmltoPDF” kullanarak pdf formatına dönüştürüp lp komutunu kullanarak yazıcıya gönderebilmektedir. Metot SFaaytuısrıa Cihaz Yazd(SıramnaiySe)üresi
Raspberry Pi-B 97.6 Apache PDFBOX & 1 Sayfa i5-Notebook 8.3
JavaxPrint Raspberry Pi-B 657.4
12 Sayfa i5-Notebook 12.5 WkhtmltoPDF & 1 Sayfa ROadsrpobide-rXryUP3i-B 39..17
lp-Komutu 12 Sayfa ROadsrpobide-rXryUP3i-B 349..54
Tablo 1: DIARIST Cihazı Yazdırma Performansı ve Test Sonuçları “lp” komutu doğrudan gömülü kartta bulunan yazdırma servisinden çağrılarak, yazdırılmak üzere olan e-Fatura belgesi varsayılan yazıcıya gönderilmektedir.
Projenin devamında elde edilen ölçümlerden faydalanarak optimum donanımların belirlenmesi ve buna uygun özelleşmiş kart tasarımı yapılması planlanmaktadır. 4
Bu çalışmada verimli e-Belge oluşturma, arşivleme, yazdırma yöntemi tasarlanmış ve geliştirişmiştir. Tüm iş yükünü sunucuya aktarmak yerine yerelde çalışan cihazlar ile ayrık programlamanın bahsedilen kullanım senaryosu için daha iyi bir çözüm olduğu düşünülmüş ve projelendirme aşamasına geçilmiştir. Önerilen/oluşturulan cihaz ve yöntem ile ağ trafik yükü azaltıldığı gibi kullanıcılar açısından zamandan tasarruf sağlanarak iş akışları geliştrilmektedir. Ürünleştirme aşamasından sonra e-Arşiv kapsamında kullanıma başlayacak olan cşhaz ve yöntem diğer hukuki, finansal, sağlık ile alakalı elektronik dokümanların işlenmesinde, arşivlenmesinde ve yazdırılmasında kullanılabilecektir. 5 6
Teşekkür
Bu çalışma 3140421 No’ lu, "E-Belge İşleme ve Yazdırma Donanım Platformu" başlıklı TÜBİTAK TEYDEB projesi kapsamında desteklenmektedir.
[1] Ernst & Young, Son düzenlemeler ışığında Elektronik Fatura ve Elektronik Defter Uygulamaları, Temmuz 2013
[2] Koch B., E-Invoicing / E-Billing International Market Overview & Forecast, Billentis Report, Şubat 2013
[3] Devlet Planlama Teşkilatı Müsteşarlığı, Bilgi Toplumu İstatistikleri 2011, Haziran 2011. [4] Oasis, Universal Business Language 1.0, Eylül 2014, http://docs.oasisopen.org/ubl/cd-UBL-1.0/