Muhasebe tarafı Logo üzerinde oturmuş, ekip alışmış ve mali müşavir aynı düzenle çalışıyor. Buna karşılık saha ekibi hâlâ kâğıtla dolaşıyor ve siparişler akşam ofiste yeniden yazılıyor.
Bu tabloda mevcut sistemi değiştirmek, çözülmek istenenden çok daha büyük bir sorun üretir. Asıl ihtiyaç, mali kayıt düzenini korurken saha ve mobil tarafını hızlandırmaktır.
Bu yazıda Logo ile birlikte çalışan bir kurulumun nasıl yapılacağını, veri akış yönlerini, eşleme tanımlarını ve kurulum adımlarını anlattık.
İçindekiler
Birlikte çalışma modeli
EQLEM bir çözüm platformudur ve mevcut ERP sisteminizin yerini almak üzere kurgulanmamıştır. Amaç, o sistemin kapsamadığı alanları tamamlamak ve iki yapıyı birbirine bağlamaktır.
Bu modelde Logo mali kayıtların merkezi olarak kalır ve muhasebe süreçleri hiç değişmez. Mali müşavirinizin çalışma düzenine dokunulmaz.
Platform ise saha satışı, mobil kullanım, pazaryeri operasyonu ve müşteri ilişkileri gibi alanlarda devreye girer. Bu alanlar klasik muhasebe yazılımlarının doğal kapsamı dışındadır.
İki sistem arasında kurulan senkron, aynı bilginin iki kez girilmesini önler. Çift veri girişi, entegrasyonun çözdüğü ilk ve en somut sorundur.
Bu yaklaşımın en büyük avantajı, sistem değiştirme riskini hiç almadan yeni yetenek kazandırmasıdır.
Hangi kayıt nerede doğar?
Entegrasyon kurulumunun en kritik kararı, her veri türünün hangi sistemde oluşturulacağıdır. Bu karar netleşmeden teknik kurulum yapılmamalıdır.
Her veri türünün tek bir sahibi olmalıdır ve diğer sistem o veriyi yalnızca okumalıdır. İki yerde birden oluşturulan kayıtlar kaçınılmaz olarak çakışır.
Yaygın kurguda cari ve stok kartları mevcut sistemde doğar; muhasebe düzeni bunu gerektirir. Platform bu kartları okur ve operasyonda kullanır.
Buna karşılık saha siparişleri, ziyaret kayıtları ve müşteri aktiviteleri platformda doğar. Bunların mevcut sistemde karşılığı zaten yoktur.
Bu kararların yazılı hale getirilmesi ve ekiple paylaşılması, sonraki tartışmaları baştan önler.
Cari kart akışı
Cari kartlar, neredeyse her kurulumda paylaşılan ilk veri türüdür. Müşteri bilgisi hem muhasebe hem saha tarafında gereklidir.
Genel kurguda kartlar mevcut sistemde açılır ve platforma aktarılır. Böylece vergi bilgileri ve muhasebe kodları tek yerde yönetilir.
Saha ekibinin yeni müşteri kaydı açması gerektiğinde ise farklı bir kurgu gerekir. Bu kayıtlar aday olarak açılıp onaydan sonra mevcut sisteme aktarılabilir.
Cari bakiyelerin de aktarılması, saha ekibinin müşteri riskini görmesini sağlar. Bakiyeyi bilmeden yapılan sevkiyat, tahsilat sorununa dönüşür.
Kart yapısını cari hesap kartı yazısında ele aldık.
Stok kartı ve bakiye akışı
Stok kartları da genellikle mevcut sistemde tanımlanır ve platforma aktarılır. Ürün kodlarının tek yerden yönetilmesi tutarlılık sağlar.
Bakiye akışı ise daha dikkat gerektirir çünkü sık değişen bir veridir. Eski bakiye bilgisi, sahada yanlış sipariş sözü verilmesine yol açar.
Bu nedenle stok senkronu diğer veri türlerinden daha sık çalıştırılır. Sıklık, hareket hacmine göre belirlenir.
Platformda oluşan hareketlerin de mevcut sisteme yansıması gerekir. Aksi halde iki tarafın stoğu birbirinden ayrışır.
Depo eşleşmesi bu noktada kritiktir; yanlış depo tanımı, stoğun yanlış yere yazılmasına neden olur.
Belge aktarımı
Entegrasyonun asıl değeri, belge aktarımında ortaya çıkar. Sahada oluşan siparişin ofiste yeniden yazılması bu adımla sona erer.
Siparişler platformda oluşturulur ve mevcut sisteme aktarılır. Faturalama ve muhasebeleştirme orada devam eder.
Aktarım anı da belirlenmelidir; sipariş onaylandığında mı yoksa gün sonunda mı gönderileceği kurguya bağlıdır.
Aktarılan belgenin numarası her iki tarafta da izlenebilir olmalıdır. Bu bağ, sonraki kontrollerin dayanağını oluşturur.
Tahsilat kayıtları da benzer şekilde aktarılabilir; saha tahsilatı ofise anında yansır.
Eşleme tanımları
İki sistemin veri yapıları birebir örtüşmediği için ayrıntılı bir eşleme tanımı gerekir. Bu tanım, entegrasyonun sessiz omurgasıdır.
Kart kodlarının eşleştirilmesi ilk adımdır ve mümkünse ortak bir kod yapısı kullanılmalıdır. Ortak kod, eşlemeyi neredeyse gereksiz kılar.
Birim tanımları da eşlenmelidir; farklı birimler tutar farklarına yol açar. Kilogram ile gram karışıklığı bin katlık hatalar üretir.
Vergi oranları ve döviz tanımlarının eşleşmesi de tutarların doğruluğu için şarttır.
Depo, şube ve belge türü karşılıkları da tanımlanmalıdır; bunlar atlandığında kayıtlar yanlış yere düşer.
Bağlantı ve güvenlik
Logo genellikle şirket ağındaki bir sunucuda çalışır ve buluttan doğrudan erişilemez. Bu, bir kısıt değil güvenlik açısından doğru bir yapıdır.
Bu nedenle yerel ağa kurulan bir bağlantı bileşeni kullanılır. Bileşen dışarıdan gelen bağlantıyı kabul etmez; bağlantıyı kendisi kurar.
Bu model, güvenlik duvarında port açılmasını gereksiz kılar. Sunucu dış dünyaya açılmadan veri alışverişi yapabilir.
Erişim yetkileri de sınırlı tutulmalıdır; bileşen yalnızca ihtiyaç duyduğu tablolara erişmelidir.
Mimariyi on-prem agent yazısında ayrıntılandırdık.
Hata yönetimi
Hiçbir entegrasyon hatasız çalışmaz; önemli olan hataların görünür olması ve düzeltilebilmesidir.
En yaygın hata, karşılığı bulunmayan kart kaynaklıdır. Bir tarafta olmayan kod, aktarımı durdurur ve kayıt kuyrukta bekler.
İkinci sırada bağlantı kesintileri gelir. Bu durumda kayıtların kaybolmaması ve bağlantı geldiğinde gönderilmesi gerekir.
Başarısız aktarımlar tek bir listede toplanmalı ve günlük kontrol edilmelidir. Sessizce biriken hatalar günler sonra fark edilir.
İzleme düzenini entegrasyon hatalarını izlemek yazısında anlattık.
Kurulum adımları
Kurulum, mevcut sistemin sürümünün ve yapılandırmasının tespitiyle başlar. Kapsam, sürüme göre farklılık gösterebilir.
İkinci adımda kayıt sahipliği ve akış yönleri kararlaştırılır. Bu adım teknik değil, yönetimsel bir karardır.
Üçüncü adımda bağlantı bileşeni kurulur ve erişim test edilir. Ağ tarafındaki hazırlık bu aşamada tamamlanır.
Dördüncü adımda eşleme tanımları yapılır ve az sayıda kayıtla deneme aktarımı gerçekleştirilir.
Son adımda kapsam kademeli genişletilir; tüm veri türlerini aynı anda açmak, sorunları ayırt etmeyi zorlaştırır.
Dikkat edilecek noktalar
Kayıt sahipliğinin belirsiz bırakılması, entegrasyon projelerinin en yaygın başarısızlık nedenidir. Teknik sorunların çoğu bu belirsizlikten doğar.
Kapsamın gereğinden geniş tutulması da bakım yükünü sürdürülemez hale getirir. Her ek veri türü kalıcı bir sorumluluk demektir.
Mevcut sistemin sürüm güncellemeleri de takip edilmelidir; veri yapısı değişiklikleri entegrasyonu etkileyebilir.
Test aşamasının atlanması, canlıda düzeltilmesi zor veri sorunlarına yol açar.
Kapsam ve sürüm uyumu her kurulumda ayrıca doğrulanmalıdır; genel bir taahhüt yerine sizin kurulumunuz değerlendirilmelidir.
Sık sorulanlar
Mevcut sistemimizi bırakmamız gerekir mi?
Gerekmez; EQLEM mevcut ERP sisteminizin yanında çalışır ve mali kayıt düzeninize dokunmaz.
Hangi sürümlerle çalışır?
Kapsam sürüme ve yapılandırmaya göre değişir; mevcut kurulumunuz için desteği önceden birlikte teyit ediyoruz.
Sunucumuza dışarıdan erişim açılır mı?
Açılmaz; bağlantı içeriden dışarıya kurulur ve güvenlik duvarında port açılması gerekmez.
Çift yönlü senkron mümkün mü?
Mümkündür; ancak alan bazında sahiplik tanımlanmalıdır. Senkron çatışması yazısına bakın.
Mevcut muhasebe düzenini korurken saha ve mobil tarafını hızlandırmak, çoğu işletme için en düşük riskli yol. Sistem değiştirme projeleri, kazandırdığından fazlasını götürebiliyor.
Kayıt sahipliğini baştan netleştirin ve yazılı hale getirin; entegrasyon projelerindeki tartışmaların neredeyse tamamı bu belirsizlikten doğuyor.
Kapsamı da dar tutarak başlayın; cari ve stok akışı çalışır hale geldikten sonra belge aktarımını eklemek çok daha kolay oluyor.
Ortak kod yapısı kullanmaya çalışın; eşleme tablolarına duyulan ihtiyacı büyük ölçüde ortadan kaldırıyor.
Hata listesini günlük kontrol etmeyi de rutine bağlayın; sessizce biriken aktarım hataları en pahalı sürprizleri üretiyor.
EQLEM ekibiyle görüşerek entegrasyon kapsamınızı netleştirebilirsiniz.