=Paper=
{{Paper
|id=Vol-1483/38_Deneyim
|storemode=property
|title=Kullanıcı Tarafında eBelge Oluşturma ve Yazdırma Yazılım Deneyimleri
|pdfUrl=https://ceur-ws.org/Vol-1483/38_Deneyim.pdf
|volume=Vol-1483
|dblpUrl=https://dblp.org/rec/conf/uyms/BayarUS15
}}
==Kullanıcı Tarafında eBelge Oluşturma ve Yazdırma Yazılım Deneyimleri==
https://ceur-ws.org/Vol-1483/38_Deneyim.pdf
Kullanıcı Tarafında E-Belge Oluşturma ve
Yazdırma Yazılım Deneyimleri
Salih Bayar1,2 , Mehmet Görkem Ülkar1,3 , and Alper Şen2
1
İdea Teknoloji Çözümleri,
Sun Plaza BBDO Blok Dereboyu Cd. Bilim Sk No:5 34398 Maslak/İstanbul
2
Boğaziçi Üniversitesi, Bilgisayar Mühendisliği,
Bebek, İstanbul
3
Boğaziçi Üniversitesi, Elektrik-Elektronik Mühendisliği
Bebek, İstanbul
{salih.bayar, gorkem.ulkar}@ideateknoloji.com.tr,
{salih.bayar, gorkem.ulkar, alper.sen}@boun.edu.tr,
Özet. E-Belgeler günümüzde şirketler tarafından yaygın olarak kul-
lanı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ın-
dan kullanılmak zorunda olan e-Fatura belgeleri üzerinde çalıştık. Ön-
erdiğ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 yere-
linde 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şlet-
menin 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 perfor-
mans 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.
Anahtar Kelimeler: E-Belge, E-Fatura, E-Arşiv, UBL, XML, XSLT,
XSD, HTML, Schematron
1 Giriş
E-Fatura uygulaması, hem Türkiye’ de hem de diğer ülkelerde kullanıl-
makta olup, elektronik belge biçiminde düzenlenen faturaların, taraflar arasında
dolaşımını güvenli ve sağlıklı biçimde sağlamaktadır. Türkiye’ de 397 nolu Vergi
369
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 fir-
maları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 siste-
minde olmalıdır. E-Fatura kapsamında 20.000 civarında kayıtlı kullanıcı bulun-
makta 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şturu-
lacak, elektronik olarak arşivlenecek ancak kağıt olarak iletilecektir. Geliştirilen
proje özellikle bu gerekliliğe uygun olarak tasarlanmıştır.
370
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öndermek-
tedirler. 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 mik-
tarda 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 format-
taki 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.
371
Ş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.
372
Fatura işleme yazılımı yukardan-aşağı (top-down) dizayn metodolojisi kul-
lanı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çek-
leş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 kon-
trollerden 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 Performans Testleri ve Deneyimler
Özellikle perakende sektöründe e-Arşiv kullanacak olan mükellefler için e-
Fatura 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.
373
Fatura Yazdırma Süresi
Metot Cihaz
Sayısı (Saniye)
Raspberry Pi-B 97.6
1 Sayfa
Apache PDFBOX & i5-Notebook 8.3
JavaxPrint Raspberry Pi-B 657.4
12 Sayfa
i5-Notebook 12.5
Raspberry Pi-B 9.7
1 Sayfa
WkhtmltoPDF & Odroid-XU3 3.1
lp-Komutu Raspberry Pi-B 39.4
12 Sayfa
Odroid-XU3 4.5
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ım-
ların belirlenmesi ve buna uygun özelleşmiş kart tasarımı yapılması planlanmak-
tadır.
4 Sonuç
Bu çalışmada verimli e-Belge oluşturma, arşivleme, yazdırma yöntemi tasar-
lanmış 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ön-
tem 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 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.
6 Kaynaklar
[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.
374
[4] Oasis, Universal Business Language 1.0, Eylül 2014, http://docs.oasis-
open.org/ubl/cd-UBL-1.0/
375