2 saat önce
E-ticarette stok takibi, yalnızca “depoda kaç ürün kaldı?” sorusunun cevabını bilmek değildir. Doğru stok yönetimi; satışa açık miktarı, bekleyen siparişleri, iadeleri, tedarik süresini ve birden fazla satış kanalındaki hareketleri birlikte takip edebilmeyi gerektirir.
Özellikle aynı ürünü kendi e-ticaret sitesiyle birlikte Trendyol, Hepsiburada, Amazon veya başka pazaryerlerinde satan işletmelerde stok yönetimi büyüdükçe daha kritik hale gelir.
Başlangıçta birkaç ürün için Excel veya basit bir tablo yeterli olabilir. Ancak ürün ve sipariş sayısı arttıkça manuel güncellemeler gecikebilir, aynı ürün iki farklı kanalda aynı anda satılabilir veya gerçekte olmayan bir stok müşteriye satışa açık görünebilir.
Bu konuda stok takibine basit bir sistemle nasıl başlanabileceğini, hangi noktada entegrasyon ihtiyacı doğduğunu ve stok hatalarını azaltmak için hangi kontrollerin yapılabileceğini adım adım ele alalım.
Stok miktarı ile satılabilir stok aynı şey değildir
Depoda fiziksel olarak 20 adet ürün bulunması, her zaman 20 adedinin satışa açılabileceği anlamına gelmez.
Örneğin depoda 20 adet ürününüz olsun. Bunlardan 3 tanesi hazırlanmakta olan siparişlere ayrılmış, 1 tanesi hasarlı ve 2 tanesi de değişim veya kalite kontrolü için bekliyor olabilir.
Bu durumda fiziksel stok 20 adet görünmesine rağmen gerçekte satışa açabileceğiniz miktar daha düşük olabilir.
Bu nedenle işletmede en azından iki kavramı ayırmak faydalıdır:
Entegrasyon kullanan sistemlerde de esas alınan kavram çoğu zaman satılabilir stoktur. Örneğin Trendyol’un resmî entegrasyon dokümantasyonunda stok güncellemesinde gönderilen “quantity” değerinin satılabilir stok bilgisini ifade ettiği belirtilmektedir.
Stok takibine en basit nasıl başlanabilir?
Yeni başlayan ve sınırlı sayıda ürünü bulunan bir işletme için ilk günden karmaşık bir ERP sistemi kurmak zorunlu değildir.
Basit bir Excel veya Google Sheets tablosuyla başlanabilir.
Her ürün için örneğin şu bilgiler tutulabilir:
- SKU
- Barkod
- Ürün adı
- Fiziksel stok
- Satılabilir stok
- Bekleyen sipariş miktarı
- Son alış tarihi
- Son alış fiyatı
- Tedarikçi
- Minimum stok seviyesi
- Yeniden sipariş verilmiş miktar
Burada önemli olan kullanılan yazılımdan çok stok hareketlerinin disiplinli biçimde kaydedilmesidir.
Bir ürün geldiğinde stok artırılıyor fakat satış olduğunda azaltılmıyorsa en gelişmiş tablo bile doğru sonuç vermez.
SKU neden önemlidir?
Ürün sayısı arttığında yalnızca ürün adıyla stok yönetmek ciddi karışıklığa neden olabilir.
Örneğin:
“Siyah Tişört”
tek bir ürün değildir.
Siyah tişörtün:
S bedeni,
M bedeni,
L bedeni
ayrı stoklara sahip olabilir.
Bu nedenle her satılabilir varyantın kendine ait benzersiz bir SKU ile takip edilmesi işinizi kolaylaştırır.
Örneğin:
TS-SYH-S
TS-SYH-M
TS-SYH-L
gibi işletme içerisinde anlaşılabilir bir yapı kullanılabilir.
SKU biçiminin mutlaka bu örnekteki gibi olması gerekmez. Önemli olan aynı SKU’nun iki farklı ürüne verilmemesi ve kullanılan sistemin işletme içerisinde tutarlı olmasıdır.
Barkod ile SKU aynı şey midir?
Hayır.
Barkod ve SKU stok yönetiminde birlikte kullanılabilir ancak aynı kavram değildir.
SKU işletmenin kendi ürün veya varyant tanımlama kodu olabilir. Barkod ise ürünü belirli bir standart içerisinde tanımlayan ayrı bir bilgidir.
Bazı işletmeler stok yönetimini barkod üzerinden yürütürken bazıları kendi SKU sistemini ana referans olarak kullanabilir.
Önemli olan hangi kodun “ana ürün kimliği” olarak kullanılacağının baştan belirlenmesidir.
Bir pazaryeri, e-ticaret sitesi, depo yazılımı ve muhasebe sistemi arasında entegrasyon kurulacaksa aynı ürünün bütün sistemlerde doğru eşleşmesi özellikle önem kazanır.
Tek satış kanalında manuel stok takibi ne kadar sürdürülebilir?
Bunun için “50 siparişe kadar Excel yeterlidir” gibi evrensel bir sınır vermek doğru değildir.
Bir işletme 100 siparişi manuel olarak sorunsuz yönetebilirken, çok varyantlı başka bir işletme çok daha az siparişte zorlanabilir.
Asıl belirleyici olan şudur:
Cevap evetse mevcut sisteminiz henüz işinizi görüyor olabilir.
Ama stok güncellemelerini unutmaya başladıysanız, sipariş iptalleri oluşuyorsa veya her gün farklı panellere girip aynı rakamı değiştirmek ciddi zaman alıyorsa entegrasyon ihtiyacı yaklaşmış demektir.
Birden fazla pazaryerinde satış yapınca sorun nasıl oluşur?
Elinizde son 1 adet ürün olduğunu düşünelim.
Aynı ürün:
Kendi sitenizde,
Pazaryeri A’da,
Pazaryeri B’de
1 adet stokla satışa açık olsun.
Saat 15.00’te Pazaryeri A’dan sipariş geldi.
Gerçek stok artık:
0
oldu.
Ancak Pazaryeri B’deki stok bilgisi henüz güncellenmediyse başka bir müşteri aynı ürünü satın alabilir.
Bu durumda iki siparişiniz fakat yalnızca bir ürününüz olur.
Satıcı daha sonra siparişlerden birini iptal etmek, müşteriye açıklama yapmak veya yeniden tedarik sağlamaya çalışmak zorunda kalabilir.
İşte çok kanallı stok entegrasyonunun temel amacı bu problemi azaltmaktır.
Merkezi stok mantığı nasıl çalışır?
Çok kanallı yapıda daha sağlıklı model, bir sistemi ana stok kaynağı olarak belirlemektir.
Örneğin merkezi sistemde:
Stok: 10
olsun.
Pazaryeri A’dan:
2 adet
satıldı.
Merkezi stok:
8
olarak güncellenir.
Ardından diğer bağlı kanallara yeni satılabilir stok bilgisi gönderilir.
Pazaryeri B:
8
Kendi site:
8
şeklinde güncellenir.
Gerçek sistemlerde sipariş işleme süresi, rezervasyon, iptal, iade ve entegrasyon gecikmeleri gibi başka ayrıntılar bulunabilir ancak temel mantık budur:
Hangi sistem ana stok kaynağı olmalıdır?
Bunun tek bir doğru cevabı yoktur.
İşletmeye göre ana sistem:
- ERP
- Muhasebe/stok programı
- E-ticaret altyapısı
- Pazaryeri entegratörü
- Depo yönetim sistemi
olabilir.
Önemli olan aynı anda birkaç sistemin birbirinden bağımsız biçimde “ana stok” olmaya çalışmamasıdır.
Örneğin hem ERP’nin pazaryerine stok gönderdiği hem entegratörün aynı stok değerini farklı kuralla güncellediği bir yapı hatalara yol açabilir.
Bu nedenle entegrasyon kurulurken:
sorusu net cevaplanmalıdır.
Stok güncellemeleri mümkün olduğunca değişiklik bazlı yapılmalıdır
Entegrasyon kullanıldığında bütün ürün stoğunu sürekli baştan göndermek yerine değişen ürünlerin güncellenmesi daha sağlıklı olabilir.
Trendyol’un güncel resmî stok ve fiyat entegrasyonu dokümantasyonunda da yalnızca değişen stok/fiyat bilgilerinin gönderilmesi gerektiği belirtilmektedir. Aynı değişiklik yapılmamış isteğin kısa süre içerisinde tekrar gönderilmesine karşı sistem kontrolü bulunmaktadır.
Bu teknik ayrıntı entegrasyon geliştiricileri için önemli olsa da işletme açısından çıkarılacak ders daha basittir:
Entegrasyona bir istek gönderilmiş olması tek başına güncellemenin başarıyla tamamlandığı anlamına gelmeyebilir. Kullanılan platformun sağladığı işlem sonucu veya hata kayıtları da kontrol edilmelidir.
Güvenlik stoğu nedir?
Bazı işletmeler sistemdeki gerçek stok miktarının tamamını satışa açmak yerine küçük bir güvenlik payı bırakabilir.
Örneğin fiziksel stok:
20 adet
olsun.
İşletme 2 ürünü güvenlik payı olarak ayırıyorsa satış kanallarına:
18 adet
stok gönderebilir.
Bu yaklaşım özellikle:
- Stok sayım farkları
- Hasarlı ürünler
- Aynı anda gelen siparişler
- Tedarik belirsizlikleri
gibi durumlarda ek tampon sağlayabilir.
Ancak her işletmenin mutlaka belirli sayıda güvenlik stoğu tutması gerektiğine dair tek bir doğru rakam yoktur. Ürünün satış hızına, tedarik süresine ve operasyon yapısına göre karar verilmelidir.
Minimum stok seviyesi nasıl belirlenebilir?
“Stok 5’e düşünce sipariş ver” gibi sabit bir kural bütün ürünlerde çalışmaz.
Daha sağlıklı yaklaşım ürünün satış hızını ve tedarik süresini birlikte değerlendirmektir.
Örneğin bir ürün günde ortalama:
4 adet
satılıyor olsun.
Tedarikçinin yeni ürünü size ulaştırması:
7 gün
sürüyorsa yalnızca tedarik süresindeki tahmini satış:
4 x 7 = 28 adet
olabilir.
Sipariş vermek için stoğun 5 adede düşmesini beklerseniz yeni ürün gelmeden stok bitebilir.
Bu nedenle yeniden sipariş seviyesi hesaplanırken en azından:
- Ortalama satış hızı
- Tedarik süresi
- Satış dalgalanmaları
- Güvenlik stoğu
birlikte değerlendirilmelidir.
Basit yeniden sipariş noktası örneği
Ürün günlük ortalama:
3 adet
satılıyor olsun.
Tedarik süresi:
10 gün
Güvenlik stoğu:
10 adet
olarak işletme tarafından belirlenmiş olsun.
Tedarik süresindeki tahmini ihtiyaç:
3 x 10 = 30 adet
Güvenlik stoğu da eklendiğinde:
30 + 10 = 40 adet
elde edilir.
Bu basitleştirilmiş örnekte stok yaklaşık 40 seviyesine geldiğinde yeni sipariş vermeyi değerlendirmek mantıklı olabilir.
Bu rakam evrensel değildir. Satışın sabit olmadığı ürünlerde daha ayrıntılı tahmin yapılması gerekir.
Stokta olmayan ürünü satmak kadar fazla stok da problemdir
Stok yönetimi yalnızca ürünün bitmesini önlemeye çalışmak değildir.
Gereğinden fazla stok tutmak da işletme için maliyetlidir.
Örneğin 1.000 TL maliyetli bir üründen gereğinden fazla:
500 adet
stok tuttuğunuzu düşünelim.
Stoka bağlanan sermaye:
500.000 TL
olur.
Ürün yavaş satıyorsa bu para uzun süre depoda bekler.
Ürün sezonluksa veya yeni modeli çıkıyorsa stok değer kaybedebilir.
Bu nedenle iyi stok yönetimi:
“Hiç ürün bitmesin.”
değil,
dengesini kurmaya çalışır.
İadeler stok sistemine doğrudan eklenmeli mi?
Her zaman otomatik olarak değil.
Müşteriden dönen ürün fiziksel olarak depoya ulaşmış olsa bile tekrar satışa uygun olmayabilir.
Ürün:
- Kullanılmış
- Hasarlı
- Eksik parçalı
- Ambalajı bozulmuş
olabilir.
Bu nedenle iade gelen ürün için ideal süreç:
İade alındı → ürün kontrol edildi → satışa uygunluğu belirlendi → uygunsa satılabilir stoğa eklendi
şeklinde olabilir.
İade oluştuğu anda ürünü satılabilir stoğa eklemek, gerçekte satılamayacak ürünlerin müşteriye yeniden sunulmasına neden olabilir.
Stok sayımı neden hâlâ gereklidir?
Entegrasyon kullanmanız fiziksel stok sayımına artık ihtiyaç olmadığı anlamına gelmez.
Zaman içerisinde:
- Yanlış paketleme
- Eksik giriş
- Hasar
- Kayıp
- İade hatası
- Manuel işlem
- Sistem eşleşme problemi
nedeniyle sistem stoğu ile gerçek depo stoğu arasında fark oluşabilir.
Bu nedenle belirli aralıklarla fiziksel sayım yapılması ve sistem kayıtlarıyla karşılaştırılması önemlidir.
Çok geniş ürün kataloğunda bütün depoyu aynı gün saymak yerine döngüsel sayım yöntemleri de kullanılabilir. Örneğin yüksek satış hacimli ürünler daha sık kontrol edilebilir.
Negatif stok nasıl araştırılmalıdır?
Sisteminizde:
-1
-2
gibi stok değerleri görüyorsanız yalnızca rakamı sıfırlayıp geçmek sorunun kaynağını çözmez.
Önce hangi hareketin hataya neden olduğunu bulun.
Örneğin:
1. Son doğru stok miktarı neydi?
2. Hangi siparişler geldi?
3. İptaller stoğa geri eklendi mi?
4. İadeler doğru işlendi mi?
5. Manuel stok değişikliği yapıldı mı?
6. Aynı sipariş iki kez düşülmüş olabilir mi?
7. Entegrasyon aynı hareketi tekrar işlemiş olabilir mi?
Sorunun kaynağı bulunmadan yalnızca stok rakamını düzeltmek aynı hatanın tekrar oluşmasına neden olabilir.
Excel’den entegrasyona geçme zamanının geldiğini nasıl anlarsınız?
Burada sipariş sayısından çok operasyonun zorlanıp zorlanmadığına bakmak gerekir.
Şu durumlar sıklaşmaya başladıysa entegrasyon değerlendirmek mantıklı olabilir:
- Aynı ürünü birkaç satış kanalında satıyorsunuz.
- Bir satıştan sonra diğer panelleri manuel güncelliyorsunuz.
- Stok olmadığı halde sipariş almaya başladınız.
- Aynı ürün farklı sistemlerde farklı miktarlarda görünüyor.
- Ürün/varyant sayısı manuel takibi zorlaştırdı.
- Stok güncellemesi için her gün ciddi zaman harcıyorsunuz.
- Sipariş iptallerinin veya iadelerin stoğa dönüşünü takip etmek zorlaşıyor.
- Depo stoğu ile paneldeki stok sık sık uyuşmuyor.
Bu noktada entegrasyon yalnızca zamandan tasarruf sağlamaz; operasyon hatasının azaltılmasına da yardımcı olabilir.
Entegrasyon seçerken yalnız “kaç pazaryerine bağlanıyor?” diye bakmayın
Bir entegrasyon sistemi seçerken desteklediği pazaryeri sayısı önemli olsa da tek kriter olmamalıdır.
Özellikle şu konuları sorun:
- Stok hangi sıklıkta güncelleniyor?
- Sipariş geldiğinde stok ne zaman düşüyor?
- İptal edilen sipariş stoğa nasıl dönüyor?
- İade süreci nasıl işleniyor?
- Varyantlar nasıl eşleştiriliyor?
- Aynı SKU birden fazla kanalda nasıl yönetiliyor?
- Güncelleme başarısız olursa uyarı geliyor mu?
- Hatalı stok hareketlerinin geçmişi görülebiliyor mu?
- Manuel düzeltme yapılabiliyor mu?
- ERP veya muhasebe sistemiyle bağlantı kurulabiliyor mu?
Entegrasyon yalnız veri gönderen değil, hata olduğunda problemi fark etmenizi sağlayan bir sistem olmalıdır.
Günlük stok kontrolünde neye bakılabilir?
Her gün binlerce ürünü tek tek incelemek gerekmez.
Öncelikli bir kontrol listesi oluşturulabilir.
Örneğin:
1. Stoğu sıfırlanan ürünler
2. Minimum stok seviyesinin altına düşen ürünler
3. Negatif stok görünen ürünler
4. Son 24 saatte olağan dışı hızlı satılan ürünler
5. Kanallar arasında stok uyuşmazlığı bulunan SKU’lar
6. Yeni stoğu beklenen ancak henüz gelmeyen ürünler
7. Yüksek satış hacimli kritik ürünler
Bu şekilde sorunlu ürünler öncelikli olarak incelenebilir.
Stok takip tablosunda hangi alanlar bulunabilir?
Başlangıç seviyesinde şu yapı yeterli olabilir:
SKU
Barkod
Ürün adı
Varyant
Fiziksel stok
Satılabilir stok
Bekleyen sipariş
Güvenlik stoğu
Minimum stok seviyesi
Günlük ortalama satış
Tedarik süresi
Son tedarik tarihi
Tedarikçi
Beklenen yeni stok
Bu alanların tamamını ilk günden kullanmak zorunda değilsiniz. İşletmenin ihtiyacına göre sistem zaman içerisinde geliştirilebilir.
Sonuç
E-ticarette stok yönetiminin amacı mümkün olduğunca fazla ürün depolamak değildir. Asıl amaç müşteriye satışa sunduğunuz miktarla gerçekte teslim edebileceğiniz miktarın mümkün olduğunca uyumlu olmasını sağlamaktır.
Yeni başlayan bir işletme az sayıda ürünle Excel veya benzeri basit bir tablo kullanarak stok takibine başlayabilir. Ancak ürün, varyant, sipariş veya satış kanalı arttıkça manuel yöntemin hata riski de artar.
Özellikle bir ürün birkaç farklı kanalda aynı anda satışa sunuluyorsa merkezi stok yönetimi önemli hale gelir.
Sağlıklı bir stok sisteminde:
fiziksel stok,
satılabilir stok,
bekleyen sipariş,
iade,
tedarik süresi
ve güvenlik stoğu
birbirinden ayrılabilmelidir.
En önemli prensip ise şudur:
Böylece bir hata oluştuğunda yalnızca sonucu düzeltmek yerine sorunun kaynağını da bulabilirsiniz.
Sizde stok takibi nasıl yapılıyor?
E-ticaret yapanlara birkaç soru:
1. Stoklarınızı Excel ile mi, entegratörle mi yoksa ERP sistemiyle mi takip ediyorsunuz?
2. Birden fazla pazaryerinde aynı ürünün stoklarının farklılaştığı oldu mu?
3. Stokta olmadığı halde sipariş aldığınız bir durum yaşadınız mı?
4. Manuel stok takibinden otomasyona geçmenize neden olan asıl problem neydi?
Entegrasyon sorunlarını anlatırken API anahtarı, kullanıcı şifresi veya işletmenize ait gizli erişim bilgilerini forumda paylaşmayın.
Kaynak notu
Trendyol Developers – Stok ve Fiyat Güncelleme (updatePriceAndInventory)
Trendyol Developers – Marketplace Entegrasyon Dokümantasyonu
Not: Pazaryerlerinin API ve entegrasyon sürümleri zaman içerisinde değişebildiğinden teknik entegrasyon geliştirilirken ilgili platformun güncel resmî dokümantasyonu esas alınmalıdır.
Özellikle aynı ürünü kendi e-ticaret sitesiyle birlikte Trendyol, Hepsiburada, Amazon veya başka pazaryerlerinde satan işletmelerde stok yönetimi büyüdükçe daha kritik hale gelir.
Başlangıçta birkaç ürün için Excel veya basit bir tablo yeterli olabilir. Ancak ürün ve sipariş sayısı arttıkça manuel güncellemeler gecikebilir, aynı ürün iki farklı kanalda aynı anda satılabilir veya gerçekte olmayan bir stok müşteriye satışa açık görünebilir.
Bu konuda stok takibine basit bir sistemle nasıl başlanabileceğini, hangi noktada entegrasyon ihtiyacı doğduğunu ve stok hatalarını azaltmak için hangi kontrollerin yapılabileceğini adım adım ele alalım.
Stok miktarı ile satılabilir stok aynı şey değildir
Depoda fiziksel olarak 20 adet ürün bulunması, her zaman 20 adedinin satışa açılabileceği anlamına gelmez.
Örneğin depoda 20 adet ürününüz olsun. Bunlardan 3 tanesi hazırlanmakta olan siparişlere ayrılmış, 1 tanesi hasarlı ve 2 tanesi de değişim veya kalite kontrolü için bekliyor olabilir.
Bu durumda fiziksel stok 20 adet görünmesine rağmen gerçekte satışa açabileceğiniz miktar daha düşük olabilir.
Bu nedenle işletmede en azından iki kavramı ayırmak faydalıdır:
Alıntı:Fiziksel stok = Depoda gerçekten bulunan toplam miktar
Satılabilir stok = Yeni sipariş alabileceğiniz kullanılabilir miktar
Entegrasyon kullanan sistemlerde de esas alınan kavram çoğu zaman satılabilir stoktur. Örneğin Trendyol’un resmî entegrasyon dokümantasyonunda stok güncellemesinde gönderilen “quantity” değerinin satılabilir stok bilgisini ifade ettiği belirtilmektedir.
Stok takibine en basit nasıl başlanabilir?
Yeni başlayan ve sınırlı sayıda ürünü bulunan bir işletme için ilk günden karmaşık bir ERP sistemi kurmak zorunlu değildir.
Basit bir Excel veya Google Sheets tablosuyla başlanabilir.
Her ürün için örneğin şu bilgiler tutulabilir:
- SKU
- Barkod
- Ürün adı
- Fiziksel stok
- Satılabilir stok
- Bekleyen sipariş miktarı
- Son alış tarihi
- Son alış fiyatı
- Tedarikçi
- Minimum stok seviyesi
- Yeniden sipariş verilmiş miktar
Burada önemli olan kullanılan yazılımdan çok stok hareketlerinin disiplinli biçimde kaydedilmesidir.
Bir ürün geldiğinde stok artırılıyor fakat satış olduğunda azaltılmıyorsa en gelişmiş tablo bile doğru sonuç vermez.
SKU neden önemlidir?
Ürün sayısı arttığında yalnızca ürün adıyla stok yönetmek ciddi karışıklığa neden olabilir.
Örneğin:
“Siyah Tişört”
tek bir ürün değildir.
Siyah tişörtün:
S bedeni,
M bedeni,
L bedeni
ayrı stoklara sahip olabilir.
Bu nedenle her satılabilir varyantın kendine ait benzersiz bir SKU ile takip edilmesi işinizi kolaylaştırır.
Örneğin:
TS-SYH-S
TS-SYH-M
TS-SYH-L
gibi işletme içerisinde anlaşılabilir bir yapı kullanılabilir.
SKU biçiminin mutlaka bu örnekteki gibi olması gerekmez. Önemli olan aynı SKU’nun iki farklı ürüne verilmemesi ve kullanılan sistemin işletme içerisinde tutarlı olmasıdır.
Barkod ile SKU aynı şey midir?
Hayır.
Barkod ve SKU stok yönetiminde birlikte kullanılabilir ancak aynı kavram değildir.
SKU işletmenin kendi ürün veya varyant tanımlama kodu olabilir. Barkod ise ürünü belirli bir standart içerisinde tanımlayan ayrı bir bilgidir.
Bazı işletmeler stok yönetimini barkod üzerinden yürütürken bazıları kendi SKU sistemini ana referans olarak kullanabilir.
Önemli olan hangi kodun “ana ürün kimliği” olarak kullanılacağının baştan belirlenmesidir.
Bir pazaryeri, e-ticaret sitesi, depo yazılımı ve muhasebe sistemi arasında entegrasyon kurulacaksa aynı ürünün bütün sistemlerde doğru eşleşmesi özellikle önem kazanır.
Tek satış kanalında manuel stok takibi ne kadar sürdürülebilir?
Bunun için “50 siparişe kadar Excel yeterlidir” gibi evrensel bir sınır vermek doğru değildir.
Bir işletme 100 siparişi manuel olarak sorunsuz yönetebilirken, çok varyantlı başka bir işletme çok daha az siparişte zorlanabilir.
Asıl belirleyici olan şudur:
Alıntı:Stok değişikliği olduğunda bütün satış kanallarını zamanında ve hatasız güncelleyebiliyor musunuz?
Cevap evetse mevcut sisteminiz henüz işinizi görüyor olabilir.
Ama stok güncellemelerini unutmaya başladıysanız, sipariş iptalleri oluşuyorsa veya her gün farklı panellere girip aynı rakamı değiştirmek ciddi zaman alıyorsa entegrasyon ihtiyacı yaklaşmış demektir.
Birden fazla pazaryerinde satış yapınca sorun nasıl oluşur?
Elinizde son 1 adet ürün olduğunu düşünelim.
Aynı ürün:
Kendi sitenizde,
Pazaryeri A’da,
Pazaryeri B’de
1 adet stokla satışa açık olsun.
Saat 15.00’te Pazaryeri A’dan sipariş geldi.
Gerçek stok artık:
0
oldu.
Ancak Pazaryeri B’deki stok bilgisi henüz güncellenmediyse başka bir müşteri aynı ürünü satın alabilir.
Bu durumda iki siparişiniz fakat yalnızca bir ürününüz olur.
Satıcı daha sonra siparişlerden birini iptal etmek, müşteriye açıklama yapmak veya yeniden tedarik sağlamaya çalışmak zorunda kalabilir.
İşte çok kanallı stok entegrasyonunun temel amacı bu problemi azaltmaktır.
Merkezi stok mantığı nasıl çalışır?
Çok kanallı yapıda daha sağlıklı model, bir sistemi ana stok kaynağı olarak belirlemektir.
Örneğin merkezi sistemde:
Stok: 10
olsun.
Pazaryeri A’dan:
2 adet
satıldı.
Merkezi stok:
8
olarak güncellenir.
Ardından diğer bağlı kanallara yeni satılabilir stok bilgisi gönderilir.
Pazaryeri B:
8
Kendi site:
8
şeklinde güncellenir.
Gerçek sistemlerde sipariş işleme süresi, rezervasyon, iptal, iade ve entegrasyon gecikmeleri gibi başka ayrıntılar bulunabilir ancak temel mantık budur:
Alıntı:Stok için mümkün olduğunca tek bir doğru kaynak oluşturmak.
Hangi sistem ana stok kaynağı olmalıdır?
Bunun tek bir doğru cevabı yoktur.
İşletmeye göre ana sistem:
- ERP
- Muhasebe/stok programı
- E-ticaret altyapısı
- Pazaryeri entegratörü
- Depo yönetim sistemi
olabilir.
Önemli olan aynı anda birkaç sistemin birbirinden bağımsız biçimde “ana stok” olmaya çalışmamasıdır.
Örneğin hem ERP’nin pazaryerine stok gönderdiği hem entegratörün aynı stok değerini farklı kuralla güncellediği bir yapı hatalara yol açabilir.
Bu nedenle entegrasyon kurulurken:
Alıntı:Stok bilgisinin gerçek sahibi hangi sistem?
sorusu net cevaplanmalıdır.
Stok güncellemeleri mümkün olduğunca değişiklik bazlı yapılmalıdır
Entegrasyon kullanıldığında bütün ürün stoğunu sürekli baştan göndermek yerine değişen ürünlerin güncellenmesi daha sağlıklı olabilir.
Trendyol’un güncel resmî stok ve fiyat entegrasyonu dokümantasyonunda da yalnızca değişen stok/fiyat bilgilerinin gönderilmesi gerektiği belirtilmektedir. Aynı değişiklik yapılmamış isteğin kısa süre içerisinde tekrar gönderilmesine karşı sistem kontrolü bulunmaktadır.
Bu teknik ayrıntı entegrasyon geliştiricileri için önemli olsa da işletme açısından çıkarılacak ders daha basittir:
Alıntı:Stok sisteminiz hangi ürünün gerçekten değiştiğini bilmeli ve güncelleme sonucunu kontrol etmelidir.
Entegrasyona bir istek gönderilmiş olması tek başına güncellemenin başarıyla tamamlandığı anlamına gelmeyebilir. Kullanılan platformun sağladığı işlem sonucu veya hata kayıtları da kontrol edilmelidir.
Güvenlik stoğu nedir?
Bazı işletmeler sistemdeki gerçek stok miktarının tamamını satışa açmak yerine küçük bir güvenlik payı bırakabilir.
Örneğin fiziksel stok:
20 adet
olsun.
İşletme 2 ürünü güvenlik payı olarak ayırıyorsa satış kanallarına:
18 adet
stok gönderebilir.
Bu yaklaşım özellikle:
- Stok sayım farkları
- Hasarlı ürünler
- Aynı anda gelen siparişler
- Tedarik belirsizlikleri
gibi durumlarda ek tampon sağlayabilir.
Ancak her işletmenin mutlaka belirli sayıda güvenlik stoğu tutması gerektiğine dair tek bir doğru rakam yoktur. Ürünün satış hızına, tedarik süresine ve operasyon yapısına göre karar verilmelidir.
Minimum stok seviyesi nasıl belirlenebilir?
“Stok 5’e düşünce sipariş ver” gibi sabit bir kural bütün ürünlerde çalışmaz.
Daha sağlıklı yaklaşım ürünün satış hızını ve tedarik süresini birlikte değerlendirmektir.
Örneğin bir ürün günde ortalama:
4 adet
satılıyor olsun.
Tedarikçinin yeni ürünü size ulaştırması:
7 gün
sürüyorsa yalnızca tedarik süresindeki tahmini satış:
4 x 7 = 28 adet
olabilir.
Sipariş vermek için stoğun 5 adede düşmesini beklerseniz yeni ürün gelmeden stok bitebilir.
Bu nedenle yeniden sipariş seviyesi hesaplanırken en azından:
- Ortalama satış hızı
- Tedarik süresi
- Satış dalgalanmaları
- Güvenlik stoğu
birlikte değerlendirilmelidir.
Basit yeniden sipariş noktası örneği
Ürün günlük ortalama:
3 adet
satılıyor olsun.
Tedarik süresi:
10 gün
Güvenlik stoğu:
10 adet
olarak işletme tarafından belirlenmiş olsun.
Tedarik süresindeki tahmini ihtiyaç:
3 x 10 = 30 adet
Güvenlik stoğu da eklendiğinde:
30 + 10 = 40 adet
elde edilir.
Bu basitleştirilmiş örnekte stok yaklaşık 40 seviyesine geldiğinde yeni sipariş vermeyi değerlendirmek mantıklı olabilir.
Bu rakam evrensel değildir. Satışın sabit olmadığı ürünlerde daha ayrıntılı tahmin yapılması gerekir.
Stokta olmayan ürünü satmak kadar fazla stok da problemdir
Stok yönetimi yalnızca ürünün bitmesini önlemeye çalışmak değildir.
Gereğinden fazla stok tutmak da işletme için maliyetlidir.
Örneğin 1.000 TL maliyetli bir üründen gereğinden fazla:
500 adet
stok tuttuğunuzu düşünelim.
Stoka bağlanan sermaye:
500.000 TL
olur.
Ürün yavaş satıyorsa bu para uzun süre depoda bekler.
Ürün sezonluksa veya yeni modeli çıkıyorsa stok değer kaybedebilir.
Bu nedenle iyi stok yönetimi:
“Hiç ürün bitmesin.”
değil,
Alıntı:“Satış ihtiyacını karşılayacak kadar stok bulunsun ancak gereksiz sermaye stokta tutulmasın.”
dengesini kurmaya çalışır.
İadeler stok sistemine doğrudan eklenmeli mi?
Her zaman otomatik olarak değil.
Müşteriden dönen ürün fiziksel olarak depoya ulaşmış olsa bile tekrar satışa uygun olmayabilir.
Ürün:
- Kullanılmış
- Hasarlı
- Eksik parçalı
- Ambalajı bozulmuş
olabilir.
Bu nedenle iade gelen ürün için ideal süreç:
İade alındı → ürün kontrol edildi → satışa uygunluğu belirlendi → uygunsa satılabilir stoğa eklendi
şeklinde olabilir.
İade oluştuğu anda ürünü satılabilir stoğa eklemek, gerçekte satılamayacak ürünlerin müşteriye yeniden sunulmasına neden olabilir.
Stok sayımı neden hâlâ gereklidir?
Entegrasyon kullanmanız fiziksel stok sayımına artık ihtiyaç olmadığı anlamına gelmez.
Zaman içerisinde:
- Yanlış paketleme
- Eksik giriş
- Hasar
- Kayıp
- İade hatası
- Manuel işlem
- Sistem eşleşme problemi
nedeniyle sistem stoğu ile gerçek depo stoğu arasında fark oluşabilir.
Bu nedenle belirli aralıklarla fiziksel sayım yapılması ve sistem kayıtlarıyla karşılaştırılması önemlidir.
Çok geniş ürün kataloğunda bütün depoyu aynı gün saymak yerine döngüsel sayım yöntemleri de kullanılabilir. Örneğin yüksek satış hacimli ürünler daha sık kontrol edilebilir.
Negatif stok nasıl araştırılmalıdır?
Sisteminizde:
-1
-2
gibi stok değerleri görüyorsanız yalnızca rakamı sıfırlayıp geçmek sorunun kaynağını çözmez.
Önce hangi hareketin hataya neden olduğunu bulun.
Örneğin:
1. Son doğru stok miktarı neydi?
2. Hangi siparişler geldi?
3. İptaller stoğa geri eklendi mi?
4. İadeler doğru işlendi mi?
5. Manuel stok değişikliği yapıldı mı?
6. Aynı sipariş iki kez düşülmüş olabilir mi?
7. Entegrasyon aynı hareketi tekrar işlemiş olabilir mi?
Sorunun kaynağı bulunmadan yalnızca stok rakamını düzeltmek aynı hatanın tekrar oluşmasına neden olabilir.
Excel’den entegrasyona geçme zamanının geldiğini nasıl anlarsınız?
Burada sipariş sayısından çok operasyonun zorlanıp zorlanmadığına bakmak gerekir.
Şu durumlar sıklaşmaya başladıysa entegrasyon değerlendirmek mantıklı olabilir:
- Aynı ürünü birkaç satış kanalında satıyorsunuz.
- Bir satıştan sonra diğer panelleri manuel güncelliyorsunuz.
- Stok olmadığı halde sipariş almaya başladınız.
- Aynı ürün farklı sistemlerde farklı miktarlarda görünüyor.
- Ürün/varyant sayısı manuel takibi zorlaştırdı.
- Stok güncellemesi için her gün ciddi zaman harcıyorsunuz.
- Sipariş iptallerinin veya iadelerin stoğa dönüşünü takip etmek zorlaşıyor.
- Depo stoğu ile paneldeki stok sık sık uyuşmuyor.
Bu noktada entegrasyon yalnızca zamandan tasarruf sağlamaz; operasyon hatasının azaltılmasına da yardımcı olabilir.
Entegrasyon seçerken yalnız “kaç pazaryerine bağlanıyor?” diye bakmayın
Bir entegrasyon sistemi seçerken desteklediği pazaryeri sayısı önemli olsa da tek kriter olmamalıdır.
Özellikle şu konuları sorun:
- Stok hangi sıklıkta güncelleniyor?
- Sipariş geldiğinde stok ne zaman düşüyor?
- İptal edilen sipariş stoğa nasıl dönüyor?
- İade süreci nasıl işleniyor?
- Varyantlar nasıl eşleştiriliyor?
- Aynı SKU birden fazla kanalda nasıl yönetiliyor?
- Güncelleme başarısız olursa uyarı geliyor mu?
- Hatalı stok hareketlerinin geçmişi görülebiliyor mu?
- Manuel düzeltme yapılabiliyor mu?
- ERP veya muhasebe sistemiyle bağlantı kurulabiliyor mu?
Entegrasyon yalnız veri gönderen değil, hata olduğunda problemi fark etmenizi sağlayan bir sistem olmalıdır.
Günlük stok kontrolünde neye bakılabilir?
Her gün binlerce ürünü tek tek incelemek gerekmez.
Öncelikli bir kontrol listesi oluşturulabilir.
Örneğin:
1. Stoğu sıfırlanan ürünler
2. Minimum stok seviyesinin altına düşen ürünler
3. Negatif stok görünen ürünler
4. Son 24 saatte olağan dışı hızlı satılan ürünler
5. Kanallar arasında stok uyuşmazlığı bulunan SKU’lar
6. Yeni stoğu beklenen ancak henüz gelmeyen ürünler
7. Yüksek satış hacimli kritik ürünler
Bu şekilde sorunlu ürünler öncelikli olarak incelenebilir.
Stok takip tablosunda hangi alanlar bulunabilir?
Başlangıç seviyesinde şu yapı yeterli olabilir:
SKU
Barkod
Ürün adı
Varyant
Fiziksel stok
Satılabilir stok
Bekleyen sipariş
Güvenlik stoğu
Minimum stok seviyesi
Günlük ortalama satış
Tedarik süresi
Son tedarik tarihi
Tedarikçi
Beklenen yeni stok
Bu alanların tamamını ilk günden kullanmak zorunda değilsiniz. İşletmenin ihtiyacına göre sistem zaman içerisinde geliştirilebilir.
Sonuç
E-ticarette stok yönetiminin amacı mümkün olduğunca fazla ürün depolamak değildir. Asıl amaç müşteriye satışa sunduğunuz miktarla gerçekte teslim edebileceğiniz miktarın mümkün olduğunca uyumlu olmasını sağlamaktır.
Yeni başlayan bir işletme az sayıda ürünle Excel veya benzeri basit bir tablo kullanarak stok takibine başlayabilir. Ancak ürün, varyant, sipariş veya satış kanalı arttıkça manuel yöntemin hata riski de artar.
Özellikle bir ürün birkaç farklı kanalda aynı anda satışa sunuluyorsa merkezi stok yönetimi önemli hale gelir.
Sağlıklı bir stok sisteminde:
fiziksel stok,
satılabilir stok,
bekleyen sipariş,
iade,
tedarik süresi
ve güvenlik stoğu
birbirinden ayrılabilmelidir.
En önemli prensip ise şudur:
Alıntı:Stok rakamını yalnızca güncel tutmaya değil, stok hareketinin neden değiştiğini izleyebilecek bir sistem kurmaya çalışın.
Böylece bir hata oluştuğunda yalnızca sonucu düzeltmek yerine sorunun kaynağını da bulabilirsiniz.
Sizde stok takibi nasıl yapılıyor?
E-ticaret yapanlara birkaç soru:
1. Stoklarınızı Excel ile mi, entegratörle mi yoksa ERP sistemiyle mi takip ediyorsunuz?
2. Birden fazla pazaryerinde aynı ürünün stoklarının farklılaştığı oldu mu?
3. Stokta olmadığı halde sipariş aldığınız bir durum yaşadınız mı?
4. Manuel stok takibinden otomasyona geçmenize neden olan asıl problem neydi?
Entegrasyon sorunlarını anlatırken API anahtarı, kullanıcı şifresi veya işletmenize ait gizli erişim bilgilerini forumda paylaşmayın.
Kaynak notu
Trendyol Developers – Stok ve Fiyat Güncelleme (updatePriceAndInventory)
Trendyol Developers – Marketplace Entegrasyon Dokümantasyonu
Not: Pazaryerlerinin API ve entegrasyon sürümleri zaman içerisinde değişebildiğinden teknik entegrasyon geliştirilirken ilgili platformun güncel resmî dokümantasyonu esas alınmalıdır.