Bir tedarikçi XML'inde ürün fiyatı:

200 TL

görünüyor.

Bu değeri doğrudan Trendyol'a:

200 TL satış fiyatı

olarak göndermek ilk bakışta kolay bir entegrasyon gibi görünebilir.

Ancak şu soruların cevapları bilinmiyorsa ciddi fiyat hataları ortaya çıkabilir:

200 TL alış fiyatı mı?

KDV dahil mi?

Bayi fiyatı mı?

Tavsiye edilen satış fiyatı mı?

Kampanyalı maliyet mi?

Bu fiyat ne zaman güncellendi?

Kargo ve platform giderleri hesaba katıldı mı?

Minimum kâr sınırının altında mı?

Trendyol'a en son hangi fiyat gönderildi?

Gönderilen fiyat gerçekten uygulandı mı?

Bu nedenle Trendyol XML fiyat entegrasyonu:

XML fiyatını kopyalamak

değil,

kaynak maliyeti kontrollü bir satış fiyatına dönüştürüp Trendyol ile tutarlı tutmak

olarak düşünülmelidir.

Ulu İthalat'ın canlı XML Bayilik sayfası da tedarik fiyatı ve satış fiyatındaki değişikliklerin zamanında takip edilememesinin kârlılık hesaplarını bozabileceğini; XML üzerinden sağlanan fiyat verilerinin daha kontrollü yönetilmesinin önemli olduğunu belirtiyor.

Daha sağlıklı mimari:

Tedarikçi XML fiyatı

↓

Kaynak fiyatın anlamını doğrula

↓

Normalize edilmiş maliyet

↓

KDV / masraf / iş kuralları

↓

Minimum güvenli fiyat

↓

Yuvarlama

↓

Trendyol salePrice / listPrice

↓

Önceki onaylı fiyatla karşılaştır

↓

Yalnız değişen fiyatı gönder

↓

batchRequestId

↓

Item sonucu

↓

Gerekirse Trendyol fiyatını geri oku

↓

Reconciliation

şeklindedir.

1. Önce XML'deki Fiyatın Ne Anlama Geldiğini Belirleyin

XML'de:

price = 200

yazması tek başına yeterli değildir.

Bu alan:

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

olabilir.

Alan anlamı tedarikçiden doğrulanmalıdır.

2. Fiyat Alanının Adına Körü Körüne Güvenmeyin

price

cost

sale_price

bayi_fiyat

gibi alan isimleri tedarikçiden tedarikçiye farklı anlamlara gelebilir.

Entegrasyon kuralı tahmine değil belgelenmiş veri yapısına dayanmalıdır.

3. Ham Kaynak Fiyatını Koruyun

Örneğin:

raw_supplier_price = 200

değerini ayrı saklayın.

Daha sonra:

normalized_cost = 240

ve:

target_sale_price = 349,90

gibi hesaplanmış değerleri ayrı tutun.

Bu ayrım hata araştırmasında çok değerlidir.

4. Kaynak Fiyatı Doğrudan Trendyol Satış Fiyatı Olarak Görmeyin

Tedarikçinin:

200 TL

verdiği değer sizin maliyetinizse Trendyol'daki satış fiyatınız:

200 TL

olamaz.

Arada işletmenin gerçek maliyet ve fiyatlandırma modeli bulunmalıdır.

5. KDV Dahil ve Hariç Fiyatı Ayırın

Örneğin:

200 TL KDV hariç

ile:

200 TL KDV dahil

aynı maliyet değildir.

Kaynak fiyatın vergi semantiği doğrulanmadan fiyat motoruna sokulmamalıdır.

6. Para Birimini Doğrulayın

Tedarikçi:

100

gönderiyor.

Bu:

TRY,

USD,

EUR

olabilir.

Para birimi başka alanla belirtiliyorsa birlikte işlenmelidir.

7. Kur Dönüşümü Ayrı Bir Katman Olmalıdır

Kaynak maliyet:

10 USD.

Trendyol fiyatı:

TRY.

Bu durumda kur dönüşümü:

kaynak fiyat normalizasyonu

aşamasında ele alınabilir.

Trendyol'un Türkiye ürün yapısında fiyat alanları TL satış modeli üzerinden kullanılmalıdır; kur bilgisini tedarikçi fiyatı yerine otomatik Trendyol fiyat alanı olarak düşünmemek gerekir.

8. Kullanılan Kurun Kaynağını Kaydedin

Örneğin:

exchange_rate = 44,25

rate_source = ...

rate_timestamp = ...

tutulabilir.

Sonradan:

“Bu fiyat neden 629 TL oldu?”

sorusunun cevabı bulunabilir.

9. Kur Değiştiğinde Her Ürünü Körü Körüne Yeniden Fiyatlamayın

Maliyet dövize bağlı olabilir.

Ancak işletme fiyatı:

• kur tamponu,
• minimum değişiklik eşiği,
• fiyat sabitleme süresi

gibi kurallar kullanabilir.

Bu fiyat motorunun konusudur.

10. 134'ün Görevi Fiyat Formülünü Baştan Kurmak Değildir

Bu ayrım önemli.

Örneğin:

maliyet + marj + kargo + komisyon

formülünün nasıl tasarlanacağı XML Fiyat Kuralları Nasıl Oluşturulur? içeriğinin alanıdır.

134:

hesaplanan son fiyatın Trendyol'a doğru geçirilmesini

sahiplenmelidir.

11. salePrice Alanını Doğru Anlayın

Trendyol güncel dokümantasyonunda:

salePrice

ürün satış fiyatı (TSF)

olarak tanımlanıyor.

Bu müşteriye sunmak istediğiniz temel satış fiyatı alanıdır.

12. listPrice Alanını da Doğru Anlayın

Trendyol:

listPrice

alanını satış fiyatı daha düşük olduğunda üzeri çizilen liste fiyatı/PSF olarak tanımlıyor.

Dolayısıyla bu alanı:

alış maliyeti

olarak kullanmak yanlış olur.

13. listPrice ile salePrice Aynı Olabilir

İndirimli görünüm kullanılmıyorsa:

listPrice = salePrice

olabilir.

Her üründe yapay olarak daha yüksek liste fiyatı üretmek zorunlu değildir.

14. listPrice, salePrice Değerinden Küçük Olamaz

Trendyol'un güncel Product V2 ürün oluşturma kurallarında:

listPrice < salePrice

olamayacağı belirtiliyor.

Bu kontrol fiyat Trendyol'a gönderilmeden önce yapılmalıdır.

15. Liste Fiyatını Sahte İndirim Üretmek İçin Kullanmayın

Örneğin gerçek satış planınız:

299 TL.

Sırf indirim görüntüsü için:

listPrice = 999 TL

oluşturmak sağlıklı fiyat yönetimi değildir.

Liste ve satış fiyatları gerçek ticari fiyat stratejinizle uyumlu olmalıdır.

16. Minimum Güvenli Satış Fiyatı Oluşturun

Örneğin sisteminiz:

minimum_safe_price = 319,90 TL

hesaplamış olabilir.

Yeni fiyat:

299 TL

çıkarsa otomatik yayına göndermek yerine:

PRICE_BELOW_FLOOR

durumuna alınabilir.

17. Minimum Fiyat Kuralı Trendyol API Kuralı Değildir

Bu sizin işletme kuralınızdır.

Trendyol size:

“%20 kâr et”

demez.

Bu nedenle platform kuralı ile kendi fiyat politikanızı ayırın.

18. Maksimum Fiyat Kontrolü de Kullanılabilir

Kaynak maliyet:

200 TL.

Hesaplanan fiyat:

20.000 TL.

Bu büyük ihtimalle:

• yanlış çarpan,
• kur hatası,
• ondalık problemi

olabilir.

Anormal fiyat artışı canlıya gitmeden durdurulabilir.

19. Fiyat Değişim Oranını Kontrol Edin

Eski fiyat:

300 TL.

Yeni:

303 TL.

Normal olabilir.

Eski:

300 TL.

Yeni:

3.000 TL.

İnceleme gerektirebilir.

20. Mutlak Değişim ve Yüzdesel Değişimi Birlikte Kullanabilirsiniz

10 TL → 20 TL:

%100 değişim.

5.000 TL → 5.010 TL:

yalnız %0,2.

Sadece TL veya sadece yüzde eşiği kullanmak her fiyat bandında yeterli olmayabilir.

21. Fiyat Kaynağının Güncelliğini Saklayın

Örneğin:

supplier_price_updated_at

feed_fetched_at

price_calculated_at

trendyol_sent_at

trendyol_confirmed_at

tutulabilir.

Böylece fiyatın yaşı anlaşılır.

22. XML'i İndirdiğiniz Saat Kaynak Fiyatın Güncellendiği Saat Olmayabilir

Feed'i:

18:00'de

indirdiniz.

Tedarikçi fiyatı:

14:00 snapshot'ı

olabilir.

Bu ayrım özellikle hızlı maliyet değişiminde önemlidir.

23. Kaynakta Timestamp Varsa Kullanın

Tedarikçi ürün başına veya feed başına güncelleme zamanı veriyorsa fiyat değişiminin gerçek yaşı daha iyi ölçülebilir.

24. Timestamp Yoksa Değişim Geçmişini Siz Tutun

Örneğin sistem:

17:00 → 200

17:15 → 210

gözlemlediyse en azından fiyatın ne zaman değiştiğini ilk fark ettiğinizi bilirsiniz.

25. Her XML Okumasında Fiyat Göndermek Gereksizdir

Eski hesaplanan fiyat:

349,90.

Yeni:

349,90.

Trendyol'a yeni request göndermeye gerek olmayabilir.

Trendyol da yalnız değişen stok/fiyatların gönderilmesini istiyor.

26. Delta Fiyat Güncellemesi Kullanın

Örnek:

last_confirmed_sale_price = 349,90

new_sale_price = 349,90

↓

Gönderme.

Yeni:

359,90

↓

Gönder.

27. last_calculated_price Tutabilirsiniz

Bu:

fiyat motorunun son ürettiği değerdir.

Ancak Trendyol'a başarıyla uygulandığı anlamına gelmez.

28. last_sent_price Ayrı Olmalıdır

Bu:

API'ye gönderdiğiniz son değerdir.

Ama hâlâ:

başarısız olmuş

olabilir.

29. last_confirmed_price En Kritik Alanlardan Biridir

Bu:

Trendyol batch işleminde başarılı olduğunu doğruladığınız son fiyattır.

Örneğin:

Calculated → 399

Sent → 399

Confirmed → 379

ise sistemde uyuşmazlık vardır.

30. Gönderildi ile Uygulandı Aynı Şey Değildir

Trendyol stok/fiyat servisi başarılı istekte:

batchRequestId

döndürüyor. İşlem kuyruğa alınıyor ve sonucu ayrıca kontrol etmeniz gerekiyor.

31. HTTP 200 Sonucunu “Fiyat Güncellendi” Diye Loglamayın

Daha doğru:

REQUEST_ACCEPTED

veya:

QUEUED

şeklinde tutulabilir.

Gerçek sonuç batch kontrolünden sonra belli olur.

32. Batch Sonucunu Mutlaka Kontrol Edin

Trendyol getBatchRequestResult servisiyle toplu işlemin tamamlanıp tamamlanmadığının kontrol edilmesini istiyor.

33. Item Bazında Sonuç Takibi Yapın

Batch:

500 ürün.

499 başarılı.

1 başarısız.

Bütün batch'e:

SUCCESS

demek tek problemli ürünü kaybettirir.

34. failureReasons Alanını Kaydedin

Batch içerisinde hata bulunan ürünlerde Trendyol:

failureReasons

alanının incelenebileceğini belirtiyor.

Bu bilgi fiyat update log'una yazılmalıdır.

35. Fiyat Hataları İçin Kendi Error Code'larınızı Oluşturun

Örneğin:

SOURCE_PRICE_MISSING

SOURCE_PRICE_INVALID

CURRENCY_UNKNOWN

PRICE_BELOW_FLOOR

PRICE_ABOVE_CEILING

LIST_PRICE_BELOW_SALE_PRICE

PRICE_JUMP_REVIEW

TRENDYOL_PRICE_UPDATE_FAILED

gibi.

36. Barkod Eşleşmesini Doğru Kurun

Trendyol fiyat/stok update örneğinde ürün:

barcode

ile tanımlanıyor.

Yanlış barkoda doğru fiyat gönderirseniz yanlış ürünün fiyatı değişir.

37. Supplier SKU ile Trendyol Barkodunu Karıştırmayın

Supplier SKU:

ABC-100

olabilir.

Trendyol barkodu:

869...

olabilir.

İki kimlik ayrı tutulmalıdır.

38. Varyant Fiyatlarını Ayrı Yönetebilirsiniz

Örneğin:

Siyah / 128 GB → 8.999 TL

Siyah / 256 GB → 10.499 TL.

Her barkodun maliyeti ve satış fiyatı ayrı olabilir.

39. Parent Ürün Fiyatı Üzerinden Bütün Varyantları Ezmemeye Dikkat Edin

Bir varyant maliyeti diğerinden farklıysa tek ürün ailesi fiyatını bütün barkodlara yazmak marj hatası oluşturabilir.

40. XML'deki Varyant Fiyatını Doğru SKU'ya Bağlayın

Tedarikçi:

SKU-128 → 5.000 TL

SKU-256 → 6.000 TL.

Mapping tersse Trendyol fiyatları da ters gider.

41. Fiyat Güncellemesinde Stok Göndermek Zorunda Değilsiniz

Trendyol'un güncel dokümantasyonuna göre yalnız fiyat güncellenecekse stok alanının gönderilmesi zorunlu değil.

Bu çok önemli bir ayrım.

42. 134 Bu Nedenle 133'ten Teknik Olarak Ayrılabilir

133:

quantity

durumunu yönetir.

134:

salePrice / listPrice

durumunu yönetir.

Aynı endpoint kullanılsa da state ve iş kuralları farklıdır.

43. Fiyat ve Stok Job'ları Aynı Anda Çalışmak Zorunda Değildir

Stok:

çok hızlı değişebilir.

Fiyat:

daha seyrek değişebilir.

Aynı endpoint'in kullanılması aynı update sıklığını zorunlu kılmaz.

44. Stok Güncellemesi İçin Fiyatı Tekrar Göndermeyin

Fiyat değişmedi ama stok değişti.

Gereksiz biçimde eski fiyatı request içine koymak istemeyebilirsiniz.

Trendyol diğer alanın zorunlu olmadığını açıkça belirtiyor.

45. Aynı Şekilde Fiyat İçin Stok Göndermek Gerekmeyebilir

Fiyat:

349 → 359.

Stok:

aynı.

Sadece gerekli fiyat alanları gönderilebilir.

46. Aynı Request Body'yi 15 Dakika İçinde Tekrar Göndermeyin

Trendyol güncel dokümantasyonunda aynı request body'nin değişmeden 15 dakika içerisinde tekrar gönderilmesinin hata üreteceğini söylüyor.

Retry sistemi bunu bilmeli.

47. Retry Öncesi Fiyatı Yeniden Hesaplayın

İlk request:

349 TL

başarısız oldu.

10 dakika sonra tedarikçi maliyeti değişti.

Yeni doğru fiyat:

379 TL.

Eski payload'ı tekrar göndermek yerine güncel fiyat state'i kullanılmalıdır.

48. Eski Retry Yeni Fiyatı Ezmemelidir

Örnek:

Job A → 349.

Job B → 399.

B başarılı.

A retry oldu.

A tekrar:

349

gönderirse güncel fiyat geri alınır.

49. Fiyat Güncellemelerine Version Ekleyebilirsiniz

Örneğin:

SKU X:

Price Version 501 → 349

Version 502 → 399.

Version 501 artık gönderilmemelidir.

50. Overlapping Job'lara Dikkat Edin

Fiyat sync:

20 dakika

sürüyor.

Scheduler:

10 dakikada bir

başlıyor.

İki farklı kaynak snapshot aynı barkoda farklı fiyat gönderebilir.

51. Job Versiyonu ile Feed Versiyonunu Ayırabilirsiniz

Örneğin:

Feed snapshot: SUPPLIER_18_00

Pricing job: PRICE_JOB_18_02

Trendyol batch: UUID.

Bu zincir geriye dönük incelenebilir.

52. Bir İstekte Maksimum 1.000 SKU Bulunabilir

Trendyol güncel stok/fiyat endpoint'inde tek request maksimum:

1.000 item

kabul ediyor.

Büyük fiyat değişimlerinde batch'leme gerekir.

53. 25.000 Fiyat Değişimi 25 Batch Gerektirebilir

1.000'er SKU'luk:

25 batch

örneklenebilir.

Ancak bütün batch'ler aynı pricing snapshot'a bağlanmalıdır.

54. Batch Sırası Fiyat Güncelliğini Etkilememelidir

İlk batch:

18:00 fiyatı.

Son batch:

18:25'te gönderiliyor.

Bu sırada yeni fiyat snapshot oluştuysa hangi sürümün geçerli olduğu açık olmalıdır.

55. Uzun Queue Fiyat Gecikmesi Oluşturabilir

Kaynak maliyet değişti.

Ancak Trendyol'a 45 dakika sonra ulaştı.

Bu:

price propagation delay

olarak ölçülebilir.

56. Fiyat Senkronizasyon Gecikmesini Ölçün

Örneğin:

Source changed → 18:00

Calculated → 18:01

Queued → 18:02

Sent → 18:03

Confirmed → 18:04

Toplam:

4 dakika.

Bu gerçek entegrasyon performansıdır.

57. Kritik Maliyet Artışlarını Önceliklendirebilirsiniz

Örneğin:

100 → 180 TL maliyet artışı,

satış fiyatında hızlı aksiyon gerektirebilir.

Çok küçük fiyat değişikliği daha düşük öncelikte olabilir.

Bu işletme kuralıdır.

58. Büyük Maliyet Düşüşü de Önemlidir

Tedarikçi:

200 → 150 TL

düştü.

Satış fiyatınız aynı kalabilir veya stratejiye göre değişebilir.

Fiyat entegrasyonu:

maliyet düştü → mutlaka satış fiyatını düşür

diye varsaymamalıdır.

59. Kaynak Maliyet ile Kanal Satış Fiyatı Birebir Bağlı Olmak Zorunda Değildir

Tedarikçi:

%5 maliyet düşürdü.

İşletme:

satış fiyatını koruyabilir.

Bu nedenle fiyat motoru ile channel sync ayrı katmanlardır.

60. Kampanyaları Basit XML Fiyat Güncellemesiyle Karıştırmayın

Bir üründe Trendyol kampanyası veya başka fiyat görünümü bulunabilir.

134'ün görevi sizin gönderdiğiniz:

salePrice

ve:

listPrice

değerlerini doğru yönetmektir.

Kampanya yönetimi ayrı operasyon olabilir.

61. Trendyol'da Müşterinin Gördüğü Fiyat İçin Ayrı Alan Bulunabilir

Onaylı Ürün V2 yanıtında fiyat bölümünde:

salePrice

listPrice

ve:

priceSeenByCustomer

alanları dönebiliyor.

Bu yüzden read-back sırasında hangi fiyat alanını karşılaştırdığınızı bilin.

62. priceSeenByCustomer ile salePrice Alanını Otomatik Aynı Kabul Etmeyin

Trendyol yanıtında bunlar ayrı alanlar olarak sunulabiliyor.

Reconciliation kuralınız:

gönderdiğim temel satış fiyatı mı

yoksa:

müşteriye görünen fiyat mı

kontrol ediyor,

açık olmalıdır.

63. Price Reconciliation Yapın

Örneğin:

Expected salePrice → 399,90

Last confirmed → 399,90

Trendyol read-back → 399,90.

↓

Uyumlu.

Başka ürün:

Expected → 399,90

Trendyol → 349,90.

↓

İnceleme.

64. Her Update Sonrası Read-Back Yapmak Zorunda Değilsiniz

Büyük katalogda her fiyat yazımından hemen sonra tek tek geri okuma maliyetli olabilir.

Periyodik:

• örneklem,
• riskli SKU,
• başarısız batch,
• yüksek fiyat değişimi

kontrolleri kullanılabilir.

65. Onaylı Ürün V2 Servisi Reconciliation İçin Yararlı Olabilir

Trendyol'un güncel servisinde onaylı ürünlerin fiyat yapısı okunabiliyor.

Bu channel-side doğrulama için kullanılabilir.

66. Fiyat Değişiklik Geçmişini Saklayın

Örneğin:

18:00 Supplier cost → 200

18:01 Calculated → 319,90

18:02 Sent → 319,90

18:03 Confirmed → 319,90

21:00 Supplier cost → 225

21:01 Calculated → 349,90.

Timeline hata araştırmasında çok değerlidir.

67. Değişiklik Sebebini de Saklayın

Örneğin:

SUPPLIER_COST_CHANGE

FX_CHANGE

PRICING_RULE_CHANGE

MANUAL_OVERRIDE

PROMOTION_END

MIN_MARGIN_PROTECTION

gibi.

68. Fiyat Kuralı Değişikliği Binlerce Ürünü Etkileyebilir

Maliyet değişmedi.

Ancak:

minimum marj %20 → %25

oldu.

Binlerce ürünün satış fiyatı yeniden hesaplanabilir.

Bu değişiklik feed update'ten farklıdır.

69. Kural Değişikliğinde Dry-Run Yapın

Yeni fiyat kuralı:

20.000 ürünü

etkileyecek.

Önce rapor:

Fiyat artacak → 12.500

Düşecek → 4.000

Aynı → 3.500

Anormal → 250

şeklinde üretilebilir.

70. Toplu Fiyat Artışında Dağılım Kontrolü Yapın

Örneğin bütün ürünlerde:

tam %500 artış

görülüyorsa kur veya KDV formülünde hata olabilir.

Canlıya gitmeden önce anomali kontrolü yararlıdır.

71. Fiyatı 0 Yapmayı Özel Durum Olarak Ele Alın

Kaynak:

0 TL.

Bu:

• ücretsiz ürün,
• eksik maliyet,
• veri hatası

olabilir.

Toptan ürün feed'lerinde çoğu zaman önce doğrulanması gereken bir durumdur.

72. Boş Fiyatı 0 Fiyat Saymayın

price=""

ile:

price=0

aynı değildir.

Boş alan:

SOURCE_PRICE_MISSING

olarak ele alınabilir.

73. Parse Edilemeyen Fiyatı 0'a Çevirmeyin

Örneğin:

1.250,50 TL

parse edilemiyor.

Sistemin:

0

üretmesi ürünleri çok yanlış fiyattan satışa açabilir.

74. Türkçe Ondalık ve Binlik Ayracına Dikkat Edin

Örneğin:

1.250,50

Türkiye formatında:

1250,50

olabilir.

Başka feed:

1,250.50

kullanabilir.

Format kaynağa göre belirlenmelidir.

75. Fiyat Alanını Float ile Kontrolsüz Yönetmeyin

Finansal hesaplarda binary floating-point beklenmedik kuruş farklarına yol açabilir.

Uygun decimal para yaklaşımı kullanılmalıdır.

76. Yuvarlamayı En Son Aşamada Yapın

Örneğin:

ham maliyet

↓

vergi/maliyet

↓

marj

↓

kanal fiyatı

↓

son yuvarlama

yapılabilir.

Yuvarlama kuralının detayları 115'in alanıdır.

77. Ara Aşamalarda Tekrar Tekrar Yuvarlamayın

Her matematik adımında kuruş kırpmak final fiyatı değiştirebilir.

İşletmenin belirlenmiş decimal ve rounding politikası olmalıdır.

78. Psikolojik Fiyat Sonlandırması Ayrı Kural Olabilir

Örneğin:

351,27

↓

349,90 veya 354,90

gibi ticari sonlandırmalar kullanılabilir.

Ancak bunlar evrensel doğru değildir.

Fiyat motorunun ayrı kuralıdır.

79. Minimum Marj Kontrolünü Yuvarlamadan Sonra Tekrar Yapın

Hesaplanan fiyat:

100,04.

Yuvarlama:

99,90.

Bu işlem minimum marj sınırının altına düşürebilir.

Final publish fiyatı tekrar doğrulanmalıdır.

80. Manuel Fiyat Override Desteği Bulundurun

Bir ürün özel olarak:

399 TL

satılacak.

XML sync:

429 TL

hesaplıyor.

Manual override varsa XML sync bunu sürekli ezmemelidir.

81. Manuel Override Süreli Olabilir

Örneğin:

48 saat

veya:

kampanya bitişine kadar

geçerli olabilir.

Daha sonra otomatik fiyat motoru devralabilir.

82. Override Kaynağını Saklayın

Örneğin:

AUTO_PRICING

MANUAL

CAMPAIGN

SUPPLIER_SPECIAL

gibi.

Fiyatın nereden geldiği bilinmelidir.

83. Override'ın Bitiş Tarihini Kaydedin

Süresi bitmiş manuel fiyatın aylarca açık kalması maliyet değişimlerine karşı risk oluşturur.

84. Tedarikçi Kampanya Fiyatının Süresini Bilin

Supplier:

bugün 150 TL.

Yarın tekrar:

220 TL.

Satış fiyatını 199 TL'ye düşürdüyseniz maliyet normale döndüğünde fiyatın da yeniden değerlendirilmesi gerekir.

85. Kampanyalı Maliyet ile Kalıcı Maliyeti Ayırın

Örneğin:

normal_cost

campaign_cost

ayrı tutulabilir.

Kampanya sona erdiğinde eski satış fiyatının kalması engellenebilir.

86. Birden Fazla Tedarikçide Fiyat Kaynağını Belirleyin

Supplier A → 200

Supplier B → 220.

Hangi tedarikçi aktif source?

Sadece en ucuz olan mı?

Stok ve teslimat da kriter mi?

Fiyat motoru aktif tedarik kaynağını bilmelidir.

87. Supplier Switching Fiyatı Değiştirebilir

Ana tedarikçi:

200 TL.

Tükendi.

Alternatif:

280 TL.

Ürün stoğu devam etse bile satış fiyatı eski maliyete göre kalırsa zarar edebilirsiniz.

88. Supplier Switching ile Fiyat Sync Birlikte Çalışmalıdır

Aktif fulfilment source değiştiğinde:

active_cost

yeniden hesaplanmalı.

Ardından yeni Trendyol fiyatı üretilmelidir.

89. Sadece En Ucuz Tedarikçiyi Seçmek Zorunda Değilsiniz

Ucuz kaynak:

yavaş veya güvensiz olabilir.

Fiyatlandırma ve tedarik kaynağı seçimi birbirine bağlı ancak ayrı kararlardır.

90. Fiyat Senkronizasyonunu Stok Senkronizasyonundan Ayrı İzleyin

Dashboard:

Price changed: 850

Price sent: 845

Price confirmed: 842

Price failed: 3

gibi olabilir.

Stok metriği ayrı tutulmalıdır.

91. Fiyat Uyuşmazlık Oranını Ölçün

Örneğin:

10.000 aktif SKU.

Trendyol fiyatı beklenen değerden farklı:

25 SKU.

price reconciliation mismatch = %0,25

gibi bir metrik üretilebilir.

92. Fiyat Gecikmesini Supplier Bazında Ölçün

Supplier A:

maliyet değişimi → Trendyol 3 dakika.

Supplier B:

40 dakika.

Bu fark özellikle hızlı fiyat değişen tedarikçilerde risk oluşturur.

93. Fiyat Hatası Kaynağını Ayrıştırın

Problem:

supplier source

parser

currency

pricing engine

rounding

mapping

Trendyol API

katmanlarından hangisinde?

Hepsine:

fiyat hatası

demek kök nedeni gizler.

94. Rule Version Saklayın

Örneğin:

PRICE_RULE_V12

kullanıldı.

Daha sonra:

PRICE_RULE_V13

geçti.

Bir fiyatın hangi formülle hesaplandığı geriye dönük görülebilir.

95. 14 Eylül 2026 Rate Limit Değişikliğini Şimdiden Hesaba Katın

Trendyol, 14 Eylül 2026 itibarıyla Inventory & Price Write grubuna yeni limitler getiriyor. Ürün listeleme seviyesine göre dakikada 350, 500, 1.000, 1.500 veya 2.000 istek sınırları yayımlanmış durumda.

96. Bugünkü “NO LIMIT” Durumuna Kalıcı Mimari Kurmayın

23 Ağustos 2026 itibarıyla mevcut tabloda Stok ve Fiyat Güncelleme servisi:

NO LIMIT

görünüyor.

Fakat bu durum 14 Eylül'de değişecek.

Queue ve throttling sistemi yeni limite hazırlıklı olmalıdır.

97. Rate Limit'i Hard-Code Etmeyin

Bugünkü:

350 req/min

gelecekte değişebilir.

Entegrasyon güncel dokümantasyon veya yapılandırma üzerinden yönetilebilir.

98. Queue Backlog Alarmı Kurun

100.000 ürünün fiyatı değişti.

Queue işleyemiyor.

İki saatlik backlog oluştu.

Eski fiyatlar Trendyol'da kalabilir.

Bu ticari bir risktir.

99. Fiyat Senkronizasyon Sağlığını Tek Bir Metrikle Ölçmeyin

Birlikte izlenebilecekler:

• source freshness,
• calculation success,
• price-change count,
• queue latency,
• API failure,
• batch failure,
• reconciliation mismatch,
• below-floor blocks,
• abnormal price jumps.

100. Trendyol XML Fiyat Güncellemesinin Amacı XML'deki Sayıyı Kopyalamak Değil, Doğru Ticari Fiyatı Doğru Barkoda Doğru Zamanda Uygulamaktır

134'ün ana mesajı budur.

Kaynak XML:

200 TL

gösteriyor.

Ama:

Trendyol salePrice = 349,90 TL

olması bilinçli biçimde doğru olabilir.

Çünkü 200 TL:

tedarik maliyetidir.

Asıl hata:

hesaplanan doğru fiyat:

349,90

olduğu halde Trendyol'da:

299,90

kalmasıdır.

Dolayısıyla fiyat senkronizasyonu:

aynı sayı

değil,

aynı fiyat state'inin korunması

problemidir.

TRENDYOL XML FİYAT GÜNCELLEME KONTROL LİSTESİ

Kaynak fiyat

XML alanının gerçek anlamı biliniyor mu?

Ham veri

Orijinal kaynak fiyat saklanıyor mu?

KDV

Dahil/hariç bilgisi doğru mu?

Para birimi

TRY/USD/EUR açık mı?

Kur

Kullanılıyorsa kaynak ve zamanı kayıtlı mı?

Maliyet

Normalize edilmiş gerçek maliyet hesaplanıyor mu?

Fiyat kuralı

İşletme pricing engine'i uygulanıyor mu?

Minimum fiyat

Zarar ettiren fiyat engelleniyor mu?

Maksimum/anomali

Aşırı fiyat artışı kontrol ediliyor mu?

Yuvarlama

Final fiyat kuralı tutarlı mı?

Barkod

Doğru Trendyol ürünü hedefleniyor mu?

Varyant

Her barkod ayrı fiyatlanabiliyor mu?

salePrice

Gerçek Trendyol satış fiyatı doğru mu?

listPrice

Liste fiyatının anlamı doğru mu?

Fiyat ilişkisi

listPrice >= salePrice kontrol ediliyor mu?

Delta

Değişmeyen fiyat tekrar gönderiliyor mu?

last_calculated

Son hesaplanan fiyat tutuluyor mu?

last_sent

API'ye gönderilen son fiyat tutuluyor mu?

last_confirmed

Başarıyla uygulanan son fiyat ayrı mı?

Batch

batchRequestId kayıtlı mı?

Batch result

İşlem sonucu kontrol ediliyor mu?

Item result

SKU bazında başarısızlık görülebiliyor mu?

failureReasons

Hata nedeni saklanıyor mu?

Retry

Eski fiyat tekrar gönderilebiliyor mu?

Version

Yeni fiyat eski job tarafından eziliyor mu?

1.000 SKU

Batch sınırı uygulanıyor mu?

Queue

Fiyat değişiklikleri beklemede kalıyor mu?

Rate limit

14 Eylül 2026 değişikliği hesaba katıldı mı?

Feed freshness

Kaynak fiyatın yaşı biliniyor mu?

Supplier switching

Aktif tedarikçi değişince maliyet yeniden hesaplanıyor mu?

Campaign cost

Geçici maliyet ayrı tutuluyor mu?

Manual override

XML manuel fiyatı eziyor mu?

Override expiry

Manuel fiyatın bitiş koşulu var mı?

Read-back

Trendyol'daki fiyat gerektiğinde geri okunuyor mu?

Reconciliation

Expected ve Trendyol fiyatı karşılaştırılıyor mu?

Audit

Fiyatın neden değiştiği görülebiliyor mu?

Rule version

Hangi fiyatlandırma kuralı kullanıldığı kayıtlı mı?

Metrics

Sync latency ve mismatch oranı ölçülüyor mu?

TRENDYOL XML FİYAT GÜNCELLEMESİ NASIL KURULUR? 20 ADIM

1. XML'deki fiyat alanının alış, bayi, liste veya satış fiyatı olup olmadığını doğrulayın.

2. Fiyatın KDV durumunu ve para birimini belirleyin.

3. Ham tedarikçi fiyatını değiştirmeden saklayın.

4. Gerekliyse kur dönüşümüyle normalize edilmiş maliyet üretin.

5. İşletmenin fiyatlandırma kuralını uygulayın.

6. Kargo, platform ve diğer gerçek maliyetleri fiyat motorunuzda hesaba katın.

7. Minimum güvenli satış fiyatını kontrol edin.

8. Final fiyat yuvarlama kuralını uygulayın.

9. Trendyol salePrice ve gerekiyorsa listPrice değerlerini oluşturun.

10. listPrice >= salePrice doğrulamasını gerçekleştirin.

11. Internal SKU ile doğru Trendyol barkodu eşleştirmesini kontrol edin.

12. Yeni hesaplanan fiyatı son başarıyla onaylanmış fiyatla karşılaştırın.

13. Yalnız değişen fiyatları update kuyruğuna ekleyin.

14. Ürünleri maksimum 1.000 SKU'luk request'lere bölün.

15. Yalnız fiyat değişiyorsa gereksiz stok alanlarını göndermeyin.

16. updatePriceAndInventory isteğinden dönen batchRequestId değerini kaydedin.

17. Batch sonucunu kontrol ederek her barkod için success/failure durumunu işleyin.

18. Retry öncesinde fiyatın hâlâ en güncel price version olduğunu doğrulayın.

19. Onaylı Ürün V2 üzerinden belirli aralıklarla Trendyol fiyatlarını geri okuyup reconciliation yapın.

20. Kaynak fiyat yaşı, fiyat değişim gecikmesi, API/batch başarısızlığı ve fiyat uyuşmazlık oranlarını düzenli takip edin.

SIK SORULAN SORULAR

Trendyol XML fiyat güncellemesi nasıl çalışır?

Tedarikçi veya şirket sistemindeki fiyat önce işletmenin fiyatlandırma kurallarına göre Trendyol satış fiyatına dönüştürülür. Değişiklik varsa doğru barkod için salePrice ve gerektiğinde listPrice stok/fiyat güncelleme servisine gönderilir. Servis asenkron çalıştığından dönen batchRequestId daha sonra kontrol edilmelidir.

XML'deki fiyatı doğrudan Trendyol'a göndermeli miyim?

Genellikle kaynak alanın anlamını doğrulamadan hayır. XML fiyatı alış maliyeti, bayi fiyatı veya başka bir fiyat türü olabilir. Önce KDV, para birimi ve fiyat türü doğrulanmalı; ardından işletmenin satış fiyatı kuralı uygulanmalıdır.

Trendyol'da salePrice ile listPrice arasındaki fark nedir?

Trendyol güncel dokümantasyonunda salePrice ürünün satış fiyatı, listPrice ise satış fiyatı daha düşük olduğunda üzeri çizilen liste fiyatı olarak tanımlanıyor. Product V2 kurallarında listPrice değerinin salePrice değerinden düşük olamayacağı belirtiliyor.

Sadece fiyat değiştiğinde stok bilgisini de göndermem gerekir mi?

Hayır. Trendyol güncel stok ve fiyat güncelleme dokümantasyonunda yalnız stok veya yalnız fiyat değiştiğinde diğer alanın gönderilmesinin zorunlu olmadığını belirtiyor.

Fiyat API'ye gönderildiğinde hemen başarılı sayılır mı?

Hayır. Başarılı istek sonucunda batchRequestId dönmesi isteğin kuyruğa alındığını gösterir. Trendyol işlemin durumunun toplu işlem kontrolü servisi üzerinden takip edilmesini, hata bulunan ürünlerde failureReasons alanının incelenmesini istiyor.

TRENDYOL FİYAT SENKRONİZASYONUNDA EN TEHLİKELİ HATALARDAN BİRİ ESKİ MALİYETTEN HESAPLANMIŞ FİYATIN DAHA YENİ FİYATI EZMESİDİR

Örneğin:

18:00

Supplier maliyet → 200 TL.

Pricing engine:

349,90 TL

hesapladı.

Trendyol:

349,90 TL.

18:05

Supplier maliyet:

250 TL

oldu.

Yeni güvenli satış fiyatı:

419,90 TL

hesaplandı.

Yeni update gönderildi.

18:06

Trendyol:

419,90 TL.

Ancak 18:00 job'ına ait eski request:

retry kuyruğunda

bekliyor.

18:10

Eski job tekrar:

349,90 TL

gönderiyor.

Sonuç:

güncel fiyat:

419,90 → 349,90

geriliyor.

Bu stok senkronizasyonundaki eski snapshot problemine çok benzer.

Çözüm:

price version

kullanmaktır.

Örneğin:

Version 500

Maliyet → 200

Satış → 349,90

Version 501

Maliyet → 250

Satış → 419,90

Version 501 oluşturulduktan sonra:

Version 500 retry edilmemelidir.

Bu yüzden:

“API başarısız oldu, aynı isteği tekrar gönder”

yaklaşımı yeterli değildir.

Daha doğru soru:

“Başarısız olan istekteki fiyat hâlâ güncel fiyat mı?”

olmalıdır.

134'ün temel prensibi:

Fiyat güncellemesinde yalnız fiyat değerini değil, fiyatın kaynağını, kuralını, sürümünü ve uygulama durumunu yönetin.