Çoğu işletme sahibi panel değiştirmeyi bir dosya taşıma işi sanır. Eski e-pin scripti bir veritabanı kullanıyor, yenisi de kullanıyor; o zaman bir yedek alınır, birkaç sorgu yazılır, kodlar yeni tabloya akar, iş biter. Kağıt üzerinde kulağa mantıklı geliyor. Gerçekte ise göçten iki gün sonra müşteri paneline düşen "aldığım kod kullanılmış" mesajları, hangi kısmın hiç mantıklı olmadığını sana tek tek anlatır.
Stok kodu, sitendeki tek gerçek para birimidir. Ürün açıklamasını kaybedersen yeniden yazarsın, banner'ı kaybedersen yeniden tasarlarsın; ama tedarikçiden peşin ödeyip aldığın bir kod listesini kaybedersen o para geri gelmez. Bu yüzden dijital ürün satış scripti göçünde kritik olan şey tema, hız ya da tasarım değil: kasanın bir sistemden diğerine tek bir karakter bile bozulmadan, tek bir kod bile ikinci kez satılmadan geçmesidir. Aşağıda bu geçişin gerçekte neye benzediğini, nerede patladığını ve nasıl kontrol altına alındığını anlatıyorum.
Stok kodu göçü neden basit bir kopyala-yapıştır değil?
Her epin yazılım altyapısı stoğu kendi mantığına göre tutar. Bir sistemde kodlar ürüne doğrudan bağlıdır; diğerinde araya varyant, bölge ya da tedarikçi partisi girer. Bir sistemde "satıldı" bilgisi kodun kendi satırındaki bir durum alanında durur; diğerinde sipariş kalemiyle kurulan ilişkiden çıkarılır. Yani iki tarafta da "stok" kelimesi geçiyor olması, aynı şeyi kastettikleri anlamına gelmez.
Bu yüzden göçe sorgu yazarak başlamak baştan hatalıdır. İşe önce alan eşleme tablosu çıkararak başlanır: eski taraftaki her sütunun yeni tarafta karşılığı nedir, karşılığı yoksa o bilgi nereye park edilecek, karşılığı var ama biçimi farklıysa hangi dönüşüm uygulanacak. Bu tablo hazır olmadan çalıştırılan her içe aktarma denemesi, aslında canlı veriyle yapılan bir tahmindir. Tahminin bedeli de genelde tedarikçiye bir kez daha ödeme yapmak olur.
Şifreli kolonu görmezden gelirsen ne olur?
Ciddi bir e-pin satış yazılımı kodları düz metin tutmaz. Kodlar, uygulama tarafındaki bir anahtarla şifrelenir ve veritabanında okunamaz bir dizi olarak durur. Şimdi düşün: eski sistemin şifreleme anahtarını ve yöntemini bilmeden o kolonu yeni sisteme kopyalarsan, elinde binlerce satır anlamsız karakter kalır. Panel "5.000 stok var" der, müşteri satın alır, teslim edilen kod ise çöptür.
Doğru sıra şudur: kodlar eski sistemin kendi arayüzü ya da kendi kütüphanesi kullanılarak çözülür, ara bir güvenli dosyaya alınır, sonra yeni sistemin kendi şifreleme mantığıyla yeniden şifrelenerek yazılır. Ara dosya işlem biter bitmez kalıcı olarak silinir, sunucuda yedeği bırakılmaz. Eğer eski panelde anahtar erişimi yoksa, tek dürüst yol tedarikçi tarafından yeni bir kod partisi istemek ya da stoğu sıfırlayıp yeniden yüklemektir. Okunamayan veriyi taşımak, kaybı gizlemekten başka bir şey yapmaz.
Satılmış kod ile bekleyen kodu ayırmadan taşırsan?
Göçün en pahalı hatası budur. Eski sistemde bir kod satılmış olabilir ama durum alanı hâlâ "beklemede" görünebilir; çünkü satış bilgisi sipariş tablosunda tutulmuştur. Bu iki tabloyu birleştirmeden aktarım yaparsan, aylar önce teslim ettiğin kodlar yeni panelde tazeymiş gibi rafa döner ve ikinci kez satılır. Sonuç: iade, itiraz, ödeme sağlayıcısında risk puanı ve markana kalıcı bir leke.
Ayrımı dört kovaya göre yapmalısın: satılmış ve teslim edilmiş, rezerve/bekleyen siparişe bağlı, iade veya iptal sonrası serbest, hiç dokunulmamış saf stok. Yalnızca son kova doğrudan satılabilir stok olarak yeni tarafa girer. Diğer üçü de taşınır, ama geçmiş kaydı olarak, satışa kapalı biçimde. Geçmişi atmak da yanlıştır; müşteri altı ay sonra "ben bunu sizden almıştım" dediğinde kanıtın olması gerekir.
| Eski taraftaki veri | Yeni taraftaki karşılığı | Dönüşüm ihtiyacı | Atlanırsa sonuç |
|---|---|---|---|
| Şifreli kod kolonu | Kendi anahtarıyla şifreli stok alanı | Çöz → yeniden şifrele | Teslim edilen kod geçersiz olur |
| Durum alanı (satıldı/bekliyor) | Stok durumu + sipariş ilişkisi | Sipariş tablosuyla birleştirme | Aynı kod ikinci kez satılır |
| Ürün kimliği | Ürün + varyant/bölge kimliği | Eşleme sözlüğü | Kod yanlış ürüne düşer |
| Tedarikçi / parti bilgisi | Tedarikçi kaydı ve maliyet alanı | Tedarikçi tablosu önce kurulur | Kâr raporları anlamsızlaşır |
| Alış maliyeti | Birim maliyet | Para birimi ve kur normalizasyonu | Marj hesabı şişer ya da erir |
| Teslim tarihi / log | Sipariş geçmişi kaydı | Saat dilimi düzeltmesi | İtirazlarda kanıt kalmaz |
| Seri no / ek alan | Özel alan ya da not | Serbest alana park | Tedarikçi iadeleri takip edilemez |
Mutabakat yapmazsan göçün başarılı olduğunu nereden bileceksin?
"İçe aktarma tamamlandı" yazısı bir kanıt değildir. Kanıt, sayıların iki tarafta birebir tutmasıdır. Göç bittiği anda üç sayıyı karşılaştır: toplam kod adedi, satılabilir kod adedi ve ürün bazında dağılım. Üçü de eşitse devam et; en küçük sapma varsa dur ve nedenini bul. Genelde sapmanın kaynağı yinelenen kayıtlar, boş bırakılmış ürün eşlemesi ya da karakter seti farkından bozulan satırlardır.
İkinci kontrol örneklemedir. Her ürün grubundan rastgele beş kod seç, yeni panelde test siparişi üzerinden teslim et ve kodun ilgili platformda gerçekten çalıştığını doğrula. Bu adım sıkıcıdır, on beş dakika sürer ve göç sonrası şikayetlerin neredeyse tamamını önler. Pinova gibi lisanslı bir e-pin satış scripti kullandığında bu doğrulamayı panelin stok raporu üzerinden yapabilirsin; ürün bazında beklenen ve gerçekleşen adetleri yan yana görmek, elle tutulan not defterlerinden çok daha hızlı sonuç verir.
Stok göçü kayıplarının kaynak dağılımı
- Şifreleme / okunamayan kod 40%
- Satıldı-beklemede ayrımı 28%
- Ürün eşleme hatası 20%
- Karakter seti ve biçim 12%
Göç gecesini nasıl planlarsın, geri dönüş düğmen var mı?
Stok göçü canlı sitede yapılmaz. Sıra şudur: önce yeni kurulum ayrı bir alt alan adında hazırlanır, deneme aktarımı orada çalıştırılır, hatalar orada ayıklanır. Gerçek göç gecesinde eski panel satışa kapatılır, son yedek alınır, aktarım çalıştırılır, mutabakat yapılır ve ancak sayılar tuttuktan sonra alan adı yeni tarafa yönlendirilir. Satış açıkken aktarım yapmak, sen veriyi taşırken müşterinin aynı kodu satın alması anlamına gelir.
Geri dönüş planı da yazılı olmalı: eski veritabanı yedeği nerede duruyor, hangi komutla geri yüklenecek, alan adı kaç dakikada eski sunucuya döner. Bu planı göç gecesinden önce bir kez prova etmek, seni gerçek bir kriz anında panikten kurtarır. Kesinti süresini kısa tutmanın yolu hızlı yazmak değil, önceden prova etmektir.
| Kontrol adımı | Zamanı | Kanıt | Durum |
|---|---|---|---|
| Alan eşleme tablosu onaylandı | Göçten 3 gün önce | Tablo dosyası | Zorunlu |
| Şifreleme anahtarı erişimi test edildi | Göçten 3 gün önce | 5 kod çözüldü | Zorunlu |
| Deneme aktarımı alt alan adında yapıldı | Göçten 2 gün önce | Hata günlüğü boş | Zorunlu |
| Satış kapatıldı, son yedek alındı | Göç saati | Yedek dosya boyutu | Zorunlu |
| Adet mutabakatı tuttu | Aktarım sonrası | Üç sayı eşit | Zorunlu |
| Örneklemeyle teslim testi | Aktarım sonrası | 5 kod x her grup | Zorunlu |
| Geri dönüş provası yapıldı | Göçten 1 gün önce | Süre ölçümü | Önerilir |
| Ara çözülmüş dosya silindi | Aktarım sonrası | Dizin boş | Zorunlu |
Aktarımı yaparken her koda geçici bir kaynak etiketi yaz. Göçten sonra bir sorun çıktığında, o kodun eski sistemdeki hangi satırdan geldiğini saniyeler içinde bulursun. Etiketi bir ay sonra kaldırmak dakikalar alır; etiketsiz bir kayıp ise günler alır.
Göçten sonraki ilk hafta neye bakmalısın?
İlk yedi gün, göçün gerçekten başarılı olup olmadığını söyleyen tek dönemdir. Her sabah üç şeyi kontrol et: başarısız teslim sayısı, stoğu biten ürünlerin listesi ve müşteri mesajlarındaki "kod çalışmıyor" ifadesinin sıklığı. Bu üç metrik temizse göç tamamlanmıştır. Biri bozuksa sorun genellikle tek bir ürün grubundadır ve hızlıca yamanabilir.
Bu dönemde yeni ürün eklemeyi, kampanya başlatmayı ve tema değiştirmeyi ertele. Aynı hafta içinde birden çok değişiklik yaparsan, çıkan hatanın kaynağını bulamazsın. Yeni e-pin yazılımı kurulumunda ilk hedef büyümek değil, stoğun bütünlüğünü kanıtlamaktır. Bütünlük kanıtlandıktan sonra otomasyon, tedarikçi entegrasyonu ve kampanya kurgularını sırayla açarsın; özellik listesini bu sıraya göre okumak sana zaman kazandırır.
Stoğunu riske atmadan geçmek istiyorsan
Pinova, stok kodlarını şifreli tutan, satılmış ve bekleyen kodu net biçimde ayıran ve ürün bazında mutabakat raporu üretebilen bir satış yönetim yazılımıdır. Göçü tek gecede, kanıtlı biçimde bitirmen için tasarlandı.
Stok kodlarını Excel üzerinden taşımak güvenli mi?
Küçük partiler için kabul edilebilir, ama Excel uzun kodları bilimsel gösterime çevirebilir ve baştaki sıfırları silebilir. Taşımayı düz metin CSV ile, metin biçimi zorlanarak yapmalısın. Aktarımdan sonra rastgele kodların uzunluğunu kontrol et.
Eski panelin şifreleme anahtarına erişimim yoksa ne yapmalıyım?
Kodları çözemiyorsan o veri fiilen kayıptır. Tedarikçinden ilgili partinin listesini yeniden istemek ya da satılmamış stoğu iptal ettirip yeniden yüklemek en dürüst yoldur. Okunamayan satırları taşımak sadece sorunu erteler.
Göç sırasında siparişleri açık bırakabilir miyim?
Bırakmamalısın. Aktarım sırasında gelen bir sipariş, eski tarafta stok düşer ama yeni tarafa yansımaz. Kısa bir bakım modu, günler sürecek bir mutabakat kâbusundan çok daha ucuzdur.
Geçmiş satış kayıtlarını taşımak zorunda mıyım?
Yasal ve operasyonel olarak evet. Müşteri itirazları, tedarikçi iadeleri ve muhasebe kontrolleri için eski siparişlerin kodla ilişkisi durmalı. Bu kayıtlar satışa kapalı, yalnız okunur biçimde taşınır.
Stok göçü teknik bir iş gibi görünür ama aslında bir güven işidir: müşteriye sattığın kodun çalıştığından, tedarikçiye ödediğin paranın karşılığının kasada durduğundan emin olmakla ilgilidir. Eşleme tablosunu çıkar, şifreleme tarafını netleştir, satılmışı bekleyenden ayır, mutabakatı sayılarla kanıtla ve geri dönüş düğmeni hazır tut. Bu beş adımı uygulayan bir işletme göç gecesini sakin geçirir. Yeni panelin stok, teslim ve raporlama tarafını kendi ürünlerinle test etmek istersen canlı demo üzerinden gerçek bir stok yükleyip teslim akışını baştan sona deneyebilir, ardından fiyat sayfasından sana uygun paketi seçebilirsin.