BAE Peppol B2B e-fatura pilotu yayında ve Odoo'da yerel erişim noktası yok

BAE e-fatura pilotu yayında

BAE'de zorunlu e-faturalama 1 Temmuz 2026'da pilot aşamasına girdi ve dev.to'da yayımlanan teknik bir kılavuza göre, ülkede B2B fatura gönderen KDV kayıtlı her işletme, faturalarını artık BAE Peppol ağı üzerinden PINT AE XML formatında iletmek zorunda. Odoo dağıtımlarıyla çalışan geliştiriciler için yazı, acil bir boşluğa işaret ediyor: Odoo, BAE Peppol erişim noktası olmadan geliyor, yani iletim katmanı harici olarak eklenmek zorunda.

BAE Peppol ağı nasıl yapılandırılmış

dev.to makalesi standart Peppol dört köşe modelini anlatıyor: satıcının ERP'si, satıcının akredite servis sağlayıcısı (ASP), alıcının ASP'si ve alıcının ERP'si. Geliştiricilerin bağlandığı yer satıcı tarafındaki ASP. ASP her faturayı PINT AE şemasına göre doğrular, Peppol iletimini yönetir ve ERP'nin kaydedebileceği bir durum yanıtı döndürür.

Özellikle Odoo için önerilen akış, bir account.move kaydı postalandığı anı yakalar, fatura verisini ORM'den okur, PINT AE alanlarına eşler, XML'e serileştirir, ASP'nin API endpoint'ine gönderir ve dönen durumu fatura kaydına geri yazar.

PINT AE ne gerektiriyor

PINT AE, Peppol BIS Billing 3.0'ın BAE'nin ulusal uzantısıdır ve Maliye Bakanlığı'nın Elektronik Faturalama Kılavuzu'nun 1.1 sürümünde tanımlanmıştır; yazı bu kılavuzu Haziran 2026 olarak tarihlendiriyor. Her B2B fatura, ASP'nin iletebilmesi için önce şema doğrulamasından geçmek zorundadır.

Şema, BT kodlarıyla tanımlanan 17 zorunlu alan listeler. Bunlar fatura numarasını, ISO 8601 tarihini, bir tip kodunu (standart fatura için 380, iade faturası için 381), ISO 4217 para birimi kodunu, satıcı ve alıcı için isimleri, 15 haneli TRN'leri, sokak adreslerini, şehirleri ve ülke kodlarını, ayrıca satır net tutarları toplamını, toplam KDV tutarını ve satır başına net tutarları kapsar. Satıcının ülke kodu AE olmalıdır.

Başlığın ötesinde, her fatura satırı dört KDV kategori kodundan birini taşımalıdır: %5 standart oran için S, ihracat gibi sıfır oranlı teslimler için Z, muaf teslimler için E ve kapsam dışı işlemler için O. Ölçü birimleri UN/CEFACT kodları olarak ifade edilmelidir, örneğin EA, KGM, LTR veya HUR.

Eşlemenin Odoo tarafı

Yazı, her BT alanını Odoo modellerine eşliyor: fatura düzeyindeki alanlar account.move'a, satıcı bilgileri res.company'ye, alıcı bilgileri res.partner'a ve satır tutarları account.move.line'a düşüyor. İki parça standart Odoo'da mevcut değil. Ölçü birimlerinde UN/CEFACT kodu yok ve vergi kayıtlarında PINT AE kategorisi bulunmuyor. Her ikisi de özel alanlar gerektiriyor; makale bunları uom.uom üzerinde eklenen bir kod alanı ve account.tax üzerinde veri dosyalarıyla doldurulan bir KDV kategorisi seçim alanı olarak modelliyor.

Darboğaz şema değil, veri kalitesi

Yazarın temel argümanı, şema uyumunun kolay kısmı olduğu; mevcut Odoo veritabanlarındaki dağınık verinin uygulamaları asıl sekteye uğratan şey olduğudur. Beş hata BAE dağıtımlarında tekrar tekrar karşımıza çıkıyor: alıcı TRN'lerinin eksik olması (yazıya göre tipik veritabanlarında müşteri kayıtlarının %20-40'ında görülüyor); sokak ve şehrin tek bir sokak alanına sıkıştırılmış olması; ölçü birimlerinde UN/CEFACT kodlarının eksikliği; vergi kayıtlarında KDV kategorisinin bulunmaması; ve müşteri kayıtlarında BAE mali pozisyonlarının ayarlanmamış olması ki bu, vergi satırlarının doğru kategoriyi taşımasını engelliyor.

Önerilen çözümler gösterişsiz: toplu partner import'u, BAE müşterileri için vergi numarasını zorunlu kılan kısıt kontrolleri, birleşik adresleri ayırmak için migration script'leri ve birim ile vergi kodlarını geri dolduracak veri dosyaları.

ASP ile konuşmak

Yazıya göre API deseni FTA onaylı çoğu ASP'de benzer: XML payload'ını bir bearer token ve fatura tanımlayıcı header'ı ile POST edin. 200 yanıtı faturanın gönderildiği anlamına gelir ve bir Peppol ID ile zaman damgası döndürür; 422 ise connector'ın kullanıcılara gösterebileceği yapılandırılmış doğrulama hataları döndürür.

Neden önemli

BAE zorunluluğu, e-faturalamayı bir biçimlendirme meselesinden, beraberinde bir uyum yükü taşıyan canlı bir entegrasyon projesine dönüştürüyor. Yerel Peppol bağlantısı olmayan ERP'ler — Odoo bunlardan biri — geçerli tek bir fatura sistemden çıkmadan önce connector'lara, özel alanlara ve daha maliyetli olarak veri temizliğine ihtiyaç duyuyor. Bu desen ayrıca taşınabilir: Peppol diğer yargı bölgelerindeki benzer rejimlerin temelini oluşturuyor, dolayısıyla burada belgelenen alan eşlemeleri ve hata modları geniş ölçüde yeniden kullanılabilir. Ve ASP doğrulamadan geçmeyen XML'i reddettiği için, eksik müşteri kayıtları artık doğrudan bir nakit akışı maliyeti taşıyor; çünkü iletilemeyen faturalar tahsil edilemez.