XML üzerinden binlerce ürün yönetildiğinde tedarikçinin fiyat değişikliklerini tek tek manuel kontrol etmek pratik değildir.

Otomasyon bu nedenle önemli bir avantaj sağlar.

Ancak otomasyonun şu mantıkla çalışması:

yeni fiyat geldi → eski fiyatı sil → yeni fiyatı yayınla

her durumda yeterince güvenli olmayabilir.

Çünkü fiyatın düşmesi iki farklı anlama gelebilir.

Birincisi gerçekten tedarikçinin yaptığı normal bir fiyat indirimi olabilir.

İkincisi ise:

• yanlış XML alanı,
• eksik rakam,
• KDV farklılığı,
• hatalı ürün eşleşmesi,
• yanlış varyant,
• veri aktarım problemi,
• fiyatlandırma kuralındaki hata

nedeniyle oluşmuş olağan dışı bir değer olabilir.

Ulu İthalat'ın mevcut fiyat ve stok güncelleme rehberinde de XML fiyat yönetiminde çok düşük veya çok yüksek fiyatların engellenmesi, minimum satış fiyatı belirlenmesi ve anormal fiyat değişikliklerinin manuel kontrol edilmesi öneriliyor.

Bu nedenle XML fiyat düşüş kontrolü, fiyatı otomatik olarak engellemek değil:

normal değişiklik ile şüpheli değişikliği birbirinden ayırmak

olarak düşünülmelidir.

XML Fiyat Düşüşü Neden Ayrı Kontrol Edilmeli?

Fiyat artışı fark edilmediğinde satıcı eski fiyatla satış yapıp kâr kaybedebilir.

Fakat yanlış bir fiyat düşüşünün otomatik olarak yayınlanması daha farklı bir risk oluşturabilir.

Örneğin sistemde:

1.250 → 1.180

şeklindeki değişiklik normal olabilir.

Ancak:

1.250 → 125

şeklindeki değişiklik ayrıca doğrulanması gereken bir durumdur.

Burada amaç rakamlara göre sabit bir evrensel kural oluşturmak değildir.

Önemli olan işletmenin kendi ürün ve maliyet yapısına göre anormal değişiklikleri yakalayabilecek kontrol noktaları oluşturmasıdır.

1. Önce Eski Fiyatı Saklayın

Yeni fiyat geldiğinde eski değer tamamen siliniyorsa fiyat düşüşünü doğru değerlendirmek zorlaşır.

En azından kontrol sırasında:

eski alış fiyatı

ve

yeni alış fiyatı

birlikte görülebilmelidir.

Ulu İthalat'ın veri güncelleme çakışmaları rehberi de değişiklik kayıtlarında ürün/SKU, eski değer, yeni değer, güncelleme kaynağı ve işlem zamanının tutulmasını öneriyor.

Fiyat düşüş kontrolünün temelinde de bu karşılaştırma bulunur.

2. Değişikliği Ürün Adıyla Değil SKU ile Takip Edin

Ürün adı değişebilir.

İki farklı ürün birbirine çok benzeyen isimlere sahip olabilir.

Bu nedenle fiyat değişikliğini mümkün olduğunca:

SKU / ürün kodu

üzerinden takip etmek daha güvenlidir.

Gerekirse barkod da ikinci doğrulama alanı olarak kullanılabilir.

Amaç eski fiyatla yeni fiyatın gerçekten aynı ürüne ait olduğundan emin olmaktır.

3. Eski Fiyat ile Yeni Fiyat Arasındaki Mutlak Farkı Hesaplayın

Basit ilk kontrol:

eski fiyat − yeni fiyat = düşüş tutarı

olabilir.

Örneğin:

eski fiyat 800,

yeni fiyat 760 ise

40 birimlik düşüş vardır.

Mutlak tutar özellikle yüksek fiyatlı ürünlerde anlamlı olabilir.

Ancak tek başına yeterli değildir.

4. Yüzdesel Düşüşü de Hesaplayın

Aynı 100 birimlik fiyat değişikliği:

200 TL'lik üründe

ve

5.000 TL'lik üründe

aynı anlamı taşımaz.

Bu nedenle ikinci kontrol:

(eski fiyat − yeni fiyat) / eski fiyat × 100

şeklinde yüzdesel değişim üzerinden yapılabilir.

Örneğin sistem yalnızca “fiyat düştü” değil:

“fiyat alışılmış aralığın dışında düştü”

durumunu yakalamalıdır.

5. Tek Bir Evrensel Düşüş Yüzdesi Kullanmayın

Bütün ürünler için:

“%20 düşerse hata kabul et.”

gibi tek bir kural fazla kaba olabilir.

Çünkü bazı kategorilerde kampanyalar veya fiyat değişimleri daha hareketli olabilir.

Bazı ürünlerde ise küçük değişiklik bile önemli olabilir.

Bu nedenle kontrol sınırları:

• kategori,
• fiyat seviyesi,
• ürün tipi,
• geçmiş fiyat hareketleri

gibi özelliklere göre farklılaştırılabilir.

6. Yüzde ve Tutar Kontrolünü Birlikte Kullanabilirsiniz

Yalnızca yüzde kullandığınızda düşük fiyatlı ürünlerde küçük tutarlar gereksiz uyarı oluşturabilir.

Yalnızca TL farkı kullandığınızda ise pahalı ürünlerde ciddi yüzdesel değişiklik gözden kaçabilir.

Bu nedenle sistem örneğin:

oran kontrolü + mutlak fark kontrolü

mantığını birlikte kullanabilir.

Ama kullanılacak eşiklerin işletmenin gerçek verilerine göre belirlenmesi gerekir.

7. Alış Fiyatı ile Satış Fiyatını Ayırın

XML'den gelen fiyatın ne olduğu açık olmalıdır.

Bu değer:

• alış fiyatı,
• bayi fiyatı,
• önerilen satış fiyatı

olabilir.

Ulu İthalat'ın mevcut fiyat ve stok rehberi de XML'deki fiyat alanının farklı tedarikçilerde farklı anlamlara gelebileceğini belirtiyor.

Bu nedenle fiyat düşüş kontrolü kurulmadan önce:

“Ben hangi fiyat alanını kontrol ediyorum?”

sorusu cevaplanmalıdır.

8. Tedarikçi Alış Fiyatını Doğrudan Satış Fiyatı Olarak Yayınlamayın

Daha kontrollü sistem:

XML alış fiyatı

↓

doğrulama

↓

işletmenin fiyatlandırma kuralı

↓

hesaplanan satış fiyatı

↓

satış kanalı

şeklinde ilerleyebilir.

Veri güncelleme çakışmaları rehberinde de tedarikçi alış fiyatı ile mağaza satış fiyatının ayrı kaynak ve kurallarla yönetilebileceği özellikle belirtiliyor.

9. Minimum Maliyet Sınırı Oluşturun

Bir ürünün hesaplanan satış fiyatı:

• alış maliyeti,
• komisyon,
• kargo,
• paketleme,
• diğer zorunlu giderler

nedeniyle belirli bir seviyenin altında zarar oluşturabilir.

Bu nedenle fiyat düşüş kontrolü yalnızca:

“eski fiyata göre ne kadar düştü?”

sorusunu değil,

“yeni fiyatla satış yapıldığında maliyet korunuyor mu?”

sorusunu da cevaplamalıdır.

10. Minimum Satış Fiyatı Kontrolü Ekleyin

İşletme fiyatlandırma sisteminiz destekliyorsa ürün için hesaplanan minimum satış seviyesi belirlenebilir.

Yeni satış fiyatı bu seviyenin altına düşüyorsa:

otomatik yayınlama

yerine

inceleme

durumuna gönderilebilir.

Ulu İthalat'ın mevcut XML fiyat rehberinde de minimum satış fiyatı limiti fiyat hatalarını azaltabilecek kontroller arasında gösteriliyor.

11. Sıfır Fiyatı Normal Bir İndirim Olarak İşlemeyin

XML'de fiyat alanı:

0

veya boş gelebilir.

Bu durumda:

“ürün ücretsiz oldu”

sonucu çıkarılmamalıdır.

Veri güncelleme çakışmaları rehberinde sıfır fiyatın otomatik işlenmemesi örnek bir doğrulama kuralı olarak yer alıyor.

Sıfır veya geçersiz değer:

veri doğrulama hatası

olarak ele alınabilir.

12. Çok Küçük Fiyatları Ayrı Kontrole Alın

Ürün normalde yüzlerce veya binlerce lira seviyesinde ise yeni fiyatın birkaç lira görünmesi özellikle incelenmelidir.

Bu sorun:

• ondalık ayracı,
• yanlış alan,
• eksik basamak,
• XML parse problemi

gibi nedenlerden kaynaklanabilir.

Bu nedenle minimum fiyat kontrolü kategori veya ürün seviyesinde de tanımlanabilir.

13. KDV Dahil ve Hariç Fiyat Değişimini Ayırt Edin

Fiyatın yaklaşık belirli bir oranda düşmesi her zaman kampanya anlamına gelmeyebilir.

Tedarikçi daha önce:

KDV dahil

fiyat gönderirken yeni veri:

KDV hariç

gelmeye başlamış olabilir.

Mevcut Ulu İthalat fiyat rehberinde de fiyat alanının KDV dahil veya hariç olduğunun doğrulanması gerektiği belirtiliyor.

Bu nedenle önemli fiyat değişikliğinde önce alanın anlamının değişip değişmediği kontrol edilmelidir.

14. XML Alan Değişikliğini Kontrol Edin

Tedarikçi XML yapısını değiştirebilir.

Örneğin daha önce kullandığınız:

bayi_fiyati

alanı yerine başka bir fiyat alanı eklenmiş olabilir.

Entegrasyon yanlış alanı okumaya devam ederse fiyat değişiklikleri gerçek ticari değişiklikleri yansıtmayabilir.

Bu nedenle olağan dışı toplu düşüşlerde yalnızca ürünleri değil XML alan yapısını da kontrol etmek gerekir.

15. Tek Üründeki Düşüş ile Toplu Düşüşü Ayırın

Bir SKU'nun fiyatı düşmüşse ürün bazlı kampanya olabilir.

Fakat birkaç dakika içerisinde:

3.000 ürünün büyük bölümünün

benzer oranda fiyatı düşmüşse sistemsel bir değişiklik ihtimali daha yüksektir.

Bu nedenle kontrol mekanizması yalnızca ürün bazında değil toplu değişiklik davranışını da izleyebilir.

16. Değişen Ürün Sayısını Takip Edin

Her senkronizasyonda basit bir istatistik tutulabilir:

kaç ürün arttı?

kaç ürün düştü?

kaç ürün değişmedi?

kaç ürün kontrol bekliyor?

Normalde 20–30 ürün değişirken bir gün 4.000 ürünün fiyatının düşmesi ayrıca incelenmesi gereken bir sinyaldir.

17. Aynı Oranda Düşen Çok Sayıda Ürünü İşaretleyin

Binlerce ürün aynı anda örneğin benzer oranda düşüyorsa:

• vergi yapısı,
• fiyat alanı,
• fiyat çarpanı,
• iskonto kuralı,
• entegrasyon hesaplaması

değişmiş olabilir.

Bu nedenle yalnızca tek SKU'nun geçmişini incelemek yeterli olmayabilir.

Katalog düzeyindeki desen de önemlidir.

18. Kategori Bazında Davranışı Karşılaştırın

Sadece elektronik kategorisindeki ürünlerin fiyatı düşmüş olabilir.

Bu durumda genel XML hatası yerine:

• kategori kampanyası,
• belirli tedarikçi grubu,
• kategoriye özel fiyatlandırma kuralı

söz konusu olabilir.

Bu nedenle uyarı:

tüm katalog

yerine gerekirse:

kategori

seviyesinde değerlendirilebilir.

19. SKU Eşleşmesini Tekrar Doğrulayın

Fiyat düşüşünün sebebi bazen fiyatın yanlış olması değil ürünün yanlış eşleşmesidir.

Örneğin:

pahalı bir ürünün SKU'su

ucuz başka bir ürünün fiyatıyla eşleşmiş olabilir.

Bu nedenle büyük fiyat değişikliğinde:

SKU → barkod → ürün adı → varyant

kontrol zinciri kullanılabilir.

20. Varyant Fiyatlarını Ayrı İnceleyin

Bir ürünün farklı:

• boyutu,
• rengi,
• modeli,
• paketi

farklı fiyatlara sahip olabilir.

Yanlış varyant eşleşmesi sonucunda pahalı varyant daha ucuz varyantın fiyatını alabilir.

Bu nedenle fiyat düşüş kontrolü mümkünse ana ürün kadar varyant kimliği üzerinde de çalışmalıdır.

21. Kampanyalı Ürünleri İstisna Listesine Alabilirsiniz

Gerçek kampanya dönemlerinde normalden büyük düşüşler olabilir.

Böyle durumlarda bütün kampanyalı ürünlerin sürekli alarma düşmesi sistemi kullanışsız hale getirir.

Bu nedenle kontrollü bir:

geçici istisna listesi

oluşturulabilir.

Ancak istisnanın:

• hangi SKU'lar için,
• hangi tarihler arasında,
• hangi nedenle

verildiği kayıt altında tutulmalıdır.

22. İstisnaları Süresiz Açık Bırakmayın

Bir ürün kampanya nedeniyle kontrol dışında bırakılmış olabilir.

Kampanya bittikten sonra ürün hâlâ istisnadaysa gelecekteki gerçek hatalar gözden kaçabilir.

Bu nedenle istisnalara:

başlangıç + bitiş zamanı

tanımlamak daha güvenli olabilir.

23. Anormal Düşüşte Ürünü Hemen Silmek Yerine Beklemeye Alın

Şüpheli fiyat görüldüğünde ürünün tamamen kaldırılması her durumda gerekli değildir.

Sisteme göre ürün:

fiyat güncellemesi bekliyor

veya

manuel kontrol bekliyor

durumuna alınabilir.

Amaç doğru ticari değişikliği engellemeden yanlış fiyatın müşteriye ulaşmasını önlemektir.

24. Manuel Onay Sadece Gerçekten Şüpheli Ürünlerde Kullanılmalı

Bütün fiyat değişikliklerini manuel onaya göndermek otomasyonun avantajını ortadan kaldırır.

Daha iyi yaklaşım:

normal değişiklik → otomatik

sınırdaki değişiklik → kayıt + izleme

anormal değişiklik → manuel inceleme

şeklinde olabilir.

Böylece ekip yalnızca gerçekten riskli fiyatlara odaklanır.

25. Onay Ekranında Eski ve Yeni Fiyatı Birlikte Gösterin

Manuel kontrol yapan kişinin yalnızca:

“Yeni fiyat 375.”

bilgisini görmesi yeterli değildir.

Daha kullanışlı ekran:

SKU

eski fiyat

yeni fiyat

fark

yüzdesel değişim

kaynak

son güncelleme zamanı

gibi bilgileri birlikte gösterebilir.

Bu sayede karar daha hızlı verilebilir.

26. Kaynak XML'deki Fiyatı Ayrı Gösterin

Şüpheli fiyatın:

tedarikçi XML'inde gerçekten bulunup bulunmadığı

önemlidir.

Eğer XML'de doğru fiyat mevcut ancak mağazada yanlış fiyat oluşuyorsa sorun entegrasyon veya fiyatlandırma kuralında olabilir.

Veri çakışmaları rehberimiz de problem araştırmasında önce kaynak XML, sonra entegrasyon tarafından alınan veri ve mağazada oluşan son değerin karşılaştırılmasını öneriyor.

27. Fiyatlandırma Kuralını Değişiklik Kaydıyla Birlikte Tutun

Kaynak XML doğru olabilir.

Ancak:

yanlış çarpan

yanlış marj

veya

yanlış formül

satış fiyatını düşürebilir.

Ulu İthalat'ın veri yedekleme rehberi de yalnızca verinin değil, fiyatlandırma kuralları ve entegrasyon eşleştirmelerinin de kayıt altında tutulmasının önemli olduğunu belirtiyor.

28. Yeni Fiyat Kuralını Önce Küçük Ürün Grubunda Test Edin

Yeni kontrol sistemi doğrudan bütün kataloga uygulanmamalıdır.

Örneğin önce:

20–50 SKU

üzerinde denenebilir.

Test sırasında:

normal düşüş geçiyor mu?

aşırı düşüş duruyor mu?

kampanya ürünü yanlış alarm veriyor mu?

sıfır fiyat yakalanıyor mu?

varyantlar doğru eşleşiyor mu?

kontrol edilebilir.

Ulu İthalat'ın veri çakışmaları rehberi de yeni senkronizasyon kurallarının önce sınırlı ürün grubunda denenmesini öneriyor.

29. Kritik Değişikliklerden Önce Geri Dönüş Noktası Oluşturun

Yeni fiyatlandırma kuralı bütün katalogda çalıştırılacaksa güncellemeden önce mevcut fiyatların yedeği alınabilir.

Ulu İthalat'ın mevcut veri yedekleme rehberi, özellikle toplu fiyat güncellemelerinden önce geri dönüş noktası oluşturulmasını öneriyor.

Böylece hatalı bir kural binlerce ürüne uygulanırsa eski fiyatlar tamamen kaybolmaz.

30. Yalnızca XML Dosyasını Yedeklemek Yeterli Olmayabilir

Kaynak XML'de alış fiyatı bulunabilir.

Ancak mağazada:

alış fiyatı + fiyatlandırma kuralı = satış fiyatı

oluşuyorsa yalnızca XML yedeği eski satış fiyatını göstermez.

Mevcut Ulu İthalat veri yedekleme rehberi de kaynak veri yedeği ile işlenmiş mağaza verisinin ayrı katmanlar olduğunu vurguluyor.

Bu nedenle fiyat kontrol sisteminde mümkünse iki değerin geçmişi ayrı tutulmalıdır.

31. Fiyat Değişikliğine Zaman Damgası Ekleyin

Bir fiyatın ne zaman değiştiğini bilmek hata araştırmasını kolaylaştırır.

Örneğin:

13.00 XML alındı

13.03 fiyat hesaplandı

13.05 mağazaya yazıldı

13.08 kontrol uyarısı oluştu

gibi bir kayıt problem kaynağını daraltabilir.

32. Aynı Alanı Birden Fazla Sistem Güncelliyorsa Kaynak Önceliği Belirleyin

Fiyat aynı anda:

• XML,
• ERP,
• entegrasyon sistemi,
• mağaza paneli,
• pazaryeri fiyat kuralı

tarafından değiştiriliyorsa kontrol mekanizması hangi değerin esas olduğunu bilmelidir.

Ulu İthalat'ın veri güncelleme çakışmaları rehberi de aynı fiyat alanının birden fazla görev tarafından değiştirilmesinin çakışma riskini artırdığını açıkça belirtiyor.

33. Eski Verinin Yeni Fiyatı Tekrar Ezmesini Engelleyin

Doğru fiyat düşüşü onaylanmış olabilir.

Fakat birkaç dakika sonra eski bir işlem yeniden çalışıp farklı fiyatı tekrar mağazaya yazabilir.

Bu nedenle sistemde mümkünse:

• işlem zamanı,
• veri sürümü,
• son başarılı güncelleme

gibi bilgiler takip edilmelidir.

Daha eski verinin yeni verinin üzerine yazılmaması mevcut veri çakışması rehberimizin temel kontrollerinden biridir.

34. Kontrol Mekanizmasının Kendisi İçin Kayıt Tutun

Sadece fiyat değişiklikleri değil, kontrol sisteminin verdiği karar da kaydedilebilir.

Örneğin:

SKU → düşüş algılandı → eşik aşıldı → manuel kontrole gönderildi → onaylandı

veya

SKU → düşüş algılandı → maliyet sınırının altına indi → yayınlanmadı

şeklinde kayıt tutulabilir.

Bu yapı ileride yanlış alarm oranını analiz etmeyi sağlar.

35. Yanlış Alarm Oranını Takip Edin

Sistem her gün yüzlerce normal değişikliği şüpheli gösteriyorsa ekip bir süre sonra uyarıları dikkate almamaya başlayabilir.

Bu nedenle kontrol mekanizmasının kendisi de geliştirilmelidir.

Örneğin:

100 uyarının 95'i normal fiyat değişikliği çıktıysa

eşiklerin fazla hassas olup olmadığı değerlendirilebilir.

36. Geçmiş Fiyat Hareketlerini Referans Olarak Kullanabilirsiniz

Bazı ürünlerin fiyatı düzenli hareket eder.

Bazıları ise aylarca sabit kalır.

Yeterli veri varsa kontrol mekanizması:

ürünün kendi geçmiş fiyat davranışını

da değerlendirebilir.

Böylece normalde sık değişen ürün ile neredeyse hiç değişmeyen ürün aynı kurala bağlı kalmaz.

37. Yeni Eklenen Ürünlere Ayrı Kural Uygulayın

Yeni ürünün eski fiyat geçmişi bulunmayabilir.

Bu nedenle yeni SKU'da:

“eski fiyata göre düşüş”

kontrolü kullanılamaz.

Bunun yerine:

• geçerli fiyat,
• minimum maliyet,
• fiyat alanı,
• kategori,
• tedarikçi verisi

üzerinden ilk doğrulama yapılabilir.

38. Fiyatı Düşen Ürünü Otomatik Kampanyalı Ürün Saymayın

Tedarikçinin alış fiyatını düşürmesi satıcının satış fiyatını otomatik olarak aynı oranda düşürmek zorunda olduğu anlamına gelmez.

İşletme kendi:

• marj,
• komisyon,
• kargo,
• rekabet

politikasına göre yeni satış fiyatını hesaplayabilir.

Bu ayrım özellikle XML alış fiyatıyla mağaza satış fiyatının farklı kaynaklar olarak yönetilmesi açısından önemlidir.

39. Tedarikçiye Olağan Dışı Fiyat Değişikliklerini Sorabilin

Kontrol sistemi şüpheli değişiklik bulduğunda yalnızca teknik ekrana bakmak yeterli olmayabilir.

Örneğin tedarikçiye:

Bu fiyat değişikliği bilinçli mi?

Kampanya mı?

XML alanında değişiklik yapıldı mı?

Fiyat KDV dahil/hariç yapıya mı geçti?

sorulabilir.

Tedarikçi seçimi rehberimiz de fiyat değişikliklerinin XML'e zamanında ve doğru biçimde yansımasının önemli olduğunu belirtiyor.

40. Kontrol Mekanizmasını Fiyat Artışı Kontrolünden Ayırın

Fiyat artışı ve fiyat düşüşü aynı problemi yaratmaz.

Fiyat artışında temel risk:

eski satış fiyatının korunması nedeniyle zarar oluşması.

Fiyat düşüşünde temel risk:

yanlış veya aşırı düşük fiyatın müşteriye yansıması.

Bu nedenle iki yöndeki değişiklik için ayrı eşikler ve aksiyonlar kullanılabilir.

XML Fiyat Düşüş Kontrolü İçin Pratik Kontrol Sistemi

SKU

Eski ve yeni fiyat aynı ürüne mi ait?

Eski fiyat

Güncellemeden önceki değer kayıtlı mı?

Yeni fiyat

Kaynak XML'de gerçekten bu değer mi bulunuyor?

Mutlak fark

Kaç birim düşüş gerçekleşti?

Yüzdesel değişim

Eski fiyata göre düşüş oranı ne?

Minimum fiyat

Yeni değer izin verilen maliyet sınırının altında mı?

Sıfır/boş değer

Geçersiz fiyat ayrı yakalanıyor mu?

KDV

Fiyat alanının KDV yapısı değişmiş olabilir mi?

Alan eşleşmesi

Doğru XML fiyat alanı mı okunuyor?

Varyant

Doğru varyant fiyatı mı?

Toplu değişiklik

Aynı anda kaç SKU'nun fiyatı düştü?

Kategori

Değişiklik yalnızca belirli grupta mı?

İstisna

Ürün bilinen kampanya listesinde mi?

Maliyet

Yeni satış fiyatı gerçek giderleri karşılıyor mu?

Kaynak

Fiyatı hangi sistem değiştirdi?

Zaman

Değişiklik ne zaman gerçekleşti?

Onay

Olağan dışı düşüş manuel kontrol edildi mi?

Kayıt

Kararın sonucu daha sonra görülebiliyor mu?

Yedek

Hatalı toplu güncellemede eski fiyatlara dönülebiliyor mu?

XML Fiyat Düşüş Kontrol Mekanizması Nasıl Kurulabilir?

1. Ürünleri benzersiz SKU üzerinden takip edin.

2. Her güncellemeden önce eski alış ve satış fiyatını saklayın.

3. Yeni XML fiyatını ayrı alanda okuyun.

4. Eski-yeni fiyat arasındaki farkı hesaplayın.

5. Yüzdesel düşüşü hesaplayın.

6. Minimum geçerli fiyat kontrolü uygulayın.

7. Sıfır ve boş fiyatları doğrudan reddedin veya incelemeye alın.

8. Maliyet altına düşen satış fiyatlarını durdurun.

9. Aşırı düşüşler için kategoriye uygun eşikler oluşturun.

10. Aynı anda çok sayıda SKU değiştiğinde toplu uyarı üretin.

11. Varyant ve ürün eşleşmesini doğrulayın.

12. Kampanya ürünleri için süreli istisna sistemi oluşturun.

13. Şüpheli değişiklikleri manuel inceleme kuyruğuna gönderin.

14. İnceleme ekranında eski-yeni fiyat ve kaynağı birlikte gösterin.

15. Onaylanan fiyatı satış fiyatlandırma kuralından geçirin.

16. Sonucu mağaza veya pazaryerine aktarın.

17. Güncellemeden sonra birkaç SKU'yu tekrar doğrulayın.

18. Her değişikliğin zamanını ve sonucunu kayıt altına alın.

19. Kritik toplu fiyat işlemlerinden önce geri dönüş noktası oluşturun.

20. Yanlış alarm oranına göre eşikleri zaman içinde iyileştirin.

Sık Sorulan Sorular

XML'de fiyat düşmesi her zaman hata mıdır?

Hayır. Tedarikçinin gerçek fiyat indirimi, kampanya veya maliyet değişikliği olabilir. Kontrol sisteminin amacı fiyat düşüşünü engellemek değil, normal değişiklik ile olağan dışı değişikliği ayırmaktır.

XML fiyatı çok fazla düşerse ürün otomatik kapatılmalı mı?

Bu kullanılan sisteme ve işletmenin politikasına bağlıdır. Alternatif olarak yeni fiyat mağazaya aktarılmadan beklemeye alınabilir ve manuel doğrulamaya gönderilebilir. Mevcut Ulu İthalat fiyat rehberi de anormal fiyat değişikliklerinin manuel kontrole alınmasını öneriyor.

Fiyat düşüş kontrolünde yüzde kaç sınır kullanılmalı?

Bütün mağazalar için doğru tek bir yüzde yoktur. Ürün kategorisi, fiyat seviyesi, geçmiş fiyat hareketi ve işletmenin risk toleransına göre belirlenmelidir. Sabit bir evrensel oran uydurmak yerine gerçek mağaza verisiyle eşik oluşturmak daha doğru olur.

Yanlış fiyatın kaynağı nasıl bulunur?

Kaynak XML fiyatı, entegrasyonun aldığı değer, kullanılan fiyatlandırma kuralı ve mağazadaki son satış fiyatı sırayla karşılaştırılmalıdır. Ulu İthalat'ın veri çakışmaları rehberi de kaynak veri → işlem zamanı → mağazadaki son değer → diğer otomasyonlar → değişiklik kaydı sırasını öneriyor.

Hatalı toplu fiyat güncellemesi geri alınabilir mi?

Yalnızca eski değerler veya uygun bir yedek mevcutsa güvenli geri dönüş mümkün olabilir. Bu nedenle toplu fiyatlandırma değişikliklerinden önce kaynak ve işlenmiş verinin geri dönüş noktalarının planlanması önemlidir.

Fiyat Düşüşünü Engellemek Değil, Hatalı Düşüşü Yakalamak Gerekir

XML fiyat düşüş kontrolü doğru kurulduğunda amaç tedarikçinin gerçek indirimlerini bloke etmek değildir.

Amaç:

yeni fiyatı al → eski fiyatla karşılaştır → değişim büyüklüğünü ölç → maliyet sınırını kontrol et → ürün/SKU eşleşmesini doğrula → şüpheli değişikliği ayır → gerekirse onaya gönder → sonucu kayıt altına al

şeklinde güvenli bir akış oluşturmaktır.

Böylece sistem:

“XML'de ne geldiyse doğrudan yayınla.”

mantığından,

“XML'de gelen fiyatı doğrula, normal değişiklikleri otomatik geçir, anormal değişiklikleri durdur ve incele.”

mantığına geçer.

Genel fiyat ve stok aktarım sürecinin nasıl çalıştığını görmek için XML Ürünlerinde Fiyat ve Stok Güncellemesi Nasıl Yönetilir? rehberi kullanılabilir. Mevcut içerik fiyat/stok güncellemesi, senkronizasyon sıklığı ve genel fiyat hatalarına odaklanıyor.

Bir fiyatın eski veya yanlış veri nedeniyle tekrar değişmesini önlemek için XML Entegrasyonunda Veri Güncelleme Çakışmaları Nasıl Önlenir? içeriğine geçilebilir. Bu sayfa kaynak önceliği, işlem sırası, eski-yeni veri, manuel müdahale ve değişiklik kayıtlarını ele alıyor.

Toplu fiyat hatasında eski duruma nasıl dönüleceğini planlamak için XML Entegrasyonunda Veri Yedekleme ve Geri Alma Nasıl Planlanır? rehberi kullanılabilir.

Tedarikçinin fiyat verisinin güncelliğini daha geniş çalışma koşulları içerisinde değerlendirmek için XML Tedarikçisi Seçerken Nelere Dikkat Edilmelidir? rehberi kullanılabilir.

XML sisteminin genel yapısını öğrenmek isteyen kullanıcılar XML Bayilik Nedir? Nasıl Çalışır ve Kimler İçin Uygundur? içeriğine geçebilir.

Ulu İthalat'ın mevcut ticari çalışma modelini incelemek isteyen işletmeler ise XML Bayilik sayfasını kullanabilir. Canlı sayfada fiyat ve stok bilgilerinin XML ile aktarılabildiği, fiyat değişikliklerinin kontrol edilmesi gerektiği ve güncelleme sıklığının kullanılan sisteme göre değişebileceği açıklanıyor.