EDI Entegrasyonu Nedir? B2B Sipariş Otomasyonu Rehberi

EDI Entegrasyonu Nedir?

Bir üretici veya toptancı işletmenin büyük kurumsal müşterilerinden her gün onlarca sipariş aldığını düşünün.

Siparişlerden bazıları e-posta ile Excel dosyası olarak geliyor. Bazıları müşterinin satın alma portalından indiriliyor. Başka bir müşteri kendi ERP sisteminden dosya gönderiyor.

Satış operasyonundaki çalışan bu siparişleri açıyor ve şirket ERP’sine tekrar giriyor.

Ürün kodu, miktar, teslimat adresi, fiyat ve sipariş numarası tek tek aktarılıyor.

Bu süreçte yapılan küçük bir veri giriş hatası yanlış ürünün veya yanlış miktarın sevk edilmesine kadar ilerleyebilir.

EDI — Electronic Data Interchange, işletmeler arasındaki sipariş, sevkiyat ve fatura gibi yapılandırılmış ticari belgelerin sistemler arasında elektronik ve standartlaştırılmış biçimde aktarılmasını sağlar.

Temel amaç şudur:

Müşterinin sistemi → entegrasyon → sizin ERP sisteminiz

Aradaki manuel veri girişini mümkün olduğunca ortadan kaldırmak.

Güncel EDI entegrasyon çözümlerinde sipariş, fatura ve sevkiyat belgelerinin ERP sistemlerine bağlanması; EDIFACT, X12, XML, JSON ve CSV gibi farklı formatların dönüştürülmesi temel yetenekler arasında bulunuyor.

EDI ile API Aynı Şey mi?

Hayır.

İki kavram birlikte kullanılabilir ancak aynı problemi farklı seviyelerde çözer.

API, iki yazılımın birbiriyle nasıl iletişim kuracağını tanımlar.

EDI ise şirketler arasında değiştirilen ticari belgelerin yapısını ve süreçlerini standartlaştırmaya odaklanır.

Örneğin bir müşteriniz size EDIFACT formatında sipariş gönderiyor olabilir.

Bu sipariş:

EDIFACT → Entegrasyon Servisi → JSON → ERP API

şeklinde işlenebilir.

Burada EDI ticari mesaj standardını, API ise ERP ile teknik iletişimi sağlar.

Bu nedenle “EDI mi API mi?” sorusu her zaman doğru soru değildir. Gerçek projelerde ikisi aynı mimarinin parçaları olabilir.

Hangi Belgeler EDI ile Aktarılabilir?

EDI yalnızca sipariş aktarmak için kullanılmaz.

Ticari ilişkinin farklı noktalarında farklı mesajlar kullanılabilir.

Örneğin:

• Satın alma siparişi
• Sipariş teyidi
• Sevkiyat bildirimi
• İrsaliye bilgisi
• Fatura
• Stok bilgisi
• Fiyat listesi

Uluslararası yapılarda EDIFACT veya X12 gibi standartlar kullanılabilir.

Örneğin EDIFACT dünyasında ORDERS sipariş, DESADV sevkiyat bildirimi ve INVOIC fatura süreçlerinde kullanılan mesaj türleri arasındadır. Güncel entegrasyon platformlarında bu mesajların ERP sistemleriyle eşleştirilmesi destekleniyor.

Ancak işletmenin bütün mesaj tiplerini ilk projede desteklemesi gerekmez.

En yüksek manuel iş yükünü oluşturan süreçten başlamak daha mantıklıdır.

B2B Sipariş Otomasyonu Nasıl Çalışır?

Bir örnek üzerinden ilerleyelim.

Bir otomotiv yan sanayi üreticisinin kurumsal müşterisi sipariş gönderiyor.

Siparişte:

Müşteri ürün kodu: AX-554
Miktar: 800
Teslim tarihi: 24 Eylül

bulunuyor.

Ancak üreticinin ERP sistemindeki ürün kodu:

PRD-10482

olabilir.

Entegrasyon katmanında müşteri ürün kodu şirketin ürün kartıyla eşleştirilir.

Akış şöyle ilerleyebilir:

1. Sipariş alınır.

2. Mesaj formatı doğrulanır.

3. Müşteri tanımlanır.

4. Ürün kodları eşleştirilir.

5. Miktar ve birimler kontrol edilir.

6. ERP’de satış siparişi oluşturulur.

7. Sonuç müşteriye veya entegrasyon sistemine bildirilir.

Başarılı otomasyon yalnızca dosyayı bir sistemden diğerine taşımak değildir.

Verinin iş kurallarına göre doğrulanması gerekir.

Ürün Kodu Eşleştirmesi Neden Kritik?

B2B entegrasyon projelerinde sık karşılaşılan problemlerden biri tarafların aynı ürünü farklı kodlarla tanımlamasıdır.

Müşteri:

ABC-001

kullanırken tedarikçi:

STK-8921

kullanabilir.

Entegrasyon katmanında bir ürün eşleştirme tablosu tutulabilir.

Aynı durum ölçü birimlerinde de oluşabilir.

Müşteri siparişi “10 koli” olarak gönderirken ERP stok birimini “adet” olarak tutuyor olabilir.

Bir koli 24 adetse dönüşüm kuralının açıkça tanımlanması gerekir.

Aksi halde teknik olarak başarılı görünen entegrasyon operasyonel olarak yanlış sipariş oluşturabilir.

Her Sipariş Doğrudan ERP’ye Kaydedilmeli mi?

Her zaman değil.

Bazı işletmeler için tamamen otomatik kayıt uygun olabilir.

Ancak yüksek riskli siparişlerde doğrulama katmanı kullanılabilir.

Örneğin sistem şu kontrolleri yapabilir:

• Müşteri aktif mi?
• Ürün kodu eşleşiyor mu?
• Ölçü birimi tanımlı mı?
• Sipariş numarası daha önce işlendi mi?
• Teslimat adresi geçerli mi?
• Fiyat tolerans dışında mı?
• Miktar olağan dışı mı?

Tüm kurallar geçerse sipariş otomatik oluşturulur.

Bir kural başarısız olursa kayıt:

İnceleme Gerekiyor

kuyruğuna alınabilir.

Böylece otomasyon ile insan kontrolü arasında dengeli bir yapı kurulabilir.

Aynı Siparişin İki Kez Oluşması Nasıl Önlenir?

Bu konu entegrasyon tasarımının kritik ayrıntılarından biridir.

Bir müşteriden sipariş geldiğini ve ERP’ye başarıyla işlendiğini düşünün.

Ancak cevap mesajı gönderilirken ağ bağlantısı kesiliyor.

Müşteri sistemi siparişin başarısız olduğunu düşünüp aynı mesajı tekrar gönderiyor.

Entegrasyon sistemi yalnızca “gelen her mesajı kaydet” mantığıyla çalışıyorsa ERP’de iki sipariş oluşabilir.

Bu nedenle idempotency veya benzersiz işlem kontrolü gerekir.

Örneğin:

Müşteri + Sipariş Numarası

kombinasyonu benzersiz kabul edilebilir.

Aynı sipariş tekrar geldiğinde sistem yeni kayıt oluşturmak yerine mevcut işlemin sonucunu döndürür.

Bu prensip yalnızca EDI değil, güvenilir API entegrasyonlarının da temel kararlarından biridir.

Hatalar Nasıl Yönetilmeli?

Entegrasyon projelerinde “hata olmayacak” varsayımı gerçekçi değildir.

Ürün eşleşmesi eksik olabilir.

Müşteri bilinmeyen bir depo kodu gönderebilir.

ERP geçici olarak erişilemez olabilir.

Bu nedenle sistem hatayı yalnızca log dosyasına yazıp bırakmamalıdır.

Operasyon ekibi şu bilgileri görebilmelidir:

Sipariş: 45001824
Müşteri: ABC
Durum: İşlenemedi
Neden: Ürün kodu eşleşmesi bulunamadı
Aksiyon: Ürün eşleştirmesini tamamla ve yeniden işle

Sorun giderildikten sonra sipariş tekrar işlenebilmelidir.

Böylece teknik ekibin her operasyonel hataya manuel müdahale etmesi gerekmez.

ERP Hangi Verinin Ana Kaynağı Olmalı?

Entegrasyon başlamadan önce veri sahipliği belirlenmelidir.

Örneğin:

ERP: Ürün, stok, fiyat ve siparişin ana kaynağı

CRM: Müşteri ilişkileri ve satış fırsatları

B2B Portal: Kullanıcı deneyimi ve sipariş giriş kanalı

EDI Katmanı: Sistemler arası mesaj dönüşümü ve aktarımı

Aynı bilginin birden fazla sistemde bağımsız olarak düzenlenebilmesi veri tutarsızlığı yaratabilir.

SynapTech’in ERP çözümünde de stok, sipariş, üretim ve satın alma süreçlerinin tek ve tutarlı veri kaynağı etrafında yönetilmesi; mevcut sistemlerle entegrasyon temel yaklaşım olarak yer alıyor.

EDI Entegrasyonu ile B2B Portal Birlikte Kullanılabilir mi?

Evet.

İki kanal farklı müşteri profillerine hizmet edebilir.

Büyük bir kurumsal müşteri kendi ERP sisteminden otomatik EDI siparişi göndermek isteyebilir.

Daha küçük bir bayi ise web tabanlı B2B portalına girerek sipariş oluşturabilir.

Her iki kanalın siparişleri aynı ERP’ye aktarılabilir:

Kurumsal müşteri ERP → EDI → ERP

Bayi → B2B Portal → API → ERP

Böylece işletme müşteriye tek bir sipariş yöntemi dayatmak zorunda kalmaz.

Güncel B2B ticaret platformlarında da ERP fiyatlarının, siparişlerin, EDI ve müşteri portalı kanallarının birlikte yönetildiği modeller bulunuyor.

Güvenlikte Nelere Dikkat Edilmeli?

EDI entegrasyonu doğrudan ticari işlem oluşturabildiği için güvenlik yalnızca bağlantının şifrelenmesi değildir.

Şu sorular cevaplanmalıdır:

• Mesajı gerçekten hangi müşteri gönderdi?
• Bağlantı nasıl doğrulanıyor?
• Hangi müşteri hangi mesaj tipini gönderebilir?
• Gelen dosyalar doğrulanıyor mu?
• Hassas veriler loglarda tutuluyor mu?
• İşlem geçmişi denetlenebilir mi?
• Hatalı veya şüpheli sipariş durdurulabiliyor mu?

AS2, SFTP veya güvenli API gibi taşıma yöntemleri kullanılabilir. Güncel EDI platformları farklı kurumsal bağlantı yöntemlerini destekliyor.

Teknoloji seçimi müşterinin ve ticaret partnerinin gereksinimlerine göre yapılmalıdır.

EDI Projesine Nereden Başlanmalı?

İlk aşamada bütün müşterileri entegre etmeye çalışmak yerine yüksek hacimli tek bir ticaret partneri seçmek daha yönetilebilir olabilir.

Örneğin son bir ayı inceleyin:

• Kaç sipariş manuel girildi?
• Sipariş başına kaç satır bulunuyor?
• Hangi bilgiler tekrar giriliyor?
• Hangi hatalar oluşuyor?
• Müşteri hangi formatları destekliyor?
• ERP hangi entegrasyon imkanlarını sunuyor?

Ardından yalnızca sipariş alma akışıyla pilot yapılabilir.

Süreç stabil hale geldikten sonra sipariş teyidi, sevkiyat bildirimi ve fatura gibi mesajlar eklenebilir.

Bu yaklaşım entegrasyonun teknik olarak çalışmasının yanında operasyon ekibinin de yeni sürece uyum sağlamasına yardımcı olur.

Sık Sorulan Sorular

EDI yalnızca büyük şirketler için mi?

Hayır. Ticaret partnerlerinin gereksinimleri ve işlem hacmi uygunsa KOBİ’ler de EDI kullanabilir. Yatırım kararında manuel işlem yükü ve entegrasyon maliyeti birlikte değerlendirilmelidir.

EDI için mevcut ERP’yi değiştirmek gerekir mi?

Her zaman değil. ERP API, dosya aktarımı veya başka uygun entegrasyon yöntemleri sunuyorsa araya entegrasyon katmanı kurulabilir.

EDI ile e-fatura aynı şey mi?

Hayır. EDI şirketler arasındaki farklı ticari mesajların elektronik değişimini kapsayan daha geniş bir kavramdır. E-fatura ise faturanın elektronik oluşturulması ve iletilmesine odaklanan belirli bir süreçtir.

Sipariş tamamen otomatik oluşturulabilir mi?

Evet, ancak müşteri, ürün, miktar ve tekrar sipariş gibi doğrulama kurallarının tanımlanması gerekir. Riskli durumlar manuel inceleme kuyruğuna yönlendirilebilir.

API varsa EDI’ye ihtiyaç yok mu?

Bu iki teknoloji birbirinin doğrudan alternatifi değildir. EDI ticari belge standardını, API ise sistemler arasındaki teknik iletişim yöntemlerinden birini sağlayabilir.

Kurumsal müşterilerinizin siparişleri bugün e-posta, Excel veya farklı portallardan geliyor ve ekibiniz bunları ERP’ye tekrar giriyorsa önce tek bir siparişin müşteriden ERP’ye kadar geçtiği yolu haritalayın. SynapTech, mevcut ERP’nizi değiştirmeden EDI, API ve özel entegrasyon servisleriyle sipariş akışını doğrulanabilir ve izlenebilir biçimde otomatikleştiren çözümler geliştirebilir.