Pazaryeri Sipariş Entegrasyonu Nasıl Çalışır?

Aynı sipariş webhook ve polling ile iki kez geldiğinde iki fatura kesilebilir; kısmi iptalden sonra değişen paket kimliği eski etiketi geçersiz bırakabilir; etiket basıldığı hâlde paket kargoya hiç teslim edilmemiş olabilir. Pazaryeri sipariş entegrasyonu nasıl çalışır? Kanal siparişini tekil kimlikle alır, ortak durum modeline çevirir, stok-kargo-fatura adımlarını ayrı olaylar olarak yönetir ve iptal/iade sonucunu read-back ile doğrular.

Pazaryeri sipariş entegrasyonu yalnız siparişi bir ekrana taşımak değildir. Güvenilir süreç siparişi eksiksiz ve tekil alır; order, line ve package kimliklerini korur; durum, kargo ve fatura bağlantısını doğrular; başarısız her adımı kontrollü yeniden işlenebilir hâle getirir. İnsan incelemesi gereken uyuşmazlıkları da görünür bir istisna kuyruğuna taşır.

Pazaryeri Sipariş Entegrasyonu Nedir?

Pazaryeri sipariş entegrasyonu; kanaldaki sipariş, kalem ve paket kayıtlarını güvenli biçimde iç sisteme alan, kargo ve fatura adımlarını yöneten, iptal ve iade sonuçlarını geri eşitleyen çift yönlü operasyon katmanıdır. Yalnız veri çekmez; her yazmanın sonucunu tekrar okuyup kayıtlar arasında mutabakat kurar.

Bu bölümün dışındaki ayrıntılar için genel pazaryeri entegrasyonunun kapsamı rehberi konu sınırını tamamlar.

Uygulama, risk ve kanıt

• Uygulama: Pazaryeri Sipariş Entegrasyonu Nedir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 1. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Sipariş Entegrasyonu Ne İşe Yarar ve Kimler İçin Gereklidir?

Sipariş entegrasyonu manuel kopyalamayı, geç işlemeyi ve farklı paneller arasındaki görünürlük kaybını azaltır. Tek kanalda az sipariş alan işletme basit bir akışla başlayabilir; çoklu mağaza, depo veya yüksek hacimde kimlik, kuyruk, mutabakat ve istisna yönetimi zorunlu hâle gelir.

Sipariş entegrasyonu kapsam tablosu

Aşama veya tür	Karar/veri	Sahip	Kanıt veya kontrol
Tanım	Yetkili veri ve olay sınırı	Süreç sahibi	Kayıt sözleşmesi
Risk	Eksik, mükerrer veya eski kayıt	Operasyon	Alarm ve istisna
Kontrol	Idempotency, geçiş ve read-back	Teknik ekip	Test kanıtı
Ölçüm	Gecikme, hata ve müdahale	İş sahibi	KPI ve eşik

Uygulama, risk ve kanıt

• Uygulama: Sipariş Entegrasyonu Ne İşe Yarar ve Kimler İçin Gereklidir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 2. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Sipariş Entegrasyonu Neden Sadece Siparişi Tek Panele Çekmek Değildir?

Tek panel görünümü bir arayüzdür; güvenilir entegrasyon ise siparişin tekil alınmasından fiziksel teslim, iptal, iade ve geri ödeme sonucuna kadar olay zincirini yönetir. Kanalın API’ye açmadığı uyuşmazlık, kanıt ve itiraz adımları yine kaynak panelde ya da insan incelemesinde kalabilir.

Uygulama, risk ve kanıt

• Uygulama: Sipariş Entegrasyonu Neden Sadece Siparişi Tek Panele Çekmek Değildir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 3. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Sipariş, Sipariş Kalemi, Paket, Gönderi ve Claim Arasındaki Fark Nedir?

Sipariş ticari üst kaydı, sipariş kalemi ürün ve adet satırını, paket birlikte hazırlanacak kalem grubunu, gönderi taşıyıcıya verilen fiziksel hareketi, claim ise platformdaki iptal, iade veya uyuşmazlık talebini ifade eder. Bu nesnelerin kimlikleri birbirinin yerine kullanılamaz.

Trendyol’un 15.07.2026 tarihli sipariş paketi rehberi, bu karar için kullanılan birincil teknik veya hukuki doğrulama noktasıdır; erişim tarihi 15.07.2026’dır.

15.07.2026’da resmî Trendyol rehberi orderNumber değerini ana sipariş, id değerini paket olarak ayırır; paket içindeki kalem iptalinde orderNumber aynı kalırken yeni paket ID’si ve barkod oluşabileceğini belirtir. Bu platforma özgü örnek, bütün kanallara kural olarak genellenmez.

Sipariş, kalem, paket, gönderi ve claim terim tablosu

Aşama veya tür	Karar/veri	Sahip	Kanıt veya kontrol
Kimlik	Order, line ve package ayrı	OMS	Birleşik benzersiz anahtar
Yönlendirme	Stok, mesafe ve cut-off	Routing	Karar sürümü
Toplama	Kalem ve adet taraması	WMS	Picking kanıtı
Bölme	Yeni paket ve etiket	OMS/Kargo	Eski kimliği bloke et

Uygulama, risk ve kanıt

• Uygulama: Sipariş, Sipariş Kalemi, Paket, Gönderi ve Claim Arasındaki Fark Nedir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 4. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Uçtan Uca Pazaryeri Sipariş Yaşam Döngüsü Nasıl İlerler?

Yaşam döngüsü siparişi alma ve doğrulamayla başlar; rezervasyon, toplama, paketleme, belge, etiket, fiziksel teslim, takip ve teslim olaylarıyla ilerler. İptal, teslim edilememe, iade ve geri ödeme ana akıştan ayrılan fakat aynı kimlik zincirine bağlı alt süreçlerdir.

Uçtan uca sipariş yaşam döngüsü

Uygulama, risk ve kanıt

• Uygulama: Uçtan Uca Pazaryeri Sipariş Yaşam Döngüsü Nasıl İlerler? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 5. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Siparişin Source of Truth’u Hangi Sistem Olmalıdır?

Tek bir sistem her alanın sahibi olmak zorunda değildir. Ticari sipariş ve müşteri beyanında pazaryeri, depo hareketinde WMS, mali belgede e-Belge sistemi, taşıma olayında kargo kaydı yetkili kaynak olabilir; OMS bu alanları sürüm ve kanıtla birleştirir.

Sistem ve source of truth matrisi

Uygulama, risk ve kanıt

• Uygulama: Siparişin Source of Truth’u Hangi Sistem Olmalıdır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 6. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

OMS, ERP, WMS, Kargo ve E-Belge Sistemleri Nasıl Birlikte Çalışır?

OMS yaşam döngüsünü orkestre eder, ERP ticari ve mali kaydı, WMS fiziksel depo işini, kargo sistemi gönderiyi, e-Belge sistemi faturayı yönetir. Her alan için tek yazan sistem ve açık geri bildirim sözleşmesi tanımlanmadığında çift kayıt ve durum çatışması oluşur.

Bu bölümün dışındaki ayrıntılar için ERP veri sahipliği ve entegrasyon mimarisi rehberi konu sınırını tamamlar.

Uygulama, risk ve kanıt

• Uygulama: OMS, ERP, WMS, Kargo ve E-Belge Sistemleri Nasıl Birlikte Çalışır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 7. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Pazaryeri Siparişleri Sisteme Nasıl Alınır?

Siparişler listeleme API’si, webhook, stream veya kanalın sunduğu raporlarla alınabilir. Güvenilir tasarım hızlı bildirim kanalını periyodik geri tarama ve günlük mutabakatla tamamlar; kanalın sunmadığı bir yöntemi varmış gibi varsaymaz.

Hepsiburada resmî sipariş entegrasyonu portalı, bu karar için kullanılan birincil teknik veya hukuki doğrulama noktasıdır; erişim tarihi 15.07.2026’dır.

Uygulama, risk ve kanıt

• Uygulama: Pazaryeri Siparişleri Sisteme Nasıl Alınır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 8. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Webhook, Polling ve Stream Nasıl Karşılaştırılır?

Webhook düşük gecikmeli bildirim, polling kontrollü sorgulama, stream ise cursor tabanlı ardışık tüketim sağlar. Tek başına hiçbiri kayıpsızlık garantisi değildir; desteklenen kanallarda hibrit yaklaşım hızlı alımı backfill ile tamamlar.

Trendyol’un aynı gün okunan webhook rehberi, başarısız bildirimlerin yeniden iletilebildiğini ve webhook her zaman mümkün olmayabildiği için periyodik getShipmentPackages eşitlemesini önerir. Bu not webhook teslimatının “yalnız bir kez” garantisi olmadığını açıkça gösterir.

Webhook, polling ve stream karşılaştırması

Uygulama, risk ve kanıt

• Uygulama: Webhook, Polling ve Stream Nasıl Karşılaştırılır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 9. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Sipariş Kaçırmamak İçin Cursor, Watermark ve Overlap Window Nasıl Kullanılır?

Cursor sayfalama konumunu, watermark son güvenli işleme noktasını, overlap window ise geç gelen kayıtlar için önceki zamanın küçük bölümünü yeniden okumayı temsil eder. Checkpoint ancak sayfa tamamen işlendiğinde ilerletilir ve tekrarlar idempotency ile emilir.

Cursor, watermark ve overlap kontrol tablosu

Uygulama, risk ve kanıt

• Uygulama: Sipariş Kaçırmamak İçin Cursor, Watermark ve Overlap Window Nasıl Kullanılır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 10. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Tarih Aralığı, Saat Dilimi ve Pagination Hataları Nasıl Önlenir?

Tüm kanal zamanları kaynak saat dilimiyle saklanmalı, iç sistemde UTC karşılığı ve özgün değer birlikte tutulmalıdır. Sayfa numarası, cursor, toplam sayfa, boş içerik ve aynı zaman damgalı son kayıt için ayrı bitiş koşulları test edilmelidir.

n11 resmî RestAPI sipariş listeleme rehberi, bu karar için kullanılan birincil teknik veya hukuki doğrulama noktasıdır; erişim tarihi 15.07.2026’dır.

15.07.2026’da n11 resmî rehberinde dakika başına azami 1.000 istek, sayfada azami 100 kayıt, tek statü filtresi, page=0 başlangıcı ve tarih aralığında 15 günlük davranış yer alır. Trendyol rehberi ise sayfada azami 200 kayıt, sorguda iki haftalık aralık ve mevcut serviste dakika başına 1.000 istek gösterir; bunlar tarihli kanal örnekleridir, evrensel limit değildir.

Tarih, saat ve pagination risk tablosu

Aşama veya tür	Karar/veri	Sahip	Kanıt veya kontrol
Kalıcı	400/401/403/422 sınıfı	Otomatik retry yok	Düzelt ve kontrollü yeniden işle
Geçici	429 veya seçili 5xx	Sınırlı retry	Backoff, jitter ve Retry-After
Belirsiz	Timeout sonrası sonuç bilinmiyor	Önce read-back	Aynı idempotency anahtarı
Tükenmiş	Maksimum deneme aşıldı	DLQ	Sahip ve kanıtla çözüm

Uygulama, risk ve kanıt

• Uygulama: Tarih Aralığı, Saat Dilimi ve Pagination Hataları Nasıl Önlenir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 11. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Aynı Siparişin İki Kez İşlenmesi Nasıl Önlenir?

Benzersizlik yalnız order ID’ye değil kanal, tenant ve mağaza kimliğiyle birleşik anahtara dayanır. Webhook ve polling aynı kaydı getirdiğinde kayıt ekleme, rezervasyon, fatura ve etiket işlemleri atomik idempotency anahtarlarıyla tek yan etki üretir.

Senaryo 1: Webhook ve polling aynı siparişi getiriyor

Senaryo alanı	Uygulama
Başlangıç koşulu	Temsili O-20260715-001 siparişi webhook ile gelir; yanıt timeout olur.
Olay zaman çizelgesi	10:00 webhook, 10:00:02 kayıt, 10:02 polling, 10:03 sonuç doğrulama.
Kaynak sistemler	Pazaryeri, alım servisi, OMS, stok, e-Belge ve kargo.
Beklenen kayıtlar	Tek sipariş, tek rezervasyon; fatura ve etiket henüz iş kuralına göre birer kez.
Risk	Timeout nedeniyle iki tüketicinin aynı yan etkiyi üretmesi.
Otomasyon kuralı	tenant+store+orderId ve işlem türüyle atomik idempotency.
İnsan kontrolü	Çelişen payload veya aynı anahtarda farklı tutar varsa inceleme.

Uygulama, risk ve kanıt

• Uygulama: Aynı Siparişin İki Kez İşlenmesi Nasıl Önlenir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 12. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Idempotency Sipariş, Fatura ve Kargo İşlemlerinde Nasıl Kurulur?

Idempotency, aynı niyete ait tekrar çağrının yeni bir yan etki oluşturmamasıdır. Sipariş içe alma, fatura oluşturma ve etiket üretme için ayrı anahtar, payload özeti, sonuç ve saklama süresi tutulur; aynı anahtar farklı veriyle gelirse işlem reddedilir.

AWS idempotent API rehberi, bu karar için kullanılan birincil teknik veya hukuki doğrulama noktasıdır; erişim tarihi 15.07.2026’dır.

Kimlik ve idempotency anahtarları

Aşama veya tür	Karar/veri	Sahip	Kanıt veya kontrol
Veri	Paket kimliği, belge numarası, kalem ve toplam	e-Belge/OMS	Read-back ve ret kodu
Tetik	İşletme ve kanal kuralı	Finans	Onaylı iş kuralı
Hata	Mükerrerlik veya veri uyuşmazlığı	İstisna sahibi	Belge kimliğiyle düzeltme
Kanıt	Sağlayıcı ve kanal sonucu	Denetim izi	Maskeli durum kaydı

Uygulama, risk ve kanıt

• Uygulama: Idempotency Sipariş, Fatura ve Kargo İşlemlerinde Nasıl Kurulur? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 13. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Olay Sırası Bozulursa Eski Durum Yeni Durumu Nasıl Ezmez?

Her olayın sürümü, kanal lastModified değeri, mümkünse sequence numarası ve izin verilen geçişi kontrol edilir. Delivered kaydından sonra gelen eski Shipped olayı audit kaydına alınır fakat güncel durumu geriye çekmez.

Uygulama, risk ve kanıt

• Uygulama: Olay Sırası Bozulursa Eski Durum Yeni Durumu Nasıl Ezmez? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 14. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Eksik Sipariş veya Missing Order Nasıl Tespit Edilir?

Eksik sipariş yalnız hata logundan bulunamaz; periyodik backfill, kanal ve OMS adet karşılaştırması, kimlik boşluğu, gecikme yüzdelikleri ve günlük mutabakat birlikte kullanılır. Alarm, etkilenen mağaza ve zaman penceresini gösterecek kadar somut olmalıdır.

CloudEvents ortak olay zarfı yaklaşımı, bu karar için kullanılan birincil teknik veya hukuki doğrulama noktasıdır; erişim tarihi 15.07.2026’dır.

Uygulama, risk ve kanıt

• Uygulama: Eksik Sipariş veya Missing Order Nasıl Tespit Edilir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 15. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Pazaryeri Sipariş Durumları Ortak Bir Modele Nasıl Eşlenir?

Her kanal durumu ortak bir canonical modele çevrilirken ham değer de saklanır. NEW, PICKING veya SHIPPED gibi iç durumlar şirket standardıdır; kanalın aynı isimli durumuyla otomatik olarak aynı anlamı taşımaz.

Durum eşleme tablosu

Aşama veya tür	Karar/veri	Sahip	Kanıt veya kontrol
NEW	Yeni ve doğrulanmış kayıt	ACKNOWLEDGED	Kimlikler tam
PICKING	Depo iş emri açık	PACKED	Tarama tamam
SHIPPED	Fiziksel kabul kanıtlı	DELIVERED	Taşıyıcı olayı
EXCEPTION	Geçersiz veya eksik kayıt	İnsan kararı	Audit izi

Uygulama, risk ve kanıt

• Uygulama: Pazaryeri Sipariş Durumları Ortak Bir Modele Nasıl Eşlenir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 16. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Sipariş Durum Makinesi Nasıl Tasarlanır?

Durum makinesi izin verilen geçişleri, geri döndürülemez noktaları ve koşullu dalları açıkça tanımlar. Geçersiz geçiş sessizce uygulanmaz; neden, kaynak olay ve mevcut sürümle istisna kuyruğuna taşınır.

İzin verilen durum geçiş matrisi

Uygulama, risk ve kanıt

• Uygulama: Sipariş Durum Makinesi Nasıl Tasarlanır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 17. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Ödeme Durumu ile Sipariş Operasyon Durumu Neden Ayrılmalıdır?

Ödeme yetkilendirmesi, tahsilat, risk incelemesi ve refund mali eksendir; picking, paketleme ve sevk operasyon eksenidir. İki ekseni tek alan yapmak ödeme bekleyen siparişin yanlış sevkine veya teslim edilen siparişin yanlış iptaline yol açabilir.

Ödeme ve operasyon durumu ayrımı

Uygulama, risk ve kanıt

• Uygulama: Ödeme Durumu ile Sipariş Operasyon Durumu Neden Ayrılmalıdır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 18. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Sipariş Ne Zaman Kabul Edilmeli ve Stok Ne Zaman Rezerve Edilmelidir?

Kabul ve rezervasyon; kanal statüsü, ödeme uygunluğu, iptal penceresi ve depo kapasitesine göre ayrı kurallarla tetiklenmelidir. Erken rezervasyon satılabilir stoğu gereksiz bağlar, geç rezervasyon ise fazla satış riskini artırır.

Bu bölümün dışındaki ayrıntılar için stok rezervasyonu ve kanal senkronizasyonu rehberi konu sınırını tamamlar.

Uygulama, risk ve kanıt

• Uygulama: Sipariş Ne Zaman Kabul Edilmeli ve Stok Ne Zaman Rezerve Edilmelidir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 19. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Sipariş Paketleme Akışı Nasıl Tasarlanır?

Paketleme akışı iş emri, picking, barkod doğrulama, kalite kontrol, packing ve etiket sırasını izlemelidir. Sipariş fişi, toplama listesi, paketleme listesi ve taşıyıcı etiketi farklı amaçlara sahip belgelerdir.

Picking ve packing kontrol tablosu

Uygulama, risk ve kanıt

• Uygulama: Sipariş Paketleme Akışı Nasıl Tasarlanır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 20. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Sipariş ile Sipariş Paketi Neden Aynı Şey Değildir?

Bir sipariş birden çok pakete bölünebilir ve her paket ayrı taşıyıcı, takip numarası ve sevk durumuna sahip olabilir. Üst sipariş durumu, paketlerin tamamı ve kalem sonuçları değerlendirilmeden kesinleştirilmemelidir.

Uygulama, risk ve kanıt

• Uygulama: Sipariş ile Sipariş Paketi Neden Aynı Şey Değildir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 21. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Paket Bölme ve Kısmi Sevkiyat Nasıl Yönetilir?

Bölme kararı stok yeri, hacim, teslimat vaadi ve kanal desteğiyle verilir. Eski paket kimliği, yeni paketler, barkodlar, takip numaraları ve kalem dağılımı aynı korelasyon zincirinde saklanır.

Paket bölme ve kısmi sevkiyat etkileri

Uygulama, risk ve kanıt

• Uygulama: Paket Bölme ve Kısmi Sevkiyat Nasıl Yönetilir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 22. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Kısmi İptal Paketi Nasıl Değiştirir?

Kalem veya adet iptali paket içeriğini ve bazı platformlarda paket ID’siyle barkodu değiştirebilir. Eski etiket önce bloke edilir, güncel paket tekrar okunur, toplam ve fatura verisi doğrulandıktan sonra operasyon devam eder.

Senaryo 2: Kısmi iptal paket kimliğini değiştiriyor

Uygulama, risk ve kanıt

• Uygulama: Kısmi İptal Paketi Nasıl Değiştirir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 23. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Çoklu Depoda Sipariş Yönlendirme Nasıl Yapılır?

Routing motoru yalnız stok varlığına değil mesafe, cut-off, ship-by, kapasite, ürün uygunluğu ve bölme maliyetine bakmalıdır. Karar sürümü saklanmalı; aynı kalem için iki depoda eşzamanlı picking oluşması atomik kilitle engellenmelidir.

Çoklu depo routing matrisi

Senaryo 3: Çoklu depo ve kısmi sevkiyat

Uygulama, risk ve kanıt

• Uygulama: Çoklu Depoda Sipariş Yönlendirme Nasıl Yapılır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 24. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Set ve Bundle Ürün Siparişleri Nasıl İşlenir?

Kanalda tek kalem görünen set, iç sistemde bileşenlerine açılır; picking ve stok hareketi bileşen bazında yürür. Fatura satırı ise ürün tanımı ve güncel mali kurala göre ayrıca doğrulanır.

Bu bölümün dışındaki ayrıntılar için ürün, barkod ve SKU eşleştirme süreci rehberi konu sınırını tamamlar.

Uygulama, risk ve kanıt

• Uygulama: Set ve Bundle Ürün Siparişleri Nasıl İşlenir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 25. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Seri, Lot veya Son Kullanma Tarihi Gereken Ürünlerde Ne Değişir?

İzlenebilir ürünlerde picking sırasında seri veya lot atanır, FEFO/FIFO kuralı kategoriye göre uygulanır ve iade aynı kimlikle kontrol edilir. Bu gereksinimler her ürün için evrensel değildir; sektör uzmanlığı ve mevzuat kontrolü ister.

Uygulama, risk ve kanıt

• Uygulama: Seri, Lot veya Son Kullanma Tarihi Gereken Ürünlerde Ne Değişir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 26. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Handling Time, Cut-Off ve Ship-By Date Nasıl Yönetilir?

Handling time hazırlama süresi, cut-off sipariş kesim saati, ship-by ise en geç kargoya verme zamanıdır. Kanal vaadi depo takvimi, tatil, taşıyıcı kabul saati ve gerçek kapasiteyle birlikte hesaplanmalıdır.

Uygulama, risk ve kanıt

• Uygulama: Handling Time, Cut-Off ve Ship-By Date Nasıl Yönetilir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 27. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Pazaryeri Anlaşmalı Kargo, Satıcı Anlaşmalı Kargo ve Fulfillment Nasıl Karşılaştırılır?

Kargo modelleri etiket üreticisi, ücret sorumlusu, takip kaynağı, fiziksel operasyon ve API kapsamı bakımından ayrılır. Her işletme için tek üstün model yoktur; hacim, bölge, maliyet ve kontrol ihtiyacı birlikte değerlendirilir.

Bu bölümün dışındaki ayrıntılar için kargo sözleşmesi ve maliyet koşulları rehberi konu sınırını tamamlar.

Kargo modeli karşılaştırması

Uygulama, risk ve kanıt

• Uygulama: Pazaryeri Anlaşmalı Kargo, Satıcı Anlaşmalı Kargo ve Fulfillment Nasıl Karşılaştırılır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 28. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Kargo Etiketi ve Barkod Nasıl Oluşturulur?

Etiket üretmeden önce güncel paket kimliği, kalemler, adres, taşıyıcı kodu ve servis seviyesi doğrulanır. Aynı pakete iki aktif etiket bırakmamak için üretim isteği idempotent yapılır ve önceki etiket durumu okunur.

Uygulama, risk ve kanıt

• Uygulama: Kargo Etiketi ve Barkod Nasıl Oluşturulur? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 29. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Etiket Oluşturulması Kargoya Teslim Anlamına Gelir mi?

Hayır. Etiket yalnız taşıma kaydının hazırlandığını gösterir; manifest, fiziksel kabul ve first scan ayrı kanıtlardır. Shipped durumu kanal kuralına göre doğrulanmış teslim olayından sonra gönderilmelidir.

Etiket, manifest ve first-scan kanıt zinciri

Uygulama, risk ve kanıt

• Uygulama: Etiket Oluşturulması Kargoya Teslim Anlamına Gelir mi? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 30. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Kargo Firması veya Servis Seviyesi Nasıl Değiştirilir?

Değişiklik yalnız kanal ve taşıyıcının izin verdiği pencerede yapılır. Eski etiket geçersizleştirilir, yeni taşıyıcı sonucu read-back ile alınır ve paketleme alanındaki basılı kopyalar da fiziksel olarak ayrılır.

Taşıyıcı değişikliği, paket bölme ve etiket üretme yetkileri her kanalda aynı değildir. Hepsiburada portalındaki sipariş oluşturma/test, shipping ve talep ürünleri bu nedenle ayrı doğrulanmış; erişilemeyen veya sözleşmeye bağlı ayrıntılar tahmin edilmemiştir.

Uygulama, risk ve kanıt

• Uygulama: Kargo Firması veya Servis Seviyesi Nasıl Değiştirilir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 31. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Takip Numarası ve Kargo Durumları Pazaryerine Nasıl Gönderilir?

Takip numarası doğru package ID, carrier code, gönderim zamanı ve servis seviyesiyle bağlanır. Kargo olayı ile pazaryeri görünümü arasında gecikme olabileceği için yazma kabulü, taşıyıcı kaydı ve kanal read-back ayrı izlenir.

Kargo takip durum eşleme tablosu

Uygulama, risk ve kanıt

• Uygulama: Takip Numarası ve Kargo Durumları Pazaryerine Nasıl Gönderilir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 32. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Teslim Edilemeyen veya Geri Dönen Kargo Nasıl Yönetilir?

Adres sorunu, alıcı reddi, operasyonel teslim edememe ve return-to-sender aynı neden değildir. Paket geri dönse bile müşteri iadesi, stok açma, fatura düzeltme ve refund kararları bağımsız kanıtlarla yürütülür.

Uygulama, risk ve kanıt

• Uygulama: Teslim Edilemeyen veya Geri Dönen Kargo Nasıl Yönetilir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 33. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Fatura Hangi Sipariş Aşamasında Hazırlanmalıdır?

Fatura tetik noktası işletmenin vergi süreci, kanal şartı, iptal riski ve sevk planına göre belirlenir. Sipariş alınır alınmaz kesmek düzeltme yükünü, çok geç kesmek sevkiyat ve uyum riskini artırabilir.

Fatura tetikleme seçenekleri

Uygulama, risk ve kanıt

• Uygulama: Fatura Hangi Sipariş Aşamasında Hazırlanmalıdır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 34. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Sipariş Verisi Faturaya Nasıl Eşleştirilir?

Alıcı tipi, unvan, VKN/TCKN, adres, ürün adı, SKU, adet, birim, KDV, indirim, kargo ve toplamlar kalem bazında doğrulanır. Pazaryeri verisiyle ürün kaynağı çelişirse yetkili alan ve istisna kuralı önceden belirlenir.

Fatura veri eşleştirme tablosu

Uygulama, risk ve kanıt

• Uygulama: Sipariş Verisi Faturaya Nasıl Eşleştirilir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 35. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

e-Fatura ve e-Arşiv Ayrımı Nasıl Doğrulanır?

Belge türü güncel GİB mükellef kaydı, işlem türü ve e-Belge sağlayıcısı yanıtıyla belirlenir. Bu rehber tek bir iptal veya iade yöntemi dayatmaz; mali müşavir ve e-Belge uzmanı kontrolü korunur.

Bu bölümün dışındaki ayrıntılar için otomatik e-Belge akışının ayrıntıları rehberi konu sınırını tamamlar.

GİB e-Belge portalı, bu karar için kullanılan birincil teknik veya hukuki doğrulama noktasıdır; erişim tarihi 15.07.2026’dır.

Uygulama, risk ve kanıt

• Uygulama: e-Fatura ve e-Arşiv Ayrımı Nasıl Doğrulanır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 36. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Fatura Linki ve Fatura Dosyası Pazaryerine Nasıl İletilir?

Kanalın desteklediği yönteme göre güvenli URL veya dosya; doğru paket kimliği, fatura numarası ve tarih ile gönderilir. Link erişimi tahmin edilemez olmalı, token loglanmamalı ve saklama gereksinimi güncel resmî kuralla doğrulanmalıdır.

Uygulama, risk ve kanıt

• Uygulama: Fatura Linki ve Fatura Dosyası Pazaryerine Nasıl İletilir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 37. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Fatura Gönderim Durumu Nasıl İzlenir?

Gönderilmedi, alındı, doğrulanıyor, reddedildi ve kabul edildi gibi iç durumlar ayrı tutulur. HTTP yanıtı taşıma kabulünü gösterebilir; platform doğrulaması ve müşterinin eriştiği belge ayrıca read-back ile kontrol edilir.

Fatura durum ve hata tablosu

Uygulama, risk ve kanıt

• Uygulama: Fatura Gönderim Durumu Nasıl İzlenir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 38. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Fatura Reddedilirse Ne Yapılmalıdır?

Ret kodu kalem, toplam, vergi kimliği, numara veya bağlantı hatasına çevrilir; mevcut belgenin kimliği korunarak düzeltme yapılır. Kör yeniden kesim yerine aynı belgenin durumu okunur, yetkili onayı alınır ve sevk blokajı kuralı uygulanır.

Senaryo 4: Fatura reddi ve sevkiyat blokajı

Uygulama, risk ve kanıt

• Uygulama: Fatura Reddedilirse Ne Yapılmalıdır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 39. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Sipariş İptali Türleri Nelerdir?

Müşteri iptali, satıcı iptali, ödeme iptali, tedarik edememe, sistem iptali ve kısmi iptal farklı neden, yetki ve sonuçlara sahiptir. Kanalın reason code’u özgün hâliyle saklanmalı ve iç durumla birlikte raporlanmalıdır.

İptal türleri ve sistem etkileri

Uygulama, risk ve kanıt

• Uygulama: Sipariş İptali Türleri Nelerdir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 40. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Kısmi İptal Nasıl Yönetilir?

Kısmi iptal order line ve adet düzeyinde uygulanır; üst sipariş tamamen iptal edilmiş sayılmaz. Paket, toplam, indirim, vergi, fatura ve etiket sonuçları yeni sürüm üzerinden tekrar doğrulanır.

Kısmi iptal karar tablosu

Uygulama, risk ve kanıt

• Uygulama: Kısmi İptal Nasıl Yönetilir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 41. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Kargo Etiketi Oluşturulduktan Sonra İptal Olursa Ne Yapılır?

Önce fiziksel durum ayrılır: yalnız etiket basılmış paket durdurulabilirken taşıyıcıya verilmiş paket geri çağırma veya iade akışına girebilir. Etiket void, manifest çıkarma ve kanal read-back adımları ayrı kanıt üretir.

Uygulama, risk ve kanıt

• Uygulama: Kargo Etiketi Oluşturulduktan Sonra İptal Olursa Ne Yapılır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 42. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Fatura Kesildikten Sonra Sipariş İptal Olursa Ne Yapılır?

Sipariş, e-Belge, muhasebe, stok, ödeme ve müşteri bildirimi ayrı iş adımlarıdır. Belge türüne ve güncel kurala uygun düzeltme uzman kontrolüyle yapılmalı; iptal olayı otomatik olarak her sistemi tamamlandı saymamalıdır.

Uygulama, risk ve kanıt

• Uygulama: Fatura Kesildikten Sonra Sipariş İptal Olursa Ne Yapılır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 43. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Belge düzeltme ve durum izleme gerekiyorsa Solofor e-Fatura hizmetinin REST API, raporlama, yetkilendirme ve kontör koşullarını canlı sayfa ile sözleşmede ayrıca doğrulayın.

İptalde Stok, Geri Ödeme ve Muhasebe Kaydı Nasıl Koordine Edilir?

İptal alındı, onaylandı, stok açıldı, refund başlatıldı, refund tamamlandı ve mali kayıt düzeltildi durumları ayrı tutulur. Her yan etki iptal kimliğiyle idempotent çalışır ve mutabakat sonucu kapanır.

Uygulama, risk ve kanıt

• Uygulama: İptalde Stok, Geri Ödeme ve Muhasebe Kaydı Nasıl Koordine Edilir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 44. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Sipariş İptalinde Tüketici İletişimi Nasıl Olmalıdır?

Bildirim doğru neden, güncel durum, varsa geri ödeme aşaması ve başvuru kanalını açıkça göstermelidir. Keyfî veya gerekçesiz otomatik iptal hukuki ve itibar riski taşır; somut olay güncel resmî kaynak ve hukuk uzmanıyla değerlendirilir.

Bu bölümün dışındaki ayrıntılar için iptal ve refund sonrası finansal mutabakat rehberi konu sınırını tamamlar.

Ticaret Bakanlığının gerekçesiz iptal uyarısı, bu karar için kullanılan birincil teknik veya hukuki doğrulama noktasıdır; erişim tarihi 15.07.2026’dır.

Uygulama, risk ve kanıt

• Uygulama: Sipariş İptalinde Tüketici İletişimi Nasıl Olmalıdır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 45. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

İade Talebi ile Fiziksel İade Arasındaki Fark Nedir?

Talep açılması müşterinin süreci başlattığını, fiziksel kabul ise ürünün depoya gerçekten ulaştığını gösterir. Aradaki kargo, teslim, inceleme, karar ve refund olayları ayrı kimlik ve zaman damgalarıyla izlenir.

Bu bölümün dışındaki ayrıntılar için satış sonrası müşteri ve iade operasyonu rehberi konu sınırını tamamlar.

İade yaşam döngüsü

Uygulama, risk ve kanıt

• Uygulama: İade Talebi ile Fiziksel İade Arasındaki Fark Nedir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 46. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

İade Kodu, RMA ve Tersine Lojistik Nasıl Çalışır?

İade kodu veya RMA talebi tanımlar; tersine lojistik etiketi, taşıyıcı, takip ve kabul adresiyle ürünü geri taşır. Her pazaryeri aynı adı veya API yetkisini kullanmadığından kanal kuralı yazım gününde doğrulanır.

Uygulama, risk ve kanıt

• Uygulama: İade Kodu, RMA ve Tersine Lojistik Nasıl Çalışır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 47. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

İade Ürün Depoya Geldiğinde Hangi Kontroller Yapılmalıdır?

Depo paket, ürün, adet, seri/lot, aksesuar, hasar ve kategoriye uygun hijyen koşullarını kontrol eder. Fotoğraf veya video kanıtı amaç, erişim ve saklama süresi sınırlanarak tutulur; kişisel veri gereksiz yere kaydedilmez.

Bu bölümün dışındaki ayrıntılar için iade nedenlerini azaltma yaklaşımı rehberi konu sınırını tamamlar.

İade kalite kontrol tablosu

Senaryo 5: İade talebi, fiziksel kabul ve kalite kontrol

Uygulama, risk ve kanıt

• Uygulama: İade Ürün Depoya Geldiğinde Hangi Kontroller Yapılmalıdır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 48. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

İade Onayı veya Reddi Nasıl Yönetilir?

Karar yetkili rol, reason code, açıklama, zaman damgası ve kanıtla oluşturulur. API’nin izin vermediği ya da hukuki yorum gerektiren retler otomatikleştirilmez; insan ve gerektiğinde hukuk kontrolü uygulanır.

İade onay ve ret karar matrisi

Uygulama, risk ve kanıt

• Uygulama: İade Onayı veya Reddi Nasıl Yönetilir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 49. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Kısmi İade ve Değişim Nasıl Yönetilir?

Kısmi iade kalem ve adet bazında refund doğurabilir; değişim ise bazı kanallarda yeni sipariş veya yeni belge gerektirebilir. Mevcut paket, claim ve mali kayıtlar özgün kimliklerle birbirine bağlanır.

Uygulama, risk ve kanıt

• Uygulama: Kısmi İade ve Değişim Nasıl Yönetilir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 50. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

İade Edilen Ürün Ne Zaman Satılabilir Stoğa Eklenir?

Ürün yalnız fiziksel kabul ve kalite kontrol sonucunda satılabilir kararı verildiğinde stoğa açılır. Yeniden paketleme, onarım, karantina, hurda veya tedarikçiye dönüş ayrı stok sınıflarıdır.

Bu bölümün dışındaki ayrıntılar için iade sonrası stok sınıflandırması rehberi konu sınırını tamamlar.

Uygulama, risk ve kanıt

• Uygulama: İade Edilen Ürün Ne Zaman Satılabilir Stoğa Eklenir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 51. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

İade Sonrası Fatura ve Geri Ödeme Nasıl İzlenir?

İade kabulü, belge düzeltmesi, refund başlatma, ödeme sonucu ve muhasebe kaydı birbirinden bağımsız durumlardır. Tamamlanma ancak pazaryeri, ödeme ve mali kayıt sonuçları mutabık olduğunda ilan edilir.

Uygulama, risk ve kanıt

• Uygulama: İade Sonrası Fatura ve Geri Ödeme Nasıl İzlenir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 52. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Müşteri Bildirimleri Hangi Olaylarda Gönderilmelidir?

Bildirimler sipariş alındı, hazırlık, fatura hazır, fiziksel sevk, teslim, iptal, iade kabul ve refund tamamlandı gibi doğrulanmış olaylara bağlanmalıdır. Aynı event ID için tek mesaj üretilir ve erken bildirim geri çekme yükü yaratmaz.

Uygulama, risk ve kanıt

• Uygulama: Müşteri Bildirimleri Hangi Olaylarda Gönderilmelidir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 53. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Hangi Siparişler Otomatik, Hangileri İnsan Onayıyla İşlenmelidir?

Standart ve veri bütünlüğü tam siparişler otomatik ilerleyebilir; yüksek tutar, adres/vergi uyuşmazlığı, şüpheli ödeme, kısmi iptal, iade reddi ve müşteri uyuşmazlığı insan onayına gider. Risk eşikleri ölçülür ve periyodik gözden geçirilir.

Bu bölümün dışındaki ayrıntılar için e-ticaret operasyonunda rol ve sorumluluklar rehberi konu sınırını tamamlar.

Uygulama, risk ve kanıt

• Uygulama: Hangi Siparişler Otomatik, Hangileri İnsan Onayıyla İşlenmelidir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 54. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Exception Queue veya İstisna Kuyruğu Nasıl Tasarlanır?

İstisna kuyruğu kurala uymayan siparişleri sipariş, mağaza, hata, son deneme, yaş, sahip ve önerilen aksiyonla görünür kılar. Kaydın sessizce beklemesini önlemek için SLA, eskalasyon ve kapanış kanıtı bulunur.

Exception queue alanları

Uygulama, risk ve kanıt

• Uygulama: Exception Queue veya İstisna Kuyruğu Nasıl Tasarlanır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 55. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

API İsteği Başarılıysa İşlem Kesin Tamamlanmış mıdır?

Hayır. Bağlantı başarısı, isteğin kabulü, asenkron işleme, satır sonucu, hedef kayıt ve vitrin görünümü farklı aşamalardır. 200 veya 202 sonrasında task sonucu ya da read-back kontrolü gerekebilir.

Uygulama, risk ve kanıt

• Uygulama: API İsteği Başarılıysa İşlem Kesin Tamamlanmış mıdır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 56. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Sipariş Entegrasyonunda Hata Sınıfları Nasıl Ayrılır?

Kimlik/yetki, doğrulama, iş kuralı, conflict, rate limit, timeout ve sunucu hataları aynı şekilde ele alınmaz. Kalıcı hata düzeltilir, geçici hata sınırlı tekrar edilir, belirsiz sonuç ise yan etki sorgulanmadan yeniden gönderilmez.

HTTP ve API hata karar tablosu

Uygulama, risk ve kanıt

• Uygulama: Sipariş Entegrasyonunda Hata Sınıfları Nasıl Ayrılır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 57. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Retry, Backoff ve Jitter Nasıl Tasarlanır?

429, seçili 5xx, bağlantı ve timeout hataları idempotency koşuluyla sınırlı tekrar edilebilir. Retry-After varsa öncelenir; üstel bekleme, jitter, maksimum deneme ve circuit breaker tekrar fırtınasını sınırlar.

AWS timeout, retry, backoff ve jitter rehberi, bu karar için kullanılan birincil teknik veya hukuki doğrulama noktasıdır; erişim tarihi 15.07.2026’dır.

Retry ve backoff politikası

Uygulama, risk ve kanıt

• Uygulama: Retry, Backoff ve Jitter Nasıl Tasarlanır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 58. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Kuyruk, Backpressure ve Dead-Letter Queue Neden Gereklidir?

Kuyruk ani hacmi tamponlar, backpressure tüketici kapasitesine göre giriş hızını sınırlar, DLQ ise normal yolla işlenemeyen olayları ayırır. Kuyruk yaşı ve en eski mesaj, yalnız toplam adetten daha erken risk sinyali verir.

Kuyruk ve DLQ metrik tablosu

Uygulama, risk ve kanıt

• Uygulama: Kuyruk, Backpressure ve Dead-Letter Queue Neden Gereklidir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 59. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

API Limitleri ve Yüksek Sipariş Hacmi Nasıl Yönetilir?

Kanal bazlı token bucket, kontrollü paralellik, öncelik kuyruğu ve cursor tabanlı tarama kullanılır. Yeni sipariş ve kritik durum trafiği, geçmiş rapor veya düşük öncelikli backfill yüzünden aç bırakılmamalıdır.

IETF HTTP Semantics standardı, bu karar için kullanılan birincil teknik veya hukuki doğrulama noktasıdır; erişim tarihi 15.07.2026’dır.

Uygulama, risk ve kanıt

• Uygulama: API Limitleri ve Yüksek Sipariş Hacmi Nasıl Yönetilir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 60. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Sipariş Mutabakatı Nasıl Yapılır?

Pazaryeri, OMS, ERP, WMS, kargo ve e-Belge kayıtları order, line ve package düzeyinde karşılaştırılır. Eksik, mükerrer, durum farkı, toplam farkı ve gecikme ayrı hata sınıfları olarak sahiplenilir.

Sipariş mutabakat matrisi

Uygulama, risk ve kanıt

• Uygulama: Sipariş Mutabakatı Nasıl Yapılır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 61. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Sipariş Entegrasyonunda Güvenlik Nasıl Sağlanır?

TLS, secret kasası, en az ayrıcalık, düzenli anahtar döndürme, webhook doğrulama, replay koruması, giriş doğrulama ve audit trail birlikte uygulanır. IP allowlist tek başına kimlik doğrulama yerine geçmez.

OWASP API Security Top 10 2023, bu karar için kullanılan birincil teknik veya hukuki doğrulama noktasıdır; erişim tarihi 15.07.2026’dır.

Uygulama, risk ve kanıt

• Uygulama: Sipariş Entegrasyonunda Güvenlik Nasıl Sağlanır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 62. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

KVKK Açısından Sipariş Verisi Nasıl Korunmalıdır?

Adres, telefon, e-posta ve fatura alanları yalnız gerekli amaç ve süreyle işlenir. Erişim rol bazlı sınırlandırılır, loglar maskelenir, dış aktarım ve silme süreçleri kayıt altına alınır; somut yükümlülük hukuk uzmanıyla doğrulanır.

KVKK veri güvenliği yükümlülükleri, bu karar için kullanılan birincil teknik veya hukuki doğrulama noktasıdır; erişim tarihi 15.07.2026’dır.

Güvenlik ve KVKK kontrol tablosu

Uygulama, risk ve kanıt

• Uygulama: KVKK Açısından Sipariş Verisi Nasıl Korunmalıdır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 63. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Çoklu Mağaza ve Tenant İzolasyonu Neden Önemlidir?

Yanlış tenant bağlamı başka mağazaya sipariş, etiket, fatura veya müşteri verisi gönderebilir. Her sorgu ve iş emri tenant ID, store ID ve doğru credential scope ile çalışır; çapraz erişim negatif testlerle engellenir.

Uygulama, risk ve kanıt

• Uygulama: Çoklu Mağaza ve Tenant İzolasyonu Neden Önemlidir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 64. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Hangi Log, Metric, Trace ve Audit Verileri Tutulmalıdır?

Log olay ayrıntısını, metric eğilimi, trace servisler arası yolu, audit trail ise yetkili değişikliğin önceki ve sonraki değerini gösterir. Correlation ID ortak olmalı; ham müşteri payloadı ve fatura tokenı loga yazılmamalıdır.

OpenTelemetry log, metric ve trace dokümantasyonu, bu karar için kullanılan birincil teknik veya hukuki doğrulama noktasıdır; erişim tarihi 15.07.2026’dır.

Uygulama, risk ve kanıt

• Uygulama: Hangi Log, Metric, Trace ve Audit Verileri Tutulmalıdır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 65. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Hangi Sipariş KPI’ları Takip Edilmelidir?

Gecikme, eksik sipariş, mükerrer işleme, manuel dokunuş, durum başarısı, etiket hatası, fatura reddi, geç kargolama, iptal süresi, iade çevrimi, refund gecikmesi ve mutabakat farkı birlikte izlenmelidir. Her metrik için formül, kaynak, sahip ve aksiyon eşiği bulunur.

Bu bölümün dışındaki ayrıntılar için sipariş KPI ve raporlama tasarımı rehberi konu sınırını tamamlar.

KPI formül, sahip ve eşik tablosu

KPI formülleri ve aksiyon mantığı

Uygulama, risk ve kanıt

• Uygulama: Hangi Sipariş KPI’ları Takip Edilmelidir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 66. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Sipariş Entegrasyonu İçin Olay Müdahale Planı Nasıl Hazırlanır?

Plan algılama, etki sınırı, kill switch, kuyruk dondurma, manuel iş, iletişim, recovery, backfill ve postmortem adımlarını içerir. Hangi koşulda otomatik yazmanın duracağı ve kimin karar vereceği önceden belirlenir.

Olay müdahale RACI tablosu

Uygulama, risk ve kanıt

• Uygulama: Sipariş Entegrasyonu İçin Olay Müdahale Planı Nasıl Hazırlanır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 67. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Kampanya Döneminde Sipariş Entegrasyonu Nasıl Hazırlanır?

Trafik tahmini, kapasite testi, API bütçesi, kuyruk tüketimi, etiket ve fatura sağlayıcı kapasitesi, nöbet ve change freeze birlikte planlanır. Temsili yük testleri gerçek müşteri verisi kullanmadan yapılır.

Bu bölümün dışındaki ayrıntılar için kampanya dönemi operasyon planı rehberi konu sınırını tamamlar.

Kampanya hazırlık tablosu

Senaryo 6: Kampanya sırasında API kesintisi ve backfill

Uygulama, risk ve kanıt

• Uygulama: Kampanya Döneminde Sipariş Entegrasyonu Nasıl Hazırlanır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 68. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Mevcut Entegratörden Yeni Sisteme Geçiş Nasıl Yapılır?

Geçiş keşif, mapping, paralel okuma, tek yazan sistem, cutover, backfill ve rollback aşamalarına bölünür. Eski ve yeni çözüm aynı anda fatura veya etiket yazamaz; yetki devri kesin bir zaman ve kanıtla yapılır.

Bu bölümün dışındaki ayrıntılar için sistem taşıma ve cutover hazırlığı rehberi konu sınırını tamamlar.

Uygulama, risk ve kanıt

• Uygulama: Mevcut Entegratörden Yeni Sisteme Geçiş Nasıl Yapılır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 69. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Pilot ve Test Planı Nasıl Hazırlanır?

Pilot tek mağaza ve sınırlı hacimle; farklı kimlik, paket, kargo, fatura, iptal, iade ve hata senaryolarını kapsar. Başarı eşiği, durdurma koşulu ve rollback adımı canlıya çıkmadan imzalanır.

Pilot ve go-live kriterleri

Somut test matrisi

Uygulama, risk ve kanıt

• Uygulama: Pilot ve Test Planı Nasıl Hazırlanır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 70. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Yapay Zekâ Sipariş Operasyonunda Nasıl Kullanılabilir?

Yapay zekâ maskelenmiş logları özetleme, gecikme anomalisi bulma, iade nedenlerini sınıflandırma, kapasite tahmini ve destek yanıt taslağı üretmede yardımcı olabilir. Çıktı öneridir; gerçek sistem durumu ve süreç sahibi onayıyla uygulanır.

Uygulama, risk ve kanıt

• Uygulama: Yapay Zekâ Sipariş Operasyonunda Nasıl Kullanılabilir? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 71. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Hangi Kararlar Yapay Zekâya Tamamen Bırakılmamalıdır?

Sipariş iptali, iade reddi, refund, fatura düzeltmesi, hukuki değerlendirme ve yüksek tutarlı uyuşmazlıklar koşulsuz AI kararına bırakılmamalıdır. Confidence, açıklama, guardrail, insan onayı ve değiştirilemez audit kaydı gerekir.

Uygulama, risk ve kanıt

• Uygulama: Hangi Kararlar Yapay Zekâya Tamamen Bırakılmamalıdır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 72. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Pazaryeri Sipariş Entegrasyon Sağlayıcısına Hangi Sorular Sorulmalıdır?

Sağlayıcıdan yalnız özellik listesi değil, canlı kanal kapsamı, kimlik modeli, gecikme ölçümü, idempotency, backfill, kargo/fatura/iade sınırı, güvenlik, veri çıkışı ve olay müdahale kanıtı istenmelidir. Sorular bu makalede sipariş akışıyla sınırlıdır.

Sağlayıcı doğrulama soruları

Uygulama, risk ve kanıt

• Uygulama: Pazaryeri Sipariş Entegrasyon Sağlayıcısına Hangi Sorular Sorulmalıdır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 73. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Pazaryeri Sipariş Entegrasyonu Maliyeti Nelerden Oluşur?

Toplam maliyet abonelikten büyüktür: kanal ve mağaza, sipariş hacmi, kullanıcı, kurulum, mapping, kargo, e-Belge kontörü, ERP/WMS, log, güvenlik, migrasyon, destek ve SLA kalemleri ayrı hesaplanır. İlk yıl ile devam eden işletim maliyeti ayrıştırılır.

Bu bölümün dışındaki ayrıntılar için paket ve özel proje ayrımını değerlendirme rehberi konu sınırını tamamlar.

15.07.2026 canlı paket sayfasında Büyüme paketinde pazaryeri sipariş görünürlüğü ve kargo/iade süreç görünürlüğü, Profesyonel pakette gelişmiş pazaryeri ile stok/depo görünürlüğü, Enterprise’da özel entegrasyon ve SLA yer alır. e-Fatura/e-Arşiv opsiyonel gösterildiğinden standart paket, kontör ve özel proje aynı maliyet sayılmaz.

Toplam sahip olma maliyeti tablosu

Uygulama, risk ve kanıt

• Uygulama: Pazaryeri Sipariş Entegrasyonu Maliyeti Nelerden Oluşur? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 74. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

SoloMarketplace Sipariş Yönetiminde Nasıl Konumlanır?

15.07.2026 canlı sayfasında SoloMarketplace için sipariş fişi, durum, kargo, fatura, iptal/iade ve işlem geçmişi yönleri anlatılırken üst bölümde YAKINDA!!! ibaresi vardır. Bu nedenle kapsam duyurulan yön olarak okunmalı; canlılık, kanal ve sözleşme koşulları satın alma öncesi doğrulanmalıdır.

Uygulama, risk ve kanıt

• Uygulama: SoloMarketplace Sipariş Yönetiminde Nasıl Konumlanır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 75. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Canlı sayfadaki ürün yönünü değerlendirmek için SoloMarketplace sipariş yönetimi kapsamını inceleyin; YAKINDA!!! ibaresi nedeniyle aktif kanal, sipariş, kargo, fatura, iptal/iade ve SLA kapsamını yazılı teyit edin.

SoloCommerce ile Kendi Siteniz ve Pazaryeri Siparişleri Nasıl Birlikte Planlanır?

Ortak SKU ve sipariş görünürlüğü; site ile pazaryeri akışlarını aynı operasyon modelinde karşılaştırmayı sağlar. Paket sayfasında Büyüme için pazaryeri sipariş görünürlüğü, Profesyonel için gelişmiş operasyon, Enterprise için özel entegrasyon ve SLA ayrımı görülür; e-Belge ise opsiyonel kapsamdır.

Uygulama, risk ve kanıt

• Uygulama: SoloCommerce ile Kendi Siteniz ve Pazaryeri Siparişleri Nasıl Birlikte Planlanır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 76. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Kendi sitesi ve pazaryeri operasyonunu birlikte planlayan işletmeler SoloCommerce e-ticaret paketlerini canlı kapsam, opsiyonel e-Belge, özel entegrasyon ve toplam maliyet bakımından karşılaştırabilir.

30-60-90 Günlük Sipariş Entegrasyonu Yol Haritası Nasıl Olmalıdır?

İlk 30 gün veri modeli, kimlik, durum ve güvenlik; 31-60 gün kargo, fatura, iptal, iade ve mutabakat; 61-90 gün kapasite, olay müdahalesi ve ölçümlü iyileştirmeye ayrılır. Her fazın go/no-go kararı kanıtla verilir.

30-60-90 gün yol haritası

Uygulama, risk ve kanıt

• Uygulama: 30-60-90 Günlük Sipariş Entegrasyonu Yol Haritası Nasıl Olmalıdır? için yetkili kaynak, kimlik, tetik ve hedef durum sözleşmesini yazılı tanımlayın.
• Risk: Eksik, mükerrer, sıra dışı veya belirsiz sonuçları 77. bölümün istisna koduyla sınıflandırın.
• Kontrol: Yazmadan önce sürüm ve geçişi, yazdıktan sonra hedef read-back sonucunu doğrulayın.
• Ölçüm: Gecikme, hata, retry, manuel dokunuş ve mutabakat farkını mağaza ve paket bazında izleyin.
• Kanıt: Correlation ID, maskeli log, API sonucu ve sorumlu onayını aynı olay zincirinde saklayın.

Pazaryeri Sipariş Entegrasyonu Kontrol Listesi

Kontrol listesi, kapsamdan güvenliğe kadar tasarım ve işletim kararlarını canlıya çıkmadan görünür kılar. Maddeler yalnız işaretlenmez; her biri sahip, kanıt ve gözden geçirme tarihiyle takip edilir.

Strateji ve kapsam

• Strateji ve kapsam: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Strateji ve kapsam: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Strateji ve kapsam: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Strateji ve kapsam: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Strateji ve kapsam: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Strateji ve kapsam: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Strateji ve kapsam: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Kanal ve mağaza

• Kanal ve mağaza: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kanal ve mağaza: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kanal ve mağaza: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kanal ve mağaza: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kanal ve mağaza: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kanal ve mağaza: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kanal ve mağaza: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Sipariş veri modeli

• Sipariş veri modeli: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Sipariş veri modeli: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Sipariş veri modeli: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Sipariş veri modeli: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Sipariş veri modeli: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Sipariş veri modeli: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Sipariş veri modeli: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Kimlik ve eşleştirme

• Kimlik ve eşleştirme: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kimlik ve eşleştirme: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kimlik ve eşleştirme: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kimlik ve eşleştirme: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kimlik ve eşleştirme: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kimlik ve eşleştirme: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kimlik ve eşleştirme: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Webhook, polling ve stream

• Webhook, polling ve stream: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Webhook, polling ve stream: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Webhook, polling ve stream: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Webhook, polling ve stream: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Webhook, polling ve stream: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Webhook, polling ve stream: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Webhook, polling ve stream: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Pagination ve zaman

• Pagination ve zaman: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Pagination ve zaman: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Pagination ve zaman: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Pagination ve zaman: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Pagination ve zaman: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Pagination ve zaman: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Pagination ve zaman: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Idempotency ve olay sırası

• Idempotency ve olay sırası: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Idempotency ve olay sırası: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Idempotency ve olay sırası: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Idempotency ve olay sırası: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Idempotency ve olay sırası: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Idempotency ve olay sırası: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Idempotency ve olay sırası: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Durum modeli

• Durum modeli: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Durum modeli: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Durum modeli: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Durum modeli: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Durum modeli: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Durum modeli: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Durum modeli: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Stok rezervasyonu

• Stok rezervasyonu: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Stok rezervasyonu: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Stok rezervasyonu: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Stok rezervasyonu: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Stok rezervasyonu: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Stok rezervasyonu: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Stok rezervasyonu: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Paketleme ve depo

• Paketleme ve depo: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Paketleme ve depo: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Paketleme ve depo: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Paketleme ve depo: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Paketleme ve depo: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Paketleme ve depo: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Paketleme ve depo: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Kargo, etiket ve takip

• Kargo, etiket ve takip: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kargo, etiket ve takip: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kargo, etiket ve takip: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kargo, etiket ve takip: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kargo, etiket ve takip: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kargo, etiket ve takip: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kargo, etiket ve takip: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Fatura ve e-Belge

• Fatura ve e-Belge: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Fatura ve e-Belge: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Fatura ve e-Belge: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Fatura ve e-Belge: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Fatura ve e-Belge: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Fatura ve e-Belge: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Fatura ve e-Belge: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

İptal

• İptal: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• İptal: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• İptal: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• İptal: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• İptal: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• İptal: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• İptal: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

İade ve tersine lojistik

• İade ve tersine lojistik: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• İade ve tersine lojistik: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• İade ve tersine lojistik: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• İade ve tersine lojistik: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• İade ve tersine lojistik: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• İade ve tersine lojistik: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• İade ve tersine lojistik: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Müşteri bildirimi

• Müşteri bildirimi: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Müşteri bildirimi: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Müşteri bildirimi: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Müşteri bildirimi: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Müşteri bildirimi: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Müşteri bildirimi: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Müşteri bildirimi: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Kuyruk ve retry

• Kuyruk ve retry: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kuyruk ve retry: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kuyruk ve retry: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kuyruk ve retry: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kuyruk ve retry: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kuyruk ve retry: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Kuyruk ve retry: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Mutabakat

• Mutabakat: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Mutabakat: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Mutabakat: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Mutabakat: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Mutabakat: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Mutabakat: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Mutabakat: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Güvenlik ve KVKK

• Güvenlik ve KVKK: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Güvenlik ve KVKK: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Güvenlik ve KVKK: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Güvenlik ve KVKK: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Güvenlik ve KVKK: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Güvenlik ve KVKK: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Güvenlik ve KVKK: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Gözlemlenebilirlik

• Gözlemlenebilirlik: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Gözlemlenebilirlik: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Gözlemlenebilirlik: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Gözlemlenebilirlik: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Gözlemlenebilirlik: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Gözlemlenebilirlik: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Gözlemlenebilirlik: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Test ve canlıya geçiş

• Test ve canlıya geçiş: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Test ve canlıya geçiş: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Test ve canlıya geçiş: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Test ve canlıya geçiş: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Test ve canlıya geçiş: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Test ve canlıya geçiş: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Test ve canlıya geçiş: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Maliyet ve SLA

• Maliyet ve SLA: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Maliyet ve SLA: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Maliyet ve SLA: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Maliyet ve SLA: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Maliyet ve SLA: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Maliyet ve SLA: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• Maliyet ve SLA: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

AI ve insan onayı

• AI ve insan onayı: kapsamı ve sahibi yazılı belirle; kontrol 1 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• AI ve insan onayı: yetkili veri kaynağını kaydet; kontrol 2 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• AI ve insan onayı: başarı kanıtını tanımla; kontrol 3 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• AI ve insan onayı: negatif testi çalıştır; kontrol 4 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• AI ve insan onayı: alarm ve aksiyon eşiği ata; kontrol 5 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• AI ve insan onayı: geri dönüş adımını doğrula; kontrol 6 için sorumlu ve kanıt bağlantısı kaydedildi mi?
• AI ve insan onayı: gözden geçirme tarihini planla; kontrol 7 için sorumlu ve kanıt bağlantısı kaydedildi mi?

Sık Yapılan Sipariş Entegrasyonu Hataları

Sipariş entegrasyonu hataları çoğunlukla kimlikleri karıştırmak, HTTP kabulünü sonuç sanmak, tekrarları kontrolsüz yapmak ve fiziksel olayları dijital kayıtlardan ayırmamak nedeniyle oluşur. Her hata için önleyici kontrol ve sahip belirlenmelidir.

Sıkça Sorulan Sorular

Pazaryeri sipariş entegrasyonu nedir?

Pazaryeri sipariş entegrasyonu; kanaldaki sipariş, kalem ve paket kayıtlarını güvenli biçimde iç sisteme alan, kargo ve fatura adımlarını yöneten, iptal ve iade sonuçlarını geri eşitleyen çift yönlü operasyon katmanıdır.

Eksik sipariş nasıl bulunur?

Eksik sipariş yalnız hata logundan bulunamaz; periyodik backfill, kanal ve OMS adet karşılaştırması, kimlik boşluğu, gecikme yüzdelikleri ve günlük mutabakat birlikte kullanılır. Alarm, etkilenen mağaza ve zaman penceresini gösterecek kadar somut olmalıdır.

Mükerrer sipariş nasıl önlenir?

Pazaryeri, OMS, ERP, WMS, kargo ve e-Belge kayıtları order, line ve package düzeyinde karşılaştırılır. Eksik, mükerrer, durum farkı, toplam farkı ve gecikme ayrı hata sınıfları olarak sahiplenilir.

Sipariş durumları nasıl eşleştirilir?

Alıcı tipi, unvan, VKN/TCKN, adres, ürün adı, SKU, adet, birim, KDV, indirim, kargo ve toplamlar kalem bazında doğrulanır. Pazaryeri verisiyle ürün kaynağı çelişirse yetkili alan ve istisna kuralı önceden belirlenir.

Kampanya döneminde sipariş entegrasyonu nasıl hazırlanır?

Trafik tahmini, kapasite testi, API bütçesi, kuyruk tüketimi, etiket ve fatura sağlayıcı kapasitesi, nöbet ve change freeze birlikte planlanır. Temsili yük testleri gerçek müşteri verisi kullanmadan yapılır.

Uygulamaya Geçmeden Önce

Güvenilir pazaryeri sipariş entegrasyonu, siparişi tek ekrana taşımaktan çok daha fazlasıdır: kimlikleri korur, geçişleri doğrular, kargo ve faturayı fiziksel sonuçla bağlar, iptal ve iadeyi izlenebilir kılar, başarısız adımları güvenle yeniden işler. Küçük pilot ve ölçümlü iyileştirme, pazarlama vaadinden daha değerlidir.

Önce sipariş, kalem ve paket kimliklerinizi; ortak durum modelinizi; source of truth sahipliğini; kargo ve fatura tetiklerini; iptal ve iade istisnalarını çıkarın. Tek kanal ve sınırlı sipariş hacmiyle webhook, polling, duplicate, paket bölme, fatura ret, iptal, iade ve mutabakat testlerini çalıştırın.

Duyurulan özellikleri ve canlılık durumunu kargo ve fatura bağlantılı pazaryeri entegrasyonu sayfasında; site ile pazaryeri birlikteliğini paket sayfasında; e-Belge akışını ilgili hizmet sayfasında karşılaştırın. API sınırlarını, özel proje ihtiyacını, güvenliği, veri çıkışını ve toplam maliyeti yazılı kanıtla doğrulamadan karar vermeyin.