E-Ticaret ERP Entegrasyonu: Ürün, Fiyat, Stok ve Sipariş Akışı

Ürün fiyatını bir sistemde, stok miktarını başka yerde değiştiriyor ve gelen siparişi yeniden elle yazıyorsanız entegrasyon ihtiyacı doğmuş olabilir. Ancak “e-ticaret ERP'ye bağlanacak” ifadesi tek başına uygulanabilir kapsam değildir. Bu rehber, ürün, fiyat, stok ve sipariş akışlarını ayrı ayrı planlamanızı ve aktarım hatalarını görünür kılmanızı sağlar.

Entegrasyon hangi verileri taşıyacak?

Bir ev gereçleri satıcısının online mağazası ve depo sistemi bulunduğunu düşünün. Ürün merkezde açılıyor, mağazada açıklaması hazırlanıyor ve sipariş depoda işleniyor. Hangi bilginin hangi sistemde üretildiği net değilse aynı alan iki tarafta farklı değerlere dönüşebilir.

Önce ürün, fiyat, stok, müşteri ve sipariş verilerini listeleyin. Her biri için kaynak, hedef, aktarım yönü ve güncelleme koşulu belirleyin. Bütün verileri çift yönlü taşımak zorunda değilsiniz; gereksiz yönler çakışmayı artırabilir.

Bu yazıda ERP, işletmenin ürün ve operasyon kayıtlarını yöneten mevcut kurumsal sistemi ifade eder. Kullandığınız ürünün bağlantı olanakları farklı olabilir. Lisans, API erişimi ve test ortamını ilgili sağlayıcıdan doğrulayın.

Hangi sistem asıl veri kaynağı olmalı?

Ürün kodu merkezden, pazarlama açıklaması mağazadan yönetilebilir. Aynı ürünün bütün alanlarının tek yerde olması zorunlu değildir. Önemli olan her alanın sahibinin ve değişiklik kuralının belli olmasıdır.

Tablodaki kaynaklar örnektir; işletmenizin çalışma düzenine göre değişir. Kararı yazılı hâle getirin ve sorumlu çalışanlara gösterin. “Ben burada düzelttim, neden geri değişti?” sorusu çoğu zaman bu sahiplik kuralının belirsizliğini gösterir.

Ürün ve varyant eşleştirmesinde neye dikkat edilmeli?

Aynı ürünün renk, ölçü veya paket seçenekleri farklı varyantlar olabilir. Merkezde tek kart, mağazada çok varyant bulunuyorsa eşleştirme açıklanmalıdır. Yanlış ilişki, doğru görünen stoğun yanlış ürüne yazılmasına neden olabilir.

Ürün kodlarının boş, tekrarlı veya değişken olduğu kayıtları aktarım öncesinde temizleyin. Görsel, açıklama ve teknik alanların ne şekilde taşınacağını belirleyin. Eksik alanı rastgele başka üründen doldurmak yerine inceleme listesine alın.

• Tekil kimlik: Ürün veya varyantın ayırt edici kodu.
• Birim: Adet, paket veya koli farkının karşılığı.
• Durum: Aktif, taslak veya satıştan kaldırılmış kayıt.
• Alan sahipliği: Açıklama, görsel ve teknik bilgiyi kimin yönettiği.

İlk aktarım ile sonraki güncellemeleri ayrı test edin. İlk açılışta doğru görünen ürün, güncelleme sırasında elle eklenen web açıklamasını kaybedebilir. Hangi alanların korunacağını kabul koşuluna yazın.

Fiyat değişikliği hangi koşullarla yansımalı?

Vergi, para birimi, iskonto ve kampanya kurallarının hangi sistemde hesaplandığını belirleyin. Bu yazı vergi uygulaması önermez; işletmenizin geçerli hesap kurallarının iki tarafta aynı yorumlanmasını hedefler. Örnek kayıtları ilgili sorumlularla doğrulayın.

Merkezde değişen fiyatın mağazaya ne zaman aktarılacağı açık olsun. Güncelleme başarısız olduğunda eski fiyatın kaldığı görülebilmelidir. Büyük değişikliklerin yayın öncesi inceleme gerektirip gerektirmediğine işletme karar vermelidir.

Kampanya bitince hangi değere dönüleceğini de konuşun. Mağazada tanımlanan bir promosyon ile merkezdeki standart fiyat birbirini yanlışlıkla ezmemelidir. Kuralları birkaç gerçek örnekle test etmek soyut “fiyat eşitlenecek” ifadesinden daha yararlıdır.

Stok ve sipariş aynı anda değişirse ne olur?

Son ürün farklı kanallarda aynı anda talep edilebilir. Entegrasyonun ne kadar sık çalıştığı kadar rezervasyonun nerede yapıldığı da önemlidir. Ekranda görünen miktarın hangi iş durumlarını içerdiğini tanımlayın.

Sipariş alınması, ödemenin sonucu ve depodan çıkış farklı olaylardır. Stok her birinde aynı biçimde düşülürse mükerrer hareket oluşabilir. Hangi olayın hangi stok hareketini başlatacağını açıkça eşleyin.

İptal ve iade durumlarında da ters hareketin ne zaman oluşacağını belirleyin. Ürünün fiziksel olarak geri gelmesi ile müşterinin iade talebi açması farklıdır. İnceleme bekleyen ürünün satışa uygun miktara hemen eklenmesi istenmeyebilir.

Sipariş aktarımında hangi bilgiler birlikte gitmeli?

Sipariş kimliği, ürün kalemleri, miktarlar, müşteri bilgileri ve gerekli teslim ayrıntıları eşleştirilmelidir. Her alıcı bilgisinin hedefte gerçekten gerekli olup olmadığını değerlendirin. Veri aktarımını işin gerektirdiği kapsamla sınırlayın.

Hedef sistem siparişi kabul ettiğinde mağazadaki kayıtla bağlantısı korunsun. Sadece “gönderildi” yazmak, merkezde kaydın oluştuğunu doğrulamayabilir. Merkez kayıt kimliği ve aktarım sonucu izlenebilir olmalıdır.

Kısmi sevkiyat varsa siparişin tamamını tek durumla kapatmak yetmeyebilir. Kalem bazında gönderilen ve bekleyen miktarların hangi sistemden döneceğini belirleyin. Müşteri ekranı ile depo gerçeği farklı görünmemelidir.

Aktarım başarısız olursa ne yapılmalı?

Bağlantı zaman aşımına uğradığında hedef sistem işlemi yapmış fakat yanıt dönememiş olabilir. Tekrar gönderim aynı siparişi ikinci kez oluşturmamalıdır. Teknik ekipten tekrarlı iş olaylarının nasıl tanındığını açıklamasını isteyin.

Shopify'ın webhook teslimlerini doğrulama rehberi, aynı bildirimin birden çok kez gelebileceğini ve işlemlerin buna göre tasarlanmasını açıklar; erişim 28 Ekim 2026. Bu, bütün platformların aynı yöntemi kullandığı anlamına gelmez; kendi sisteminizin davranışını doğrulayın.

Hata listesinde kayıt, neden, son deneme ve sorumlu kişi görülebilsin. Bazı sorunlar otomatik yeniden denemeyle çözülebilir; yanlış ürün kodu gibi durumlar insan düzeltmesi gerektirebilir. İkisini ayırmak gereksiz deneme trafiğini önler.

Entegrasyon hangi testlerle kabul edilmeli?

Yalnızca bir başarılı sipariş göndermek yeterli değildir. Ürün değişikliği, fiyat güncellemesi, eksik stok, iptal, iade ve bağlantı kesintisini deneyin. Test verisinin iki tarafta da neyi ifade ettiği anlaşılır olsun.

1. Alan eşleştirme: Kod, birim ve varyant doğru mu?
2. Güncelleme: Sahibi farklı olan alanlar korunuyor mu?
3. Tekrar: Aynı olay yeniden geldiğinde sonuç değişiyor mu?
4. Kesinti: Bekleyen işlem kaybolmadan görülebiliyor mu?
5. Uzlaştırma: İki sistemdeki sonuçlar karşılaştırılabiliyor mu?

Geçişten önceki siparişlerin nasıl ele alınacağını da belirleyin. Yeni bağlantı çalışmaya başladığında eski kayıtların yeniden işlenmesi istenmeyebilir. Başlangıç sınırı ve gerekli arşiv aktarımı ayrı kararlar olmalıdır.

Bütçe ve devreye alma nasıl planlanmalı?

Bağlantı erişimi, veri eşleştirme, geliştirme, hata ekranları ve test işlerini ayrı görün. Hazır bağlantı sunuluyorsa desteklediği alanları kendi senaryonuzla kontrol edin. Ek lisans veya sağlayıcı desteği gereksinimini teklif aşamasında doğrulayın.

Varsayımsal 20-35 kişi-gün iş ve 6.000 TL kişi-gün bedeliyle 120.000-210.000 TL geliştirme hesabı oluşur. Bu piyasa fiyatı veya Navdion teklifi değildir. KDV, ERP lisansı, dış hizmet ve kapsam dışı veri temizliği dahil değildir.

Örnek pilot planında sınırlı ürün ve sipariş grubuyla iki haftalık gözlem yapılabilir. Bu süre standart değildir; işlem çeşitliliği ve sağlayıcı erişimleri belirleyicidir. Günlük uzlaştırmayla eksik veya tekrarlı kayıtları kontrol edin.

Operasyon hazırlığını e-ticaret başlangıç rehberiyle birlikte değerlendirin. Bağlantının genel iş akışındaki yerini ise süreç otomasyonu rehberindeki sorumluluk yaklaşımıyla ele alın.

Sipariş aktarılırken bağlantı kesilirse ne olur?

Mağazada oluşan sipariş merkeze gönderilsin ve yanıt gelmeden bağlantı kesilsin. Operasyon çalışanı siparişi göremediği için elle eklemek isteyebilir. Önce hedefte kaydın oluşup oluşmadığını doğrulayacak yöntem bulunmalıdır; aksi durumda aynı iş iki kez hazırlanabilir.

Aktarım ekranı son durumu ve yapılacak kontrolü açıkça gösterebilir. Gerekirse yetkili kullanıcı aynı kaydı güvenli biçimde yeniden dener. Elle düzeltme yapıldıysa bunun asıl siparişle bağlantısı korunmalı, otomatik akış yeniden başladığında ikinci kez işlem oluşmamalıdır.

Bu senaryoyu pilotta teknik ekip ve depo sorumlusuyla birlikte deneyin. Sistem doğru sonucu verse bile çalışan ekranın anlamını bilmiyorsa yanlış geçici çözüm uygulayabilir. Hata yönetimi hem teknik davranış hem günlük kullanım eğitimi gerektirir.

Günlük uzlaştırmada hangi kayıtlar karşılaştırılmalı?

Mağazada oluşan siparişler ile merkezde kabul edilen kayıtları ortak kimlik üzerinden karşılaştırın. Eksik, tekrarlı veya farklı durumda görünenleri inceleme listesine alın. Yalnızca toplam adet eşitse bütün kayıtların doğru olduğunu varsaymayın; iki hata birbirini sayısal olarak gizleyebilir.

Önceliği müşterinin işini etkileyen farklara verin. Gönderilmeyen sipariş, yanlış miktar veya kapanmış görünen bekleyen kalem ayrı nedenlerle oluşabilir. Düzeltmeden önce kaynağı anlayın ve yapılan işlemi kayda geçirin.

Entegrasyon olgunlaştığında da bu kontrolü tamamen unutmayın. Yeni ürün tipi, ek kanal veya güncellenen dış sistem farklı davranış getirebilir. Değişikliklerden sonra önemli örnekleri yeniden deneyin ve veri sahipliği belgesini güncel tutun.

Sonuç: Önce veri sahipliğini belirleyin

Ürün, fiyat, stok ve sipariş için kaynakları ve iş kurallarını ayrı tanımlayın. Tekrar gönderim, kesinti ve iptal senaryolarını test edip sınırlı pilotla ilerleyin. Navdion ile e-ticaret entegrasyonu ihtiyacınızı değerlendirmek için ücretsiz proje analizi talep edebilirsiniz.