B2B E-İhracatta Çok Para Birimli ve Yerelleştirilmiş Checkout Mimarisi

B2B E-İhracatta Çok Para Birimli ve Yerelleştirilmiş Checkout Mimarisi

Yazar: Kumsal AjansOluşturulma: Güncellenme: 9 dk okuma
Henüz puanlanmadı Puanınız:

Blog yazısı içeriği

B2B e-ihracatta checkout, alıcının yalnızca teslimat adresini girip ödeme yaptığı son ekran değildir. Ülke, müşteri, kullanıcı rolü, para birimi, fiyat listesi, vergi statüsü, teslimat biçimi, ödeme koşulu ve belge gereksinimi bu aşamada tek bir ticari karara dönüşür. Bu nedenle başarılı bir B2B e-ihracat checkout mimarisi; kullanıcı arayüzü, iş kuralları, entegrasyonlar ve denetim kayıtlarının birlikte tasarlanmasını gerektirir.

Alıcı, siparişin hangi para birimiyle oluşturulduğunu, kurun nasıl belirlendiğini, hangi vergilerin veya ek maliyetlerin uygulandığını ve toplam yükümlülüğünü açıkça görebilmelidir. Satıcı tarafında ise siparişin ERP’ye doğru cari, fiyat, vergi, stok, teslimat ve belge verileriyle aktarılması gerekir. Bu iki beklentiyi aynı akışta karşılayan yapı, uluslararası satış sürecini hem anlaşılır hem de yönetilebilir hâle getirir.

B2B e-ihracat checkout mimarisi neden standart bir ödeme sayfasından farklıdır?

Perakende e-ticarette checkout çoğunlukla ürün toplamı, adres, kargo ve kart ödemesi etrafında ilerler. B2B satışta aynı müşteri kuruluşunun satın almacı, finans yöneticisi ve onay yetkilisi farklı yetkilere sahip olabilir. Bir kullanıcı yalnızca sipariş hazırlarken diğeri bütçe limitine göre onay verebilir. Müşteriye özel sözleşme fiyatı, miktar basamağı, vadeli ödeme, kredi limiti veya belirli teslimat koşulları da devreye girebilir.

Uluslararası satış bu yapıya hedef ülkenin dili, para birimi, vergi yaklaşımı, adres biçimi, gümrük bilgileri ve kullanılabilir ödeme yöntemlerini ekler. Dolayısıyla checkout, değişkenleri son anda hesaplayan bağımsız bir ekran değil; ürün keşfi ve sepetten ERP kabulüne kadar uzanan sipariş yaşam döngüsünün kontrollü bir aşaması olmalıdır.

B2B E-İhracat Checkout Karar Akışı
B2B E-İhracat Checkout Karar Akışı

Çok para birimli fiyatlandırma nasıl kurgulanmalıdır?

İlk karar, alıcıya gösterilen para birimi ile siparişin bağlayıcı para biriminin aynı olup olmadığıdır. Sadece bilgilendirme amacıyla dönüştürülen tutar ile faturaya ve tahsilata esas tutar birbirine karıştırılmamalıdır. Checkout içinde fiyat para birimi, vergi para birimi, ödeme para birimi ve ERP kayıt para birimi ayrı alanlar olarak modellenebilir.

Fiyat listesini kur dönüşümünden ayırın

Her ülke fiyatını ana para biriminden anlık olarak çevirmek pratik görünse de ticari gerçekliği her zaman yansıtmaz. Navlun, pazar maliyeti, distribütör marjı, yuvarlama ve sözleşme hükümleri ülkeye özel fiyat listelerini gerekli kılabilir. Bu nedenle sistem önce müşteriye atanmış geçerli fiyat listesini aramalı; tanımlı liste yoksa yetkili kur dönüşümü gibi açık bir yedek kurala başvurmalıdır.

Avrupa Merkez Bankası referans kurlarını her iş günü yayımlar; ancak bu oranların bilgi amaçlı olduğunu ve işlem kuru olarak kullanılmasının tavsiye edilmediğini belirtir. Bu ayrım, checkout tasarımında kur kaynağı kadar satış kurunun nasıl üretildiğini de açıklamayı gerekli kılar. Kur kaynağı, alış veya satış yönü, marj, geçerlilik zamanı ve yuvarlama kuralı birlikte kaydedilmelidir. Güncel kur verisinin niteliği için Avrupa Merkez Bankasının kur açıklamaları incelenebilir.

Kuru sipariş anında sabitleyin

Teklif hazırlanırken görülen tutarın sipariş onayında değişmesi güven kaybı yaratır. Sistem; kurun hangi anda sabitlendiğini, ne kadar süre geçerli olduğunu ve süre dolduğunda ne yapılacağını göstermelidir. “Kur 30 dakika geçerlidir” gibi bir bilgi tek başına yeterli değildir. Süre dolunca yeniden fiyatlama yapılacağı, kullanıcının onayının tekrar isteneceği ve önceki tutarın sipariş geçmişinde korunacağı da tanımlanmalıdır.

  • Kaynak para birimi ve sipariş para birimi ayrı tutulmalıdır.
  • Kullanılan kur, zaman damgası ve kural sürümü kaydedilmelidir.
  • Ondalık basamak ve yuvarlama ürün, vergi ve genel toplam düzeyinde tutarlı olmalıdır.
  • İade ve alacak dekontunda kullanılacak kur politikası önceden belirlenmelidir.

Yerelleştirme dil çevirisinin ötesinde neyi kapsar?

Yerelleştirilmiş checkout; metinleri çevirmekten daha geniştir. Tarih ve sayı biçimi, ondalık ayırıcı, adres alanlarının sırası, posta kodu zorunluluğu, şirket ve vergi numarası etiketleri, telefon formatı, teslimat seçenekleri ve yasal onay metinleri ülkeye göre değişebilir. Mobil arayüzde uzun şirket unvanları, çok satırlı adresler ve farklı alfabeler de test edilmelidir.

Dil ve ülke birbirine zorunlu biçimde bağlanmamalıdır. Almanya’daki bir satın almacı İngilizce arayüz kullanmak isteyebilir; buna rağmen teslimat ve vergi kuralları Almanya’ya göre çalışmalıdır. Arayüz dili kullanıcı tercihinden, ticari ve yasal kurallar ise teslimat ülkesi, fatura ülkesi, şirket kaydı ve işlem türünden türetilmelidir. Kumsal Ajans’ın e-ticaret içerikleri, satış deneyiminin farklı bileşenlerini planlamak isteyen ekipler için tamamlayıcı bir çerçeve sunar.

Vergi ve belge kuralları checkout’a nasıl taşınır?

Vergi hesaplaması yalnızca ülke seçimine bağlanmamalıdır. Satıcının yerleşik olduğu ülke, ürün veya hizmet türü, teslimat ve fatura adresi, alıcının işletme statüsü, geçerli vergi numarası ve teslim şekli sonucu etkileyebilir. Avrupa Komisyonu, AB’de işletmeden işletmeye yapılan işlemlerin çoğunda KDV faturasının zorunlu olduğunu ve ulusal kuralların da uygulanabildiğini açıklar. Ayrıca bazı işlemlerde vergiyi ödeme sorumluluğu alıcıya geçebilir. Genel çerçeve için Avrupa Komisyonunun işletmeler için KDV rehberi dikkate alınmalı; somut ülke ve işlem kuralları vergi uzmanlarıyla doğrulanmalıdır.

Checkout bu hukuki değerlendirmeyi kullanıcıdan beklemek yerine gerekli verileri toplamalı ve tanımlı kuralları açıklanabilir biçimde çalıştırmalıdır. Vergi numarasının yalnızca biçimsel kontrolü yeterli olmayabilir; doğrulama sonucu, doğrulama zamanı ve kullanılamayan servis durumunda izlenecek istisna akışı kaydedilmelidir.

  • Ürün satırı bazında vergi sınıfı ve oranı gösterilmelidir.
  • Vergi hariç ara toplam, vergi ve vergi dâhil toplam ayrıştırılmalıdır.
  • Tersine vergi veya istisna uygulanıyorsa gerekçesi sipariş kaydına eklenmelidir.
  • Proforma, ticari fatura, paketleme listesi ve menşe belgesi gibi çıktılar ülke ve sipariş tipine göre üretilmelidir.

Teslimat ve ödeme seçenekleri hangi kurallarla belirlenir?

Her taşıyıcı, depo veya ödeme yöntemi her ülke ve sipariş için uygun değildir. Ürün ağırlığı ve hacmi, tehlikeli madde statüsü, çıkış deposu, teslimat ülkesi, minimum sipariş tutarı ve Incoterms tercihi kullanılabilir teslimat seçeneklerini etkiler. Checkout yalnızca seçilebilir seçenekleri göstermeli; uygun olmayan seçeneğin nedenini operasyon ekibinin görebileceği şekilde kaydetmelidir.

Ödeme tarafında kart, banka transferi, açık hesap, akreditif veya tahsilat bağlantısı gibi seçenekler müşteri segmentine göre yetkilendirilebilir. Vadeli ödeme seçeneği gösterilmeden önce ERP’den cari risk, kullanılabilir kredi limiti ve gecikmiş bakiye kontrol edilebilir. Sonuç olumsuzsa sipariş tamamen engellenmek yerine finans onayına yönlendirilebilir. Tutar veya limit temelli kararların nasıl modellenebileceği, B2B siparişlerde onay akışı içeriğinde ayrıntılı biçimde ele alınmaktadır.

Rol ve müşteri bazlı yetkilendirme neden gereklidir?

B2B hesabı tek bir kullanıcıdan ibaret değildir. Kuruluş yöneticisi yeni kullanıcı davet edebilir; satın almacı sepet hazırlayabilir; bölüm yöneticisi belirli tutara kadar onay verebilir; finans kullanıcısı faturaları görebilir. Yetkiler ekran görünürlüğünün yanında fiyat listesi, iskonto, teslimat adresi, ödeme koşulu, belge erişimi ve sipariş limiti üzerinde de uygulanmalıdır.

Müşteri hiyerarşisi; merkez şirket, şube, teslimat noktası ve alt hesapları kapsayabilir. Kullanıcı yalnızca yetkili olduğu cari hesapları ve adresleri seçebilmelidir. Fiyatın hangi kurala göre oluştuğu da destek ekiplerinin anlayabileceği biçimde açıklanmalıdır. Sözleşmeli fiyat ve indirim önceliklerinin tasarımı için bayi portalında özel fiyat ve iskonto kuralları rehberinden yararlanılabilir.

Karar alanıAna veri kaynağıTemel kontrolAlıcıya gösterim
Fiyat ve kurERP / fiyat motoruListe, geçerlilik, yuvarlamaPara birimi, kur zamanı, toplam
Vergi ve belgeVergi kural motoruÜlke, statü, ürün sınıfıMatrah, vergi, gerekçe
TeslimatERP / lojistik servisiDepo, ülke, ağırlık, IncotermsSeçenek, süre, maliyet
ÖdemeERP / ödeme kuruluşuLimit, risk, yöntem uygunluğuKoşul, vade, ödeme durumu
Sipariş aktarımıE-ticaret / ERPTekil anahtar, kabul, hata kuyruğuSipariş no, durum, sonraki adım

ERP entegrasyonu sipariş bütünlüğünü nasıl korur?

Checkout’ta görülen ürün, stok, fiyat, kur, cari, ödeme koşulu ve belge bilgilerinin sistemler arasında çelişmemesi gerekir. Hangi veri için ERP’nin, e-ticaret platformunun veya başka bir servisin ana kaynak olduğu veri sözlüğünde tanımlanmalıdır. Örneğin ürün içeriği PIM’den, kullanılabilir stok ERP’den, ödeme sonucu ödeme kuruluşundan gelebilir.

Sipariş gönderildiğinde yalnızca “başarılı” yanıtına güvenilmemelidir. Tekrarlanan isteğin ikinci sipariş yaratmasını önleyen benzersiz işlem anahtarı kullanılmalı; zaman aşımı durumunda sonuç sorgulanmalı ve başarısız kayıtlar kontrollü bir hata kuyruğuna alınmalıdır. ERP sipariş numarası alındıktan sonra alıcıya gösterilen durum güncellenmeli; sonraki sevkiyat ve belge görünürlüğü B2B sipariş takip portalı yaklaşımıyla sürdürülebilir.

Güvenli ve denetlenebilir ödeme akışı nasıl kurulmalıdır?

Kart verisi mümkün olduğunca satıcının uygulama alanına alınmamalı; uygun ödeme kuruluşlarının yönlendirmeli veya güvenli gömülü çözümleri değerlendirilmelidir. Bununla birlikte ödeme hizmetinin dışarıdan alınması, e-ticaret sayfasının güvenlik sorumluluğunu tamamen ortadan kaldırmaz. PCI Security Standards Council, ödeme üçüncü tarafa yönlendirilse veya iframe ile sunulsa bile ilgili e-ticaret sayfaları için belirli güvenlik kontrollerinin sürdüğünü belirtir. Güncel kapsam, hizmet sağlayıcı ve güvenlik uzmanlarıyla birlikte PCI SSC’nin e-ticaret sayfalarına ilişkin açıklaması üzerinden değerlendirilmelidir.

Checkout boyunca TLS, güvenli oturum yönetimi, çok faktörlü yönetici erişimi, hassas verilerin maskelenmesi, yetki kontrolleri ve kayıt bütünlüğü uygulanmalıdır. Denetim izi; fiyatı oluşturan kuralı, kullanılan kuru, vergi sonucunu, kullanıcının onaylarını, ödeme yanıtını ve ERP aktarımını kişisel veriyi gereksiz yere çoğaltmadan ilişkilendirmelidir.

Operasyonel istisnalar nasıl yönetilir?

Gerçek süreçlerde kur servisi yanıt vermeyebilir, vergi numarası doğrulanamayabilir, stok sipariş sırasında değişebilir veya ERP geçici olarak erişilemez olabilir. Her hata için aynı genel mesajı göstermek yerine kullanıcının ne yapabileceği belirtilmelidir. Yeniden deneme güvenliyse otomatik tekrar uygulanmalı; ticari karar gerekiyorsa sipariş taslak, incelemede veya finans onayı bekliyor durumuna alınmalıdır.

Operasyon panelinde hata nedeni, etkilenen sipariş, son başarılı adım, tekrar sayısı ve sorumlu ekip görünmelidir. Manuel müdahale sırasında yapılan değişiklik eski değeri silmemeli; kim, ne zaman ve hangi gerekçeyle değiştirdi bilgisi korunmalıdır. Böylece istisna yönetimi e-posta ve elektronik tablo trafiğine bağımlı kalmaz.

Performans ve mobil deneyim satış dönüşümünü nasıl etkiler?

B2B sepetleri yüzlerce satır içerebilir. Fiyat, stok, vergi ve teslimat servislerinin her satır için art arda çağrılması checkout’u yavaşlatır. Toplu sorgular, kontrollü önbellek, değişen alanları yeniden hesaplama ve zaman aşımı politikaları birlikte planlanmalıdır. Kullanıcı beklerken hangi işlemin sürdüğü gösterilmeli; belirsiz yükleme ekranları ve çift tıklamayla yinelenen siparişler önlenmelidir.

Mobil checkout’ta geniş tablolar yerine özet kartları ve açılabilir ayrıntılar kullanılabilir. Ancak masaüstünde gösterilen kur, vergi, teslimat ve toplam bilgileri mobilde gizlenmemelidir. Çok dilli ve mobil uyumlu arayüz; klavye kullanımı, hata odağı, alan etiketleri ve kontrast gibi erişilebilirlik ihtiyaçlarıyla birlikte test edilmelidir.

Uygulama yol haritası nasıl oluşturulur?

Çalışmaya ekran çizmekle değil, ülke ve müşteri senaryolarını çıkarmakla başlanmalıdır. Hangi ülkelerde hangi şirketlerin satış yapacağı, hangi para birimlerinin bağlayıcı olacağı, fiyat ve kur sahipliği, vergi kararları, teslim şekilleri, ödeme yöntemleri ve üretilecek belgeler bir karar matrisi hâline getirilmelidir.

Ardından kullanıcı rolleri, veri kaynakları, entegrasyon sözleşmeleri ve istisna durumları tanımlanır. Pilot kapsam için temsil gücü yüksek birkaç ülke, müşteri tipi ve ödeme yöntemi seçilebilir. Normal akışın yanında kur süresi dolması, stok değişimi, ödeme reddi, ERP zaman aşımı ve kısmi hizmet kesintisi gibi senaryolar da test edilmelidir.

Projeye özel web yazılım yaklaşımı; hazır bir ödeme ekranına iş kurallarını sığdırmak yerine, checkout’u kurumun gerçek satış ve operasyon modeliyle uyumlu biçimde geliştirmeyi sağlar. Başarı ölçümü yalnızca ödeme tamamlanma oranıyla sınırlı tutulmamalı; fiyat uyuşmazlığı, manuel düzeltme, ERP aktarım hatası, sipariş tamamlama süresi ve destek talebi gibi göstergeler de izlenmelidir.

Sonuç: Checkout, uluslararası siparişin karar ve kontrol katmanıdır

Çok para birimli ve yerelleştirilmiş B2B checkout; doğru fiyatı göstermekten daha fazlasını yapar. Ülke, müşteri, kullanıcı, kur, vergi, teslimat, ödeme ve belge kurallarını açıklanabilir bir siparişe dönüştürür. Sağlam ERP entegrasyonu, güvenli ödeme mimarisi, izlenebilir kararlar ve yönetilebilir istisnalar sayesinde alıcı neyi onayladığını bilir; satış, finans ve operasyon ekipleri ise aynı sipariş gerçeği üzerinde çalışır.

Ülke, para birimi, fiyat, vergi, teslimat, ödeme ve ERP gereksinimlerinizi birlikte analiz ederek markanıza ve gerçek işleyişinize uygun B2B e-ihracat checkout mimarisini planlamak için Kumsal Ajans ile iletişime geçin.

Anasayfa

Projelerimiz

Ürünlerimiz

Hizmetlerimiz