SAP Kullanan Firmalar İçin Türkiye e-Dönüşüm Mimarisi: SAP DRC mi, Özel Entegratör mü?

Ters köşe: Bu bir "ya o, ya bu" sorusu değil

SAP kullanan pek çok şirkette e-dönüşüm kararı şöyle özetlenir: "SAP DRC alalım, özel entegratöre gerek kalmasın." Kulağa mantıklı gelir ama Türkiye mevzuatında çoğu senaryoda doğru değildir. Çünkü SAP DRC (Document and Reporting Compliance) bir ERP tarafı çözümüdür; belgeyi üretir, UBL-TR formatına dönüştürür, imza/mühür sürecini ve durum takibini SAP içinde yönetir. Buna karşılık belgenin Gelir İdaresi Başkanlığı (GİB) tarafına hangi yasal kanaldan iletileceği ayrı bir sorudur.

Yani gerçek soru "DRC mi, entegratör mü?" değil; "son kilometreyi (last mile) kim taşıyacak ve mevzuat değiştiğinde faturayı kim ödeyecek?"

Problem: Aynı işi tarif eden üç farklı katman

Karışıklığın kaynağı, üç ayrı katmanın tek başlık altında konuşulmasıdır:

Belge üretimi ve iş süreci katmanı: Satış/satın alma belgesinden e-Fatura, e-Arşiv Fatura, e-İrsaliye, e-Müstahsil vb. çıkarılması, iptal/itiraz/red akışları, muhasebe entegrasyonu.
Dönüştürme, imzalama ve zarflama katmanı: UBL-TR şemasına uyum, şema/şematron validasyonu, mali mühür veya e-imza uygulanması.
GİB'e bağlantı (yasal kanal) katmanı: Belgenin resmî olarak sisteme girdiği nokta.

GİB'in e-Belge uygulamalarında başvuru/kullanım yöntemleri genel olarak üç başlıkta tanımlanır: GİB portalı, doğrudan entegrasyon ve özel entegratör aracılığıyla kullanım. Bu çerçeve 509 Sıra No.lu Vergi Usul Kanunu Genel Tebliği ve sonraki değişiklik tebliğlerinde düzenlenmiştir; güncel metin ve haddler ebelge.gib.gov.tr üzerinden teyit edilmelidir.

SAP DRC 1. ve 2. katmanı güçlü şekilde kapsar. 3. katman ise ya bir özel entegratör hizmetiyle ya da şirketin kendi doğrudan entegrasyon izniyle çözülür. Doğrudan entegrasyon; sistem testleri, 7/24 erişilebilirlik, kapasite ve saklama gibi yükümlülükler getirdiği için Türkiye'de görece az sayıda kurumun tercih ettiği bir yoldur.

Üç gerçekçi mimari

A) SAP DRC + özel entegratör (en yaygın hibrit)

Belge SAP içinde üretilir, eDocument/DRC kokpitinde izlenir; entegratör GİB tarafındaki kanal, alıcı posta kutusu yönetimi, arşivleme ve raporlama tarafını üstlenir. Avantajı: ERP verisi tek yerde, mevzuatın kanal tarafındaki oynaklığı dışarıda. Dezavantajı: iki sözleşme, iki destek hattı ve arayüzün sahipliği sorusu.

B) Özel entegratörün SAP konnektörü / add-on'u

Entegratörün ABAP tarafında kurduğu bileşen belgeyi SAP'den alır, mapping ve gönderim entegratörde yapılır. Avantajı: hızlı devreye alma, mevzuat güncellemelerinin büyük kısmının tedarikçi tarafında kalması. Dezavantajı: standart dışı geliştirme yükü, S/4HANA geçişinde ve sürüm yükseltmelerinde yeniden test ihtiyacı, ERP dışında oluşan belge durum verisinin mutabakat maliyeti.

C) Doğrudan entegrasyon (kendi kanalın)

SAP DRC + kendi entegrasyon altyapın. Çok yüksek hacim, güçlü iç BT ekibi ve uzun vadeli sahiplenme iradesi gerektirir. Yükümlülükler (test süreci, süreklilik, saklama-ibraz) idari düzenlemelerle belirlenir ve başvuru öncesi GİB dokümantasyonundan doğrulanmalıdır.

[İÇ LİNK: e-Fatura, e-Arşiv ve e-İrsaliye arasındaki farklar]

Toplam sahip olma maliyeti: Faturada görünmeyen kalemler

Teklif karşılaştırmaları çoğunlukla lisans ve belge başı ücret üzerinden yapılır; oysa 3-5 yıllık TCO'yu belirleyen kalemler genelde şunlardır:

Uygulama/danışmanlık günü: Belge tipi sayısı, şirket kodu (company code) sayısı, özelleştirilmiş satış süreçleri ve iade/iptal senaryoları maliyeti doğrudan büyütür.
Mapping ve özel alan yükü: İskonto, ÖTV/tevkifat, ihracat, konaklama vergisi gibi senaryolarda alan eşlemesi işin en uzun kısmıdır.
Basis ve sürüm bakımı: DRC tarafında güncellemeler SAP notları/destek paketleri üzerinden gelir; bunları uygulayacak kapasite bir maliyettir. Entegratör add-on'unda ise regresyon testi maliyeti vardır.
Arşiv ve ibraz: Elektronik belgelerin saklanması ve istendiğinde ibrazı Vergi Usul Kanunu'nun saklama-ibraz hükümlerine tabidir; Türk Ticaret Kanunu'nun defter ve belgelere ilişkin saklama süresi ise ayrıca değerlendirilir. Hangi tarafın hangi süreyle saklayacağı sözleşmede net yazılmalıdır.
e-Defter tarafı: e-Defter ve berat süreçleri e-Fatura'dan ayrı bir uygulamadır ve edefter.gov.tr üzerinden düzenlenir. DRC'nin ülke kapsamının bu tarafı ne ölçüde içerdiği sürüm ve sürüme göre değişebileceğinden SAP resmî dokümantasyonundan teyit edilmelidir.
Çıkış maliyeti: Sözleşme bitiminde geçmiş belgelerin hangi formatta ve ne kadar sürede teslim edileceği.

[İÇ LİNK: e-Defter berat yükleme takvimi ve sık yapılan hatalar]

Uyum riski: Asıl ayrım burada

Türkiye'de e-belge mevzuatı sık güncellenir: kapsam haddi değişir, yeni belge tipi gelir, şema revizyonu yayımlanır, iptal/itiraz süreçleri yeniden tanımlanır. Kritik soru şudur: bir değişiklik yayımlandığında sizin tarafınızda kaç adam-gün iş doğuyor?

Entegratör ağırlıklı modelde değişikliğin çoğu tedarikçi tarafında absorbe edilir; ancak ERP'de yeni alan üretmek gerekiyorsa iş yine size döner.
DRC ağırlıklı modelde güncelleme SAP'nin yayımladığı içeriklerle gelir; avantajı standart ve denetlenebilir olmasıdır, dezavantajı takvimin sizin sürüm/destek stratejinize bağlı olmasıdır.

Çok ülkeli SAP kurulumlarında tablo değişir: Türkiye'yi yerel bir çözümle, diğer ülkeleri farklı yerel çözümlerle yönetmek beş yıl sonra yönetilemez bir portföy üretebilir. Global standardizasyon hedefi varsa DRC lehine ağırlık artar.

Ne yapmalı

Katmanları ayır: Üretim, dönüştürme/imzalama ve GİB kanalı için ayrı ayrı "kim sahibi?" sorusunu yanıtla; tek bir kutucukta karar verme.
Hacim ve senaryo envanteri çıkar: Yıllık belge adedi, belge tipleri, şirket kodu sayısı, ihracat/tevkifat/iade senaryoları. Karar bu tabloya bakılarak verilir.
ERP yol haritanı sabitle: ECC'de mi kalınacak, S/4HANA'ya ne zaman geçilecek, RISE kapsamında mı? Geçiş tarihi yakınsa iki kez uygulama yapmamak için mimariyi ona göre kur.
Mevzuat değişikliği senaryosu iste: Tedarikçilerden "şema revizyonu yayımlandığında hangi adımlar, kim, ne sürede" yazılı olarak istensin.
SLA'yı belgeye bağla: Kesinti, kuyruk birikmesi, GİB tarafı yanıt gecikmesi ve mutabakat farkları için ölçülebilir taahhüt.
Arşiv ve çıkış maddesini şimdi yaz: Saklama süresi, format, teslim süresi ve devir maliyeti sözleşmeye girsin.
DRC kapsamını sürüm bazında doğrula: "Türkiye destekleniyor" ifadesi yeterli değil; hangi belge tipleri, hangi sürümde, hangi bileşenlerle destekleniyor, resmî dokümantasyondan teyit edilmeli.
Pilot koş: Karar öncesi tek bir şirket kodu ve tek belge tipiyle uçtan uca test; teklif slaytı değil, gerçek belge akışı konuşsun.

Sonuç

Doğru cevap tek değil. Düşük-orta hacimli, tek ülkeli, iç BT kapasitesi sınırlı şirketlerde entegratör ağırlıklı model genelde daha hızlı ve öngörülebilir sonuç verir. Yüksek hacimli, çok ülkeli, S/4HANA yol haritası netleşmiş ve Basis kapasitesi olan kurumlarda DRC ağırlıklı standart mimari uzun vadede daha yönetilebilir olabilir. Her iki durumda da GİB kanalı kararı ayrıca verilmelidir.

Sizin kurumunuzda mevzuat değişikliği geldiğinde ilk telefonu kim açıyor: BT mi, mali işler mi, tedarikçi mi? Bu sorunun cevabı, aslında mimari kararınızı büyük ölçüde şimdiden veriyor olabilir.

Kaynaklar

509 Sıra No.lu Vergi Usul Kanunu Genel Tebliği (19.10.2019 tarihli Resmî Gazete) ve sonraki değişiklik tebliğleri — güncel metin: ebelge.gib.gov.tr
Gelir İdaresi Başkanlığı e-Belge Portalı (ebelge.gib.gov.tr): başvuru/kullanım yöntemleri, kılavuzlar, özel entegratör listesi
Gelir İdaresi Başkanlığı e-Defter Portalı (edefter.gov.tr): e-Defter ve berat süreçleri
Vergi Usul Kanunu'nun defter ve belgelerin saklanması ile ibrazına ilişkin hükümleri; Türk Ticaret Kanunu'nun saklamaya ilişkin hükümleri
SAP resmî ürün dokümantasyonu (help.sap.com): Document and Reporting Compliance ülke/sürüm kapsamı — kapsam bilgisi sürüme göre değiştiğinden doğrudan doğrulanmalıdır

Bu yazı bilgilendirme amaçlıdır, mali müşavirlik/danışmanlık hizmeti değildir.