Bir ürün kartında “stokta var” yazması, depodaki bütün birimlerin aynı üretim partisinden geldiği anlamına gelmez. Aynı ürün farklı günlerde, farklı partilerde veya farklı tarih bilgileriyle teslim alınmış olabilir. Sipariş satırı yalnız ürün koduna ve toplam miktara bağlanıyorsa, ekip hangi fiziksel partinin müşteriye ayrıldığını sonradan göremeyebilir.

Bu rehber, ürünün genel kataloğunu veya toplam satılabilir stok hesabını yeniden kurmaz. Dar konusu, sipariş satırına seçilen gerçek parti kaydını ve varsa o partiye ait tarih bilgisini bağlamak; toplama, sevk ve düzeltme adımlarında bu ilişkinin kaybolup kaybolmadığını sınamaktır. Örnekler kurgu iş akışlarıdır. Belirli bir ürün grubu için mevzuat, etiketleme veya güvenlik yükümlülüğü tanımlamaz.

Ürün, varyant, parti ve tarih farklı soruları yanıtlar

Ürün kimliği müşterinin ne satın aldığını anlatır. Varyant, renk, hacim veya paket büyüklüğü gibi satın alma seçeneğini ayırabilir. Parti kaydı ise aynı ürün ve varyantın hangi ayrı teslim alınmış ya da üretilmiş grubundan söz edildiğini gösterir. Tarih alanı, işletmenin kaydettiği üretim, paketleme, tavsiye edilen tüketim veya son kullanım bilgisini belirli bir partiye bağlayabilir. Her tarih her üründe bulunmayabilir.

Bu katmanları tek bir ürün adına veya serbest not alanına sıkıştırmak, ilişkiyi kırılgan yapar. Örneğin “Kahve 250 g” ürün ve varyantı gösterebilir; “P-2407” işletmenin seçtiği parti kimliği olabilir; “15.08.2027” ise kaynak kayıttaki belirli tarih alanı olabilir. Bu örnekler kurgusaldır. Parti kodunun nasıl üretileceği veya tarihin hangi anlamı taşıyacağı işletmenin doğrulanmış kaynağından belirlenmelidir.

Ürün, seçenek ve stok bilgisinin nerede tutulduğunu anlamak için ürün, varyant ve stok veri modeli rehberine bakabilirsiniz. Buradaki ek karar, bu modeldeki toplam miktarların içinden hangi fiziksel partinin belirli sipariş satırına ayrıldığını kayda geçirmektir.

Toplam miktarı parti bakiyesiyle karıştırmayın

Bir varyantın satılabilir toplamı beş olabilir; ancak bu beş birimin iki ayrı partiden geldiği varsayımsal bir durumda, siparişe düşen miktarın hangi partiden ayrıldığı ayrıca bilinmelidir. Toplam stok, bir ürünün satışa açık miktarıyla ilgili soruya; parti bakiyesi ise belirli bir parti içinde elde kalan miktara yanıt verir. İkisini aynı alanda güncellemek, toplam doğru görünürken parti dağılımını belirsiz bırakabilir.

Parti bakiyesi de tek başına sipariş kanıtı değildir. Birim depoda sayılmış olabilir, kalite kontrolünde bekleyebilir, başka siparişe ayrılmış olabilir veya henüz toplama için seçilmemiş olabilir. İşletmenin kullandığı durum adlarını, hangi olayla değiştiklerini ve yetkili kaynağı belirleyin. Stok senkronizasyonu rehberi toplam miktar, rezervasyon ve kanallar arasındaki akışı inceler; bu yazı ise sipariş satırının belirli partiye tahsisini ele alır.

Birden çok depo veya satış kanalı varsa, parti kimliği ve miktarının hangi kayıttan geldiği açık olmalıdır. Bir sistem toplamı güncellerken başka bir sistem parti bakiyesini değiştiriyorsa, sipariş satırına bağlanan değer bu iki akıştan hangisine dayanıyor? Eşitleme sonrasında sadece ürün bazındaki toplamı değil, her partinin başlangıç miktarı, ayrılan miktarı ve kalan bakiyesini de örneklerle karşılaştırın.

Sipariş satırına kaynak kimliğini bağlayın

Sipariş oluşturulduğunda her satırda ürün ve varyant kimliğinin yanında, tahsis edilmiş parti kaydı için ayrı bir ilişki tutulabilir. İlişki, parti kodunu metin olarak tekrarlamaktan daha güvenli biçimde değişmez bir iç kayıt kimliğine dayanabilir; kullanıcıya gösterilecek parti kodu ise bu kayda bağlı kalır. Kullanılan yöntemi yazılım ekibiyle doğrulayın. Aynı ürünün adı veya kodu düzeltildiğinde geçmiş siparişin hangi fiziksel kaydı temsil ettiği kaybolmamalıdır.

Parti seçiminin ne zaman kesinleşeceği bir iş kararıdır. Sipariş kabul edilirken, depoda toplama başlarken veya fiilen ürün seçildiğinde bağ kurulabilir. Önceden tahmin edilen parti ile çalışanın gerçekten aldığı parti farklı çıkabilir. Bu nedenle sistem ilk tahsisi ve son doğrulanmış seçimi ayrı olaylar olarak saklayabilir. Hangi adımın müşteriye verilen bilgi için esas olduğu ekiplerce açıkça kararlaştırılmalıdır.

Bir sipariş satırı birden çok partiden karşılanıyorsa, ilişki tek değer varsaymamalıdır. Örneğin aynı sipariş miktarının iki birimi bir partiden, kalan bir birimi başka partiden toplanmış olabilir. Her alt miktarın hangi partiye bağlandığı, ilgili tarih kaydı ve hareket zamanı ayrı izlenebilir. Müşteri ekranında gereksiz depo ayrıntısı göstermek şart değildir; destek ve operasyon tarafında siparişi açıklamaya yetecek kayıt bulunmalıdır.

Toplama ve sevk sırasında değişikliği kaydedin

Toplama listesi ürün ve miktarı gösterip parti seçimini saklıyorsa çalışan doğru birimi bulduğunu sanabilir, fakat sipariş kaydında hangi partinin kullanıldığı görünmez. Barkod, parti etiketi, el terminali veya manuel doğrulama gibi yöntemler değerlendirilebilir; her yöntem gerçek depo düzeninde denenmelidir. Başarılı tarama yalnız kodun okunduğunu gösterir. Kodun doğru ürün, varyant ve partiye ait olduğu ayrıca doğrulanmalıdır.

Toplanan parti beklenen kayıtla eşleşmiyorsa süreç bunu sessizce kabul etmemelidir. Çalışan yanlış seçim uyarısı alabilir, yetkili bir rol farklı bir parti seçebilir veya sipariş istisna durumuna geçebilir. Hangi yolun kullanılacağını işletme belirler. Sistem değişikliği yapan kişiyi, eski ve yeni parti ilişkisini, miktarı ve gerekçeyi kaydetmelidir. Böylece sonradan yapılan düzeltme ilk seçimmiş gibi görünmez.

Bir sipariş birkaç pakete bölünüyorsa, her sevk edilen miktarın parti bağlantısı korunmalıdır. Etiket oluşturma, taşıyıcıya teslim ve müşteriye bildirim farklı olaylardır. Siparişin tümü gönderildi gibi görünen bir ana durum, gerçekte hangi satırın hangi partiden ve hangi miktarda çıktığını perdelememelidir. Kargo takibi, parti tahsisinin yerine geçmez; iki kayıt farklı sorulara yanıt verir.

Tarih bilgisinin anlamını ve kaynağını belirtin

“Tarih” tek başına yeterince açık bir alan adı değildir. Üretim tarihi, paketleme tarihi, tavsiye edilen tüketim tarihi ve son kullanım tarihi aynı anlama gelmez. Alan etiketi, veri kaynağı ve biçim birlikte tanımlanmalıdır. GS1’in resmi uygulama tanımlayıcıları sözlüğü, parti/lot numarasıyla farklı tarih türlerini ayrı tanımlar; bu, her ürün veya işletme için belirli bir alanın zorunlu olduğu anlamına gelmez. Kullanılacak bilgi ürün kaydının gerçek kaynağından doğrulanmalıdır.

Tarih doğrudan partiye aitse, sipariş satırındaki parti seçiminin bu tarihe nasıl eriştiği test edilir. Tarih yalnız ürün seviyesinde tutuluyorsa farklı partilerin değişen tarihleri aynı alanda ezilebilir. Eksik veya çelişkili kaynak varsa sistemin tahmin yapması yerine kayıt beklemeye alınabilir. Müşteriye gösterilecek bilgiye karar verilirken şirketin kendi onaylı ürün ve iletişim politikası izlenmelidir; bu yazı yasal bir etiket ya da satış kuralı önermez.

Yeni veya bekleyen ürün satışında parti henüz belirlenmemiş olabilir. Bu durumda ön sipariş kapasitesi ve teslim beklentisi başka bir iş akışıdır; sipariş satırına fiziksel parti bağlandığı iddia edilmemelidir. Ön sipariş sayfası rehberi hazır stok ile beklenen tedarik bilgisini ayırır. Ürün depoya geldiğinde tahsis kaydı, gerçek kabul ve toplama hareketine dayanmalıdır.

İstisnalarda iz bırakın, geriye doğru sorgulayın

İade, iptal, eksik toplama, hasarlı birim veya sipariş satırında yapılan düzeltme, önceki parti hareketini silmemelidir. İşlem iptal edilse bile “hangi kaydın, ne zaman, kimin tarafından, hangi gerekçeyle geri alındığı” görülebilmelidir. Böylece güncel bakiye yeniden hesaplanabilir ve sipariş geçmişi açıklanabilir. İade edilen ürünün yeniden satışa açılıp açılmayacağı ayrı işletme kararıdır; sistem bunu otomatik varsaymamalıdır.

Geriye doğru arama iki yönde çalışmalıdır: sipariş satırından seçilmiş partiye ulaşmak ve parti kaydından hangi sipariş satırlarının etkilendiğini bulmak. Bu, inceleme için bilgi sağlar; tek başına resmi bir geri çağırma süreci, yasal uygunluk veya tüm kayıtların eksiksiz yakalanacağı garantisi değildir. Erişim yetkisi, saklama süresi ve hangi rolün bu aramayı yapabileceği işletmenin kendi veri yönetimi düzeninde belirlenmelidir.

Kontrol listesini gerçekçi örneklerle sınayın: aynı varyantta iki parti; bir satırın miktarının iki partiye bölünmesi; sipariş sonrası yanlış parti seçimi; kısmi sevk; iptal ve geri ekleme; eksik tarih; çift gelen depo bildirimi. Her senaryoda beklenen başlangıç ve sonuç değerini yazın. Yalnız ekrandaki ürün toplamına değil, parti hareketine, sipariş bağlantısına ve değişiklik geçmişine bakın. Bir örnek hata verirse veri kaynağı, arayüz ve işlem kuralını birbirinden ayırarak kök nedeni bulun.

Yayına geçmeden önce sipariş, toplama, sevk ve düzeltme adımlarından sorumlu kişilerin aynı terimleri kullandığını doğrulayın. Deneme kayıtları gerçek müşteri verisi içermemelidir. Kabul koşullarını tamamlayan testlerin ardından hangi senaryonun kapsam dışında kaldığını da kaydedin. BiKreatif’in e-ticaret yazılımı hizmetini inceleyebilir; yukarıdaki ürün modeli, stok eşitlemesi ve ön sipariş rehberlerini iş akışınızı tasarıma aktarırken yardımcı kaynak olarak kullanabilirsiniz.

Sık Sorulan Sorular

Parti kaydı ürün varyantından nasıl ayrılır?

Varyant satın alınabilir seçeneği, örneğin hacim veya rengi ayırır. Parti, aynı ürün ve varyantın ayrı bir fiziksel grubunu gösterir. İşletmenin kullandığı parti kimliği ve bu kayda bağlı tarih, katalogdaki ürün adından ayrı saklanmalı ve sipariş hareketine bağlanmalıdır.

Sipariş satırına parti bilgisi ne zaman bağlanmalı?

Bu, sipariş kabulü, depo ayırması veya fiili toplama aşamasında kesinleşebilir. Seçim sonradan değişebiliyorsa ilk tahmini ve doğrulanmış son partiyi ayırın. Hangi olayın müşteri ve destek ekranında esas alınacağı iş akışında kararlaştırılmalıdır.

Aynı sipariş satırı iki partiden karşılanabilir mi?

Operasyon bunu destekliyorsa satır miktarı alt kayıtlara bölünebilir. Her alt miktar ilgili partiye, tarih bilgisine ve sevk hareketine bağlanmalıdır. Tek bir parti alanına son seçimi yazıp önceki miktar dağılımını silmek geçmişi açıklamayı zorlaştırır.

Ürün toplamı doğruysa parti takibi de doğru mudur?

Hayır. Toplam miktar kanallar arasında doğru eşitlenmiş olsa bile, hangi partinin hangi siparişe ayrıldığı kaybolabilir. Ürün bakiyesiyle parti bakiyesini ayrı kontrol edin; testte sipariş satırı, toplama kaydı ve kalan miktarı birlikte karşılaştırın.

Tarih bilgisi boşsa yazılım tahmin edebilir mi?

Hayır. Kaynakta tarih yoksa veya iki kaynak farklıysa sistem bunu eksik ya da çelişkili olarak göstermelidir. Tarih türü ve değerini ürün kaydının yetkili kaynağından doğrulayın. Boşluğu genel ürün bilgisiyle doldurmak, belirli partinin kaydını kanıtlamaz.

Parti ve tarih bilgisini müşteriye göstermek gerekir mi?

Bu yazı evrensel bir gösterim kuralı koymaz. Müşterinin göreceği bilgi, ürünün gerçek niteliğine ve işletmenin onaylı iletişim düzenine göre belirlenmelidir. Operasyon tarafında sipariş ile seçilen parti ilişkisi bulunmalı; gösterilmeyen bilgi de doğrulanmış kayıtla çelişmemelidir.

İptal edilen siparişte parti bakiyesi nasıl düzeltilir?

İptal edilen tahsis ayrı bir hareket olarak kaydedilebilir; önceki bağ silinmemelidir. Yetkili kaynakta ürünün gerçekten hangi duruma döndüğü doğrulanmalı ve ilgili parti bakiyesi güncellenmelidir. İptal, iade ve yeniden satışa açma aynı olay değildir.

Partiden etkilenen siparişleri bulmak kesin sonuç garantisi verir mi?

Hayır. Geriye doğru sorgu mevcut ilişkili kayıtları bulmaya yardımcı olur; eksiksiz veri, mevzuata uygun süreç veya resmi geri çağırma garantisi değildir. Hangi verinin tutulduğu, erişebilen roller ve izlenecek kurumsal süreç ayrıca tanımlanmalıdır.