WMS ve ERP Birlikte Nasıl Çalışır? Entegrasyon Mimarisi

Sabah toplantısında iki ekran açık. ERP'de o ürün için 340 adet yazıyor, WMS'te 296. Depo sorumlusu rafı gösteriyor, muhasebe belgeyi. İkisi de kendi içinde tutarlı, ama kimse pazaryerine hangi rakamın gönderileceğini söyleyemiyor. Bu tablo genelde bozulan bir koddan değil, hiç yapılmamış bir tanımdan doğar: stoğun gerçek sahibi hangi sistem? Soru netleşmeden kurulan bağlantılar, iki sistemin birbirini sürekli düzelttiği ve kimsenin hangi rakama güveneceğini bilemediği bir yapıya dönüşür.

Görev paylaşımı

Entegrasyonun ilk çıktısı kod değil, tek sayfalık bir sahiplik tablosudur. Her sürecin bir sahibi olur; diğer sistem o veriyi okur, gösterir, referans alır ama üzerine yazmaz. Kural basit görünür; pratikte en çok burası gevşer.

Tablonun asıl mesajı sütunlarda değil: bir veriyi iki sistem birden yazmaz. Depo ekibi ERP ekranından stok düzeltmesi yapabiliyorsa, WMS'in tuttuğu adres bakiyesi ilk haftada anlamını kaybeder. Yetkiyi kapatmak teknik bir iş; asıl zor kısmı ekibe alışkanlığını bıraktırmak. İki sistemin hangi soruya cevap verdiğini WMS yazımızda ayrıntılandırmıştık.

Stok tek bir rakam değildir

"Stok kaç?" sorusunun tek cevabı yok. Aynı ürün için aynı anda birkaç farklı doğru rakam bulunur ve entegrasyon bunların hangisini taşıyacağına karar vermek zorundadır.

• Brüt stok: Depoda fiziksel olarak bulunan her şey. Muhasebenin baktığı rakama en yakın olan budur, ama aynısı değil: konsinye ve emanet mal fiziksel olarak sizdedir, mali stoğunuzda görünmez.
• Yerleştirilmiş stok: Adresi olan, toplayıcının bulabileceği miktar. Mal kabul alanında bekleyen palet buna dahil değildir.
• Rezerve: Sevk emri açılmış, henüz koliye girmemiş miktar.
• Karantina ve iade: Kontrol bekleyen mal. Fiziksel olarak depoda, satışa kapalı.
• Satılabilir: Yerleştirilmiş stoktan rezerve ve emniyet payı düşüldükten sonra kalan miktar. Kanala gidecek olan bu.

3.000 SKU'lu bir depoda bu ayrım yapılmadan kurulan entegrasyon, ERP'nin brüt rakamını pazaryerine gönderir. Sonuç, mal kabulde bekleyen ve iade rafında duran adetlerin satılmasıdır. Kanal tarafındaki emniyet payı ve senkron sıklığı kurgusunu e-ticaret entegrasyonu yazısında ayrıca ele aldık.

Senkronizasyon noktaları

İki sistem arasında sürekli veri akmasına gerek yoktur; yalnızca kararı değiştiren olaylar paylaşılmalıdır:

• ERP → WMS: Yeni ürün ve barkod tanımı, beklenen mal kabul (satın alma siparişi), sevk edilecek siparişler.
• WMS → ERP: Gerçekleşen mal kabul, sevk edilen sipariş, sayım farkları, iade girişleri.

Bu akışın gerçek zamanlı mı yoksa toplu mu olacağı hacme bağlıdır. Her olayın gecikme toleransı da farklı; hepsini aynı periyoda bağlamak hem gereksiz yük üretir hem de acil olanı geciktirir.

En önemli satır en alttaki. Depo içindeki her raf hareketini ERP'ye taşımaya çalışan projeler, ERP'yi gereksiz hareket kaydıyla şişirir ve raporları yavaşlatır. ERP'nin bilmesi gereken tek şey depo toplamının değiştiği andır. Raf, göz ve koli detayı WMS'te kalır. Tek istisna, ERP'de ayrı ambar kodu tanımlanmış alanlar: karantina ya da mağaza deposu ERP'de ayrı bir ambarsa, oraya yapılan hareket adres değişimi değil ambarlar arası transferdir ve ERP'ye gitmek zorundadır. Bu ayrımı baştan yapmazsanız, hangi hareketin transfer sayılacağı her ay yeniden tartışılır. Adres kodunun nasıl kurgulanacağı ise tamamen WMS'in iç meselesi; koridor-raf-seviye kırılımını ve hane sayısı kararını adresli depo kurulumu yazısında anlattık.

Stok farkı nasıl yönetilir?

Sayım farkı kaçınılmazdır; önemli olan farkın kayıt altına alınarak ERP'ye yansıtılmasıdır. Sayan taraf WMS'tir, o sayımın mali karşılığını yazan taraf ERP. WMS'te bulunan fark ERP'de bir stok düzeltme fişine dönüşür; böylece depo ile muhasebenin rakamı aynı yerden beslenir.

Entegrasyon tarafındaki asıl karar, bu fişin otomatik mi yoksa onaya bağlı mı düşeceği. Çoğu işletmede işe yarayan kurgu şu: küçük sapmalar için bir eşik tanımlanır, eşiğin altı otomatik geçer, üstü depo sorumlusunun onayını bekler. Onaysız akan bir kanalda muhasebe ay sonunda hiç görmediği fişlerle karşılaşır; her farkı onaya bağlayan kurgu ise birkaç hafta içinde tıkanır ve kimse onay ekranına bakmaz olur. Farkın türüne göre kök neden ayrıştırmasını ve döngüsel sayım planını depo sayım farkı yazısında ele aldık.

Mal kabul: beklenen ile gerçekleşen ayrı kayıtlardır

ERP'de onaylanan satın alma siparişi WMS'e beklenen mal kabul olarak düşer. Mal geldiğinde sayım kör yapılır; sapma ekrana ancak okutma bittikten sonra çıkar. Kısmi teslimat, fazla teslimat ve hasarlı gelen mal burada ayrışır.

Çoğu projede atlanan nokta şu: gerçekleşen miktar ERP'ye giderken siparişin hangi satırına bağlandığı belli olmalı. Bağ kurulmazsa açık kalan sipariş satırları birikir, tedarikçi mutabakatı elle yapılır. Fazla gelen mal ise sessizce stoğa girmemeli; ya kabul edilip sipariş revize edilir ya da karantinada bekler. Karar işletmeye göre değişir, ama yazılı olmak zorundadır.

Sevkiyat, irsaliye ve fatura sırası

Stoğun hangi anda düşeceği teknik değil ticari bir karardır. Üç yaygın seçenek var: sipariş kesinleştiğinde rezerve edip koli kapanınca düşmek, toplama tamamlandığında düşmek, ya da irsaliye kesildiğinde düşmek. En sağlıklısı genelde ilki; rezerve WMS'te tutulur, gerçek düşüş koli kapanışında ERP'ye yazılır. Burada sık karıştırılan bir ayrım var: koli kapanışındaki düşüş operasyonel stoğu günceller, malın mülkiyetten çıktığı an ise sevk belgesinin kesildiği andır. İkisi arasında birkaç saat olabilir; depo ile muhasebenin rakamı ay sonunda tutmuyorsa ilk bakılacak yer bu aralıktır.

e-İrsaliye devredeyse sıralama daha da önemli hale gelir, çünkü belgeye giren adet koli içeriğiyle birebir aynı olmak zorunda. Koli kapanmadan belge üretilirse, eksik toplanan satır belgede doğru görünür ve düzeltme süreci ancak müşteri şikâyetiyle başlar. Kağıt irsaliyedeki gibi üzerini çizip düzeltmek de mümkün değil; belge iletildikten sonra iptal ve alıcı yanıtı ayrı bir süreç olarak yürür. Belge akışının ERP tarafındaki kurgusunu e-Fatura ve e-İrsaliye entegrasyonu yazısında adım adım anlattık.

Entegrasyon deseni

Sağlam bir entegrasyon katmanı üç bileşenden oluşur:

1. Kuyruk: Sistemlerden biri yanıt vermediğinde iş kaybolmaz, sırada bekler. Yeniden deneme artan aralıklarla yapılır; üç denemede de başarısız olan kayıt hata kuyruğuna alınır ve alarm üretir.
2. Tekillik anahtarı (idempotency): Aynı hareket iki kez işlenmez. Sevkiyat için koli numarası, mal kabul için belge numarası doğal anahtar olarak kullanılabilir. Yeniden deneme ile tekilleştirme birlikte kurulur; birini yapıp diğerini atlamak sorunu çözmez, biçim değiştirir.
3. İzlenebilirlik: Her aktarımın kaydı tutulur; "bu sipariş neden ERP'ye düşmedi" sorusu dakikalar içinde cevaplanır. İstek ve yanıt gövdesini saklamayan bir servis, canlıda tahminle yönetilir.

Canlıda en sık karşılaştığımız hataları REST API entegrasyonu hataları yazısında topladık. Bu katmanı kurarken kullandığımız teknolojiler özel yazılım geliştirme sayfamızda.

Doğrudan veritabanına yazmak neden kötü fikir?

Hızlı çözüm gibi görünür. WMS'in tablosuna insert atıp geçmek ilk gün çalışır. Sonra sürüm güncellenir, kolon adı değişir, kaydı işleyen tetikleyiciler atlanır ve stok sessizce kaymaya başlar. Servis üzerinden yazmak daha yavaş ama iş kurallarını atlamaz. Doğrudan tablo erişimini yalnızca okuma ve raporlama tarafında tercih ediyoruz.

İade akışı ayrı tasarlanır

İade, mal kabulün ters yönü değildir. Gelen kutu önce kontrol edilir; ürün satılabilir durumdaysa normal rafa, değilse hasarlı veya elden geçirme alanına gider. Her üç sonuç ERP'ye farklı yazılır ve iade sebebi kayıt altına alınır. Kontrol edilmeden stoğa giren iade, iki hafta sonra sayımda tutmayan bir rakam olarak geri döner.

Sürecin bir de mali tarafı var: iadenin hangi ödeme yöntemiyle karşılanacağı, hangi düzeltme belgesinin üretileceği ve müşterinin ne zaman bilgilendirileceği. Bu akışın tamamını tek ekranda toplayan İade Yönetim Paneli projemizde iadenin sebebi, sonucu ve bedelinin hangi kanaldan döneceği aynı kayıtta tutuluyor; ürünün depo içindeki hareketi WMS tarafında kalıyor.

Sık yapılan hatalar

• Çift yönlü stok yazımı: Her iki sistem de stoğu güncellerse, doğru rakam kalmaz.
• Barkod standardının olmaması: WMS'in tüm verimi barkod disiplinine bağlıdır. Aynı barkodun iki stok kodunda tanımlı olması, entegrasyonun çözemeyeceği bir veri sorunudur.
• Hata bildiriminin olmaması: Sessizce başarısız olan entegrasyon, en pahalı entegrasyondur.
• Test ortamının canlı veriye bağlanması: Ayrı anahtar, ayrı veritabanı olmadan yapılan denemeler canlı stoğu bozar.
• Ölçü birimi ve paket katsayısının taşınmaması: ERP'de koli, WMS'te adet çalışıyorsa fark her sevkiyatta büyür.

Entegrasyonun sağlığı hata sayısıyla değil, hatanın ne kadar sürede fark edildiğiyle ölçülür. Her sabah bakılan tek satırlık bir mutabakat raporu, aylık denetimden fazla iş görür.

Devreye alma öncesi kontrol listesi

• Her veri için tek bir sahip tanımlandı mı, sahiplik tablosu yazıya döküldü mü?
• Depo ekibinin ERP'den stok düzeltme yetkisi kapatıldı mı?
• Kanala gönderilecek "satılabilir stok" formülü net mi; karantina ve iade alanı hariç tutuluyor mu?
• Mal kabulde kısmi ve fazla teslimatta izlenecek adım yazılı mı?
• Stok düşüşünün hangi anda olacağı ticari tarafla birlikte kararlaştırıldı mı?
• Sayım farkı sebep kodları belirlendi mi, hangi kodun hangi muhasebe hesabına gideceği yazılı mı?
• Kuyruk yaşı ve eşleşmeyen kayıt sayısı için uyarı eşiği tanımlandı mı?
• Bağlantı koptuğunda depo hangi yedek yöntemle çalışmaya devam edecek?

Bu maddeler netleşmeden yazılan kod, canlıda her hafta farklı bir şekilde yanlış çalışır. Nebim V3 tarafındaki kurgu için Nebim V3 rehberimize, ERP kurulum ve özelleştirme kapsamımız için ERP çözümleri sayfasına bakabilirsiniz.

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.