ERP entegrasyonu, şirketin kaynak planlama yazılımındaki ürün, stok, fiyat, cari, sipariş ve fatura bilgisinin e-ticaret sitesi, CRM, bayi portalı gibi diğer sistemlerle elle aktarım olmadan, kurallı ve izlenebilir biçimde alışverişidir. Pratikteki karşılığı basittir: muhasebeci sabah Excel'den stok yüklemez, satış ekibi siparişi ikinci kez yazmaz, müşteri sitede "stokta var" görüp telefonda "kalmamış" cevabı almaz.
Teknik kısmı çoğu zaman sanıldığından kolaydır. Zor olan, iki karara baştan net cevap vermektir: Hangi veri hangi sistemin malıdır? ve ERP'ye hangi kapıdan girilecek? Bu yazı bu iki kararı, CRM ile ERP arasındaki sınırı ve Türkiye'ye özgü e-Fatura katmanını ele alıyor.
Kısa cevap: ERP entegrasyonu, ERP'deki verinin diğer sistemlerle otomatik ve denetlenebilir biçimde paylaşılmasıdır. Sağlam bir entegrasyon dört şeye dayanır:
- Veri sahipliği tablosu: her bilginin tek bir "asıl" sistemi olur, diğerleri onu okur.
- Doğru bağlantı yolu: öncelik üreticinin resmî API'si veya nesne kütüphanesidir. Veritabanına doğrudan yazılmaz.
- Değişmeyen eşleştirme anahtarları: stok kodu, vergi numarası, sipariş numarası.
- Görünür hata yönetimi: reddedilen kayıt bir log dosyasında kaybolmaz, sorumlu kişinin ekranına düşer.
Türkiye'de ERP ve CRM Ne Kadar Yaygın?
Türkiye'de en az 10 çalışanı olan girişimlerin yüzde 28,3'ü ERP, yüzde 12'si CRM yazılımı kullanıyor. Fark şirket büyüklüğüyle açılıyor:
Kaynak: TÜİK, Girişimlerde Bilişim Teknolojileri Kullanım Araştırması 2025 (Anadolu Ajansı aktarımı)
Bu tablodan çıkan sonuç şu: büyük şirketlerin dörtte üçünde ERP var ama CRM ancak yarısından azında. Yani pek çok firmada müşteri ilişkisi hâlâ e-posta kutularında ve tablolarda yürüyor, sipariş ve fatura ise ERP'de. Entegrasyon projelerinin büyük bölümü de tam bu boşlukta başlıyor: ERP zaten var, etrafına bir site, bir portal veya bir CRM eklenecek ve hepsinin aynı rakamı göstermesi gerekiyor.
Önce Karar: Hangi Veri Hangi Sistemin?
Her bilginin tek bir asıl kaynağı olmalı. Diğer sistemler o bilgiyi okur, gerekiyorsa önbelleğe alır, ama değiştirmez. Bu kural yazılmadığında iki sistem aynı alanı güncellemeye başlar ve bir hafta sonra kimse hangi stok rakamının doğru olduğunu bilmez.
Bir entegrasyon projesinin başında doldurulması gereken tablo kabaca şöyle görünür. Satırlar sizin işinize göre değişir, ama sorular hep aynıdır:
| Veri | Asıl sahibi (tipik) | Okuyan sistemler | Akış yönü | Ne sıklıkla? |
|---|---|---|---|---|
| Ürün kartı (kod, ad, birim, vergi) | ERP | Site, portal, pazaryeri | ERP → dışarı | Değiştikçe |
| Pazarlama içeriği (görsel, açıklama) | Site / ürün içerik sistemi | Pazaryeri | Site → dışarı | Değiştikçe |
| Fiyat listesi ve iskonto | ERP | Site, portal, CRM teklifleri | ERP → dışarı | Değiştikçe + gece tam eşitleme |
| Stok | ERP (depo) | Site, portal, pazaryeri | ERP → dışarı | Dakikalar mertebesinde |
| Potansiyel müşteri ve fırsat | CRM | — | CRM içinde kalır | — |
| Cari kart | ERP | CRM, portal | CRM → ERP (ilk siparişte), sonra ERP → CRM | Olay bazlı |
| Teklif | CRM | ERP (onaylanınca) | CRM → ERP | Olay bazlı |
| Sipariş | Siparişin girildiği kanal, sonra ERP | CRM, portal | Kanal → ERP, durum ERP → kanal | Anında |
| Fatura ve e-belge | ERP + e-belge entegratörü | Site, portal, CRM | ERP → dışarı | Olay bazlı |
| Kargo / sevk durumu | ERP veya kargo firması | Site, portal | Dışarı → müşteri ekranı | Saatlik veya olay bazlı |
İki satır çoğu tartışmayı başlatır. Birincisi pazarlama içeriği: ERP'deki ürün adı genellikle "VİDA M8X30 GALV" gibidir ve sitede kullanılamaz. Bu yüzden ürünün teknik kimliği ERP'de, vitrindeki anlatımı başka bir yerde tutulur ve iki kayıt stok kodu ile eşleşir. İkincisi cari kart: aşağıda CRM bölümünde döneceğiz.
ERP'ye Bağlanmanın Dört Yolu
ERP'ye dışarıdan erişmenin dört yolu vardır. Bunlardan biri neredeyse her zaman yanlıştır. Hangisinin elinizde olduğu ise ERP'nin sürümüne, kurulum tipine ve lisans paketine göre değişir. Logo, Netsis, Mikro veya SAP Business One kullanıyor olun, bu soruyu ERP iş ortağınızla projeden önce netleştirin.
| Yol | Nasıl çalışır? | Artısı | Riski | Görüşümüz |
|---|---|---|---|---|
| Resmî API / web servis | ERP'nin HTTP üzerinden sunduğu REST veya SOAP servisleri | ERP'nin iş kurallarından geçer, güncellemelerde korunur | Her işlem servis olarak açılmamış olabilir, ek lisans gerekebilir | İlk tercih |
| Üreticinin nesne kütüphanesi (SDK) | ERP sunucusuna yakın çalışan bir programın üretici kütüphanesiyle kayıt açması | API'nin açmadığı belge tiplerine erişim, yine iş kurallarından geçer | Genellikle Windows sunucusuna ve belirli sürüme bağlıdır | API yetmezse ikinci tercih |
| Doğrudan veritabanı | ERP'nin SQL veritabanından okumak, hatta yazmak | Hızlı, her tabloya erişim | Yazma iş kurallarını atlar; tablo yapısı sürüm güncellemesinde değişebilir | Yazma: hayır. Okuma: salt okunur görünüm ve ayrı kullanıcıyla, dikkatle |
| Dosya aktarımı | ERP'den veya ERP'ye Excel, CSV, XML dosyaları; elle ya da zamanlanmış | Her ERP'de vardır, kurulumu kolay | Gecikmeli, hatalar sessizce birikir, kimin yüklediği belirsizleşir | Geçici çözüm veya düşük hacim |
Örnek olarak SAP Business One'ın Service Layer'ı, SAP'nin kendi tanımıyla "SAP Business One verisini kullanmanızı sağlayan bir REST API" ve OData 3.0 ile 4.0 standartlarını destekliyor. Yerli ERP'lerin çoğunda da benzer bir servis katmanı ya da nesne kütüphanesi bulunur. Önemli olan, bunun sizin sürümünüzde açık ve lisanslı olup olmadığıdır.
Doğrudan veritabanına yazmaya neden bu kadar karşıyız? Çünkü ERP'de "bir sipariş" tek bir satır değildir. Başlık, satırlar, stok rezervasyonu, cari hareket, belge numarası sayacı ve bazen onay akışı birlikte oluşur. Arayüz bunları birlikte ve tutarlı yazar. Dışarıdan bir SQL komutu ise yalnızca kendisine söyleneni yazar. Sorun da genellikle hemen değil, ay sonu kapanışında ortaya çıkar.
Yerinde Kurulu ERP: Bulut Uygulaması Ofisteki Sunucuya Nasıl Ulaşır?
Türkiye'de pek çok ERP hâlâ şirketin kendi sunucusunda çalışıyor. E-ticaret sitesi veya bayi portalı ise bulutta. Aradaki boşluğu kapatmanın en temiz yolu, şirket ağının içine kurulan küçük bir köprü servisidir:
- Köprü servisi ERP'nin yanında çalışır ve ERP ile yerel ağda konuşur.
- Dışarıya yalnızca giden bağlantı açar. Bekleyen siparişleri buluttan çeker, stok ve fiyat değişikliklerini buluta iter.
- Böylece güvenlik duvarında içeriye doğru bir port açmak gerekmez. ERP veritabanı internete hiç görünmez.
- İnternet kesildiğinde köprü kuyruğu tutar. Bağlantı gelince kaldığı yerden devam eder, aynı siparişi iki kez yazmaz.
Alternatifler de var: şirket ağıyla bulut arasında site-to-site VPN kurmak ya da ERP'nin bulut sürümüne geçmek. VPN çalışır ama bakım yükü BT ekibinizdedir. ERP'nin bulut sürümüne geçmek ise kendi başına bir projedir ve yalnızca entegrasyon için yapılmaz. Hangi yolu seçerseniz seçin, köprünün çalışıp çalışmadığını dışarıdan izleyen bir kontrol kurun. Bunun için bir uptime izleme aracı yeterlidir; örneğin kendi ürünümüz olan UptimeTR bu tür kontrolleri yapar. Genel olarak izleme mantığını uptime rehberimizde anlattık.
CRM ile ERP Arasındaki Sınır Nerede?
CRM satışın öncesini, ERP satışın sonrasını yönetir. Sınır genellikle teklifin onaylandığı andır. O ana kadar potansiyel müşteri, fırsat, görüşme notu ve teklif CRM'de yaşar. Teklif onaylandığında iki şey olur: müşteri ERP'de cari kart hâline gelir ve teklif ERP'ye sipariş olarak geçer.
Bu sınırı yanlış çizen projelerde en sık görülen üç sorun şunlardır:
- Her potansiyel müşterinin ERP'de cari kart olarak açılması. Bir yıl sonra muhasebede hiç hareket görmemiş yüzlerce kart birikir. Cari kartı ilk siparişte açın.
- Unvanla eşleştirme. "ABC Ltd. Şti." ile "ABC Limited Şirketi" iki ayrı müşteri olur. Eşleştirme anahtarı vergi kimlik numarası (bireyler için TC kimlik numarası) olmalı. CRM bu numarayı en geç teklif aşamasında istemeli.
- Fiyatın iki yerde hesaplanması. CRM'deki teklif ekranı kendi iskonto mantığını çalıştırırsa, ERP'deki fiyat listesiyle bir gün mutlaka ayrışır. Teklif ekranı fiyatı ERP'den sormalı, satış temsilcisinin yetkisi dahilindeki ek iskonto ayrı bir satır olarak taşınmalıdır.
Sipariş ERP'ye geçtikten sonra akış ters döner. Sevk, fatura ve tahsilat durumu ERP'den CRM'e geri gelir. Böylece satış temsilcisi müşterisini aradığında "faturanız kesildi, kargo yolda" diyebilir ve muhasebeye sormak zorunda kalmaz.
e-Fatura Katmanı: ERP mi Keser, Site mi?
Türkiye'de entegrasyonun ERP ile bitmediği bir katman daha vardır: e-belge. Gelir İdaresi Başkanlığı e-Fatura için üç yararlanma yöntemi tanımlıyor: e-Fatura Portalı, entegrasyon ve özel entegrasyon. Özel entegrasyon, GİB'in ifadesiyle "faturalama ihtiyaçları farklılık gösteren veya çok sayıda fatura düzenleyen mükelleflere" kendi altyapıları yetersizse "teknik yeterliliğe sahip bir özel entegratörün bilgi işlem sistemi vasıtasıyla" fatura alıp gönderme imkânı veriyor (GİB, özel entegrasyon).
Pratikte çoğu işletmede zincir şöyledir: sipariş ERP'ye gelir, fatura ERP'de oluşur, ERP faturayı özel entegratöre iletir. Buradan çıkan entegrasyon kuralı şudur: e-ticaret sitesi veya portal kendi başına ayrı bir fatura numarası üretmemeli. Faturayı ERP keser. Site, faturanın PDF'ini ve durumunu ERP'den veya entegratörden okuyup müşteriye gösterir. Aksi hâlde aynı satış için iki belge, iki numara ve ay sonunda uzlaştırılması gereken bir fark oluşur.
Bu bölüm genel bilgilendirmedir. Hangi e-belgeye tabi olduğunuzu ve hangi yöntemi kullanacağınızı mali müşavirinizle netleştirin.
Hazır Bağlayıcı mı, Özel Entegrasyon mu?
ERP'niz yaygın bir ürünse ve kullandığınız e-ticaret altyapısı veya pazaryeri aracı onun için hazır bir bağlayıcı sunuyorsa, önce onu deneyin. Standart alanlarla çalışan bir işletmede hazır bağlayıcı çoğu zaman yeterlidir ve daha ucuzdur.
Özel entegrasyon şu durumlarda kendini öder:
- ERP'de firmanıza özel alanlar, belge tipleri veya depo yapısı varsa ve bağlayıcı bunları taşıyamıyorsa,
- fiyat kuralınız müşteri, kanal ve miktara göre değişiyorsa,
- birden fazla sistem (site, portal, CRM, pazaryeri) aynı ERP'ye bağlanacaksa ve her biri için ayrı bir bağlayıcı yerine tek bir ara servis istiyorsanız,
- hataların kimde ve nerede görüneceğini kendiniz belirlemek istiyorsanız.
Senaryoya özel ayrıntıları ayrı yazılarda ele aldık: bayi siparişlerinin ERP'ye yazılması için B2B bayi portalı rehberimize, Trendyol ve Hepsiburada gibi kanallar için pazaryeri entegrasyonu rehberimize bakabilirsiniz.
Bir Entegrasyon Projesi Nasıl Planlanır?
Bir ERP entegrasyonunun takvimini kodlama değil, keşif ve test belirler. Önerdiğimiz sıra şöyledir:
1. Veri sahipliği tablosu ve alan eşleştirmesi. Yukarıdaki tablo sizin işinize göre doldurulur. Ardından her alanın karşılığı çıkarılır: sitedeki "renk" ERP'de hangi alan, birimler (adet, koli, metre) nasıl çevrilecek, KDV oranı nereden gelecek?
2. Test ortamı. Canlı ERP'ye hiçbir şey yazılmadan önce bir test şirketi veya canlı verinin kopyası olan bir deneme veritabanı hazırlanır. ERP iş ortağınızın burada desteği gerekir. Bunu baştan planlamak haftalar kazandırır.
3. Hata senaryoları listesi. "Her şey yolunda" akışı en kolay kısımdır. Asıl iş şu sorulara cevap vermektir: Ürün ERP'de pasife alınırsa? Cari kartın vergi numarası eksikse? ERP bakımdaysa? Aynı sipariş iki kez gelirse? Her senaryonun bir sahibi ve bir ekranı olur.
4. Paralel çalıştırma. İlk haftalarda entegrasyon çalışırken eski yöntem (Excel, elle giriş) bir süre yanında devam eder ve sonuçlar günlük karşılaştırılır. Fark sıfıra inince eski yöntem kapatılır.
5. İzleme ve devir. Entegrasyonun durduğunu müşteri şikâyetinden değil, bir uyarıdan öğrenmelisiniz. Son kuyruk işleminin zamanı, reddedilen kayıt sayısı ve köprü servisinin ayakta olup olmadığı tek bir ekranda görünmeli.
Digitexa'dan Bir Örnek
Parça E-Kuralkan, Kuralkan'ın motosiklet yedek parça satışı için geliştirdiğimiz özel e-ticaret platformu. 50.000'den fazla ürün, bayi bazlı özel fiyatlandırma ve ERP entegrasyonu içeriyor. Stok yönetimi tamamen otomatik, yani elle güncelleme gerektirmiyor. Proje 6 ayda tamamlandı. Bu ölçekte bir katalogda ekranlardan önce yukarıdaki tablonun ilk dört satırı belirleyicidir: ürün kartı kimde, fiyat kimde, stok ne sıklıkla ve hangi anahtarla taşınacak.
Sonuç
ERP entegrasyonu bir "bağlantı kurma" işi gibi görünür ama aslında bir sahiplik işidir. Önce her verinin tek sahibini yazın, sonra ERP'ye hangi resmî kapıdan gireceğinizi seçin, eşleştirmeyi değişmeyen anahtarlarla yapın ve hataları görünür kılın. Bu dört karar netse kodlama kısmı, projenin en öngörülebilir kısmı olur.
ERP'nizi siteniz, bayi portalınız veya CRM'inizle konuşturmak istiyorsanız özel yazılım geliştirme sayfamızda nasıl çalıştığımızı görebilirsiniz. 2019'dan bu yana web, e-ticaret ve özel yazılım projeleri geliştiren bir yazılım ajansı olarak ilk görüşmede veri sahipliği tablonuzu birlikte çıkarabiliriz. İletişim sayfamızdan görüşme planlayabilirsiniz.
Bu yazıyı nasıl hazırladık? Yazı yapay zeka araçlarının desteğiyle hazırlandı. İstatistikler ve GİB alıntıları bağlantısı verilen sayfalardan kontrol edildi. Parça E-Kuralkan bilgileri kendi proje sayfamızdan alındı. Yöntem karşılaştırması ve öneriler kendi proje deneyimimize dayanan görüşlerimizdir. e-Belge bölümü genel bilgilendirme amaçlıdır, mali veya hukuki görüş değildir.
