SAP'ta e-Fatura entegrasyonu: entegratör bağımsız mimari nasıl kurulur?

Türkiye'de e-Fatura uygulamasını SAP ile birlikte kuran çoğu şirket aynı hikâyeyi yaşar: ilk kurulum entegratörün sağladığı bir eklentiyle yapılır, birkaç yıl sonra entegratör ya fiyatını değiştirir ya da hizmet kalitesi düşer, geçiş düşünülür ve o anda fark edilir ki fatura numaralandırmasından onay ekranlarına kadar her şey o entegratörün yapısına bağlıdır. Geçiş yeni bir proje olur. Bu yazı, entegratörün yalnızca bir iletim kanalı olduğu, sürecin ise SAP'ta yaşadığı bir mimariyi anlatıyor.

Dört katman, tek belge

Entegratör bağımsız kurgunun temeli, e-Fatura sürecini dört katmana ayırmaktır: belge, dönüşüm, iletim ve yanıt. Belge katmanı standart SAP'tır; SD faturası ya da FI belgesi her zamanki gibi oluşur. Dönüşüm katmanı bu belgeden UBL-TR XML'ini üretir, mükellef sorgusunu yapar, senaryoyu seçer ve GİB şema kontrollerini çalıştırır. İletim katmanı hazır XML'i entegratöre teslim eder ve GİB'den dönen yanıtı alır. Yanıt katmanı ise bu yanıtı SAP belgesine yazar ve durumu izleme ekranına düşürür. Entegratörün dokunduğu tek yer üçüncü katmandır; ilk, ikinci ve dördüncü katman ondan habersizdir.

Dönüşüm katmanı neden SAP'ta olmalı?

UBL-TR üretimi dışarıda yapıldığında, fatura üzerindeki her alan — vergi istisna kodları, iskonto satırları, döviz kurları, sipariş ve irsaliye referansları — bir ara tabloyla dışarı taşınır ve orada yorumlanır. Her yorum farkı GİB'de ret ya da alıcıda itiraz olarak geri döner. Dönüşüm SAP içinde yapıldığında XML doğrudan belgeden üretilir, alan eşlemesi tek yerde tanımlıdır ve şema değişikliği tek noktadan uygulanır. Ayrıca kontrol, belge kaydedilmeden çalışır: hatalı vergi kodu ya da eksik VKN, kullanıcıya fatura kesilmeden söylenir; GİB'e gidip reddedildikten sonra değil.

Gelen fatura tarafı: onay akışı belgede yaşar

e-Fatura'nın yarısı gelen belgelerdir. Entegratör portalında kabul-ret yapılan yapılarda muhasebe kaydı ile GİB durumu birbirinden kopar; portalda kabul edilen fatura SAP'a hiç girmemiş olabilir. Doğru kurguda gelen XML SAP'a düşer, sipariş ve mal girişiyle eşleştirilir, tutar ve maliyet yeri kurallarına göre onaya gider, kabul ya da ret kararı belge üzerinden verilir ve GİB'e o karardan iletilir. Böylece hangi faturanın neden reddedildiği yıllar sonra bile belge geçmişinden okunabilir.

Çok şirketli yapıda parametreleme

Holding ve gruplarda entegratör bağımsızlığın ikinci kazancı ortaya çıkar: süreç ortak, parametreler şirket kodu bazındadır. Her şirketin VKN'si, senaryo tercihi, numara aralığı ve entegratör hesabı ayrı tanımlanır; bir şirket farklı entegratörle çalışmak istese bile süreç değişmez. Rönesans Holding'de 200'den fazla şirket kodunun aynı e-Fatura kurgusunu kullanması bu yaklaşımın ölçeklendiğinin kanıtıdır.

Sık yapılan hatalar

Numaralandırmayı entegratöre bırakmak

Fatura numarası SAP'ta üretilmeli ve GİB'e o numarayla gitmelidir. Numarayı entegratörün ürettiği yapılarda SAP belgesi ile yasal belge arasında ikinci bir eşleme tablosu doğar ve her uzlaşmazlıkta ilk o sorgulanır.

Yanıtı belgeye yazmamak

GİB ve alıcı yanıtlarının yalnızca portalda kalması, kapanışta "hangi faturalar kabul edildi" sorusunu Excel'e taşır. Yanıt, SAP belgesinin durum alanına yazılmalı ve rapor oradan alınmalıdır.

Test ortamını atlamak

GİB test ortamı, entegratör bağlantısı ve iki yönlü akış en az bir kapanış döngüsü boyunca çalıştırılmadan canlıya geçmek, ilk ay sonunda toplu ret ile sonuçlanır.

Sonuç

Entegratör bağımsız mimari, entegratör karşıtı bir mimari değildir; entegratörün işini iletime indirger ve süreci SAP'ın içinde tutar. Sonuç, sağlayıcı değişse bile değişmeyen bir e-Fatura süreci, tek yerde yönetilen mevzuat güncellemeleri ve muhasebe ile yasal belge arasında kapanan farktır. Kataloğumuzdaki e-Fatura ve e-Arşiv çözümleri bu dört katmanlı kurguyla gelir.