Stoktan Faturaya Tek Veri Akışı: E-Ticaret ERP Entegrasyonu Nasıl Kurulur?

E-ticaret ERP entegrasyonu yalnız teknik ekibin iki uygulama arasında bağlantı açması değildir. Ürün kodundan satılabilir stoğa, ödeme durumundan sevkiyat ve yasal belge referansına kadar her bilgi; müşteri deneyimini, finansal kaydı ve günlük operasyonu etkiler. Manuel kopyalama, dağınık tablolar ve görünmeyen aktarım hataları büyüdükçe sorun, “veri gidiyor mu?” sorusundan “hangi kayıt doğru, kim düzeltecek ve nasıl toparlanacağız?” sorusuna dönüşür.

Stoktan faturaya tek veri akışı, bütün veriyi tek uygulamada toplamak anlamına gelmez. Güvenilir model her veri alanı için kayıt otoritesini, iş sahibini, güncelleme yönünü, kabul edilen gecikmeyi, hata telafisini ve mutabakatı belirler. Ürün ticari kodu ERP'de, zengin açıklama e-ticaret platformunda, tahsilat sonucu ödeme sağlayıcısında, yasal belge durumu e-belge sisteminde güvenilir kaynak olabilir.

Bu rehber; süreç haritası, veri sözlüğü, entegrasyon yöntemi, kesinti dayanıklılığı, güvenlik, test, canlıya geçiş ve sağlayıcı seçimi için karar çerçevesi sunar. Amaç “anlık ve hatasız” gibi doğrulanamaz vaatler vermek değil; yanlış veriyi görünür kılan, tekrar işlenmeye dayanıklı ve sistemler arası farkı kapatabilen bir işletim modeli kurmaktır.

E-Ticaret ERP Entegrasyonu Nedir?

ERP, Kurumsal Kaynak Planlama sistemidir; finans, satış, satın alma, stok, üretim veya lojistik gibi işletme kaynaklarını ürünün kapsamına göre yönetir. E-ticaret ERP entegrasyonu ise mağaza ile bu iç süreçler arasında ürün, fiyat, stok, müşteri, sipariş, ödeme, sevkiyat, belge ve iade verisinin tanımlı kurallarla alışverişidir. Entegrasyon, dosya taşımanın ötesinde kimlik, iş kuralı, durum ve hata yönetimidir.

ETBİS E-Ticaret Akademisi ERP entegrasyonu içeriği, hangi verinin entegre edileceği yanında kaynağı, hedefi veya sorumlusu ve güncelleme sıklığının belirlenmesini önerir. Bu yaklaşım aşağıdaki uçtan uca kapsamı bir teknoloji listesi değil, iş akışı olarak okumayı gerektirir.

Veri veya olay	Tipik kaynak	Tipik hedef	İş kontrolü	Hata etkisi
Ürün ve varyant	ERP, PIM veya platform	Mağaza ve kanallar	Kimlik, birim, yayın durumu	Yanlış veya eksik katalog
Fiyat ve vergi	Fiyat motoru veya ERP	Satış kanalları	Net/brüt, KDV, kur, yuvarlama	Yanlış tahsilat ve fark
Satılabilir stok	ERP, WMS veya OMS	Mağaza ve pazaryeri	Depo, rezervasyon, tampon	Fazla satış veya gereksiz kapanma
Sipariş ve ödeme	E-ticaret ve ödeme sağlayıcısı	ERP, OMS ve finans	Dış kimlik, tutar, durum	Mükerrer veya kayıp kayıt
Sevkiyat ve belge	WMS, ERP, kargo, e-belge	Platform ve müşteri ekranı	Paket, takip, UUID, durum	Yanlış bildirim veya finans kuyruğu

Karar çıkarımı: Entegrasyon kapsamını “ERP var” cümlesiyle değil, her nesne ve olay için kaynak, hedef, kontrol ve hata etkisiyle tanımlayın.

Stoktan Faturaya Tek Veri Akışı Ne Anlama Gelir?

Tek veri akışı, tek veritabanı değil, birbirini izleyen olayların güvenilir ve denetlenebilir bir yoldan geçmesidir. Ürün yayına çıkar, müşteri sipariş verir, ödeme veya onay koşulu oluşur, stok ayrılır, sevkiyat hazırlanır ve belge üretilir. Her adımın ayrı kimliği ve durumu korunur; “sipariş tamamlandı” gibi tek bir etikete indirgenmez.

Temsili bir işletmede aşağıdaki matris, her alanın ana kaynağını ve hata davranışını açıklar. Kabul edilen gecikme sabit bir sektör reçetesi değil, iş riski ve kullanıcı beklentisiyle belirlenir.

Veri alanı	Ana kaynak	Tüketen sistem	Yön	Gecikme toleransı	Hata aksiyonu
Ticari ürün kodu	ERP	Platform ve WMS	Dışarı	Yayın öncesi	Karantina ve veri sahibi onayı
SEO açıklaması	E-ticaret platformu	Vitrin	İç kullanım	İçerik planına göre	Eski onaylı sürümü koru
Satılabilir stok	WMS veya ERP	Satış kanalları	Dışarı	Fazla satış riskine göre	Tampon, sınırlı mod veya satış kapatma
Tahsilat sonucu	Ödeme sağlayıcısı	Platform ve ERP	Olay	Sipariş kuralına göre	Sorgula, idempotent yeniden işle
Yasal belge durumu	E-belge sistemi	ERP ve müşteri ekranı	Geri bildirim	Operasyon eşiğine göre	İstisna kuyruğu ve alarm

Karar çıkarımı: “Tek merkez” söylemini kaynak sistem sahipliğiyle karıştırmayın; birleştirilen şey veri tabanı değil, sorumluluk ve olay zinciridir.

ERP, Muhasebe, OMS, WMS, PIM, CRM ve E-Ticaret Platformu Arasındaki Fark Nedir?

Bu sistemlerin işlevleri örtüşebilir, fakat ana sorumlulukları aynı değildir. Muhasebe sistemi finansal kayıt ve raporlamaya, OMS sipariş orkestrasyonuna, WMS depo icrasına, PIM zengin ürün bilgisine, CRM ilişki yönetimine odaklanır. iPaaS veya middleware ise verinin iş sahibi değil, sistemler arasındaki bağlantı ve dönüşüm katmanıdır.

Sistem envanteri aşağıdaki görev ayrımıyla hazırlanmalıdır. Bir yeteneğin bir üründe bulunması, o ürünün otomatik kayıt otoritesi olduğu anlamına gelmez.

Sistem türü	Temel sorumluluk	Tipik ana veri	Alışveriş yapılan veri	Yanlış konumlandırma riski
ERP	Kurumsal kaynak ve ticari süreç	Stok kartı, cari, mali boyut	Ürün, sipariş, stok, belge	Bütün veriyi zorla ERP'ye yığmak
Muhasebe	Finansal kayıt ve rapor	Hesap planı, fiş, bakiye	Satış, tahsilat, belge özeti	Operasyon durumunu finans fişi sanmak
OMS	Sipariş orkestrasyonu	Sipariş ve tahsis durumu	Kanal emri, stok, sevkiyat	ERP siparişiyle bire bir eşlemek
WMS	Depo icrası	Lokasyon ve fiziksel hareket	Toplama, paket, sevkiyat	Fiziksel stoğu satılabilir stok sanmak
PIM	Zengin ürün içeriği	Açıklama, özellik, medya	SKU referansı, kanal içeriği	Ticari fiyat ve bakiyeyi burada yönetmek
CRM	Müşteri ilişkisi	İletişim ve etkileşim	Müşteri, segment, sipariş özeti	Yasal cari kaydıyla karıştırmak
E-ticaret platformu	Vitrin, sepet, checkout	Oturum, sepet, web içeriği	Ürün, fiyat, stok, sipariş	Finansal kayıt otoritesi yapmak

Karar çıkarımı: Her sistem için “hangi kaydı üretir, hangi kaydı yalnız okur ve hangi durumda karar verir?” sorularını yanıtlamadan entegrasyon yönünü seçmeyin.

Hangi İşletmeler ERP Entegrasyonuna İhtiyaç Duyar?

Sipariş adedi tek başına ERP entegrasyonu gereksinimini belirlemez. Kanal ve depo sayısı, fiyat/cari kurallarının karmaşıklığı, üretim veya tedarik bağımlılığı, hata maliyeti ve denetim ihtiyacı birlikte değerlendirilir. Düşük hacimli basit işletmede kontrollü manuel süreç yeterliyken, çok kanallı yapıda aynı yöntem görünmez risk oluşturabilir.

Aşağıdaki karar tablosu, hazır bağlantı ile özel proje arasındaki ilk ayrımı verir. Paket seçimi yaparken güncel entegrasyon ihtiyacına uygun e-ticaret altyapısı seçeneklerini özellik ve proje kapsamı ayrı olacak biçimde karşılaştırın.

İşletme profili	Temel sorun	Entegrasyon derinliği	Başlangıç yaklaşımı	Özel proje ihtiyacı
Tek kanal, düşük karmaşıklık	Az sayıda manuel kayıt	Sınırlı	Dosya veya hazır aktarım	Genellikle düşük
Büyüyen çok kanallı marka	Stok ve durum gecikmesi	Orta	Hazır konektör ve mutabakat	Alan farkına göre
Çoklu depo ve B2B	Tahsis, fiyat, cari onayı	Yüksek	Hibrit API ve olay akışı	Sıklıkla gerekir
Üretim/tedarik bağlı satış	Termin ve backorder	Yüksek	Fazlı özel süreç	İş kuralına bağlı
Yüksek hacim/denetim	Kapasite ve audit	Kurumsal	Queue, gözlemleme, SLA	Analiz ve teklif gerekir

Karar çıkarımı: Manuel süreç ölçülebilir ve kabul edilebilir düzeydeyse aşırı mimari kurmayın; hata etkisi ve bağımlılık arttığında otomasyonu fazlandırın.

ERP Entegrasyonu İhtiyacını Gösteren Belirtiler Nelerdir?

Mükerrer sipariş, kapanmayan gün sonu farkı, stok uyuşmazlığı ve geciken belge birer belirtidir; kök neden yanlış mapping, süreç disiplini, kaynak veri veya entegrasyon hatası olabilir. Önce belirtiyi ölçün, sonra hangi sistemde ve hangi olaydan sonra başladığını bulun. Her sorunu “yeni API gerekir” diye yorumlamak maliyeti artırabilir.

Belirti ile olası kök neden arasındaki ayrım aşağıdaki gibidir.

Belirti	Olası kök neden	Ölçülecek veri	Hızlı kontrol	Kalıcı seçenek
Aynı sipariş iki kez açılıyor	Timeout sonrası kör retry	Dış sipariş ID ve çağrı geçmişi	Idempotency kaydını ara	Benzersiz anahtar ve tekrar cevabı
Site stoğu yüksek kalıyor	Yanlış depo veya gecikmiş olay	Depo bazlı hareket zamanı	Mapping ve queue yaşını karşılaştır	Kaynak/satılabilir formül düzeltmesi
Fiyat tutarı farklı	KDV veya yuvarlama ayrışması	Net, vergi, kur, satır toplamı	İki hesap izini karşılaştır	Tek hesaplayan sistem ve sözleşme
Belge kuyruğu büyüyor	Kalıcı veri doğrulama hatası	Hata kodu ve kayıt yaşı	Retry sınıfını incele	İstisna kuyruğu ve veri sahibi
Destek siparişi bulamıyor	Kimlik/correlation eksikliği	Kaynak ve karşı sistem ID'leri	Uçtan uca arama yap	Correlation ve operasyon ekranı

Karar çıkarımı: Teşhis için şu on beş işareti ölçün: manuel yeniden giriş, farklı SKU, depo farkı, fiyat farkı, negatif stok, overselling, mükerrer sipariş, kayıp sipariş, bekleyen ödeme, görünmeyen iade, kısmi sevkiyat hatası, belge backlog'u, yüksek retry, uzun queue yaşı ve kapanmayan mutabakat farkı.

ERP Entegrasyonunun Amaçları ve Başarı Kriterleri Nasıl Belirlenir?

“Entegrasyon yapalım” ölçülebilir bir hedef değildir. Başarı; iş akışı, veri kalitesi, teknik güvenilirlik ve operasyonel toparlanma açısından ayrı metriklerle tanımlanır. Evrensel yüzde veya saniye hedefi yerine mevcut baz değer, risk toleransı ve müşteri etkisi kullanılır; SLO teknik hizmet hedefini, iş kabul kriteri ise sürecin doğru sonucunu gösterir.

E-ticaret raporlama yaklaşımını entegrasyon baz ölçümüyle birleştirerek aşağıdaki KPI kartını doldurun.

Amaç	Metrik	Baz değer	Hedef yaklaşımı	Veri kaynağı	Sahip
Kayıp siparişi azaltmak	Kaynak-hedef sipariş farkı	Mutabakattan ölçülür	Risk eşiğine göre	Platform ve ERP	Operasyon
Stok tazeliği	Kaynak-hedef güncelleme yaşı	Kanal/depo bazlı	Ürün riskine göre	Event ve stok tablosu	Depo/BT
Mükerreri önlemek	Aynı dış ID kayıt sayısı	Geçmiş analiz	Kritik tolerans	ERP ve idempotency store	BT
İstisnayı hızla çözmek	MTTR ve en yaşlı hata	Ticket/log	Önem seviyesine göre	Alarm ve destek	On-call
Finans farkını kapatmak	Tutar/belge mutabakat farkı	Dönemsel rapor	Mali kabul kuralı	ERP/e-belge	Finans

Karar çıkarımı: Her KPI için formül, kaynak, sıklık, sahip ve ihlal aksiyonu yazılmadıkça hedefi onaylamayın.

Siparişten Faturaya Süreç Haritası Nasıl Çıkarılır?

Süreç haritası yalnız mutlu yolu değil; ödeme başarısızlığı, stok yetersizliği, kısmi sevkiyat, iptal, iade ve ERP kesintisini de gösterir. Her adımda tetikleyici, kaynak, hedef, oluşan kimlik, başarı kanıtı ve hata yolu yazılır. Kod başlamadan önce operasyon, depo ve finans bu haritayı birlikte onaylamalıdır.

Genel sipariş, stok, fatura ve kargo operasyonu ile entegrasyon olaylarını aşağıdaki tabloda ayırın.

Karar çıkarımı: Tek “sipariş tamamlandı” durumu yerine bağımsız sipariş, ödeme, sevkiyat ve belge durum makinelerini ilişkilendirin.

ERP Entegrasyonu Projesinde Kim Hangi Sorumluluğu Üstlenir?

RACI; işi yapanı, nihai hesap veren karar sahibini, danışılanı ve bilgilendirileni ayıran sorumluluk matrisidir. Veri hatasının sahibi ürün veya finans ekibi olabilirken, mesaj teslim hatasının sahibi entegrasyon ekibidir. Tüm yükü tek teknik kişiye vermek hem kabul hem süreklilik riski yaratır.

Temsili RACI matrisi aşağıdaki gibi özelleştirilebilir.

Karar çıkarımı: Her kritik iş paketinde tek bir hesap veren kişi ve ölçülebilir kabul kanıtı bulunmalıdır.

Source of Truth Nedir ve Nasıl Seçilir?

Source of truth veya system of record, belirli bir veri alanında geçerli kaydı üretme ve düzeltme yetkisine sahip sistemdir. Bütün veriler için tek uygulama seçmek gerekmez; her alanın bir otoritesi olmalıdır. İki sistem aynı alanı kuralsız güncellerse ping-pong, eski verinin yeniyi ezmesi ve çözülemeyen çatışma oluşur.

Kaynak kararı, aşağıdaki aday ve çatışma ölçütleriyle verilmelidir.

Karar çıkarımı: Kaynak sistem seçimini teknik kolaylığa değil, kaydı kimin ürettiği, hangi kontrolle onayladığı ve nasıl düzelttiğine bağlayın.

Veri Sahipliği Matrisi Nasıl Hazırlanır?

Teknik kaynak sistem ile iş sahibi farklıdır: ERP fiyatı saklayabilir, fakat ticari ekip fiyat kuralından sorumludur. Veri sahipliği matrisi oluşturma, okuma, güncelleme, pasifleştirme, onay, tüketim ve mutabakat yetkilerini gösterir. Bu matris, özel geliştirme başlamadan önce çatışmaları görünür kılar.

İşletmeye göre doldurulacak örnek şablon şöyledir.

Karar çıkarımı: CRUD yetkileri kadar, kimin fark raporunu kapatacağı ve hangi kanıtla kapatacağı da yazılmalıdır.

Master Data, Reference Data ve Transaction Data Arasındaki Fark Nedir?

Master data ürün, müşteri ve tedarikçi gibi uzun ömürlü ana varlıklardır. Reference data vergi, birim, para birimi ve durum kodu gibi ortak anlam listeleridir; transaction data ise sipariş, ödeme, stok hareketi ve sevkiyat gibi zaman içinde oluşan işlemlerdir. Bu sınıflar aynı sıklık, silme ve retry politikasıyla yönetilmemelidir.

Veri sınıflarının entegrasyon davranışı aşağıdaki gibi ayrılır.

Karar çıkarımı: Ana veride silme yerine pasifleştirmeyi, işlem verisinde değişmez referans ve ters işlem yaklaşımını değerlendirin.

Ürün Kimlikleri, SKU, Barkod ve GTIN Nasıl Eşleştirilir?

İç ürün ID'si veritabanı kimliğidir; SKU işletmenin stok tutma birimi kodu, barkod makinece okunabilen taşıyıcı, GTIN ise ticari öğeyi küresel bağlamda tanımlayan numaradır. Varyant, kanal ve ERP stok kodları ayrıca tutulabilir. Baştaki sıfırı atmak, büyük-küçük harfi değiştirmek veya SKU'yu yeniden kullanmak ilişkiyi bozabilir.

GS1'in resmî GTIN tanımı, numaranın tedarik zincirinde fiyatlanabilen, sipariş edilebilen veya faturalanabilen ticari öğeyi tanımladığını belirtir. Ürün veri kalitesi için SKU, barkod ve varyant hazırlama rehberi de kullanılabilir.

Karar çıkarımı: Kimlikleri tek alanda eritmeyin; kaynak ve karşı sistem ID'lerini değişmez çapraz referansla ilişkilendirin.

Birim, Depo, Vergi, Para Birimi ve Durum Kodları Nasıl Eşleştirilir?

İki sistemde aynı görünen kod aynı anlamı taşımayabilir. “ADET”, “PKT” veya “KOLI” dönüşümü; depo ile fiziksel lokasyon ayrımı; vergi kodu, para birimi ve sipariş durumu için anlam, geçerlilik ve dönüşüm kuralı yazılmalıdır. Bilinmeyen kod varsayılan değere sessizce çevrilmek yerine karantinaya alınmalıdır.

Referans kod mapping tablosu sürümlü ve tarihli tutulmalıdır.

Karar çıkarımı: Dağınık hard-code dönüşümleri yerine sahipli, versiyonlu ve bilinmeyen kod davranışı tanımlı bir referans sözlüğü kullanın.

Veri Sözlüğü ve API Sözleşmesi Nasıl Hazırlanır?

Veri sözlüğü her alanın iş anlamını; API contract ise tarafların istek, cevap, hata, kimlik doğrulama ve davranış sözleşmesini açıklar. Alan adı, tür, uzunluk, zorunluluk, enum, birim, saat dilimi, null anlamı, hassasiyet ve dönüşüm birlikte belgelenmelidir. HTTP 200, iş kaydının doğru oluştuğunu tek başına kanıtlamaz.

OpenAPI 3.2.0 HTTP API'lerini, AsyncAPI 3.1.0 mesaj güdümlü arayüzleri makinece okunabilir biçimde tanımlamak için kullanılabilir. Her iki standart da araç değil sözleşme disiplinidir; gerçek iş kuralı yine ekiplerce onaylanır.

Karar çıkarımı: Sözleşmeye idempotency, pagination, rate limit, correlation ID, hata modeli ve geriye uyumluluk kuralı eklenmeden geliştirmeyi başlatmayın.

API ve Olay Sözleşmeleri Nasıl Versiyonlanır?

Breaking değişiklik mevcut tüketiciyi bozar; alan kaldırma, anlam değiştirme veya zorunlu yeni alan ekleme buna örnektir. Yeni opsiyonel alan çoğu zaman geriye uyumlu olabilir, fakat enum genişlemesi katı tüketiciyi yine bozabilir. Versiyonlama; tüketici envanteri, deprecation dönemi, contract test ve geri dönüş planıyla yönetilir.

Değişiklik sınıfları aşağıdaki karar tablosuyla incelenebilir.

Karar çıkarımı: Eski sürümü kapatma tarihi, son tüketici kanıtı ve rollback tetikleyicisi olmadan deprecation tamamlanmış sayılmaz.

Tek Yönlü ve Çift Yönlü ERP Entegrasyonu Arasındaki Fark Nedir?

Tek yönlü entegrasyonda veri bir kaynaktan hedefe gider; çift yönlü entegrasyonda iki taraf farklı alan veya durumları birbirine iletir. Çift yönlülük otomatik olarak daha gelişmiş değildir: aynı alanı iki sistem güncelliyorsa öncelik, versiyon ve çatışma kuralı gerekir. En yaygın hibrit modelde ürün/fiyat/stok dışarı, sipariş içeri akar.

Yön ve gecikme kararı birlikte verilmelidir.

Karar çıkarımı: “Çift yönlü” yerine hangi alanın hangi yönde ve hangi çatışma politikasıyla aktığını yazılı isteyin.

Gerçek Zamanlı, Yakın Gerçek Zamanlı ve Batch Entegrasyon Nasıl Seçilir?

Gerçek zamanlı akış olayın hemen işlendiği düşük gecikmeli modeli; yakın gerçek zaman kısa kabul penceresini; batch ise kayıtların belirli aralıklarla toplu işlenmesini anlatır. Evrensel saniye sınırı yoktur. Stok ve ödeme daha sıkı, ürün içeriği veya analitik rapor daha geniş gecikme toleransına sahip olabilir.

Seçim tablosu iş riski ve fallback ile birlikte okunmalıdır.

Karar çıkarımı: Her veriyi gerçek zamanlı yapmak yerine, gecikmenin gerçek iş etkisini ve sistem bağımlılığını ölçün.

Push, Pull, Polling ve Webhook Yaklaşımları Nasıl Karşılaştırılır?

Push, kaynağın veriyi hedefe göndermesidir; pull, hedefin veriyi kaynaktan istemesidir. Polling belirli aralıklarla sorgulama, webhook ise bir olay olduğunda hedef URL'ye bildirim gönderme yöntemidir. Webhook teslim garantisi değildir; imza, tekrar, sıra, gözlemleme ve API ile yeniden sorgulama gerekebilir.

Hibrit model, webhook ile değişikliği haber alıp ayrıntıyı yetkili API'den çekebilir.

Karar çıkarımı: Yöntemi moda göre değil, iki tarafın kabiliyeti, çağrı limiti, teslim kanıtı ve toparlanma yolu üzerinden seçin.

API, Webhook, XML, CSV, SFTP ve EDI Ne Zaman Kullanılır?

API istek-cevap arayüzü, webhook olay bildirimi, XML ve CSV veri biçimi, SFTP dosya taşıma kanalı, EDI ise yapılandırılmış iş belgesi değişimi yaklaşımıdır. Dosya tabanlı aktarım “ilkel” olmak zorunda değildir; schema, manifest, checksum, atomik adlandırma ve arşivle güvenilir olabilir. SFTP tek başına iş sözleşmesini veya hatayı çözmez.

Yöntem karşılaştırması şu karar ölçütlerini içerir.

Karar çıkarımı: Dosya adı, encoding, delimiter, schema, partial file, duplicate, arşiv ve hata geri bildirimi yazılı değilse dosya entegrasyonu tamamlanmış değildir.

REST, SOAP ve GraphQL Arasında Nasıl Seçim Yapılır?

REST HTTP kaynakları ve standart yöntemlerle yaygın kullanılan yaklaşım; SOAP sözleşmeli mesajlaşma ve WSDL ekosistemi; GraphQL ise istemcinin ihtiyaç duyduğu alanları sorgulayabildiği şema tabanlı arayüzdür. Hiçbiri her durumda üstün değildir. ERP üreticisinin desteklediği kararlı arayüz, sürüm ömrü ve operasyon kabiliyeti moda tercihten önemlidir.

Protokol seçimi şu tarafsız karşılaştırmayla yapılabilir.

Karar çıkarımı: Güvenlik, bulk, retry, idempotency ve gözlemlenebilirlik protokolden bağımsız tasarım gerektirir.

Noktadan Noktaya, Middleware, iPaaS, ESB ve Event Bus Arasındaki Fark Nedir?

Noktadan noktaya bağlantı iki sistem arasında doğrudan ve hızlı başlayabilir; sistem sayısı arttıkça bağlantı ağı ve değişiklik etkisi büyür. Middleware genel ara katman, iPaaS yönetilen entegrasyon platformu, ESB merkezî servis aracısı, event bus ise üretici ve tüketicileri olaylar üzerinden gevşek bağlayan altyapıdır. Her işletmenin iPaaS veya ESB'ye ihtiyacı yoktur.

Mimari seçeneklerin ölçek, ekip ve maliyet karşılaştırması şöyledir.

Karar çıkarımı: Lisans kadar veri yerleşimi, çıkış planı, gözlemleme ve ekibin gerçekten işletebileceği karmaşıklığı değerlendirin.

Senkron ve Asenkron Entegrasyon Arasındaki Fark Nedir?

Senkron çağrıda istemci yanıtı bekler; asenkron akışta iş kuyruk veya olay üzerinden daha sonra tamamlanabilir. Checkout için bazı anlık doğrulamalar senkron gerekebilir, fakat uzun ERP işlemini kullanıcı isteğine bağlamak gecikme ve kesinti etkisini büyütür. Asenkron model durum ekranı, retry, geri bildirim ve kullanıcı mesajı ister.

İki modelin seçim kriterleri şöyledir.

Karar çıkarımı: Kullanıcının gerçekten beklemesi gereken kontrolleri senkron tutun; geri kalan işi güvenli asenkron akışla ayırmayı değerlendirin.

Olay Güdümlü Mimari ve Mesaj Kuyruğu Ne Sağlar?

Event gerçekleşmiş gerçeği, command yapılması istenen işi, message ise taşınan zarfı anlatır. Olay güdümlü mimari üreticiyle tüketiciyi gevşek bağlayabilir; kuyruk ani yükü tamponlar ve yeniden işleme sağlar. Bunun bedeli duplicate, sıra, şema, kapasite ve gözlemlenebilirlik sorumluluğudur.

Dağıtık sistemlerde exactly-once ifadesini kolay ve mutlak bir platform garantisi saymak yerine, bağlama göre en az bir kez teslim, idempotent işleme ve bağımsız mutabakat birlikte tasarlanır. CloudEvents 1.0.2, olay meta verisini ortak biçimde tanımlamak için kullanılabilecek bir spesifikasyondur; kullanımı zorunlu değildir. Temsili olay sözleşmesi aşağıdaki gibi kurulabilir.

Karar çıkarımı: Kuyruk veri kaybını tek başına önlemez; kalıcılık, teslim semantiği, idempotent tüketici, alarm ve replay tasarımı gerekir.

Entegrasyon Mimarisi Nasıl Seçilir?

Mimari; sistem sayısı, işlem hacmi, gecikme toleransı, ERP kabiliyeti, ekip yetkinliği, bütçe, güvenlik ve denetim ihtiyacına göre seçilir. Her veri için aynı yöntem gerekmez. Temsili iki depolu, çok kanallı işletmede sipariş için queue, stok için olay, ürün için batch ve rapor için dosya kullanılması makul olabilir; bu evrensel reçete değildir.

Kriterleri düşük/orta/yüksek olarak puanlayan karar matrisi şöyledir.

Karar çıkarımı: En karmaşık mimariyi değil, iş riskini karşılayan ve ekibin sürdürebildiği en yalın mimariyi seçin.

Ürün, Kategori ve Varyant Verileri Nasıl Senkronize Edilir?

Ürün entegrasyonu ilk import ile bitmez; taslak, aktif, pasif, varyant ailesi, kategori, özellik, set ürün ve kanal uygunluğu yaşam döngüsü boyunca değişir. ERP ticari kodun, PIM veya e-ticaret platformu zengin açıklama ve görselin sahibi olabilir. Silme yerine pasifleştirme, tarihsel sipariş ilişkilerini korur.

Ürün alanı sahipliği şu mapping tablosuyla netleştirilebilir.

Karar çıkarımı: Import ile sürekli senkronizasyonu ayırın; her alanın yaşam döngüsü ve pasifleştirme davranışını test edin.

Fiyat, İskonto, KDV, Döviz ve Yuvarlama Nasıl Entegre Edilir?

Liste fiyatı, satış fiyatı, müşteri grubu, kanal fiyatı, kampanya ve kupon aynı nesne değildir. Net/brüt, KDV dahil/haric, para birimi, kur kaynağı, geçerlilik ve yuvarlama basamağı sözleşmede açık olmalıdır. Aynı fiyatı iki sistemin yeniden hesaplaması kuruş veya toplam farkı yaratabilir.

E-ticarette fiyatlandırma kurallarını entegrasyon sahipliğiyle karıştırmadan aşağıdaki tabloda alan bazında belirleyin.

Karar çıkarımı: Fiyat güncellemesi başarısızsa satışa devam etme veya kapatma kararını finansal risk ve ürün grubuna göre önceden tanımlayın.

Stok, Depo, Rezervasyon ve Satılabilir Stok Nasıl Entegre Edilir?

Fiziksel stok elde bulunan miktardır; rezerve stok siparişe ayrılan, tahsis edilmiş stok belirli depo veya kanala bağlanan, güvenlik stoğu satışa açılmayan tampon miktardır. Satılabilir stok bu bileşenlerden iş kuralıyla hesaplanır. Kaynak ERP, WMS veya OMS olabilir; otomatik olarak ERP seçilmez.

Çok kanallı stok yaklaşımında kanal kotası ve depo sahipliği aşağıdaki formül bileşenleriyle belgelenmelidir.

Karar çıkarımı: Satılabilir stok formülünü SKU/depo/kanal seviyesinde onaylatın; karantina ve hasarlı stoğu otomatik satışa açmayın.

Negatif Stok ve Overselling Riski Nasıl Azaltılır?

Overselling yalnız yavaş API'den değil, yanlış SKU/depo mapping, geç iptal, eksik rezervasyon ve aynı anda çok kanaldan satıştan doğar. Güvenlik stoğu, kanal kotası, atomik rezervasyon, optimistic concurrency ve olay sırası riski azaltabilir; sıfır fazla satış garantisi vermez. Kesintide satışı sürdürme kararı ürün riskine göre değişir.

Risk senaryoları için önleme, tespit ve telafi birlikte tasarlanmalıdır.

Karar çıkarımı: Stok akışı eskidiğinde son bilinen miktarı göstermek, tampon düşmek veya satışı kapatmak için SKU sınıfı bazlı runbook hazırlayın.

Müşteri, Adres ve Cari Hesap Verileri Nasıl Eşleştirilir?

Bireysel müşteri, şirket, şube, kullanıcı, teslimat adresi, fatura adresi ve ERP cari kartı ayrı nesnelerdir. E-posta veya telefon değişebilir ve paylaşılıyor olabilir; tek evrensel anahtar kabul edilmemelidir. Tarihsel sipariş adresi, müşteri profilindeki güncel adresten bağımsız korunmalıdır.

Eşleştirme; kaynak kimlik, cross-reference, güven skoru ve manuel birleştirme kontrolüyle yapılır. TCKN/VKN gibi kimlikler yalnız gerekli amaç, yetki ve saklama kuralıyla işlenmeli; loglarda açık bırakılmamalıdır.

• Şirket, şube ve kullanıcı hiyerarşisini ERP cari kartıyla bire bir varsaymayın.
• Duplicate birleştirmede önceki kimlikleri çapraz referans olarak saklayın.
• Adres güncellemesinin geçmiş sipariş belgesini değiştirmesini engelleyin.
• Alan bazlı kaynak ve çatışma politikasını veri sahipliği matrisine ekleyin.

Sipariş ERP'ye Hangi Anda Aktarılmalıdır?

Aktarım tetikleyicisi sipariş oluşturma, ödeme yetkilendirme, tahsilat, risk onayı veya manuel onay olabilir. Kart, havale, kapıda ödeme ve açık hesap aynı tetikleyiciyi kullanmak zorunda değildir. Erken aktarım iptal/temizlik yükü, geç aktarım stok ve sevkiyat gecikmesi yaratabilir.

Sipariş sözleşmesi başlık, satır, indirim, vergi, kargo, ödeme, müşteri, kanal ve dış referansları taşır. Tetikleyici, rezervasyon ve finansal durum ayrı alanlarla izlenmelidir.

• Kartlı siparişte ödeme sağlayıcısı işlem kimliğini aktarım kararına bağlayın.
• Havalede “ödeme bekliyor” ve “doğrulandı” durumlarını ayırın.
• Kapıda ödemede tahsilatın sevkiyat veya teslim olayında oluşabileceğini modelleyin.
• B2B açık hesapta cari limit kontrolünün zamanını ve rezervasyon davranışını yazın.

Sipariş Durumları Nasıl Eşleştirilir?

E-ticaret ve ERP durum adları aynı görünse bile anlamı ve terminal davranışı farklı olabilir. Sipariş, ödeme, sevkiyat ve belge durumları ayrı yaşam döngüleridir. Kısmi satır durumları üst siparişe kuralla özetlenir; her olayı “tamamlandı” durumuna çevirmek müşteri bildirimini ve finans kaydını bozar.

Temsili yaşam döngüsü mappingi aşağıdadır.

Karar çıkarımı: Geçerli ileri/geri geçişleri, terminal durumları ve olay zamanını state machine olarak belgeleyin.

Ödeme Durumu ERP Entegrasyonunda Nasıl Yönetilir?

Ödeme durumu sipariş durumundan ayrı tutulur: yetkilendirme, tahsilat, başarısızlık, bekleme, kısmi/tam iade ve chargeback farklı finans olaylarıdır. ERP'ye kart verisi taşınmamalı; gerekli sağlayıcı işlem ID'si, token referansı, tutar ve para birimi sözleşmeyle sınırlandırılmalıdır.

Timeout sonrasında aynı tahsilatı tekrar başlatmak yerine sağlayıcı durumunu işlem ID'siyle sorgulayın. Kısmi iade, orijinal tahsilat ve sipariş satırıyla bağlanmalı; “ödeme başarısız” siparişi otomatik silmek yerine iş kuralına göre bekletme veya iptal yolu kullanılmalıdır.

Sevkiyat, Kargo ve Kısmi Gönderim Nasıl Entegre Edilir?

Tek sipariş farklı depolardan birden çok sevkiyat ve pakete bölünebilir. Shipment ID, package ID, carrier code ve tracking code ayrı kimliklerdir; ilk takip numarasını tüm siparişe yazmak kısmi sevkiyatı gizler. Teslim, başarısız teslim ve iade kargo olayları da kaynaklarıyla korunmalıdır.

Kargo ve desi süreçleri iş stratejisini açıklar; entegrasyon tarafında aşağıdaki olay ilişkisi kullanılır.

Karar çıkarımı: Sipariş üst durumu yerine satır, paket ve depo seviyesindeki sevkiyat kimliklerini koruyun.

Fatura ve E-Belge Akışı ERP Entegrasyonuna Nasıl Bağlanır?

Site siparişi, ERP satış belgesi, muhasebe fişi, e-Fatura/e-Arşiv/e-İrsaliye ve PDF görünümü aynı kayıt değildir. Fatura tetikleyicisi ödeme, sevkiyat veya geçerli iş/mevzuat kuralına göre değişebilir. Belge UUID/numara, durum, hata kodu ve orijinal sipariş referansı ayrı tutulmalıdır.

GİB e-Belge duyuruları teknik paket ve kılavuz değişikliklerinin güncel izlenmesi gerektiğini gösterir. Genel resmî çerçeve için e-ticaret belgeleri rehberi, ticari seçenek için Solofor e-Fatura entegrasyon seçenekleri incelenebilir; hizmet, kontör ve bağlantı kapsamı ayrıca doğrulanmalıdır.

Karar çıkarımı: E-belge servisi erişilemediğinde siparişi kaybetmeyen kuyruk, kalıcı/geçici hata ayrımı, alarm ve manuel istisna akışı kurun.

İptal, İade ve Değişim Akışları Nasıl Entegre Edilir?

Sipariş iptali, satır iptali, tam/kısmi iade, değişim, ödeme iadesi ve belge ters işlemi farklı olaylardır. Fiziksel ürün depoda kabul edilmeden satılabilir stoğa dönmemelidir. Orijinal sipariş, satır, ödeme, sevkiyat ve belge referansları zincir boyunca korunur.

Ödeme iadesi, depo kabulü ve mali belge aynı anda tamamlanmayabilir. Saga veya kompansasyon yaklaşımı, tamamlanan adımların iş kuralına uygun ters olaylarla dengelenmesini sağlar; yasal ya da finansal kaydı keyfî biçimde silmek anlamına gelmez.

B2B, Bayi ve Cari Süreçleri ERP ile Nasıl Bağlanır?

B2B bağlantısında müşteri grubu, özel fiyat, cari limit, vade, teklif/proforma ve satış temsilcisi referansları taşınabilir; ancak bunların iş kuralları bu makalenin değil ilgili B2B tasarımının kapsamıdır. Entegrasyon açısından şirket, şube, kullanıcı ve ERP cari kartı mappingi ile onay/versiyon kaydı önemlidir.

Cari limitin gecikmeli kopyasına güvenmek eşzamanlı siparişlerde aşım yaratabilir. Kritik limit kontrolünün senkron mu, rezervasyonlu mu, manuel onaylı mı olacağı; ERP kesintisindeki davranış ve teklifin siparişe dönüşürken hangi sürümün geçerli olduğu açıkça yazılmalıdır.

Web Sitesi, Pazaryeri ve Fiziksel Mağaza Kanalları Nasıl Ayrıştırılır?

Aynı ürün ve sipariş modelinde kanal ID, mağaza ID, kaynak sipariş numarası, kampanya ve fiyat/stok kuralı korunmalıdır. Kanal sipariş ID'si ERP iç sipariş numarası değildir. Stok havuzu, kanal kotası ve iade kaynağı kanala göre değişebilir.

Pazaryeri entegrasyonu ile kanal bağlantısının genel kapsamı incelenebilir. Bu ERP rehberi hakediş, komisyon veya stopaj mutabakatına girmez; yalnız kaynak kimlik, ürün, fiyat, stok, sipariş ve durum akışını ele alır.

Üretim, Satın Alma ve Tedarik Süreçleri Entegrasyona Ne Zaman Dahil Edilir?

Made-to-order, backorder, drop-shipping, tedarikçi stok ve üretim emri modellerinde e-ticaret siparişi iç tedarik sürecini tetikleyebilir. Otomatik satın alma veya üretim emri açmak; onay, minimum miktar, tedarikçi kapasitesi ve iptal telafisi gerektirir. Tahmini termin bilgisinin kaynağı ve güncelleme sıklığı ayrıca belirlenmelidir.

İlk fazda kritik ürün–stok–sipariş akışını çalıştırıp üretim/tedarik otomasyonunu ölçülmüş ihtiyaçla eklemek kapsam riskini azaltabilir. Ön sipariş etiketi, termin değişikliği ve tedarikçi gecikmesi müşteri görünümüne nasıl yansıyacaksa sözleşmede yer almalıdır.

Idempotency Nedir ve Mükerrer Sipariş veya Fatura Nasıl Önlenir?

Idempotency, aynı iş talebi güvenli biçimde tekrar geldiğinde ikinci bir iş sonucu oluşturmama özelliğidir. Ağ timeout'unda karşı taraf kaydı oluşturmuş, yalnız cevap kaybolmuş olabilir. Kör tekrar yeni sipariş veya belge yaratırken, idempotency anahtarı önceki sonucu bulup tutarlı cevap döndürür.

Deduplication kopya mesajı tanımaya yardımcı olur; idempotency iş sonucunun tekrar etkisiz kalmasını sağlar. Anahtar kapsamı, saklama süresi ve farklı payload ile aynı anahtar geldiğindeki hata davranışı sözleşmeye yazılır.

Karar çıkarımı: HTTP yöntemi veya mesaj brokerı tek başına idempotency sağlamaz; iş anahtarı ve sonuç kaydı gerekir.

Mesaj Sırası, Versiyon ve Eşzamanlı Güncellemeler Nasıl Yönetilir?

Out-of-order olaylar eski stok, fiyat veya sipariş durumunun yeni değeri ezmesine neden olabilir. Event time olayın işte gerçekleştiği, processing time sistemin işlediği zamandır; ikisi aynı olmayabilir. Sequence/version numarası ve optimistic concurrency, eski güncellemeyi tanımaya yardım eder.

Global sıra çoğu zaman pahalı ve gereksizdir; SKU, sipariş veya cari gibi aggregate bazında sıra yeterli olabilir. İptal, sevkiyat ve ödeme aynı anda geldiğinde durum makinesi geçişi doğrular; geçersiz olay karantinaya alınır veya güncel snapshot ile uzlaştırılır.

Retry, Backoff, Jitter, Timeout ve Circuit Breaker Nasıl Kullanılır?

Retry yalnız geçici ağ, rate limit veya servis yoğunluğu gibi toparlanabilir hatalarda uygulanır; eksik vergi kodu gibi kalıcı doğrulama hatası sonsuz tekrar edilmez. Exponential backoff denemeler arasını büyütür, jitter istemcilerin aynı anda tekrar yüklenmesini azaltır. Timeout kaynakları korur; circuit breaker sürekli başarısız servise çağrıyı geçici olarak keser.

Hata, retry ve DLQ kararı aşağıdaki matriste birlikte yönetilir.

Karar çıkarımı: Circuit breaker veri kaybını çözmez; kontrollü başarısızlık, fallback, kuyruk ve toparlanma planıyla birlikte kullanılır.

Dead-Letter Queue ve Güvenli Yeniden İşleme Nasıl Tasarlanır?

Dead-letter queue (DLQ), ana akışta işlenemeyen mesajların incelendiği kontrollü alandır. Hata nedeni, deneme sayısı, ilk/son zaman, şema sürümü, correlation ID ve güvenli payload referansı tutulur. DLQ unutulmuş depo değil; sahibi, alarmı, triage süresi ve replay runbook'u olan operasyondur.

Güvenli yeniden işleme sırası; kök nedeni düzeltme, mesajı doğrulama, dry-run, idempotency kontrolü, sınırlı replay, karşı sistem sonucunu doğrulama ve audit kaydını kapatmadır. Hassas veri DLQ veya logda açık tutulmamalıdır.

Dual Write Riski ve Transactional Outbox Nedir?

Dual write, uygulamanın tek iş adımında hem veritabanına hem mesaj sistemine ayrı yazmasıdır; biri başarılı diğeri başarısız olursa tutarsızlık oluşur. Transactional outbox, iş kaydı ile yayımlanacak olay kaydını aynı yerel transaction içinde saklayıp ayrı yayımlayıcıyla gönderen desendir. Her teknoloji için zorunlu değildir.

Outbox, tüketici tarafındaki duplicate'i otomatik ortadan kaldırmaz; idempotent consumer gerekebilir. Change Data Capture alternatif olabilir ve seçimin veritabanı, sipariş garantisi, sıra, işletim yetkinliği ve gecikme ihtiyacına göre yapılması gerekir.

Karar çıkarımı: Deseni isim olarak değil, hangi başarısızlık penceresini kapattığı ve hangi yeni operasyonu doğurduğuyla değerlendirin.

Eventual Consistency ve Veri Mutabakatı Nasıl Birlikte Çalışır?

Eventual consistency, dağıtık sistemlerin kısa süre farklı görünüp tanımlı mekanizmalarla yakınsamasıdır; “veri yanlış kalabilir” izni değildir. Kabul edilen gecikme, kullanıcı mesajı, retry ve eskimiş veri davranışı yazılır. Gerçek zamanlı akış olsa bile kayıp, duplicate veya mapping farkını bulmak için mutabakat gerekir.

Mutabakat yalnız kayıt sayısı değil; tutar, durum, stok ve referans düzeyinde yapılmalıdır.

Karar çıkarımı: Farkı otomatik kapatmadan önce ana kaynak, tolerans, finansal etki ve onay sahibini belirleyin.

ERP Çalışmadığında E-Ticaret Sitesi Ne Yapmalıdır?

ERP kesintisinde siteyi tamamen durdurmak, siparişi kalıcı kuyruğa almak, sınırlı mod kullanmak veya son bilinen stok/fiyatla devam etmek seçeneklerdir. Doğru davranış ürün, stok, finans ve müşteri riskine bağlıdır. ETBİS de ERP devre dışı kaldığında sitenin nasıl çalışacağı ve sonradan verilerin nasıl eşleneceği sorusunu planlama konusu yapar.

Kesinti kararı şu runbook matrisiyle önceden onaylanmalıdır.

Karar çıkarımı: Kesinti sırasında oluşan siparişleri kalıcı, denetlenebilir ve tekrar işlemeye dayanıklı biçimde saklamadan satışa devam etmeyin.

Kampanya Trafiğinde Rate Limit, Queue ve Backpressure Nasıl Yönetilir?

Yoğun trafik ERP'ye aynı oranda doğrudan senkron çağrı olarak yansıtılırsa checkout ve arka ofis birlikte zorlanabilir. Rate limit çağrı hızını, concurrency limit eşzamanlı işi, queue buffer'ı, backpressure ise tüketici yavaşladığında üretim hızını kontrol eder. Sipariş mesajları rapor veya içerik güncellemesinden daha yüksek öncelik alabilir.

Kampanya operasyon planı ile entegrasyon kapasitesini birleştirirken queue depth, oldest-message-age, consumer lag, hata oranı ve ERP yanıt süresini izleyin.

Karar çıkarımı: Queue boyutu tek başına kapasite değildir; mesaj yaşı, tüketim hızı ve toparlanma süresi birlikte planlanır.

Entegrasyonlarda Log, Metrik ve Trace Nasıl Tasarlanır?

Log tek olayın ayrıntısını, metric zaman içindeki sayısal eğilimi, trace ise dağıtık çağrı ve mesaj yolunu gösterir. Correlation ID veya trace ID, bir siparişi platformdan entegrasyon katmanına ve ERP'ye kadar ilişkilendirir. Kişisel veri, token ve belge içeriği loga kontrolsüz yazılmaz.

OpenTelemetry, trace, metric ve log sinyalleri için sağlayıcı bağımsız gözlemlenebilirlik çerçevesidir. Aşağıdaki matris teknik ve iş sinyallerini ayırır.

Karar çıkarımı: Yalnız HTTP hata oranına değil, iş kaydı oluşumu, queue yaşı ve mutabakat farkına alarm kurun.

Audit Log ve Denetlenebilirlik Neden Önemlidir?

Operasyon logu sistemi çalıştırmaya, audit kaydı kim-ne zaman-ne değiştirdi sorusunu kanıtlamaya yarar. Önceki ve yeni değer, kaynak/karşı sistem kimliği, kullanıcı veya servis kimliği, neden, onay ve olay zamanı kaydedilebilir. Audit saklama, değişmezlik ve erişim tasarımı iş/mevzuat ihtiyacına göre belirlenir.

Manuel replay, mapping değişikliği, fiyat düzeltmesi, secret rotasyonu ve mutabakat kapatma gibi yüksek etkili işlemler özellikle audit edilmelidir. Audit verisi de kişisel veya hassas olabilir; gereksiz payload kopyalamak yerine güvenli referans kullanılmalıdır.

Dashboard ve Alarm Sistemi Nasıl Kurulur?

Teknik sağlık dashboard'u API, queue ve bağımlılıkları; iş dashboard'u sipariş, ödeme, sevkiyat ve belge akışını; veri kalitesi dashboard'u mutabakat farklarını gösterir. Alarm toplam hata sayısına değil oran, yaş, önem, kanal ve iş etkisine göre tasarlanmalıdır. Alarmın sahibi, runbook'u ve kapanış kanıtı olmalıdır.

Uyarıları deduplicate etmek ve escalation planı kurmak alarm yorgunluğunu azaltır. Destek ekibi siparişin nerede kaldığını teknik log okumadan görebilmeli; on-call ekip ise correlation ID ile ayrıntıya inebilmelidir.

SLA, SLO, RTO ve RPO Entegrasyon Projesinde Nasıl Kullanılır?

SLA taraflar arasındaki hizmet taahhüdü, SLO iç hizmet hedefi, RTO kesintiden sonra toparlanma süresi hedefi, RPO ise geri dönüldüğünde kabul edilen veri kaybı noktasıdır. Uptime tek başına yeterli olmaz; veri tazeliği, işlem başarısı, backlog yaşı ve mutabakat kapanışı da hedeflenebilir.

ERP, e-ticaret platformu, entegrasyon sağlayıcısı ve üçüncü tarafın sorumluluk sınırları ayrı yazılmalıdır. SLO baz ölçüme ve iş etkisine dayanmalı; “her durumda anlık” gibi işletilemeyen taahhüt yerine ölçüm yöntemi ve ihlal aksiyonu içermelidir.

ERP API Güvenliği Nasıl Sağlanır?

API güvenliği kimlik doğrulama, yetkilendirme, şifreleme, girdi doğrulama, kaynak sınırı, secret yönetimi, envanter ve izlemeyi katmanlı kurar. TLS tek başına nesne veya fonksiyon yetkisini sağlamaz. Her endpoint ve servis hesabı en az ayrıcalıkla, nesne/işlem bazlı kontrolle sınırlandırılmalıdır.

OWASP API Security Top 10 2023; bozuk nesne/fonksiyon yetkilendirmesi, bozuk kimlik doğrulama, sınırsız kaynak tüketimi, eksik envanter ve güvensiz üçüncü taraf API tüketimi gibi güncel riskleri tanımlar.

Karar çıkarımı: Güvenlik kontrolünü giriş kapısına bırakmayın; her veri nesnesi, işlem ve tüketici sınırında doğrulayın.

API Key, OAuth 2.0, mTLS, HMAC ve HTTP Message Signatures Nasıl Karşılaştırılır?

API key istemciyi tanımaya yarayabilir, fakat tek başına güçlü kullanıcı delegasyonu veya payload bütünlüğü sağlamaz. OAuth 2.0 kapsamlı ve süreli token yetkilendirmesi; mTLS karşılıklı sertifika ile taraf kimliği; HMAC ortak sırla mesaj doğrulama; HTTP Message Signatures ise seçili HTTP bileşenlerini imzalama yaklaşımıdır. Birlikte kullanılabilirler.

RFC 9700 / BCP 240, OAuth 2.0 için güncel güvenlik uygulamalarını tanımlar. HTTP Message Signatures RFC 9421 ise uygun projelerde seçenek olarak değerlendirilmeli, evrensel zorunluluk gibi sunulmamalıdır.

Karar çıkarımı: Kimlik, yetki, kanal ve mesaj bütünlüğü farklı sorunlardır; tek kontrolün hepsini çözdüğünü varsaymayın.

Webhook Güvenliği ve Replay Koruması Nasıl Tasarlanır?

Webhook HTTPS üzerinden gelmeli; imza, timestamp, nonce veya event ID ve kabul penceresiyle doğrulanmalıdır. Aynı event ID daha önce işlendiğinde idempotent cevap verilir. Canonical payload ve imzalanan header listesi iki tarafta aynı olmalı; IP allowlist tek güven katmanı sayılmamalıdır.

Secret rotasyonunda eski ve yeni anahtarın kontrollü geçiş penceresi, audit ve geri dönüş planı bulunur. Sağlayıcı sözleşmesi uygunsa webhook'a hızlı 2xx dönüp işi kalıcı kuyruğa almak timeout'u azaltabilir; 2xx iş sonucunun tamamlandığı anlamına gelmez.

KVKK Açısından ERP Entegrasyonunda Nelere Dikkat Edilmelidir?

ERP entegrasyonu kişisel verinin hangi amaçla, hangi sistemler ve taraflar arasında aktığını görünür kılmalıdır. Veri minimizasyonu, rol bazlı erişim, şifreleme, log maskeleme, saklama-imha, üçüncü taraf sözleşmeleri ve ihlal süreci teknik tasarımla birlikte ele alınır. Entegrasyon tek başına KVKK uyumu sağlamaz.

KVKK veri güvenliği yükümlülükleri, hukuka aykırı işleme ve erişimi önleme ile muhafaza için uygun teknik/idari tedbirleri vurgular. Yurt dışı aktarım, saklama ve hukuki rol değerlendirmeleri güncel mevzuat ve uzman görüşüyle doğrulanmalıdır.

• Test ortamında sentetik veya maskelenmiş veri kullanın; üretim kopyasını varsayılan yöntem yapmayın.
• Loglarda parola, token, kart verisi, tam adres ve gereksiz kimlik numarasını maskeleyin.
• Servis hesaplarını en az ayrıcalık, süreli erişim ve düzenli gözden geçirmeyle yönetin.
• Veri akışı, saklama gerekçesi ve imha sorumluluğunu veri envanterine bağlayın.

ERP Entegrasyonu Proje Aşamaları Nasıl Planlanır?

Başarılı proje keşif, tasarım, geliştirme, doğrulama, pilot, canlıya geçiş ve işletim evrelerini görünür kapılarla ilerletir. Her kapıda iş sahibi yalnız teknik çıktıyı değil, süreç sonucunu da kabul eder. Böylece çözülmemiş bir eşleştirme sorunu sonraki evreye sessizce taşınmaz.

Aşağıdaki plan süre taahhüdü değildir; veri kalitesi, ERP erişimi, taraf sayısı, özel süreçler ve ekip kapasitesi takvimi değiştirir. Evreler kısmen paralel ilerleyebilse de üretim riski taşıyan kararların onay sırası korunmalıdır.

Karar çıkarımı: Takvimi özellik bitişine göre değil, kanıtlanmış kabul kapılarına göre yönetin.

Dokümantasyon Setinde Neler Bulunmalıdır?

Dokümantasyon geliştiricinin hafızası değil, ekipler arası işletim sözleşmesidir. Sistem bağlamı, veri akışları, kaynak sahipliği, alan sözlüğü, API/event şemaları, durum ve kod eşlemeleri, güvenlik modeli, hata politikaları, runbook, test kanıtı ve değişiklik geçmişi tek katalogda ilişkilendirilmelidir.

• Sistem bağlam diyagramında tarafları, güven sınırlarını ve veri yönlerini gösterin.
• Her sözleşmenin sahibi, sürümü, yürürlük tarihi ve geriye uyumluluk politikasını yazın.
• Mapping kararlarına örnek kaynak/hedef payload ve başarısız örnek ekleyin.
• Alarmın anlamını, eşiğini, ilk kontrolü, yükseltme yolunu ve toparlanma kanıtını runbook'a bağlayın.
• İş karar kayıtlarında alternatifleri, gerekçeyi ve yeniden değerlendirme tetikleyicisini saklayın.

Test Ortamı ve Anonimleştirilmiş Veri Nasıl Hazırlanır?

Test ortamı üretimin küçültülmüş fakat davranışça anlamlı bir temsilidir. Aynı şema sürümleri, benzer kimlik ve rate-limit kuralları, kuyruk/DLQ, webhook doğrulaması ve kontrollü hata üretimi bulunmalıdır. Üretim kişisel verisini kopyalamak yerine sentetik, maskelenmiş veya hukuken uygun yöntemle hazırlanmış veri kullanılmalıdır.

Test veri seti Türkçe karakter, uzun adres, eksik opsiyonel alan, mükerrer barkod girişimi, farklı KDV ve para birimi, kısmi sevkiyat, sıra dışı iade ve yüksek hacim örneklerini kapsamalıdır. Token ve sertifikalar üretimden ayrı tutulmalı; test webhook'u gerçek müşteriye veya taşıyıcıya işlem göndermemelidir.

Entegrasyon Testleri Hangi Katmanlarda Yapılır?

Tek bir uçtan uca test bütün hatayı gösterse de kök nedeni hızla ayıramaz. Bu yüzden şema/contract, mapping, bileşen, entegrasyon, uçtan uca, performans, dayanıklılık, güvenlik, kullanıcı kabul ve mutabakat testleri katmanlanır. Her test beklenen iş sonucunu ve yan etkileri birlikte doğrular.

Aşağıdaki test piramidi, sorunu mümkün olan en dar ve ucuz katmanda yakalamayı; az sayıdaki uçtan uca senaryoyla gerçek iş zincirini doğrulamayı hedefler.

Karar çıkarımı: Üretime geçişi yalnız başarılı API cevabına değil, iş sonucu, yan etki ve toparlanma kanıtına bağlayın.

Kritik Test Senaryoları Nelerdir?

Kritik senaryolar normal akış, sınır değer, tekrar, sıra, kesinti, güvenlik ve yasal belge referanslarını kapsamalıdır. Aşağıdaki matris her projede iş kurallarına uyarlanmalı; beklenen sonuç, gerçek sonuç, kanıt ve onay sahibi test yönetim aracında saklanmalıdır.

Karar çıkarımı: Go/no-go kararından önce bu 34 senaryonun proje karşılığını, kanıtını ve varsa kabul edilmiş riskini görünür kılın.

Pilot, Cutover ve Canlıya Geçiş Runbook'u Nasıl Hazırlanır?

Pilot; seçilmiş ürün, depo, kanal veya sipariş hacmiyle iş kuralını gerçek koşullarda sınar. Cutover runbook'u ise hazırlık, veri dondurma veya delta yakalama, konfigürasyon, başlangıç senkronu, doğrulama, trafik açma, iletişim ve geri dönüş adımlarını saat, sahip ve kanıtla tanımlar.

Plan iş gününe, finansal kapanışa, kampanyaya ve destek vardiyasına göre kurulmalıdır. Aşağıdaki örnek, proje saatleri ve toleransları belirlendikten sonra doldurulacak işletim iskeletidir.

Karar çıkarımı: Canlıya geçişi tek bir “deploy” anı değil, ölçülebilir kontrol noktaları ve açık durdurma yetkisi olan iş operasyonu sayın.

Rollback, Roll-Forward ve Hypercare Nasıl Yönetilir?

Rollback yalnız kodu eski sürüme çevirmek değildir; yeni şemayla yazılmış kayıtları, kuyruktaki olayları, stok rezervasyonlarını, ödeme ve yasal belge yan etkilerini de ele alır. Finansal veya yasal kayıtlar sessizce silinmez; uygun ters kayıt ya da telafi işlemi iş sahibi ve mevzuat kuralıyla yürütülür.

Aşağıdaki seçenekler olayın veri etkisine göre seçilir. Veri migrasyonu geri çevrilemiyorsa uyumlu bir roll-forward çoğu zaman daha güvenli olabilir.

Karar çıkarımı: Geri dönüş kararını teknik hata kadar finansal, müşteri ve belge etkisine göre verin; yetkiliyi canlıdan önce belirleyin.

Değişiklik, Sürüm ve Bakım Yönetimi Nasıl Kurulur?

ERP ve e-ticaret platformu farklı takvimlerde değişebilir. Sözleşme versiyonu, deprecation penceresi, tüketici uyumluluk testi, feature flag, şema migrasyonu, bakım takvimi ve iletişim listesi ortak değişiklik sürecine bağlanmalıdır. Üretimde kullanılan endpoint, event ve dosya formatlarının aktif envanteri tutulmalıdır.

• Kırıcı değişikliği yeni ana sürümde yayınlayın ve tüketici geçiş planı verin.
• Eklenen opsiyonel alanın eski tüketiciyi bozmadığını contract testle gösterin.
• Webhook/event tüketicisinin bilinmeyen alanları güvenli biçimde tolere etmesini tasarlayın.
• Sertifika, token, API sürümü ve dosya anahtarları için son kullanma alarmı kurun.
• Her bakım sonrası kritik iş akışı ve mutabakat smoke testini çalıştırın.

Hazır Konektör, Özel Entegrasyon veya iPaaS Nasıl Seçilir?

Hazır konektör hızlı başlangıç sağlayabilir, fakat desteklediği nesne, alan, yön, frekans, hata yönetimi ve sürüm sınırları yazılı doğrulanmalıdır. Özel entegrasyon özgün iş kurallarında denetim sağlar; geliştirme ve bakım sorumluluğu getirir. iPaaS çok sayıda sistemde orkestrasyon ve izleme sağlayabilir, ancak lisans, veri konumu, yetkinlik ve bağımlılık değerlendirmesi ister.

Bir hazır e-ticaret altyapısı seçerken yalnız ekran özelliklerini değil, entegrasyon sözleşmesi ve işletim modelini de inceleyin. Aşağıdaki karar tablosu ürün adı yerine bağlamı öne çıkarır.

Karar çıkarımı: “Bağlantı var” yanıtını yeterli saymayın; nesne, alan, yön, gecikme, hata ve destek kapsamını örnek işlemle kanıtlatın.

ERP Veritabanına Doğrudan Bağlanmak Doğru mudur?

Doğrudan veritabanı okuması bazı eski sistemlerde kontrollü, salt okunur raporlama için son çare olabilir; fakat şema iç yapıya bağlılık, yetki, kilit, performans, audit ve sürüm riskleri yaratır. Uygulama kurallarını atlayarak doğrudan yazmak; eksik muhasebe yan etkisi, hatalı stok, destek dışı yapı ve veri bütünlüğü riski doğurabilir.

Öncelik desteklenen API, event, servis katmanı veya üreticinin onayladığı entegrasyon arayüzüdür. Zorunlu DB erişiminde salt okunur kullanıcı, replica/view, sorgu limiti, ağ kısıtı, şema sözleşmesi, değişiklik bildirimi, performans testi ve kaldırma planı yazılı olmalıdır.

ERP Entegrasyonu Maliyeti ve TCO Nasıl Hesaplanır?

Teklifte görünen kurulum bedeli, toplam sahip olma maliyetinin yalnız bir parçasıdır. ERP/e-ticaret/iPaaS lisansları, API veya işlem kotaları, altyapı, geliştirme, test, veri temizliği, güvenlik, izleme, destek, sürüm yükseltme, kesinti operasyonu ve çıkış maliyeti ayrı hesaplanmalıdır. Belirsiz kalemler varsayım ve aralıkla görünür kılınır.

Aşağıdaki model kesin fiyat üretmez; karşılaştırılabilir teklif ve üç yıllık senaryo kurmaya yardım eder.

Karar çıkarımı: Teklifleri aynı kapsam, hacim, destek penceresi ve exit varsayımıyla üç yıllık TCO üzerinden karşılaştırın.

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

Sağlayıcı değerlendirmesi “ERP ile entegre misiniz?” sorusundan çok daha ayrıntılı olmalıdır. Yanıtları evet/hayır olarak değil; doküman, kapsam matrisi, demo, test sonucu, SLA metni veya örnek export gibi kanıtlarla isteyin.

Karar çıkarımı: Yanıtların sözleşme ve kabul testine girmediği durumda pazarlama ifadesiyle teknik kapsamı birbirinden ayırın.

ERP Entegrasyonu Başarısı Hangi Metriklerle Ölçülür?

Başarı yalnız düşük API gecikmesi değildir. Veri doğruluğu, iş tamamlanma süresi, hata ve tekrar oranı, mutabakat farkı, kuyruk yaşı, manuel müdahale, belge durumu, toparlanma süresi ve kullanıcı etkisi birlikte izlenmelidir. Başlangıç değeri ölçülmeden iyileşme oranı iddiası kurulmaz.

Bu metrikleri e-ticaret raporlama yaklaşımıyla iş hedeflerine bağlayın; aynı teknik olayın sipariş, tutar ve müşteri etkisini ayrı gösterin.

Karar çıkarımı: Teknik sağlığı iş sonucuyla birleştiren az sayıda sahipli gösterge seçin; sayısal hedefleri pilot baz çizgisinden sonra onaylayın.

Yapay Zekâ ERP Entegrasyonunda Nasıl Kullanılabilir?

Yapay zekâ; alan eşleştirme önerisi, anomali kümelendirme, log özetleme, veri kalite sınıflandırması, test senaryosu taslağı ve kapasite tahmininde yardımcı olabilir. Bununla birlikte model çıktısı doğru veya güvenli kabul edilemez; finansal, stok, müşteri ve belge etkili eylemler deterministik kurallara, test kanıtına ve insan onayına bağlanmalıdır.

yapay zekâ destekli e-ticaret uygulamalarında olduğu gibi amaç, veri minimizasyonu ve çıktı sorumlusu baştan tanımlanmalıdır. Hassas payload'lar onaysız genel araçlara gönderilmemeli; model ve prompt sürümü, değerlendirme seti, hata eşiği ve geri alma seçeneği izlenmelidir.

Karar çıkarımı: Yapay zekâyı karar desteği olarak başlatın; hassas veri, açıklanabilirlik, test ve insan onayı geçmeden geri döndürülemez işlem yaptırmayın.

E-Ticaret Paketi Seçerken ERP Kapsamı Nasıl Değerlendirilir?

Paket seçiminde “entegrasyon” tek kutu değildir. Ürün, fiyat, stok, sipariş, ödeme, kargo, cari, finans görünürlüğü, pazaryeri ve özel bağlantı gereksinimlerini ayrı satırlarda doğrulayın. e-ticaret paketi seçme ölçütleri ile ERP'nin teknik ve operasyonel ihtiyaçlarını aynı karar dosyasına alın.

Güncel e-ticaret paketi kapsamlarını teklif tarihinde yeniden inceleyin. Paket kartındaki bir görünürlük veya modül ifadesinin belirli harici ERP için hazır, çift yönlü ve tüm alanları kapsayan bağlantı anlamına geldiğini varsaymayın.

Karar çıkarımı: Standart paket, opsiyonel hizmet ve özel proje kalemlerini ayrı teklif ve kabul ölçütleriyle değerlendirin.

SoloCommerce ERP Entegrasyonunda Nasıl Konumlandırılmalıdır?

SoloCommerce, doğrulanmış paket sayfasında katalog ve satış işlevlerinden çok kanallı operasyon görünürlüğüne, cari/tahsilat ve depo görünürlüğünden özel ERP/muhasebe bağlantılarına kadar farklı seviyelerde konumlanır. Bu ifadeler her harici ERP için otomatik hazır konektör veya belirli senkron süresi vaadi olarak yorumlanmamalıdır.

hangi SoloCommerce paketinin uygun olduğunu değerlendirirken güncel SoloCommerce seçeneklerini veri sahipliği ve kabul matrisiyle karşılaştırın. Müşteri deneyimindeki veri tutarlılığını e-ticaret sitesinde güven oluşturma hedefinin bir parçası sayın; yine de stok, fatura veya kesintisizlik sonucu garanti değildir.

Karar çıkarımı: Ürün özelliklerini doğrulanabilir proje kapsamına dönüştürün; bağlanacak ERP sürümünü, alanları, yönleri, frekansı ve hata işletimini yazılılaştırın.

E-Ticaret ERP Entegrasyonu Kontrol Listesi

Bu 207 maddelik liste keşiften işletime kadar kararları denetlenebilir hale getirir. Her maddeye kurumunuzda bir sahip, tamamlanma tarihi ve kanıt bağlantısı ekleyin; uygulanmayan kontrolleri gerekçe ve kabul edilmiş riskle kaydedin.

1. İş Hedefi ve Kapsam

• Proje sponsoruyla ölçülebilir iş hedeflerini yazılı onaylayın.
• Kapsama giren şirket, marka, kanal ve depoları listeleyin.
• Kapsam dışındaki süreçleri gerekçesiyle karar kaydına alın.
• Başlangıç değerlerini sipariş, hata ve manuel iş bazında ölçün.
• Başarı metriklerinin formülünü, sahibini ve veri kaynağını tanımlayın.
• Kapsam değişikliğinin takvim, maliyet ve risk onayını belirleyin.

2. Süreç Haritası ve İstisnalar

• Siparişten faturaya normal akışı sistem adımlarıyla çizin.
• Ödeme türlerine göre alternatif sipariş yollarını ayırın.
• Kısmi sevkiyat, backorder ve ön sipariş dallarını gösterin.
• İptal, iade, değişim ve belge hatası istisnalarını ekleyin.
• Her manuel müdahalenin tetikleyicisini ve sahibini işaretleyin.
• As-is ile to-be süreç farklarını iş sahibiyle onaylayın.

3. Paydaş, RACI ve Onaylar

• Her veri alanına hesap verebilir bir iş sahibi atayın.
• Tasarım, test, go-live ve rollback onay yetkililerini yazın.
• ERP, platform, finans, depo ve güvenlik sorumluluklarını ayırın.
• Üçüncü tarafların iletişim ve yükseltme zincirini belgeleyin.
• RACI matrisini her kapsam değişikliğinde yeniden onaylayın.

4. Sistem ve Entegrasyon Envanteri

• Tüm kaynak ve hedef sistemlerin sürüm envanterini çıkarın.
• API, webhook, dosya, kuyruk ve zamanlanmış işleri listeleyin.
• Üretimde kullanılan servis hesaplarını sahipleriyle kaydedin.
• Ağ, sertifika, domain ve IP bağımlılıklarını belgeleyin.
• Her bağlantının veri yönü ve çalışma sıklığını yazın.

5. Source of Truth ve Veri Sahipliği

• Her veri alanı için ana kaynak sistemi açıkça yazın.
• Alan bazlı güncelleme yönünü ve izin verilen yazarları belirleyin.
• İki sistemde değişebilen alanlar için conflict policy tanımlayın.
• Kaynak geçici erişilemezken okunacak değeri belirleyin.
• Manuel override işlemlerinin süresini ve audit kuralını yazın.
• Kaynak değişiminde veri migrasyonu ve geçiş sahibini atayın.
• Veri sahipliği matrisini iş ve teknik ekiplerle imzalayın.

6. Master, Reference ve Transaction Data

• Master, reference ve transaction veri sınıflarını ayırın.
• Her sınıfın yaşam döngüsü ve saklama süresini tanımlayın.
• Referans kodlarının versiyon ve yürürlük tarihini tutun.
• Transaction kayıtlarında değişmez dış referans kullanın.
• Silme yerine pasifleştirme gereken kayıtları belirleyin.

7. Ürün, SKU, Barkod, GTIN ve Varyant

• Ürün, SKU, varyant ve iç kimlik kavramlarını ayrı tanımlayın.
• Her mesaj veya işlem için benzersiz dış referans belirleyin.
• Barkod ve GTIN tekillik kurallarını veri girişinde uygulayın.
• Varyant eksenlerinin kaynak ve hedef değerlerini eşleyin.
• Ürün birleştirme ve ayırma için kimlik geçiş planı yazın.
• Eksik veya mükerrer kimliği karantina kuyruğuna yönlendirin.
• Ürün pasifleştirmesinin kanal ve stok etkisini test edin.

8. Birim, Kategori, Depo ve Kod Mapping

• Birim kodlarını metin yerine sabit kod tablosuyla eşleyin.
• Koli-adet dönüşüm katsayısını ve hassasiyetini onaylayın.
• Kategori eşlemesinde varsayılan atama yetkisini sınırlayın.
• Depo kodlarını satışa açık ve kapalı olarak sınıflandırın.
• Vergi ve sipariş durum kodlarına bilinmeyen değer kuralı ekleyin.
• Mapping tablosuna sahip, sürüm ve geçerlilik tarihi koyun.

9. Fiyat, İskonto, KDV, Döviz ve Yuvarlama

• Fiyatın KDV dahil veya hariç anlamını belgeleyin.
• Net, vergi ve brüt tutar formüllerini örnekle onaylayın.
• İskonto sırasını satır, sepet ve kampanya bazında belirleyin.
• Döviz kurunun kaynağını ve geçerlilik anını yazın.
• Yuvarlama hassasiyetini ve farkın hangi satıra yazılacağını tanımlayın.
• Negatif fiyat ve sıfır fiyat kontrollerini kurun.
• ERP ile site toplamlarını golden dataset üzerinde karşılaştırın.

10. Stok, Depo, Rezervasyon ve Satılabilir Miktar

• Satılabilir stok formülünü iş sahipleriyle onaylayın.
• Fiziksel, rezerve, güvenlik ve blokeli stoğu ayrı tutun.
• Satışa dahil edilen depo listesini kanal bazında belirleyin.
• Çoklu depo ve rezervasyon davranışını eşzamanlı test edin.
• Stok güncellemesinde sıra veya sürüm kontrolü uygulayın.
• Negatif stokta satışın ve alarmın davranışını tanımlayın.
• İptal ve iade sonrası stok dönüş zamanını belgeleyin.
• Kanal güvenlik payını yoğun trafik senaryosuyla sınayın.

11. Müşteri, Adres, Şirket ve Cari

• Müşteri ve cari tekilleştirme anahtarlarını belirleyin.
• Bireysel ve kurumsal müşteri alanlarını ayrı doğrulayın.
• Fatura ve teslimat adreslerini değişmez sipariş anlık görüntüsüyle saklayın.
• Adres normalizasyonunun orijinal veriyi kaybetmesini önleyin.
• Misafir müşterinin cari açma kuralını finansla onaylayın.
• Kişisel alanların hangi sistemlere gideceğini en aza indirin.

12. Sipariş ve Durum Yaşam Döngüsü

• Sipariş aktarım tetikleyicisini ödeme türüne göre tanımlayın.
• Site, ERP ve kanal durumlarını kod tablosunda eşleyin.
• Geçersiz durum geçişlerini state machine ile reddedin.
• Sipariş üst ve satır durumlarını ayrı modelleyin.
• Bölünmüş siparişte üst-alt referansları koruyun.
• Ön sipariş ve backorder teslim kurallarını belgeleyin.
• Değiştirilemez sipariş alanlarının kesim anını tanımlayın.
• Durum olaylarının audit zaman çizelgesini saklayın.

13. Ödeme ve Tahsilat

• Provizyon, tahsilat ve ödeme başarısını ayrı durumlar yapın.
• Havale bekleme ve süre aşımı kuralını belirleyin.
• Kapıda ödeme alacağını doğru ödeme koduyla aktarın.
• Kısmi ve tam para iadesini sipariş satırına bağlayın.
• Timeout sonrası kör tekrar öncesinde ödeme durumunu sorgulayın.
• Ödeme toplamını ERP siparişiyle günlük mutabakata alın.

14. Sevkiyat, Kargo ve Kısmi Gönderim

• Sevkiyat kaydını siparişten ayrı kimlikle modelleyin.
• Kısmi sevkiyatta satır ve miktar referanslarını koruyun.
• Birden çok takip numarasının aktarımını test edin.
• Teslim, başarısız teslim ve geri dönüş durumlarını eşleyin.
• Depo çıkışı ile müşteriye bildirim sırasını tanımlayın.
• İptal sonrası oluşmuş sevkiyat için durdurma süreci yazın.

15. Fatura ve E-Belge Referansları

• Site siparişi, satış belgesi ve yasal belge kimliklerini ayırın.
• Fatura kesme tetikleyicisini iş ve mevzuat ekibiyle onaylayın.
• Belge UUID, numara ve sipariş referansını birlikte saklayın.
• E-belge hata durumunu sipariş hatasından ayrı yönetin.
• İptal veya iade belgesinde orijinal belge ilişkisini koruyun.
• Belge sağlayıcı kesintisi için kuyruk ve operasyon planı hazırlayın.

16. İptal, İade ve Değişim

• Tam ve kısmi iptal kurallarını sipariş aşamasına göre ayırın.
• Kısmi sevkiyat ve kısmi iade akışını uçtan uca test edin.
• İade edilen ürünün kalite kontrol ve stok durumunu belirleyin.
• Değişimi iade ve yeni sevk referanslarıyla izleyin.
• Para iadesi ve belge işleminin sırasını tanımlayın.
• Mükerrer iade talebini dış referansla engelleyin.

17. B2B ve Çoklu Kanal

• Bayi fiyat listesi, vade ve cari limit kaynağını belirleyin.
• Kanal kimliğini her sipariş ve ödeme kaydında koruyun.
• Pazaryeri ile markalı site stok paylarını tanımlayın.
• Fiziksel mağaza siparişinin depo ve vergi kuralını eşleyin.
• Kanala özel iptal ve iade kısıtlarını süreçte gösterin.

18. API/Event Sözleşmesi ve Versiyonlama

• Alan sözlüğünde tip, zorunluluk ve iş anlamını yazın.
• API sözleşmesini makinece doğrulanabilir şema olarak sürümleyin.
• Event adı, kaynağı, zamanı ve correlation alanını tanımlayın.
• Kırıcı değişiklik için yeni ana sürüm ve geçiş penceresi verin.
• Opsiyonel alan eklemesini tüketici contract testiyle doğrulayın.
• Örnek başarılı ve hatalı payload'ları dokümana ekleyin.
• API sürüm değişikliği bildirimini sözleşmeye koyun.

19. Senkronizasyon Yöntemi ve Mimari

• Her akış için senkron, asenkron veya batch kararını gerekçelendirin.
• Gecikme toleransını veri alanı ve iş etkisine göre yazın.
• Push, pull veya polling sıklığını kapasite hesabıyla seçin.
• Noktadan noktaya bağlantı sayısı büyüme eşiğini tanımlayın.
• Middleware veya iPaaS sahipliğini mimari diyagramda gösterin.
• Dosya entegrasyonunda şifreleme, manifest ve tekrar kuralı belirleyin.

20. Idempotency, Sıra ve Concurrency

• Idempotency anahtarının kapsamını ve saklama süresini belirleyin.
• Aynı anahtar farklı payload ile gelirse reddetme kuralı uygulayın.
• Out-of-order olaylar için version veya sequence kontrolü kurun.
• Eşzamanlı yazmada optimistic locking ya da conflict policy kullanın.
• Duplicate event'i iş sonucunu bozmadan cevaplayın.
• Timeout sonrası hedefte sonuç sorgulama endpoint'i sağlayın.
• Idempotency kayıtlarını audit ve kapasite planına dahil edin.

21. Retry, Timeout, Circuit Breaker ve DLQ

• Geçici ve kalıcı hataları ayrı hata sınıflarına bölün.
• Kalıcı veri hatasını sonsuz retry döngüsünden çıkarın.
• Exponential backoff üst sınırı ve jitter değerini test edin.
• Bağlantı ve işlem timeout'larını ayrı tanımlayın.
• Circuit breaker açılma ve yarı açık koşullarını ölçün.
• DLQ için sahip, alarm ve replay runbook'u hazırlayın.
• Replay işlemini seçici, idempotent ve auditli yapın.
• Poison message kök nedeni çözülmeden toplu replay yapmayın.

22. Kesinti, Queue, Rate Limit ve Kapasite

• ERP kapalıyken sitenin sipariş davranışını iş sahibine onaylatın.
• Kuyruk kapasitesini hedef kesinti süresi ve pik hacimle hesaplayın.
• Oldest-message-age ve kuyruk derinliği alarmı kurun.
• Rate limit yanıtında kontrollü backoff uygulayın.
• Backpressure ile alıcıyı sınırsız çağrıdan koruyun.
• ERP dönüşünde backlog boşaltma hızını sınırlayın.
• Disk, broker ve tüketici kapasitesini yük testiyle kanıtlayın.

23. Mutabakat ve Veri Kalitesi

• Kaynak-hedef sayım ve tutar kontrollerini günlük çalıştırın.
• Mutabakat farkları için sahipli exception queue kurun.
• Ürün, stok, sipariş, ödeme ve belge kontrollerini ayırın.
• Eksik, fazla ve farklı kayıt sınıflarına düzeltme kuralı verin.
• Otomatik düzeltmede önce ve sonra değerini audit'e yazın.
• Fark toleranslarını finans ve operasyonla onaylayın.
• Tekrarlayan farkların kök nedenini problem kaydına bağlayın.

24. Güvenlik, Auth, Secret ve Webhook

• Her endpoint'te tenant ve nesne bazlı yetki kontrolü uygulayın.
• Servis hesaplarına en az ayrıcalıklı scope verin.
• API key'i tek güvenlik katmanı olarak kullanmayın.
• OAuth token ömrü ve revoke sürecini belgeleyin.
• mTLS sertifikaları için son kullanma ve rotasyon alarmı kurun.
• Secret'ları kod veya düz metin konfigürasyonda saklamayın.
• Webhook imzasını canonical payload üzerinden doğrulayın.
• Webhook timestamp, nonce ve replay penceresini test edin.
• Rate limit ve payload boyutu sınırını güvenlik testine alın.
• Secret rotasyonunu kesintisiz geçiş senaryosuyla doğrulayın.

25. KVKK, Log Maskeleme ve Test Verisi

• İşlenen kişisel veriyi amaç ve sistem bazında envantere alın.
• Gereksiz kişisel alanların entegrasyonunu kaldırın.
• Loglarda token ve hassas verinin maskelendiğini doğrulayın.
• Üretim verisini test ortamına kontrolsüz taşımayın.
• Sentetik veya uygun biçimde maskelenmiş test verisi kullanın.
• Saklama ve imha sürelerini veri sahibiyle onaylayın.
• Üçüncü taraf veri rolü ve aktarım koşullarını güncel hukukla inceleyin.

26. Log, Metric, Trace, Dashboard ve Alarm

• Uçtan uca correlation ID'yi tüm bileşenlerde taşıyın.
• Yapılandırılmış loglarda event ve dış referansı saklayın.
• Başarı, hata, retry ve DLQ sayaçlarını akış bazında ölçün.
• Uçtan uca gecikmeyi p50, p95 ve p99 olarak izleyin.
• Kuyruk derinliği ile en yaşlı mesaj yaşını birlikte gösterin.
• Trace örnekleme politikasını maliyet ve olay ihtiyacına göre seçin.
• Her alarm için sahip, eşik ve runbook bağlantısı ekleyin.
• Dashboard'u teknik sağlık ve iş etkisi panellerine ayırın.

27. Test ve Kabul

• En az 30 kritik test senaryosunun geçtiğini kanıtlayın.
• Contract, mapping ve regresyon testlerini otomatikleştirin.
• Normal akış yanında sınır ve negatif senaryoları çalıştırın.
• Tekrar, sıra ve concurrency testlerini paralel istekle yürütün.
• ERP kesintisi ve toparlanmayı kontrollü arıza ile sınayın.
• Kampanya hacminde yük ve soak testi yapın.
• Kısmi sevkiyat, iptal, iade ve belge hatasını doğrulayın.
• Webhook imzası, replay ve yetki testlerini geçirin.
• UAT sonucunu operasyon ve finans sahiplerine imzalatın.
• Her başarısız test için risk kabulü veya düzeltme kaydı oluşturun.

28. Pilot, Cutover, Rollback ve Hypercare

• Temsilî ürün, depo, kanal ve ödeme türüyle pilot yapın.
• Cutover adımlarına saat, sahip ve kanıt alanı ekleyin.
• Başlangıç ve bitiş mutabakatını go-live koşulu yapın.
• Delta yakalama veya kısa veri dondurma yöntemini belirleyin.
• Go/no-go ve rollback yetkilisini açıkça atayın.
• Rollback'in veri, kuyruk ve yan etkilerini planlayın.
• Geri alınamayan değişiklik için roll-forward seçeneği hazırlayın.
• Canlıda sınırlı trafikle ilk işlem zincirini doğrulayın.
• İlk 24 saat, 7 gün ve 30 gün izleme planı uygulayın.
• Hypercare bitişini metrik ve açık hata koşuluna bağlayın.

29. Dokümantasyon, Sürüm ve Bakım

• Sistem bağlamı ve veri akış diyagramını güncel tutun.
• Mapping kataloğuna sahip, sürüm ve karar gerekçesi ekleyin.
• API, event ve dosya sözleşmelerini tek katalogda yayınlayın.
• Alarm ve hata sınıfları için uygulanabilir runbook yazın.
• Bakım, sertifika ve token bitiş tarihlerini takvime alın.
• Değişiklik geçmişini sürüm ve onay kaydıyla saklayın.
• Doküman güncelliğini periyodik işletim kontrolüne bağlayın.

30. Maliyet, Sözleşme, Exit Planı ve AI

• İlk kurulum ile üç yıllık TCO kalemlerini ayrı hesaplayın.
• Özel geliştirme, üçüncü taraf ve paket maliyetlerini ayırın.
• API kota ve aşım ücretlerini hacim senaryosuyla değerlendirin.
• Hazır konektörün desteklediği alan ve yönleri yazılı alın.
• SLA, RTO, RPO ve istisnaları sözleşmede netleştirin.
• API sürüm değişikliği ve veri çıkış planını sözleşmeye ekleyin.
• AI aracına gönderilecek veri politikasını onaylayın.
• AI önerilerinde değerlendirme seti ve insan onayı zorunlu kılın.

E-Ticaret ERP Entegrasyonunda Sık Yapılan Hatalar

Aşağıdaki hatalar çoğunlukla teknoloji seçiminden önceki anlam, sahiplik ve işletim boşluklarından doğar. Her biri doğrudan veri farkı, müşteri etkisi, finansal düzeltme veya uzun kesinti üretebilir.

1. ERP'yi bütün veriler için otomatik ana kaynak kabul etmek: ERP her alanın en güncel iş bağlamını taşımayabilir. Alan bazında kaynak, sahip ve güncelleme yönü seçin.
2. ERP, muhasebe, OMS, WMS ve PIM rollerini karıştırmak: Çakışan sorumluluk iki sistemin aynı veriyi yazmasına yol açar. Sistem sınırlarını süreç ve veri matrisiyle ayırın.
3. Süreç haritası ve RACI olmadan geliştirmek: Normal demo çalışsa bile istisnalar sahipsiz kalır. Akışları ve onay yetkilerini koddan önce netleştirin.
4. Veri sahipliği ve conflict policy tanımlamamak: Eşzamanlı değişiklikte son yazan rastgele kazanır. Sürüm ve iş önceliği kuralı kullanın.
5. SKU, barkod, GTIN ve iç ID'yi aynı saymak: Kimlik çakışması yanlış ürünü günceller. Her kimliğin kapsamı ve tekillik kuralını ayrı uygulayın.
6. Kodları görünen metne göre eşlemek: Dil ve yazım değişikliği mapping'i bozar. Birim, depo, vergi ve durumlarda sabit kod tablosu kullanın.
7. Net, brüt ve KDV anlamını belirsiz bırakmak: Sipariş ile fatura toplamı ayrışır. Formülü ve örnek hesabı veri sözleşmesine koyun.
8. Kur ve yuvarlamayı iki sistemde farklı yapmak: Kuruş farkları mutabakat ve belge hatası üretir. Kaynak, zaman ve hassasiyeti tekilleştirin.
9. Fiziksel stokla satılabilir stoğu eşitlemek: Rezerve veya blokeli ürün yeniden satılabilir. Satılabilir miktar formülünü depo bazında kurun.
10. Rezervasyon ve eşzamanlı satışı test etmemek: Pik anda overselling oluşur. Paralel istek, güvenlik payı ve atomik güncelleme senaryolarını sınayın.
11. Her veriyi gerçek zamanlı istemek: Gereksiz çağrı ve maliyet, kritik akışı yavaşlatır. Gecikme toleransına göre event, yakın gerçek zamanlı veya batch seçin.
12. Webhook'u teslim garantisi sanmak: Ağ veya alıcı hatası olayı kaybettirebilir ya da tekrarlatabilir. Kalıcı kuyruk, retry, idempotency ve mutabakat ekleyin.
13. Tekrarlanan olaya dayanıklı olmamak: Aynı sipariş veya iade iki kez oluşur. İş kapsamlı idempotency anahtarı ve sonuç kaydı tutun.
14. Mesaj sırasını yok saymak: Eski stok veya durum yeniyi ezer. Entity sürümü, sequence ve geçersiz geçiş kontrolü kullanın.
15. Bütün hatalarda sonsuz retry yapmak: Kalıcı bozuk kayıt kuyruğu kilitler. Hataları geçici/kalıcı ayırıp kalıcı olanı DLQ'ya alın.
16. Timeout sonrasında sonucu sorgulamamak: Hedef işlemişken tekrar gönderim çift kayıt doğurabilir. Dış referansla durum sorgulayın.
17. DLQ'yu sahipsiz bırakmak: Kayıtlar görünmez bir mezarlıkta birikir. Alarm, sorumlu, düzeltme ve auditli replay runbook'u kurun.
18. Dual write riskini görmezden gelmek: Veritabanı yazılıp olay yayınlanmayabilir. Uygun bağlamda outbox veya telafi tasarlayın.
19. Gerçek zamanlı akış var diye mutabakat yapmamak: Sessiz kayıp ve mantık farkı yakalanmaz. Düzenli sayım, tutar ve alan farkı denetimi çalıştırın.
20. ERP kesintisini planlamamak: Sipariş kabulü, stok gösterimi ve toparlanma belirsiz kalır. Kuyruk, degrade mod ve backlog planını test edin.
21. Pikte ERP'ye sınırsız çağrı göndermek: Her iki sistem de çökebilir. Rate limit, batch, queue ve backpressure ile kapasiteyi yönetin.
22. HTTP 200'ü iş başarısı saymak: Teknik kabulden sonra işleme hata verebilir. İş durumu ve hedef kayıt referansını doğrulayın.
23. Correlation ID kullanmamak: Uçtan uca kök neden bulunamaz. Kimliği log, metric, trace, mesaj ve iş kaydında taşıyın.
24. Loglara token ve kişisel veri yazmak: Gözlemlenebilirlik yeni ihlal yüzeyi doğurur. Maskeleme, erişim ve saklama politikası uygulayın.
25. API key'i tek savunma saymak: Sızan anahtar geniş erişim sağlar. TLS, scope, nesne yetkisi, rotasyon ve izleme ekleyin.
26. Webhook imzası ve replay koruması kullanmamak: Sahte veya eski istek işlenebilir. İmza, timestamp, nonce ve kabul penceresini doğrulayın.
27. Üretim verisini teste kopyalamak: Gereksiz kişisel veri riski oluşur. Sentetik veya kontrollü maskelenmiş veri üretin.
28. Yalnız happy path test etmek: Gerçek operasyon ilk istisnada durur. Negatif, sınır, tekrar, sıra, kesinti ve yük senaryolarını ekleyin.
29. Kısmi süreçleri ve e-belge hatasını atlamak: Stok, ödeme ve belge referansı parçalanır. Kısmi sevk, iptal, iade ve belge tekrarını uçtan uca test edin.
30. Cutover ve rollback olmadan canlıya çıkmak: İlk ciddi farkta karar gecikir. Adım, kanıt, yetkili ve durdurma eşiğini önceden yazın.
31. Rollback'i sadece kod geri alma sanmak: Yeni kayıt, mesaj ve yan etkiler kalır. Veri, kuyruk, telafi ve roll-forward planını birlikte hazırlayın.
32. Hazır konektörün her şeyi desteklediğini varsaymak: Eksik alan veya yön canlıda fark edilir. Kapsam matrisini demo ve testle kanıtlatın.
33. ERP veritabanına kontrolsüz yazmak: İş kuralları ve audit atlanır. Desteklenen servis katmanını kullanın; zorunlu erişimi sınırlayın.
34. Yalnız ilk kurulum fiyatına bakmak: Lisans, kota, bakım ve exit maliyeti görünmez kalır. Aynı varsayımla çok yıllı TCO hesaplayın.
35. Sağlayıcı bağımlılığı ve çıkışı düşünmemek: Sözleşme sonunda veri veya süreç taşınamaz. Tam export, doküman ve geçiş şartlarını yazın.
36. Doğrulanmamış hazır entegrasyon vaadi vermek: Paket ve ERP sürüm farkları yanlış beklenti doğurur. Alan, yön, frekans ve özel proje sınırını teklif tarihinde doğrulayın.
37. AI önerisini test etmeden üretime uygulamak: Hallucination finansal veya stok etkisi yaratabilir. Hassas veri politikası, değerlendirme seti ve insan onayı kullanın.

Sıkça Sorulan Sorular

E-ticaret ERP entegrasyonu nedir?

ERP, Kurumsal Kaynak Planlama sistemidir; finans, satış, satın alma, stok, üretim veya lojistik gibi işletme kaynaklarını ürünün kapsamına göre yönetir. E-ticaret ERP entegrasyonu ise mağaza ile bu iç süreçler arasında ürün, fiyat, stok, müşteri, sipariş, ödeme, sevkiyat, belge ve iade verisinin tanımlı kurallarla alışverişidir.

ERP entegrasyonu hangi işletmeler için gereklidir?

Sipariş adedi tek başına ERP entegrasyonu gereksinimini belirlemez. Kanal ve depo sayısı, fiyat/cari kurallarının karmaşıklığı, üretim veya tedarik bağımlılığı, hata maliyeti ve denetim ihtiyacı birlikte değerlendirilir.

Stoktan faturaya tek veri akışı ne demektir?

Tek veri akışı, tek veritabanı değil, birbirini izleyen olayların güvenilir ve denetlenebilir bir yoldan geçmesidir. Ürün yayına çıkar, müşteri sipariş verir, ödeme veya onay koşulu oluşur, stok ayrılır, sevkiyat hazırlanır ve belge üretilir.

Fiyatlar ERP'den e-ticaret sitesine nasıl aktarılır?

Paket seçiminde “entegrasyon” tek kutu değildir. Ürün, fiyat, stok, sipariş, ödeme, kargo, cari, finans görünürlüğü, pazaryeri ve özel bağlantı gereksinimlerini ayrı satırlarda doğrulayın.

Çoklu depo stok entegrasyonu nasıl çalışır?

Fiziksel stok elde bulunan miktardır; rezerve stok siparişe ayrılan, tahsis edilmiş stok belirli depo veya kanala bağlanan, güvenlik stoğu satışa açılmayan tampon miktardır. Satılabilir stok bu bileşenlerden iş kuralıyla hesaplanır.

ERP entegrasyonu nasıl test edilir?

Teklifte görünen kurulum bedeli, toplam sahip olma maliyetinin yalnız bir parçasıdır. ERP/e-ticaret/iPaaS lisansları, API veya işlem kotaları, altyapı, geliştirme, test, veri temizliği, güvenlik, izleme, destek, sürüm yükseltme, kesinti operasyonu ve çıkış maliyeti ayrı hesaplanmalıdır.

ERP entegrasyonu başarısı nasıl ölçülür?

Başarı yalnız düşük API gecikmesi değildir. Veri doğruluğu, iş tamamlanma süresi, hata ve tekrar oranı, mutabakat farkı, kuyruk yaşı, manuel müdahale, belge durumu, toparlanma süresi ve kullanıcı etkisi birlikte izlenmelidir.

Uygulamaya Geçmeden Önce

E-ticaret ERP entegrasyonu yalnız API bağlamak veya siparişi bir sisteme kopyalamak değildir. Güvenilir tasarım; alan bazlı source of truth, değişmez kimlikler, açık veri sözleşmesi, idempotency, sıra kontrolü, kesinti kuyruğu, güvenlik, gözlemlenebilirlik, test ve düzenli mutabakatı aynı işletim modelinde birleştirir.

Gerçek zamanlılık tek başarı ölçütü değildir. Doğru veriyi görünür gecikmeyle taşımak, belirsiz sonucu güvenle sorgulamak, hatayı sahibine ulaştırmak ve kesinti sonrası mutabakatla toparlanmak çoğu zaman milisaniyeden daha değerlidir. Hazır konektör, özel entegrasyon ve iPaaS kararı; süreç özgünlüğü, hacim, ekip, bütçe, risk ve exit planıyla verilmelidir.

SoloCommerce değerlendirmesinde doğrulanmış paket özellikleriyle standart konektör, opsiyonel hizmet ve özel proje kapsamını ayırın. Stok doğruluğu, kesintisizlik, fatura başarısı, maliyet tasarrufu veya satış artışı için mutlak sonuç beklemek yerine alan/yön matrisi, pilot kanıtı, kabul testleri ve ölçülebilir SLO isteyin.

Solofor e-ticaret paketleri sayfasını inceleyerek ürün, fiyat, stok, sipariş, ödeme, kargo, cari, pazaryeri, finans görünürlüğü ve özel entegrasyon ihtiyaçlarınıza uygun güncel seçenekleri karşılaştırabilirsiniz. Harici ERP veya muhasebe bağlantısında desteklenen alanları, yönleri, sıklığı, hata yönetimini ve özel proje kapsamını teklif öncesinde yazılı netleştirin.