Yazılım Projesinde Müşteri Veri ve Erişim Vermiyorsa Gecikme Kime Aittir?

Özel yazılım projesinin müşteriden gelecek veriye, sisteme erişime veya belirli bir onaya bağlı olması, gecikme sorumluluğunun yalnız teslim tarihine bakılarak belirlenmesini engeller. Hangi hazırlık işlemini kimin, ne zaman yapması gerektiği ve eksikliğin hangi çalışmayı durdurduğu somut olarak gösterilmelidir. “Müşteriyi bekledik” ifadesi, bütün proje gecikmesini açıklayan bir delil değildir.

TBK m. 106, gereği gibi önerilen edimin kabul edilmemesinin yanında borçlunun ifası için alacaklı tarafından yapılması gereken hazırlık fiillerinden haklı sebep olmaksızın kaçınılmasını da düzenler. Yazılım projesinde bu hüküm, sözleşmedeki işbirliği düzeni ve yüklenicinin bildirim borcuyla birlikte uygulanır. Veri eksikliği, ücret, süre uzatımı ve sözleşmeyi sona erdirme bakımından aynı sonucu otomatik olarak doğurmaz.

Müşterinin sağlaması gereken hazırlık fiili nasıl belirlenir?

Projenin iş planında veri sözlüğü, mevcut sistem dokümantasyonu, test ortamı, bağlantı izni, örnek veri ve karar verecek yetkili kişi ayrı kalemler hâlinde bulunmalıdır. Müşterinin her teknik ihtiyacı karşılamakla yükümlü olduğu varsayılmaz. Önce yüklenicinin hangi araçları kendisinin sağlayacağı, hangi girdilerin müşterinin hâkimiyetinde bulunduğu ve bunların sözleşmede nasıl paylaştırıldığı belirlenir. Yalnız geliştiricinin tercih ettiği yöntemin daha kolay olması, karşı tarafa yeni bir hazırlık borcu yüklemez.

TBK m. 106, ifa için alacaklının yapması gereken hazırlık fiillerinden haklı sebep olmaksızın kaçınmayı kapsar. İşin gerçekten bu girdiye bağlı olması gerekir. Veri biçimi daha başta kararlaştırılmamışsa tarafların açıklamaları, teknik gereklilik ve sözleşmenin amacı birlikte incelenir. Yüklenici sonradan ilk kapsamı aşan bir veri hazırlama işini tek taraflı müşteriye yükleyip gecikmenin tamamını buna bağlayamaz.

Yüklenici çalışmaya hazır olduğunu nasıl göstermelidir?

Alacaklı temerrüdü incelemesinde yüklenicinin kendi edimini gereği gibi sunma veya ilerletme durumu önemlidir. Henüz gerekli yazılım bileşenini geliştirmemiş kişinin, ileride lazım olacak bir erişim kodunu bahane ederek mevcut gecikmesini müşteriye aktarması yeterli değildir. Eksik girdinin hangi hazır faaliyeti engellediği gösterilmelidir. Plan, tamamlanan işler ve sıradaki çalışmanın teknik koşulları birbirini doğrulamalıdır.

Eksik veri talebi; istenen alanları, biçimi, teslim kanalını, kullanım amacını ve uygun süreyi içermelidir. “Bütün bilgileri gönderin” şeklindeki belirsiz talep, muhatabın ne yapması gerektiğini açıklamaz. Yüklenici alternatif bir test verisiyle ilerleyebiliyorsa bunun sınırları da kayıt altına alınır. Alacaklının temerrüdü hakkındaki genel kurallar bu şartların yerini tutmaz; yazılım dosyasında ifa hazırlığı somut teknik kayıtlarla gösterilmelidir.

Müşteri erişim vermemekte haklı olabilir mi?

TBK m. 106’da haklı sebep bulunmaması açık bir koşuldur. Müşteriden sözleşmeyle ilgisiz bütün sistemlere sınırsız erişim istenmesi, henüz belirlenmemiş kişilere yönetici hesabı açılması veya kararlaştırılan güvenlik tedbirlerinin sağlanmaması ayrıca değerlendirilir. Müşteri, talebin kapsamını ve hangi şartın eksik olduğunu somut olarak açıklamalıdır. Sadece “güvenlik politikamız izin vermiyor” demek, önceden üstlenilmiş işbirliği düzenini kendiliğinden ortadan kaldırmaz.

Taraflar ihtiyaca uygun erişim seviyesini, işlem kaydını, süreyi ve erişimin sona erdirilmesini belirleyebilir. Gerçek üretim verisi zorunlu değilse ayrıştırılmış test verisi veya kontrollü test ortamı değerlendirilir. Bunların her projede aynı biçimde kurulması gerektiği ileri sürülemez; sözleşme ve işin gerçek gereği esas alınır. Hukuka aykırı veri aktarımı veya yetkisiz sistem erişimi yapılması, gecikmeden kaçınma amacıyla meşrulaştırılamaz.

Gecikme tehlikesi ortaya çıkınca yüklenici bekleyebilir mi?

Belirli bir eser sonucunun üstlenildiği projede TBK m. 472, eserin gereği gibi veya zamanında meydana getirilmesini tehlikeye düşüren durumun hemen işsahibine bildirilmesini öngörür. Bildirmeyen yüklenici bundan doğacak sonuçlardan sorumlu olur. Bu hüküm, müşterinin geciken girdisi öğrenildiği hâlde projenin son gününe kadar sessiz kalıp sonradan bütün gecikmeyi karşı tarafa yüklemeyi önler.

Bildirimde eksik unsur, talep tarihi, yapılması gereken işlem, etkilenen faaliyet ve gecikme etkisi açıklanmalıdır. Müşterinin gerçekleştirebileceği somut adım belirtilmeden yalnız “proje risk altındadır” demek yeterli açıklık sağlamaz. Plan henüz bütün etkileri göstermiyorsa bilinen engel hemen bildirilmeli, ayrıntılı güncelleme sonra sunulmalıdır. Bildirimin hangi tarihte karşı tarafa ulaştığı, sözleşmedeki proje kanalı ve hukuki ihtar düzeni birlikte saklanır.

Veri on gün geç geldiyse teslim de otomatik on gün mü uzar?

Geciken girdinin süresi ile projenin tamamlanmasına etkisi aynı sayı olmak zorunda değildir. Aynı dönemde başka işler yürütülmüşse gecikmenin bir bölümü plan içinde karşılanmış olabilir. Buna karşılık bağımlı ekiplerin yeniden planlanması veya test sırasının kayması gerçek ve belgelenmiş ilave etki doğurabilir. Hesap, sözleşmenin süre uzatımı hükmü ve teknik iş programı üzerinden kurulmalıdır; her durumda otomatik gün ekleme kuralı yoktur.

Zaman çizelgesi başlangıç tarihi, müşteriden istenen girdi, beklenen teslim, fiili teslim, çalışmanın başlayabildiği tarih ve nihai etkiden oluşmalıdır. Aynı günlerde yüklenicinin kendi hazırlığının tamamlanmadığı süre ayrıca işaretlenir. İki farklı gecikmenin çakışması, bütün günlerin iki kez sayılmasına yol açmamalıdır. Bağımlılıkların gösterilmesi, yalnız çizelgedeki tarihleri değiştirmekten daha önemlidir; hangi işin neden beklediği açıklanmalıdır.

Her iki tarafın gecikmesi varsa sorumluluk nasıl ayrılır?

Müşterinin veri teslimini geciktirmesi, yüklenicinin daha önceki veya bağımsız gecikmelerini ortadan kaldırmaz. Veri beklenmeden geliştirilebilen modüllerin yapılmaması ayrıca incelenir. Aynı şekilde yüklenicide başka eksikler bulunması da müşterinin gerçekten engellediği işleri yok saydırmaz. Uyuşmazlık, taraflardan birinin tamamen kusursuz olduğu varsayımına dayanmadan faaliyet bazında çözülmelidir.

TBK m. 112 kapsamındaki tazminat incelemesinde borca aykırılık, zarar ve nedensellik değerlendirilir; borçlu kendisine kusur yüklenemeyeceğini ispat etmedikçe sorumludur. TBK m. 114’ün yollamasıyla m. 52’deki zarar görenin katkısı da dikkate alınır. Bunun için müşterinin hangi davranışının zararın doğmasına veya artmasına etkili olduğu gösterilmelidir. “İki taraf da gecikti” demek, zararı kanunda bulunmayan sabit bir oranla paylaşmaya yeterli değildir.

Bekleyen ekip ve lisans gideri müşteriden istenir mi?

Alacaklı temerrüdü ile tazminat borcu aynı koşullara sahip değildir. TBK m. 106 kapsamında hazırlık fiilinin yapılmaması için ayrıca bir tazminat taahhüdü bulunması gerekmez; fakat bundan her bekleme giderinin otomatik tahsil edileceği sonucu çıkmaz. İşbirliği davranışının ayrıca sözleşmesel borç olarak üstlenilip üstlenilmediği, gider maddesi ve tazminatın kanuni koşulları ayrı incelenir. Yüklenici talebinin dayanağını açıkça göstermelidir.

Bekleyen personelin hangi günlerde projeye tahsis edildiği, başka işe yönlendirilip yönlendirilemediği ve gerçekten ek maliyet oluşup oluşmadığı kayıtlarla açıklanır. Zaten ödenecek bütün personel ücretini ek zarar saymak yeterli değildir. Uzatılan test ortamı, üçüncü taraf erişim lisansı veya yeniden planlanan uzman çalışması için ödeme belgesi ve proje bağlantısı gerekir. Sözleşmede günlük bekleme bedeli varsa bu kaydın şartları ve hukuki niteliği ayrıca değerlendirilir; mahkemece otomatik uygulanacağı söylenemez.

Yüklenici bütün çalışmayı durdurabilir mi?

Eksik girdinin belirli bir faaliyeti durdurması ile sözleşmenin bütününü askıya almak farklıdır. Yüklenici önce hangi işlerin teknik olarak yapılamadığını ve hangi bağımsız işlerin devam edebildiğini ortaya koymalıdır. Sözleşmede geçerli bir askıya alma düzeni varsa bildirim ve süre şartları izlenir. Bu düzen yoksa bütün hizmetlerin durdurulmasının hukuki dayanağı ayrıca gösterilmelidir. Eski sistemin işletilmesi veya güvenlik desteği ayrı borç olarak sürüyorsa onlar da değerlendirilir.

TBK m. 97, karşılıklı borç yükleyen sözleşmede ifa isteyenin, daha sonra ifa hakkı yoksa kendi borcunu ifa etmiş veya önermiş olmasını arar. Bu hüküm her proje içi hazırlık eksikliğinde sınırsız hizmet kesme yetkisi vermez. Karşılıklı edimler, ifa sırası ve ileri sürülen savunmanın ilgili borca uygulanması incelenir. Müşteri verisine erişimi engellemek veya kayıtları silmek, çalışma takvimini askıya almaktan ayrı sonuçlar doğurur.

Müşteri testi yapmıyorsa yazılım kabul edilmiş sayılır mı?

Test için gereken ortamın müşteriye sunulup sunulmadığı ve teslim edilen sürümün incelenebilir olup olmadığı önce belirlenir. Teste hazır olmayan bir çıktının “onay bekleniyor” durumuna geçirilmesi, müşteriyi kendiliğinden temerrüde düşürmez. Müşterinin hangi senaryoları uygulayacağı, erişimin açıldığı tarih ve sonuç bildirme düzeni anlaşılır olmalıdır. İnceleme olanağı ile takvimde yazan sembolik teslim tarihi birbirinden ayrılır.

Teslim ve ayıp rejimi yönünden TBK m. 474 ve m. 477 ayrıca önem taşır. Yazılım kabul testi ve ayıp bildirimi yazısında açıklanan bu kurallar, her teknik sessizliğin sınırsız kabul sayılması anlamına gelmez. Sözleşmedeki kabul düzeni, kanuni gözden geçirme ve bildirim yükümlülükleri ile somut teslim birlikte değerlendirilir. Verinin geç verilmesi ayrı; tamamlanmış eserin incelenmemesi ayrı olgudur.

Veri gönderildiği hâlde kullanılamıyorsa ne yapılır?

Müşteri bir dosya gönderdiğinde teslimin gerçekleştiğini, geliştirici ise dosyanın kullanılamadığını ileri sürebilir. Bu durumda eksik alanlar, bozuk kodlama, uyumsuz tarih biçimi, mükerrer kayıt veya yanlış ilişki anahtarı teknik olarak belirtilmelidir. Dosyanın yalnız “uygunsuz” diye reddedilmesi yeterli açıklık sağlamaz. İlk sözleşmede veri temizleme ve dönüştürme işini kimin üstlendiği belirlenmeden bütün sorun müşteriye yüklenemez.

Kontrol raporu, kullanılan doğrulama kuralını ve başarısız kayıtları gösterebilir; fakat gereksiz kişisel veriler rapora açık biçimde taşınmamalıdır. Yeni veri gönderildiğinde önceki dosyayla sürüm ilişkisi korunur. Sonradan genişletilen alan listesi ile baştan istenmiş ama eksik verilmiş alanlar ayrı tutulmalıdır. Aksi hâlde yüklenicinin yeni talebi, müşterinin eski borcunu geç yerine getirmesi gibi görünür ve takvim hesabı yanlış kurulur.

İşbirliği sağlanmıyorsa sözleşmeden nasıl çıkılır?

TBK m. 110, borcun konusu bir şeyin teslimini gerektirmiyorsa alacaklı temerrüdünde borçlunun, borçlunun temerrüdüne ilişkin hükümlere göre sözleşmeden dönebileceğini düzenler. Yazılım ilişkisinin niteliği ve ilgili edim belirlenmeden bu hüküm doğrudan bütün sözleşmeye uygulanmaz. Yapma edimi bakımından bu yola dayanılacaksa TBK m. 123–125’teki uygun süre, süre gerektirmeyen hâller ve seçimlik hak düzeni birlikte değerlendirilir.

Süre verilmesini gerektirmeyen TBK m. 124 hâlleri bulunmadığında, eksikliğin giderilmesi için uygun ve ifaya elverişli süre tanınması önemlidir. Bildirimde hangi hazırlık fiilinin beklendiği ve yerine getirilmemesinin sonucu açık olmalıdır. Tacirler arasında temerrüt, fesih ve dönme ihbarları için TTK m. 18/3 uygulanır. Tacirler arasındaki ihtar yöntemleri, proje içi mesajlaşmanın hukuki bildirimden ayrılması bakımından önemlidir.

Geçici veri eksikliği ile imkânsızlık aynı değildir

Müşterinin henüz veri vermemesi, her durumda eserin tamamlanmasının imkânsızlaştığı anlamına gelmez. Geçici engel, kalıcı engel, ifadan kaçınma ve projenin müşteri tarafından iptal edilmesi farklı hukuki niteliklerdir. TBK m. 485, eserin tamamlanmasının işsahibiyle ilgili beklenmedik olay dolayısıyla imkânsızlaşmasına özgü hüküm içerir. Yapılmış işin değeri ve bu değere girmeyen giderler ile kusurlu imkânsızlıkta tazminat bu çerçevede ele alınır.

Veri sağlanması hâlinde devam edilebilen projeyi yalnız uzun süre beklediği için imkânsız saymak doğru değildir. İşsahibiyle ilgili imkânsızlık hakkındaki açıklamalar ayrı koşulları gösterir. Dosyada hangi engelin ortadan kalkabileceği, tarafların devam iradesi ve sözleşmenin sona erdirilip erdirilmediği belirlenir. Yüklenicinin bütün sözleşme bedelini istemesi ile yapılmış kısmın ve hukuken karşılanabilir giderlerin talebi aynı hesap değildir.

Gecikmenin ispatı için hangi kayıtlar korunmalıdır?

HMK m. 190, m. 194 ve m. 199 kapsamında iddialar somutlaştırılmalı, elektronik belgeler ilgili olguyla eşleştirilmelidir. Erişim talebi, açılan hesabın yetkisi, bağlantı denemesi, hata kaydı, test sonucu ve veri sürümü aynı çizelgede bulunmalıdır. Yalnız e-posta sayısının çokluğu, talebin gerekli veya gecikmenin nedensel olduğunu kanıtlamaz. Kayıtların tarih ve içerik bütünlüğü korunmalıdır.

Karşılaştırma dosyasında başlangıç planı silinmeden saklanmalı, her revizyonun gerekçesi gösterilmelidir. Toplantı tutanağına tarafların farklı değerlendirmeleri açıkça yazılır. “Bütün gecikme müşteri kaynaklıdır” gibi gerekçesiz özet yerine hangi faaliyetlerin kaç gün ve neden etkilendiği açıklanır. Teknik uzman, iş akışının etkisini değerlendirir; hukuki temerrüt ve tazminat sonucunu mahkemenin yerine belirlemez. Delil, hem müşterinin itirazını hem yüklenicinin iddiasını denetlenebilir hâle getirmelidir.

Geciken erişim başka bir tedarikçiye bağlıysa

Entegrasyon projesinde erişimi müşterinin mevcut muhasebe, ödeme veya depo sistemi sağlayıcısı açacaksa sorumluluk zinciri açık kurulmalıdır. Yeni geliştirici ile eski tedarikçi arasında sözleşme bulunması zorunlu değildir; bunun bulunmaması müşterinin bütün sonuçlardan otomatik sorumlu olduğu anlamına da gelmez. Müşterinin erişimi sağlama taahhüdü, yalnız başvuruyu yapma borcu veya yüklenicinin koordinasyon görevi ayrı ayrı belirlenir. Karşı tarafın kontrol alanında olmayan işlemin nasıl üstlenildiği sözleşmeden okunmalıdır.

Dosyada üçüncü tedarikçiye yapılan başvuru, başvurunun içeriği, ücret veya lisans şartı, verilen cevap ve erişimin açılma tarihi bulunmalıdır. Talep baştan yanlış teknik bilgi içeriyorsa gecikme yalnız cevabı veren kuruma yüklenemez. Erişim kanalı ilk kapsamda bilinmesine rağmen gerekli başvuru geç yapılmışsa bunun nedeni araştırılır. Sağlayıcının sonradan farklı bir lisans istemesi ise başlangıçta kararlaştırılan erişim varsayımıyla karşılaştırılır. Böylece gecikmenin başvuru, teknik hazırlık veya üçüncü kişinin işlemi aşamalarından hangisinde oluştuğu anlaşılır.

Üçüncü kişiyle yazışma müşteri adına yürütülüyorsa yetki sınırı da korunmalıdır. Yeni ücret kabul etmek, mevcut sözleşmeyi değiştirmek veya geniş veri aktarımına izin vermek, sıradan teknik koordinasyonun her durumda içinde sayılmaz. Müşteriye yöneltilen ek bedel ve süre talepleri bu işlemlerden ayrılarak bildirilir. Üçüncü kişinin geç cevap vermesi, geliştiricinin kendi gecikme bildirimini yapmasını gereksiz kılmaz; engelin öğrenildiği tarih ile müşteriye açıklandığı tarih ayrıca izlenir.

Girdi teslim edildiğinde yeni plan nasıl kurulmalıdır?

Eksik veri veya erişim sağlandığında engelin fiilen kalktığı tarih kaydedilir. Yüklenici kontrol için gereken işlemleri gecikmeden yapmalı; devamı engelleyen başka eksiklik varsa açıkça bildirmelidir. Eski bekleme kaydı süresiz açık bırakılmamalıdır. Yeni takvimde tamamlanan işler, devam edecek işler, test penceresi ve teslim ölçütleri yeniden gösterilir. Müşteri tarafından sağlanan girdinin hangi sürümünün esas alındığı belirtilir.

Tarafların yeni takvimde anlaşması, geçmiş zarar iddialarının mutlaka sona erdiği anlamına gelmez. Geçmiş gecikme ve giderler ayrıca tasfiye edilecekse bunun kapsamı yazılmalıdır. Buna karşılık açık bir sulh veya ibra yapılmışsa sonradan aynı döneme ilişkin talep o belge ışığında incelenir. Yeniden başlangıç tutanağı, teknik devam planı ile geçmiş uyuşmazlığın hukuki sonucunu ayrı başlıklarla göstermelidir.

Sık sorulan sorular

Müşteri test verisi vermediğinde otomatik temerrüde düşer mi?

TBK m. 106 koşulları incelenir. Veri gerçekten müşterinin yapması gereken hazırlık fiiline ait olmalı, ifa gereği gibi önerilmeli ve kaçınma haklı sebebe dayanmamalıdır. Yalnız veri istenmiş olması yeterli değildir.

Yüklenici veri beklediğini proje sonunda bildirebilir mi?

Eser sözleşmesinde TBK m. 472, gereği gibi veya zamanında ifayı tehlikeye düşüren durumun hemen bildirilmesini gerektirir. Bildirmeyen yüklenici bundan doğacak sonuçlardan sorumlu olur.

Veri geç geldiği kadar teslim süresi mutlaka uzar mı?

Otomatik gün ekleme kuralı yoktur. Sözleşmenin süre hükmü ve geciken girdinin iş programına gerçek etkisi incelenir. Paralel yürüyen işler ve yüklenicinin kendi gecikmesi ayrıca ayrılır.

Müşteri güvenlik gerekçesiyle sınırsız erişimi reddedebilir mi?

TBK m. 106 haklı sebebin bulunmamasını arar. Talebin kapsamı, sözleşme ve alınması gereken tedbirler incelenir. Müşterinin bütün erişimi gerekçesiz engellemesi ile kapsam dışı erişimi reddetmesi aynı değildir.

Bekleyen personelin bütün maaşı müşteriye yüklenir mi?

Hayır. Talebin sözleşme veya tazminat dayanağı, gerçek ek gider ve nedensellik gösterilmelidir. Alacaklı temerrüdü tek başına bütün personel maliyetini otomatik alacağa dönüştürmez.

Yüklenici bağımsız işleri de durdurabilir mi?

Bütün işi askıya almanın sözleşmesel veya kanuni dayanağı ayrıca incelenir. Eksik girdiden etkilenmeyen işler ve sürmekte olan ayrı borçlar, genel bir bekleme bildirimiyle kendiliğinden sona ermez.

Müşteri testi yapmadığında yazılım her durumda kabul edilir mi?

Teslimin ve inceleme imkânının gerçekleşmesi, sözleşmedeki kabul düzeni ile TBK m. 474 ve m. 477 koşulları değerlendirilir. Teknik görev sistemindeki sessizlik tek başına bütün haklardan vazgeçme değildir.

Veri dosyası gönderildi ama kullanılamıyorsa kim sorumludur?

Önce veri hazırlama ve dönüştürme işinin kimde olduğu belirlenir. Eksik alan veya biçim sorunu somut gösterilir. Başlangıçta kararlaştırılmamış yeni talepler eski teslim borcu gibi değerlendirilemez.

Hazırlık fiili yapılmazsa yüklenici sözleşmeden dönebilir mi?

TBK m. 110, konusu şey teslimi olmayan borçlarda alacaklı temerrüdü için borçlu temerrüdü hükümlerine göre dönme imkânı tanır. Edimin niteliği, uygun süre ve TBK m. 123–125 koşulları ayrıca incelenir.

Uzun süre veri beklenmesi TBK m. 485 imkânsızlığı mıdır?

Tek başına değildir. TBK m. 485, işsahibiyle ilgili beklenmedik olay nedeniyle tamamlamanın imkânsızlaşmasına ilişkindir. Girdi sağlanınca devam edilebilen işte geçici engel ve temerrüt ayrı değerlendirilir.

İstanbul ve Mersin ofislerinde yazılım projesinin müşteri girdisi nedeniyle gecikmesi incelenirken ilk iş planı, veri talepleri, erişim kayıtları ve bütün takvim revizyonları birlikte ele alınır. Teknik açıklama, eksikliğin hangi çalışmayı durdurduğunu göstermelidir. Hukuki değerlendirme bu açıklamayı sözleşmedeki sorumluluk, bildirim ve gider hükümleriyle birleştirerek talebin dayanağını ve sınırını belirler.

Kanun maddeleri ve resmî kaynaklar

• 6098 sayılı Türk Borçlar Kanunu — güncel resmî UYAP metni: m. 52, 97, 106, 110, 112, 114, 123–125, 472–474, 477 ve 485
• 6102 sayılı Türk Ticaret Kanunu — güncel resmî UYAP metni: m. 18/3
• 6100 sayılı Hukuk Muhakemeleri Kanunu — güncel resmî UYAP metni: m. 190, 194 ve 199

Av. Halil Bakırcı tarafından hazırlanmış, Av. Emirhan Keskin tarafından incelenmiştir.

Yazar Bilgisi

Avukat Halil BAKIRCI, Mersin Barosu 3472 sicil numarasına kayıtlıdır. Bakırcı & Keskin Hukuk Bürosu bünyesinde ceza, aile, iş, gayrimenkul ve ticaret hukuku alanlarında hukuki danışmanlık ve dava takibi sunmaktadır.

İnceleyen: Av. Emirhan Keskin · Mersin Barosu Sicil No: 5507

Av. Halil Bakırcı profilini inceleyin →