Aydınlatma metni yükleniyor…
B2B iade yönetimi, bayinin talep açmasından ürünün depoda teslim alınmasına, incelenmesine, fiziksel sonucunun belirlenmesine ve ERP'deki mali kaydın kapanmasına kadar tek kimlikle izlenen bir tersine lojistik sürecidir. RMA (Return Material Authorization) numarası bu sürecin referansı olabilir; fakat tek başına süreç değildir. Sağlıklı sistem, “gönderilebilir” kararı ile “depoya geldi”, “kusur doğrulandı”, “stoğa dönebilir” ve “alacak kaydı tamamlandı” durumlarını birbirinden ayırır.
Bu rehber bayi/distribütör operasyonu, depo, kalite, satış sonrası, finans ve bilgi teknolojileri ekiplerinin ortak kapsam çıkarması için hazırlanmıştır. “Kumsal sekiz iade kanıtı” ve beklenen–gelen–karar mutabakatı bu makale için geliştirilen özgün planlama araçlarıdır. İade hakkı, garanti, ayıp, fatura ve vergi uygulamaları sözleşmeye ve geçerli mevzuata göre değişebilir; bu metin hukuki veya mali görüş değildir. Kurumun politikası ilgili uzmanlarca onaylanmalıdır.
İade talebi, gönderim izni, depo kabulü ve mali sonuç aynı kayıt değildir
Bayi bir ürünün yanlış, hasarlı, fazla veya arızalı olduğunu bildirerek talep açar. Ön inceleme, ürünün geri gönderilmesine izin verebilir veya fiziksel iade gerektirmeyen başka bir çözüm önerebilir. Kargo hareketi ürünün yolda olduğunu; depo kabulü ise belirli koli ve miktarın gerçekten ulaştığını gösterir. Kalite kararı ürünün tekrar satılabilir, tamir edilebilir, hurda, tedarikçiye dönüş veya müşteriye geri gönderim gibi sonucunu belirler. Finansal kayıt ancak ilgili kanıt ve kuruma ait kurallarla tamamlanır.
Bu nesneleri tek “iade edildi” alanına sıkıştırmak; yoldaki ürünün stokta görünmesine, eksik gelen miktarın tam kabul edilmesine veya incelemesi bitmeyen ürün için erken alacak oluşturulmasına yol açabilir. Her durumun sahibi, zamanı, girdisi ve bir sonraki izinli adımı ayrı tutulmalıdır.
RMA numarası neyi temsil etmelidir?
RMA numarası, talebi; ilgili bayi hesabı, orijinal satış/sipariş satırı, ürün, miktar, seri veya lot, iade nedeni, hedef depo ve geçerlilik dönemiyle ilişkilendiren kalıcı referanstır. Aynı numara portalda, kargo belgesinde, depo kabulünde, incelemede ve ERP işleminde taşınmalıdır. Ancak RMA numarasını bilen herkes yetkili sayılmamalı; her işlem kullanıcı ve şirket kapsamıyla doğrulanmalıdır.
Microsoft Dynamics 365 satış iadeleri belgeleri, RMA numarasını iade emri boyunca alternatif anahtar olarak kullanır; iade satırını faturalanmış satış satırına bağlamanın ürün, miktar, fiyat, iskonto ve maliyet bağlamını geri getirebildiğini açıklar. Aynı belge, RMA'nın geliş ve kabulü yönettiğini; değiştirme siparişinin ayrı fakat ilişkili kayıt olabileceğini gösterir. Bu yaklaşım genel bir tasarım ilkesini destekler: geçmiş satış kanıtı, fiziksel hareket ve sonraki ticari işlem birbirine bağlanmalı ama tek kayıt hâline getirilmemelidir.
Kumsal sekiz iade kanıtı
İade sürecinin nerede kaldığını görebilmek için her geçiş ölçülebilir bir kanıt üretmelidir:
- Talep kanıtı: Bayi, hesap, ürün/satış satırı, miktar, neden, açıklama ve ekler.
- Uygunluk kararı: Politika sürümü, inceleyen rol, kabul/ret veya ek bilgi isteği.
- Gönderim yetkisi: RMA kimliği, hedef depo, son gönderim tarihi ve ambalaj/taşıma talimatı.
- Taşıyıcı teslimi: Paket kimliği, taşıyıcı referansı, koli sayısı ve teslim zamanı.
- Depo gelişi: Gelen koli, ürün, seri/lot, miktar, ambalaj ve gözle görülür durum.
- İnceleme kararı: Kabul edilen/reddedilen miktar, bulgu, fotoğraf ve dispozisyon.
- Fiziksel ve mali işlem: Stok durumu, konum, tamir/değişim/hurda kararı ve ilgili ERP belgesi.
- Kapanış kanıtı: Bayiye bildirilen sonuç, açık farklar, tamamlanma zamanı ve sorumlu.
Bu zincir, “talep onaylandı” ile “iade tamamlandı” arasındaki görünmeyen işleri açığa çıkarır. Her kanıt aynı iade kimliğine bağlı olsa da farklı ekip ve sistem tarafından üretilebilir.
İade nedeni ile ürünün son durumunu ayırın
Neden kodu, bayinin ürünü neden geri göndermek istediğini ifade eder: yanlış ürün, taşıma hasarı, arıza iddiası, fazla sevkiyat veya sözleşmeye göre başka bir neden. Dispozisyon ise inceleme sonrasında ürünle ne yapılacağını belirler: yeniden stoğa alma, karantina, tamir, yenileme, değiştirme, hurda, tedarikçiye gönderme veya bayiye geri çevirme. Talep nedeni, inceleme sonucuyla otomatik olarak aynı kabul edilmemelidir.
Microsoft'un iade dispozisyonu belgeleri, neden kodu ile dispozisyon kodunu ayrı tutar ve dispozisyon eyleminin fiziksel, mali ve değişim sonucunu etkileyebildiğini açıklar. Kod listesi işletmeye göre özelleştirilebilir; fakat her kodun stok, finans ve müşteri iletişimi etkisi net olmalıdır.
Ön inceleme fiziksel kabulün yerine geçmez
Fotoğraf, video, seri numarası veya fatura bilgisi gereksiz gönderimi azaltmaya yardımcı olabilir; ancak fiziksel ürünün durumunu kesin olarak kanıtlamayabilir. Ön inceleme sonucunu “gönderim yetkisi”, depo/kalite sonucunu “kabul ve dispozisyon” olarak ayrı durumlarda saklayın. Bayiye de bu ayrımı açıkça gösterin.
Talep reddedildiğinde gerekçe ve eksik kanıt görünür olmalıdır. Ek bilgi istendiğinde yeni talep açtırmak yerine aynı sürüm zincirinde yanıt alınabilir. Gönderim izni verildiğinde hedef depo, geçerlilik tarihi, izinli ürün/miktar, paketleme şartı ve çok kolili gönderim davranışı belirtilmelidir. RMA etiketi kimliği kolaylaştırır; ancak güvenlik, tehlikeli madde, sıcaklık veya taşıma kurallarının yerine geçmez.
Beklenen–gelen–karar mutabakatını satır düzeyinde yapın
| Alan | Beklenen | Depoda gelen | İnceleme kararı | Fark davranışı |
|---|---|---|---|---|
| Ürün ve varyant | Yetkilendirilen stok kodu | Okunan/tespit edilen ürün | Aynı, farklı veya tanımsız | Karantina ve inceleme görevi |
| Miktar | İzin verilen miktar | Fiilî sayım | Kabul/red miktarı | Eksik/fazla fark kaydı |
| Seri/lot | Talepteki kimlikler | Okunan kimlikler | Doğrulandı veya uyuşmadı | Kaynak satış ve sahiplik kontrolü |
| Fiziksel durum | Bildirilen sorun | Ambalaj ve ürün gözlemi | Dispozisyon ve bulgu | Fotoğraf, not ve sorumlu |
| Belge | RMA ve satış referansı | Kargo/koli referansı | ERP işlem referansı | Eksik bağ varsa kapanışı durdur |
Kısmi geliş olağandır: iki üründen biri gelebilir, koli içindeki miktar farklı olabilir veya ürünlerin sonuçları ayrışabilir. Bu nedenle iade başlığını tek seferde kapatmak yerine satır ve gerekirse seri/lot düzeyinde kalan miktarı izleyin.
Depo kabulünde karantina ile satılabilir stoku ayırın
Ürün kapıdan girdiği anda satılabilir stoğa eklenmemelidir. İlk kayıt, ürünün fiziksel olarak ulaştığını gösterir; kalite ve dispozisyon kararı kullanılabilirlik durumunu belirler. İade alanı, inceleme alanı, tamir, hurda ve tekrar satış konumlarının sistemde ayırt edilmesi yanlış rezervasyon ve sevkiyatı önlemeye yardımcı olur.
Microsoft'un depo konum yönlendirme belgeleri, iade emirlerinde dispozisyon koduna göre ürünü inceleme veya karantina konumuna yönlendirme örneği verir. SAP iade inceleme belgeleri de tam veya kısmi miktarlar için depo inceleme sonuçlarının kaydedilebildiğini belirtir. Ürün seçimi ve depo altyapısı değişse de temel ayrım sabittir: fiziksel geliş, kalite kabulü değildir.
Seri, lot ve çoklu koli ilişkisini baştan tasarlayın
Seri takipli üründe her birimin geçmiş satış ve iade kararı ayrı olabilir. Lot takipli üründe miktar, üretim partisi, son kullanım veya kalite bağlamı önem kazanır. Serisiz üründe bile bir koli birden fazla RMA satırı taşıyabilir; tek RMA da birden fazla kolide gelebilir. Veri modeli RMA–koli–satır–seri/lot ilişkisini çoktan çoğa desteklemelidir.
Depo çalışanı yalnız serbest metin aramak yerine RMA, paket veya ürün kimliğini tarayabilmeli; beklenen kayıtla fark varsa güvenli biçimde istisna açabilmelidir. Barkod ya da QR kullanılması otomatik olarak doğruluk sağlamaz: kodun hangi nesneyi temsil ettiği, yeniden basım yetkisi ve mükerrer tarama davranışı belirlenmelidir.
Dispozisyon, stok ve finans sonuçlarını tek kuralla körlemesine bağlamayın
“Kabul edildi” kararı her zaman stoğa dönüş veya anında alacak anlamına gelmez. Ürün karantinaya, teknik servise, hurdaya veya tedarikçiye gidebilir. Finansal sonuç; sözleşme, satış belgesi, kabul edilen miktar, masraf ve kurum politikasına bağlı olabilir. Portal, depo ve ERP arasında hangi sistemin ürün durumu, stok değeri ve mali belgenin ana kaynağı olduğu yazılmalıdır.
ERP çağrısı başarısız olursa depo kararını kaybetmeyin ve ikinci fiziksel kabul oluşturmayın. Kalıcı iade/satır kimliğiyle teknik yeniden deneme yapılmalı; veri hatası insan incelemesine gitmelidir. Genel stok, sipariş, ödeme ve iade alanlarının sistem sahipliği için e-ticaret–ERP entegrasyonu rehberini kullanabilirsiniz.
Bayiye tek durum yerine anlamlı kilometre taşları gösterin
“İşleniyor” etiketi haftalar boyunca aynı kaldığında portal şeffaflık sağlamaz. Talep alındı, ek bilgi bekleniyor, gönderim yetkisi verildi, taşıyıcıya teslim edildi, depoya ulaştı, incelemede, karar verildi, mali işlem bekleniyor ve kapandı gibi işletmeye uygun kilometre taşları kullanın. İç teknik hataları aynen göstermek yerine güvenli ve eyleme dönük açıklama verin.
Her durumun sahibi ve beklenen sonraki adımı bulunmalıdır. Bayiden belge bekleniyorsa gereken dosya; depodan sayım bekleniyorsa koli; finans ekibinden işlem bekleniyorsa ilgili karar paketi görünür olmalıdır. Bildirim, durumun kendisi değildir; e-posta gitmese bile portal kaydı doğru kalmalıdır.
Kabul testleri gerçek farkları kapsamalıdır
| Senaryo | Beklenen davranış | Kanıt |
|---|---|---|
| RMA'da iki ürün, depoda yalnız biri var | Gelen satır işlenir; kalan miktar açık kalır | Sayım ve açık bakiye |
| Başka seri numarası geldi | Otomatik stoğa giriş olmaz; inceleme kuyruğu açılır | Beklenen/gelen seri farkı |
| Aynı koli iki kez tarandı | İkinci fiziksel kabul oluşmaz | Paket kimliği ve önceki işlem |
| Bir satır satılabilir, diğeri hurda | Satırlar farklı dispozisyon ve konuma ayrılır | Satır bazlı karar geçmişi |
| ERP yanıtı alınmadan bağlantı kesildi | Aynı işlem kimliğiyle güvenli yeniden deneme yapılır | Tek mali/ERP kaydı |
| İade süresi veya sözleşme koşulu belirsiz | Otomatik ret yerine yetkili incelemesine gider | Politika sürümü ve karar sahibi |
Başarıyı yalnız kapanış süresiyle ölçmeyin
Talep–ön karar, gönderim–depo gelişi, depo–inceleme ve karar–mali kapanış sürelerini ayrı ölçün. İlk seferde doğru RMA oranı, eksik kanıt, beklenen/gelen miktar farkı, seri uyuşmazlığı, istisna yaşı, yeniden açılan talepler, dispozisyon dağılımı ve ERP hata kuyruğu birlikte izlenmelidir. Hız uğruna inceleme veya yetki adımlarını atlamak başarı değildir.
Teklifte hangi teslimatlar bulunmalı?
- İade nedeni, uygunluk ve gerekli kanıt karar tablosu
- RMA, koli, satır, seri/lot ve satış belgesi veri modeli
- Ön inceleme, gönderim, depo kabulü, kalite ve kapanış durumları
- Beklenen–gelen–karar mutabakatı ve kısmi kabul davranışı
- Dispozisyon, karantina, stok konumu ve yeniden satış kontrolleri
- ERP alanları, işlem kimliği, yeniden deneme ve hata kuyruğu
- Bayi görünürlüğü, bildirim, belge ve fotoğraf erişim yetkileri
- Sınır koşullarını kapsayan kabul testi ve operasyon sahipliği
Üyelik, belge, talep ve ödeme gibi daha geniş öz-servis kapsamı için müşteri portalı kapsam rehberini inceleyebilirsiniz.
Sonuç: İade, tek onay değil kanıt zinciridir
B2B iade sistemi; bayinin bildirimini depo gerçeğiyle, inceleme sonucunu stok davranışıyla ve mali kapanışı doğru ERP kaydıyla ilişkilendirmelidir. RMA kimliği, bu zinciri birleştirir; her adımın yerine geçmez. Bayi talebinden depo ve ERP kapanışına kadar kuruma özel akışı planlamak için Kumsal Ajans e-ticaret çözümlerini inceleyebilirsiniz.