Muhasebe ve ERP Entegrasyonu: Sipariş, Stok ve Fatura Nasıl Konuşur?

Bir e-ticaret sitesi yayına girer, siparişler gelmeye başlar ve ilk haftanın sonunda muhasebeden aynı soru gelir: “Bu siparişleri programa ben mi tek tek gireceğim?” Birkaç sipariş varken cevap evet olabilir. Günde onlarca sipariş geldiğinde ise bu iş bir kişinin bütün gününü doldurur ve hatasız yapılması neredeyse imkânsız hâle gelir.

Aynı sahne bayilere açılan sipariş portallarında, saha ekiplerinin kullandığı uygulamalarda ve firmaya özel yazılımlarda da yaşanıyor. Türkiye'de pek çok firma Logo, Mikro, Netsis gibi muhasebe ve ERP programlarıyla çalışıyor. Web tarafındaki sistem bu programlarla konuşmadığında, ekipten biri iki sistem arasında veri taşıyan bir köprüye dönüşüyor.

Entegrasyonu tek bir “bağlantı” gibi düşünmek yanıltıcı. Aslında ayrı ayrı tasarlanması gereken birkaç veri akışından ve bu akışların arızalandığı gün ne olacağına dair birkaç karardan oluşuyor.

Dört ayrı akış: cari, stok, sipariş, fatura

Cari hesaplar

Siteden üye olan ya da sipariş veren müşterinin muhasebede bir cari karta dönüşmesi gerekir. İlk karar şu: Her müşteri için ayrı cari mi açılacak, yoksa bireysel müşteriler tek bir perakende carisinde mi toplanacak? Kurumsal müşterilerde vergi numarası ve vergi dairesi zorunlu. Aynı firmanın ikinci kez cari olarak açılmaması için eşleştirmenin neye göre yapılacağı, vergi numarasına mı e-posta adresine mi bakılacağı baştan belirlenmeli.

Stok ve fiyat

Ürün kartları genellikle ERP'de doğar. Stok kodu, birim, KDV oranı ve çoğu zaman fiyat oradan gelir. Web tarafı ise ürün açıklamasını, görselleri, kategori yapısını ve site içi kampanyaları tutar. Stok miktarı ise en sık değişen bilgi; hangi aralıklarla aktarılacağı ayrıca verilmesi gereken bir karar.

Sipariş

Sitede oluşan sipariş ERP'ye sipariş fişi olarak mı, yoksa doğrudan irsaliye ya da fatura olarak mı düşecek? Kargo bedeli, kupon indirimi, kapıda ödeme ücreti gibi kalemler muhasebede nasıl karşılık bulacak? Bu soruların cevabı firmanın muhasebe düzenine göre değişiyor ve mali müşavirle birlikte verilmesi en doğrusu.

Fatura

Fatura çoğu yapıda ERP'de kesilir. Fatura numarası, tarihi ve belgenin kendisi siteye ya da müşteri paneline geri döner. Böylece müşteri faturasını kendi hesabından görebilir, destek ekibi de ayrı bir programa bakmadan siparişin hangi aşamada olduğunu bilir.

Hangi sistem ana kaynak olacak?

Entegrasyon projelerinde en çok sorun çıkaran konu teknik değil, belirsizliktir. Aynı bilgi iki sistemde de değiştirilebiliyorsa, bir gün ikisi farklı değer gösterir ve hangisinin doğru olduğunu kimse söyleyemez.

Her veri türünün tek bir sahibi olmalı.

Tipik bir dağılım şöyle olabilir: Stok miktarı, fiyat ve cari bakiyesi ERP'de; ürün açıklaması, görseller ve site kampanyaları e-ticaret tarafında. Sipariş sitede doğar, ERP'ye aktarıldıktan sonra muhasebe tarafında yaşamaya devam eder. Bu dağılım her firmada farklı olabilir. Önemli olan, kararın yazılı olması ve herkesin aynı tabloya bakması.

Bir fiyatı sitede düzeltip ERP'de düzeltmeyi unutan bir personel, bu kural yoksa ertesi sabah iki farklı fiyatla satış yapıldığını fark eder. Kural varsa, sitede fiyat alanı zaten düzenlemeye kapalıdır.

Tek yönlü mü, çift yönlü mü?

Tek yönlü entegrasyonda veri yalnızca bir yöne akar; örneğin siparişler siteden ERP'ye gider ve geriye bir şey dönmez. Kurulumu ve bakımı daha kolaydır. Çift yönlü yapıda ise stok ve fiyat ERP'den siteye, sipariş siteden ERP'ye, fatura bilgisi yeniden siteye akar.

Çift yönlü entegrasyonun her alanda gerekli olduğunu düşünmüyoruz. İki sistemin aynı alanı birbirine yazdığı yapılar çakışma kurallarını da beraberinde getirir: Aynı kayıt iki tarafta aynı anda değişirse hangisi geçerli sayılacak?

Mümkün olan her alanda tek yönlü akışla başlayın, ikinci yönü ihtiyaç netleştikçe ekleyin.

Anlık mı, belirli aralıklarla mı?

Her verinin aynı hızda akması gerekmiyor. Sipariş aktarımının birkaç dakika gecikmesi çoğu firmada sorun yaratmaz. Stok bilgisinin gecikmesi ise son ürünün iki ayrı müşteriye satılması demek olabilir. Ürün açıklamaları gibi seyrek değişen veriler günde bir kez eşitlense yeter.

Bu ayrımı yapmak ERP'nin yükünü de hafifletir. Her dakika bütün ürün listesini sorgulayan bir entegrasyon, muhasebe ekibinin programı yavaşlattığı için şikâyet ettiği bir entegrasyona dönüşebilir. Mümkünse yalnızca değişen kayıtları taşımak gerekir.

Eşleştirme: iki sistem aynı dili konuşmuyor

Sitede “Kredi kartı” olarak görünen ödeme türü ERP'de bir kasa ya da banka hesabına karşılık gelir. Sitedeki kargo firması, ERP'de bir masraf kalemi ya da hizmet kartıdır. Sitedeki ürün varyantı, ERP'de ayrı bir stok kodu olabilir. Bu karşılıkların her biri için bir eşleştirme tablosu gerekir.

Eşleştirmelerin kod içine gömülmemesi, yönetim panelinden düzenlenebilmesi önemli. Yeni bir ödeme yöntemi ya da yeni bir kargo firması eklendiğinde yazılımcıyı beklemek zorunda kalmamalısınız.

e-Fatura ve e-Arşiv tarafı

Web sitesi ya da e-ticaret altyapısı genellikle faturayı kendisi düzenlemez. Pratikte e-Fatura ve e-Arşiv süreçleri çoğunlukla ERP'nin ilgili modülü ya da bir özel entegratör üzerinden yürür. Site siparişi aktarır, fatura muhasebe tarafında oluşur, sonuç siteye geri bildirilir.

Bazı yapılarda e-ticaret sistemi entegratörle doğrudan konuşur. Bu da mümkün, ama o zaman muhasebe kayıtlarıyla fatura kayıtlarının ayrıca eşleştirilmesi gerekir. Hangi faturanın hangi türde düzenleneceği gibi konular ise yazılımın değil mali müşavirinizin alanı; entegrasyonu onun belirlediği düzene göre kurmak gerekir.

Bağlantının kendisi

ERP programlarının çoğu dış yazılımlarla veri alışverişi için bir servis ya da entegrasyon aracı sunar. Hangi yöntemin kullanılabileceği programın sürümüne ve sahip olduğunuz lisansa göre değişebildiği için, bu konuyu projenin başında programınızın bayisi ya da destek firmasıyla birlikte netleştirmek gerekir. Bazen entegrasyon için ek bir lisans ya da modül gerektiği bu görüşmede ortaya çıkıyor.

Önermediğimiz bir yöntem de var: ERP'nin veritabanına doğrudan kayıt yazmak. Kısa vadede hızlı görünür, ama programın iç kurallarını atladığı için tutarsız kayıtlar üretebilir ve program güncellendiğinde sessizce bozulabilir. Raporlama için sınırlı okuma erişimi ayrı bir konu; yazma işlemlerinde programın kendi sunduğu yolu kullanmak gerekir.

Masada kimler olmalı?

Bir entegrasyon projesi birden fazla tarafın sorumluluk alanına dokunur: web tarafını geliştiren yazılım ekibi, ERP programının bayisi ya da destek firması ve firmanın kendi muhasebe ekibi. Sorun çıktığında herkes topu bir diğerine atabilir. “Bizim tarafta her şey doğru görünüyor” cümlesini aynı hafta içinde farklı ağızlardan duymak hiç de ender değil.

Bunu önlemenin yolu, sorumlulukları işin başında yazıya dökmek. Hangi alanın ERP'de hangi alana yazılacağını kim onaylayacak? ERP tarafında gereken ayarları kim yapacak? Aktarılan bir kaydın muhasebe açısından doğru olduğunu kim kontrol edecek? Bu toplantıya mali müşavirin bir kez katılması, sonradan yapılacak pek çok düzeltmeyi baştan engeller.

Tecrübemiz şunu söylüyor: Entegrasyon projelerinde yaşadığımız gecikmelerin çoğu teknik bir sorundan değil, cevabı haftalarca beklenen bir sorudan kaynaklanıyor.

Hata olacak: senkronizasyon kuyruğu

ERP sunucusu gece yeniden başlatılır. Bir ürünün stok kodu sitede farklı yazılmıştır. Kurumsal bir müşterinin vergi numarası eksik girilmiştir. Bunlar istisna değil, entegrasyonun gündelik hâlidir.

Entegrasyonun kalitesi, her şey yolundayken değil, bir şey ters gittiğinde anlaşılır.

Bu yüzden aktarımları doğrudan değil, bir kuyruk üzerinden kurmayı öneriyoruz. Aktarılamayan kayıt kaybolmaz; kuyrukta bekler, belirli aralıklarla yeniden denenir, birkaç denemeden sonra hâlâ gidemiyorsa bir hata ekranına düşer ve sorumlu kişiye bildirim gider. Projenin ölçeğine göre bu kuyruk RabbitMQ gibi bir mesaj kuyruğu da olabilir, veritabanında tutulan basit bir iş tablosu da. E-posta ve SMS gönderimindeki kuyruk mantığı burada da aynen geçerli.

Hata ekranında “Sipariş aktarılamadı: stok kodu ERP'de bulunamadı” gibi anlaşılır bir mesaj görmek, muhasebe ile yazılım ekibi arasındaki telefon trafiğini büyük ölçüde azaltır. Bu tür bir hatayı muhasebeci kendisi çözer, düzeltilen kayıt bir sonraki denemede yerine ulaşır.

Test: canlı muhasebe verisiyle deneme yapılmaz

Entegrasyonun testi muhasebenin gerçek kayıtları üzerinde yapılmamalı. Çoğu ERP'de ayrı bir deneme firması ya da test veritabanı açılabiliyor; testleri orada yapmak, yanlışlıkla kesilmiş bir faturanın peşine düşmekten çok daha kolay.

Test senaryolarını “bir ürün, bir sipariş” üzerine kurmayın. Kısmi iade, tam iade, kuponla indirimli sipariş, farklı KDV oranlarındaki ürünlerin aynı sepette olması, kargo bedeli, kuruş yuvarlamaları, iptal edilen sipariş… Sorunların çoğu bu kenar durumlarda çıkar. Canlıya geçtikten sonra da ilk birkaç hafta, aktarılan siparişlerin bir kısmının elle kontrol edildiği bir paralel dönem öneriyoruz.

Entegrasyon öncesi netleştirilmesi gereken sorular

Proje küçük de olsa büyük de olsa, başlamadan önce şu soruların cevabı masada olmalı.

1. Hangi muhasebe ya da ERP programını, hangi sürüm ve lisansla kullanıyorsunuz?
2. Programınız dış yazılımlarla veri alışverişi için hangi yöntemi destekliyor? Bayiniz ya da destek firmanız bu konuda ne diyor?
3. Cari, stok, fiyat ve sipariş verilerinin her birinin ana kaynağı hangi sistem olacak?
4. Bireysel müşteriler için ayrı cari mi açılacak, toplu bir cari mi kullanılacak?
5. Sipariş ERP'ye hangi belge türüyle düşecek: sipariş fişi, irsaliye ya da fatura?
6. Stok ve fiyat hangi sıklıkla güncellenecek?
7. Ödeme türleri, kargo firmaları ve ürün varyantları ERP'de neye karşılık geliyor?
8. e-Fatura ve e-Arşiv hangi sistem üzerinden düzenlenecek?
9. İade, iptal ve kısmi iade muhasebede nasıl işlenecek?
10. Aktarılamayan kayıtları kim takip edecek, bildirim kime gidecek?
11. Testler hangi ortamda yapılacak ve canlıya geçiş kararını kim verecek?

Bu sorulara verilen cevaplar, entegrasyonun süresini ve maliyetini herhangi bir teknik tercihten daha çok belirliyor. İster bir e-ticaret sitesi, ister bayilerinize açılan bir web yazılım portalı, ister firmanıza özel bir yazılım projesi olsun; listeyi mali müşavirinizle ve muhasebe ekibinizle birlikte doldurun. Yazılım ekibiyle ilk toplantıya bu kâğıtla gitmek, konuşmayı birkaç hafta ileriden başlatır.