E-belge entegrasyonu nasıl kurulur, hataları nasıl çözülür

E-belge entegrasyonu, satış ve satın alma belgelerinin kendi yazılımınız içinde üretilip onaylı bir e-belge kanalına iletilmesi ve dönen yanıtın kayıt altına alınmasıdır. İşin özü üç adımdır: belge verisini eksiksiz hazırlamak, gönderim sonucunu kaydın üzerinde bir durum olarak saklamak, hatayı kullanıcının anlayacağı dille geri vermek. Bu üçü kurulmadığında entegrasyon teknik olarak çalışır ama muhasebe tarafında güven vermez, çünkü kimse hangi belgenin gittiğini, hangisinin takıldığını tek ekrandan göremez.

Entegrasyon hangi adımlardan oluşur

Akış her zaman aynı iskelete oturur. Kullanıcı ya da iş akışı bir belgeyi oluşturur, yazılım belgeyi doğrular, gönderim sırasına koyar, kanaldan dönen yanıtı kaydın üzerine yazar ve sonucu arayüzde gösterir. Gönderimi kullanıcının tıklamasına bağlı tek bir adım gibi kurmak en sık yapılan hatadır; ağ koptuğunda kullanıcı aynı belgeyi ikinci kez gönderir.

1. Hazırlık: belge satırları, vergi oranları ve taraf bilgileri yazılım içinde tamamlanır.
2. Doğrulama: zorunlu alanlar ve toplam tutarlar gönderimden önce kontrol edilir.
3. Sıraya alma: belge bir kuyruğa yazılır, gönderim arka planda yapılır.
4. Yanıtın işlenmesi: kabul, red veya bekleme yanıtı belgenin durumuna işlenir.
5. Mutabakat: belirli aralıklarla yazılımdaki belge listesi kanaldaki liste ile karşılaştırılır.

Kuyruk ve yeniden deneme mantığı için entegrasyon mimarisi yazısındaki yaklaşım geçerlidir; e-belge tarafı bu iskeletin üstüne kendi doğrulama kurallarını ekler. Pratikte en çok fayda veren ayrıntı, gönderimi kullanıcı arayüzünden ayırmaktır: kullanıcı belgeyi kaydeder ve işine döner, gönderimi arka plan işi yürütür, sonucu bildirim veya liste ekranındaki durum sütunu gösterir. Böylece yavaş yanıt veren bir kanal kullanıcının ekranını kilitlemez ve kimse sayfayı yenileyerek ikinci belge üretmez.

Belge verisi hazırlanırken en çok nerede hata yapılır

Red yanıtlarının büyük kısmı kanalın değil, kaynak verinin sorunudur. Müşteri kartındaki vergi kimlik bilgisi eksiktir, birim adı serbest metindir, ıskonto satır yerine toplam üzerinden hesaplanmıştır. Bu alanlar belge üretildiği anda değil, cari ve ürün kartı açılırken denetlenirse red sayısı kendiliğinden düşer.

Gönderim sonucu nasıl saklanır

Belgenin tek bir gönderildi işareti yetmez. Kaydın üstünde en az şu alanlar durur: iç durum, kanalın verdiği belge kimliği, son yanıt zamanı, son hata metni ve deneme sayısı. Böylece bir kullanıcı sorduğunda cevap tahmin değil, kayıt olur.

• hazır — belge oluştu, henüz sıraya girmedi.
• sırada — gönderim kuyruğunda bekliyor.
• gönderildi — kanal isteği aldı, sonuç bekleniyor.
• kabul — yanıt olumlu, belge kimliği kayıtlı.
• red — yanıt olumsuz, hata metni kayıtlı ve kullanıcıya görünür.
• iptal — belge muhasebe onayıyla geçersiz kılındı.

Durum geçişlerini serbest bırakmamak gerekir; kabul almış bir belge tekrar hazır konumuna düşmemelidir. Durum kümesini tasarlarken durum akışı tasarımındaki kural geçerlidir: izinli geçişler listelenir, listede olmayan geçiş kodla engellenir.

Reddedilen belge geldiğinde ne yapılır

Red yanıtı teknik bir kayıt değil, bir iş adımıdır. Kullanıcı hata metnini olduğu gibi değil, ne yapması gerektiğini söyleyen bir cümleyle görmelidir: hangi alan eksik, hangi ekrandan düzeltilecek. Düzeltme sonrası yeni gönderimin aynı belge üzerinden mi yoksa yeni bir belge olarak mı yapılacağı baştan karara bağlanır; bu karar muhasebe biriminin çalışma biçimine göre verilir ve yazılım bunu tek bir yolla uygular.

İptal ve yeniden düzenleme yetkisi herkese açılmaz. Belgeyi kim iptal edebilir, kim yeniden gönderebilir sorusunun cevabı rol tanımında yazılı olur; rol ve yetki yönetimi burada doğrudan devreye girer.

Mutabakat: iki listeyi karşılaştırmak

Entegrasyonun sessiz arızası, belgenin yazılımda kabul görünüp kanalda bulunmaması ya da tersidir. Bunu yakalamanın tek yolu düzenli karşılaştırmadır: seçilen dönem için yazılımdaki belge sayısı, toplam tutarı ve belge kimlikleri kanaldan okunan listeyle eşleştirilir. Eşleşmeyen kayıtlar bir fark raporuna düşer ve kimse elle sayım yapmak zorunda kalmaz.

• Dönem bazlı belge sayısı farkı.
• Aynı kimlikle iki kez kayıtlı belge.
• Kanalda olup yazılımda karşılığı olmayan belge.
• Durumu gönderildi aşamasında asılı kalmış, yanıtı hiç işlenmemiş belge.

Fark raporunun en değerli özelliği eskimemesidir. Bir hafta önceki farkı bugün görmek işe yaramaz; rapor günlük üretilip sorumlu kişinin göreceği bir yere düşürülürse fark sayısı genellikle tek haneye iner ve orada kalır.

Gelen belge tarafı da planlanır

Entegrasyon konuşulurken genellikle yalnızca giden belgeler düşünülür, oysa gelen belgelerin kayda alınması da aynı akışın parçasıdır. Tedarikçiden gelen belgenin satın alma kaydıyla eşleştirilmesi, eşleşmeyenin bir bekleyen listesine düşmesi ve onay adımının kime ait olduğu baştan tanımlanmalıdır. Eşleştirme ölçütü belge numarası, tutar ve taraf kimliği üçlüsüdür; üçü de tutuyorsa otomatik eşleşir, biri tutmuyorsa kullanıcı onayına gider.

Bu tarafı ihmal etmenin maliyeti ay sonunda görülür: muhasebe gelen belgeleri elle girer, satın alma kaydı ile belge arasındaki bağ kurulamaz ve ödeme planı belgeye değil hafızaya dayanır. Gelen belge akışı kurulduğunda satın alma, stok girişi ve ödeme adımları aynı kayıt üzerinden izlenebilir hale gelir.

Kısa kontrol listesi

• Zorunlu alan denetimi gönderim anında değil, kart kaydında yapılıyor.
• Gönderim arka planda, kuyruk üzerinden ve yeniden denemeye dayanıklı çalışıyor.
• Her belgede iç durum, kanal kimliği, son hata ve deneme sayısı saklanıyor.
• Red yanıtı kullanıcıya yapılacak işi söyleyen bir mesaja çevriliyor.
• İptal ve yeniden gönderim yetkisi role bağlı.
• Dönemsel mutabakat raporu otomatik üretiliyor.

Özet: e-belge entegrasyonu bir aktarım işi değil, veri kalitesi ve durum yönetimi işidir. KAV Yazılım bu akışı mevcut muhasebe ve sipariş süreçlerinize göre kurar; kapsam ve yöntem hizmetlerimiz sayfasındaki çerçevede belirlenir.