E-Ticaret Firması ile Pazaryeri Sipariş Mutabakatı Projesinin Maliyeti Nasıl Belirlenir?

Pazaryeri mutabakat entegrasyonu maliyeti neye bağlıdır?

Pazaryeri mutabakat entegrasyonu maliyeti; bağlı kanal sayısı, veri çeşitliliği, kaynak sistemler, eşleştirme kuralları, hata yönetimi ve test kapsamının birlikte değerlendirilmesiyle belirlenir. Bir projede yalnızca sipariş toplamı ile muhasebe kaydı karşılaştırılırken başka bir projede ürün satırları, kargo kesintileri, iadeler, komisyonlar ve farklı ödeme hareketleri de kontrol edilebilir. Dolayısıyla aynı pazaryeri sayısına sahip iki işletme aynı entegrasyon kapsamına sahip olmayabilir. Teklifin maliyet mantığı, bağlantı adedinden önce hangi ticari kayıtların hangi doğrulama kurallarıyla işleneceğini açıklamalıdır.

Mutabakat projesini standart entegrasyondan ayıran işler

Standart bağlantı çoğu zaman veriyi bir sistemden diğerine taşımaya odaklanırken mutabakat, iki veya daha fazla kaydın aynı işleme ait olup olmadığını belirleyen kurallar gerektirir. Bu nedenle entegrasyon ve veri yönetimi yaklaşımı içinde veri kaynağı, eşleştirme anahtarı ve hata durumlarının önceden tanımlanması önemlidir. Proje teklifinde yalnızca API bağlantısı değil, verinin nasıl yorumlanacağı ve fark bulunduğunda hangi sürecin çalışacağı da görünür olmalıdır.

• Bağlanacak pazaryeri ve iç sistem sayısı
• Sipariş, iade ve finans veri çeşitliliği
• Eşleştirme ve doğrulama kurallarının karmaşıklığı
• Hata yönetimi ve manuel inceleme ihtiyacı
• Test, geçmiş veri ve canlıya geçiş kapsamı

Veri değerli bir şeydir ve sistemlerin kendisinden daha uzun süre yaşar.- Tim Berners-Lee

Hangi pazaryeri verileri mutabakata dahil edilmelidir?

Mutabakat kapsamına, işletmenin finansal ve operasyonel sonucunu değiştiren tüm gerekli kayıt türleri dahil edilmelidir. Temel sipariş bilgileri yanında sipariş satırları, indirimler, kargo bedelleri, iptaller, iadeler, komisyonlar ve pazaryerinin sağladığı ödeme veya hakediş verileri ayrı veri kümeleri olarak ele alınabilir. Her kanal aynı alanları aynı isim ve yapıda sunmayabileceği için veri envanteri kanal bazında hazırlanmalıdır. Böylece pazaryeri sipariş mutabakatı teklifi, belirsiz bir “sipariş entegrasyonu” kalemi yerine işlenecek gerçek veri kümelerini gösterir.

Veri envanteri finans sürecine göre oluşturulmalı

İşletme hangi kayıtların muhasebe, ERP veya finans uygulamasında karşılık bulması gerektiğini belirlemelidir. Kurumsal e-ticaret mimarisinde pazaryeri bağlantılarının diğer sistemlerle ilişkisini değerlendirmek için ERP, CRM, pazaryeri ve ödeme entegrasyonlarının birlikte planlanması yararlı bir çerçeve sunar. Mutabakat kapsamı oluşturulurken yalnızca mevcut API alanları değil, finans ekibinin gerçekten kontrol etmek istediği sonuçlar da esas alınmalıdır. Gereksiz alanların taşınması yerine karar ve kayıt süreçlerinde kullanılan veriler önceliklendirilmelidir.

• Sipariş ve sipariş satırı kayıtları
• İndirim, kampanya ve kupon bilgileri
• İade ve iptal hareketleri
• Komisyon ve diğer kesinti verileri
• Ödeme, hakediş veya tahsilat kayıtları

Kanal sayısı entegrasyon maliyetini nasıl etkiler?

Kanal sayısı proje maliyetini etkiler; ancak her yeni kanalın aynı oranda ek iş yarattığı varsayılmamalıdır. Bazı pazaryerleri benzer veri modelleri ve hazır bağlantılar sunarken bazıları farklı sipariş durumları, iade akışları, komisyon yapıları veya API sınırları nedeniyle ek eşleme ve test gerektirebilir. Bu yüzden teklif kanal başına bağlantı maliyetini gösterebilir, fakat bunun yanında kanalın özel veri farkları da ayrıca değerlendirilmelidir. Çok kanallı satış entegrasyonu büyüdükçe ortak bir iç veri modelinin kurulması, kanal özelindeki farklılıkların yönetimini kolaylaştırabilir.

Kanal başına kapsam ile ortak altyapı ayrılmalı

Teklifte ortak entegrasyon çekirdeği ile her pazaryerine özgü çalışmalar ayrı gösterildiğinde yeni kanal eklemenin gerçek etkisi daha anlaşılır hale gelir. Örneğin sipariş kimliği, müşteri, toplam tutar ve durum alanları ortak modele aktarılabilirken komisyon veya iade detayları kanal bazında farklı işlenebilir. e-ticaret sitesinde gerekli entegrasyonların planlanması sırasında kullanılan sistemlerin tamamı çıkarılırsa pazaryeri bağlantılarının ERP, ödeme, kargo ve diğer uygulamalar üzerindeki bağımlılıkları da önceden görülebilir.

• Her kanal için bağlantı ve yetkilendirme çalışması
• Kanal özelindeki veri alanı farklılıkları
• Ortak veri modeline dönüştürme ihtiyacı
• API limitleri ve veri çekme yöntemleri
• Kanal bazlı test senaryoları

İade ve iptal kayıtları nasıl eşleştirilmelidir?

İade ve iptal kayıtları, yalnızca sipariş durumunun değiştirilmesiyle değil, ilgili sipariş satırı ve finans hareketiyle ilişkilendirilerek eşleştirilmelidir. Bir sipariş tamamen iptal edilebilir, yalnızca belirli ürünler iade edilebilir veya pazaryeri farklı zamanlarda birden fazla düzeltme kaydı oluşturabilir. Bu nedenle iade verisi entegrasyonu, hangi olayın hangi siparişe ve hangi satıra bağlandığını açık biçimde izlemelidir. Finans tarafında komisyon veya ödeme düzeltmesi oluşuyorsa bu hareketin de aynı mutabakat zincirinde görülebilmesi gerekir.

Durum kodları ve zaman sırası birlikte değerlendirilmelidir

Farklı pazaryerlerinin “iptal”, “iade talebi”, “iade tamamlandı” veya benzeri durumları farklı anlamlara gelebilir. Entegrasyon projesinde bu durumlar işletmenin kullandığı ortak iç durum modeline eşlenmelidir. Ayrıca aynı sipariş için sonradan gelen olayların önceki kayıtları nasıl güncelleyeceği belirlenmelidir. Yanlış sırada işlenen bir iade veya iptal, sipariş toplamı ile finans kaydının farklı görünmesine yol açabilir. Teklifte olay geçmişinin tutulup tutulmayacağı ve düzeltme kayıtlarının nasıl izleneceği açıklanmalıdır.

• Tam ve kısmi iptal senaryoları
• Tam ve kısmi iade hareketleri
• Sipariş satırı ile iade bağlantısı
• Komisyon ve tahsilat düzeltmeleri
• Durum değişikliklerinin zaman sırası

Komisyon ve finans verisi akışı nasıl kapsamlandırılır?

Pazaryeri komisyon verisi aktarımı, mutabakat projesinde sipariş toplamından ayrı bir finans veri akışı olarak ele alınmalıdır. Pazaryerinin satış, hizmet, kargo veya başka başlıklar altında oluşturduğu kesintiler işletmenin finans sisteminde farklı hesaplara karşılık gelebilir. Bu nedenle yalnızca toplam komisyon tutarını taşımak yerine hangi kesintinin hangi sipariş veya ödeme dönemiyle ilişkili olduğu belirlenmelidir. Finans veri akışı projesi kapsamında muhasebe veya ERP tarafındaki hedef alanlar, belge mantığı ve kayıt zamanı da teknik keşifte netleştirilmelidir.

ERP ve muhasebe tarafındaki hedef kayıtlar tanımlanmalı

Mutabakat entegrasyonu pazaryerinden veri almakla tamamlanmaz; verinin iç sistemde hangi kayıt türüne dönüşeceği de belirlenmelidir. ERP bağlantısının nasıl yapılandırılacağı konusunda kurumsal yazılımın ERP ve CRM sistemleriyle entegrasyonu veri eşleme ve sistem sorumluluklarını değerlendirmek için kullanılabilir. Finans ekibinin kullandığı hesap planı, belge türleri veya kontrol raporları özel iş kuralı gerektiriyorsa bunlar standart bağlantı kapsamından ayrı gösterilmelidir. Böylece teklif teknik bağlantı ile işletmeye özgü finans mantığını birbirinden ayırır.

• Komisyon ve kesinti türlerinin sınıflandırılması
• Sipariş veya ödeme dönemiyle ilişkilendirme
• ERP veya muhasebe hedef alanlarının belirlenmesi
• Belge ve kayıt oluşturma kurallarının tanımlanması
• Finans raporunda kullanılacak kontrol alanları

Veri farklarını kim incelemeli ve nasıl onaylamalı?

Veri farklarının incelenmesi yalnızca yazılım ekibinin sorumluluğunda bırakılmamalıdır; teknik ekip farkı tespit ederken operasyon ve finans ekipleri ticari anlamını değerlendirip kabul kararını vermelidir. Bir sipariş toplamının farklı görünmesi entegrasyon hatasından kaynaklanabileceği gibi pazaryerindeki kesinti veya sonradan oluşan iade nedeniyle de ortaya çıkabilir. Bu nedenle hangi sistemin hangi veri alanında esas kaynak olduğu proje başında belirlenmelidir. Mutabakat sistemi farkı göstermeli, fakat işletme kuralına göre nihai karar verecek rol de açıkça tanımlanmalıdır.

Esas kayıt kaynağı ve sorumluluk matrisi kurulmalı

Sipariş kimliği için pazaryeri, stok için ERP, muhasebe kaydı için finans sistemi esas alınabilir; ancak bu dağılım her işletmede aynı olmak zorunda değildir. Proje keşfinde kaynak sistemler ve veri sahipleri belirlenerek farkların kime yönlendirileceği tanımlanmalıdır. E-ticaret operasyon otomasyonu içinde otomatik eşleşen kayıtlarla manuel inceleme gerektiren kayıtların ayrılması önemlidir. Böylece ekipler yalnızca istisnalara odaklanabilir ve yazılımın hangi durumda otomatik karar vereceği, hangi durumda insan onayı bekleyeceği netleşir.

• Her veri alanı için esas kaynak sistem
• Teknik hata ile ticari farkın ayrılması
• Operasyon ekibinin inceleme sorumluluğu
• Finans ekibinin kabul ve düzeltme rolü
• Manuel onay gerektiren istisnaların tanımı

Hazır bağlantı ve özel iş kuralı maliyeti nasıl ayrılır?

Hazır pazaryeri bağlantısı kullanılabilen durumlarda teknik bağlantı süresi azalabilir; ancak bu durum mutabakat kurallarının da hazır olduğu anlamına gelmez. Standart entegrasyon siparişleri çekebilir fakat işletmenin komisyon hesapları, iade süreçleri veya finans sistemi için özel eşleştirme mantığı gerekebilir. Bu nedenle pazaryeri entegrasyon firması teklifinde lisanslı veya hazır bağlantının kapsamı ile işletmeye özel geliştirmeler ayrı kalemler halinde gösterilmelidir. Böylece hazır konektörün sağladığı teknik avantaj ile özel iş kurallarının yaratacağı proje yükü birbirine karıştırılmaz.

Özel geliştirme gerektiren durumlar önceden belirlenmeli

Hazır bağlantının desteklemediği alanlar, kanal özelindeki olaylar, farklı ERP veri modeli veya kuruluş içi onay süreçleri özel geliştirme gerektirebilir. Ayrıca mevcut konektörün yalnızca güncel siparişleri işlemesi halinde geçmiş kayıt aktarımı için ayrı yöntem hazırlanması gerekebilir. Teklifte hangi fonksiyonların mevcut bileşenle çözüldüğü, hangi alanların konfigürasyon gerektirdiği ve hangi işlerin kod geliştirme istediği belirtilirse bakım sorumluluğu da daha net anlaşılır. Bu ayrım, projenin ileride yeni kanallara genişletilmesinde de bütçe planlamasını kolaylaştırır.

• Hazır konektörün desteklediği veri alanları
• Konfigürasyon ile çözülebilen kurallar
• Özel kod gerektiren eşleştirmeler
• Geçmiş veri aktarımı için ek yöntemler
• Bakım ve sürüm güncelleme sorumlulukları

Hata yönetimi ve geçmiş kayıt aktarımı nasıl planlanmalı?

Hata yönetimi, entegrasyonun yalnızca başarılı işlemleri değil işlenemeyen veya eksik kalan kayıtları da takip edebilmesini sağlamalıdır. API kesintısı, eksik alan, geçersiz durum veya hedef sistem hatası nedeniyle işlenemeyen kayıtların yeniden denenmesi, kuyrukta tutulması veya manuel incelemeye yönlendirilmesi gerekebilir. Pazaryeri sipariş mutabakatı teklifi bu davranışları açıklamalı ve hata kaydının kim tarafından izleneceğini belirtmelidir. Geçmiş kayıt aktarımı isteniyorsa canlı akıştan farklı olarak hangi dönemlerin ve hangi veri türlerinin geriye dönük işleneceği de ayrı kapsamlandırılmalıdır.

Geçmiş veri ile canlı akış aynı süreç değildir

Canlı entegrasyon yeni olayları düzenli biçimde işlerken geçmiş veri aktarımı yüksek hacimde toplu kayıtların yeniden okunmasını ve mevcut finans kayıtlarıyla eşleştirilmesini gerektirebilir. Tarihsel veride artık değişmiş durum kodları veya eski kanal yapıları bulunabileceği için ek dönüşüm kuralları gerekebilir. Hata yönetiminde de her kayıt sonsuz kez tekrar edilmemeli; yeniden deneme sayısı, uyarı mekanizması ve manuel müdahale noktası belirlenmelidir. Bu kurallar, operasyon ekibinin entegrasyon sorunlarını görünür biçimde takip etmesini sağlar.

• Başarısız kayıtların loglanması
• Otomatik yeniden deneme kuralları
• Manuel inceleme kuyruğu
• Geçmiş kayıt döneminin belirlenmesi
• Hata uyarısı ve sorumlu ekip tanımı

Mutabakat entegrasyonunun doğruluğu nasıl test edilir?

Entegrasyonun doğru çalıştığı, yalnızca siparişlerin sisteme düşmesiyle değil; önceden tanımlanmış mutabakat senaryolarının beklenen sonucu üretmesiyle test edilmelidir. Normal sipariş, kısmi iade, tam iptal, komisyon kesintisi, geç gelen durum güncellemesi ve bağlantı hatası gibi örnekler test planına alınabilir. Her senaryoda kaynak pazaryeri kaydı, entegrasyon çıktısı ve finans sistemindeki sonuç karşılaştırılmalıdır. Böylece e-ticaret sipariş eşleştirme yazılımının yalnızca veri taşıdığı değil, iş kurallarını doğru uyguladığı da doğrulanabilir.

Operasyon ve finans ekipleri kabul testine katılmalı

Teknik ekip API çağrılarını ve veri eşlemelerini kontrol ederken operasyon ekibi sipariş yaşam döngüsünü, finans ekibi ise komisyon, iade ve ödeme sonuçlarını doğrulamalıdır. Proje tekliflerinin test ve sorumluluk kapsamını değerlendirirken e-ticaret firması teklifinin teknik kapsam ve sözleşme açısından değerlendirilmesi kabul kriterlerini yazılı hale getirmek için destekleyici olabilir. Test sonuçları, başarılı ve başarısız senaryolarla kayıt altına alınmalı; canlıya geçiş için hangi hataların kapatılması gerektiği önceden belirlenmelidir.

• Normal sipariş ve ödeme senaryosu
• Kısmi iade ve tam iptal senaryoları
• Komisyon ve kesinti kontrolleri
• API kesintisi ve yeniden deneme testi
• Operasyon ve finans kabul kontrolleri

Mutabakat entegrasyonu teklifi için ne hazırlanmalı?

Teklif istemeden önce kullanılan pazaryerleri, e-ticaret altyapısı, ERP veya muhasebe sistemi, günlük işlem hacmi ve mutabakat yapılacak veri türleri derlenmelidir. Ayrıca iadelerin nasıl işlendiği, komisyon bilgilerinin nereden alındığı, finans ekibinin bugün hangi raporları karşılaştırdığı ve mevcut süreçte hangi farkların manuel çözüldüğü açıklanmalıdır. Bu bilgiler e-ticaret pazaryeri mutabakat entegrasyonu maliyeti için daha gerçekçi bir ön keşif yapılmasını sağlar. Firmalar aynı teknik ve operasyonel brief üzerinden çalıştığında teklifler yalnızca bağlantı sayısına göre değil, çözülmesi gereken gerçek iş kurallarına göre karşılaştırılabilir.

Kısa bir teknik keşif listesi teklifleri karşılaştırılabilir yapar

İşletme her pazaryeri için erişim yöntemini, kullanılan sipariş ve finans alanlarını, geçmiş veri ihtiyacını, günlük yaklaşık hareket hacmini ve kabul testine katılacak ekipleri paylaşmalıdır. Teklifte kanal bağlantısı, veri eşleme, hata yönetimi, geçmiş kayıt aktarımı, özel iş kuralları ve test çalışmalarının ayrı ayrı gösterilmesi istenebilir. Böylece hazır bağlantı kullanan çözümle özel geliştirme ağırlıklı çözüm arasındaki kapsam farkı anlaşılır. Mutabakat projesinin başarısı yalnızca teknik entegrasyona değil, operasyon ve finans ekiplerinin hangi kayıtları nasıl kabul edeceğinin önceden tanımlanmasına bağlıdır.

• Kullanılan pazaryerleri ve erişim yöntemleri
• ERP veya muhasebe sistemi bilgileri
• Günlük sipariş, iade ve finans hareket hacmi
• Mevcut manuel mutabakat kuralları
• Test ve kabul sürecine katılacak ekipler