İade Ürün Yönetimi: Stok Statüsü ve İnceleme Akışı

İade kolisi depoya girdi, sistemde miktar arttı. Ancak kutunun içindeki ürün henüz kontrol edilmedi. Yeni bir sipariş bu miktarı kullanılabilir sanıp toplama görevi oluşturursa sorun, iade masasından sevkiyata taşınmış olur. İade ürün yönetiminde ilk karar, ürünü hangi rafa koyacağınız kadar hangi stok statüsünde tutacağınızdır.

Bu yazı genel depo operasyonlarında iadenin kabulü, incelemesi ve yeniden kullanılabilir stoğa geçişi için bir kontrol taslağı sunuyor. Yazılım örnekleri üreticilerin resmî belgelerine dayanıyor; uygulama önerileri ve sayısal tablo varsayımsaldır. Ürün grubuna özgü kalite veya mevzuat onayı yerine geçmez.

İade kabulü, kontrolü ve stok kararını standartlaştırmak için Prosedür ve Dokümantasyon Yönetimi hizmetimizi inceleyin.

İade nedeni ile ürün kararı ayrı kayıtlardır

“Yanlış ürün gönderildi”, “müşteri vazgeçti” ve “hasarlı geldi” ifadeleri, ürünün neden döndüğünü anlatır. Bunlar tek başına ürünün yeniden satışa uygun olduğunu veya olmadığına karar verildiğini göstermez. Örneğin yanlış ürün gönderimiyle dönen bir kutuda da içerik, miktar ve fiziksel durum kontrolü gerekebilir.

Microsoft Dynamics 365 belgesi, iade nedeni kodunu ürünün neden döndüğünü tanımlamak için; disposition kodu ve eylemini ise ürünle ne yapılacağını belirlemek için ayırır. Belgedeki eylemler arasında stoğa dönüş, hurdaya ayırma ve müşteriye geri gönderme gibi farklı yollar vardır. Ayrıca fiziksel ürün dönüşü beklenmeden müşteriye alacak tanımlanan ayrı bir seçenek de bulunur. Bu ayrım, finansal işlemin fiziksel stok kararının yerine geçmediğini gösteren bir sistem örneğidir. [1]

Operasyon taslağında üç alanı ayrı tutun: iade nedeni, inceleme sonucu ve onaylanan sonraki işlem. Aynı “iade” kodunu bu üç iş için kullanırsanız raporda hangi ürünün beklediğini, hangisinin kararının verildiğini ayırt etmek zorlaşır.

Bir bekleme rafı oluşturmak sistemde blokaj kurmak değildir

Fiziksel ayrım ile yazılım kuralını birlikte test edin. İade kutularını ayrı bir masaya bırakmak, sistemin o ürünleri siparişe tahsis etmeyeceğini kanıtlamaz. Tersine sistemde blokeli görünen ürünün yanlışlıkla kullanılabilir stok rafına taşınması da sahadaki ayrımı bozabilir.

Oracle WMS, tahsis edilebilir ve edilemez envanteri ayrı tanımlar. Kullanılamayan stok örnekleri arasında, tahsise kapalı olarak yapılandırılmış kilit kodu bulunan lokasyonlar da yer alır. Aynı üreticinin kilit kodu belgesinde Allocatable seçiliyse kilitli taşıma birimlerinin hâlâ sipariş tahsisine uygun olabileceği açıklanır. Yalnızca kodun adında “blokaj” yazması yeterli değildir; davranışı belirleyen ayar kontrol edilmelidir. [2] [3]

Bu, bütün WMS ürünlerinin aynı alanları kullandığı anlamına gelmez. Kendi yazılımınızda statünün tahsise, toplamaya ve lokasyon değişikliğine etkisini kontrol edin. Otomatik kilit kaldırma veya statü dönüşü kuralları varsa iade ürünü başka adrese taşırken ne olduğunu ayrıca sınayın.

İade ürünlerinin hangi koşullarda yeniden satışa açılacağını belirlemek ve kullanılabilir stok doğruluğunu iyileştirmek için Stok Yönetimi Danışmanlığını inceleyin.

Varsayımsal örnek: depodaki 100 adet neden 100 adet kullanılabilir değildir?

Aynı üründen 100 adet iade alındığını varsayalım. Aşağıdaki tablo tek bir andaki operasyonel durum dağılımıdır. Tüm ürünler hâlâ depodadır; tedarikçiye geri gönderim henüz gerçekleşmemiştir.

Örnekte başka rezervasyon, stok engeli veya eşzamanlı hareket olmadığı kabul edilmiştir. Kullanılabilir miktar 60 adettir; fiziksel toplamın yüzde 60’ıdır. Bu oran bir sektör hedefi veya gerçekleşmiş müşteri sonucu değildir. ERP ile WMS ekranları farklı toplamlar gösteriyorsa önce ekranın fiziksel, kullanılabilir veya belirli statüdeki miktarı mı gösterdiğini açıklığa kavuşturun.

İade ürün yönetimi için önerilen karar akışı

1. Ürünü ve kaynağı eşleştirin. İade kaydı, ürün kodu, ilgili sipariş ve miktar birimini ilişkilendirin. Tanımlanamayan ürünü tahminle ana veriye bağlamayın.
2. Giriş anındaki durumu kaydedin. Ambalaj, içerik ve miktar uyuşmazlığını birbirinden ayırın. Gerekiyorsa fotoğrafı ilgili kayda bağlayın.
3. Bekleme statüsünü uygulayın. İnceleme tamamlanana kadar hangi işlemlerin kapalı olacağını ve ürünün hangi alanda duracağını tanımlayın.
4. Kararı yetkili role verdirin. Kullanılabilir stoğa dönüş, yeniden işlem, tedarikçiye gönderim veya diğer kararlar için sorumlu kişiyi belirleyin.
5. Karar ile hareketi birlikte tamamlayın. Statü değişikliğini, fiilî adresi ve işlem kaydını eşleştirin. Yalnızca etiketi değiştirip sistem durumunu açık bırakmayın.

Bu adımlar önerilen bir süreç taslağıdır. İşletmenizin ürün özelliklerine göre ek kontroller gerekebilir. Karar sahipliği ve onay kaydını netleştirmek için prosedür ve dokümantasyon çalışmasını süreç tasarımıyla birlikte ele alabilirsiniz.

Devreye almadan önce hangi senaryolar denenmeli?

Bir test ürünüyle, inceleme bekleyen miktara normal müşteri siparişi açıldığında ne olduğunu görün. Ardından ürünü farklı lokasyona taşıyın, kısmi onay verin ve kalan miktarı tekrar kontrol edin. Aynı iadenin ikinci kez kaydedilmesini, yanlış koli–adet dönüşümünü ve yetkisiz statü değişikliğini de test listesine ekleyin.

Birim ve ambalaj hatalarının ayrıntısı için WMS ürün ana verisi rehberini inceleyebilirsiniz. Fiziksel durum ile sistem kaydı arasındaki farkları düzenli kontrol etmek için stok doğruluk denetimini kullanabilirsiniz.

İlk raporda yalnızca gelen iade miktarını göstermeyin. Karar bekleyen miktarı ve bekleme süresini; onaylanmış ancak adres hareketi bitmemiş ürünleri de ayrı izleyin. Böylece toplam stok rakamının altında bekleyen işleri görebilirsiniz. Statü ve adres kurallarının birlikte kurgulanması gerekiyorsa WMS danışmanlığı kapsamında gereksinim ve kabul senaryoları birlikte hazırlanabilir.

Kaynakça

1. Microsoft (2025). Specify how to dispose of returned items. Dynamics 365 Supply Chain Management, Microsoft Learn. Son güncelleme: 7 Mayıs 2025. Resmî teknik belge.
2. Oracle (2026). Inventory Types. Oracle Warehouse Management, 26B, Online Help. Resmî teknik belge.
3. Oracle (2026). Configuring Lock Codes. Oracle Warehouse Management, 26A, Online Help. Resmî yapılandırma belgesi.

Kaynaklar 25 Ekim 2026 tarihinde açılıp kontrol edilmiştir. Yazılım davranışları belirtilen ürün ve sürümlere aittir. Örnek tablo ve test listesi bu yazı için hazırlanmıştır. Kapak temsili bir görseldir.