Bir bayin arayıp "dün bu ürün 240 liraydı, bugün 265 olmuş, ne oldu?" dediğinde ne yapıyorsun? Çoğu satıcının cevabı aynı: paneli açıp güncel fiyata bakmak, sonra hafızayı zorlamak. Dünkü fiyatın ne olduğunu sistem sana söylemiyorsa, tartışma bir veri meselesi olmaktan çıkıp inanç meselesine dönüşür. Ve bu tartışmayı genellikle sen kaybedersin, çünkü karşı taraf ekran görüntüsü almıştır, sen almamışsındır.
İnsanların büyük kısmı fiyat geçmişini bir muhasebe lüksü sanır. Aslında bu, işletmenin hafızasıdır. Fiyatın ne zaman, kim tarafından, hangi değerden hangi değere çekildiğini tutmayan bir e-pin satış sistemi, geçmişi sürekli silinen bir kasa gibidir; bugünü gösterir ama dün ne olduğunu asla açıklayamaz. Bu yazıda fiyat log mimarisinin nasıl kurulduğunu, hangi alanların tutulması gerektiğini ve bu kaydın seni tam olarak hangi kavgalardan kurtardığını anlatacağım.
Fiyat geçmişi tutmamak tam olarak neye mal oluyor?
Kaybın ilk kalemi zaman. Bir fiyat itirazını çözmek için tedarikçi yazışmalarını, ekip sohbetlerini ve eski siparişleri tarayarak geçirdiğin süre, ayda birkaç saati kolayca bulur. İkinci kalem güven. Bayiye "öyle bir fiyat hiç olmadı" demek zorunda kaldığında, haklı olsan bile ilişki zedelenir; çünkü iddianı destekleyen tek şey senin sözündür.
Üçüncü ve en pahalı kalem ise görünmez: öğrenememek. Fiyatlarını ne zaman yükselttiğini bilmiyorsan, o yükselişin satış adedine ne yaptığını da ölçemezsin. Hangi zammı piyasa yuttu, hangisinde siparişler durdu, hangi indirim gerçekten hacim getirdi? Bu soruların hepsinin cevabı, fiyat değişim tarihçesiyle satış verisinin kesişiminde durur. Kayıt yoksa kesişim de yoktur ve fiyatlandırma kalıcı olarak sezgiyle yapılır. Ciddi bir e-pin satış scripti bu yüzden fiyat tablosunu değil, fiyat hareketlerini saklar.
Bir fiyat kaydında hangi alanlar mutlaka bulunmalı?
Sadece eski ve yeni fiyatı yazmak yetmez; o kayıt bir yıl sonra okunduğunda tek başına anlaşılabilmelidir. Yani kaydın içinde kim, ne zaman, hangi kanaldan ve neden sorularının cevabı olmalı. Özellikle "neden" alanı çoğu kurulumda atlanır ve en çok aranan alan odur. Tedarikçi zammı mı, rakip takibi mi, kampanya başlangıcı mı, kur güncellemesi mi; bunu değişikliği yapan kişi o an tek cümleyle yazarsa, altı ay sonra kimse tahmin yürütmek zorunda kalmaz.
Bir diğer kritik alan değişikliğin kaynağıdır. Fiyat elle mi girildi, toplu güncelleme aracıyla mı değişti, tedarikçi entegrasyonu mu otomatik çekti? Kaynağı ayırmadığında otomasyonun yaptığı hatayı insana, insanın yaptığı hatayı otomasyona yükleme riski doğar. Aşağıdaki tablo, sağlam bir dijital ürün satış yazılımı kurulumunda tutulması gereken minimum alan setini gösteriyor.
| Alan | Örnek Değer | Ne İşe Yarar |
|---|---|---|
| Zaman damgası | 2026-09-11 14:32:07 | Sipariş saatiyle eşleştirme |
| Kullanıcı | operasyon_2 | Sorumluluk ve yetki denetimi |
| Ürün ve varyant | Oyun kodu 100 birim | Doğru kalemi ayırt etme |
| Eski / yeni fiyat | 240 TL / 265 TL | Değişim yönü ve oranı |
| Fiyat tipi | Liste / bayi kademe 2 | Hangi kitleyi etkilediği |
| Kaynak | Toplu güncelleme | İnsan mı otomasyon mu |
| Gerekçe notu | Tedarikçi zammı | Geriye dönük yorumlama |
| IP ve oturum | Panel oturumu | Yetkisiz erişim incelemesi |
Kayıt, bayi itirazını nasıl otuz saniyede kapatıyor?
Senaryo şöyle işliyor. Bayi belirli bir siparişin fiyatına itiraz ediyor. Sen sipariş numarasını açıyorsun, siparişin oluşturulma saatini görüyorsun ve o saatte geçerli olan fiyat kaydını sistemden çekiyorsun. Karşına çıkan satır şunu söylüyor: fiyat o gün saat 14:32'de 240'tan 265'e çıkarılmış, sipariş 15:10'da oluşmuş. Yani bayi gerçekten eski fiyatı görmüş ama alışverişi zam sonrasında yapmış.
Bu noktada tartışma biter, çünkü ortada yorum değil kayıt vardır. Üstelik bu kayıt seni haksız çıkarabilir de; bazen gerçekten sistem yanlış saatte zam uygulamıştır ve bunu görmek, bayine dürüstçe telafi sunmanı sağlar. Her iki durumda da kazanan sensin. Epin yazılım tarafında aradığın yetenek, fiyat kaydını sipariş kaydıyla aynı ekranda eşleştirebilmektir; iki ayrı raporu elle karşılaştırmak zorunda kalıyorsan sistem işini yarım yapıyor demektir.
Fiyat değişikliklerinin tetikleyici dağılımı
- Tedarikçi maliyet güncellemesi 45%
- Rakip fiyat takibi 25%
- Kampanya başlangıç ve bitişi 20%
- Hatalı giriş düzeltmesi 10%
Ekip büyüdükçe yetki denetimi neden zorunlu hale geliyor?
Tek kişilik bir işletmede fiyatı kimin değiştirdiği sorusu anlamsızdır. İkinci kişi işe girdiği anda anlam kazanır, üçüncü kişide ise kritik hale gelir. Panelde fiyat yetkisi olan herkes, farkında olmadan senin kâr marjını yeniden tanımlayabilecek güce sahiptir. Bir rakamın sonuna fazladan sıfır eklemek ya da yüzde işaretini yanlış kutuya yazmak, dakikalar içinde yüzlerce siparişi etkiler.
Kayıt tutmak burada iki işlevi birden görür. Birincisi düzeltmeyi hızlandırır: hatalı değişikliğin saatini bildiğinde, o saatten sonraki siparişleri tek sorguyla listeler ve telafiyi hedefli yaparsın. İkincisi caydırıcıdır; her değişikliğin isimle kaydedildiğini bilen bir ekip, fiyat kutusuna girmeden önce iki kez düşünür. İyi bir e-pin satış yazılımı bu kaydı kullanıcıdan gizlemez, aksine değişiklik ekranının hemen altında son hareketleri gösterir; şeffaflık en ucuz kontrol mekanizmasıdır.
Fiyat geçmişi satırları salt yazılır olmalı; düzeltme gerektiğinde eski satır silinmez, üzerine yeni bir hareket eklenir. Değiştirilebilen bir log, hiç olmayan logdan daha tehlikelidir çünkü sana yanlış bir güven verir.
Geçmiş veriyi fiyatlandırma stratejisine nasıl çeviriyorsun?
Kaydın asıl değeri savunmada değil, saldırıda ortaya çıkar. Elinde altı aylık fiyat hareketi ve aynı dönemin satış adetleri varsa, her ürün için basit ama çok güçlü bir soruyu cevaplayabilirsin: fiyatı yükselttiğimde adet ne kadar düştü? Bazı ürünlerde yüzde on zam adedi hiç etkilemez, bazılarında yüzde üçlük bir artış siparişleri yarıya indirir. Bu ayrımı bilen satıcı, zammı doğru kalemde yapar.
İkinci kullanım alanı kampanya değerlendirmesidir. İndirimin başladığı ve bittiği saatler kayıtlıysa, kampanya penceresindeki satış yoğunluğunu normal dönemle dürüstçe karşılaştırabilirsin. Çoğu satıcı kampanyayı "iyi gitti" diye hatırlar ama gerçek karşılaştırma çoğu zaman daha az parlak bir tablo gösterir. Bu tür bir analiz, e-pin scripti üzerinde ek bir modül gerektirmez; yalnızca doğru alanların baştan kaydedilmiş olmasını gerektirir. Kaydı sonradan üretemezsin, bu yüzden bugün başlamalısın.
Kurulumda hangi maddeleri tek tek geçmelisin?
Fiyat geçmişini devreye almak teknik olarak ağır bir iş değil ama eksik kurulan bir log, güvendiğin ama işe yaramayan bir sigortaya benzer. Aşağıdaki listeyi kurulum sırasında elinin altında tut; her maddenin karşısındaki durumu kendi panelinde doğrula.
| Kontrol | Doğrulama Yöntemi | Öncelik |
|---|---|---|
| Elle yapılan fiyat değişikliği kaydediliyor mu | Test ürününde fiyat değiştir, logu gör | Yüksek |
| Toplu güncelleme her satır için kayıt üretiyor mu | On ürünlük toplu işlem dene | Yüksek |
| Bayi kademe fiyatları ayrı loglanıyor mu | Kademe 2 fiyatını değiştir | Yüksek |
| Gerekçe alanı zorunlu mu | Boş bırakıp kaydetmeyi dene | Orta |
| Sipariş detayından fiyat geçmişine geçiş var mı | Eski bir siparişi aç | Orta |
| Kayıtlar en az 12 ay saklanıyor mu | Arşiv politikasını kontrol et | Yüksek |
| Log silme yetkisi kısıtlı mı | Operasyon kullanıcısıyla dene | Yüksek |
| Dışa aktarma mümkün mü | CSV çıktısı al | Düşük |
İşletmenin hafızasını yazılıma emanet et
Pinova, fiyat hareketlerini kullanıcı, kaynak ve gerekçe kırılımıyla salt yazılır biçimde saklar ve sipariş detayından tek tıkla ilgili kayda geçmeni sağlar.
Fiyat kayıtları veritabanını çok şişirir mi?
Hayır. Bir fiyat hareketi satırı birkaç yüz bayt yer kaplar. Bin ürünlük bir katalogda ayda beş bin hareket olsa bile yıllık boyut, tek bir ürün görselinin altında kalır. Şişme endişesi neredeyse her zaman yersizdir.
Geçmişe dönük kayıt oluşturabilir miyim?
Sistem devreye alınmadan önceki değişiklikler için gerçek kayıt üretilemez. Yapabileceğin en doğru şey, bugünkü fiyatları başlangıç noktası olarak işaretlemek ve bu tarihten sonrasını eksiksiz tutmaktır.
Otomatik tedarikçi güncellemeleri de loglanmalı mı?
Kesinlikle. Aksi halde en sık fiyat değiştiren kaynak görünmez kalır. Otomasyon kayıtlarını ayrı bir kaynak etiketiyle tutarsan, insan kaynaklı değişiklikleri de filtreleyerek inceleyebilirsin.
Bayilerim fiyat geçmişini görebilmeli mi?
Genelde hayır. Ancak itiraz durumunda ilgili tek satırı paylaşmak güven inşa eder. Panelde bayilere açık bir geçmiş ekranı yerine, destek talebine eklenebilen bir kayıt özeti daha sağlıklı bir yaklaşımdır.
Fiyat geçmişi, kurarken kimsenin heyecanlanmadığı ama ihtiyaç duyduğun ilk gün paha biçilmez hale gelen bir özelliktir. Hangi alanların hazır geldiğini görmek için özellik listesine göz atabilir, ölçeğine uygun paketi fiyat bölümünden seçebilir ve bir fiyat değişikliğinin kayda nasıl düştüğünü canlı demo içinde test ürünü üzerinde birkaç dakikada deneyebilirsin.

