Aydınlatma metni yükleniyor…
Bayi portalında özel fiyat ve iskonto yönetimi, her bayiye farklı bir fiyat göstermekten daha geniş bir problemdir. Sistem; hangi şirket veya şubenin giriş yaptığını, hangi ürünleri görebildiğini, geçerli sözleşmeyi, miktar basamağını, kampanyayı, para birimini, tarihi ve manuel yetkiyi aynı sipariş anında değerlendirmelidir. En önemli çıktı yalnız net tutar değil, bu tutarın hangi kurallarla oluştuğunun açıklanabilir ve tekrar üretilebilir olmasıdır.
Bu rehber, B2B satış ve e-ticaret yöneticilerinin fiyat kuralı kapsamını yazabilmesi için hazırlanmıştır. “Kumsal fiyat karar yığını” ve kabul testi matrisi bu makale için geliştirilmiş özgün planlama araçlarıdır. Belirli bir yazılım ürününü önermez; bir Kumsal Ajans müşterisinin sonucu veya kârlılık garantisi değildir.
Önce fiyat ile iskontoyu birbirinden ayırın
Fiyat, ürünün belirli bir bağlamdaki başlangıç veya sözleşmeli birim tutarıdır. İskonto ise bu tutar üzerine uygulanan ticari değişikliktir. “Liste fiyatından yüzde 20 indirim” ile “bayiye özel net fiyat 800 TL” aynı kural değildir. Birincisi kaynak fiyat değiştiğinde farklı sonuç verir; ikincisi geçerlilik süresi boyunca sabit bir net tutar olabilir.
Benzer şekilde kampanya, miktar basamağı, ödeme şekli avantajı, kupon, satış temsilcisi indirimi ve sözleşmeli fiyat aynı sepette görünse bile farklı sahiplik ve çakışma davranışına ihtiyaç duyar. Her birini tek bir “indirim yüzdesi” alanına sıkıştırmak, sonucun neden oluştuğunu ve hangi ekip tarafından değiştirildiğini izlemeyi zorlaştırır.
Fiyat bağlamını siparişten önce tanımlayın
Aynı ürünün doğru fiyatı, yalnız ürün kodundan çıkarılamaz. Hesaplama başlamadan önce aşağıdaki bağlam açıkça belirlenmelidir:
- Bayi şirketi, şubesi, teslimat hesabı ve kullanıcı rolü
- Satış kanalı, ülke/bölge, para birimi ve vergi gösterim tercihi
- Ürün, varyant, paket/birim ve satışa uygunluk durumu
- Sipariş miktarı, toplam sepet koşulu ve teslimat tarihi
- Sözleşme, fiyat listesi, segment ve kampanya üyeliği
- Hesaplama zamanı, geçerlilik aralığı ve kullanılan veri sürümü
Bayi şirketi ile şirketin satın alma şubesi aynı şey olmayabilir. Merkez sözleşmesi bütün şubelere uygulanabilir veya belirli teslimat noktası için ayrı fiyat bulunabilir. Kullanıcı adı üzerinden fiyat vermek yerine ticari hesabın ve konumun fiyat bağlamı tanımlanmalıdır.
Kumsal fiyat karar yığını: kural sırasını görünür yapın
Fiyat motorunu tek, uzun bir formül yerine ardışık karar katmanları olarak tanımlamak; iş ekibi, ERP ekibi ve yazılım ekibinin aynı sonucu tartışmasını kolaylaştırır. Aşağıdaki sıra evrensel bir standart değildir; projeye uyarlanacak bir kapsam çerçevesidir.
| Katman | Temel soru | Kaydedilecek kanıt | Belirsizlikte davranış |
|---|---|---|---|
| 1. Kimlik ve bağlam | Hangi şirket, şube, kanal ve para birimi? | Hesap/konum kimliği ve hesaplama zamanı | Fiyatı göstermeden bağlamı tamamlama |
| 2. Ürün uygunluğu | Bayi bu ürün, varyant ve paketi satın alabilir mi? | Katalog ve satış kısıtı sürümü | Ürünü gizleme veya gerekçeli bloke |
| 3. Kaynak fiyat | Sözleşme, şube listesi, segment veya genel liste hangisi? | Kazanan fiyat kaydı ve öncelik | Tanımlı yedek kural; sessiz tahmin yok |
| 4. Miktar kuralı | Minimum, kat ve hacim basamağı sağlandı mı? | Uygulanan basamak ve ölçü birimi | Geçerli miktarı açıkça önerme |
| 5. İskonto çakışması | En iyi, birleşen veya dışlayıcı kural mı? | Kazanan/kaybeden kural kimlikleri | Tanımsız birleşimi uygulamama |
| 6. Yetki ve taban | Manuel değişiklik yetki veya alt sınırı aşıyor mu? | Kullanıcı, gerekçe ve onay durumu | Fiyatı değiştirmeden onaya yönlendirme |
| 7. Son hesap | Yuvarlama, para birimi ve satır/sepet dağılımı nedir? | Ara değerler ve yuvarlama yöntemi | Hesabı reddetme; yaklaşık tutar göstermeme |
| 8. Sipariş anlık görüntüsü | Bu sonuç siparişte nasıl korunacak? | Fiyat sürümü, kural özeti ve net tutar | Değişiklikte yeniden fiyatlama ve kullanıcı teyidi |
Bu yapı sayesinde “bayinin fiyatı yanlış” bildirimi yalnız ekrandaki tutara bakılarak değerlendirilmez. Hangi bağlamın geldiği, hangi kayıtların aday olduğu, hangi önceliğin kazandığı ve hangi indirimin elendiği görülebilir.
Özel fiyatlarda öncelik nasıl belirlenir?
Sistemde aynı ürün için sözleşmeli net fiyat, şirkete bağlı fiyat listesi, şube fiyatı, bayi segmenti ve genel liste aynı anda bulunabilir. Ekip “en düşük fiyat her zaman kazanır” veya “en özel kayıt kazanır” kararlarından hangisini kullanacağını açıkça yazmalıdır. Bazı ürünlerde sözleşme fiyatı dışlayıcı olurken bazı yapılarda miktar indirimi sözleşme fiyatına da uygulanabilir.
Microsoft Dynamics 365 Commerce fiyat yönetimi belgeleri, fiyat gruplarıyla kanal, katalog ve müşteri gibi varlıkların fiyat kayıtlarına bağlanabildiğini; fiyat önceliğinin daha yüksek öncelikteki kaydın önce değerlendirilmesini sağlayabildiğini açıklar. Bu, kullanılacak ürün için bir öneri değildir. Aynı ürün için birden fazla aday bulunduğunda seçimin tesadüfe bırakılamayacağını gösteren uygulama örneğidir.
Öncelik yalnız bir sayı olmamalıdır. Her fiyat türü için kapsam, geçerlilik, ürün seviyesi, müşteri seviyesi, para birimi, kaynak sistem ve yedek davranış yazılmalıdır. İki kayıt aynı öncelik ve tarih aralığında çakışıyorsa yayına alınmadan hata üretmek, oluşturma sırasına göre görünmez bir kazanan seçmekten daha güvenlidir.
İskontolar “en iyi”, “birleşen” ve “dışlayıcı” olarak sınıflandırılmalıdır
İki yüzde indirimin aynı anda geçerli olması, otomatik olarak ikisinin toplanacağı anlamına gelmez. Kurallar üç temel davranıştan biriyle tasarlanabilir:
- En iyi sonuç: Uygun indirimlerden yalnız tanımlı ölçüte göre kazanan uygulanır.
- Birleşen: Birden fazla indirim belirli sıra ve hesap tabanıyla birlikte uygulanır.
- Dışlayıcı: Kural uygulandığında aynı kapsamda başka indirim kabul edilmez.
Birleşen yüzde indirimlerinde işlem sırası ve hesap tabanı sonucu değiştirir. Yüzde 10 ve yüzde 20 indirimi orijinal fiyat üzerinden ayrı ayrı düşmek ile ikinci indirimi ilk indirimden kalan tutara uygulamak aynı net fiyatı üretmez. Microsoft'un fiyat ayarları belgeleri de “en iyi fiyat” ve birleşen indirimlerin öncelik içinde veya öncelikler arasında nasıl yarışacağı ile birleşen indirimlerin özgün fiyat ya da kalan fiyat üzerinden hesaplanması için ayrı davranışlar tanımlar.
Her kampanya kaydına yalnız oran değil; davranış türü, öncelik, birleşebileceği kural aileleri, hesap tabanı, maksimum etki ve geçerlilik eklenmelidir. Böylece yeni bir kampanya açıldığında bütün mevcut indirimlerle beklenmedik biçimde birleşmez.
Miktar kuralları ile hacim fiyatını aynı şey sanmayın
Minimum sipariş miktarı, satın alma katı ve maksimum miktar bir uygunluk kuralıdır. Hacim fiyatı ise belirli miktarda ulaşılan yeni birim fiyat veya indirimdir. Bir ürün yalnız 12'li koliyle satılabilir fakat 60 adette ayrıca fiyat avantajı başlayabilir. Paket birimi ile stok birimi farklıysa miktar basamakları hangi birimde değerlendirildiğini açıkça belirtmelidir.
Shopify'ın B2B miktar ve hacim fiyatlandırma belgeleri, minimum, maksimum ve artış miktarlarını hacim fiyat basamaklarından ayrı yapılandırır; hacim fiyatının ürün varyantındaki miktara göre değerlendirilmesini açıklar. B2B katalog belgeleri ise bir şirkete veya konuma birden fazla katalog atanabildiğini ve çakışan ürün fiyatları için tanımlı seçim davranışı gerektiğini gösterir. Bunlar platforma özgü örneklerdir; proje kuralı şirketin sözleşme ve satış modeline göre yazılmalıdır.
Fiyatı ürün sayfası, sepet ve ERP'de aynı girdilerle hesaplayın
Ürün sayfası bir fiyat, sepet başka fiyat ve ERP üçüncü fiyat üretiyorsa kullanıcı hangi tutara güveneceğini bilemez. Tek bir merkezi fiyat servisi kullanılabilir veya farklı sistemler aynı kural paketini uygulayabilir; her iki durumda da girdi ve sürüm sözleşmesi ortak olmalıdır.
Ürün listeleme sırasında performans için önceden hesaplanmış fiyat gösterilebilir. Sepette ise miktar, teslimat hesabı, kampanya ve güncel sözleşme yeniden değerlendirilir. Sipariş ERP'ye aktarılırken portalın fiyat açıklaması ve ERP sonucu karşılaştırılır. Fark varsa siparişi sessizce farklı tutarla kaydetmek yerine tanımlı tolerans, yeniden fiyatlama ve kullanıcı/onay akışı uygulanmalıdır. Stok, fiyat, sipariş ve hata sahipliğini birlikte planlamak için e-ticaret–ERP entegrasyonu rehberini kullanabilirsiniz.
Fiyat kilidi ve yeniden fiyatlama koşullarını belirleyin
Sepete eklenen fiyatın ne kadar süre korunacağı iş modeline bağlıdır. Sözleşmeli net fiyat gün sonuna kadar geçerli olabilir; dövize bağlı bir kayıt daha kısa süreli değerlendirilebilir; sipariş taslağı ise onaylanana kadar yeniden hesap gerektirebilir. “Sepete eklenen fiyat değişmez” ve “her sayfa açılışında güncellenir” seçeneklerinin ikisi de her işletme için doğru değildir.
Fiyat değiştiğinde sistem eski tutarı, yeni tutarı, değişen kuralı ve kullanıcıdan beklenen işlemi göstermelidir. Siparişe yalnız son net tutarı değil, kullanılan fiyat ve iskonto kayıtlarının kimliği ile sürümünü de yazmak; iade, itiraz ve mutabakat sırasında aynı hesabı yeniden kurmayı kolaylaştırır.
Cari limit fiyat hesaplamasından ayrı bir karar olmalıdır
Bayiye doğru net fiyatı hesaplamak ile vadeli satın alma yetkisi vermek aynı işlem değildir. Kredi/cari limit, gecikmiş borç, ödeme yöntemi veya risk blokajı ödeme ve sipariş kabul aşamasında ayrı bir karar üretir. Limit yetersiz olduğunda fiyatı değiştirmek yerine vadeli ödeme seçeneğini kapatmak, kısmi ödeme istemek veya yetkili incelemeye yönlendirmek gibi davranışlar tanımlanabilir.
Bu ayrım, “fiyat neden değişti?” ile “sipariş neden kabul edilmedi?” sorularının farklı kanıtlarla yanıtlanmasını sağlar. Finansal limit ve risk politikaları yetkili iş birimleri tarafından onaylanmalıdır; bu rehber muhasebe, kredi veya hukuk görüşü değildir.
Fiyat kuralı değişikliklerini sürümleyin
Bir kuralın yalnız mevcut hâlini saklamak yeterli değildir. Başlangıç/bitiş zamanı, taslak–onaylı–etkin–sona ermiş durumları, değişiklik gerekçesi, yapan ve onaylayan kullanıcı ile etkilenen ürün/bayi kapsamı tutulmalıdır. Geçmiş bir sipariş bugünkü kurallarla yeniden hesaplandığında farklı çıkabilir; inceleme için sipariş anındaki sürüm korunmalıdır.
Toplu fiyat içe aktarmada doğrulama raporu üretin: bilinmeyen ürün, yinelenen kayıt, çakışan tarih, yanlış para birimi, negatif/boş değer, alt sınır ihlali ve beklenmeyen fiyat farkı ayrı gösterilsin. Etkinleştirmeden önce örnek bayi ve sepetlerle etki analizi yapılması, geniş bir hatayı canlıda fark etmekten daha kontrollüdür.
Kabul testlerini gerçek kural çakışmalarıyla yazın
Aşağıdaki örnekler temsili bir fiyat politikasını sınar; gerçek oran ve öncelikler değildir. Test verisi, beklenen sonuç ve açıklama aynı kayıtta bulunmalıdır.
| Senaryo | Beklenen davranış | Kontrol edilen kanıt |
|---|---|---|
| Ürüne özel sözleşmeli net fiyat var | Segment listesi elenir; sözleşmenin dışlayıcılık kuralı uygulanır | Kazanan kayıt, öncelik ve geçerlilik |
| Aynı şirket konumuna iki katalog atanmış | Tanımlı özgüllük/öncelik kuralı deterministik kazanan seçer | Aday kataloglar ve eleme nedeni |
| Miktar basamağı sağlanıyor, kampanya da geçerli | En iyi/birleşen/dışlayıcı politikaya göre tek açıklanabilir sonuç | Hesap sırası ve ara değerler |
| Sipariş miktarı koli katına uymuyor | Fiyat üretmek yerine geçerli kat ve minimum açıklanır | Birim dönüşümü ve miktar kuralı |
| Manuel indirim kullanıcının sınırını aşıyor | Yetkisiz fiyat uygulanmaz; gerekçe ile onaya gider | Kullanıcı limiti ve onay durumu |
| Kural tam başlangıç/bitiş anında hesaplanıyor | Saat dilimi ve sınır dâhil/hariç kararı tutarlı uygulanır | Zaman damgası ve kural sürümü |
| Sepetten siparişe geçerken fiyat değişmiş | Fark görünür; yeniden fiyatlama ve teyit politikası çalışır | Eski/yeni sürüm ve kullanıcı kararı |
| ERP farklı net tutar döndürüyor | Sipariş sessizce değiştirilmez; tolerans veya hata kuyruğu çalışır | Portal hesabı, ERP hesabı ve sonuç |
Bayi fiyatlandırma projesi teklifinde neler bulunmalı?
- Fiyat bağlamı, bayi/şube modeli ve ürün katalog kapsamı
- Fiyat türleri, öncelik matrisi ve geçerlilik kuralları
- Miktar, paket, hacim ve minimum sipariş davranışları
- İskonto çakışma, birleşme, dışlama ve yetki politikaları
- Para birimi, hassasiyet, yuvarlama ve fiyat kilidi yaklaşımı
- ERP ile alan sahipliği, yeniden hesap, tolerans ve hata kuyruğu
- Kural sürümleme, toplu içe aktarma, onay ve denetim izi
- Kabul testleri, pilot kapsamı, izleme ve işletim sorumluları
Teklif yalnız “bayiye özel fiyat yapılacaktır” diyorsa sonuç test edilemez. En az bir öncelik matrisi, çakışma politikası, örnek hesap açıklaması ve uçtan uca kabul senaryosu teslimat olarak yazılmalıdır.
Sonuç: Net fiyat kadar fiyatın açıklaması da bir çıktıdır
Bayi portalında güvenilir fiyatlandırma; sözleşme, katalog, miktar, kampanya ve manuel yetki kurallarını görünmez biçimde üst üste yığmak değildir. Her kuralın kapsamı, önceliği, birleşme davranışı, geçerliliği ve sahibi tanımlanmalı; sipariş aynı girdilerle tekrar hesaplandığında aynı açıklanabilir sonucu üretmelidir.
Önce fiyat karar yığınını ve çakışma tablosunu yazın, ardından gerçek sepet senaryolarıyla test edin. Bayi portalı fiyat yapınızı, ERP bağlantısını ve yönetim ekranlarını birlikte kapsamlandırmak isterseniz Kumsal Ajans e-ticaret çözümlerini inceleyebilirsiniz.
Bayi portalında özel fiyat ve iskonto yönetimi, her bayiye farklı bir fiyat göstermekten daha geniş bir problemdir. Sistem; hangi şirket veya şubenin giriş yaptığını, hangi ürünleri görebildiğini, geçerli sözleşmeyi, miktar basamağını, kampanyayı, para birimini, tarihi ve manuel yetkiyi aynı sipariş anında değerlendirmelidir. En önemli çıktı yalnız net tutar değil, bu tutarın hangi kurallarla oluştuğunun açıklanabilir ve tekrar üretilebilir olmasıdır.
Bu rehber, B2B satış ve e-ticaret yöneticilerinin fiyat kuralı kapsamını yazabilmesi için hazırlanmıştır. “Kumsal fiyat karar yığını” ve kabul testi matrisi bu makale için geliştirilmiş özgün planlama araçlarıdır. Belirli bir yazılım ürününü önermez; bir Kumsal Ajans müşterisinin sonucu veya kârlılık garantisi değildir.
Önce fiyat ile iskontoyu birbirinden ayırın
Fiyat, ürünün belirli bir bağlamdaki başlangıç veya sözleşmeli birim tutarıdır. İskonto ise bu tutar üzerine uygulanan ticari değişikliktir. “Liste fiyatından yüzde 20 indirim” ile “bayiye özel net fiyat 800 TL” aynı kural değildir. Birincisi kaynak fiyat değiştiğinde farklı sonuç verir; ikincisi geçerlilik süresi boyunca sabit bir net tutar olabilir.
Benzer şekilde kampanya, miktar basamağı, ödeme şekli avantajı, kupon, satış temsilcisi indirimi ve sözleşmeli fiyat aynı sepette görünse bile farklı sahiplik ve çakışma davranışına ihtiyaç duyar. Her birini tek bir “indirim yüzdesi” alanına sıkıştırmak, sonucun neden oluştuğunu ve hangi ekip tarafından değiştirildiğini izlemeyi zorlaştırır.
Fiyat bağlamını siparişten önce tanımlayın
Aynı ürünün doğru fiyatı, yalnız ürün kodundan çıkarılamaz. Hesaplama başlamadan önce aşağıdaki bağlam açıkça belirlenmelidir:
- Bayi şirketi, şubesi, teslimat hesabı ve kullanıcı rolü
- Satış kanalı, ülke/bölge, para birimi ve vergi gösterim tercihi
- Ürün, varyant, paket/birim ve satışa uygunluk durumu
- Sipariş miktarı, toplam sepet koşulu ve teslimat tarihi
- Sözleşme, fiyat listesi, segment ve kampanya üyeliği
- Hesaplama zamanı, geçerlilik aralığı ve kullanılan veri sürümü
Bayi şirketi ile şirketin satın alma şubesi aynı şey olmayabilir. Merkez sözleşmesi bütün şubelere uygulanabilir veya belirli teslimat noktası için ayrı fiyat bulunabilir. Kullanıcı adı üzerinden fiyat vermek yerine ticari hesabın ve konumun fiyat bağlamı tanımlanmalıdır.
Kumsal fiyat karar yığını: kural sırasını görünür yapın
Fiyat motorunu tek, uzun bir formül yerine ardışık karar katmanları olarak tanımlamak; iş ekibi, ERP ekibi ve yazılım ekibinin aynı sonucu tartışmasını kolaylaştırır. Aşağıdaki sıra evrensel bir standart değildir; projeye uyarlanacak bir kapsam çerçevesidir.
| Katman | Temel soru | Kaydedilecek kanıt | Belirsizlikte davranış |
|---|---|---|---|
| 1. Kimlik ve bağlam | Hangi şirket, şube, kanal ve para birimi? | Hesap/konum kimliği ve hesaplama zamanı | Fiyatı göstermeden bağlamı tamamlama |
| 2. Ürün uygunluğu | Bayi bu ürün, varyant ve paketi satın alabilir mi? | Katalog ve satış kısıtı sürümü | Ürünü gizleme veya gerekçeli bloke |
| 3. Kaynak fiyat | Sözleşme, şube listesi, segment veya genel liste hangisi? | Kazanan fiyat kaydı ve öncelik | Tanımlı yedek kural; sessiz tahmin yok |
| 4. Miktar kuralı | Minimum, kat ve hacim basamağı sağlandı mı? | Uygulanan basamak ve ölçü birimi | Geçerli miktarı açıkça önerme |
| 5. İskonto çakışması | En iyi, birleşen veya dışlayıcı kural mı? | Kazanan/kaybeden kural kimlikleri | Tanımsız birleşimi uygulamama |
| 6. Yetki ve taban | Manuel değişiklik yetki veya alt sınırı aşıyor mu? | Kullanıcı, gerekçe ve onay durumu | Fiyatı değiştirmeden onaya yönlendirme |
| 7. Son hesap | Yuvarlama, para birimi ve satır/sepet dağılımı nedir? | Ara değerler ve yuvarlama yöntemi | Hesabı reddetme; yaklaşık tutar göstermeme |
| 8. Sipariş anlık görüntüsü | Bu sonuç siparişte nasıl korunacak? | Fiyat sürümü, kural özeti ve net tutar | Değişiklikte yeniden fiyatlama ve kullanıcı teyidi |
Bu yapı sayesinde “bayinin fiyatı yanlış” bildirimi yalnız ekrandaki tutara bakılarak değerlendirilmez. Hangi bağlamın geldiği, hangi kayıtların aday olduğu, hangi önceliğin kazandığı ve hangi indirimin elendiği görülebilir.
Özel fiyatlarda öncelik nasıl belirlenir?
Sistemde aynı ürün için sözleşmeli net fiyat, şirkete bağlı fiyat listesi, şube fiyatı, bayi segmenti ve genel liste aynı anda bulunabilir. Ekip “en düşük fiyat her zaman kazanır” veya “en özel kayıt kazanır” kararlarından hangisini kullanacağını açıkça yazmalıdır. Bazı ürünlerde sözleşme fiyatı dışlayıcı olurken bazı yapılarda miktar indirimi sözleşme fiyatına da uygulanabilir.
Microsoft Dynamics 365 Commerce fiyat yönetimi belgeleri, fiyat gruplarıyla kanal, katalog ve müşteri gibi varlıkların fiyat kayıtlarına bağlanabildiğini; fiyat önceliğinin daha yüksek öncelikteki kaydın önce değerlendirilmesini sağlayabildiğini açıklar. Bu, kullanılacak ürün için bir öneri değildir. Aynı ürün için birden fazla aday bulunduğunda seçimin tesadüfe bırakılamayacağını gösteren uygulama örneğidir.
Öncelik yalnız bir sayı olmamalıdır. Her fiyat türü için kapsam, geçerlilik, ürün seviyesi, müşteri seviyesi, para birimi, kaynak sistem ve yedek davranış yazılmalıdır. İki kayıt aynı öncelik ve tarih aralığında çakışıyorsa yayına alınmadan hata üretmek, oluşturma sırasına göre görünmez bir kazanan seçmekten daha güvenlidir.
İskontolar “en iyi”, “birleşen” ve “dışlayıcı” olarak sınıflandırılmalıdır
İki yüzde indirimin aynı anda geçerli olması, otomatik olarak ikisinin toplanacağı anlamına gelmez. Kurallar üç temel davranıştan biriyle tasarlanabilir:
- En iyi sonuç: Uygun indirimlerden yalnız tanımlı ölçüte göre kazanan uygulanır.
- Birleşen: Birden fazla indirim belirli sıra ve hesap tabanıyla birlikte uygulanır.
- Dışlayıcı: Kural uygulandığında aynı kapsamda başka indirim kabul edilmez.
Birleşen yüzde indirimlerinde işlem sırası ve hesap tabanı sonucu değiştirir. Yüzde 10 ve yüzde 20 indirimi orijinal fiyat üzerinden ayrı ayrı düşmek ile ikinci indirimi ilk indirimden kalan tutara uygulamak aynı net fiyatı üretmez. Microsoft'un fiyat ayarları belgeleri de “en iyi fiyat” ve birleşen indirimlerin öncelik içinde veya öncelikler arasında nasıl yarışacağı ile birleşen indirimlerin özgün fiyat ya da kalan fiyat üzerinden hesaplanması için ayrı davranışlar tanımlar.
Her kampanya kaydına yalnız oran değil; davranış türü, öncelik, birleşebileceği kural aileleri, hesap tabanı, maksimum etki ve geçerlilik eklenmelidir. Böylece yeni bir kampanya açıldığında bütün mevcut indirimlerle beklenmedik biçimde birleşmez.
Miktar kuralları ile hacim fiyatını aynı şey sanmayın
Minimum sipariş miktarı, satın alma katı ve maksimum miktar bir uygunluk kuralıdır. Hacim fiyatı ise belirli miktarda ulaşılan yeni birim fiyat veya indirimdir. Bir ürün yalnız 12'li koliyle satılabilir fakat 60 adette ayrıca fiyat avantajı başlayabilir. Paket birimi ile stok birimi farklıysa miktar basamakları hangi birimde değerlendirildiğini açıkça belirtmelidir.
Shopify'ın B2B miktar ve hacim fiyatlandırma belgeleri, minimum, maksimum ve artış miktarlarını hacim fiyat basamaklarından ayrı yapılandırır; hacim fiyatının ürün varyantındaki miktara göre değerlendirilmesini açıklar. B2B katalog belgeleri ise bir şirkete veya konuma birden fazla katalog atanabildiğini ve çakışan ürün fiyatları için tanımlı seçim davranışı gerektiğini gösterir. Bunlar platforma özgü örneklerdir; proje kuralı şirketin sözleşme ve satış modeline göre yazılmalıdır.
Fiyatı ürün sayfası, sepet ve ERP'de aynı girdilerle hesaplayın
Ürün sayfası bir fiyat, sepet başka fiyat ve ERP üçüncü fiyat üretiyorsa kullanıcı hangi tutara güveneceğini bilemez. Tek bir merkezi fiyat servisi kullanılabilir veya farklı sistemler aynı kural paketini uygulayabilir; her iki durumda da girdi ve sürüm sözleşmesi ortak olmalıdır.
Ürün listeleme sırasında performans için önceden hesaplanmış fiyat gösterilebilir. Sepette ise miktar, teslimat hesabı, kampanya ve güncel sözleşme yeniden değerlendirilir. Sipariş ERP'ye aktarılırken portalın fiyat açıklaması ve ERP sonucu karşılaştırılır. Fark varsa siparişi sessizce farklı tutarla kaydetmek yerine tanımlı tolerans, yeniden fiyatlama ve kullanıcı/onay akışı uygulanmalıdır. Stok, fiyat, sipariş ve hata sahipliğini birlikte planlamak için e-ticaret–ERP entegrasyonu rehberini kullanabilirsiniz.
Fiyat kilidi ve yeniden fiyatlama koşullarını belirleyin
Sepete eklenen fiyatın ne kadar süre korunacağı iş modeline bağlıdır. Sözleşmeli net fiyat gün sonuna kadar geçerli olabilir; dövize bağlı bir kayıt daha kısa süreli değerlendirilebilir; sipariş taslağı ise onaylanana kadar yeniden hesap gerektirebilir. “Sepete eklenen fiyat değişmez” ve “her sayfa açılışında güncellenir” seçeneklerinin ikisi de her işletme için doğru değildir.
Fiyat değiştiğinde sistem eski tutarı, yeni tutarı, değişen kuralı ve kullanıcıdan beklenen işlemi göstermelidir. Siparişe yalnız son net tutarı değil, kullanılan fiyat ve iskonto kayıtlarının kimliği ile sürümünü de yazmak; iade, itiraz ve mutabakat sırasında aynı hesabı yeniden kurmayı kolaylaştırır.
Cari limit fiyat hesaplamasından ayrı bir karar olmalıdır
Bayiye doğru net fiyatı hesaplamak ile vadeli satın alma yetkisi vermek aynı işlem değildir. Kredi/cari limit, gecikmiş borç, ödeme yöntemi veya risk blokajı ödeme ve sipariş kabul aşamasında ayrı bir karar üretir. Limit yetersiz olduğunda fiyatı değiştirmek yerine vadeli ödeme seçeneğini kapatmak, kısmi ödeme istemek veya yetkili incelemeye yönlendirmek gibi davranışlar tanımlanabilir.
Bu ayrım, “fiyat neden değişti?” ile “sipariş neden kabul edilmedi?” sorularının farklı kanıtlarla yanıtlanmasını sağlar. Finansal limit ve risk politikaları yetkili iş birimleri tarafından onaylanmalıdır; bu rehber muhasebe, kredi veya hukuk görüşü değildir.
Fiyat kuralı değişikliklerini sürümleyin
Bir kuralın yalnız mevcut hâlini saklamak yeterli değildir. Başlangıç/bitiş zamanı, taslak–onaylı–etkin–sona ermiş durumları, değişiklik gerekçesi, yapan ve onaylayan kullanıcı ile etkilenen ürün/bayi kapsamı tutulmalıdır. Geçmiş bir sipariş bugünkü kurallarla yeniden hesaplandığında farklı çıkabilir; inceleme için sipariş anındaki sürüm korunmalıdır.
Toplu fiyat içe aktarmada doğrulama raporu üretin: bilinmeyen ürün, yinelenen kayıt, çakışan tarih, yanlış para birimi, negatif/boş değer, alt sınır ihlali ve beklenmeyen fiyat farkı ayrı gösterilsin. Etkinleştirmeden önce örnek bayi ve sepetlerle etki analizi yapılması, geniş bir hatayı canlıda fark etmekten daha kontrollüdür.
Kabul testlerini gerçek kural çakışmalarıyla yazın
Aşağıdaki örnekler temsili bir fiyat politikasını sınar; gerçek oran ve öncelikler değildir. Test verisi, beklenen sonuç ve açıklama aynı kayıtta bulunmalıdır.
| Senaryo | Beklenen davranış | Kontrol edilen kanıt |
|---|---|---|
| Ürüne özel sözleşmeli net fiyat var | Segment listesi elenir; sözleşmenin dışlayıcılık kuralı uygulanır | Kazanan kayıt, öncelik ve geçerlilik |
| Aynı şirket konumuna iki katalog atanmış | Tanımlı özgüllük/öncelik kuralı deterministik kazanan seçer | Aday kataloglar ve eleme nedeni |
| Miktar basamağı sağlanıyor, kampanya da geçerli | En iyi/birleşen/dışlayıcı politikaya göre tek açıklanabilir sonuç | Hesap sırası ve ara değerler |
| Sipariş miktarı koli katına uymuyor | Fiyat üretmek yerine geçerli kat ve minimum açıklanır | Birim dönüşümü ve miktar kuralı |
| Manuel indirim kullanıcının sınırını aşıyor | Yetkisiz fiyat uygulanmaz; gerekçe ile onaya gider | Kullanıcı limiti ve onay durumu |
| Kural tam başlangıç/bitiş anında hesaplanıyor | Saat dilimi ve sınır dâhil/hariç kararı tutarlı uygulanır | Zaman damgası ve kural sürümü |
| Sepetten siparişe geçerken fiyat değişmiş | Fark görünür; yeniden fiyatlama ve teyit politikası çalışır | Eski/yeni sürüm ve kullanıcı kararı |
| ERP farklı net tutar döndürüyor | Sipariş sessizce değiştirilmez; tolerans veya hata kuyruğu çalışır | Portal hesabı, ERP hesabı ve sonuç |
Bayi fiyatlandırma projesi teklifinde neler bulunmalı?
- Fiyat bağlamı, bayi/şube modeli ve ürün katalog kapsamı
- Fiyat türleri, öncelik matrisi ve geçerlilik kuralları
- Miktar, paket, hacim ve minimum sipariş davranışları
- İskonto çakışma, birleşme, dışlama ve yetki politikaları
- Para birimi, hassasiyet, yuvarlama ve fiyat kilidi yaklaşımı
- ERP ile alan sahipliği, yeniden hesap, tolerans ve hata kuyruğu
- Kural sürümleme, toplu içe aktarma, onay ve denetim izi
- Kabul testleri, pilot kapsamı, izleme ve işletim sorumluları
Teklif yalnız “bayiye özel fiyat yapılacaktır” diyorsa sonuç test edilemez. En az bir öncelik matrisi, çakışma politikası, örnek hesap açıklaması ve uçtan uca kabul senaryosu teslimat olarak yazılmalıdır.
Sonuç: Net fiyat kadar fiyatın açıklaması da bir çıktıdır
Bayi portalında güvenilir fiyatlandırma; sözleşme, katalog, miktar, kampanya ve manuel yetki kurallarını görünmez biçimde üst üste yığmak değildir. Her kuralın kapsamı, önceliği, birleşme davranışı, geçerliliği ve sahibi tanımlanmalı; sipariş aynı girdilerle tekrar hesaplandığında aynı açıklanabilir sonucu üretmelidir.
Önce fiyat karar yığınını ve çakışma tablosunu yazın, ardından gerçek sepet senaryolarıyla test edin. Bayi portalı fiyat yapınızı, ERP bağlantısını ve yönetim ekranlarını birlikte kapsamlandırmak isterseniz Kumsal Ajans e-ticaret çözümlerini inceleyebilirsiniz.