Selam arkadaslar, BIM tarafindan yazsam da bu konu lab yazilimi olarak da uygun. Bizim tasarim ofisinde lab'tan gelen Atterberg/proktor/CBR raporlarini BIM modeline aktarip 3D zemin profili cikariyoruz. Su anda lab'in raporu Excel sablonu, 4 sheet, ic ice 30+ makro var. Sablonu 2018'de bir lab teknik elemani yazmis, 2022'de bir IT arkadas duzenlemis, simdi kimse "bu makro tam olarak ne yapiyor" sorusuna cevap veremiyor. VBA kodu commentsiz, degisken adlari "x", "y", "temp1", "temp2".

Su an makro arada bir patliyor (ozellikle Office 2024'e gectikten sonra), "Type Mismatch error 13" diyor random hucrede. Lab'taki arkadaslar Excel'i kapatip yeniden aciyor, %70 ihtimalle calisiyor. Bu, urun degil acidir.

Soru: Excel makrolarini Python'a (pandas + openpyxl + jinja2 sablon) tasimak mantikli mi? Lab tarafindan VBA bilen yok, Python'a hic uzak degiller. Yoksa bir baska Excel-native cozum mu (Power Query, LAMBDA fonksiyonlari) tercih edilir?

Berk Bey, Office 2024 + eski VBA kombinasyonu ortak bir agri kaynagi. Microsoft son 3 yıldir VBA'yi yavas yavas pasifize ediyor, 2024'te bircok eski API'yi deprecate etti, "Type Mismatch error 13" tipik olarak ADO recordset veya Range nesnesinin tipi degisikliginden cikiyor. Kisa vadede VBA kodunu auditi yapip duzeltebilirsiniz, ama uzun vadede Excel-makro mimarisi olu yola giriyor.

Python alternatifi mantikli, ozellikle pandas + openpyxl kombinasyonu rapor cikarmak icin olgun. Jinja2 yerine direkt openpyxl ile sablon doldurmak daha az bagimlilik. Lab tarafinin Python ogrenmesi ortalama 2-4 hafta yarim zamanli alir, VBA debug etmekten kolay.

erp_dev_seda yazdi:

pandas + openpyxl kombinasyonu rapor cikarmak icin olgun

Seda hanim, openpyxl ile sablon doldurma orneklerine baktım, mantikli gorunuyor. Tek endisem: sablonun gorsel tasarimi bozuluyor mu (renkli hucreler, conditional formatting, embedded chart'lar)? Lab'in mevcut sablonu cok stilize, musteri marka kimligine uygun.

Berk Bey, openpyxl mevcut bir xlsx sablonunu (boş hucrelerle hazirlanmis) acip degerleri yerlestirip kaydedince stil korunur, conditional formatting de korunur. Embedded chart'lar tricky cunku chart data range'i dinamik degisirse manuel guncellemek lazim. Ama o da yapılabilir.

Bir alternatif olarak xlsxwriter var, sıfırdan dosya yaratir, hizli ama mevcut sablon kullanmaz. openpyxl sizin senaryonuza daha uygun.

Berk Bey, eski Ankara MYO mezunuyum, makro deyince benim aklima Word makrolari geliyor 90'lardan. Lab'imda Excel makro olan bir sey yok cunku 1 numune 1 satir defterimde, hesabi kafamda yapiyorum. Ama gencler her sey makroya devrediyor, sonra makroyu yazani bulamiyorlar. Ders: kim yazarsa yazsin, kodun yorumu olsun. "// Bu satir LL hesabi" yazsa keske 2018'deki adam.

Bizim kaya mekanigi labda da benzer hikaye var. 2019'da bir staj ogrencisi UCS test raporu icin Excel makro yazmis, 4 yıl sonra ben bakinca anlayamadim. Yeniden Python'la yazdim, 200 satir kod oldu, 80 satir comment. Su an 2 yıldir sorunsuz cikiyor rapor. Python tarafini kucumsemek lazim, gercekten okunabilir.

Ama Berk Bey'e bir uyari: Python'a gecis sirasinda eski makro sonuclari ile yeni Python sonuclari paralel kosulmali en az 1 ay. Numerik sapma cikabilir (round-off, formul yorumu farkliligi). Bizim UCS'te 0.05 MPa fark cikmisti bir hesapta, eski makro yanlis yuvarliyormus, Python dogru yapiyor. Yani gecisten sonra "eski raporlar yanlis miydi" sorusu cikabilir, hazirliklı olun.

kk_muh_emre yazdi:

eski makro sonuclari ile yeni Python sonuclari paralel kosulmali en az 1 ay

Emre, paralel kosulma ciddi bir uyari, dusunmemistim. Eski raporlar yanlis cikarsa musteri tarafına acılma riski var (geriye donuk yeniden raporlama, vs). Lab sefiyle bu konuyu konusmam lazim — belki gecisi "ileriye donuk yeni format" olarak cerceveleyip eski raporlari acmamak yolunu tercih ederiz.

Berk Bey, Python'a gecerken bir mimari karari da verin: hesap mantigi nerede yasayacak? Iki secenek:

1) Lab teknik elemani Python script'i kosacak, lokal makinede pandas+openpyxl. Hizli, basit, ama versiyonlama dagiklik (hangi script guncel?). 2) Merkezi bir sunucuda (kucuk bir Flask/FastAPI uygulamasi) script kosacak, lab teknik elemani sadece browser'dan veri yukleyip rapor indirecek. Daha disiplinli ama BT yuku var.

Kucuk lab icin (1) yeterli ama "single source of truth" kuralina uyun: script bir git repo'da yasasin, lab teknik elemanlari her sabah git pull yapmayi alıskanlik etsin. Aksi halde 2 yil sonra "bu script kimde guncelin" sorusu yine cikar.

Power Query alternatifi de duşunulebilir aslinda Berk Bey. Office 365'in dahili, M dili (Power Query) ya da DAX (Power Pivot/BI) ile veri donusturme yapilabilir. Avantaj: Excel native, lab teknik elemani Excel'den cikmadan ogrenebilir. Dezavantaj: hala Excel'in icindesiniz, ileri seviye veri yapilarinda (nested JSON, conditional aggregation) zorlanir.

Ama gercek kıstas su: 5 yıl sonrasini dusun. Python ogrenen lab personeli sadece raporu degil, KAY-ZEM API entegrasyonu, otomatik mail gonderimi, plot uretimi gibi 10 farkli is yapabilir. Power Query sadece veri donusturmek icin. Eger lab'in rotada baska otomasyon ihtiyaclari varsa, Python'a yatirim 5 yıllık verim getirir.

Berk Bey, KAY-ZEM tarafinda zaten rapor sablonu motoru var (Crystal Reports + JasperReports karisimi, ic gelistirme ile birlikte). Sizin lab'in mevcut Excel sablonunu KAY-ZEM'e migration etmek de bir secenek olabilir, kod yazmadan. Tabii lab KAY-ZEM kullaniyorsa.

Bilgi: lab hangi LIMS kullaniyor? Eger bagimsiz bir Excel-tabanli sistemse Python mantikli, eger LIMS varsa LIMS'in raporlama motorunu zorlamak daha temiz olabilir.

kayzem_fatih yazdi:

lab hangi LIMS kullaniyor?

Fatih Bey, lab KAY-ZEM kullaniyor (3 yıldir). Iyi nokta, KAY-ZEM'in sablon motoruyla halledilebilirse cok daha temiz olur. Tek endisem: BIM tarafina cikan rapor formati cok ozel (IFC4 zemin property set'lerine map edilen 50+ alan), KAY-ZEM'in standart sablon motoru bunu destekliyor mu?

Berk Bey, IFC4 export icin KAY-ZEM'de pilot bir modul var, 2025 baslarinda yayinlandi. Su an 3 lab kullaniyor. IFC4 zemin property set'lerinden GeotechnicalUnitProperties ve SoilLayerProperties'i destekliyor, custom field eklemek icin admin panelden tanim acilabiliyor. Demo isterseniz ayarlayabiliriz.

Ama eğer mevcut Excel sablonu cok stilize ve musteri marka kimligi ise, IFC export ile birlikte Excel rapor da cikarmak gerekebilir. Ikisi paralel.

VBA, Python, M, DAX... Berk Bey bilgisayar dillerinin kac tanesi varsa rapor yazilabiliyor, biz alfabe ezberlemeye yetisemiyoruz. Eskiden tek dil vardi raporda: Turkce. Simdi rapor 5 dilli oluyor, Turkce sayilmiyor.

Sarkayasinegi, bence dogru bir nokta sakanin altinda — "rapor cikarma" diye baslayan is, "veri pipeline" muhendisligine donusuyor. Lab teknik elemani simdi yarim zamanli yazılım gelistirici aslinda.

Karar matrisi cikariyorum:

1) Hizli cozum: VBA kodu audit + Office 2024 uyumluluk fix (1-2 hafta, gecici kazan)

2) Orta vadeli: KAY-ZEM sablon motoru + IFC export modulu (Seda hanim demo ayarlayacak)

3) Uzun vadeli: lab personeli icin Python kursu, gelecekteki otomasyon ihtiyaclari icin yetisme.

Lab sefiyle ve Fatih Bey'le konusup karar verecegim. Tesekkurler herkese, cok dolu bir tartisma oldu.

Berk Bey, karar matrisin temiz. Bir not: "kisa vadede VBA fix" adımını atlama, en azından 6 ay sureyle calisan bir Excel sablonu kalsin elinde, paralel kosus icin lazim olur Emre'nin uyarisi geregi. Iyi yol.

Berk Bey, biz 2023'te Python'a gectik raporlama icin, lab teknik elemani yarim zamanli kursa gitti (Udemy, 80 saat ucretsiz egitim materyali). Su an 3 yıldir Python script kullaniyoruz, kurum bilgisi olarak script git repo'da, 5 farkli rapor turu icin tek kod tabani. Bakim cok dustu. Bu yatirim 5 yıllık geri donus saglıyor.