İçeriğe geç
eMc Bilişim

Pazar Yeri

Sipariş, İade ve Entegrasyonlar

Çok satıcılı bir siparişte zorluk, siparişi almak değil; onu doğru parçalara ayırmak, iadeyi doğru kaleme bağlamak ve dış sistemlerle olan alışverişi sessiz hatalar bırakmadan yürütmektir.

Açıklayıcı sistem şeması — ürün ekranı değildir.
  1. 01 · Müşteri siparişi

    Müşteri tarafında tek bir sipariş deneyimi görülebilir; sepet birden fazla satıcıdan oluşmuş olsa da bu deneyim bütün kalabilir.

  2. 02 · Satıcı parçalarına ayrım

    Tek müşteri siparişi, operasyon tarafında satıcıya özel sipariş parçalarına dönüşebilir.

  3. 03 · Satıcı kabul / hazırlık

    Her satıcı yalnız kendi kapsamındaki kalemler üzerinde işlem yapar; hangi durumların kullanılacağı projede yapılandırılır.

  4. 04 · Sevkiyat ve takip

    Gönderi ve takip olayları ilgili satıcıya ve ilgili sipariş parçasına bağlanır.

  5. 05 · İade / iptal talebi

    Talep ilgili kaleme ya da sipariş parçasına bağlanır; tam veya kısmi olması ve uygunluk tanımlı kurallara bağlıdır.

  6. 06 · Düzeltme / geri ödeme sonucu

    İade veya iptalin sonucu ile finansal düzeltme ilişkili ama aynı olay değildir; burada evrensel bir sağlayıcı ya da ödeme modeli iddia edilmez.

  7. 07 · Senkron + istisna

    Dış sistemler olay alır ve olay döner; başarısız ya da sırası bozuk olaylar görünür bir istisna yoluna düşer.

Durum adları, iade uygunluğu ve tahsilat modeli projeye göre değişir. Bu zincir, tek bir doğru akış değil, kararların nerede verildiğini gösteren bir çerçevedir.

Bu sipariş neden ilerlemiyor?

Operasyonda kaybedilen zaman genellikle burada başlar. Nedeni seçtiğinizde satıcının ne gördüğünü, operatörün ne yapabileceğini ve sistemin hangi izi bıraktığını birlikte okuyabilirsiniz.

Açıklayıcı sistem şeması — ürün ekranı değildir.

Olası nedenler

Durum adları ve geçiş kuralları projede tanımlanır. Buradaki nedenler, sabit bir durum listesi değil, operasyonda sık karşılaşılan tıkanma tipleridir.

Neden

Sipariş parçası ilgili satıcıya düşmüş ancak kabul, hazırlık ya da sevkiyat adımı henüz tamamlanmamıştır. Hangi adımın zorunlu olduğu projede tanımlanır.

Satıcının gördüğü

Satıcı yalnız kendi parçasını ve beklenen adımı görür; başka satıcının kalemi bu listede yer almaz.

Operatör aksiyonu

Operatör bekleyen parçayı ana siparişle birlikte görür ve gerekirse satıcıyı bilgilendirir.

Sistem izi

Parçanın hangi durumda ne kadar beklediği kayıt altındadır; ana sipariş bu bilgiyle birlikte okunur.

Açıklayıcı sistem şeması — ürün ekranı değildir.

Tek müşteri siparişi, birden fazla operasyon parçası

Müşterinin gördüğü bütünlük ile operasyonun ihtiyaç duyduğu ayrım aynı şey değildir. Bu iki katman birbirine karışırsa yanlış satıcı yanlış kalem üzerinde işlem yapar.

Müşteri tarafı bütün kalabilir

Müşteri deneyimi tek sipariş olarak sürdürülebilir; operasyonel bölünme müşteriye karmaşa olarak yansımak zorunda değildir.

Operasyon satıcı bazlıdır

Hazırlık, sevkiyat ve iade işleri her satıcının kendi kapsamı içinde yürür.

Kapsam dışına işlem yok

A satıcısı, B satıcısının kalemleri üzerinde işlem yapamaz; listeler ve yetkiler buna göre ayrılır.

Durumlar ayrışabilir

Bir parça sevk edilmişken diğeri hazırlıkta olabilir; ana sipariş bu farkı gizlemez.

Referans doğru olmalı

Sevkiyat, iade ve istisna kayıtları doğru satıcıya ve doğru sipariş kalemine bağlanır.

Operatör bütünü görür

Operatör ana siparişi ve ona bağlı satıcı parçalarını birlikte inceleyebilir.

Ana siparis ve satici parcalari
Açıklayıcı sistem şeması — ürün ekranı değildir.

Çok satıcılı sipariş

  1. 01Müşteri siparişi
  2. 02Satıcı A parçası
  3. 03Satıcı B parçası
  4. 04Parça durumları
  5. 05Birleşik görünüm
Ana siparis ve satici parcalari. Ana musteri siparisi ile satici bazli alt parcalarin ve parca bazli durumlarin birlikte izlenmesi. Operator rolü, Masaustu görünümü. Görsel kanıt henüz eklenmedi.
Satici siparis listesi
Açıklayıcı sistem şeması — ürün ekranı değildir.

Satıcı sipariş parçası

  1. 01Sipariş parçası
  2. 02Hazırlık
  3. 03Sevkiyat
  4. 04Teslim
  5. 05İade
Satici siparis listesi. Saticiya dusen siparis parcalarinin yonetimi. Backoffice rolü, Masaustu görünümü. Görsel kanıt henüz eklenmedi.

Sipariş durumu tek bir etiket değildir

Durum, bir kelime değil; hangi işlemin yapılabileceğini belirleyen bir kuraldır. Bu nedenle geçişlerin tanımı, kaydın geçmişi ve geçersiz denemelerin nasıl ele alındığı önem taşır.

  1. 01 · Durum kümesi yapılandırılır

    Sabit ve evrensel bir durum listesi iddia edilmez. Hangi durumların, hangi sırayla kullanılacağı projede tanımlanır.

  2. 02 · Aksiyon kalem düzeyindedir

    İşlemler çoğunlukla sipariş parçası ya da kalem düzeyinde yapılır; ana sipariş bunların bileşimidir.

  3. 03 · İptal uygunluğa bağlıdır

    İptalin mümkün olup olmadığı kaydın güncel durumuna ve tanımlı kurallara bağlıdır; her durumda iptal edilebilir denmez.

  4. 04 · Geçmiş korunur

    Durum değişiklikleri kim, ne zaman ve hangi kaynakla bilgisiyle saklanır.

  5. 05 · Geçersiz geçiş istisnadır

    Uygun olmayan ya da sırası bozuk bir geçiş sessizce uygulanmaz; görünür bir istisna olarak açılır.

Siparis ve iade istisna kuyrugu
Açıklayıcı sistem şeması — ürün ekranı değildir.

Sipariş ve iade istisnası

  1. 01Olay tespiti
  2. 02Sipariş parçası
  3. 03Satıcı / müşteri bağlamı
  4. 04Müdahale
  5. 05Kapanış / iz
Siparis ve iade istisna kuyrugu. Satici bazli gecikme, iptal, iade ve itiraz inceleme akisi. Operator rolü, Masaustu görünümü. Görsel kanıt henüz eklenmedi.

İade, siparişin aynasını tersine çevirmek değildir

İade kendi başına bir dosyadır: bağlı olduğu kalem, gerekçesi, kararı ve sonucu vardır. Finansal düzeltme ise bu dosyaya bağlı ama ayrı bir kayıttır.

Talep kaleme bağlanır

İade talebi ilgili satıcıya ve ilgili sipariş kalemine/parçasına bağlanır; siparişin tamamına genellenmek zorunda değildir.

Tam ve kısmi ayrımı

Bir siparişte yalnız bazı kalemler iade edilebilir; kısmi iade ile tam iade farklı sonuçlar üretir.

Gerekçe ve uygunluk

İade gerekçeleri ve uygunluk kuralları yapılandırılır; süre, ürün tipi ve politika projeye özgüdür.

Kimin karar verdiği değişir

Kararın satıcıda mı, operatörde mi ya da iki aşamada mı olacağı proje iş akışına bağlıdır.

İade durumu ≠ finansal düzeltme

İade dosyasının durumu ile geri ödeme veya hakediş düzeltmesi ayrı ama birbirine bağlı kayıtlardır.

Geçmiş yeniden yazılmaz

Orijinal sipariş ve iade geçmişi silinmez; sonuç yeni kayıtlarla eklenir.

Müşteriye anlamlı görünürlük

Müşteri dosyanın güncel durumunu anlamlı bir düzeyde görebilir; iç değerlendirme notları dışarı açılmaz.

Iade dosyasi gorunumu
Açıklayıcı sistem şeması — ürün ekranı değildir.

İade dosyası

  1. 01Talep
  2. 02Kalem + satıcı
  3. 03İnceleme
  4. 04Karar
  5. 05Finansal düzeltme
Iade dosyasi gorunumu. Iade dosyasi, bagli siparis kalemi, gerekce, guncel durum ve karar izi. Operator rolü, Masaustu görünümü. Görsel kanıt henüz eklenmedi.
Satici iade akisi
Açıklayıcı sistem şeması — ürün ekranı değildir.

Satıcı iade akışı

  1. 01Talep
  2. 02Satıcı inceleme
  3. 03Ürünün karşılanması
  4. 04Karar
  5. 05Finansal düzeltme
Satici iade akisi. Iade taleplerinin incelenmesi ve sonuclandirilmasi. Backoffice rolü, Masaustu görünümü. Görsel kanıt henüz eklenmedi.
Açıklayıcı sistem şeması — ürün ekranı değildir.

Entegrasyon bağlantı değil, veri sahipliği + olay akışıdır

Soru “hangi sistemle konuşuyoruz” değil, “hangi veri kimin, hangi olay kimi tetikliyor” sorusudur.

Merkez

Pazar Yeri Çekirdeği

Sipariş, sipariş parçası ve iade dosyası çekirdekte durur. Dış sistemler bu kayıtlara olay gönderir ya da bu kayıtlardan olay alır.

  • Satıcı / ERP

    Ürün, stok, fiyat ya da sipariş verisi satıcı sisteminden gelebilir veya oraya iletilebilir.

  • Kargo

    Gönderi oluşturma ve takip olayları ilgili sipariş parçasına bağlanır.

  • Ödeme sağlayıcısı

    Tahsilat ve/veya satıcı ödemesi ayrı sağlayıcı yetenekleriyle yürür; model projeye özgüdür.

  • Fatura / muhasebe

    Belge üretimi ve muhasebe aktarımı ayrı bir veri alanı olarak tanımlanır.

  • Diğer dış servisler

    Bildirim, pazaryeri kanalları veya raporlama gibi ek servisler aynı olay disiplinine bağlanır.

Her veri alanının bir sahibi olur

Stok, fiyat, sipariş durumu ya da müşteri verisi için kaynağın hangisi olduğu tanımlanmadan entegrasyon kurulmaz.

Taşıma yöntemi bağlı sisteme göre değişir

API, webhook, düzenli sorgulama, dosya aktarımı ya da manuel giriş; hangisinin kullanılacağı karşı sistemin yeteneğine bağlıdır.

Tahsilat ile hakediş ayrı konudur

Müşteriden tahsilat modeli ile satıcı ödemesi ve mutabakat aynı akış değildir; tek bir evrensel para akışı sunulmaz.

Sağlayıcı ve mevzuat projeye özgüdür

Dış sağlayıcının yetenekleri ve hukuki/finansal model projeye göre netleşir; burada taahhüt edilmez.

Sessiz hata yok: olay kuyruğu, tekrar deneme, iz kaydı

Entegrasyonlarda asıl risk hata almak değil, hatanın görünmemesidir. Bir olay işlenemediğinde bunun nerede durduğu ve kimin ne yapacağı belli olmalıdır.

Olay kaydı

Gelen ve giden her olay, içeriği ve zamanıyla birlikte kaydedilir.

Tekilleştirme

Aynı olayın birden çok kez iletilmesi durumunda kayıt tekrar işlenmez.

Tekrar deneme

Geçici hatalarda tanımlı bir tekrar deneme politikası uygulanır.

Görünür istisna yolu

Tekrar eden başarısızlık sonrası kayıt istisna/manuel inceleme listesine düşer; sessizce kaybolmaz.

İş kaydıyla ilişki

Her olay ilgili sipariş, sipariş parçası ya da iade dosyasıyla ilişkilendirilir.

Son hata ve sıradaki aksiyon

Son hata mesajı, son deneme zamanı ve beklenen sonraki adım görünür durumdadır.

Yetkili müdahale

Yeniden deneme veya kapatma yalnız yetkili kullanıcı tarafından, gerektiğinde gerekçesiyle yapılır.

Entegrasyon olay sagligi
Açıklayıcı sistem şeması — ürün ekranı değildir.

Entegrasyon olay akışı

  1. 01Gelen / giden olay
  2. 02Doğrulama + dedup
  3. 03İşleme
  4. 04Retry
  5. 05İstisna / çözüm
Entegrasyon olay sagligi. Gelen/giden olaylar, basarisiz kayitlar, tekrar denemeler ve bagli is kaydi. Operator rolü, Masaustu görünümü. Görsel kanıt henüz eklenmedi.

Aynı olay, üç farklı görünüm

Bir sevkiyat ya da iade olayı tek bir kayıttır; ancak müşteri, satıcı ve operatör bu kaydın farklı kesitlerini görür.

Müşteri

Sipariş ve iade durumunu bütünlüklü bir düzeyde görür; varsa gönderi bilgisine ulaşır. İç operasyon ayrıntıları müşteriye açılmaz.

Satıcı

Yalnız kendi sipariş parçalarını, hazırlık ve sevkiyat işlerini, kendi kalemlerine ait iade görevlerini görür.

Operatör

Ana siparişi, satıcı parçalarını, istisnaları ve entegrasyon izini birlikte görür; müdahale kapsamı yetkiye bağlıdır.

Bu akış hangi sayfalara bağlanır?

Sık sorulanlar

Kısa yanıtlar

Müşteri tarafındaki sipariş bütün kalabilirken operasyon tarafında satıcıya özel parçalar oluşturulur. Her parça yalnız ilgili satıcının kalemlerini içerir ve kendi durumunu taşır. Parçalama kuralları ve durum kümesi projede yapılandırılır.

Sipariş ve iade akışınızı uçtan uca netleştirelim

Siparişin satıcı parçalarına nasıl ayrılacağını, iade kurallarının nasıl tanımlanacağını, hangi verinin kaynağının hangi sistem olduğunu ve hatalı olayların hangi istisna yolundan yürüyeceğini görüşmede birlikte belirleyelim.

Demo Talep Et