DİA’nız yerinde kalır; sahayı, e-ticareti ve yönetim panelini DİA’ya web servisi üzerinden bağlarız. Bulutta kestirme yol yok — tek kapı var ve o kapıdan her geçiş kontör olarak sayılıyor; mimariyi buna göre kurarız.
DİA bulut tabanlı bir ERP’dir; doğrudan veritabanı erişimi yoktur. Üreticinin geliştirici dokümantasyonunda tanımlanan tek entegrasyon yolu web servistir.
Arayüz JSON tabanlı REST’tir ve TLS 1.2 veya üzeri zorunludur. Adres kalıbı sunucu koduyla başlar, modül adıyla devam eder; servisler modül_nesne_aksiyon biçiminde adlandırılır.
Kimlik doğrulama iki aşamalıdır: API anahtarıyla oturum açılır, dönen session_id her servis çağrısının ilk parametresi olur.
Oturum bir saat işlemsizlikten sonra düşer; her çağrı süreyi sıfırlar. Tazeleme mantığı koda yazılmalıdır.
Her web servis çağrısı 0,0125 kontör tüketir; login ve logout gibi bazı işlemler muaftır.
Yani DİA’da mimariyi belirleyen şey istek limiti değil, çağrı maliyetidir — sürekli yoklama pahalıdır.
Yazma resmi olarak desteklenir: ekleme, güncelleme ve silme servisleri vardır ve yanıtta kaydın anahtarı ile işlem mesajı (msg alanı) döner. Üretici yazmayı kendi arayüzüne açmıştır.
Bulutta kestirme yol yok: web servis tek kapı
Masaüstü ERP entegrasyonlarında tartışmanın büyük kısmı “veritabanına doğrudan bağlanalım mı” sorusu etrafında döner. DİA’da bu tartışma hiç başlamaz. Ürün bulutta çalışır, veritabanı müşterinin makinesinde durmaz ve üreticinin geliştirici dokümantasyonunda tanımlanan tek entegrasyon yolu web servistir. Arkada hangi veritabanı yönetim sisteminin çalıştığı açıklanmaz — pratikte de entegrasyonu ilgilendirmez.
Bu kısıt gibi görünen durum aslında planlamayı kolaylaştırıyor. Şema değişikliğini takip etmek, tablo adı tahmin etmek, kolon kodlarını çözmek gibi işler gündemden düşüyor. Yerine tek bir soru geliyor: ihtiyacınız olan veri, belgelenmiş servisler arasında var mı? Bu sorunun cevabı keşif görüşmesinde verilebilir ve verildikten sonra takvim gerçekçi olur.
Arayüz JSON tabanlı REST’tir ve bağlantının TLS 1.2 ya da üzeri ile kurulması zorunludur. Eski bir sunucudan veya eski bir çalışma zamanından çağrı yapmayı planlıyorsanız, bunu ilk gün kontrol ediyoruz; eski çalışma zamanlarında ilk bağlantı hatası çoğu zaman koddan değil, çağrıyı yapan tarafın TLS yapılandırmasından çıkar.
Adres kalıbı da tahmin gerektirmiyor: müşteriye özel sunucu koduyla başlayan bir alt alan adı, ardından sürümlü JSON REST yolu ve modül adı gelir; kalıbın güncel hâli proje başında üretici dokümanından teyit edilir. Sunucu kodu müşterinin kendi kurulumuna aittir; yani aynı kodu iki farklı müşteride kullanmak diye bir şey yoktur, yapılandırma en baştan müşteri bazlı tasarlanmalıdır.
Adlandırmanın bu kadar düzenli olması, entegrasyon katmanını jenerik yazabilmemizi sağlıyor: nesne adı ve aksiyon parametre haline geliyor, her servis için ayrı kod yazılmıyor. Bu da yeni bir nesne devreye alındığında geliştirme süresini kısaltıyor.
DİA web servislerinde modül kodu ve adlandırma düzeni. Servis adları modül_nesne_aksiyon kalıbını izler; hangi nesnelerin ve aksiyonların o kurulumda açık olduğu proje başında teyit edilir.
Modül kodu
Kapsam
Adlandırma örneği
sis
Sistem tarafı — oturum açma, kontör sorgulama, yetki
Oturum, anahtar ve yetki: dört bilgi olmadan bağlantı kurulmaz
DİA’da kimlik doğrulama iki aşamalıdır ve bu ayrımı kavramak entegrasyonun yarısıdır. Önce API anahtarıyla oturum açma servisi çağrılır; bu servis bir session_id döner. Sonraki her servis çağrısında bu session_id ilk parametre olmak zorundadır. API anahtarı yalnızca oturum açma adımında kullanılır — sonraki çağrılarda anahtarı taşımak gerekmez, hatta taşınmamalıdır.
Oturumun ömrü bir saattir ve bu süre işlemsizlik üzerinden işler: her çağrı sayacı sıfırlar. Buradan iki pratik sonuç çıkıyor. Birincisi, yoğun çalışan bir entegrasyonda oturumu her seferinde yeniden açmak gereksizdir; mevcut oturum yeniden kullanılmalıdır. İkincisi, gece boyunca hiç çağrı yapmayan bir entegrasyon sabah ilk çağrısında düşmüş bir oturumla karşılaşır — bu durumun sessizce hata üretmemesi için oturum tazeleme mantığının koda yazılması gerekir.
Entegrasyonu başlatmak için gereken bilgi listesi kısadır ama eksiksiz olmalıdır: API anahtarı, web servis kullanıcı adı ve şifresi, firma kodu ve dönem kodu. Kullanıcı tarafında ayrıca bir yetki şartı var — ilgili kullanıcıda “Web Servis Çağırabilir” yetkisinin açık olması gerekiyor. Bu yetki kapalıyken alınan hata çoğu zaman yanlış yorumlanır ve saatlerce kodda aranır.
Bir de ağ tarafı var: hesapta “İzin Verilen IP’ler” tanımlıysa çağrılar yalnızca o adreslerden kabul edilir. Entegrasyon katmanını bulutta çalıştırıyorsanız çıkış IP’sinin sabit olması gerekir; değilse bu kısıtın nasıl yönetileceği mimarinin bir parçası haline gelir. Keşifte sorduğumuz sorulardan biri tam olarak budur.
Kontör: DİA entegrasyonunda mimariyi belirleyen tek kalem
Bu bölüm, bu sayfanın diğer program sayfalarından ayrıldığı yer. Çoğu üründe entegrasyonun sınırını “saniyede kaç istek atabilirim” sorusu çizer. DİA’da sınırı çizen şey farklı: üretici dokümanı API çağrıları için “işlem sınırı bulunmamaktadır” diyor, buna karşılık her web servis çağrısı 0,0125 kontör tüketiyor. Login ve logout gibi bazı işlemler bu tüketimden muaf. Kalan bakiye sis_kontor_sorgula servisiyle sorgulanabiliyor.
Farkı görmek için iki tasarımı yan yana koymak yeterli. Klasik yaklaşımda entegrasyon her dakika “yeni sipariş var mı” diye sorar. Veri değişmemiş olsa bile çağrı yapılmıştır ve tüketim gerçekleşmiştir. Gün boyunca bunu birkaç nesne için tekrarladığınızda, hiçbir iş yapılmadan ciddi bir çağrı hacmi üretilmiş olur. Olay odaklı ya da filtreli tasarımda ise çağrı yalnızca gerçek bir iş olduğunda veya belirli bir aralıkta, hedefi daraltılmış şekilde yapılır.
Bu yüzden DİA projelerinde ilk oturduğumuz masa kod değil, çağrı planıdır. Hangi nesne hangi sıklıkla okunacak, hangi filtreyle daraltılacak, hangi işlem tekil çağrı yerine liste çağrısıyla toplanabilir — bunlar yazılmadan geliştirmeye başlamıyoruz. Bir entegrasyonun kontör davranışını sonradan düzeltmek, baştan doğru kurmaktan çok daha zahmetli; çünkü mesele bir ayarı değiştirmek değil, akışın kendisini yeniden kurgulamak oluyor.
Şeffaflık adına şunu da yazalım: burada bir kontör bütçesi ya da tahmini tüketim rakamı vermiyoruz, çünkü bu tamamen kapsama bağlı ve müşterinin kendi hesabındaki koşullarla birlikte anlam kazanıyor. Yaptığımız şey, tasarımı öngörülebilir hale getirmek ve tüketimi izlenebilir kılmak.
Aynı ihtiyacın farklı tasarımlarda çağrı davranışı. Tüketim değerleri üreticinin tanımına dayanır; hesabınızdaki muafiyetler ve bakiye kurulumda teyit edilir.
Tasarım tercihi
Çağrı davranışı
Sonuç
Sürekli yoklama
Kısa aralıklarla, filtresiz liste servisi çağrılır
Veri hiç değişmese bile her tur tüketim üretir
Aralıklı ve filtreli çekme
Belirlenen aralıkta, tarih veya durum filtresiyle tek çağrı
Çağrı sayısı öngörülebilir, boşa tur büyük ölçüde kalkar
Liste + hedefli getir
Önce liste alınır, yalnızca gereken kayıtta tekil getir çağrılır
Tekil çağrı sayısı gerçek ihtiyaca sınırlanır
Olay tetiklemeli akış
Değişiklik olduğunda tek yönlü tetikle iş başlatılır
Çağrı yalnızca gerçek iş olduğunda üretilir
Oturum yeniden kullanımı
session_id süresi dolmadan yeniden kullanılır
Tüketim açısından muaf olsa da ağ turu ve gecikme azalır
Okuma ve yazma: aynı kapı, farklı sorumluluk
Masaüstü ürünlerde okuma ve yazma ayrımı fiziksel bir ayrımdır: okuma veritabanından, yazma resmi arayüzden yapılır. DİA’da böyle bir ayrım yoktur — iki iş de aynı web servis kapısından geçer. Ama sorumluluk farkı ortadan kalkmaz, sadece yer değiştirir.
Okuma — asıl risk yanlış rakam değil, gereksiz çağrı
Okuma tarafında kayıt bozma riski yoktur; servis size veriyi olduğu gibi döner. Buradaki risk maliyet ve tutarlılık tarafında toplanıyor.
Firma kodu ve dönem kodu her çağrının bağlamını belirler; çok firmalı ya da çok dönemli kurulumlarda bu iki değer yapılandırmadan gelmeli, koda gömülmemelidir
Filtresiz liste çağrısı hem gereksiz tüketim üretir hem de gereksiz veri taşır — sayfalama ve tarih aralığı baştan tasarıma girer
Raporlama ihtiyacı yüksekse veriyi her seferinde DİA’dan çekmek yerine, aralıklı çekme turlarıyla beslenen yerel bir rapor tablosu tutmak hem panel hızını hem kontör tüketimini düzeltir
Oturumun düşmesi okuma akışında sessiz boşluk üretebilir; tazeleme ve yeniden deneme mantığı okuma tarafında da zorunludur
Yazma — üretici kapıyı kendisi açmış, o kapıdan geçiyoruz
DİA tarafında yazma bir gri alan değil. Nesneler için ekleme, güncelleme ve silme servisleri resmi olarak tanımlı. Daha da önemlisi, ekleme ve güncelleme yanıtları oluşan ya da değişen kaydın anahtar değerini ve işlem mesajını (msg alanı) geri döndürüyor. Bu iki bilgi, sağlam bir entegrasyonun temel malzemesi: anahtar sayesinde karşı taraftaki kaydı kendi kaydımızla eşleştirebiliyor, işlem mesajı sayesinde de ne olduğunu kayıt altına alabiliyoruz.
Bunun pratik karşılığı şu: DİA’da “yazmayalım, riskli” demek için teknik bir gerekçe yok. Üretici yazmayı kendi arayüzüne açmış ve geri bildirimi de standart hale getirmiş. Bizim işimiz bu imkânı disiplinli kullanmak — aynı kaydın iki kez gönderilmesi durumunda ikinci kaydın oluşmaması için dönen anahtarı saklamak ve her yazma işlemini yeniden denenebilir kurgulamak.
Silme tarafında ise tutumumuz farklı. Silme servisi var diye entegrasyonun silme yetkisiyle çalışması gerekmiyor. Çoğu projede entegrasyon kullanıcısına silme yetkisi vermiyoruz; iptal ve düzeltme akışlarını güncelleme üzerinden kurguluyoruz. Yanlışlıkla çalışan bir döngünün geri alınamaz sonuç üretmesini en ucuz engelleme yolu budur.
Tetikleme mi, zamanlanmış çekme mi?
Kontör gerçeği yüzünden DİA’da “olay olduğunda haber ver” yaklaşımı, “sürekli sorup dur” yaklaşımından yalnızca zarif değil, doğrudan daha ekonomik. Bu yüzden tetikleme imkânını her projede masaya koyuyoruz.
DİA tarafında webhook ile başlatılan türde süreç tanımlanabiliyor; sürece bir geri çağırma adresi ve bir jeton giriliyor. Buradaki dürüst ifade şu: bunun genel amaçlı bir nesne webhook’u mu, yoksa dar kapsamlı bir süreç tetikleyicisi mi olduğu bizim doğrulayabildiğimiz kaynaklarda net değil. Bu yüzden sayfada kesin bir kapsam iddiası yazmıyoruz — süreç tetikleyici düzeyinde webhook tanımlanabiliyor, kapsamı ve hangi olaylara bağlanabileceği projeye göre teyit edilir.
Pratikte tasarımı iki katmanlı kuruyoruz. Tetikleme mümkünse ana yolu o oluşturuyor: olay geldiğinde entegrasyon uyanıyor, yalnızca ilgili kaydı çekiyor ve işini yapıyor. Tetiklemenin kapsamadığı ya da tetiğin kaybolduğu durumlar için arkada düşük sıklıkta, dar filtreli bir mutabakat turu çalışıyor. Bu ikinci katman güvenlik ağıdır; ana yol değildir ve ana yol gibi sık çalışmaz.
Geri çağırma adresini açarken bir güvenlik notu daha var: adres internete açık olduğu için gelen isteğin gerçekten beklenen kaynaktan geldiğini doğrulamak gerekiyor. Süreçte tanımlanan jeton bunun için var ve entegrasyon tarafında doğrulanmadan işlem başlatılmıyor.
Sürüm yükseltmesinde ne oluyor? Burada karar sizde değil
Masaüstü ERP’lerde yükseltme bir karardır: tarih seçilir, yedek alınır, gece çalışılır. Bulut ERP’de böyle bir karar anı yoktur. Ürün üreticinin takvimine göre güncellenir ve müşteri bunu onaylamaz. Bu, entegrasyon açısından hem avantaj hem sorumluluktur.
Avantaj tarafı açık: şema değişikliğini takip etmek, veritabanı üzerindeki nesnelerin bozulması, yükseltme sonrası tabloların yeniden eşlenmesi gibi masaüstü dünyasının klasik dertleri burada yok. Adres kalıbının içinde bir sürüm işareti bulunuyor, yani arayüzün kendisi sürümlü bir yüzey olarak tasarlanmış. Bu da değişikliğin rastgele değil, yönetilen bir şekilde geleceğini gösteriyor.
Sorumluluk tarafı ise şu: güncelleme zamanını siz seçmediğiniz için entegrasyonun “o gün müsait değilim” deme lüksü yok. Bu nedenle DİA entegrasyonlarında dayanıklılığı koda yazıyoruz — beklenmeyen alanlar yok sayılıyor, eksik alanlar patlamaya değil kayda dönüşüyor, başarısız çağrılar kuyrukta bekliyor ve yeniden deneniyor. Bir gün bir yanıt beklediğimiz biçimde gelmezse entegrasyonun durması değil, o kaydı işaretleyip devam etmesi gerekiyor.
Burada somut bir kırılma örneği vermiyoruz; çünkü doğrulanmış bir örnek elimizde yok ve olmayan bir örneği uydurmak bu sayfanın değerini sıfırlar. Yazdığımız şey bir tahmin değil, bir mühendislik duruşu: değişimin ne zaman geleceğini bilmediğiniz bir yüzeyle çalışıyorsanız, entegrasyonu değişimi kaldıracak şekilde yazarsınız.
Hata düzeltme teslimden sonra 15 gün ücretsiz. Bulutta asıl süreklilik izlemeyle sağlanır: çağrı hataları, oturum düşmeleri ve tüketim eğrisi takip edilmezse bir sorun ancak kullanıcı şikâyetiyle fark edilir. Bu izleme hizmeti 15 günün içinde değil, sözleşmede ayrı bir bakım maddesinde tanımlanır.
DİA çözüm ortakları için: anahtar sizde, kod bizde
Bu sayfanın ikinci okuyucusu, DİA satan ve kuran taraf. Sizin için buradaki denklem diğer ERP’lerden biraz farklı işliyor: API anahtarı üretici dokümanına göre DİA’dan talep edilse de uygulamada bu talebe çoğu zaman siz aracılık ediyorsunuz. Yani müşterinin önündeki idari kapı büyük ölçüde sizin elinizde; eksik olan şey çoğu zaman o kapının arkasındaki geliştirme kapasitesi.
Biz tam olarak o boşluğa oturuyoruz. Anahtar, lisans, kontör bütçesi ve müşteri ilişkisi sizde kalır; web servis üzerinden yazılacak entegrasyon kodu ve bakımı bizde olur. Bu ayrım sadece iş bölümü değil, aynı zamanda bir güvence: hiçbir üreticinin çözüm ortağı olmadığımız için sizin kanalınıza rakip olma ihtimalimiz yapısal olarak yok.
Müşteriye karşı görünen taraf sizsiniz; istenirse tamamen arka planda kalır, istenirse ekibinizin bir parçası olarak görünürüz
Kontör davranışı proje teslim dosyasında yazılı olarak raporlanır — müşteriye ne kadar çağrı ürettiğinizi açıklayabilirsiniz
Kapsam yazılı, bedel sabit: müşterinize verdiğiniz teklifin arkasında değişken bir geliştirme maliyeti durmaz
Çözüm ortaklığı başvurusu, anahtar talebine aracılık ve ürün danışmanlığı tamamen sizin alanınızdır; o alana girmiyoruz
Yazılan kodun dokümantasyonu ve yapılandırma haritası size teslim edilir; iş birliği sonlansa bile elinizde çalışır bir varlık kalır
Sahada nasıl görünüyor?
Saha satış uygulamasından cari ve sipariş akışı
Sahada açılan cari kart ve alınan sipariş, DİA’ya ilgili ekleme servisleri üzerinden yazılıyor. Yanıtta dönen anahtar kendi kaydımızla eşleştiriliyor; aynı sipariş ağ kesintisi sonrası tekrar gönderilse bile DİA tarafında ikinci kez oluşmuyor.
E-ticaret siparişi ve stok bakiyesi senkronizasyonu
Mağaza siparişleri DİA’ya aktarılıyor, stok bakiyesi filtreli liste çağrılarıyla okunuyor. Yoklama yerine aralıklı ve daraltılmış çekme tasarlandığı için bakiye güncelliği korunurken gereksiz çağrı üretilmiyor.
Üretim kaydının bulut ERP’ye düşmesi
Tezgâh başında kapatılan iş emri, mamul girişi ve sarf olarak DİA’ya yazılıyor. Excel’de toplama adımı tamamen kalkıyor; başarısız kayıtlar kuyrukta bekliyor, bağlantı döndüğünde sırayla işleniyor ve kayıtlar liste çağrısıyla toplu gittiği için kontör tüketimi öngörülebilir kalıyor.
Çok firmalı grupta tek yönetim paneli
Grup içindeki her firma ve dönem için doğru bağlam parametreleriyle çağrı yapılıyor, veriler tek panelde birleşiyor. Firma ve dönem kodu yapılandırmadan geldiği için yeni bir firma açıldığında kod değişikliği gerekmiyor.
Tüketim ve sağlık izleme panosu
Entegrasyonun ürettiği çağrı sayısı, başarısız istekler ve kalan kontör bakiyesi tek ekranda izleniyor. Tasarım hatası aylar sonra fark edilen bir maliyet olarak değil, ilk hafta görünen bir eğri olarak ortaya çıkıyor.
Referans iş birliği
Entegrasyon tarafında yeni bir hat kuruyoruz ve ilk projeleri referans iş birliğiyle yürütüyoruz: projenin sonunda ölçülebilir sonuçları vaka çalışması olarak yayımlamamıza ve sizi referans göstermemize izin veren firmalara özel koşul uyguluyoruz. Karşılığında alacağınız şey standart bir paket değil, süreçlerinize göre yazılmış bir sistem — ve geliştiren ekibe doğrudan erişim.
Sık sorulan sorular
DİA veritabanına doğrudan bağlanabilir misiniz?
Hayır ve bu bir tercih değil, ürünün mimarisinin sonucu. DİA bulutta çalışır; veritabanı sizin makinenizde durmaz, arkada hangi sistemin çalıştığı da üretici tarafından açıklanmaz. Geliştirici dokümantasyonunda tanımlanan tek entegrasyon yolu web servistir ve biz de o yolu kullanırız. Bunu bir kayıp olarak görmüyoruz: şema takibi, tablo tahmini ve yükseltme sonrası eşleme gibi masaüstü dertleri bu sayede gündeme hiç gelmiyor.
Entegrasyon için neye ihtiyacımız var?
Dört şeye: API anahtarı, web servis kullanıcı adı ve şifresi, firma kodu ve dönem kodu. Buna ek olarak ilgili kullanıcıda “Web Servis Çağırabilir” yetkisinin açık olması gerekiyor — bu yetki kapalıyken alınan hata çoğu zaman yanlış yorumlanıp kodda aranıyor. Hesabınızda “İzin Verilen IP’ler” tanımlıysa entegrasyonun çalışacağı sunucunun çıkış adresinin de o listede olması gerekir. API anahtarı, üretici dokümanına göre DİA’dan e-posta ile talep edilir; uygulamada çoğu zaman firmanın mevcut çözüm ortağı bu talebe aracılık eder. Bu adım proje takviminin ilk kalemidir.
Kontör tüketimi entegrasyonu pahalı hale getirir mi?
Tasarıma bağlı — ve bu yüzden DİA projelerinde ilk oturduğumuz masa kod değil, çağrı planı. Her web servis çağrısı 0,0125 kontör tüketiyor; login ve logout gibi bazı işlemler muaf. Sürekli yoklama yapan bir entegrasyon veri hiç değişmese bile tüketim üretir. Bizim kurduğumuz tasarımda çağrı ya gerçek bir olayla tetiklenir ya da belirli aralıkta, tarih ve durum filtresiyle daraltılmış olarak yapılır; tekil çağrılar da liste sonucuna göre sınırlanır. Kalan bakiye sis_kontor_sorgula servisiyle sorgulanabildiği için tüketimi izleme paneline bağlıyoruz. Burada bir bütçe rakamı vermiyoruz çünkü bu tamamen kapsama ve sizin hesabınızdaki koşullara bağlı.
DİA’ya veri yazmak riskli mi?
DİA tarafında yazma resmi olarak destekleniyor; nesneler için ekleme, güncelleme ve silme servisleri tanımlı. Üstelik ekleme ve güncelleme yanıtları kaydın anahtar değerini ve işlem mesajını (msg alanı) geri döndürüyor — yani üretici sadece yazmaya izin vermekle kalmamış, geri bildirimi de standart hale getirmiş. Bizim disiplinimiz şu: dönen anahtarı saklayıp aynı kaydın iki kez oluşmasını engelliyoruz, her yazma işlemini yeniden denenebilir kurguluyoruz ve projeye salt okuma pilotuyla başlıyoruz. Silme tarafında ise çoğu projede entegrasyon kullanıcısına silme yetkisi vermiyoruz; iptal ve düzeltmeyi güncelleme üzerinden kurguluyoruz.
Oturum süresi entegrasyonu etkiler mi?
Evet ve bu, oturum tabanlı web servislerde tipik bir sessiz kopma sebebi. Oturum bir saat işlemsizlikten sonra düşer; her çağrı bu süreyi sıfırlar. Gündüz sürekli çalışan bir akışta sorun çıkmaz, ama gece boyunca hiç çağrı yapmayan bir entegrasyon sabah ilk denemesinde düşmüş bir oturumla karşılaşır. Bu yüzden oturum tazeleme ve yeniden deneme mantığını koda yazıyoruz; ayrıca mevcut oturumu gereksiz yere kapatıp yeniden açmıyoruz.
DİA webhook desteği var mı, yoksa sürekli sorgulamak mı gerekiyor?
DİA tarafında webhook ile başlatılan türde süreç tanımlanabiliyor ve sürece bir geri çağırma adresi ile jeton giriliyor. Ancak bunun genel amaçlı bir nesne webhook’u mu yoksa dar kapsamlı bir süreç tetikleyicisi mi olduğu bizim doğrulayabildiğimiz kaynaklarda net değil; bu yüzden size kesin bir kapsam taahhüdü vermiyoruz, kapsamı projeye göre teyit ediyoruz. Tasarımı iki katmanlı kuruyoruz: tetikleme mümkünse ana yol o oluyor, kapsamadığı durumlar için arkada düşük sıklıkta ve dar filtreli bir mutabakat turu çalışıyor.
DİA çözüm ortağı mısınız?
Hayır. DİA çözüm ortağı listesinde yer almıyoruz; başka hiçbir ERP üreticisiyle de bayilik ya da iş ortaklığı ilişkimiz yok. Bağımsız bir yazılım geliştiricisiyiz. API anahtarı, lisans, kontör bütçesi ve ürün danışmanlığı tarafı sizin kanalınıza ait ve o alana girmiyoruz. Yaptığımız iş, ürünün belgelenmiş web servisi üzerinden entegrasyon geliştirmek. DİA çözüm ortaklarıyla da taşeron geliştirme modelinde çalışıyoruz: müşteri ilişkisi ve anahtar sizde kalır, kod ve bakım bizde olur.
Bulut ürün için yerinde ziyaret gerekir mi? Mersin dışındaysak ne değişir?
DİA bulutta çalıştığı için entegrasyonun kendisi yerinde kurulum gerektirmez; web servis bağlantısı ve geliştirme nerede olursanız olun uzaktan yürür. Yerinde olduğumuz kısım sahadır: Mersin, Tarsus, Adana, Hatay, İskenderun ve Osmaniye’de keşfi ve tezgâh başı ya da depo terminali kurulumunu yerinde yapıyoruz. Türkiye’nin diğer illerinde başlangıç online keşif; saha montajı gerekiyorsa seyahat takvime baştan yazılır, sürpriz kalem olmaz.
Hangi programı kullandığınızı, sahada hangi verinin elle girildiğini ve neyi otomatikleştirmek istediğinizi anlatın. İlk görüşmede teknik olarak mümkün olup olmadığını ve hangi yöntemle yapılacağını netleştiriyoruz.
Bu sayfada adı geçen ürün ve markalar ilgili firmaların tescilli ticari markalarıdır. D'Cloud Software bağımsız bir yazılım geliştiricisidir; anılan firmaların yetkili bayisi, çözüm ortağı veya iş ortağı değildir. Entegrasyon hizmeti, ürünlerin kendi belgelenmiş arayüzleri ve veri erişim yöntemleri üzerinden sunulur.