Karekod ile iade kabul, geri gelen ürünün doğru satış veya sevkiyat kaydıyla eşleştirilmesini ve kontrol tamamlanmadan kullanılabilir stoğa karışmamasını sağlayacak şekilde tasarlanır. Ürün kimliği, fiziksel konum ve karar durumu birlikte izlenir. Temel stok hareketleri için Posingo depo barkod sistemi, kuruma özel onay akışından ayrı kapsamda değerlendirilebilir.
İade kabul neden normal mal kabulden ayrılmalıdır?
İade kabulde depoya giren ürünün kimliği kadar geçmişi ve mevcut durumu da incelenir. Fiziksel teslim alınan ürün her zaman yeniden satılabilir değildir. Bu nedenle teslim alma, inceleme ve kullanılabilir stok onayı ayrı olaylar olarak kaydedilmelidir.
Normal tedarik girişinde beklenen ürün ve miktar satın alma belgesine bağlanır. İadede ise farklı satış kanalları, eksik aksesuarlar, açılmış ambalajlar ve önceki servis işlemleri gündeme gelebilir. Personelin yalnız ürün barkodunu okutup stoğa eklemesi bu ayrıntıları görünmez bırakır. Geri gelen ürünün hangi hareketle ilişkili olduğu ve kabul sırasında hangi koşulda bulunduğu ayrıca tutulmalıdır.
Buradaki karantina ifadesi, kontrol bekleyen ürünün operasyonel olarak ayrılması anlamındadır. Her sektörün fiziksel güvenlik, kalite ve mevzuat gereksinimleri farklı olabilir. Yazılımda bir durum seçmek tek başına bunları karşılamaz. Bu rehber depo iş akışını ele alır; hukuki iade hakkı veya sektörel uygunluk kararı yerine geçecek otomatik hükümler üretmez. Süreç, işletmenin yetkili ekiplerinin belirlediği kurallarla tamamlanır.
İlk teslimde hangi bilgiler kaydedilmelidir?
İlk teslim kaydı, ürünün depoya hangi olayla geldiğini ve kimin teslim aldığını açıklamalıdır. Kaynak belge, beklenen ürün, gelen miktar ve gözlenen durum temel başlangıç alanlarıdır. Sonradan yapılan kalite kararları bu ilk gözlemin üzerine eklenmeli, ilk kayıt sessizce değiştirilmemelidir.
Depo görevlisi kargodan bir koli aldığında önce sevkiyat veya iade talebiyle ilişki kurar. Belge bulunamıyorsa geliş kaydı yine izlenebilir olmalı; fakat otomatik satış düzeltmesi yapılmamalıdır. Gönderenin beyanı ile fiilen gelen içerik ayrı alanlarda tutulabilir. Bu ayrım özellikle bir kolide birden fazla ürüne ait iade bulunduğunda önemlidir. Paket sayısı ile ürün adedi birbirine karıştırılmaz.
Kabul anındaki hasar, eksik parça veya ambalaj durumu gerektiğinde fotoğrafla desteklenebilir. Fotoğrafın hangi ürün ve hangi kabul olayıyla ilişkili olduğu belli olmalıdır. Ortak klasöre rastgele dosya yüklemek sonraki incelemeyi zorlaştırır. Gereksiz kişisel bilgiler kadraja alınmaz. Fotoğrafın varlığı da tek başına karar değildir; inceleme yetkisi ve sonraki işlem ayrı iş akışıyla belirlenir.
Ürün, seri ve lot eşleşmesi nasıl yapılır?
Ürün barkodu ürün çeşidini tanımlayabilir; seri numarası tekil ürünü, lot ise belirli bir partiyi ayırt eder. Hangi kimliğin gerekli olduğu işletmenin izlenebilirlik modeline bağlıdır. Satılan tekil ürünle geri gelen nesnenin eşleşmesi gerekiyorsa yalnız ürün kodunu kontrol etmek yeterli olmaz.
Örneğin aynı modelden birçok cihaz satılmış olabilir. Model barkodu doğru olduğu halde geri gelen seri numarası başka satışa ait çıkabilir. Uygulama bunu görünür uyuşmazlık olarak göstermelidir. Personelin işlemi kapatmak için seri alanını gelişigüzel değiştirmesi uygun değildir. Kaynak belgedeki seri ile fiziksel etiketteki seri yan yana incelenir; gereken karar yetkili role bırakılır.
Lotla çalışan ürünlerde ise miktar, birim ve parti ilişkisi birlikte kontrol edilir. Geri gelen koli farklı lotlardan ürün içeriyorsa tek satırda toplamak izlenebilirliği zayıflatabilir. Etiket okunamıyorsa geçici inceleme kimliği verilebilir; bunun asıl ürün kimliği yerine geçtiği varsayılmaz. Son eşleştirme tamamlandığında geçici kaydın hangi ürün ve hangi kabul olayıyla bağlandığı geçmişte görülebilmelidir.
Fiziksel karantina alanı ile yazılım durumu nasıl eşleştirilir?
Karantina alanı, kontrol bekleyen ürünün yanlışlıkla normal stoktan seçilmesini önlemeye yönelik operasyon düzenidir. Yazılımda ayrılmış durum ile gerçek raf veya bölme birbirini karşılamalıdır. Ürün ekranda beklemede görünürken fiziksel olarak satış rafında tutulmamalıdır.
Alan kodu belirlenirken ekiplerin günlük kullanım alışkanlıkları dikkate alınır. Büyük bir depo için ayrı raf, küçük bir işletme için tanımlanmış kapalı bölme uygun olabilir; çözüm koşula göre seçilir. Her hareketin nereden nereye yapıldığı kayda alınır. Ürünün kabul masasında kalmasıyla karantina rafına yerleştirilmesi aynı konum değildir. Sürecin sorumlusu bu farkı ekranda görebilmelidir.
Ayrılmış ürünün kullanılabilir stok hesaplarına nasıl yansıyacağı açıkça yazılmalıdır. Fiziksel toplam ile satılabilir miktar farklı değerlerdir. Satış ekranı hangi miktarı gösteriyor, sipariş ayırma hangi miktarı kullanıyor, rapor hangi durumu topluyor soruları birlikte cevaplanır. Yalnız raf adını değiştirmek, diğer modüllerin ürünü kullanmasını otomatik olarak engellemeyebilir. Bu davranış gerçek kabul testiyle görülmelidir.
İnceleme durumları ve karar yetkisi nasıl tanımlanır?
Durumlar, ürünün süreçte nerede olduğunu ve sıradaki kararın kimden beklendiğini açıklamalıdır. Gereğinden fazla durum personeli zorlayabilir; çok az durum ise farklı ihtiyaçları aynı başlıkta toplar. Her durum için giriş şartı, yetkili rol ve izin verilen sonraki adım belirlenmelidir.
| Durum | Gerekli kayıt | Karar noktası |
|---|---|---|
| Teslim alındı | Kabul kimliği, kaynak, miktar | İnceleme alanına yönlendirme |
| Kimlik incelemesi | Ürün / seri / lot karşılaştırması | Eşleşme veya uyuşmazlık |
| Kontrol bekliyor | Konum ve sorumlu rol | İnceleme başlatma |
| İnceleme tamamlandı | Gözlem ve gerekçe | Yetkili stok kararı |
| İşlem kapandı | Hedef hareket ve belge ilişkisi | Mutabakat doğrulama |
İlk kabulü yapan personelle yeniden stoğa alma kararı veren rol ayrılabilir. Her işletmede aynı onay sayısına ihtiyaç yoktur; önemli olan sorumlulukların belirsiz kalmamasıdır. Yetki modelinde vekâlet ve görev değişimi de düşünülür. Bir çalışan izinliyken işlemin sahipsiz kalması yerine yetkili devralma yöntemi bulunmalıdır. Kararın hangi kullanıcı tarafından hangi gerekçeyle verildiği geçmişte saklanır.
Kısmi iade ve eksik aksesuar nasıl yönetilir?
Bir satışın yalnız bazı satırları veya belirli miktarı geri gelebilir. İade kaydı, belgenin tamamını geri dönmüş gibi göstermeden satır ve miktar seviyesinde kurulmalıdır. Aksesuar eksikliği de ürün adediyle aynı veri alanında tutulmamalıdır.
Örneğin üç parçalı bir setin iki parçası gelmiş olabilir. Ürün kartında set birimi kullanıldığı halde fiziksel kontrolde parça bazında değerlendirme gerekebilir. Hangi dönüşümün geçerli olduğu önceden belirlenir. Personelin ekranda bir set seçmesi, eksik parçanın varlığını kanıtlamaz. Kontrol listesi; ana ürün, aksesuarlar ve ambalaj için ayrı gözlem alanları içerebilir.
Kısmi iadede önceki kabul edilen miktarlar da kontrol edilir. Aynı satış satırı için birden fazla geliş varsa toplam geri dönüşün beklenen miktarla ilişkisi görülmelidir. Aksi halde aynı belge üzerinden tekrar tekrar ürün kabul edilmesi mümkün hale gelebilir. Sınır aşımı bir uyarı veya yetkili inceleme gerektirebilir. Bu iş kuralının kullanılan yazılımda gerçekten nasıl uygulandığı pilotta doğrulanır.
Tekrar okutma ve çift kabul riski nasıl azaltılır?
Aynı ürünün tekrar okutulması her zaman yeni bir fiziksel ürün geldiği anlamına gelmez. Tarama olayı ile kabul hareketi birbirinden ayrılmalıdır. Uygulama, kullanıcının mevcut satırı mı kontrol ettiğini yoksa yeni miktar mı eklediğini açıkça göstermelidir.
Yoğun kabul masasında cihaz aynı etiketi iki kez algılayabilir. Bazı ekranlar her okumada miktarı artırır; bazıları mevcut satırı açar. Personelin bu davranışı bilmesi gerekir. Seri numarasıyla izlenen ürünlerde aynı seri aynı açık kabulde yeniden görülürse önceki kayıt gösterilebilir. Adetle çalışan ürünlerde ise aynı barkoddan birçok ürün bulunabileceği için farklı kontrol modeli gerekir.
Aktarım tarafında da aynı kabulün ERP’ye iki kez yazılmaması önemlidir. Kaynak kabul kimliği ve hedef hareket ilişkisi korunur. Ağ hatası sonrası yeniden gönderim yeni fiziksel giriş gibi ele alınmamalıdır. Bunun için API sözleşmesi ve tekrar davranışı ayrıca tasarlanır. İade akışının yalnız okuyucu ekranını düzeltmekle tamamlandığı varsayılmamalı; bağlı sistemdeki stok hareketi de kontrol edilmelidir.
Kalite kararı stok ve finans kayıtlarına nasıl bağlanır?
Kalite kararı ürünün fiziksel kullanım durumunu, finansal işlem ise ticari kayıtların karşılığını belirler. Bu iki olayın zamanlaması her işletmede aynı olmayabilir. Entegrasyon, birindeki değişikliğin diğerinde hangi işlemi tetikleyeceğini açıkça tanımlamalıdır.
Depoda teslim alınan ürün henüz incelenmeden mali işlem başlatılması, işletmenin süreç tercihine ve geçerli kurallarına bağlıdır. Yazılım projesinde bu karar kendiliğinden verilmez. Muhasebe, operasyon ve ilgili süreç sahipleri birlikte değerlendirme yapar. Hangi belge türünün kim tarafından oluşturulacağı ve hatalı durumda nasıl düzeltileceği belirlenir. Ürün stoğa girdi diye bütün ticari akışın kapandığı gösterilmez.
İnceleme sonrası ürünün yeniden kullanılabilir olması ayrı bir stok durumu geçişi oluşturabilir. Onarım, tedarikçiye gönderim veya başka kararlar için farklı hedef akışlar gerekebilir. Her birine hazır özellik varmış gibi yaklaşılmaz; mevcut sistemin desteklediği adımlar doğrulanır. Özel geliştirme ihtiyacı varsa kapsam, veri alanları ve kabul testleri ayrı maddeler halinde tanımlanır.
Bekleyen iadeler hangi ölçütlerle izlenmelidir?
İade raporu, yalnız kaç ürün geldiğini değil hangi ürünün neden beklediğini de göstermelidir. Bekleme süresi, durum, sorumlu rol ve fiziksel alan temel inceleme boyutlarıdır. Ölçüm tanımları tutarlı olmazsa raporlar ekipler arasında farklı yorumlanabilir.
İlk teslim tarihi ile kalite incelemesine başlama tarihi ayrı tutulduğunda gecikmenin nerede oluştuğu görülebilir. Ancak her gecikme aynı neden değildir; eksik belge bekleyen ürünle teknik inceleme bekleyen ürün ayrı değerlendirilir. Neden listesi işletmenin gerçek olaylarından türetilmelidir. Personelin her kaydı “diğer” seçeneğine atması, raporun karar vermedeki değerini düşürür.
Yeniden satışa açılan miktar raporlanırken aynı ürünün durumlar arasında gidip gelmesi tekrar sayılmamalıdır. Sayının kabul olayı, ürün adedi veya tekil seri bazında mı hesaplandığı belirtilir. Başlangıç ölçümü olmadan hız artışı veya hata azalması yüzdesi ileri sürülmez. Raporlama ihtiyacı kalite kontrol akışı ve stok kayıtlarıyla birlikte tasarlanabilir.
Pilot iade kabul testinde neler denenmelidir?
Pilot test, normal kabulün yanında uyuşmayan seri, eksik ürün, tekrar tarama ve yanlış rafa yerleştirme gibi durumları içermelidir. Beklenen işlem ve beklenen stok etkisi önceden yazılır. Başarı mesajı kadar kayıtların sonraki ekranlarda nasıl göründüğü de incelenir.
| Senaryo | Beklenen kontrol | Gözlenecek çıktı |
|---|---|---|
| Doğru ürün, doğru seri | Kaynakla birebir ilişki | Tek kabul kaydı |
| Seri uyuşmazlığı | Otomatik stok onayı verilmez | İnceleme durumu |
| Eksik aksesuar | Parça kontrol listesi | Ayrı eksiklik kaydı |
| Tekrar okutma | Mevcut kayıtla ilişki | İstenmeyen çift giriş oluşmaması |
| Karantina ürünü seçimi | Kullanılabilir stok filtresi | Satışa açılmadan seçilememesi |
Testte gerçek satış kaydı kullanılıyorsa ticari sonuç doğurmaması için uygun test ortamı ve örnek veri seçilir. Bir senaryonun hangi aşamada duracağı açıklanır. Kalite kararından önce ürünün satışa seçilememesi gibi kabul maddeleri gerçekten çalıştırılır. Sonradan verilen kararın geçmişi koruduğu görülür. Hangi örneklerin denendiği ve hangi istisnaların kapsam dışında kaldığı rapora açıkça yazılır.
Vardiya devrinde hangi bilgiler aktarılmalıdır?
Vardiya değişimi sırasında ürünün durumu, bulunduğu alan ve bekleyen karar birlikte devredilmelidir. Yalnız koli sayısını aktarmak açık incelemelerin sahipsiz kalmasına neden olabilir. Uygulama, sıradaki ekibin aynı kabul kimliği üzerinden devam etmesini sağlamalıdır.
Masada etiketsiz bir ürün bırakıldığında önceki çalışanın hafızasına bağımlı bir süreç oluşur. Geçici inceleme etiketi kullanılıyorsa okunabilir ve kayda bağlı olmalıdır. Ürünün neden ayrıldığı, son yapılan kontrol ve gereken sonraki adım kısa biçimde yazılır. Devir notunda kişisel yorum yerine gözlenmiş durumlar kullanılır. “Sorunlu ürün” ifadesi yerine görülen belirti belirtilir.
Yetkili karar verilmeden kapatılan işlemler ayrı kontrol edilebilir. Ayrıca fiziksel alanın belirli aralıklarla sayılması, ekrandaki bekleyen kayıtlarla yerindeki ürünlerin karşılaştırılmasına yardımcı olur. Fark varsa belgeyi silerek eşitlemek yerine nedeni incelenir. Böylece iade süreci günlük yoğunluk içinde görünmez bir stok alanına dönüşmez; sorumluluğu ve hareket geçmişi takip edilebilir kalır.
Özel geliştirme kapsamı nasıl somutlaştırılır?
Özel iade kabul yazılımı kapsamı, gerçek örnekler ve karar noktaları üzerinden oluşturulmalıdır. Kullanılacak cihaz, mevcut satış sistemi ve beklenen rapor birlikte değerlendirilir. Hazır bir ürünün desteklemediği onay veya durum akışı proje keşfinde ayrı geliştirme ihtiyacı olarak yazılır.
İlk görüşmede temsilî bir iade paketi, kaynak belgenin güvenli örneği ve mevcut ekranlar paylaşılabilir. Hangi adımda bekleme olduğu, personelin nerede tekrar veri girdiği ve hangi kararın kaybolduğu açıklanır. Bu bilgiler gereksiz ekran çoğaltmak yerine gerçek soruna odaklanmayı sağlar. Proje tesliminde yalnız kod değil süreç haritası, rol listesi ve kabul testleri de anlaşılır olmalıdır.
Mesai saatleri içinde uzaktan inceleme ve online teknik görüşme üzerinden mevcut akış değerlendirilir. Destek kapsamı, veri taşıma ihtiyacı ve sonraki değişikliklerin nasıl yönetileceği netleştirilir. Karekod Yazılım’ın özel yazılım yaklaşımında belirli bir iş akışının gerçekten geliştirilmesiyle, aynı akışın hazır bir üründe varsayılması ayrı konulardır. Uygulama kapsamı bu ayrım korunarak belirlenmelidir.
Örnek bir iade günü nasıl kayda alınır?
Bir işletmeye aynı gün iki ayrı pakette benzer ürünler geldiğini düşünün. İlk paket kaynak satışla eşleşirken ikinci pakette seri farkı görülsün. İki paketi aynı ürün satırına toplamak yerine ayrı kabul kimlikleriyle izlemek gerekir. İlk ürün inceleme kuyruğuna, ikinci ürün kimlik uyuşmazlığı durumuna yönlendirilir. Fiziksel olarak farklı bölmeler kullanılıyorsa yerleri kayda işlenir. Vardiya değişiminde iki olayın farklı nedenle beklediği görülebilir. Bu senaryo uygulama testi için kullanılabilir; gerçek bir müşteri vakası veya ölçülmüş performans örneği olarak sunulmaz. Test sonunda her paketin miktarı, kararı ve kaynak belgesi ayrı ayrı doğrulanır.
Sıkça Sorulan Sorular
İade gelen ürün doğrudan satış stoğuna eklenebilir mi?
Bu karar işletmenin ürün ve kalite sürecine bağlıdır. Kontrol gereken ürünler fiziksel olarak ayrılmalı ve kullanılabilir stoktan farklı durumda izlenmelidir. Teslim alma kaydı ile yeniden satışa açma onayı aynı olay olarak varsayılmamalıdır.
Karantina yalnız yazılımda bir durum seçmek midir?
Fiziksel alan ve operasyon kuralları da gereklidir. Ekrandaki durum, gerçek raf veya bölmeyle uyuşmalıdır. Satış ve sipariş ayırma ekranlarının bu ürünü nasıl ele aldığı ayrıca test edilmelidir.
Ürün barkodu doğruysa seri numarası kontrolü gerekir mi?
Tekil ürün izleniyorsa gerekebilir. Aynı modelden birçok ürün aynı ürün barkodunu taşırken seri numaraları farklıdır. Geri gelen ürünün ilgili satıştaki tekil nesne olması bekleniyorsa seri ilişkisi ayrıca doğrulanır.
Etiketi okunmayan ürün nasıl kabul edilir?
Ürün doğrudan tanımlanmış kabul edilmek yerine inceleme akışına alınabilir. Geçici kimlik fiziksel nesneyi kabul olayıyla bağlar. Asıl ürün eşleştirmesi yetkili incelemeyle tamamlanır ve iki kimlik arasındaki ilişki korunur.
Bir belgenin yalnız bir satırı iade edilebilir mi?
İş akışı satır ve miktar seviyesinde tasarlanabilir. Önceki iadeler ve beklenen toplam birlikte kontrol edilir. Kaynak belgenin tamamının geri döndüğü gösterilmeden, gerçekten gelen ürünlerin karşılığı tutulmalıdır.
Bu rehber finansal iade kurallarını belirliyor mu?
Hayır; rehber depo kabulü ve yazılım akışını açıklar. Ticari belge ve muhasebe adımları işletmenin ilgili yetkilileriyle ayrıca belirlenir. Fiziksel stok durumu, bütün finansal sürecin tamamlandığı anlamına gelmez.
İade akışı Posingo’da hazır olarak var mı?
Yazı belirli bir onay, karantina veya seri eşleştirme özelliğinin hazır olduğunu ileri sürmez. Kullanılacak sistemde mevcut davranış doğrulanır. Desteklenmeyen adımlar varsa özel geliştirme ihtiyacı ve entegrasyon kapsamı ayrı belirlenir.
Pilot için hangi örnekler hazırlanmalıdır?
Normal iade, seri uyuşmazlığı, eksik aksesuar, kısmi miktar ve tekrar okutma örnekleri yararlıdır. Her örnekte beklenen stok durumu ve yetkili karar yazılır. Güvenli örnek belgeler ve kullanılan cihaz bilgisi görüşmeye eklenebilir.
İade kabulünüzdeki bekleme ve kayıt noktalarını birlikte incelemek için Karekod Yazılım ekibine ulaşın. Örnek ürün, mevcut belge ve karar akışı üzerinden uygulanabilir kapsam oluşturulabilir.
İlgili rehberler
Naron Bilişim Teknolojileri San. ve Tic. A.Ş.
