A
Ali Güngör
Misafir
Misafir
Almanya SAP e-Fatura geçişi, SAP veya farklı ERP sistemlerinden çıkan fatura verisini EN 16931 uyumlu bir formata dönüştürdüğümüz ve partnerin beklediği kanaldan ilettiğimiz süreçtir. Bu süreci beş adımda yürütüyoruz.
Adımlar şunlar: mevcut yapıyı çıkarma, hedef mimariyi tasarlama, veri kontrolü, pilot partnerlerle uçtan uca test ve kapsamı kademeli genişletme. İlk toplantılarda konu genellikle teknik taraftan açılıyor. XRechnung mı kullanacağız, ZUGFeRD mi, Peppol olacak mı, web servis bağlantısı mı kuracağız?
Biz bir adım geriden başlıyoruz. Önce şirketin bugün faturayı nasıl yönettiğini anlıyoruz. Kaç farklı ERP var, faturalar nereden çıkıyor, hangi partnerlerle çalışıyorsunuz, hangi formatları kullanıyorsunuz? Bu tabloyu çıkardıktan sonra nasıl bir yapı kuracağımız da netleşiyor.
Almanya tarafında tek bir doğru senaryo yok. Şirketler farklı formatlarla, farklı iletişim yöntemleriyle ve partnerden partnere değişen akışlarla çalışıyor. Bu yüzden mimari tartışmasını mevcut durumu görmeden başlatmıyoruz.
Mevzuat da bu ihtiyacı destekliyor. Almanya’da B2B e-fatura alma yükümlülüğü 1 Ocak 2025’te başladı. Gönderme zorunluluğu ise kademeli ilerliyor. 800.000 Euro üzeri ciroya sahip işletmeler 1 Ocak 2027’de, diğer tüm işletmeler 1 Ocak 2028’de kapsama giriyor.
Ayrıntılı takvim için
İlk iş mevcut fatura akışlarını masaya yatırıyoruz. Fatura hacmine bakıyoruz. ERP sistemlerini listeliyoruz. Şirketin kullandığı formatları, partnerleri, mevcut entegrasyonları ve gönderim yöntemlerini inceliyoruz.
Bu aşamada ilk toplantılarda konuşmadığımız detaylar da ortaya çıkıyor. Ekipler belirli bir müşteri için yıllar önce özel bir akış geliştirmiş olabiliyor. Bazı faturalar farklı bir kanaldan gidiyor olabiliyor. Bir noktada operasyon ekibi manuel müdahale yapıyor olabiliyor. Grup şirketleri aynı süreci farklı şekillerde yürütebiliyor.
Bu detayları mümkün olduğunca başta görmek istiyoruz. Çünkü birazdan çizeceğimiz mimaride hepsinin bir karşılığı olacak.
Elimizde mevcut yapı olduğunda yeni akışın nasıl çalışacağını konuşmaya başlıyoruz. ERP’den çıkan fatura nereye gelecek? XRechnung mı hazırlayacağız, ZUGFeRD mi? Müşteri faturayı nasıl almak istiyor? Faturanın durumu ERP’ye geri dönecek mi? Hata olduğunda ekip bunu nereden görecek?
Burada tek bir akış çizip bütün partnerleri o akışa sokmuyoruz. Partnerin istediği format ve iletişim yöntemi neyse senaryoyu ona göre kuruyoruz. Örnek akışlar şöyle şekilleniyor:
Format ve iletim kanalı iki ayrı karardır. Aşağıdaki tablo, sahada en sık karşılaştığımız kombinasyonları özetliyor.
MIP’i bu akışların merkezindeki entegrasyon katmanı olarak konumlandırıyoruz. ERP’den gelen veriyi alıyoruz, gerekli dönüşümleri yapıyoruz, ilgili formatı oluşturuyoruz ve partner için tanımladığımız kanala yönlendiriyoruz. Bir
Yeni bir partner geldiğinde ERP tarafında sıfırdan entegrasyon geliştirmek yerine bu yapı üzerinden ilerliyoruz.
Projelerde en fazla vakit kaybettiren konu veridir. Bağlantıları kuruyorsunuz, testlere başlıyorsunuz ve faturadaki zorunlu alanlardan birinin eksik olduğunu görüyorsunuz. Başka bir faturada vergi numarası beklenen formatta gelmiyor. Bir partnerin istediği bilgi ERP’den hiç çıkmıyor.
Bu yüzden ana veriyi, vergi bilgilerini, zorunlu alanları ve iş kurallarını akışın içine dahil ediyoruz. XRechnung hazırlayacaksak o formatın zorunlu alanlarını kontrol ediyoruz. Kamu kurumuna gidecek faturalarda Leitweg-ID gibi yönlendirme bilgilerini ayrıca doğruluyoruz. ZUGFeRD senaryosunda gömülü XML verisini gözden geçiriyoruz.
Faturadaki problemi karşı tarafa gönderdikten sonra değil, MIP tarafındayken görmek istiyoruz. Böylece operasyon ekibi hatayı daha rahat takip ediyor. Hatanın hangi alanda ve hangi adımda çıktığını görebilmek işleri epey kolaylaştırıyor.
Mimari hazır olduğunda belirli partnerlerle pilot sürece geçiyoruz. ERP’de faturayı oluşturuyoruz. Veri MIP’e geliyor. Gerekli kontrolleri yapıyoruz. Partner XRechnung istiyorsa XRechnung, ZUGFeRD istiyorsa ZUGFeRD hazırlıyoruz. Ardından faturayı o partner için belirlediğimiz kanala gönderiyoruz.
Testlerde özellikle hata senaryolarını çalıştırıyoruz. Eksik alan gönderiyoruz. Format hatası oluşturuyoruz. Peppol tarafında bir hata döndüğünde nasıl yönettiğimize bakıyoruz. E-posta gönderiminde çıkabilecek problemleri kontrol ediyoruz.
Canlıya çıktıktan sonra ekipler en sık şu soruyu soruyor: “Bu fatura nerede kaldı?” Kurduğumuz yapının bu soruya hızlı cevap vermesini istiyoruz. Mevcut EDI altyapısı olan şirketlerde
Pilot tamamlandıktan sonra diğer partnerleri sisteme almaya başlıyoruz. Burada gruplar halinde ilerlemeyi tercih ediyoruz. Önce belirlediğimiz partnerler, ardından diğer gruplar ve varsa özel senaryolar geliyor.
Her yeni partnerde aynı iki soruyla başlıyoruz: Hangi formatı istiyor? Nasıl almak istiyor? Cevap XRechnung ile Peppol olabilir. XRechnung ile web servis olabilir. ZUGFeRD ile e-posta olabilir. Buna göre MIP üzerinde ilgili akışı oluşturuyoruz ve devreye alıyoruz.
Geçiş sırasında sonuçları da takip ediyoruz. Kaç fatura gönderdik, kaçı başarılı geçti, hangi faturalar hata aldı, hata hangi aşamada çıktı, yeniden gönderim yaptık mı? Bir süre sonra süreç oturuyor ve günlük operasyonun parçası haline geliyor.
Hedefimiz ekiplerin sürekli teknik logların arasında dolaşması değil. Bir problem çıktığında ilgili faturayı bulup ne yaşandığını hızlı görebilmeleri gerekiyor.
MIP’in görevini kısaca ERP ile Almanya e-fatura ekosistemi arasındaki entegrasyonu yönetmek olarak anlatabiliriz. SAP veya farklı ERP sistemlerinden gelen fatura verisini alıyoruz. Partnerin ihtiyacına göre gerekli dönüşümleri yapıyoruz. XRechnung veya ZUGFeRD oluşturuyoruz.
Ardından faturayı ilgili kanala yönlendiriyoruz: Peppol, web servis, e-posta veya kullandığınız provider. Gelen cevapları ve durum bilgilerini de ilgili sistemlere geri taşıyoruz.
MDP Group olarak bu yapıyı özellikle SAP tarafında mevcut entegrasyonları olan şirketlerde tercih ediyoruz. Yıllardır çalışan ERP süreçlerini mümkün olduğunca koruyoruz ve yeni e-fatura akışlarını entegrasyon katmanında yönetiyoruz. Böylece yeni bir partner geldiğinde konu tekrar başa dönmüyor.
Partnerin formatını ve iletişim yöntemini belirliyoruz, mapping ve kuralları oluşturuyoruz, bağlantıyı tanımlıyoruz ve mevcut yapıya ekliyoruz. MIP hibrit bir entegrasyon platformudur. Bu nedenle cloud ve on-premise sistemleri birlikte kullanan şirketlerde de aynı mimari üzerinden ilerleyebiliyoruz. Peppol tarafındaki ayrıntılar için
XRechnung saf XML formatıdır. Kamu kurumlarına giden faturalarda Almanya’nın ulusal standardı olarak öne çıkar.
ZUGFeRD ise hibrit bir formattır. PDF/A-3 dosyası ile makine tarafının işleyebileceği XML verisini tek dosyada birleştirir. Okunabilir belge bekleyen partnerler bu formatı tercih ediyor. Peppol BIS Billing 3.0 ise sınır ötesi alışverişte kullandığımız uluslararası profildir.
Bu yaklaşım her senaryoda aynı sonucu vermez. Birkaç sınırlamayı baştan paylaşmakta fayda var.
Süre partner sayısına, ERP sayısına ve veri kalitesine göre değişir. Tek ERP ve sınırlı partner grubu olan şirketlerde pilot aşamasını birkaç hafta içinde tamamlıyoruz. Çok şirketli ve çok formatlı yapılarda süre uzar. En belirleyici etken teknik bağlantı değil, ana veri hazırlığıdır.
Kararı partnerin beklentisi belirler, sizin tercihiniz değil. Kamu kurumlarına ve XML tabanlı süreç işleten partnerlere XRechnung gönderin. Okunabilir bir PDF bekleyen partnerlerde ZUGFeRD daha uygundur. Her iki format da EN 16931 ile uyumludur, bu yüzden ikisini paralel yürütebilirsiniz.
Çoğu projede gerekmiyor. Fatura verisini mevcut çıktı noktasından alıyoruz ve dönüşüm ile iletim işini entegrasyon katmanında yürütüyoruz. Bu sayede yıllardır çalışan ERP süreçlerini koruyoruz. Yalnızca eksik alanlar için ERP tarafında küçük eklemeler gündeme gelebilir.
Her fatura için gönderim durumunu, doğrulama sonucunu ve kanaldan dönen cevabı kayıt altına alıyoruz. Bir fatura hata alırsa hatanın hangi alanda çıktığını gösteriyoruz. Operasyon ekibi böylece teknik log okumadan ilgili faturayı bulur ve yeniden gönderim kararını hızlı verir.
Almanya SAP e-Fatura projelerine başlarken ilk sorumuz basit kalıyor: Bugün faturalarınız nasıl gidiyor? Cevabı aldıktan sonra tabloyu çıkarıyoruz, mimariyi çiziyoruz, verileri kontrol ediyoruz, pilot partnerlerle uçtan uca test yapıyoruz ve kapsamı adım adım genişletiyoruz.
Almanya tarafındaki yapı da zaten bunu gerektiriyor: birden fazla format, birden fazla iletişim yöntemi ve partnerden partnere değişen senaryolar. Biz de MIP üzerinde bu farklı akışları tek bir entegrasyon yapısı altında yönetiyoruz. Geçiş planınızı konuşmak için MDP Group ekibiyle iletişime geçebilirsiniz.
Adımlar şunlar: mevcut yapıyı çıkarma, hedef mimariyi tasarlama, veri kontrolü, pilot partnerlerle uçtan uca test ve kapsamı kademeli genişletme. İlk toplantılarda konu genellikle teknik taraftan açılıyor. XRechnung mı kullanacağız, ZUGFeRD mi, Peppol olacak mı, web servis bağlantısı mı kuracağız?
Biz bir adım geriden başlıyoruz. Önce şirketin bugün faturayı nasıl yönettiğini anlıyoruz. Kaç farklı ERP var, faturalar nereden çıkıyor, hangi partnerlerle çalışıyorsunuz, hangi formatları kullanıyorsunuz? Bu tabloyu çıkardıktan sonra nasıl bir yapı kuracağımız da netleşiyor.
Almanya SAP e-Fatura projesine neden mevcut yapıdan başlıyoruz?
Almanya tarafında tek bir doğru senaryo yok. Şirketler farklı formatlarla, farklı iletişim yöntemleriyle ve partnerden partnere değişen akışlarla çalışıyor. Bu yüzden mimari tartışmasını mevcut durumu görmeden başlatmıyoruz.
Mevzuat da bu ihtiyacı destekliyor. Almanya’da B2B e-fatura alma yükümlülüğü 1 Ocak 2025’te başladı. Gönderme zorunluluğu ise kademeli ilerliyor. 800.000 Euro üzeri ciroya sahip işletmeler 1 Ocak 2027’de, diğer tüm işletmeler 1 Ocak 2028’de kapsama giriyor.
Ayrıntılı takvim için
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
yazımıza bakabilirsiniz. Quadient ve OpinionWay araştırmasına göre işletmelerin yaklaşık yüzde 90’ı yeni kurallardan etkileniyor. Buna karşılık yüzde 70’i geçişi henüz tamamlamadı. Erken başlayan şirketler bu tabloda ciddi bir zaman avantajı kazanıyor.Adım 1: Önce mevcut yapıyı çıkarıyoruz
İlk iş mevcut fatura akışlarını masaya yatırıyoruz. Fatura hacmine bakıyoruz. ERP sistemlerini listeliyoruz. Şirketin kullandığı formatları, partnerleri, mevcut entegrasyonları ve gönderim yöntemlerini inceliyoruz.
Bu aşamada ilk toplantılarda konuşmadığımız detaylar da ortaya çıkıyor. Ekipler belirli bir müşteri için yıllar önce özel bir akış geliştirmiş olabiliyor. Bazı faturalar farklı bir kanaldan gidiyor olabiliyor. Bir noktada operasyon ekibi manuel müdahale yapıyor olabiliyor. Grup şirketleri aynı süreci farklı şekillerde yürütebiliyor.
Hangi soruları soruyoruz?
- Faturalar hangi ERP sisteminden ve hangi modülden çıkıyor?
- Aylık fatura hacmi ne kadar ve hangi partnerlerde yoğunlaşıyor?
- Partner hangi formatı bekliyor: XRechnung mı, ZUGFeRD mi?
- Fatura hangi kanaldan gidiyor: Peppol, web servis, e-posta veya mevcut bir provider?
- Hangi akışlarda manuel adım var ve bu adımı kim yürütüyor?
Bu detayları mümkün olduğunca başta görmek istiyoruz. Çünkü birazdan çizeceğimiz mimaride hepsinin bir karşılığı olacak.
Adım 2: Sonra hedef mimariyi çiziyoruz
Elimizde mevcut yapı olduğunda yeni akışın nasıl çalışacağını konuşmaya başlıyoruz. ERP’den çıkan fatura nereye gelecek? XRechnung mı hazırlayacağız, ZUGFeRD mi? Müşteri faturayı nasıl almak istiyor? Faturanın durumu ERP’ye geri dönecek mi? Hata olduğunda ekip bunu nereden görecek?
Burada tek bir akış çizip bütün partnerleri o akışa sokmuyoruz. Partnerin istediği format ve iletişim yöntemi neyse senaryoyu ona göre kuruyoruz. Örnek akışlar şöyle şekilleniyor:
- ERP → MIP → XRechnung → Peppol → Alıcı
- ERP → MIP → XRechnung → Web Servis → Alıcı
- ERP → MIP → ZUGFeRD → E-posta → Alıcı
Format ve kanal senaryoları
Format ve iletim kanalı iki ayrı karardır. Aşağıdaki tablo, sahada en sık karşılaştığımız kombinasyonları özetliyor.
| Senaryo | Format | İletim Kanalı | Tipik Kullanım |
| Kamu kurumuna fatura (B2G) | XRechnung (saf XML) | Peppol veya kamu portalı | Leitweg-ID zorunlu, KoSIT doğrulaması uygulanır |
| Peppol ağındaki B2B partner | XRechnung veya Peppol BIS Billing 3.0 | Peppol Access Point | Sınır ötesi ve büyük partnerler |
| Kendi web servisi olan partner | XRechnung | Web servis / API | Partnerin kendi entegrasyon altyapısı vardır |
| PDF görüntüsü isteyen partner | ZUGFeRD 2.x (PDF/A-3 + XML) | E-posta | KOBİ partnerler ve okunabilir belge ihtiyacı |
| Mevcut EDI akışı olan partner | EN 16931 uyumlu format | AS2 / AS4 / EDI | Alıcının onayıyla 2027 sonuna kadar geçerlidir |
MIP’i bu akışların merkezindeki entegrasyon katmanı olarak konumlandırıyoruz. ERP’den gelen veriyi alıyoruz, gerekli dönüşümleri yapıyoruz, ilgili formatı oluşturuyoruz ve partner için tanımladığımız kanala yönlendiriyoruz. Bir
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
temel işlevi de zaten budur.Yeni bir partner geldiğinde ERP tarafında sıfırdan entegrasyon geliştirmek yerine bu yapı üzerinden ilerliyoruz.
Adım 3: Faturayı göndermeden önce veriye bakıyoruz
Projelerde en fazla vakit kaybettiren konu veridir. Bağlantıları kuruyorsunuz, testlere başlıyorsunuz ve faturadaki zorunlu alanlardan birinin eksik olduğunu görüyorsunuz. Başka bir faturada vergi numarası beklenen formatta gelmiyor. Bir partnerin istediği bilgi ERP’den hiç çıkmıyor.
Bu yüzden ana veriyi, vergi bilgilerini, zorunlu alanları ve iş kurallarını akışın içine dahil ediyoruz. XRechnung hazırlayacaksak o formatın zorunlu alanlarını kontrol ediyoruz. Kamu kurumuna gidecek faturalarda Leitweg-ID gibi yönlendirme bilgilerini ayrıca doğruluyoruz. ZUGFeRD senaryosunda gömülü XML verisini gözden geçiriyoruz.
Faturadaki problemi karşı tarafa gönderdikten sonra değil, MIP tarafındayken görmek istiyoruz. Böylece operasyon ekibi hatayı daha rahat takip ediyor. Hatanın hangi alanda ve hangi adımda çıktığını görebilmek işleri epey kolaylaştırıyor.
Adım 4: Birkaç partnerle gerçek akışı deniyoruz
Mimari hazır olduğunda belirli partnerlerle pilot sürece geçiyoruz. ERP’de faturayı oluşturuyoruz. Veri MIP’e geliyor. Gerekli kontrolleri yapıyoruz. Partner XRechnung istiyorsa XRechnung, ZUGFeRD istiyorsa ZUGFeRD hazırlıyoruz. Ardından faturayı o partner için belirlediğimiz kanala gönderiyoruz.
Testlerde özellikle hata senaryolarını çalıştırıyoruz. Eksik alan gönderiyoruz. Format hatası oluşturuyoruz. Peppol tarafında bir hata döndüğünde nasıl yönettiğimize bakıyoruz. E-posta gönderiminde çıkabilecek problemleri kontrol ediyoruz.
Canlıya çıktıktan sonra ekipler en sık şu soruyu soruyor: “Bu fatura nerede kaldı?” Kurduğumuz yapının bu soruya hızlı cevap vermesini istiyoruz. Mevcut EDI altyapısı olan şirketlerde
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
da bu aşamada değerlendiriyoruz.Adım 5: Sonra kapsamı büyütüyoruz
Pilot tamamlandıktan sonra diğer partnerleri sisteme almaya başlıyoruz. Burada gruplar halinde ilerlemeyi tercih ediyoruz. Önce belirlediğimiz partnerler, ardından diğer gruplar ve varsa özel senaryolar geliyor.
Her yeni partnerde aynı iki soruyla başlıyoruz: Hangi formatı istiyor? Nasıl almak istiyor? Cevap XRechnung ile Peppol olabilir. XRechnung ile web servis olabilir. ZUGFeRD ile e-posta olabilir. Buna göre MIP üzerinde ilgili akışı oluşturuyoruz ve devreye alıyoruz.
Geçiş sırasında sonuçları da takip ediyoruz. Kaç fatura gönderdik, kaçı başarılı geçti, hangi faturalar hata aldı, hata hangi aşamada çıktı, yeniden gönderim yaptık mı? Bir süre sonra süreç oturuyor ve günlük operasyonun parçası haline geliyor.
Hedefimiz ekiplerin sürekli teknik logların arasında dolaşması değil. Bir problem çıktığında ilgili faturayı bulup ne yaşandığını hızlı görebilmeleri gerekiyor.
MIP bu süreçte ne yapıyor?
MIP’in görevini kısaca ERP ile Almanya e-fatura ekosistemi arasındaki entegrasyonu yönetmek olarak anlatabiliriz. SAP veya farklı ERP sistemlerinden gelen fatura verisini alıyoruz. Partnerin ihtiyacına göre gerekli dönüşümleri yapıyoruz. XRechnung veya ZUGFeRD oluşturuyoruz.
Ardından faturayı ilgili kanala yönlendiriyoruz: Peppol, web servis, e-posta veya kullandığınız provider. Gelen cevapları ve durum bilgilerini de ilgili sistemlere geri taşıyoruz.
MDP Group olarak bu yapıyı özellikle SAP tarafında mevcut entegrasyonları olan şirketlerde tercih ediyoruz. Yıllardır çalışan ERP süreçlerini mümkün olduğunca koruyoruz ve yeni e-fatura akışlarını entegrasyon katmanında yönetiyoruz. Böylece yeni bir partner geldiğinde konu tekrar başa dönmüyor.
Partnerin formatını ve iletişim yöntemini belirliyoruz, mapping ve kuralları oluşturuyoruz, bağlantıyı tanımlıyoruz ve mevcut yapıya ekliyoruz. MIP hibrit bir entegrasyon platformudur. Bu nedenle cloud ve on-premise sistemleri birlikte kullanan şirketlerde de aynı mimari üzerinden ilerleyebiliyoruz. Peppol tarafındaki ayrıntılar için
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
sayfamızı inceleyebilirsiniz.Almanya e-Fatura formatları arasındaki temel fark nedir?
XRechnung saf XML formatıdır. Kamu kurumlarına giden faturalarda Almanya’nın ulusal standardı olarak öne çıkar.
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
göre KoSIT bu standardı yürütür ve faturaların biçimsel doğruluğunu kontrol eden bir doğrulama aracı sunar.ZUGFeRD ise hibrit bir formattır. PDF/A-3 dosyası ile makine tarafının işleyebileceği XML verisini tek dosyada birleştirir. Okunabilir belge bekleyen partnerler bu formatı tercih ediyor. Peppol BIS Billing 3.0 ise sınır ötesi alışverişte kullandığımız uluslararası profildir.
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
de format ile iletim kanalını iki ayrı karar olarak ele alır. Avrupa genelindeki düzenlemelerin toplu görünümü için
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
yazımız iyi bir başlangıç noktası sunar.Nelere dikkat etmek gerekiyor?
Bu yaklaşım her senaryoda aynı sonucu vermez. Birkaç sınırlamayı baştan paylaşmakta fayda var.
- Almanya mevzuatı, yapılandırılmış veri içermeyen standart PDF faturaları EN 16931 anlamında e-fatura olarak kabul etmez. Geçiş süreleri dolduğunda bu belgeler usulüne uygun fatura niteliğini kaybeder.
- Mevzuat arşivleme yükümlülüğünü XML verisi üzerinden tanımlar. GoBD kapsamında 10 yıllık saklama süresi geçerlidir. Yalnızca PDF görüntüsünü saklamak yeterli olmaz.
- Alıcı onay verirse EDI formatındaki faturaları kullanabilirsiniz. Bu esneklik geçiş dönemiyle sınırlı kalır.
- UStG madde 19, küçük işletmecileri fatura düzenleme yükümlülüğünden muaf tutar. Ancak alma yükümlülüğü onlar için de sürer.
- Mevzuat değişebilir. Proje planınızı yaparken güncel BMF duyurularını takip etmenizi öneriyoruz.
Sıkça Sorulan Sorular
Almanya SAP e-Fatura geçişi ne kadar sürer?
Süre partner sayısına, ERP sayısına ve veri kalitesine göre değişir. Tek ERP ve sınırlı partner grubu olan şirketlerde pilot aşamasını birkaç hafta içinde tamamlıyoruz. Çok şirketli ve çok formatlı yapılarda süre uzar. En belirleyici etken teknik bağlantı değil, ana veri hazırlığıdır.
XRechnung mı ZUGFeRD mi kullanmalıyım?
Kararı partnerin beklentisi belirler, sizin tercihiniz değil. Kamu kurumlarına ve XML tabanlı süreç işleten partnerlere XRechnung gönderin. Okunabilir bir PDF bekleyen partnerlerde ZUGFeRD daha uygundur. Her iki format da EN 16931 ile uyumludur, bu yüzden ikisini paralel yürütebilirsiniz.
Mevcut SAP entegrasyonlarımı değiştirmem gerekir mi?
Çoğu projede gerekmiyor. Fatura verisini mevcut çıktı noktasından alıyoruz ve dönüşüm ile iletim işini entegrasyon katmanında yürütüyoruz. Bu sayede yıllardır çalışan ERP süreçlerini koruyoruz. Yalnızca eksik alanlar için ERP tarafında küçük eklemeler gündeme gelebilir.
Gönderdiğim faturanın durumunu nasıl takip ederim?
Her fatura için gönderim durumunu, doğrulama sonucunu ve kanaldan dönen cevabı kayıt altına alıyoruz. Bir fatura hata alırsa hatanın hangi alanda çıktığını gösteriyoruz. Operasyon ekibi böylece teknik log okumadan ilgili faturayı bulur ve yeniden gönderim kararını hızlı verir.
Sonuç
Almanya SAP e-Fatura projelerine başlarken ilk sorumuz basit kalıyor: Bugün faturalarınız nasıl gidiyor? Cevabı aldıktan sonra tabloyu çıkarıyoruz, mimariyi çiziyoruz, verileri kontrol ediyoruz, pilot partnerlerle uçtan uca test yapıyoruz ve kapsamı adım adım genişletiyoruz.
Almanya tarafındaki yapı da zaten bunu gerektiriyor: birden fazla format, birden fazla iletişim yöntemi ve partnerden partnere değişen senaryolar. Biz de MIP üzerinde bu farklı akışları tek bir entegrasyon yapısı altında yönetiyoruz. Geçiş planınızı konuşmak için MDP Group ekibiyle iletişime geçebilirsiniz.
Referanslar
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.
Bu bağlantıyı görüntüleyebilmek için kayıt olmalı zaten üyeyseniz üye girişi yapmalısınız.