Bir tedarikçi XML'inde ürünün stoğu:

10

görünüyor.

Entegrasyon bu değeri Trendyol'a gönderiyor.

Trendyol mağazasında da:

10 adet

satılabilir stok oluşuyor.

Buraya kadar sistem basit görünür.

Fakat ardından müşteriden:

1 adet sipariş

geliyor.

Trendyol stok miktarını azaltıyor.

Bu sırada tedarikçinin XML'i henüz değişmediyse kaynak feed hâlâ:

10

gösterebilir.

Entegrasyon birkaç dakika sonra XML'i tekrar okuyup:

quantity = 10

gönderirse ne olur?

Trendyol dokümantasyonuna göre quantity alanında gönderilen değer satılabilir stok bilgisidir ve bu bilgi sipariş geldiğinde veya satıcı tarafından yeniden stok gönderildiğinde güncellenir.

Dolayısıyla entegrasyonun eski XML snapshot'ını yeniden göndermesi:

sipariş nedeniyle azalmış stoğu tekrar yükseltme

riski oluşturabilir.

İşte gerçek stok senkronizasyonu problemi burada başlar.

Doğru sistem yalnız:

XML stoğunu oku → Trendyol'a gönder

değildir.

Daha güvenli model:

kaynak stok

↓

kaynağın güncellik kontrolü

↓

ürün kimliği eşleştirmesi

↓

stok iş kuralları

↓

satılabilir stok

↓

son gönderilen stokla karşılaştırma

↓

yalnız değişen SKU'lar

↓

Trendyol stok güncelleme isteği

↓

batchRequestId

↓

işlem sonucu

↓

gerektiğinde Trendyol'daki gerçek stokla reconciliation

şeklinde kurulmalıdır.

Ulu İthalat'ın mevcut XML Bayilik sayfasında da stoksuz satışta ürünün stok ve fiyat bilgilerinin güncel tutulmasının, stokta olmayan ürünlerin satışa açık kalmasını azaltmak açısından önemli olduğu belirtiliyor.

1. Stok Senkronizasyonu Nedir?

Stok senkronizasyonu, aynı fiziksel ürünün farklı sistemlerdeki satılabilir miktarının birbirine mümkün olduğunca uyumlu tutulmasıdır.

Bu sistemlerden bazıları:

tedarikçi

depo

ERP

e-ticaret sitesi

Trendyol

diğer pazaryerleri

olabilir.

2. XML'deki Stok ile Trendyol Stoğu Aynı Kavram Olmak Zorunda Değildir

XML:

stock = 20

gönderiyor olabilir.

Bu:

tedarikçinin fiziksel stok adedi

olabilir.

Trendyol'a göndermek istediğiniz sayı ise:

satılabilir stok

olmalıdır.

Trendyol da quantity alanını doğrudan satılabilir stok olarak tanımlıyor.

3. Önce Kaynak Stoğun Ne Anlama Geldiğini Öğrenin

Tedarikçide:

stock = 5

alanı:

• fiziksel stok,
• kullanılabilir stok,
• depo toplamı,
• bayi için ayrılmış stok

olabilir.

Alan anlamını tahmin etmeyin.

4. XML'deki Stok Alanını Doğru Map Edin

Örneğin XML'de:

urun_stok

gerçek stok olabilir.

Ama:

koli_adedi

başka bir alan olabilir.

Koli miktarını stok sanmak:

1 stok → 100 stok

gibi ciddi hatalara yol açabilir.

5. Ham Stok Değerini Saklayın

Örneğin:

raw_supplier_stock = 12

olarak saklanabilir.

Ardından hesaplanan:

sellable_stock = 8

ayrı tutulabilir.

Böylece:

Tedarikçi ne gönderdi?

ve:

Biz Trendyol'a ne gönderdik?

soruları ayrı cevaplanır.

6. Kaynak Stok ile Satılabilir Stoğu Ayırın

Örnek:

Kaynak stok → 10

Güvenlik tamponu → 2

Satılabilir stok → 8

Bu yalnız örnek bir modeldir.

Evrensel olarak her üründe 2 adet düşülmesi gerektiği anlamına gelmez.

7. Satılabilir Stok İçin İş Kuralı Oluşturabilirsiniz

Örnek formül:

Satılabilir Stok = Kaynak Stok - Güvenlik Payı

Daha karmaşık yapılarda:

Kaynak stok

− rezervasyonlar

− satılamayan miktar

− güvenlik payı

şeklinde hesap yapılabilir.

Ancak aynı stoğu iki kez düşmemeye dikkat edilmelidir.

8. Trendyol'a Kaynak Stoğu Körü Körüne Göndermeyin

Tedarikçide:

100

stok bulunması:

Trendyol'a mutlaka:

100

göndermeniz gerektiği anlamına gelmez.

Aynı stok:

• kendi sitenizde,
• Trendyol'da,
• başka pazaryerinde

satılıyor olabilir.

9. Çoklu Kanalda Stok Paylaştırması Düşünebilirsiniz

Örneğin:

Kaynak stok → 20.

Kendi site → 8.

Trendyol → 8.

Diğer kanal → 4.

Bu yalnız örnektir.

Alternatif olarak merkezi stok havuzu ve hızlı senkronizasyon da kullanılabilir.

10. Aynı 20 Stoğu Her Kanala 20 Olarak Açmanın Riskini Anlayın

Kaynak:

Site:

Trendyol:

Pazaryeri B:

Teorik görünür satış kapasitesi:

60

olur.

Fiziksel kaynak ise hâlâ:

Bu overselling riskidir.

11. Tek Kaynak Gerçeği Belirleyin

Sisteminizde:

stok konusunda son söz kimde?

belirlenmelidir.

Bu:

• tedarikçi ERP,
• kendi ERP'niz,
• kendi depo sisteminiz,
• merkezi inventory service

olabilir.

Buna genellikle:

source of truth

denir.

12. Trendyol Her Zaman Ana Stok Kaynağı Olmak Zorunda Değildir

Dropshipping modelinde ana kaynak:

tedarikçi

olabilir.

Kendi stoklu işletmenizde:

ERP veya depo

olabilir.

Trendyol ise çoğu mimaride satış kanalı rolündedir.

13. Trendyol'daki Stok Yine de İzlenmelidir

Ana kaynak olmasa bile:

Trendyol'da şu an kaç stok görünüyor?

sorusunu bilmek önemlidir.

Çünkü kaynak ve hedef zaman içinde ayrışabilir.

14. Trendyol V2 Onaylı Ürün Servisi Stok Bilgisini Döndürebiliyor

Güncel Onaylı Ürün V2 yanıt yapısında varyant seviyesinde:

stock.quantity

ve stok için:

lastModifiedDate

bilgileri bulunuyor.

Bu bilgiler periyodik reconciliation için kullanılabilir.

15. Reconciliation Nedir?

Reconciliation:

bizim sistemimizde olması gereken stok

ile:

Trendyol'da gerçekten görünen stok

arasındaki farkın kontrol edilmesidir.

Örneğin:

Expected → 8

Trendyol → 5

Difference → -3.

Bu kayıt incelenebilir.

16. Her Senkronizasyonda Bütün Trendyol Kataloğunu Geri Okumak Zorunda Değilsiniz

Büyük kataloglarda:

her stok yazımından sonra bütün ürünleri tekrar sorgulamak

gereksiz yük oluşturabilir.

Bunun yerine:

• problemli SKU,
• örneklem,
• belirli zaman aralığı,
• periyodik reconciliation

kullanılabilir.

17. Trendyol Sipariş Sonrasında Stoğu Değiştirebilir

Trendyol dokümantasyonuna göre satılabilir stok bilgisi sipariş alındığında değişir.

Bu bilgi entegrasyon mimarisinde kritik öneme sahiptir.

18. Sipariş Sonrası Eski XML Değeri Stoğu Tekrar Yükseltebilir

Örnek:

Supplier XML → 10

Trendyol → 10

Sipariş → 1

Trendyol → 9

Supplier XML henüz → 10

Entegrasyon yeniden → 10

Bu durumda kaynak verinin güncellik gecikmesi satış kanalındaki azaltımı geri çevirebilir.

19. Bu Soruna “Stale Stock Overwrite” Gözüyle Bakabilirsiniz

Yani:

eski kaynak snapshot'ının daha yeni stok durumunun üzerine yazılması.

Sorun yalnız:

güncelleme sıklığı

değildir.

Aynı zamanda:

hangi veri daha yeni?

sorusudur.

20. Her Stok Kaydına Zaman Bilgisi Ekleyin

Örneğin:

source_updated_at

feed_fetched_at

parsed_at

calculated_at

sent_to_trendyol_at

confirmed_at

ayrı tutulabilir.

Böylece verinin yaşı takip edilir.

21. Feed İndirme Zamanı ile Kaynak Verinin Oluşturulma Zamanını Karıştırmayın

XML'i:

18:00'de

indirdiniz.

Ancak feed:

16:00 verisini

içeriyor olabilir.

Dolayısıyla:

downloaded_at

ile:

source_snapshot_at

aynı şey değildir.

Kaynak zaman bilgisi mevcutsa ayrıca kullanılmalıdır.

22. Kaynak Zaman Bilgisi Yoksa Daha Temkinli Olun

Tedarikçi feed'i timestamp vermiyorsa:

stok ne kadar taze?

sorusunu doğrudan bilemezsiniz.

Bu durumda feed üretim davranışı ve geçmiş değişim süreleri izlenebilir.

23. Siparişin Tedarikçiye Ne Zaman Yansıdığı Önemlidir

Trendyol'da sipariş geldi.

Tedarikçi henüz bunu bilmiyor olabilir.

Dolayısıyla tedarikçi XML'i eski miktarı göstermeye devam edebilir.

Siparişin tedarikçiye aktarılması ile sonraki XML snapshot arasında geçici tutarsızlık oluşabilir.

24. Dropshipping'de Bu Geçiş Penceresini Yönetmek Gerekir

Örneğin:

Trendyol siparişi → 17:01

Supplier order → 17:02

Supplier XML refresh → 17:15.

17:01–17:15 arasında kaynak feed henüz siparişi yansıtmıyor olabilir.

Bu örnek mimariyi anlatmak içindir; gerçek süre tedarikçiye göre değişir.

25. Lokal Rezervasyon Kullanılabilir

Sipariş geldiğinde sistem:

pending_supplier_reservation = 1

tutabilir.

Supplier feed henüz azalmasa bile satılabilir stok hesaplamasında bu rezervasyon düşülebilir.

26. Ancak Rezervasyonu Sonsuza Kadar Düşmeyin

Tedarikçinin XML'i siparişi daha sonra yansıttı.

Kaynak:

10 → 9

oldu.

Siz hâlâ ayrıca:

1 rezervasyon

düşerseniz:

8

hesaplarsınız.

Bu kez double subtraction oluşur.

27. Rezervasyonun Yaşam Döngüsü Olmalıdır

Örneğin:

CREATED

SENT_TO_SUPPLIER

ACKNOWLEDGED

REFLECTED_IN_SOURCE

RELEASED

gibi durumlar kullanılabilir.

Bu mimari işletmenin sistemine göre değişebilir.

28. Supplier Feed Siparişi Yansıttığında Rezervasyonu Kapatın

Önemli olan:

aynı satışı hem source stock değişiminde hem local reservation'da iki kez saymamak.

Bu özellikle dropshipping stok senkronizasyonunun en zor noktalarından biridir.

29. Kendi Stoklu Modelde Mimari Daha Farklı Olabilir

Ürün sizin deponuzdaysa:

ana stok ERP'de tutulabilir.

Trendyol siparişi:

ERP stoğunu azaltır.

Sonra ERP'deki yeni satılabilir stok bütün kanallara dağıtılır.

Bu durumda supplier XML rezervasyon problemi olmayabilir.

30. Hibrit Stokta Kaynakları Ayrı Tutun

Örneğin:

Kendi depo → 4.

Tedarikçi → 10.

Toplam teorik → 14.

Ancak:

tedarikçi ürünü iki günde,

kendi depo aynı gün

gönderiyor olabilir.

İki stoğu sadece toplayıp tek quantity yapmak teslimat operasyonunu yanlış temsil edebilir.

31. Stok Kaynağı ile Teslimat Yeteneğini Birlikte Düşünün

Stok:

var.

Ama ürün:

5 gün sonra sevk edilebiliyor.

Bu durumda:

quantity > 0

tek başına satışa açmak için yeterli karar olmayabilir.

32. Stok Eşiği Kullanabilirsiniz

Kaynak:

1

ise:

0 satılabilir stok

üretmek isteyebilirsiniz.

Kaynak:

20

ise:

18

gibi.

Bu işin detayları ayrı XML Stok Eşiği içeriğinin konusudur.

133'te yalnızca hesaplanan son satılabilir stok Trendyol'a nasıl senkronize edilir sorusu ele alınmalıdır.

33. Gerçek Sıfır ile Hata Sıfırını Ayırın

XML:

stock = 0

gerçek bir stok değeri olabilir.

XML:

stock = ""

aynı şey değildir.

Feed indirilemedi:

bu da stok 0 değildir.

Parser hata verdi:

bu da stok 0 değildir.

34. Feed Kesildi Diye Bütün Trendyol Stoklarını Otomatik 0 Yapmayın

Bu çok riskli olabilir.

Feed'in erişilememesi:

tedarikçinin bütün ürünleri tükendi

demek değildir.

Burada ayrı outage/freshness politikası gerekir.

35. Ancak Eski Stokları Sonsuza Kadar Açık Bırakmak da Güvenli Değildir

Feed:

3 gündür

gelmiyor.

Son bilinen stokları satmaya devam etmek overselling riskini yükseltebilir.

Bu nedenle:

freshness timeout

gibi işletme politikaları düşünülebilir.

36. Freshness Timeout Evrensel Bir Sayı Değildir

Bazı tedarikçi feed'leri:

saatlik.

Bazıları:

günlük.

Dolayısıyla:

2 saat geçtiyse kapat

bütün sistemler için doğru değildir.

110 numaralı güncelleme sıklığı içeriği bu konuyu daha derin ele alır.

37. SKU XML'den Kaybolduğunda Hemen Stok 0 Varsaymayın

Bugünkü feed:

10.000 ürün.

Dünkü:

12.000.

2.000 ürün gerçekten kaldırılmış olabilir.

Ama feed eksik üretilmiş de olabilir.

Önce toplu değişimin nedeni kontrol edilmelidir.

38. “Missing Product” Durumu Oluşturun

Örneğin:

SOURCE_PRODUCT_MISSING

ürün XML'de bulunamadığında kullanılabilir.

Bu:

STOCK_ZERO

ile aynı durum olmamalıdır.

39. Tek SKU Kaybolması ile Binlerce SKU Kaybolmasını Farklı Değerlendirin

1 ürün kayboldu:

ürün kaldırılmış olabilir.

5.000 ürün kayboldu:

feed sorunu ihtimali çok daha yüksektir.

Toplu oran alarmı kullanılabilir.

40. Kaynak Ürün Sayısındaki Ani Düşüşleri İzleyin

Dün:

20.000 ürün.

Bugün:

4.000.

Bütün kayıp ürünleri 0'a çekmeden önce feed integrity kontrolü yapılmalıdır.

Bu, 116 numaralı yanlış stok sıfırlama içeriğiyle bağlantılıdır.

41. Trendyol Stok Güncellemesi Barkod Üzerinden Yapılıyor

Güncel updatePriceAndInventory örnek payload'ında ürün:

barcode

ile tanımlanıyor ve yanında quantity gönderiliyor.

Dolayısıyla internal SKU → Trendyol barcode eşleşmesi doğru olmalıdır.

42. Supplier SKU'yu Trendyol Barkodu Sanmayın

Supplier SKU:

ABC-152

olabilir.

Trendyol'daki ürünün barkodu:

başka değer

olabilir.

Yanlış kimlikle stock update yapılmamalıdır.

43. Varyant Bazında Stok Eşleştirmesi Yapın

Ürün:

Siyah / M → 10.

Siyah / L → 0.

Beyaz / M → 5.

Her varyant doğru Trendyol barkoduna bağlanmalıdır.

Parent seviyesinde tek stok kullanmak yanlış miktar üretebilir.

44. Aynı Barkodun İki Internal SKU'ya Bağlanmasını Kontrol Edin

Mapping tablosunda:

SKU A → barcode X

SKU B → barcode X

varsa bu bilinçli değilse ciddi stok çakışması oluşturabilir.

45. Barkod Mapping Değişikliklerini Audit Edin

Dün:

SKU A → Barcode X.

Bugün:

SKU A → Barcode Y.

Stok güncellemesi artık başka ürüne gidebilir.

Bu nedenle kimlik değişikliği sessiz yapılmamalıdır.

46. Her Feed Okumada Bütün Stokları Tekrar Göndermeyin

Trendyol güncel dokümantasyonu özellikle:

yalnız değişen stok ve fiyatların gönderilmesini

istiyor. Aynı request body'nin 15 dakika boyunca tekrarlanması hata oluşturabiliyor.

Bu nedenle delta sync daha doğru modeldir.

47. Delta Sync Nedir?

Önceki gönderilen değer:

Yeni hesaplanan:

↓

Gönderme.

Yeni hesaplanan:

↓

Gönder.

Böylece gereksiz request sayısı azalır.

48. last_sent_stock Tutun

Örneğin:

calculated_stock = 8

last_sent_stock = 8

ise işlem gerekmeyebilir.

Ancak last_sent:

Trendyol tarafından başarıyla kabul edildi

anlamına gelmemelidir.

49. last_sent ile last_confirmed Ayrı Olmalıdır

Örneğin:

last_sent_stock = 5

ama batch:

FAILED.

Bu durumda:

last_confirmed_stock

hâlâ 7 olabilir.

İki alanın ayrılması önemlidir.

50. Trendyol İsteğinin 200 Dönmesi Nihai Başarı Değildir

Güncel servis isteği başarılı olduğunda:

batchRequestId

dönüyor.

Trendyol, işlem sonucunun getBatchRequestResult üzerinden kontrol edilmesini açıkça istiyor.

51. Batch Sonucu Kontrol Edilmeden “Stok Güncellendi” Demeyin

Daha doğru durumlar:

QUEUED

SUCCESS

FAILED

PARTIAL

gibi tutulabilir.

52. Item Bazlı Hataları Kontrol Edin

Batch içerisinde:

1.000 SKU

olabilir.

999 başarılı,

1 başarısız

olabilir.

Batch'i yalnız genel seviyede başarılı saymak bu tek SKU'yu kaçırabilir.

53. failureReasons Bilgisini Saklayın

Trendyol toplu işlem sonucunda item bazında hata varsa failureReasons alanından sebebin görülebileceğini belirtiyor.

Bu bilgi stok senkronizasyon log'una eklenmelidir.

54. Maksimum 1.000 SKU Kuralını Batch Tasarımına Ekleyin

Trendyol'un güncel stok/fiyat servisi tek request içinde maksimum:

1.000 item

kabul ediyor.

Örneğin 12.500 değişen SKU varsa işlemler bölünmelidir.

55. 12.500 SKU İçin 13 Batch Oluşturulabilir

Örneğin:

12 × 1.000

1 × 500

şeklinde.

Ancak bütün batch'lerin kaynak snapshot/version bilgisi aynı tutulmalıdır.

56. Batch'e Kaynak Sürüm Kimliği Ekleyin

Kendi sisteminizde:

STOCK_SYNC_20260823_183000

gibi internal job ID kullanılabilir.

Her Trendyol batchRequestId bu job'a bağlanabilir.

57. Eski Sync Job'ın Yeni Sync'i Ezmesini Önleyin

Örneğin:

Job A → kaynak stok 10.

Job B → kaynak stok 5.

B daha yeni.

Sistem A'nın geç kalan işlemini yeniden çalıştırıp:

10

göndermemelidir.

58. Stok Güncellemelerini Versiyonlayabilirsiniz

Örneğin:

SKU X:

Version 100 → 10 stok

Version 101 → 5 stok.

Version 100 işi geç kaldıysa gönderilmemelidir.

Bu local entegrasyon tarafında uygulanabilecek koruma yöntemidir.

59. Overlapping Job'ları Kontrol Edin

Bir stok sync job'ı:

20 dakika

sürüyor.

Scheduler:

10 dakikada bir

yeni job başlatıyor.

İki job aynı SKU'ları farklı snapshotlarla işleyebilir.

Bu yarış koşulu oluşturabilir.

60. Scheduler ile Stock Sync'i Aynı Konu Sanmayın

117:

job ne zaman ve hangi sırada çalışacak?

133:

çalışan job hangi stok durumunu Trendyol'a gönderecek ve sonucu nasıl doğrulayacak?

Bu ayrım korunmalıdır.

61. Aynı Request'i Kör Retry Etmeyin

Trendyol aynı request body'nin değişiklik olmadan 15 dakika içinde yeniden gönderilmesi durumunda hata döndürebileceğini belirtiyor.

Dolayısıyla retry sistemi platform kuralını dikkate almalıdır.

62. Retry Sebebine Göre Davranın

Örneğin:

401 → kimlik bilgisi problemi olabilir.

400 → request veya parametre problemi olabilir.

500 → geçici servis problemi olabilir.

Trendyol güncel reference sayfasında bu cevap türlerini ayrı açıklıyor.

Her hata sonsuz retry edilmemelidir.

63. Geçici Hatalarda Backoff Kullanılabilir

Örneğin:

hemen arka arkaya:

100 tekrar

yerine artan bekleme süreleri uygulanabilir.

Bu genel entegrasyon dayanıklılığı prensibidir.

64. Retry'da Stok Değerinin Hâlâ Güncel Olduğunu Kontrol Edin

İlk request:

quantity = 10.

10 dakika sonra retry yapılacak.

Bu sırada gerçek stok:

5

olmuş olabilir.

Eski payload'ı yeniden göndermek yerine son state kontrol edilmelidir.

65. Retry Queue'yu Normal Sync'ten Ayırın

Normal sync:

en güncel stokları üretir.

Retry:

başarısız eski işlemleri tekrar çalıştırır.

İki kuyruğun aynı SKU üzerinde çatışmaması gerekir.

66. Eski Retry Yeni Stock Version'ı Ezmemelidir

SKU:

başarısız eski request → 20.

Yeni başarılı calculation → 5.

Retry kuyruğu daha sonra:

20

gönderirse stok yanlış yükselir.

Retry öncesi version kontrolü bu yüzden önemlidir.

67. Stok 0 Güncellemesini Yüksek Öncelikli İşleyebilirsiniz

Bir ürün gerçekten tükendiyse:

10 → 0

değişikliği ticari olarak önemlidir.

0 → 10

de önemlidir.

Ancak yanlış sıfırlamayı önleyecek validation yine yapılmalıdır.

68. Çok Büyük Stok Değişikliklerini Alarm Olarak İşaretleyin

Örneğin:

10 → 9

normal.

10 → 10.000

şüpheli olabilir.

Ürün bazında:

stock jump

kontrolü yapılabilir.

69. Trendyol'un Ürün Başına Stok Üst Limitini Dikkate Alın

Güncel dokümantasyonda ürün başına maksimum:

20.000 adet

stok gönderilebildiği belirtiliyor.

Kaynak değeri daha yüksekse sistemin nasıl davranacağı önceden belirlenmelidir.

70. Limiti Sessizce Yanlış Bir Değere Çevirmeyin

Supplier:

100.000

gönderiyor.

Trendyol maksimum:

20.000.

Sistem:

20.000 gönder + log

gibi kontrollü davranabilir.

Ancak bunu yapıyorsa:

source stock = 100.000

ile:

channel stock = 20.000

ayrı tutulmalıdır.

71. Negatif Stok Değerini Normal Kabul Etmeyin

XML:

-5

gönderiyorsa bu:

• kaynak hata,
• rezervasyon modeli,
• ERP davranışı

olabilir.

Ham değer saklanıp iş kuralıyla değerlendirilmelidir.

72. Parse Edilemeyen Stoğu 0'a Çevirmeyin

XML:

stock = ABC

geldi.

En kolay kod:

parse olmazsa 0.

Bu binlerce ürünü yanlışlıkla kapatabilir.

Daha doğru durum:

INVALID_STOCK_VALUE

olabilir.

73. Boş Stok Alanını da Otomatik Sıfır Saymayın

""

null

alan yok

ve:

0

aynı değildir.

Bu ayrım 100 ve 116 numaralı içeriklerle bağlantılıdır.

74. Boolean Stok Alanlarında Dönüşüm Kuralını Belirleyin

Bazı tedarikçi feed'lerinde:

in_stock = true

olabilir.

Bu quantity değildir.

true → 100

gibi keyfi bir sayı üretilmemelidir.

İşletme politikası açık olmalıdır.

75. “Var/Yok” Tedarikçi Feed'inde Güvenli Kanal Stoğu Belirlenebilir

Örneğin işletme:

true → 3

false → 0

kuralı kullanabilir.

Bu yalnız örnektir.

Neden 3 seçildiği ticari risk modeline dayanmalıdır.

76. Çoklu Depoda Toplama Kuralını Kontrol Edin

Supplier XML:

İstanbul → 5

Ankara → 10.

Toplam:

15

olabilir.

Ancak her iki depo da müşteriye aynı hizmet seviyesinde gönderebiliyor mu?

Bu doğrulanmalıdır.

77. Rezerve Stokları Kullanılabilir Stoktan Ayırın

Depoda:

10 fiziksel ürün.

3 sipariş için ayrılmış.

Gerçek kullanılabilir:

Kaynak ERP zaten:

7

gönderiyorsa tekrar 3 düşmeyin.

78. Kaynak Alanın “Available” mı “On Hand” mı Olduğunu Öğrenin

On hand: fiziksel adet.

Available: rezervasyonlardan sonra kullanılabilir adet.

Bu ayrım stok formülünü tamamen değiştirebilir.

79. Trendyol Siparişlerinin Ana Stok Sistemine Hızlı Dönmesini Sağlayın

Trendyol'da satış gerçekleşti.

Bu satış:

ana inventory sistemine

ne kadar hızlı ulaşırsa diğer kanallardaki overselling riski o kadar azalabilir.

80. Sipariş Entegrasyonu ile Stok Entegrasyonunu Birlikte Düşünün

Stok Trendyol'a gider.

Sipariş Trendyol'dan geri gelir.

İyi mimari:

stock outbound

ve:

order inbound

akışlarını birbirine bağlar.

Trendyol da API entegrasyonunun ürün aktarımı, stok-fiyat güncellemesi ve sipariş işlemlerini birlikte desteklediğini açıklıyor.

81. Sipariş Çekme Kesintileri İçin Reconciliation Mekanizması Bulundurun

Trendyol'un 22 Nisan 2026 tarihli changelog kaydında bazı satıcıların sipariş paketlerini entegrasyon üzerinden çekerken geçici hata yaşadığı ve ilgili dönemdeki siparişlerin sonradan kontrol edilmesinin tavsiye edildiği görülüyor.

Bu, yalnız gerçek zamanlı event akışına güvenmemek için iyi bir örnektir.

82. “Hiç Sipariş Gelmedi” ile “Sipariş Entegrasyonu Çalışmadı” Ayrı Durumlardır

Sipariş servisi hata veriyorsa local inventory stoğu düşmeyebilir.

Bu nedenle periyodik:

order reconciliation

mekanizması faydalıdır.

83. Stok Senkronizasyonunda Gözlemlenebilirlik Kurun

Dashboard örneği:

Son başarılı XML: 18:31

Değişen SKU: 482

Trendyol'a gönderilen: 480

Başarılı: 478

Başarısız: 2

Reconciliation farkı: 6 SKU

gibi olabilir.

84. Supplier Bazlı Stok Sağlığını Ölçün

Supplier A:

stok freshness → iyi.

Supplier B:

çok gecikmeli.

Supplier C:

sık feed kesiliyor.

Bu bilgiler tedarikçi riskini gösterir.

85. SKU Bazlı Stok Geçmişi Tutun

Örneğin:

18:00 Supplier → 10

18:01 Trendyol sent → 8

18:04 Order → 1

18:05 Expected → 7

18:15 Supplier → 9

gibi.

Sorun çıktığında timeline çok değerlidir.

86. Yalnız Son Değeri Değil Değişim Sebebini Saklayın

Örneğin:

SUPPLIER_REFRESH

MARKETPLACE_ORDER

MANUAL_OVERRIDE

SAFETY_BUFFER_CHANGE

SUPPLIER_PRODUCT_DISABLED

gibi.

Bu audit sürecini kolaylaştırır.

87. Manuel Stok Değişikliklerini Koruma Politikanız Olsun

Satıcı panelinden ürünü:

0

yaptınız.

XML sync birkaç dakika sonra:

20

yapabilir.

Bu nedenle manuel override:

• geçici,
• süreli,
• kalıcı

olarak tanımlanabilir.

88. Manuel Override Sebebi Kaydedilmelidir

Örneğin:

ürün hasarlı

tedarikçi doğrulanıyor

yüksek iade

geçici satış durdurma

gibi.

Yoksa birkaç ay sonra ürünün neden 0'da olduğu bilinmez.

89. Manuel Override'ın Bitiş Koşulu Olmalıdır

Örneğin:

24 saat

sonra otomatik kaldır.

veya:

operatör onayına kadar

koru.

Sonsuz override stok senkronizasyonunu anlamsız hale getirebilir.

90. Ürün Pasife Alınmışsa Yalnız Stok Sync Yetmeyebilir

Tedarikçi ürünü tamamen kaldırdıysa:

quantity = 0

yalnız geçici çözüm olabilir.

Ürünün lifecycle/pasif yönetimi 109 numaralı içeriğin konusudur.

91. Stok ve Fiyat Aynı Endpoint'te Olsa da Aynı Anda Değişmek Zorunda Değildir

Trendyol güncel dokümantasyonunda yalnız stok veya yalnız fiyat güncellenecekse diğer alanın gönderilmesinin zorunlu olmadığı belirtiliyor.

Bu önemli bir tasarım avantajıdır.

92. Stok Değişmediğinde Fiyat İçin Stok Göndermek Zorunda Değilsiniz

Benzer şekilde:

yalnız quantity değiştiyse gereksiz fiyat alanlarını tekrar göndermek zorunda değilsiniz.

Bu delta tabanlı mimariyi destekler.

93. Stok Sync ile Fiyat Sync'in Hız İhtiyacı Farklı Olabilir

Stok:

dakikalar içinde değişebilir.

Fiyat:

daha seyrek değişebilir.

Aynı endpoint bulunması iki job'ın aynı sıklıkta çalışması gerektiği anlamına gelmez.

94. Stok ve Fiyat Job'ları Ayrı Olabilir

Örneğin:

Inventory calculation

ayrı.

Pricing calculation

ayrı.

Son değişiklikler gerektiğinde aynı Trendyol API'ye gönderilebilir.

Bu mimari ihtiyaca göre tasarlanabilir.

95. Servis Limitlerini Hard-Code Etmeyin

Trendyol, 14 Eylül 2026 tarihinden itibaren ürün servislerinde yeni grup bazlı rate limitler uygulanacağını duyurmuş durumda. Inventory & Price Write limitleri satıcının ürün listeleme limit seviyesine göre değişecek.

Dolayısıyla yazılım:

“bu endpoint'in sonsuza kadar limiti yok”

varsayımıyla kurulmammalıdır.

96. Güncel Limitleri Resmî Dokümantasyondan Takip Edin

23 Ağustos 2026 itibarıyla doküman, 14 Eylül'e kadar stok/fiyat güncelleme servisini “NO LIMIT” gösterirken 14 Eylül sonrası için listeleme seviyesine göre yeni Inventory & Price Write limitlerini yayımlamış durumda.

Bu çok yakın tarihli değişiklik olduğu için blogda sabit entegrasyon varsayımı yapılmamalıdır.

97. Queue Boyutunu ve Throughput'u İzleyin

Değişen stok:

100.000 SKU.

API kapasitesi veya kendi worker kapasiteniz yetersizse son SKU Trendyol'a saatler sonra ulaşabilir.

Bu da senkronizasyon gecikmesidir.

98. En Kritik Stok Değişimlerini Önceliklendirebilirsiniz

Örneğin:

5 → 0

değişimi:

100 → 99

değişiminden daha yüksek overselling riski taşıyabilir.

Queue priority kullanılabilir.

99. Senkronizasyon Gecikmesini Ölçün

Örneğin:

Source changed → 18:00:00

Calculated → 18:00:20

Sent → 18:01:00

Confirmed → 18:01:15

Toplam propagation delay:

75 saniye.

Bu metrik stok sisteminin gerçek hızını gösterir.

100. Trendyol XML Stok Senkronizasyonunun Amacı Aynı Sayıyı Kopyalamak Değil, Aynı Ticari Gerçeği Korumaktır

133'ün ana mesajı budur.

Tedarikçi:

10

gösterebilir.

Trendyol:

8

gösterebilir.

Bu otomatik olarak hata değildir.

Çünkü:

2 adet güvenlik tamponu

bilinçli olarak uygulanmış olabilir.

Asıl problem:

Trendyol'un 8 göstermesi gerektiği halde 15 göstermesidir.

Dolayısıyla stok senkronizasyonu:

number copying

değil,

inventory state management

olarak tasarlanmalıdır.

TRENDYOL XML STOK SENKRONİZASYONU KONTROL LİSTESİ

Kaynak

Stok kaynağının kim olduğu belli mi?

Ham değer

XML'deki orijinal stok saklanıyor mu?

Alan anlamı

Stok fiziksel mi, kullanılabilir mı?

Birim

Adet/koli ayrımı doğru mu?

SKU

Doğru supplier SKU eşleşiyor mu?

Barkod

Doğru Trendyol barkodu biliniyor mu?

Varyant

Her varyant ayrı stoklanıyor mu?

Satılabilir stok

Kaynak stoktan ayrı hesaplanıyor mu?

Tampon

Gerekliyse güvenlik stoğu uygulanıyor mu?

Rezervasyon

Henüz kaynağa yansımamış siparişler kontrol ediliyor mu?

Double subtraction

Supplier feed siparişi yansıttığında rezervasyon tekrar düşülüyor mu?

Çoklu kanal

Aynı stok bütün kanallarda iki kez satılabilir mi?

Freshness

Kaynak verinin yaşı biliniyor mu?

Snapshot

Feed sürümü/tarihi kayıtlı mı?

Outage

Feed erişilemiyorsa 0 stok üretiliyor mu?

Missing product

XML'de bulunmayan SKU ayrı state mi?

Bulk anomaly

Binlerce ürün bir anda kaybolursa alarm oluşuyor mu?

Stock zero

Gerçek 0 ile boş/hata ayrılıyor mu?

Invalid value

Metin veya negatif değer kontrollü mü?

Delta

Yalnız değişen stoklar gönderiliyor mu?

last_sent

Son gönderilen stok tutuluyor mu?

last_confirmed

Son başarıyla uygulanmış stok ayrıca tutuluyor mu?

Batch

1.000 item sınırı dikkate alınıyor mu?

Batch result

batchRequestId kontrol ediliyor mu?

Item failure

Tek SKU hatası görülüyor mu?

failureReasons

Loglanıyor mu?

Retry

Eski stok yeniden gönderiliyor mu?

Version

Yeni stok eski retry tarafından ezilebiliyor mu?

Overlap

Aynı ürün için iki job aynı anda çalışıyor mu?

Manual override

XML manuel kapatılmış ürünü yeniden açabiliyor mu?

Reconciliation

Expected stock ile Trendyol stock karşılaştırılıyor mu?

Read-back

Onaylı ürün V2 stokları gerektiğinde okunuyor mu?

Metrics

Senkronizasyon gecikmesi ölçülüyor mu?

Rate limit

Güncel Trendyol limitleri takip ediliyor mu?

Audit

Bir ürünün stok değişim geçmişi görülebiliyor mu?

TRENDYOL XML STOK SENKRONİZASYONU NASIL KURULUR? 20 ADIM

1. Tedarikçi XML'indeki gerçek stok alanını doğrulayın.

2. Fiziksel stok, available stok, koli ve adet kavramlarını birbirinden ayırın.

3. Supplier SKU ile Trendyol barkodu arasında güvenilir ürün eşleştirmesi kurun.

4. Ham kaynak stoğu değiştirmeden saklayın.

5. İşletmenizin ana inventory source of truth sistemini belirleyin.

6. Kaynak stoktan Trendyol'a gönderilecek satılabilir stok kuralını oluşturun.

7. Gerekliyse stok tamponu ve geçici sipariş rezervasyonu mantığını ekleyin.

8. Rezervasyonun source feed'e yansıdığı anı belirleyerek double subtraction'ı önleyin.

9. Her stock snapshot'a zaman/sürüm bilgisi verin.

10. Önceki başarıyla gönderilmiş stok ile yeni stok arasında delta hesaplayın.

11. Yalnız değişen SKU'ları Trendyol güncelleme kuyruğuna ekleyin.

12. Güncellemeleri maksimum 1.000 SKU'luk request'lere bölün.

13. updatePriceAndInventory üzerinden doğru barkod ve quantity değerlerini gönderin.

14. Dönen her batchRequestId değerini internal sync job ile ilişkilendirin.

15. Batch sonucunu kontrol ederek item bazında SUCCESS/FAILED durumlarını kaydedin.

16. Başarısız güncellemeleri en son stock version'ı kontrol ederek yeniden işleyin.

17. Feed outage, toplu ürün kaybı, anormal stok artışı ve yanlış sıfırlama için koruma kuralları ekleyin.

18. Trendyol Onaylı Ürün V2 üzerinden periyodik stok reconciliation gerçekleştirin.

19. Supplier stock, expected sellable stock ve Trendyol stock arasındaki farkları raporlayın.

20. Overselling, sync latency, batch failure, source freshness ve stok uyuşmazlığı metriklerini sürekli izleyin.

SIK SORULAN SORULAR

Trendyol XML stok senkronizasyonu nedir?

Tedarikçi veya kendi stok sisteminizdeki ürün miktarlarından Trendyol'da gösterilecek satılabilir stokların hesaplanması, yalnız gerekli değişikliklerin Trendyol'a gönderilmesi ve sonuçların doğrulanması sürecidir. Trendyol güncel API'sinde gönderilen quantity değerini satılabilir stok olarak tanımlıyor.

XML'deki stok değerini doğrudan Trendyol'a göndermek doğru mu?

Her zaman değil. XML'deki değer fiziksel veya tedarikçi genel stoğu olabilir. Çoklu kanal kullanımı, güvenlik tamponu, rezervasyon ve tedarikçi stok güncelliği nedeniyle Trendyol'a gönderilecek satılabilir miktar farklı olabilir.

Trendyol sipariş geldiğinde stoğu düşürüyor mu?

Trendyol'un güncel stok/fiyat dokümantasyonuna göre quantity satılabilir stoktur ve sipariş geldiğinde veya satıcı yeniden stok gönderdiğinde bu bilgi güncellenir. Bu nedenle sipariş sonrasında eski XML miktarını yeniden gönderen entegrasyonun stoğu tekrar yükseltmemesine dikkat edilmelidir.

Her XML güncellemesinde bütün ürün stoklarını yeniden Trendyol'a göndermeli miyim?

Hayır. Trendyol yalnız değişen stok ve fiyatların gönderileceği bir yapı kullanılmasını açıkça öneriyor. Ayrıca aynı request body'nin değişmeden 15 dakika içinde tekrarlanması hata oluşturabiliyor. Bu nedenle delta bazlı güncelleme daha uygun bir modeldir.

API isteği başarılı döndüğünde stok kesin güncellenmiş sayılır mı?

Hayır. Stok/fiyat güncelleme isteğinde batchRequestId dönüyor ve Trendyol işlemin sonucunun getBatchRequestResult üzerinden kontrol edilmesini istiyor. Item bazında hata bulunması halinde failureReasons incelenmelidir.

TRENDYOL STOK SENKRONİZASYONUNDA EN KRİTİK HATA: DAHA YENİ BİR STOK DURUMUNU DAHA ESKİ BİR XML SNAPSHOT'IYLA EZMEKTİR

Örnek:

18:00

Supplier XML → 10

Entegrasyon güvenlik payı sonrası → 8

Trendyol → 8.

18:03

Trendyol siparişi → 1.

Trendyol → 7.

18:04

Supplier XML henüz değişmedi → 10.

Kötü entegrasyon:

10 kaynağını tekrar hesaplar → 8 gönderir.

Trendyol:

7 → 8.

Yani müşteri bir ürün satın aldığı halde satış kanalındaki stok yeniden yükselmiş olur.

Daha kontrollü entegrasyon:

Sipariş geldiğini bilir

↓

supplier feed'in siparişi henüz yansıtmadığını bilir

↓

pending reservation = 1

↓

source stock = 10

↓

buffer = 2

↓

pending reservation = 1

↓

expected sellable = 7

olarak tutabilir.

Daha sonra tedarikçi:

10 → 9

olarak güncellendiğinde rezervasyon artık ayrıca düşülmez:

source = 9

↓

buffer = 2

↓

reservation reflected = yes

↓

expected = 7

Bu örnek stok senkronizasyonunun yalnız:

“stok kaç?”

sorusundan oluşmadığını gösterir.

Asıl sorular:

Bu stok hangi saate ait?

Bu stok hangi sistemden geliyor?

Sipariş bu stokta zaten düşülmüş mü?

Aynı satış başka sistemde ayrıca rezerve edilmiş mi?

Trendyol'a son olarak ne gönderdik?

Gönderdiğimiz işlem gerçekten başarıyla uygulandı mı?

Trendyol şu an gerçekte kaç gösteriyor?

olmalıdır.

Bu nedenle 133'ün ana prensibi:

Stok senkronizasyonunda sadece miktarı değil, miktarın durumunu ve zamanını senkronize edin.