Özetçe. E-fatura sisteminin zorunlu hale getirilmesiyle birlikte kullanımı oldukça yaygınlaşmıştır. Bu da beraberinde yazılımsal bir yük ortaya çıkarmaktadır. e-Fatura Schematron kurallarının kontrolü de bu yükün önemli bir kısmını oluşturmaktadır. Bu çalışmada e-Fatura Schematron kurallarının tek bir XSLT dosyasında çalıştırılması ile her bir kuralın farklı XSLT dosyalarında çalıştırılma performansları kıyaslanmıştır. Elde edilen sonuç doğrudan bu işlem süresinin minimum sürede tamamlanmasını sağlayacak olup hem mükellef hem de entegratör firmalar için hayati önem taşımaktadır. Bunun için örnek bir e-Fatura UBL dosyası ile 12 kural içeren bir XSLT dosyası Saxon kütüphanesi kullanılarak Schematron kontrolü gerçekleştirilmiştir. Bu işlem hem kuralların hepsi tek bir XSLT dosyası içerisindeyken hem de kurallar ayrıştırılıp 12 ayrı XSLT dosyası halindeyken yapılmıştır. Ayrıca her iki durum için de template yapısı kullanılarak toplamda 4 durum göz önüne alınmıştır. Testlerin anlık bilgisayar yükünden etkilenmemesi için her test 100'er defa tekrarlanıp ortalama hesabı yapılmıştır.
kullanıcı bulunmakta olup, Türkiye’de yıllık minimum 5.8 milyar adet e-Fatura
beklentisi vardır [
2010 yılında Türkiye genelinde düzenlenen e-Fatura sayısı 8 bin civarındayken, bu rakam 2016 yılı itibari ile 113 milyon civarındadır. Artan e-Fatura sayısı ve tutarı, e-Fatura denetim ve kontrollerinin de zorunluluğunu beraberinde getirmiştir. Bu çalışma kapsamında e-Fatura’ nın denetiminde GİB tarafından belirlenen zorunlu kuralların ve GİB tarafından henüz belirtilmemiş olup, mükellefleri güvenli alışverişe yönlendiren, e-Fatura iptal sayı ve sürelerini asgari seviyeye indiren kontrollerde kullanılan yöntemler ve teknikler anlatılmaktadır.
Bu çalışmanın devamında Bölüm 2’ de e-Fatura’ nın oluşturma adımları ve oluşum sonrası yapılan zorunlu, satıcı ve alıcıyı korumaya yönelik kuralların işlenme yöntemlerinden bahsedilmektedir. Bölüm 3’ de e-Fatura oluşumu sonrası yapılan tetkiklerde kullanılabilecek farklı yöntemler üzerinde durulmuş olup, hangi yöntemin daha etkin olduğundan bahsedilerek, ilgili performans testleri detaylı bir şekilde yapılmıştır. Son olarak Bölüm 4’ de çalışmadan çıkan sonuçlar ele alınmıştır. 2
YÖNTEM-1 YÖNTEM-2 Mükelef
XML UBL-TR Taslak
Sınıfların Oluşturulması
UBL-TR
ObjeHalinde CSV Önİşleme
Veritabanına
Eklenmesi
JAXB ExcelXLS/XLSX
TEXT UBL-TR Taslak
UBL-TR Dönüştürme Mükelef XSLT Önİşleme Mükelef Dönüşüm
Tablosu Şekil 1. E-Fatura Oluşturma Adımları
E-Fatura oluşturulurken vergi mükelleflerinden gelen e-Fatura verisinin yapısına göre genel olarak iki farklı yöntem kullanılmaktadır. Bu iki farklı yöntem Şekil 1’ de verildiği üzere, vergi mükelleflerinin ERP sistemlerinden gönderdikleri e-Fatura’ nın oluşturuluş şekline göre farklılık göstermektedir. Şekil 1’ de gösterildiği gibi, UBL-TR YeniÖrnek UBL-TR
Sınıfın Doldurulması Şematron Kontrol Alıcı Genel
Kontrol
JAXB
Marshaling MaliMühür Sertifikası/
NES XSD Kontrol İmzasız e-Fatura e-Fatura İmzalama İmzalanmış e-Fatura Alıcı-Satıcı ArasıÖzel Kontrol
AlıcıveSatıcıOnayından
Geçmiş,
İmzalıe-Fatura
eğer e-Fatura TXT, CSV, Excel dosyası şeklindeyse Yöntem-1, aksi durumda
yani e-Fatura belirgin bir XML formatında verilirse Yöntem-2 kullanılmaktadır.
Bu yöntemler, önceki çalışmamız olan [
Bu çalışma kapsamında yapılan temel farklılık e-Fatura oluşumundan sonra yapılan XSD ve Schematron kontrolleri sonrası, imzalı UBL-TR formatındaki e-Fatura verisinin alıcının önceden belirlemiş olduğu genel kontrollerden ve alıcısatıcı arası yine önceden tanımlanmış, e-Fatura iptalini neredeyse gereksiz hale getiren kuralların kontrolleri de verilmiştir. Bu kural kontrolleri Şekil 1’ de kesikli çizgi ile gösterilmektedir.
Şekil 1’ de kesikli çizgi ile belirtilmiş olan, alıcının genel kurallarını içeren ve alıcı-satıcı arası özel kuralları içeren kontroller sayesinde e-Fatura iptal sayılarının asgari seviyeye indirgenmesi hedeflenmektedir.
Şekil 1’ den de anlaşılacağı üzere, UBL-TR formatındaki e-Fatura verisi, XSD ve Schematron kontrolleri dahil arka arkaya toplam dört farklı, birbirinden bağımsız kontrollerden geçmektedir. Hal böyle olunca, e-Fatura verisinin işlenme süresinin de hesaba katılması gerekmektedir. Arka arkaya yapılan bu kontrellerin en etkin ve hızlı şekilde yapılması için Bölüm 3’ de ilgili performans testleri verilmiştir. 3
Performans Testleri ve Deneyimler Senaryo Adı Açıklaması
Kontrolü yapılacak bütün kurallar bir xslt dosyası içerisinde All_Original listelenmiştir. Template kullanılmamıştır ve dolayısıyla yalnızca toplam süre ölçümlenebilmektedir.
Kontrolü yapılacak kurallar yine ilk senaryodaki gibi tek bir xslt All_Template ydaopsyısaısnıandgaörteopbliarnamraışdtaırbaunlucankantekmupralalltaerkbuilrllaikntıledöığlçıüiçleincefkatşuerkaildxeml, toplam 7 ölçüm değeri elde edilmiştir.
Single_Original kHuelrlaknuılrmalaadyığrıı biçiirnxysaltlndızocsayahseırkukullraanlıliaçrinaktoöplçlüamlmüsüşroeluöplç,ütme müpylaapteılmıştır.
3. Senaryodaki gibi her kural ayrı bir xslt dosyasına yazılmış,olup Single_Template template kullanımı sayesinde her kuralın süre ölçümü yapılabildiği gibi,aynı zamanda her kural için geçen toplam süre ölçümü de yapılmıştır.
Tablo 1. Olası Test Senaryoları
Test için kullanılan bilgisayar 8GB RAM ve Intel Core i5-3230M işlemcisine sahip iken, performans ölçümleme aracı olarak Saxon XSLT ve XQuery Processor Home Edition Version 9.7 kullanılmıştır. 3.1
Performans testlerinin yürütülmesi adına toplam dört farklı senaryo belirlenmiştir. Bu senaryolar Tablo 1’ de detaylı bir şekilde görülebilmektedir. 3.2
ı30 ğ lıık20 S ra10 u t a F 0 ı30 ğ lıık20 S ra10 u t a F 0 7 8 9 10 11 12 13 14 15
Süre [ms] 7 8 9 10 11 12 13 14 15
Süre [ms] Şekil 2. All_Original senaryosuna ait gross ve net histogramlar
Senaryolar belirlendikten sonra, ölçüm sonuçlarının daha tutarlı olması ve hatalardan arındırılması için her senaryo ölçümü 100 kez tekrarlanarak sonuçlar kaydedilmiştir. Daha sonra ölçüm sonuçlarının yer aldığı HTML dosyalarını ayrıştırma amacıyla jsoup kütüphanesi kullanılarak bir parser yazılmıştır. Bu parser HTML dosyalarını okuyarak ölçüm sonuçlarını CSV formatına çevirmektedir. CSV formatına gelen data analiz edilerek bölüm 3.3’ de yorumlanarak sunulmuştur. 3.3
All_Template Gross
All_Template Net 6 7 8 9 10 11 12 13 14
Süre [ms] 4 5 6 7 8 9
Süre [ms] Şekil 3. All_Template senaryosuna ait gross ve net histogramlar
All_Original senaryosu için yapılan 100 ölçüm sonuçları net ve gross olarak histogram formatına getirilmiştir. Şekil 2’ de ilgili histogram görülmektedir.
Benzer şekilde All_Template senaryosu için yapılan 100 ölçüm sonuçları net ve gross olarak histogram formatına getirilmiştir. Şekil 3’ de ilgili histogram görülmektedir.
Beklenildiği gibi All_Original senaryosunda (bkz. Şekil 2) gross ve net süreler aynı çıkmaktadır. Buna karşın All_Template senaryosunda (bkz. Şekil 3) template yapısından dolayı yalnızca kural kontrolünün ne kadar sürdüğü net olarak ölçülebilirken aynı zamanda komut verildikten itibaren sonuç dosyalarının üretimine kadar geçen süre de gross olarak kaydedilebilmektedir. Gross ortalamalarına bakıldığında All_Original senaryosunda 8,37ms ve All_Template senaryosunda 8,60ms süre elde edilmektedir. Yaklaşık 0,23ms’lik bu süre farkı her iki senaryonun da çok yakın sürelerde çalıştığını göstermektedir. Ayrıca All_Template senaryosunda (bkz. Şekil 3) net sürelerin gross sürelere bölümüyle elde edilen sonuç toplam sürenin yaklaşık %53,7’sinin kural kontrolüne harcandığını, geri kalan sürenin ise diğer işlemlere (overhead) harcandığını belirtmektedir.
Single_Original 9 8 7 ][s65 m re4 Sü3 2 1 0 1 2 3 4 5 6 7 8 9 10 11 12
Kural Sayısı
NetTotal Gross Total 12 10 ]s 8 [m6 eü r S 4 2
Single_Template
NetRule Gross Rule NetTotal
Gross Total 0 1 2 3 4 5 6 7 8 9 10 11 12
Kural Sayısı (a) Single_Original
(b) Single_Template Şekil 4. Single_Original ve _Template senaryosuna ait ölçümler Şekil 4a’ da üçüncü senaryo olan Single_Original senaryosunda ise analiz için histogram yerine her kural için ortalama net ve gross süreleri hesaplanmıştır. İlk senaryoda olduğu gibi (bkz. Şekil 2) template yapısının yokluğundan dolayı bu süreler birbirine eşit çıkmıştır. Bu ortalama süreler toplandığında bir faturanın bütün kurallardan bu yöntemle geçirilmesi esnasında toplam olarak yaklaşık 70,8ms harcandığı görülmektedir. All_Original senaryosunun (bkz. Şekil 2) ortalama süresi olan 8,37ms ile kıyaslandığında bu yöntemin daha yavaş olduğu görülmektedir.
Şekil 4b’ de son senaryo olan Single_Template senaryosunda ise yine template yapısından faydalanılarak her kural kontrolü için geçen süreyle birlikte toplam süreler de hesaplanmıştır. Ortalama Gross_Total ve Net_Total süreleri sırasıyla 92,8ms ve 82,6ms olarak hesaplanmıştır. Bu durumda bu senaryonun Single_Original senaryosundan bkz. Şekil 4a) daha yavaş çalıştığı görülmektedir. Bu durumun sebebi ise template yapısının getirdiği ekstra iş yükü olmaktadır. Kural bazında bakıldığında ise kontrolün gerçekleştiği sürenin toplam süreye oranının 5. ,6. ve 12.kurallar hariç %10 seviyesinin altında olduğu gözlemlenmiştir.
Bu çalışma kapsamında UBL-TR formatında olan e-Fatura verisinin imza sonrası dört farklı kontrolden geçmesi gerektiği anlatılmaktadır. Yukarıda da yer yer bahsedildiği gibi bu dört kontrol sırasıyla aşağıdaki gibi verilmiştir: – XSD: e-Fatura verisinin yapısal kontrolü – Schematron: e-Fatura verisinin zorunlu (GİB tarafından berlilenen) anlamsal tutarlılık kontrolü – Alıcı-Genel Kurallar: Bir vergi mükellefinin ürün, servis ya da hizmet alımında belirlediği genel kurallar – Alıcı-Satıcı Özel Kurallar: Bir e-Fatura düzenlenmesinde alıcı satıcı konumunda bulunan vergi mükelleflerinin, ya da sadece alıcının belirlediği ilgili satıcıya dair özel kurallar
UBL-TR formatında bulunan, imzalı her bir e-Fatura verisi bu kontrollerden geçtiği için, bu kontrolleri kapsayan kuralların bir e-Fatura bazında işleyiş şekli e-Fatura’ nın işleme süresinin önemli bir kısmını oluşturmaktadır. Bu çalışma kapsamında örnek bir UBL-TR formatındaki örnek bir e-Fatura XML dosyası ile 12 farklı kural içeren bir XSLT dosyası Saxon kütüphanesi kullanılarak XSD, Schematron ve alıcı genel kontrolleri gerçekleştirilmiştir. Bu işlem hem kuralların hepsi tek bir XSLT dosyası içerisindeyken hem de kurallar ayrıştırılıp 12 ayrı XSLT dosyası halindeyken yapılmıştır. Yapılan testlerin analizi sonucunda tek bir XSLT dosyasında bulunan kuralların her bir kural için farklı XSLT dosyalarına ayrılması sistemi yavaşlatmıştır. Yapılan testler sonucunda takribi olarak toplam sürenin yaklaşık %53,7’sinin kural kontrolüne harcandığını, geri kalan sürenin (%46,3’ ü) ise diğer işlemlere (overhead) harcandığı gözlemlenmiştir. Hal böyle olunca, birbirinden bağımsız dört farklı XSLT dosyasının tek bir dosyaya indirgenmesi, sistem yükünü bariz bir şekilde hafifletecektir. 5 6
TEŞEKKÜR