Mikro’nuz yerinde kalır; sahayı, depoyu ve e-ticareti Mikro’ya Desktop API üzerinden bağlarız. Doğrudan tabloya yazmayız — üretici de serbest SQL ucunu yalnızca SELECT için belgeliyor: okuma esnek, yazma tipli uç noktalara bağlı.
Mikro Yazılım’ın masaüstü ürünleri (Run, Jump, Fly ve Müşavir) MS SQL Server üzerinde çalışır; tablo adları düz ve Türkçedir, firma veya dönem öneki içermez.
Üreticinin resmi ve önerilen entegrasyon yolu Mikro Desktop API’dir — Windows servisi olarak çalışan, JSON tabanlı bir REST arayüzü.
Kimlik doğrulama her istekte gövdede taşınır: ApiKey, çalışma yılı, firma kodu, kullanıcı kodu ve şifrenin tarih önekli MD5’i (gün dönümünde önceki günle yeniden deneme gerekebilir). V2/V3 uç noktalarında oturum jetonu yoktur; V1 metotları ise APILogin ile oturum açar.
Bu yüzden çok firmalı yapıda değişen şey bağlantı dizesi değil, isteğin kendisidir; entegrasyon katmanı bunu istek başına üretmelidir.
Üretici API içindeki serbest SQL ucunu (SqlVeriOkuV2) yalnızca SELECT için belgeliyor; yazma ise tipli uç noktalara bağlı.
API kullanımı API Key gerektirir ve başvuruya tabidir; uç noktalar V1, V2, V3 sonekiyle sürümlenir, sürüm geçişlerinde port bile değişebilir.
Run, Jump, Fly ve Jump Bulut — hangisi sizdeyse mimari ona göre kurulur
Mikro tarafında “Mikro kullanıyoruz” cümlesi tek başına yeterli değil; hangi ürün, hangi sürüm ve hangi kurulum biçimi olduğunu bilmeden entegrasyonun mimarisini çizemiyoruz. Üreticinin kendi API başvuru formunda Run, Jump, Fly ve Müşavir ürünleri birlikte anılıyor; bunların yanında tarayıcı üzerinden çalışan Mikro Jump Bulut sürümü de var.
Jump Bulut’un ayrı bir başlık olmasının sebebi şu: bulut sürüm için üretici ayrı bir Postman koleksiyonu yayımlıyor. Yani masaüstü kurulumda kullandığınız çağrı kümesiyle bulut tarafındaki yüzey birebir aynı değil. Bir müşteri masaüstünden buluta geçmeyi planlıyorsa, bunu entegrasyon tasarımının başında bilmek gerekiyor — sonradan öğrenmek yeniden yazım demek.
Jump Bulut tarafında verilerin Türkiye’deki bir veri merkezinde tutulduğu belirtiliyor. Veri konumu, KVKK tarafında soru soran firmalar için ilk gündem maddesi oluyor; bu konuda bağlayıcı bilgi üreticinin ve yetkili bayinizin sözleşme metnidir.
Keşifte istediğimiz bilgi kısa: ürün adı, sürüm numarası (V16 mı V17 mi), masaüstü mü bulut mu, kaç firma ve kaç çalışma yılı aktif. Bu dört satır entegrasyonun mimarisini büyük ölçüde belirliyor.
Veri modeli: Türkçe tablo adları, kolon bazlı firma ayrımı
Mikro’nun veritabanı MS SQL Server üzerinde çalışır ve tablo adları — Logo tarafındaki önek mantığının aksine — düz, büyük harfli ve Türkçedir: STOKLAR, CARI_HESAPLAR, STOK_HAREKETLERI, MUHASEBE_HESAP_PLANI, MUHASEBE_FISLERI, PERSONELLER, FIRMALAR, SUBELER. Tablo adının içinde firma veya dönem bilgisi taşınmaz.
Alan adları ise tabloya göre önek alır: STOKLAR tarafında sto_, STOK_HAREKETLERI tarafında sth_, CARI_HESAPLAR tarafında cari_, fiş yapılarında fis_ gibi. Bu düzen sorgu yazarken okunabilirliği artırıyor; resmi V16 veritabanı dokümanında iki yüz seksenin üzerinde tablo listelendiği düşünülürse bu küçük bir kolaylık değil.
Firma ve şube ayrımı kolon bazlıdır — örneğin stok hareket tarafında sth_firmano ve sth_subeno alanları. Tablo adı dönemle değişmez; ancak çalışma yılı devir sırasında ayrı bir veritabanına taşınmış olabilir — Desktop API’de çalışma yılının (CalismaYili) istek başına verilmesinin sebebi budur. Buradan çıkan pratik sonuç şu: Mikro’da yanlış firmanın verisini okumak için özel bir hata yapmanız gerekmez, sadece filtreyi yazmamanız yeterlidir.
Mikro veri modelinde entegrasyonu doğrudan etkileyen dört başlık. Sürüm ve kurulum farkları proje başında müşteri veritabanında teyit edilir.
Konu
Mikro’daki karşılığı
Entegrasyona etkisi
Tablo adlandırma
Düz Türkçe ve büyük harfli (STOKLAR, CARI_HESAPLAR, STOK_HAREKETLERI)
Tablo adı dinamik üretilmez; sorgular sabit adlarla yazılır
Alan adlandırma
Tabloya göre önek: sto_, sth_, cari_, fis_
Birden çok tablo birleştirildiğinde alan karışıklığı azalır
Firma / şube ayrımı
Kolon bazlı (örn. sth_firmano, sth_subeno)
Filtre unutulursa sorgu hata vermez, yanlış toplam üretir
Dönem / çalışma yılı
Tablo adı dönemle değişmez; çalışma yılı devirde ayrı bir veritabanına taşınmış olabilir
Desktop API isteğinde CalismaYili her seferinde verilir; hedef yıl yapılandırmadan okunur
Mikro’nun yazılı olmayan iki kuralı — bunları bilmeyen entegrasyon rapor bozar
Bu bölüm, “neden bu işi bilen biri yapsın” sorusunun en somut cevabı. Mikro’da veriyi okuyup yazmak sadece doğru tabloyu bulmakla bitmiyor; ürünün kendi veri disiplinine uymak gerekiyor. Uymayan entegrasyon hata vermez — rapor bozar. Fark edilmesi de aylar alır.
Tarih alanlarına saat bilgisi yazmayın
Mikro tarafında DateTime alanları, aksi açıkça belirtilmedikçe saat bilgisi içermemelidir. Dışarıdan gelen bir entegrasyonun tarih alanına GETDATE() benzeri bir değer yazması ilk bakışta zararsız görünür; kayıt oluşur, hiçbir hata dönmez.
Sorun raporlarda ortaya çıkar. Gün bazlı gruplayan, tarih aralığı karşılaştıran veya dönem sonu alan raporlar, saat taşıyan kayıtları beklendiği gibi toplamaz. Muhasebe ekibi raporun yanlış olduğunu görür, sebebini bulamaz ve sonunda entegrasyona değil kendi verisine güvenmemeye başlar.
Bu kural, Mikro’ya yazan bir veri erişim katmanına ilk eklenmesi gereken kontrollerden biridir: tarih alanına yazılan her değer gün hassasiyetine indirgenir, istisna varsa açıkça tanımlanır.
Kolon değerleri koddur, metin değil
Mikro’da pek çok kolon anlamlı metin değil kod tutar. Stok cinsi, döviz sembolü, cari hareket tipi gibi alanlar ham hâlleriyle okunduğunda hiçbir şey ifade etmez — daha kötüsü, yanlış yorumlanmaya çok müsaittir.
Üretici bu değerleri çözmek için skaler fonksiyonlar sunuyor: örneğin dbo.fn_StokCins(), dbo.fn_DovizSembolu(), dbo.fn_CariHareketTip(). Doğru yaklaşım, kod eşleşmelerini kendi tarafımızda tahmin ederek tablolamak değil, ürünün kendi çözümleme fonksiyonlarını kullanmaktır. Tahminle yazılan eşleşme tablosu, üretici yeni bir kod eklediği gün sessizce eksik çalışmaya başlar.
Mikro Desktop API: resmi ve tek önerilen yol
Mikro tarafında entegrasyonun resmi yolu Mikro Desktop API’dir. JSON ile çalışır, GET, POST, DELETE ve PATCH metotlarını kullanır ve makinede bir Windows servisi olarak koşar — servis adı Mikro Desktop API’dir. Bu, entegrasyonu kuracak taraf için önemli bir ayrıntı: API’nin çalışması bir uygulamanın açık olmasına değil, servisin ayakta olmasına bağlıdır.
Servisin dinlediği port sürüme göre değişir. V17 kurulumlarında 8094, V16 kurulumlarında 8084 kullanılır. Port kayıt defteri üzerinden değiştirilebilir; değişiklik sonrasında servisin yeniden başlatılması ve güvenlik duvarında ilgili izin tanımının yapılması gerekir.
Kimlik doğrulama tarafında Mikro alışılmışın dışında bir yol izliyor. V2/V3 uç noktalarında kimlik bilgisi bir kez alınıp saklanan bir oturum jetonu değil; her istekte gövdenin içinde taşınıyor: ApiKey, çalışma yılı, firma kodu, kullanıcı kodu ve şifrenin tarih önekli MD5’i (gün dönümünde önceki günle yeniden deneme gerekebilir). V1 metotları ise APILogin ile oturum açar. Bunun mimari sonucu şu: çok firmalı ya da çok dönemli bir yapıda bağlantı dizesini değil, isteğin gövdesini değiştirirsiniz. Entegrasyon katmanı bu bilgiyi istek başına üretmek üzere tasarlanmalıdır; “kurulumda tek firma var” varsayımıyla yazılan kod, ikinci firma açıldığında baştan elden geçirilir.
Uç noktalar iş nesnesi bazında tiplidir. Cari tarafında CariKaydetV2, CariGuncelleV2, CariListesiV2 ve CariListesiV3 gibi çağrılar bulunur ve bunlar POST ile çalışır. e-Dönüşüm tarafı da API içindedir: mükellef sorgulama (EMukellefSorgulamaV2) ve fatura PDF alma (FaturaPdfV2, GelenFaturaPdfV2) gibi uçlar mevcuttur.
Mikro Desktop API — entegrasyon tasarımını doğrudan etkileyen teknik başlıklar.
Başlık
Durum
Projeye etkisi
Çalışma biçimi
Windows servisi (servis adı: Mikro Desktop API)
Uygulama açık olmasa da çalışır; servis izlenmelidir
Varsayılan port
V17 → 8094, V16 → 8084
Port koda sabit yazılmaz; yapılandırmadan okunur
Port değişikliği
Kayıt defterinden yapılır, servis yeniden başlatılır
Güvenlik duvarı izni ayrıca tanımlanır
Kimlik doğrulama
V2/V3: her istekte gövdede ApiKey, çalışma yılı, firma kodu, kullanıcı kodu, tarih önekli MD5 şifre; V1: APILogin ile oturum
Çok firmalı yapıda istek gövdesi değişir, bağlantı dizesi değil
Serbest SQL ucu
SqlVeriOkuV2 — üretici yalnızca SELECT için belgeliyor
Okuma esnek, yazma tipli uç noktalara bağlı
Bulut sürüm
Jump Bulut için ayrı Postman koleksiyonu
Masaüstü ve bulut yüzeyi birebir aynı varsayılmaz
Okuma ve yazma farkını burada üretici kendisi çizmiş
Diğer ürünlerde “neden doğrudan veritabanına yazmıyorsunuz” sorusunu mühendislik gerekçeleriyle açıklamak zorunda kalıyoruz. Mikro tarafında bu tartışmayı üretici zaten bitirmiş durumda.
API içinde SqlVeriOkuV2 adında bir uç nokta var ve bu uca serbest SQL gönderilebiliyor. Üretici bu ucu yalnızca SELECT için belgeliyor; yazma ise tipli uç noktalara — CariKaydetV2 benzeri çağrılara — bağlı. Yani üretici okumayı esnek bırakmış, yazmayı kendi çağrılarına yönlendirmiş.
Bu, entegrasyon tasarımı için hazır bir yol haritası. Rapor, panel, karşılaştırma ve analiz gibi okuma ağırlıklı işlerde esnek davranabiliriz: ihtiyaç duyulan sorgu yazılır, veri alınır, hiçbir kayıt değişmez. Kayıt oluşturma ve güncelleme tarafında ise ürünün kendi çağrılarını kullanırız; böylece Mikro’nun kendi doğrulamaları devreye girer ve hatalı kayıt en baştan reddedilir.
Pratikte bunun anlamı şu: bir müşteri “doğrudan yazalım, daha hızlı olur” dediğinde verdiğimiz cevap bir tercih beyanı değil, ürünün tasarım kararına uyum. Üretici yazmayı tipli uçlara bağlamışsa, o sınırın dışına çıkan entegrasyon desteklenen bir kullanım biçimi olmaktan çıkar.
Sürüm yükseltildiğinde ne oluyor? Mikro’da bu soru özellikle önemli
Mikro entegrasyonlarında sürüm riski, diğer ürünlere göre daha somut ve daha ölçülebilir; çünkü API’nin kendisi açıkça sürümleniyor. Uç noktalar V1, V2, V3 sonekleriyle yaşıyor. Eski sürümdeki bir uca bağlı kalan entegrasyon, yeni sürümle gelen alanları hiç görmez — ve bunu size kimse haber vermez.
İkinci ve daha sert konu şu: değişiklik kayıtlarında “breaking change” gibi bir etiket kullanılmıyor. Yani kırıcı bir değişiklik ayrıca ilan edilmiyor; sürüm notunun içinde diğer maddelerle aynı görünürlükte duruyor. Somut bir örnek: v17.05e sürümünde hizmet, stok ve masraf kalemlerinin aynı JSON yapısında gönderilmesine geçildi. Bu tür bir değişiklik, istek gövdesini eski yapıya göre kuran bir entegrasyonu doğrudan etkiler.
Üçüncüsü, büyük sürüm geçişinde servisin dinlediği port değişiyor: V16’da 8084, V17’de 8094. Portu koda sabit yazmış bir entegrasyon, yükseltmenin ertesi günü bağlantı kuramaz. Entegrasyon projelerinin klasik hatası budur — ve en kolay önlenebilir olanı.
Buna karşı üç şey yapıyoruz. Port, uç nokta sürümü ve kimlik bilgileri gibi değişmeye açık her şeyi yapılandırma katmanına alıyoruz — koda gömmüyoruz. Kullandığımız uçların sürüm notlarını takip ediyoruz. Ve her yükseltme öncesinde test ortamında bir regresyon turu çalıştırıyoruz; kırıcı değişiklik ilan edilmiyorsa, onu bizim yakalamamız gerekir.
Garanti kapsamımız net: teslim sonrası 15 gün ücretsiz hata düzeltme. Sürüm notlarını izlemek ve her yükseltme öncesi regresyon turu çalıştırmak ise sürekli bir iş; onu sözleşmede ayrı bir bakım kalemi olarak yazıyoruz.
API Key, başvuru ve API yüzeyinin sınırları
Mikro Desktop API’yi kullanabilmek için bir API Key gerekiyor ve bu anahtar başvuruyla alınıyor: üreticinin API Başvuru Formu doldurulur ve API Kullanıcı Sözleşmesi onaylanır. Yani entegrasyonun teknik tarafı kadar idari tarafı da var ve bunun projenin takvimine etkisi oluyor.
Daha önemli bir ayrıntı şu: API’de olmayan bir tablo ya da alan ihtiyacı doğarsa, bu talep de aynı form üzerinden üreticiye iletiliyor. Buradan çıkan sonucu keşif görüşmesinde açıkça söylüyoruz — Mikro’da API yüzeyi sabit ve sınırsız bir alan değil, üreticinin onayına tabi bir kapsam.
Bu, projeyi planlarken sırayı değiştiriyor. İhtiyaç duyulan verinin API üzerinden erişilebilir olup olmadığını, geliştirmeye başlamadan önce doğruluyoruz. Erişilemeyen bir alan varsa iki yol kalıyor: ya okuma tarafına taşınabilecek bir ihtiyaçsa SELECT ile çözülür, ya da talep üreticiye iletilir ve takvim buna göre kurulur. Ne yaptığımız belli olmadan tarih vermiyoruz.
Mikro bayileri ve iş ortakları için taşeron geliştirme
Mikro satan, kuran ve destekleyen bir firmaysanız bu sayfanın sizi ilgilendiren kısmı burası. Müşterinin standart ürünün dışına taşan bir isteği olduğunda, işin teknik tarafını üstlenecek bir ekip arıyorsanız masada oturabileceğimiz bir yer var.
Rolleri baştan ayırıyoruz: ürün, lisans, kurulum, eğitim ve müşteri ilişkisi tamamen sizde kalır. Bizim üstlendiğimiz şey API üzerinden yazılacak entegrasyon kodu ve onun bakımı. Hangi uç noktanın kullanılacağına, hangi verinin aktarılacağına ve müşteriye ne söyleneceğine siz karar verirsiniz.
Geliştirme kapasitesini proje bazında kiralarsınız; sabit bir ekip maliyeti taşımazsınız
İsterseniz doğrudan sizin ekibinizin bir parçası olarak görünürüz, isterseniz tamamen arka planda kalırız
API Key ve başvuru süreci müşterinin hesabında yürür — biz süreci teknik olarak destekleriz, sizin yerinize taahhüt vermeyiz
Yazılan kodun dokümantasyonu size teslim edilir; ilişkiyi sonlandırsanız bile elinizde çalışır bir varlık kalır
Sahada nasıl görünüyor?
Üretim sarf ve mamul girişi Mikro’ya akıyor
Saha terminalinden kapatılan iş emri, mamul girişi ve hammadde sarfı olarak Mikro’ya API üzerinden düşüyor. Akşam Excel’den toplu giriş yerine kayıt anında tipli uç noktadan geçiyor; tarih alanları gün hassasiyetinde yazıldığı için dönem raporları bozulmuyor.
Cari kart ve bakiye senkronizasyonu
Saha satış uygulamasında açılan cari, CariKaydetV2 benzeri tipli uç noktalar üzerinden Mikro’ya aktarılıyor; bakiye sorgusu ise okuma tarafından alınıyor. Aynı cari iki yerde iki farklı kodla açılmıyor.
E-ticaret siparişi ve stok bakiyesi
Web sitesi ve pazaryeri siparişleri Mikro’ya aktarılıyor, stok bakiyesi Mikro’dan salt okunur alınıyor. Kod değerleri ürünün kendi çözümleme fonksiyonlarıyla okunduğu için birim ve cins bilgisi vitrinde yanlış görünmüyor.
Çok firmalı grup şirketinde tek panel
Aynı grupta birden fazla firma ve çalışma yılı varsa, istek gövdesi firma ve yıl bazında üretiliyor. Yönetim paneli tüm firmaları tek ekranda gösteriyor; firma filtresi veri erişim katmanında kural olarak sabitlendiği için rapor sessizce yanlış toplam üretmiyor.
e-Dönüşüm tarafında mükellef kontrolü
Sipariş veya cari açılışı sırasında mükellef durumu API üzerinden sorgulanıyor, fatura PDF’leri gerektiğinde çekiliyor. Satış ekibi e-fatura mı e-arşiv mi sorusunu telefonla teyit etmeyi bırakı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
Mikro’yu değiştirmemiz gerekiyor mu?
Hayır ve bu çalışmanın mantığı zaten Mikro’nun yerinde kalmasına dayanıyor. Muhasebe verinize, çalışma yılı kurgunuza ve mali müşavirinizin alışkanlığına dokunmuyoruz. Entegrasyon katmanı Mikro ile kendi resmi arayüzü üzerinden konuşur; onun yerine geçmez.
Mikro bayisi misiniz?
Değiliz. Mikro Yazılım’la ya da başka bir ERP üreticisiyle bayilik, çözüm ortaklığı veya iş ortaklığı ilişkimiz yok — bağımsız bir geliştirme ekibiyiz. Lisans, kurulum, eğitim ve ürün danışmanlığı yetkili bayinizin alanı ve o alana girmiyoruz. Yaptığımız iş, ürünün belgelenmiş API’si üzerinden entegrasyon geliştirmek — bayilerle birlikte, taşeron geliştirme modelinde de çalışıyoruz.
Doğrudan Mikro veritabanına yazabilir misiniz?
Yazmıyoruz ve bunun gerekçesini bizim uydurmamıza gerek yok: üretici bu sınırı kendi belgesinde çizmiş. API içindeki serbest SQL ucunu yalnızca SELECT için belgeliyor. Kayıt oluşturma ve güncelleme işlemleri tipli uç noktalara bağlanmış durumda. Biz de bu tasarıma uyuyoruz: okuma tarafında esnek çalışıyoruz, yazma tarafında ürünün kendi çağrılarını kullanıyoruz. Böylece Mikro’nun kendi doğrulamaları devrede kalıyor.
API kullanmak için ayrıca bir izin veya anahtar gerekiyor mu?
Evet. Mikro Desktop API kullanımı bir API Key gerektiriyor; anahtar, üreticinin API Başvuru Formu doldurulup API Kullanıcı Sözleşmesi onaylandıktan sonra veriliyor. Ayrıca API’de bulunmayan bir tablo veya alan ihtiyacı doğarsa, bu talep de aynı form üzerinden üreticiye iletiliyor. Yani API yüzeyi sabit bir alan değil, üreticinin onayına tabi bir kapsam. Bu süreci projenin ilk adımına koyuyoruz; anahtar ve kapsam netleşmeden geliştirmeye başlamıyoruz.
V16’dan V17’ye geçersek entegrasyon çalışmaya devam eder mi?
Doğru kurulmuşsa eder, ama bu kendiliğinden olmaz. Büyük sürüm geçişinde servisin dinlediği port değişiyor — V16’da 8084, V17’de 8094. Portu koda sabit yazmış bir entegrasyon geçişin ertesi günü bağlantı kuramaz. Ayrıca uç noktalar V1, V2, V3 şeklinde sürümlendiği için eski uca bağlı kalan bir entegrasyon yeni alanları göremez. Bu yüzden port, uç nokta sürümü ve kimlik bilgilerini yapılandırma katmanında tutuyor, yükseltme öncesinde test ortamında regresyon turu çalıştırıyoruz.
Raporlarımızdaki rakamlar neden entegrasyondan sonra tutmamaya başladı?
Bu şikâyetin arkasında çoğu zaman iki sebepten biri çıkıyor. Birincisi tarih alanlarına saat bilgisi yazılmış olması: Mikro’da DateTime alanları aksi belirtilmedikçe saat taşımamalıdır, dışarıdan GETDATE() benzeri bir değer yazan entegrasyon gün bazlı raporları bozar ve hiçbir hata mesajı vermez. İkincisi kod değerlerinin metin sanılması: stok cinsi, döviz sembolü ve cari hareket tipi gibi alanlar kod tutar ve ürünün kendi çözümleme fonksiyonlarıyla okunmalıdır. Mevcut bir entegrasyonda bu iki noktayı kontrol etmek genelde sorunu ortaya çıkarmaya yetiyor.
Mikro Jump Bulut kullanıyoruz. Aynı şekilde mi çalışıyor?
Mantık benzer ama yüzey aynı varsayılmamalı. Jump Bulut tarayıcı üzerinden çalışan bulut sürümdür ve üretici bunun için ayrı bir Postman koleksiyonu yayımlıyor; yani çağrı kümesi masaüstü kurulumla birebir örtüşmeyebilir. Bulut tarafında doğrudan veritabanı erişimi gündemde olmadığı için entegrasyon tamamen API üzerinden kurulur. Masaüstünden buluta geçiş planınız varsa bunu keşif aşamasında söyleyin; tasarımı baştan ona göre kurmak, sonradan yeniden yazmaktan çok daha ucuz.
Adana’dayız; sadece uzaktan mı çalışırsınız?
Hayır, Adana yerinde çalıştığımız hattın içinde. Mersin, Tarsus, Adana, Hatay, İskenderun ve Osmaniye’de keşfi ve saha kurulumunu yerinde yapıyoruz. Mikro Desktop API bağlantısı ve geliştirme işi ise nerede olursanız olun uzaktan ilerliyor; Türkiye genelinde ilk adım online keşif görüşmesi. Saha terminali ya da depo kurulumu gerekiyorsa o iş için yerinde ziyaret takvime ayrı satır olarak yazılır.
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.