Nebim V3 – E-Ticaret Entegrasyonu: Stok, Sipariş ve Fatura Akışı

Kampanya sabahı ilk bir saatte 40 sipariş düşüyor, ama o üründen depoda 12 adet var. Panelde stok 60 görünüyordu. Son senkron gece 23:00'te çalışmış, araya mağaza satışları ve bir toptan sevkiyat girmiş. Şimdi 28 siparişin iptali, müşteri bilgilendirmesi ve tahsilat iadesi masada. Ortada bozulan bir kod yok; iki sistem arasındaki gecikmenin faturası var. Nebim V3 ile mağazanız arasındaki bağın nasıl kurulduğu tam olarak böyle günlerde belli olur.

Veri hangi yönde akar?

Sağlıklı bir entegrasyonda her verinin tek bir sahibi vardır. Stok ve fiyatın sahibi ERP, siparişin sahibi mağazadır. Bu ayrım netleşmediğinde iki sistem birbirinin üzerine yazmaya başlar; veri de güvenilirliğini yitirir. Sahiplik tablosu bir sayfayı geçmez ama projenin altıncı ayında en çok açılan doküman odur.

Ürün ve fiyat: sessiz sorun kaynağı

Stok ve sipariş konuşulurken ürün ana verisi genelde "zaten var" diye geçilir. Oysa ilk gün patlayan şey çoğunlukla budur. 1.200 SKU'lu bir katalogda üç dört barkod formatı, aynı ürünün iki ayrı kodla açılmış hali ve mağazada elle oluşturulmuş kayıtlar bir arada bulunur. Servis bunları eşleyemez, siparişler kuyruğa düşer, operasyon da "entegrasyon çalışmıyor" der.

Kalıcı çözüm, eşleme tablosunu ERP kodunu ana kabul edecek şekilde kurmak. Kanal kodları bu ana koda eşlenir, mağazada ürün açma yetkisi de onaya tabi olur. Fiyatta benzer bir sınır işler: liste fiyatı ERP'den gelir, kampanya kuralı mağazada kalır, ikisi aynı alanı yazmaz. Bu ayrımı Nebim V3 ERP rehberinde ayrıntılandırmıştık.

Stok senkronizasyonu

Stok, entegrasyonun en hassas parçası. Devreye almadan önce üç sorunun cevabı yazılı olsun:

• Hangi depo satışa açık? Mağaza stoğu ile e-ticaret deposu ayrışmazsa fazla satış kaçınılmaz.
• Emniyet stoğu var mı? Hızlı tükenen ürünlerde küçük bir tampon, iptal oranını düşürür.
• Stok ne zaman rezerve edilir, ne zaman düşer? Sipariş anında rezerve edip sevkte düşmek ile doğrudan sevkte düşmek farklı sonuç verir. Rezerve kullanıyorsanız iptal olan ya da ödemesi tamamlanmayan siparişin rezervini neyin serbest bıraktığı da yazılı olsun; serbest kalmayan rezerve satılabilir stoğu sessizce eritir.

Emniyet stoğunu bütün ürünlere sabit vermek kolay ama doğru değil. Günde 30 adet satan bir üründe 2 adetlik tampon bir saatlik koruma sağlar; ayda 3 adet satanda aynı tampon rafta ölü stok bırakır. Devir hızına göre kademelendirmek daha sağlıklı.

Kanala giden rakamın tam olarak ne olduğu da yazılı olsun. Gönderilen sayı fiziksel stok değil, satılabilir stoktur: depodaki adetten açık siparişlerin rezervesi ve emniyet payı düşülür. Bu formül tek yerde tanımlanmazsa aynı ürün için iki kanal iki farklı rakam görür.

Tam senkron, fark senkronu ve olay bazlı güncelleme

Senkronizasyon yönteminde üç yaklaşım var ve genelde üçü birlikte kullanılır. Hangisinin ne zaman çalışacağı, sunucu yükünüzle satış hacminiz arasındaki dengeye bağlı.

Pratikte en sağlıklısı, gün içinde sık çalışan fark senkronunu gece yapılan bir tam senkronla desteklemek. Kampanya günlerinde bütün katalogun periyodunu kısaltmak yerine, o gün vitrine çıkan ürünleri ayrı bir listeye alıp dakikada bir güncellemek daha az yük üretir. Risk 20.000 SKU'nun tamamında değil, kampanyaya giren 200 üründe.

Fazla satış olduğunda ne yapılacak?

Fazla satış, ne yaparsanız yapın bir gün olacak. Bu yüzden entegrasyonun yanına bir de karar kuralı yazılır: stok yetmediğinde sipariş otomatik iptale mi gidecek, kısmi sevkiyat mı yapılacak, müşteri temsilcisi mi arayacak? Kural yazılı değilse her vaka o günkü nöbetçinin kararına kalır. Basit bir eşik çoğu yerde iş görüyor: eksik kalan kısım siparişin küçük bir bölümüyse gerisi sevk edilip fark iade edilir, ürünün tamamı yoksa müşteriye alternatif sunulur. Kısmi sevkiyatta faturanın hangi tutar üzerinden kesileceğine de aynı toplantıda karar verin.

Sipariş akışı

Sipariş mağazada oluşur, entegrasyon servisi onu doğrular ve ERP'ye yazar. Bu adımdaki üç kontrol, sonraki altı ayın destek yükünü belirliyor:

1. Ürün eşleştirme: Mağaza stok kodu ile ERP stok kodu birebir eşleşmeli, eşleşmeyen kayıt siparişi düşürmeden kuyrukta beklemeli.
2. Mükerrer kayıt koruması: Servis her siparişi tekil anahtarla tanır; aynı sipariş ikinci kez geldiğinde yeni kayıt açmaz.
3. Cari eşleştirme: Bireysel ve kurumsal müşteri farklı cari yapısına düşer, vergi bilgisi kurumsal tarafta zorunlu alan olur.

Bireysel siparişlerde her müşteri için ayrı cari açmak ilk bakışta düzenli görünür. Altı ay sonra cari listesi on binlerce satıra çıkar, mutabakat zorlaşır. Yaygın çözüm, perakende siparişleri bir havuz cariye bağlayıp müşteri bilgisini belge üzerinde taşımak; kurumsal ve bayi siparişlerini gerçek cari kartına yazmak.

Sipariş durumları iki tarafta aynı anlama gelmeli

Mağazadaki "hazırlanıyor" ile ERP'deki sevk emri durumu birebir örtüşmez. Eşleme tablosu yapılmadığında panelde kargoya verilmiş görünen sipariş, depoda henüz toplanmamış olur. Durum eşlemesini tek yerde tanımlayın ve mağazaya yalnızca müşteriyi ilgilendiren dört durumu yazın: hazırlanıyor, kargoya verildi, teslim edildi, iptal. ERP'nin iç durumlarını panele taşımak "siparişim neden rezerve bekliyor" sorularını çoğaltmaktan başka işe yaramıyor.

Entegrasyon projelerinde en çok tıkanılan yer teknik değil, tanımdır. "Bu sipariş ERP'de hangi anda kesinleşmiş sayılıyor?" sorusunun tek bir cevabı yoksa, o entegrasyon canlıda her hafta farklı bir yerinden aksar.

Fatura, kargo ve iade

Sipariş ERP'ye düştükten sonra e-Fatura veya e-Arşiv süreci otomatik tetiklenebilir; kargo tarafında sevk emri açılır ve takip numarası mağazaya geri yazılır. Müşteri bilgilendirmesi de süreç otomasyonu ile aynı akışa bağlanır. Belgenin hangi adımda kesileceğine ve iadede hangi düzeltme belgesinin üretileceğine baştan karar verin; ayrıntısını e-Fatura ve e-İrsaliye entegrasyonu yazısında anlattık.

İade tarafı çoğu projede en son düşünülen, buna karşılık en çok destek yükü üreten kısım. İade edilen ürünün stoğa hangi koşulda geri gireceğini ve paranın hangi yöntemle döneceğini baştan tanımlayın. Kargodan gelen paket kontrol edilmeden stoğa girerse, iki hafta sonra sayımda tutmayan bir rakamla karşılaşırsınız. En basit önlem ayrı bir iade deposu: kutu önce oraya girer, kontrolden geçince satılabilir stoğa aktarılır. Bu ihtiyaçtan doğan İade Yönetim Paneli projemiz, iade sürecini tek ekranda toplayıp müşteriye otomatik bilgilendirme gönderiyor; Ticimax cüzdan bakiyesi, PayTR ve iyzico iadeleri de aynı ekrandan yürüyor.

Entegrasyonun teknik olarak dayanıklı olması

Servisler her zaman ayakta olmaz. Ağ kopar, kota dolar, karşı taraf bakıma girer. Entegrasyon katmanının bu durumlarda ne yapacağı baştan yazılır:

Tablonun ilk iki satırı ayrı ayrı işe yaramaz. Tekilleştirmesi olmayan bir yeniden deneme mükerrer sipariş üretir; yeniden denemesi olmayan servis ise ilk ağ kesintisinde veri kaybeder. İkisi aynı anda kurulur. Sahada karşımıza en sık çıkan hataları REST API entegrasyonu hataları yazısında derledik.

Sessiz bozulmayı nasıl yakalarsınız?

Bir entegrasyon tamamen durursa hemen fark edilir. Asıl tehlikeli olan, günde üç beş kaydı sessizce kaçırarak çalışmaya devam etmesi. Çare, sistemin kendi kendini kontrol eden bir görevi olması.

• Sayı karşılaştırması: Son 24 saatte mağazada oluşan sipariş adedi ile ERP'ye yazılanı her sabah kıyaslayın. Fark varsa liste halinde gelsin.
• Kuyruk yaşı ve son senkron: Kuyruktaki en eski işin beklemesi eşiği geçtiğinde uyarı üretilsin; son başarılı senkron zamanı da panelde tek satır olarak dursun.
• Eşleşmeyen kayıt sayısı: Bu sayı sıfırdan uzaklaşıyorsa ürün ana verisinde bir şey bozulmuştur.
• Stok sapma raporu: ERP stoğu ile mağaza stoğu arasında belirli bir farkı geçen SKU'ları listeleyen rapor, fazla satışı olmadan önce gösterir.

Aynı gün yakalanan on hata, iki hafta sonra bulunan tek bir hatadan ucuza gelir. Entegrasyonu ayakta tutan şey hatasız çalışması değil, bozulduğunun kaç saat içinde görülmesidir.

Depo büyüdüğünde denklem değişir

Günde 100 siparişte tek bir stok rakamı yeter. Sipariş sayısı artıp depo raflara ayrıldığında ERP'nin tuttuğu miktar ile rafta fiilen bulunan miktar ayrışır. Toplamada bulunamayan ürün, kabul edilmiş ama yerleştirilmemiş sevkiyat, iade rafında bekleyen kutular; hepsi ERP'de "var" görünür. Bu noktadan sonra satışa açılan stok, raf hareketinden beslenmeye başlar. İki sistemin nasıl ayrıştığını WMS ve ERP entegrasyonu yazısında, raf ve lokasyon kurgusunu ise adresli depo yazısında ele aldık.

Canlıya geçmeden önce netleşecek maddeler

• Stok kodu ve barkod yapısı iki tarafta da tekil mi?
• Emniyet stoğu kuralı ürün grubu bazında yazılı hale getirildi mi?
• Sipariş iptali ve iade akışı uçtan uca test edildi mi?
• Fazla satış çıktığında kim, hangi sırayla hangi adımı uygulayacak?
• Test ortamı ile canlı ortam ayrı anahtar ve ayrı veritabanı kullanıyor mu?
• Hata durumunda kim, nasıl haberdar oluyor?

Bu maddeleri netleştirmeden başlayan projeler genellikle canlıya geçtiği hafta duruyor. Ticimax, Shopify, İkas, Tsoft ve Quqasoft tarafındaki entegrasyon çalışmalarımızın tamamında listeyi müşteriyle birlikte dolduruyoruz; boş bıraktığımız her satır, canlıya geçtikten sonra bir destek talebi olarak geri geliyor. ERP ucundaki tanım ve raporlama işlerini de ERP çözümleri tarafında yürütüyoruz.

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.