ERP Entegrasyonu ve Muhasebe Programı Bağlantısı

Entegrasyon nedir, ne değildir

Entegrasyon, iki sistemin birbirinin verisini okuyup yazabilmesidir. Muhasebe programınız yerinde kalır; yanına gelen sistem ondan veri alır, ona veri verir. Kimse veri göçü yaşamaz, kimse alışkanlığını değiştirmez.

Bunu üç şeyle karıştırmamak gerekiyor. Göç (migration), verinin bir programdan diğerine taşınıp eskisinin kapatılmasıdır — tek seferliktir. Uyarlama, programın kendi içinde ekran veya rapor özelleştirmesidir. Değiştirme ise mevcut programı bırakıp yenisine geçmektir. Bizim yaptığımız iş bunların hiçbiri değil: programınız kalır, yanına bir katman eklenir.

Bir uyarı: “entegrasyon” kelimesi her üründe aynı şeyi ifade etmiyor. Örneğin Zirve’nin kendi dokümantasyonunda entegrasyon, ticari taraftaki işlemlerin genel muhasebeye fiş olarak aktarılması anlamına gelir — yani program içi bir süreçtir, dış sistem bağlantısı değil. Görüşmeye başlarken hangi anlamda konuştuğumuzu netleştirmek, iki tarafın da zamanını kurtarıyor.

Hangi program verisini nasıl açar?

Entegrasyon planının ilk adımı, programın veriye hangi kapıyı açtığını bilmektir. Aşağıdaki tablo, Türkiye’de en yaygın kullanılan ürünlerin belgelenmiş erişim yollarını özetliyor. Her satır, üreticinin kendi dokümantasyonuna ya da doğrulanabilir teknik kaynaklara dayanıyor.

Üç kategori: entegrasyonun zorluğunu asıl belirleyen şey

Yukarıdaki tabloyu uzun uzun okumak istemiyorsanız, işin özeti şu: piyasadaki ürünler entegrasyon açısından üç gruba ayrılıyor ve hangi grupta olduğunuz, projenin ne kadar tahmin edilebilir olacağını belirliyor.

2026 notu: Logo kullanıcıları için geçiş dönemi

Logo, ürün hattını Logo Edge çatısı altında yeniden adlandırdı: Tiger ailesi T-Series, Netsis ailesi N-Series, j-Platform ise J-Series olarak konumlandırıldı. Üreticinin ürün sayfalarında bu seri adları yer alıyor.

Bunun entegrasyon açısından anlamı şu: önümüzdeki dönemde Logo kullanan firmaların bir kısmı sürüm geçişi yaşayacak. Mevcut entegrasyonların bu geçişte nasıl davranacağı, projenin baştan nasıl kurulduğuna bağlı. Doğrudan veritabanına yazan entegrasyonlar bu tür geçişlerde en kırılgan olanlardır; resmi arayüz üzerinden çalışanlar daha korunaklıdır.

Geçiş takvimi ve hangi ürünün hangi seriye karşılık geldiği konusunda tek doğru kaynak Logo ve yetkili bayinizdir — biz bayisi olmadığımız için bu bilgiyi sizin adınıza taahhüt etmiyoruz. Bizim işimiz, entegrasyonu sürüm geçişini kaldıracak şekilde kurgulamak.

Okuma ve yazma aynı risk sınıfında değil

Entegrasyon tartışmalarının çoğu bu ayrımı atladığı için kilitleniyor. Veriyi okumak ile veriyi yazmak teknik olarak da hukuken de farklı ağırlıkta işlerdir.

Nasıl kuruyoruz: ara katman ve kuyruk

İki sistemi doğrudan birbirine bağlamak en kolay ama en kırılgan yoldur: biri durduğunda diğeri de durur, biri güncellendiğinde diğeri kırılır. Bu yüzden arada bir katman kuruyoruz.

• Ara katman (middleware) — İki tarafın da bağlandığı, veriyi dönüştüren ve eşleştiren bağımsız servis. ERP değişse de saha uygulaması değişmez, saha uygulaması değişse de ERP etkilenmez.
• Kuyruk — Yoğun veri akışında kayıtlar kuyruğa alınır. ERP kapalıyken veya bakımdayken saha durmaz; bağlantı geri geldiğinde birikmiş kayıtlar sırayla işlenir.
• Eşleme tablosu — Stok kodu, cari kodu, birim ve ambar eşlemeleri kodda gömülü değil, yönetilebilir bir tabloda tutulur. Kod değişikliği geliştirici gerektirmez.
• İdempotent yazma — Aynı kayıt iki kez gönderilse bile ERP’de iki kez oluşmaz. Ağ kesintisi ve yeniden deneme senaryolarında mükerrer fiş oluşmasını bu engeller.
• Hata kaydı ve uyarı — Başarısız aktarımlar sessizce kaybolmaz; listelenir, sebebi yazılır ve yeniden denenebilir. Sessiz başarısızlık, entegrasyon projelerindeki en sinsi sorundur.

Entegrasyon bitmiş bir iş değildir

Bunu sözleşme aşamasında açıkça konuşuyoruz, çünkü sektörde en sık yaşanan hayal kırıklığı burada: entegrasyon kurulup teslim edilir, altı ay sonra ERP güncellenir ve bir sabah çalışmayı bırakır.

Bu bir kusur değil, işin doğası. ERP üreticileri her sürümde yeni alanlar ekliyor, uç noktalarını sürümlüyor ve bazen kırıcı değişiklikleri ayrıca ilan etmiyor. Örneğin Mikro’da hem uç noktalar V1, V2, V3 sonekiyle sürümlenir hem de büyük sürüm geçişinde servisin dinlediği port değişir; eski sürümü kullanan entegrasyon yeni alanları görmez, sabit port yazan entegrasyon ise kopar.

Bizim yaklaşımımız üç maddeli: entegrasyonu sürüm değişikliğine dayanıklı kurmak, ERP sürüm notlarını takip etmek ve her yükseltme öncesi bir kontrol turu yapmak. Entegrasyon bir gün durduğunda ilk muhatabınız biziz: teşhisi biz koyarız; sorun ürün tarafındaysa çözümü yetkili bayinizle birlikte yürütürüz. Bunun karşılığı bir bakım anlaşmasıdır — teslim sonrası 15 gün ücretsiz hata düzeltme standardımızdır, süreklilik gerektiren takip ise ayrı bir kalemdir.

ERP bayileri ve çözüm ortakları için taşeron mühendislik

Bu sayfayı iki farklı kişi okuyor. Birincisi programı kullanan firma. İkincisi o programı satan bayi.

Bayi tarafındaki tablo tanıdık: müşteri “şu da olsa” diyor, istek standart ürünün dışında kalıyor, işi geri çevirmek istemiyorsunuz ama bünyede geliştirme ekibi yok. Bu noktada biz devreye giriyoruz.

• Müşteri ilişkisi ve ticari muhatap sizde kalır — biz yalnızca geliştirme tarafını üstleniriz
• İstenirse beyaz etiketli çalışırız: müşteriye karşı görünen taraf sizsiniz
• Kapsam ve fiyat baştan sabitlenir, böylece müşterinize verdiğiniz teklif havada kalmaz
• Ürün bilgisi ve lisans tarafı sizin uzmanlığınızdır; biz o alana girmeyiz, sizin belirlediğiniz arayüz ve yöntemle çalışırız
• Tek seferlik proje de olur, sürekli geliştirme kapasitesi de

Ne zaman entegrasyon yapmamalısınız

Her sorunun cevabı entegrasyon değil. Aşağıdaki durumlarda projeyi kabul etmiyoruz ya da önce başka bir şey öneriyoruz — çünkü yanlış yerde kurulan entegrasyon mevcut sorunu otomatikleştirerek büyütür.

• Stok kodları iki sistemde tutarsızsa — önce kod düzeni oturtulmalı. Karışık kodları bağlamak karışıklığı hızlandırır.
• Aktarılacak süreç zaten hatalıysa — bozuk süreci otomatikleştirmek onu daha hızlı bozar, düzeltmez.
• Günde birkaç kayıt söz konusuysa — elle giriş daha ucuz ve daha az risklidir. Dürüst cevap budur.
• Mevcut program kısa vadede değişecekse — entegrasyonu yeni programdan sonra kurmak gerekir.
• Karar vericiler hangi verinin doğru kabul edileceği konusunda anlaşamamışsa — bu teknik değil, yönetim sorunudur ve önce o çözülmelidir.

Nasıl başlıyoruz

• Teknik keşif — Hangi ürün, hangi sürüm, kaç firma ve dönem, hangi modüller kullanılıyor. Bu bilgi olmadan verilen her süre tahminidir.
• Arayüz ve lisans teyidi — Kullanılacak arayüzün o kurulumda mevcut olup olmadığı, ek modül veya lisans gerekip gerekmediği yetkili bayinizle birlikte teyit edilir.
• Salt okuma pilotu — Önce yalnızca veri okunur. Hiçbir kayıt değişmez; bağlantının çalıştığı, verinin doğru yorumlandığı risksiz şekilde görülür.
• Eşleme ve kural tanımı — Kodlar, birimler ve ambarlar eşlenir; hangi olayın hangi kaydı oluşturacağı yazılı hale gelir.
• Yazma tarafı ve test — Resmi arayüz üzerinden yazma açılır, önce test ortamında doğrulanır.
• Devreye alma ve izleme — Hata kaydı, uyarı ve yeniden deneme mekanizması ile canlıya geçilir.