Çoğu işletme sahibi sipariş geçmişini "nostaljik veri" sanır. Mantık şöyle kurulur: satış olmuş, kod teslim edilmiş, para tahsil edilmiş; eski kayıtları taşımaya ne gerek var? Yeni e-pin scripti kurulumunu temiz bir sayfayla açarsın, hayat devam eder. Bu görüş, göçten üç hafta sonra elindeki ilk garanti talebiyle çöker.
Çünkü sipariş geçmişi senin tek kanıt defterindir. Müşteri "aldığım kod çalışmadı" dediğinde hangi kodu, hangi saatte, hangi fiyattan teslim ettiğini göstermek zorundasın. Muhasebe dönem kapanışı istediğinde, ödeme sağlayıcısı mutabakat sorduğunda, bir bayi iskonto itirazı getirdiğinde başvuracağın yer o arşivdir. Bu yüzden geçmişi taşımak, dijital ürün satış yazılımı göçünün en az heyecan verici ama en kritik parçasıdır.
Sipariş durumları neden birebir eşlenemez?
Eski panellerde durum alanı genelde serbest metindir: "tamamlandı", "Tamamlandi", "teslim edildi", "ok", "iptal-iade". Yıllar içinde farklı kişiler farklı kelimeler yazmıştır. Yeni e-pin satış yazılımı ise sınırlı sayıda durum kodu bekler. Bu iki dünyayı birleştirmenin tek yolu, göçten önce bir eşleme sözlüğü çıkarmaktır.
Sözlüğü yaparken kaçınılması gereken şey her bilinmeyeni "tamamlandı" saymaktır. Bu, iptal edilmiş siparişleri ciroya, iade edilmiş kodları teslim edilmiş havuza yazar. Bilinmeyenler ayrı bir "incelenecek" kovasına alınır ve elle karara bağlanır; sayı genelde tahmin ettiğinden çok daha azdır.
Bir de kısmi durumlar vardır: bir siparişin üç kaleminden ikisi teslim, biri beklemede. Eski sistem bunu tek durumla ifade ettiyse bilgi zaten kayıptır. Doğru yaklaşım, kalem bazlı durumu göç sırasında sipariş satırlarından yeniden üretmektir.
| Eski durum metni | Yeni durum kodu | Ciroya yazılır mı? | Karar |
|---|---|---|---|
| tamamlandi / ok / teslim | completed | Evet | Otomatik |
| bekliyor / onay bekler | pending | Hayır | Otomatik |
| iptal / cancel | cancelled | Hayır | Otomatik |
| iade / geri odeme | refunded | Eksi kayıt | Otomatik |
| hata / basarisiz | failed | Hayır | Otomatik |
| boş veya bilinmeyen | review | Hayır | Elle |
Teslim edilmiş kodları taşımak yasal olarak zorunlu mu, riskli mi?
İkisi birlikte. Müşteriye teslim ettiğin kodu gösterebilmen gerekir; aksi halde garanti ve itiraz süreçlerinde savunmasız kalırsın. Ama teslim edilmiş kodları düz metin olarak sınırsız süre tutmak da gereksiz bir risktir; bir veri sızıntısı olduğunda elinde yıllara yayılmış kullanılabilir kod listesi bulunması istenmeyen bir tablodur.
Saha pratiği şudur: teslim edilmiş kodlar şifreli saklanır, panelde yalnızca maskeli görünür, tam değeri sadece yetkili bir eylemle ve iz kaydıyla açılır. Belirli bir yaşı geçmiş kodlar ise maskeli hâle kalıcı olarak dönüştürülür; kanıt için son karakterler ve teslim zamanı yeterlidir.
Göç sırasında en çok atlanan nokta, kodun teslim edildiği zaman damgası ve alıcı eşleşmesidir. Kod taşınır ama "kime, hangi siparişle" bağı kaybolur. O bağ olmadan arşivin hiçbir işe yaramaz; sadece yer kaplar.
Göç sonrası eski siparişe dönme sebepleri
- Kod çalışmıyor / garanti 38%
- Fatura ve muhasebe 28%
- Bayi iskonto itirazı 20%
- Ödeme mutabakatı 14%
Sipariş numaraları çakışırsa ne olur?
Bu, göçün en can sıkıcı ve en kolay önlenebilir hatasıdır. Eski sistem 1'den başlayıp 84.000'e gelmiştir. Yeni e-pin satış scripti de kurulumda 1'den başlar. Geçmişi taşırsan numaralar çakışır; ya aktarım hata verir ya da daha kötüsü, yeni siparişler eski numaraların üzerine yazar.
İki çözüm var. Birincisi, yeni sistemin sayacını eski en yüksek numaranın üstünden başlatmak; basittir ve süreklilik sağlar, müşteri fatura numarasıyla siparişini bulmaya devam eder. İkincisi, eski siparişlere "eski sistem" ön eki vermek; iki dünya net ayrışır ama müşteri kafası karışabilir.
Hangisini seçersen seç, kararı göçten önce ver ve yaz. Ortada bırakılmış numaralandırma, üç ay sonra muhasebe raporunda tekrarlı fatura numarası olarak geri döner ve o noktada düzeltmesi çok daha zordur.
Eski siparişin fiyatını bugünkü ürün fiyatından türetme. Tutar, vergi ve iskonto o günkü hâliyle donmuş olarak taşınmalı; aksi halde arşivin tamamı yanlış ciro üretir.
Arşivi canlı sistemin içine mi, yanına mı koymalısın?
Sipariş geçmişi hızla büyüyen bir veridir. Yüz binlerce satırı canlı tabloya doldurup her rapor sorgusunda taratmak, panelin yavaşlamasının bir numaralı sebebidir. Bu yüzden pratik yaklaşım iki katmanlıdır: son 12-24 ayın verisi canlı tabloda, öncesi arşiv tablosunda.
Arşiv, müşteri hesabından da erişilebilir olmalı ama ayrı sorgulanmalı. Müşteri "tüm siparişlerim" dediğinde arşivi de kapsayan bir görünüm alır; günlük ciro raporu ise sadece canlı katmanı tarar. Böylece hem kanıt defterin tam kalır, hem paneli yavaşlamaz.
Arşive taşırken indeksleri unutma. Arşiv tablosu "nadiren okunur" diye indekssiz bırakılırsa, bir garanti talebinde tek kaydı bulmak dakikalar sürer. Müşteri beklerken geçen o dakikalar, tasarruf ettiğini sandığın disk alanından çok daha pahalıdır.
Göçten sonra arşivin doğru olduğunu nasıl kanıtlarsın?
Kanıt, örneklemeyle değil toplamlarla başlar. Eski sistemde ay ay ciro, sipariş adedi, iade adedi ve teslim edilmiş kod sayısını çıkar. Aynı raporu yeni sistemde üret ve satır satır karşılaştır. Tek bir ayda fark varsa, muhtemelen o ayda durum eşlemesi kaçmıştır.
Sonra örneklem doğrulaması yap: her yıldan beş sipariş seç, müşteri hesabından bak. Kalemler doğru mu, tutar doğru mu, teslim edilen kod görünüyor mu, fatura bilgisi yerinde mi? Bu yirmi kayıt, yüz bin kaydın sağlığı hakkında şaşırtıcı derecede iyi sinyal verir.
Son adım, süreci yazmak. Hangi tablo nereye gitti, hangi durum neye eşlendi, hangi kayıtlar elle karara bağlandı? Bu tek sayfalık not, aylar sonra bir uyuşmazlık geldiğinde hem sana hem muhasebecine zaman kazandırır. Belgesiz göç, yarısı yapılmış göçtür.
| Doğrulama adımı | Yöntem | Kabul ölçütü | Önem |
|---|---|---|---|
| Aylık ciro karşılaştırması | Eski/yeni rapor | Fark 0,00 TL | Kritik |
| Sipariş adedi kontrolü | Toplam sayım | Birebir eşit | Kritik |
| Durum dağılımı kontrolü | Durum bazlı sayım | review kovası boşaltıldı | Kritik |
| Teslim kod bağlantısı | Örneklem 20 kayıt | Kod-sipariş bağı tam | Kritik |
| Sipariş numarası sürekliliği | Sayaç kontrolü | Çakışma yok | Kritik |
| Arşiv sorgu hızı | Tek kayıt arama | 1 saniye altı | Önemli |
| Göç notu belgesi | Yazılı özet | Tek sayfa hazır | Önemli |
Arşivini kaybetmeden yeni panele geç
Pinova, sipariş geçmişini kalem bazlı durum kodlarıyla, şifreli teslim arşiviyle ve donmuş tutar mantığıyla devralacak şekilde kurulur. Sipariş ve arşiv modülünü incele,
Eski siparişleri taşımak yerine sadece PDF arşiv tutsam olur mu?
Kısıtlı bir çözüm. Yasal kanıt için iş görebilir ama müşteri kendi geçmişini panelde göremez, destek ekibi arama yapamaz ve raporlama kopar.
Teslim edilmiş kodları ne kadar süre saklamalıyım?
Garanti ve itiraz süreleriniz boyunca tam, sonrasında maskeli saklamak dengeli bir yaklaşımdır. Kritik olan kodun siparişle ve zaman damgasıyla bağının korunmasıdır.
Sipariş numaraları çakışırsa sonradan düzeltebilir miyim?
Düzeltilebilir ama zahmetlidir; fatura, mutabakat ve destek kayıtları etkilenir. Doğru yol, yeni sistemin sayacını göç öncesi en yüksek numaranın üstünden başlatmaktır.
Arşiv paneli yavaşlatır mı?
İki katmanlı yapıyla yavaşlatmaz. Son 12-24 ay canlı tabloda, öncesi indeksli arşiv tablosunda tutulur ve günlük raporlar arşivi taramaz.
Sipariş geçmişi, panelinin en sessiz ama en değerli varlığıdır; onu doğru devrettiğinde göç bir risk değil, yıllardır birikmiş kayıtların ilk kez düzgün raporlandığı bir temizlik fırsatına dönüşür. Eşleme kararlarını vermeden önce yeni sistemde bir siparişin kalem, durum ve teslim arşivi görünümünü incelemen işini kolaylaştırır: canlı demo üzerinden örnek bir sipariş açıp hangi alanların hangi veriyi beklediğini not al, sonra eski tablolarını bu listeye göre hazırla.