ERP'de e-Fatura ve e-İrsaliye Entegrasyonu Nasıl Kurulur?

Akşam altı. Depo son kolileri bantlamış, kargo aracı yolda. Muhasebede biri hâlâ portalda tek tek belge kesiyor: kırk siparişin yirmi beşinde alıcı bireysel, on ikisinde şirket, üçünde vergi numarası yanlış girilmiş. ERP e-Fatura entegrasyonu konuşulmaya çoğunlukla tam burada başlanır; belge üretimi operasyonun hızına yetişemediğinde.

İşin zor tarafı belgeyi otomatik göndermek değil. Asıl soru şu: hangi belge, hangi anda, hangi sistem tarafından üretilecek ve bir yerde hata çıkarsa siparişin başına ne gelecek?

Üç belge, üç ayrı karar

E-ticaret tarafında konuşulan belge genellikle tek bir şeymiş gibi anlatılır. Değildir. Alıcının e-Fatura uygulamasına kayıtlı olup olmadığı ve malın fiziken hareket edip etmediği, üretilecek belgeyi doğrudan değiştirir.

Burada sık karıştırılan bir nokta var: mükellef olmak ile e-Fatura uygulamasına kayıtlı olmak aynı şey değil. Vergi mükellefi olduğu hâlde e-Fatura kullanıcısı olmayan bir firmaya e-Arşiv fatura düzenlenir. Belge kararını mükellefiyet varsayımına değil, sorgunun sonucuna bağlayın.

Karşı taraf e-İrsaliye kapsamında değilse fiziki irsaliye yolu açık kalır; yani deponuz iki farklı çıktıyı da üretebilmeli ve paketleyen kişi hangisinin basılacağını ekrandan görmeli. Kimin hangi kapsama girdiği GİB'in belirlediği ciro ve sektör kriterlerine göre değişiyor, kapsam da zaman içinde genişliyor; bu kısmı mali müşavirinizle güncel tutmakta fayda var.

Mükellef sorgusu sipariş anında yapılmalı

Alıcının e-Fatura kullanıcısı olup olmadığı, entegratör üzerinden sorgulanabilen bir bilgidir. Çoğu projede bu sorgu fatura kesileceği anda yapılır ve orada tıkanır. Doğrusu, sorguyu sipariş düşer düşmez çalıştırıp sonucu siparişin üzerine yazmaktır: alıcı tipi, varsa etiket bilgisi ve sorgunun yapıldığı tarih.

Neden sipariş anında? Çünkü liste değişkendir. Bugün kayıtlı olmayan bir firma üç hafta sonra kapsama girebilir. Siparişin alındığı andaki durumu saklamazsanız, ay sonunda "bu belge neden e-Arşiv kesilmiş" sorusuna cevap veremezsiniz. Birkaç yüz sipariş alan bir günde bu sorguyu her belgede tek tek çalıştırmak entegratörde gereksiz yük yaratır; kayıtlı kullanıcı listesini günlük çekip yerelde tutmak daha rahat çalışıyor.

Basit alan kontrolleri de burada devreye girsin: vergi numarası on hane, TC kimlik numarası on bir hane, unvan boş değil. Bu üç kontrol, sonradan iptal edilecek belgelerin önemli bir kısmını baştan eler. Eksik bilgiyi sipariş günü sormak, faturayı kestikten sonra düzeltmekten kolaydır.

Kurumsal satışta bir karar daha var: faturanın hangi senaryoyla gönderileceği. Temel senaryoda alıcı belgeye sistem üzerinden ret yanıtı gönderemez; ticari senaryoda gönderebilir ve o yanıtın ERP'ye işlenmesi gerekir. Ret gelen faturanın siparişte hangi duruma düşeceğini tanımlamazsanız, belge kimsenin bakmadığı bir kuyrukta kalır.

Fatura hangi anda kesilecek?

Sipariş sonrası otomatik fatura kesme kurgusunda iki yaygın tercih var ve ikisi de savunulabilir. Ödeme alındığı anda kesmek muhasebeyi rahatlatır, tahsilat ile belge aynı güne düşer. Ama iptal oranı yüksek kanallarda iade ve düzeltme belgesi sayısını da yukarı çeker.

Sevkiyat anında kesmek gerçeğe daha yakın: fatura, gerçekten çıkan mal için üretilir. Bedeli, deponun gecikmesinin faturayı da geciktirmesi. Bu tercihin bir sınırı var; belgenin düzenlenme süresi mevzuatla bağlı olduğundan sevkiyatı bekleyen sipariş sınırsız bekleyemez. Süreyi mali müşavirinizle netleştirip sisteme uyarı olarak koyun: eşiği aşan açık sevkiyatlar her sabah bir listeye düşsün.

İkisini aynı anda yürütmek de mümkün. Ön ödemeli siparişte ödeme anında, kapıda ödemede sevk anında kesmek gibi bir ayrım çoğu kurulumda sorunsuz çalışıyor. Yeter ki kural kanal ve ödeme tipi bazında tanımlanabilsin ve nerede hangi kuralın çalıştığı tek bir ekrandan görülebilsin.

Belgenin ne zaman kesileceği kadar neyle kesileceği de önemli. İnternetten yapılan satışlarda e-Arşiv faturada ödeme şekli, ödeme tarihi, satışın yapıldığı site ve taşıyıcı bilgisi gibi alanlar isteniyor. Bu veriler sipariş kaydında zaten duruyor; entegrasyon belgeye taşımıyorsa muhasebe her faturayı elle tamamlıyor.

Kısmi sevkiyatta belge nasıl bölünür?

Üç kalemli bir siparişte iki kalem bugün çıkıyor, biri tedarikçi bekliyor. İki yol var: sevkiyat tamamlanana kadar bekleyip tek fatura kesmek ya da her sevkiyat için ayrı belge üretmek. İkincisini seçtiyseniz kargo bedelinin hangi belgeye bineceğine ve indirim tutarının kalemler arasında nasıl dağıtılacağına baştan karar verin. ERP tarafında sipariş, sevkiyat ve fatura üç ayrı kayıt olarak tutulmalı; ilişki tek yönlü değil, her sevkiyat kendi faturasını işaret edebilmeli.

ERP entegratörle doğrudan mı konuşsun?

İki desen var. Birincisinde ERP'nin e-belge modülü entegratöre doğrudan bağlanır; belge ERP'de oluşur, oradan gönderilir. İkincisinde araya bir entegrasyon servisi girer: sipariş servis içinde belgeye dönüşür, entegratöre gider, dönen yanıt hem ERP'ye hem mağazaya yazılır.

Tek bir ERP ve tek bir satış kanalı varsa doğrudan bağlantı yeter. Üç mağaza, iki pazaryeri ve bayi siparişi bir aradaysa ara servis işi kolaylaştırır; e-Fatura entegratör bağlantısını tek yerde yönetir, kanal başına ayrı kural yazabilirsiniz. Nebim V3 gibi e-belge tarafı olgun ERP'lerde bile çok kanallı kurulumlarda bu ara katmanı tercih ediyoruz. Kanal bazlı sipariş akışının nasıl kurulduğunu Nebim V3 e-ticaret entegrasyonu yazımızda ayrıntılı anlatmıştık.

Belge numarası ve serinin sahibi kim?

Bu konuda tek bir sahip olmalı. Numarayı ERP veriyorsa entegratör yalnızca taşıyıcıdır. Numarayı entegratör veriyorsa ERP'deki fatura kaydı bir süre numarasız kalır ve o aradaki her rapor eksik çıkar. Hangisini seçerseniz seçin, serilerin kanal bazında ayrılması (mağaza, pazaryeri, bayi) ay sonu ayıklamayı ciddi biçimde kolaylaştırıyor.

Aynı siparişe iki belge kesilmesin

Mükerrer fatura, bu işin en can sıkıcı hatası. Sebebi neredeyse her zaman aynı: istek gönderilir, yanıt zaman aşımına uğrar, sistem "başarısız" varsayıp yeniden dener.

Entegratörden gelen zaman aşımı, belgenin kesilmediği anlamına gelmez. Yeniden denemeden önce "bu anahtarla belge zaten var mı" diye sormayan her akış, er ya da geç mükerrer fatura üretir.

Korunma yolu bilinen bir desen. Her belge isteğine sipariş numarası, belge tipi ve sevkiyat numarasından türetilmiş bir idempotency anahtarı verilir; entegratör bu anahtarı destekliyorsa doğrudan kullanılır. Desteklemiyorsa koruma sizde kurulur ve tek başına sorgulamaya güvenmeyin: yoğun saatte aynı belgeyi paralel iki iş birden "henüz kesilmemiş" görüp gönderebilir. Anahtarı kendi tarafınızda benzersiz bir kayda bağlayın, ikinci deneme kuyruğa girerken elensin. İstekler kuyruğa alınır, hata durumunda artan aralıklarla yeniden denenir: önce saniyeler, sonra dakikalar. Beş denemeden sonra hâlâ geçmiyorsa iş hata kuyruğuna düşer ve makine uğraşmayı bırakır.

İade, iptal ve tutar düzeltmesi

Bir iadenin üç ayağı var ve üçü de birbirini tutmak zorunda: belge tarafında düzeltme, depo tarafında stok geri girişi, finans tarafında ödemenin müşteriye dönmesi. Pratikte bunlar farklı zamanlarda gerçekleşiyor ve arada boşluk kalıyor.

1. Kargo geri geldi, kutu açılmadı: Belge tarafında henüz bir işlem yapmayın. Ürün mal kabulden geçmeden iade belgesi üretmek, olmayan bir stoğu kayda almak demek.
2. Ürün kontrol edildi, kabul edildi: Belge tarafındaki düzeltme ile stok geri girişi aynı işlemin iki parçası olarak üretilmeli. Biri olup diğeri olmazsa fark ay sonunda çıkar.
3. Ürün hasarlı, iade reddedildi: Stok girişi yapılmaz ama müşteriye dönüş kaydı tutulur; belge üretilmez.
4. Kısmi iade: Yalnızca dönen kalemler ve o kalemlere düşen kargo/indirim payı düzeltilir.

Ayrım alıcının kim olduğunda başlıyor: mükellef olmayan bireysel bir müşteri size iade faturası kesemez, dolayısıyla günlük konuşmada "iade faturası" dediğimiz şey her senaryoda aynı belge değildir. e-Arşiv fatura ile e-Fatura'nın düzeltme yolları da aynı değil. Birinde belirli koşullarda iptal mümkünken, diğerinde karşı tarafın belge kesmesi ya da tarafınızca düzeltme belgesi üretilmesi gerekebiliyor. Hangi yolun geçerli olduğu belge tipine ve tarafların durumuna göre değişir; bu ayrımı mali müşavirinizle netleştirip akışa öyle gömün. Üç ayağın birbirini kaybetmemesi için iade kaydının tek yerde tutulması gerekiyor; İade Yönetim Paneli projemiz iade sebebini, ödeme iadesini ve müşteri bilgilendirmesini aynı kayda bağlıyor, belge tarafı ERP'de üretilmeye devam ediyor.

e-İrsaliye, sevkiyat ve kargo takibi

e-İrsaliye entegrasyonu, fatura entegrasyonundan farklı bir zamanlamada çalışır. İrsaliye malın yanında hareket eder; sevk tarihi, saati ve taşıyıcı bilgisi belgeye yazılır. Yani belge, koli kapandıktan sonra ama araç çıkmadan önce üretilmiş olmalı.

Sağlıklı sıra şöyle: paket kapanır, kargo firmasından barkod alınır, taşıyıcı bilgisiyle birlikte e-İrsaliye üretilir, dönen takip numarası mağazanın sipariş kaydına geri yazılır ve müşteriye bildirim gider. Sahada en çok şurada tıkanılıyor: koli araca yüklenmiştir, irsaliye hâlâ kuyrukta bekliyordur. Bunun önüne geçmek için sevk onayı ile belge üretimini aynı işleme bağlayın, belge dönmeden koliyi "sevk edildi" durumuna almayın. Bildirim ve takip numarası geri yazımı gibi adımları süreç otomasyonu tarafında kurguluyoruz.

Bayi ve toptan sevkiyatta akışın bir ayağı daha var: alıcının gönderdiği e-İrsaliye yanıtı. Kısmi kabul ya da ret geldiğinde hangi kaydın düzeltileceği baştan tanımlı değilse, fark ancak mutabakat masasında görülüyor.

Belge kesilemediğinde ne olacak?

Sessizce başarısız olan bir e-belge akışı, hiç olmayan akıştan daha pahalıdır. Hatanın operasyona ulaşması için birkaç şeyin hazır olması lazım:

• Hata kuyruğu ekranı: Hangi sipariş, hangi belge tipi, kaçıncı denemede, hangi mesajla takıldı; hepsi tek listede görünmeli.
• Anlaşılır hata metni: Entegratörün döndürdüğü kod, operasyonun anlayacağı bir cümleye çevrilmeli. "Alıcı VKN bulunamadı" ile ham bir hata kodu arasında dağlar var.
• Uyarı kanalı: Belirli bir eşiği geçen hata sayısı e-posta ya da mesaj olarak sorumluya düşmeli; kimse gün boyu ekrana bakmıyor.
• Manuel müdahale yolu: Düzeltilen kaydın tekrar kuyruğa atılabilmesi ve gerekirse belgenin elle kesilip numarasının sisteme işlenebilmesi.
• Sipariş durumu: Belge kesilemeyen sipariş "tamamlandı" görünmemeli; aksi halde hata ay sonuna kadar saklanır.

Ay sonu mutabakatı

Entegrasyon canlıya alındıktan sonra ilk birkaç ay rakamları elle karşılaştırmakta fayda var. Beş ayrı kaynak, aynı ayın beş ayrı hikâyesini anlatır; aradaki fark aksamanın nerede olduğunu gösterir.

Bu beş satırın birbirini tuttuğu ilk ay, entegrasyonun gerçekten oturduğu aydır. Öncesinde çıkan farklar tek tek küçük görünür, toplamda ikinci ayın işi olur. Nebim V3 üzerinde belge akışını kurup izlediğimiz çalışmaların kapsamı ERP çözümleri sayfasında.

Bu konuda nasıl yardımcı oluyoruz?

Yuog Dev olarak e-ticaret işletmelerinin ERP, entegrasyon ve otomasyon altyapısını kuruyoruz. İhtiyaç analiziyle başlıyor, ölçülebilir hedefler koyuyor ve teslim sonrasında da destek veriyoruz. Süreçlerinizi konuşmak isterseniz iletişim sayfasından bize ulaşabilirsiniz.