E-ticaret ERP entegrasyonu nedir: sipariş stoktan nasıl düşer

Entegrasyon olmayan bir işletmede sabah biri mağaza panelini açar, gece gelen siparişleri tek tek ERP'ye yazar, sonra depodaki sayıya bakıp sitedeki stoğu elle düzeltir. İş küçükken bu yürür. Sipariş arttıkça yazım hatası, gecikme ve unutulan sipariş de artar. Entegrasyonun taşıdığı bilgi yönüne göre ayrılır:

• Mağazadan ERP'ye: sipariş, müşteri bilgisi, ödeme durumu.
• ERP'den mağazaya: stok miktarı, fiyat, ürün bilgisi.
• İki yönde: sipariş durumu, kargo takip bilgisi, iade ve iptal.

Entegrasyon bir yazılım özelliğinden çok bir anlaşmadır: iki sistem hangi bilgiyi, hangi sırayla ve hangi kurala göre paylaşacağında anlaşır. Anlaşmanın yazılı olmadığı entegrasyonlar ilk sorunda kimin haklı olduğunu tartışmaya döner.

Entegrasyonun kapsamı da baştan belirlenmelidir: yalnız sipariş mi aktarılacak, yoksa müşteri kaydı, fiyat listesi ve kampanya fiyatları da mı? Kapsam genişledikçe eşleşme kuralı da çoğalır.

Her şey eşleşmeyle başlar. Mağazadaki ürünün kodu ile ERP'deki stok kartının kodu aynı olmalıdır. Baharat üreticisinin "pul biber, orta acı, yarım kilo" ürünü sitede bir varyanttır; ERP'de ise ayrı bir stok kartıdır. Varyant ile stok kartı eşleşmezse sipariş ERP'ye düşer ama stoğa dokunmaz. Stok kartının ayrı bir programda nerede yetmediğini stok kartı ile ERP ilişkisi yazısında anlattık.

Bir de birim farkı vardır: sitede paket, depoda koli, ERP'de kilogram. Birim dönüşümü tanımlanmazsa sipariş doğru ürüne düşer ama stoktan yanlış miktar eksilir. Stok bilgisinin mağazaya geri dönmesi de zincirin öteki ucudur; depoda son paket kaldığında sitede de son paket görünmelidir.

Eşleşme doğruysa iki yaklaşım vardır. Bazı işletmeler siparişi alır almaz miktarı ayırır, sevk edince düşer; bazıları doğrudan düşer. Ayırma, ödemesi onaylanmamış ya da iptal edilebilecek siparişlerde stoğun yanlış görünmesini önler. Hangisinin seçildiği muhasebe ve depo düzeninize bağlıdır.

Örnek senaryo: Bayram öncesi bir kampanya gecesini düşünün. Depoda son kalan koli sitede satılır; aynı koli öğleden sonra telefonla arayan bir bakkala da söz verilirse sabah biri müşterilerden birini arayıp özür dilemek zorunda kalır. Satış doğru yapılmıştır; aksayan, iki ayrı stok kaydıdır.

İadeler de aynı biçimde kayar. Müşteri ürünü geri gönderir, mağaza iadeyi işler, ERP'de ise stok ve cari eski hâlinde kalır. Ay sonunda muhasebe mağaza raporuyla ERP raporunu yan yana koyar ve farkın nereden geldiğini günlerce arar.

Entegrasyonsuz düzenin görünmeyen bir bedeli de vardır: siparişleri elle yazan kişinin zamanı. Kampanya dönemlerinde bu iş gece geç saatlere uzar ve hata riski yorgunlukla artar.

Entegrasyon kurulduktan sonra da ilk haftalarda iki tarafı karşılaştırmak iyi bir alışkanlıktır: günün sonunda mağazadaki sipariş listesi ile ERP'deki sipariş listesi aynı mı?

Kendi siteniz dışında pazaryerlerinde de satıyorsanız aynı stok birden fazla kanaldan satılır. Her kanalın siparişi ERP'ye aynı eşleşme kurallarıyla düşmelidir; aksi hâlde bir kanaldaki satış ötekinin stoğunu güncellemez. Bazı işletmeler bu yüzden stoğun bir kısmını kanal bazında ayırır.

Pazaryeri satışında muhasebe tarafı da farklıdır: ödemeyi doğrudan müşteri değil pazaryeri yapar ve komisyon ile kargo bedelini keserek aktarır. Bu kesintiler ERP'de ayrıca işlenmezse cari hesap ile banka hareketi birbirini tutmaz.

Her pazaryerinin sipariş durumu, kargo ve iade adımı için kendi kuralları vardır. Entegrasyon bu durumları ERP'deki durumlarla eşleştirmezse sipariş bir tarafta "kargoda", öteki tarafta "hazırlanıyor" görünür. Pazaryeri ödemesi de çoğu zaman siparişle aynı gün gelmez, dönemler hâlinde toplu aktarılır; hangi siparişin hangi ödemeyle kapandığını eşleştirmek muhasebenin ayrı bir işidir.

• Ürün kodları mağazada ve ERP'de aynı mı; varyantlar nasıl eşleşiyor?
• Stok için esas kaynak hangisi: ERP mi, mağaza mı?
• Aktarım anlık mı, belirli aralıklarla mı yapılıyor?
• Aktarılamayan sipariş nerede görünüyor ve kime haber veriliyor?
• İade ve iptal hangi yönde, hangi kayıtla akıyor?
• Fatura hangi tarafta hazırlanıyor ve hangi belge türüyle düzenleniyor?

Son soru mali mevzuata dokunur; hangi belgenin düzenleneceğini mali müşavirinizle netleştirin. Aktarılamayan sipariş sorusu ise en çok atlanandır: entegrasyon sessizce durursa kimse fark etmez, ta ki müşteri kargosunu sorana kadar. Entegrasyonu kuran taraf ile işleten taraf farklıysa, sorun çıktığında kime ulaşılacağı da yazılı olmalıdır. Aktarım gece durduğunda sabah ilk kimin haberi olacağı, bu sorunun cevabıdır.

Baharat üreticisinin müşterisi sipariş verdikten sonra WhatsApp'tan kargoyu sorar, bir hafta sonra toptan fiyat ister. Bu konuşmalar ERP'nin değil, müşteri ilişkisinin konusudur. İki tarafın ayrımını CRM ile ERP farkı yazısında ayrıntılı anlattık.

Müşteri ilişkisi tarafı bu yüzden entegrasyonun dışında kalmamalıdır. Kargo sorusu, iade talebi ve toptan fiyat isteği aynı müşterinin kaydında durduğunda, bir sonraki kampanyada kime ne teklif edileceği de bu kayıttan okunur.

Corex360'ı bir e-ticaret ya da pazaryeri entegrasyon aracı olarak sunmuyoruz. Corex360'ın çekirdeği müşteri, teklif, sözleşme, fatura, personel ve dosyayı aynı kayıtta tutar; WhatsApp, Instagram ve web yazışmaları tek gelen kutusunda müşteri kartına düşer. Bu yapıyı kanalları tek gelen kutusunda birleştirin sayfasında görebilirsiniz.

Corex360 stok, sipariş ya da pazaryeri entegrasyon programı olarak anlatılmaz; siparişin stoktan düşmesi e-ticaret altyapınızın ve ERP'nizin işidir. Müşterinin WhatsApp, Instagram ve web sohbeti Mesajlar penceresinde tek gelen kutusuna düşer ve fırsatın kaynağı kayıtta tutulur. Web sitesindeki teklif formu otomatik fırsat kartı açar. Satış faturası Muhasebe modülünde kesilir. Corex360'ın harici sistemlerle veri alışverişi için bir API'si vardır.