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