# Geliştirme Günlüğü — Cari Takip Web Bu dosya, web tabanlı Cari Takip Sistemi'nin geliştirilmesi sırasında yapılan tüm önemli işleri tarih sırasıyla kaydeder. İleride sistemi genişletecek kişiye (sen veya başkası) "ne yapıldı, neden yapıldı, nereye bakılmalı" sorularına hızlı cevap vermek için. --- ## 2026-08-15 — Kırık görsellerin GERÇEK sebebi: seeder dosyaları diske yazmıyordu Görsellerin kırık görünmesini iki turda kod tarafında aradım ve iki gerçek hata buldum (aşağıdaki kayıt). Ama sorun devam etti. `yonet.php` > **Görsel / Dosya Tanı** raporu kesin cevabı verdi: ``` ── belgeler.dosya_yolu ── #1001 ✓ [Proje] belgeler/proje/419/OVkGeQ7k9byjMzsk2Pei.pdf ← gerçek yükleme #1000 ✗ [Musteri] belgeler/musteri/401/TESTVERI-F2-FA34EA-200.pdf ← seeder ... TOPLAM 201 kayıt | son 25'in 1'i diskte VAR, 24'ü YOK ``` **Kök neden:** `TestVeriSeeder::belgeler()` DB'ye satır ekliyor ama **diske dosya yazmıyordu**. Gerçek kullanıcı yüklemesi (#1001) sorunsuz çalışıyor; kırık görünen her şey seeder'ın ürettiği hayalet kayıtlar. Yani kod doğruydu, **veri sahteydi**. ### Düzeltmeler 1. **Seeder artık gerçek dosya yazıyor** — `belgeDosyasiYaz()` eklendi. png/jpg/jpeg için **geçerli 8×8 PNG** (getimagesize ile doğrulandı), pdf için minimal geçerli PDF, csv/txt için metin. Önizleme dalları artık gerçekten test edilebilir. 2. **Seeder temizliği dosyaları da siliyor** — önce diskteki dosya, sonra DB satırı (ters sıra olsaydı yol bilgisi kaybolur, dosyalar storage'da yetim kalırdı). 3. **`yonet.php` > Eksik Dosyalı Belge Kayıtlarını Temizle** (YENİ) — mevcut bozuk kayıtları siler. İlk tıklama **kuru çalıştırma**: ne silineceğini listeler, hiçbir şey silmez; silmek için "Onaylıyorum" kutusu işaretlenmeli. **Dosyası yerinde olan belgelere dokunmaz.** 4. **`gorsel-tani` genişletildi** — `belgeler` tablosunu da kapsıyor (önceden hiç bakmıyordu) ve **arayüzde butonu yoktu**, eklendi. Ayrıca avatar/branding görselleri `public/uploads/` altında olduğu için yanlışlıkla ✗ işaretleniyordu; bunlar bilerek webroot'a yazılıyor (symlink'e bağlı kalmamak için), tanı artık doğru yerde arıyor. ### Sunucuda yapılacak `yonet.php` > **Görsel / Dosya Tanı** → **Eksik Dosyalı Belge Kayıtlarını Temizle** (önce kuru çalıştırma, sonra onaylayarak). Test verisi yeniden üretilirse dosyalar bu kez diske de yazılır. --- ## 2026-08-15 — HATA: Dosya Yöneticisi görselleri 404 dönüyordu **Belirti:** Dosya Yöneticisi'nde görseller kırık görünüyordu ("yollar yanlış" gibi). **Kök neden:** Yol doğruydu — `Belge::getUrlAttribute()` düzgün bir route üretiyor (`/belgeler/{id}/onizleme`). Sorun **yetki katmanındaydı**: `BelgeController::preview()` ve `download()` şöyle başlıyordu: ```php $entity = $belge->iliski; $tip = $this->modelTipi(get_class($entity)); // <-- burada patlıyor ``` `modelTipi()` yalnızca modül modellerini (Cari, Personel, Teklif...) tanır ve tanımadığında `default => abort(404)` der. Ama **Dosya Yöneticisi'nden yüklenen dosyalar `iliski_type = Firma` ile kaydediliyor** (merkezi arşiv), Firma o haritada YOK → her görsel **404**. İkinci bir hata daha vardı: ilişkisi silinmiş dosyalarda `$belge->iliski` null olur, `get_class(null)` **TypeError** fırlatır → 500. Dosya Yöneticisi'nin "ilişkisiz" filtresi tam da bu dosyalar için var, yani bu yol gerçekten tetikleniyordu. **Çözüm:** `belgeErisimKontrol()` ortak metodu eklendi; iki uç da onu kullanıyor: - **Modül belgesi** → eskisi gibi o modülün `goruntule` yetkisi - **Firma'ya bağlı veya ilişkisiz belge** → `dosya_yonetici.goruntule` yetkisi - Her iki yolda da firma izolasyonu korunur (`belgeler.firma_id` damgası + ilişki firması) **Doğrulama (gerçek dosya, gerçek istek):** | Senaryo | Önce | Sonra | |---|---|---| | Dosya Yöneticisi dosyası (Firma) | 404 | **200** | | İlişkisi kopuk dosya | 500 (TypeError) | **200** | | Modül dosyası (Cari) | 200 | **200** (değişmedi) | | Yetkisiz kullanıcı | — | **403** | | Başka firmanın dosyası | — | **403** | Doğru firmadan istendiğinde gerçek dosya döndü (70 bayt PNG). **Ek düzeltmeler (aynı ekran):** - Kutu görünümünde görseller `object-cover` ile **kırpılıyordu** → `object-contain`. Geniş logolar ve dikey fotoğraflar artık tam görünüyor. Tablo görünümündeki küçük resim de aynı şekilde düzeltildi (+ ince çerçeve, şeffaf PNG kaybolmasın). - Kutu görünümündeki özel toggle switch kaldırıldı; tablo görünümüyle **aynı `IndeterminateCheckbox`** kullanılıyor. Görselin üstünde okunsun diye beyaz zeminli kutunun içinde, etiketin tamamı tıklanabilir. - `alt` metni dosya adını taşıyor, `loading="lazy"` eklendi. --- ## 2026-08-15 — HATA: iki controller'da `aktifFirmaId()` tanımsızdı **Belirti:** Dosya Yöneticisi açılırken `Call to undefined method DosyaYoneticiController::aktifFirmaId()`. **Kök neden:** Bu proje aktif firmayı her controller'da ayrı ayrı tanımlanan `private function aktifFirmaId(Request $request)` ile çözüyor (base `Controller` sınıfında yok). `DosyaYoneticiController` (Parti 2) ve `SozlesmeImzaController` (Parti 3) yazılırken metodu çağırdım ama **tanımlamayı unuttum**. `php -l`, `tsc` ve `route:list` bunu yakalamaz — sadece o sayfa açıldığında patlar. Her ikisini de yalnızca statik kontrolle geçirdiğim için kaçtı. - `DosyaYoneticiController`: 4 çağrı → **/dosya-yonetici tamamen açılmıyordu** - `SozlesmeImzaController`: 6 çağrı → imza daveti panel uçlarının hepsi 500 verirdi (liste, gönder, iptal, loglar, kayıttan gönder, özet) **Çözüm:** Diğer controller'lardaki ile birebir aynı `private aktifFirmaId()` metodu ikisine de eklendi. (Base sınıfa taşımak mümkün değil: mevcut controller'larda metot `private`, ebeveynde `protected` olsaydı PHP görünürlük daraltma hatası verirdi.) **Tekrar kaçmasın diye:** yansıma tabanlı bir tarayıcı yazıldı — her controller'ın `$this->xxx()` çağrılarını kalıtım + trait dahil gerçek metot listesiyle karşılaştırıyor (grep'in yapamadığı bu). **52 controller tarandı, 0 tanımsız çağrı.** Betik: `scratchpad/metot_tara.php` (kalıcı hâle getirilmek istenirse `php artisan tinker --execute="require ..."` ile çalıştırılır). **Doğrulama:** Dosya Yöneticisi 4 farklı filtreyle açıldı; ertelenmiş (defer) prop'ların dördü de (`dosyalar`, `uzantilar`, `ozet`, `kullanicilar`) ayrı ayrı çözüldü; `topluSil` çalıştı. --- ## 2026-08-15 — Modül Bilgi Butonları — 16 maddelik listenin 6. maddesi (SON MADDE) Filtre butonu olan **44 ekranın tamamına**, filtrenin hemen yanına bir **"?"** düğmesi kondu. Düğme o ekranın ne işe yaradığını, nasıl kullanıldığını ve dikkat edilmesi gerekenleri anlatan bir pencere açar. ### Yapı - `resources/js/lib/modulBilgi.ts` — **tüm içerik tek dosyada**. Her kayıt: `ozet` (bir paragraf), `bolumler[]` (başlık + madde listesi), `ipuclari[]`, `uyarilar[]`, `yetkiler[]`. Metinlerde `**kalın**` yazımı desteklenir. - `resources/js/Components/ModulBilgi.tsx` — düğme + pencere. Kayıt yoksa **düğme hiç çizilmez** (yarım bir yardım penceresi açmaktansa hiç açmamak yeğdir). - Raporlarda düğme `RaporAksiyonlar` bileşenine `bilgiKonu` prop'u ile eklendi — 11 rapor ekranı için tek yerden. ### İçerik 30 konu yazıldı: cari · hareket · kasa · urun · stok_hareket · musteri · sozlesme · musteri_sozlesme · personel · personel_izin · proje · gorev · randevu · teklif · teklif_urun · teknik_servis · servis_yedek_parca · yenileme · yenileme_urun · yenileme_log · firma · kullanici · dosya_yonetici · aktivite_log · sistem_log + 11 rapor konusu. Her listede tekrarlanan davranışlar (filtre paneli, toplu işlem, sayfalama, sıralama, Pasife Al / Tamamen Sil ayrımı) `ORTAK_LISTE` sabitinde bir kez yazılıp her kayda eklendi. İçerik gerçek iş kurallarını anlatır, genel geçer laf değildir. Örnekler: - **Cari ekstresi**: "Tür/tutar filtresi açıkken Bakiye sütunu yalnızca filtreye uyan satırları toplar." - **Müşteri sözleşmesi**: "İmza atıldığı anda metin donar; farklı metin gerekiyorsa yeni sözleşme oluşturun." - **Personel izni**: kıdem→gün tablosu (1–5 yıl **5 dahil** 14 gün ...), md. 56 hafta tatili kuralı, yaşa bağlı istisnanın neden otomatik uygulanmadığı. - **Ürün**: kritik/minimum stok eşiklerinin farkı. - **Teklif ürünü**: "İlişkili tüm kayıtlarda güncellensin mi?" sorusunun ne yaptığı. ### Doğrulama `npx tsc --noEmit` temiz · `npm run build` başarılı. Filtre butonu olan ekran sayısı **44**, bilgi düğmesi olan ekran sayısı **44** — eksik yok. Düğmenin filtrenin hemen ardında olduğu örnek ekranlarda doğrulandı. ### Deploy Migration yok. `yonet.php` > **Önbelleği Temizle** yeterli. --- ## 2026-08-15 — Personel İzin Takibi — 16 maddelik listenin 4. maddesi Personele yıllık izin hakkı, izin talebi ve onay akışı geldi. ### Veritabanı (`2026_08_15_000001_personel_izin_takibi`) - `izin_turleri` — ad, renk, **`haktan_dusulur`**, `ucretli`, sıra, aktif. Her firmaya 7 varsayılan tür: Yıllık İzin (haktan düşer), Mazeret, Raporlu, Ücretsiz, Doğum, Evlilik, Ölüm. - `personel_izin_haklari` — yıl bazında `hak_gun` + `devir_gun` + `elle_ayarlandi`. `(personel_id, yil)` unique. - `personel_izinleri` — tarih aralığı, gün sayısı, yıl, durum (bekliyor / onaylandi / reddedildi / iptal), red nedeni, onaylayan, aktif. Tür silinirse `nullOnDelete` + `izin_turu_ad` anlık kopya (geçmiş kayıt bozulmaz). ### İş kuralları - **Yıllık hak, 4857 md. 53'e göre kıdemden hesaplanır:** 1 yıldan az → 0, 1–5 yıl (5 DAHİL) → 14, 5'ten fazla 15'ten az → 20, 15 ve üzeri → 26 gün. Yaşa bağlı istisna (18 altı / 50 üstü ≥20 gün) doğum tarihi tutulmadığı için otomatik uygulanmaz — hak günü elle düzeltilebilir, `elle_ayarlandi` işaretlenir ve toplu hesaplama o kaydın üzerine YAZMAZ. - **Gün sayısı md. 56'ya göre:** varsayılan Cumartesi + Pazar hariç. "Cumartesi iş günü" ve "takvim günü (hafta sonu dahil)" seçenekleri var; gün sayısı elle de girilebilir. - **Yalnızca `haktan_dusulur` türler bakiyeden düşer.** Rapor/doğum izni kayda geçer ama yıllık hakkı azaltmaz. Bekleyen talepler ayrı "rezerve" gösterilir. - **Çakışma engeli:** aynı personelde tarihleri kesişen bekleyen/onaylı izin varsa kayıt reddedilir (hangi izinle çakıştığı mesajda yazar). - **Bakiye kontrolü onay anında:** kalan yetmiyorsa onaylanamaz, ne kadar eksik olduğu söylenir. - **Red nedeni zorunlu** — reddetme ayrı modalda (sistem kuralı: native prompt yasak). ### Ekranlar - `PersonelIzin/Index` — tüm izinler; özet kartlar (onay bekleyen / bugün izinde / onaylı / toplam gün), filtre çekmecesi (personel · tür · durum · yıl · tarih aralığı · bugün izinde · pasif), toplu silme, sayfalama, satırdan onayla/reddet/iptal. "Hakları Hesapla" butonu yılın haklarını kıdemden toplu üretir. - `PersonelIzin/PersonelKarti` — tek personel: kıdem, 5 bakiye kartı (hak / devir / toplam / kullanılan / bekleyen), yıl seçici, hak düzenleme formu, o yılın izin geçmişi. - `PersonelIzin/_FormModal` — tarih seçilince gün sayısı sunucudan canlı hesaplanır, seçili personelin bakiyesi anlık gösterilir, talep bakiyeyi aşıyorsa uyarır. - `PersonelIzin/_RedModal` — red nedeni zorunlu. ### Zorunlu entegrasyonlar `personel.izin` + `personel.izin_onay` yetkileri · Moduller.php sidebar ("İzinler", `route_prefixes`'e `izinler`) · Tanımlamalar > **İzin Türleri** (`izin-turu`) · AktiviteLog modülü `personelizin` (personel loglarıyla karışmasın diye ayrı kod) · Personel listesine izin ikonu · **Dashboard widget** (onay bekleyen + bugün izinde olanların listesi, personel paneliyle birlikte çizilir). ### Doğrulama — gerçek veriyle çalıştırıldı Kıdem→hak eşlemesi 8 senaryoda doğrulandı (5 ve 15 yıl sınırları dahil). Gün hesabı 5 senaryoda doğru (Pzt-Cum=5, hafta sonu dahil=7, cumartesi dahil=6, ters aralık=0). Yıllık izin bakiyeden düştü, raporlu düşmedi. Çakışma engellendi. Bekleyen→onay geçişinde bakiye 20→15→10 doğru ilerledi. Red nedeni zorunluluğu ve bakiye aşımı engeli çalıştı. Her iki ekran Inertia props'larıyla render oldu, `gunHesapla` ve `ozet` API'leri doğru JSON döndü, 6 aktivite logu yazıldı. Tüm test verisi rollback edildi. ### Deploy `yonet.php` > **Veritabanını Güncelle** (`2026_08_15_000001`) → **Önbelleği Temizle**. Ardından ilgili kullanıcılara `personel.izin` / `personel.izin_onay` yetkisi verilmeli. İlk kurulumda İzinler ekranından **"Hakları Hesapla"** çalıştırılmalı. --- ## 2026-08-15 — Sözleşme Akışı Yeniden Tasarlandı (kullanıcı düzeltmesi) Bir önceki gün kurulan "imza daveti" akışı kullanıcının istediği şey değildi. Eski akışta davet ayrı bir şablon seçimiyle başlıyor, kendi snapshot'ını üretiyor ve imzalanınca **yeni** bir sözleşme kaydı açıyordu. Doğrusu: sözleşme önce kaydedilir, sonra **o kayıt** imza için gönderilir. ### Yeni akış 1. **Sözleşme Ekle** — şablon seçilir, metin bu müşteri için doldurulur. 2. **Kaydet** — imza ve ad soyad doluysa `imzalandi`, boşsa `taslak` olarak kaydeder. İmza artık ZORUNLU DEĞİL. (Tek başına imza / tek başına ad girilirse uyarır.) 3. **Metni Düzenle** — taslak aşamasında metin **bu müşteriye özel** değiştirilebilir (fiyat, madde, tarih). Şablon ve diğer müşterilerin sözleşmeleri etkilenmez. Hem ekleme modalında hem görüntüleyicide mevcut. 4. **İmza için gönder** — listedeki bağlantı ikonu; **bu kaydın metnini** gönderir. Müşteri imzalayınca AYNI kayıt imzalanmış olur, kopya kayıt oluşmaz. 5. **Müşteriye İlet** — yalnızca imzalı kayıtta çıkar (onaylı PDF e-postası). ### Snapshot kuralı korundu, sadece inceltildi `MusteriSozlesme::booted()` artık `getOriginal('durum')` bakıyor: imzalanmış bir kaydın `DONMUS_ALANLAR`'ına dokunmak hâlâ istisna fırlatır, ama taslak → imzalandı geçişi (aynı update içinde) serbest. Yani **imzalı sözleşme asla bozulmaz**, imza öncesi düzenleme serbesttir. ### Değişiklikler - `2026_08_15_000002_musteri_sozlesme_imzasiz` — `imza_ad_soyad` + `imza` nullable, `durum` kolonu (`taslak` / `imzalandi`), mevcut imzalı kayıtlar geriye dönük işaretlendi. - `MusteriSozlesme` — `DURUM_*` sabitleri, `imzalandiMi()`, `duzenlenebilirMi()`. - `MusteriSozlesmeController::store()` — imza opsiyonel, düzenlenmiş metni kabul eder, bilgilendirme maili yalnızca imzalıda gider. - `MusteriSozlesmeController::guncelle()` (YENİ) — taslak metnini müşteriye özel günceller; imzalıda 422. Aynı istekte imza gelirse imzalanmış hâle geçirir. - `SozlesmeImzaController::kayittanGonder()` (YENİ) — mevcut kayıttan davet üretir; aynı kayıt için bekleyen davet varsa yenisini AÇMAZ, metnini tazeleyip tekrar gönderir. - `SozlesmeImzaController::imzala()` — `musteri_sozlesme_id` doluysa o kaydı imzalar, yalnızca bağlantısız/eski davetlerde yeni kayıt oluşturur. - Liste — **Durum** kolonu (İmzalandı / İmza Bekliyor rozeti), filtre panelinde durum seçimi, taslakta bağlantı ikonu · imzalıda gönder ikonu. - `_ImzaGonderModal` (YENİ) — kayıt bazlı gönderim + kopyalanabilir bağlantı. - `_GosterModal` — durum rozeti, taslakta "Metni Düzenle" + "Metni Kaydet". - `_DavetModal` — artık yalnızca **gönderim geçmişi** (şablon seçen "Yeni Davet" formu kaldırıldı). ### Doğrulama `php -l` temiz · `npx tsc --noEmit` temiz · `npm run build` başarılı · 23 sözleşme rotası ayakta. **Lokal DB'de `musteri_sozlesmeleri` tablosu olmadığı için akış çalıştırılarak test EDİLEMEDİ** (migration zinciri sqlite'ta kırık — bkz. aşağıdaki not). Sunucuda ilk denemede taslak kaydetme → metin düzenleme → imza gönderme → müşteri imzalama sırası kontrol edilmeli. ### Deploy `yonet.php` > **Veritabanını Güncelle** (`2026_08_15_000002`) → **Önbelleği Temizle**. --- ## 2026-08-15 — Raporlama Overhaul — 16 maddelik listenin 1, 2 ve 3. maddeleri **11 rapor ekranının tamamı** aynı iskelete geçirildi: zorunlu sayfalama, filtre çekmecesi, gerçek grafikler (recharts) ve baskıya hazır çıktı. ### Ortak bileşenler (`resources/js/Components/Rapor/`) - `RaporKart` — özet kartı; her raporda ayrı ayrı kopyalanmış `KartTipi`/`Kart` bileşenlerinin yerini aldı. - `RaporGrafik` — `SutunGrafik` / `PastaGrafik` / `CizgiGrafik` / `OranListesi` + `GrafikKutu`. Türkçe sayı biçimi, boş-veri durumu, tema paleti tek yerde. `recharts` zaten bağımlılıktaydı, ilk kez gerçekten kullanılıyor (önceden yalnızca CSS çubuk vardı). - `RaporAksiyonlar` — filtre + Yazdır + Excel + PDF butonları; **tablet/mobilde yalnızca ikon** (sistemdeki genel kural). `raporSorgu()` ekrandaki filtreyi indirme bağlantısına birebir taşır. - `RaporGovde` — `.rapor-yazdir` sarmalayıcısı + yalnızca kâğıtta görünen başlık (firma, rapor adı, dönem). ### Baskıya hazır çıktı (`resources/css/app.css`) `@media print` bloğu eklendi: yazdırırken sidebar/üst bar/filtre çekmecesi/sayfalama çıkmaz, tablo başlığı her sayfada tekrarlanır, kartlar ve grafikler sayfa ortasından bölünmez, `liste-tablosu`nun `white-space: nowrap` kuralı baskıda gevşetilir. Yardımcı sınıflar: `.rapor-yazdir` · `.yazdirma-gizle` · `.yazdirma-butun` · `.yalniz-yazdir`. ### Sayfalama — artık İSTİSNASIZ hepsinde Eksik olan 4 rapor tamamlandı: **Cari Ekstresi, Kasa Raporu, Mali Özet, Personel Bordrosu**. Yürüyen bakiye (cari/kasa) tüm set üzerinden hesaplandığı için SQL LIMIT kullanılamaz — `diziPaginate()` yardımcısı hesap bittikten sonra diziyi dilimler. Personel bordrosunda mesai ve ödeme listeleri **ayrı** sayfalanır (`mesai_sayfa` / `odeme_sayfa`), biri diğerini kaydırmaz. ### Gelişmiş filtreler (her rapora özel, FilterDrawer ile) | Rapor | Filtreler | |---|---| | Cari Ekstresi | tür · yön · tutar aralığı · belge no · açıklama | | Kasa Raporu | tür · yön · cari · tutar aralığı · açıklama | | Mali Özet | tür · yön · kasa · cari · tutar aralığı · açıklama | | Personel Bordrosu | ödeme türü · kasa · yalnızca fazla mesai · açıklama | | Proje | statü · tip · müşteri · yetkili · durum (aktif/pasif/tamamlandı/geciken) · başlık | | Görev | durum · öncelik · atanan · atayan · yalnızca geciken · başlık | | Randevu | statü · tip · müşteri · personel · zaman (bugün/gelecek/geçmiş) · başlık | | Teklif | statü · müşteri · atanan · durum (tamamlandı/bekleyen/süresi geçmiş) · başlık+kod | | Müşteri | kategori · şehir · sektör · durum · unvan | | Stok Envanteri | kategori · stok durumu · sıfır stoğu gizle · min. stok değeri · ad/kod/barkod | | Stok Hareket Özeti | kategori · ürün · hareket tipi · ad/kod | Filtreler **hem özet/grafik hem detay sorgusuna** aynı closure ile uygulanır — kartlardaki sayı ile tablodaki satır sayısı ayrışmaz. Cari/kasa raporlarında filtre açıkken bakiye kolonu yalnızca filtreye uyan satırları topladığı için ekranda **sarı uyarı** çıkar (`filtre_aktif` bayrağı). ### Yeni analiz + grafikler Her rapora aylık zaman serisi (`aylikSeri()` — "Oca 26" biçimi, sürücüye göre `strftime`/`DATE_FORMAT`) ve dağılım pastaları (`dagilimSeri()` — ilk 10 + "Diğer") eklendi. Mali Özet'e ayrıca gelir/gider kalem pastaları ve **sayfalı hareket detayı** tablosu; Stok Envanteri'ne stok sağlığı pastası; Teklif'e aylık adet+tutar sütunu. ### Yeni çıktı uçları `mali-ozet/excel` · `personel-bordrosu/excel` · `stok/hareket-ozet/pdf` · `stok/hareket-ozet/excel` (+ yeni blade `raporlar/stok-hareket-ozet.blade.php`). ### Yol boyunca çıkan hatalar (hepsi onarıldı) 1. **Teklif raporunda N+1** — her satır için ayrı `SUM(miktar*birim_fiyat)` sorgusu çalışıyordu; `withSum('satirlar as satir_toplam', ...)` ile tek sorguya indi. 2. **Stok durum kodları tutmuyordu** — `Urun::getStokDurumuAttribute()` `kritik/dusuk/yeterli` dönerken ekrandaki renk haritası `yeterli/az/kritik/bitti` bekliyordu: "düşük" stoktaki ürünler rozetsiz basılıyordu. Üç koda da hizalandı. 3. **PDF layout'unda tanımsız değişken** — `raporlar/_layout.blade.php` her raporda `$baslangic`/`$bitis` bekliyordu; stok envanteri gibi anlık raporlarda uyarı üretiyordu. `@isset` ile korundu, tarih aralığı yoksa "Rapor Tarihi" yazıyor. 4. **`admin/excel-import` rotaları** var olmayan `ExcelImportController`'ı çağırıyordu (500 + `route:list` çöküyordu) — açıklamayla yorum satırına alındı. 5. **Migration'lar MySQL'e bağımlıydı** — `roller_kaldir` ve `gorev_atananlar_coklu` `information_schema` sorguluyor, `users_kullanici_adi_kaldir` `ALTER TABLE ... DROP INDEX` kullanıyordu; sqlite'ta patlıyorlardı. Üçü de sürücü kontrolüyle taşınabilir hale getirildi. ### Doğrulama `npx tsc --noEmit` temiz · `npm run build` başarılı · `route:list` 36 rapor rotası. Cari/kasa/mali/bordro/müşteri/stok veri metotları filtreli + filtresiz + boş seçim hâlleriyle çalıştırıldı; geçici veriyle (40 hareket, 3 ürün, 18 stok hareketi) sayfalama sınırı, yürüyen bakiye tutarlılığı, `son = devir + giriş − çıkış` eşitliği ve filtre etkisi doğrulandı, veriler rollback edildi. Dört muhasebe/personel PDF'i + iki stok PDF'i üretildi. > **Not:** Proje/Görev/Randevu/Teklif raporları lokal sqlite'ta **çalıştırılarak** doğrulanamadı — > o modüllerin tabloları lokal veritabanında yok (migration zinciri sqlite'ta hâlâ > `users.rol_id` FK'sinde kırılıyor; canlı MySQL'de sorun değil). Bu dördü için yalnızca > statik doğrulama (php -l, tsc, build, route:list) yapıldı. ### Deploy Migration yok. `yonet.php` > **Önbelleği Temizle** yeterli (blade cache + route cache). --- ## 2026-08-14 — Sözleşme İmza Daveti (uzaktan imzalatma) — 16 maddelik listenin 5. maddesi Müşteri sözleşmesi artık sadece panel başında imzalanmıyor: müşteriye **bağlantı** gönderilip giriş yapmadan imzalatılabiliyor. İmza hukuki sonuç doğurduğu için **her adım loglanıyor**. ### Veritabanı - `2026_08_14_000001_sozlesme_imza_daveti` — iki tablo: - `sozlesme_imza_davetleri` — token (48 hex), **snapshot içerik** (davet anında dondurulur), durum (bekliyor / goruntulendi / tamamlandi / iptal / suresi_doldu), gönderilen mail + ek mailler, gönderim / ilk görüntüleme / tamamlanma tarihleri, `son_gecerlilik`, `musteri_sozlesme_id`. - `sozlesme_imza_loglari` — denetim kaydı: tip, başlık, açıklama, **IP + tarayıcı**, kullanıcı, `detay` JSON. - `2026_08_14_000002_sozlesme_imza_mail_sablonu` — `sozlesmeler` tablosuna `imza_mail_konu` + `imza_mail_govde`. ### Snapshot kuralı (kritik) Metin **davet anında** dondurulur. Şablon sonradan değişse bile müşteri gördüğü metni imzalar; imza tamamlanınca aynı metin `musteri_sozlesmeleri` kalıcı kaydına geçer. Şablon silinse dahi imzalı kayıt bozulmaz (`nullOnDelete`). ### Backend - `SozlesmeImzaDaveti` — `imzaUrl()`, `imzalanabilirMi()` (tamamlanmış/iptal/süresi dolmuş kabul etmez). - `SozlesmeImzaLog::yaz()` — tek satır log kısayolu; IP + user agent + kullanıcıyı otomatik yakalar, log yazılamazsa asıl işlemi bozmaz. 8 tip: `olusturuldu`, `mail_gonderildi`, `mail_hatasi`, `link_acildi`, `imzalandi`, `iptal_edildi`, `suresi_doldu`, `bilgilendirme_gonderildi`. - `SozlesmeImzaController` — panel: `index` / `store` / `gonder` / `iptal` / `loglar`; public: `imzaSayfasi` / `imzala`. `davetMailIcerik()` **`{imza_linki}` garantisi** verir — şablondan silinmişse gövdenin sonuna otomatik eklenir (linksiz davet işe yaramaz). - Yer tutucular: `{imza_linki}` + `{son_gecerlilik}` GRUP_SOZLESME'ye eklendi. ### Frontend - `Public/SozlesmeImza.tsx` — giriş gerektirmeyen imza sayfası (snapshot metin + SignaturePad + onay). - `Sozlesme/_MailSablonModal` — **%40 İmza Sonrası Bilgilendirme / %40 İmza Daveti / %20 Yer Doldurucular**; iki editör + iki konu alanı, 4 yönlü `hedefAlan` (token hangi alana gidecek panelde yazılı), mobilde 3 sekme. - `MusteriSozlesme/_DavetModal` — tek modalda iki görünüm: - **Liste** — durum rozeti, bağlantı kopyala, (tekrar) gönder, iptal (styled onay penceresi), oluşturma / gönderim / ilk görüntüleme / son geçerlilik tarihleri; **History ikonu → davet başına log zaman çizelgesi** (ikonlu, IP + tarayıcı + kullanıcı ile). - **Form** — AsyncSelect şablon, geçerlilik günü, "e-posta ile gönder" toggle, ek mail listesi. Kayıttan sonra bağlantı kopyalanabilir ekranda gösterilir (mail kapalıyken de link üretilir). - `MusteriSozlesme/Index` — filtre butonunun sağına `Link2` ikonu (imza davetleri). ### Yol boyunca çıkan hata `routes/web.php` içindeki `admin/excel-import` bloğu **var olmayan** `ExcelImportController` sınıfını çağırıyordu: sayfa 500 veriyor, `php artisan route:list` ReflectionException ile patlıyordu. Blok açıklamayla yorum satırına alındı (ekran dosyası `Pages/Admin/ExcelImport.tsx` duruyor). ### Bilinen lokal sorun (sunucuyu etkilemez) `2026_05_12_000009_users_kullanici_adi_kaldir` lokal **sqlite**'ta patlıyor ("no such column: kullanici_adi" — sqlite index/drop-column kısıtı). Canlı MySQL'de sorun değil, migration çoktan uygulanmış. Yeni iki migration tek tek çalıştırılarak doğrulandı. ### Deploy `yonet.php` > **Veritabanını Güncelle** → iki yeni migration. Ardından **Önbelleği Temizle**. Yetkiler: mevcut `musteri_sozlesme.goruntule` (log okuma) ve `musteri_sozlesme.ekle` (davet oluştur / gönder / iptal) kullanılıyor, yeni yetki eklenmedi. --- ## 2026-06-16 — Teknik Servis Modülü (İterasyon 1: Veritabanı + Modeller + Manifest) Yeni modül `teknik_servis` eklendi. İterasyon 1: backend iskelet (controller/route hariç). **Migration'lar** (`2026_06_18_010001 .. 010010`): - `servis_durumlari` — TeklifStatu pattern, mail_konu + mail_govde, tamamlandi_mi - `servis_turleri` — basit kategori-benzeri (firma_id, ad, renk, sıra) - `servis_hizmet_turleri` — aynı - `servis_yedek_parcalari` — TeklifUrun pattern (katalog: ad, fiyat, görsel, açıklama) - `servisler` — ana tablo: servis_no (otomatik SRV-YYYY-0001), başlık, kayıt/işlem tarihi, durum/tür/hizmet, personel (User), müşteri, teslim eden/alan, marka/model/seri, fatura_var, müşteri_beyani + personel_notlari (longText) - `servis_satirlari` — TeklifSatir pattern (yedek_parca_id + parca_adi + miktar/fiyat) - `servis_yorumlari` — Proje yorumları pattern - `servis_ek_alanlar` — başlık + içerik artırılabilir, sıralı (Firma banka bilgileri pattern) - `servis_seed` — kullanıcı listesinden 15 durum + 5 tür + 12 hizmet türü her firmaya işlenir - `teknik_servis_modulu_firmalara_ata` — `firma_modulleri` tablosuna kayıt ekle **Modeller** (`app/Models/`): - `ServisDurum`, `ServisTuru`, `ServisHizmetTuru`, `ServisYedekParca` - `Servis` — `booted::creating` ile servis_no otomatik atama; belgeler MorphMany - `ServisSatir`, `ServisYorum`, `ServisEkAlan` **Manifest + Yetki**: - `App\Support\Moduller::liste()` → `teknik_servis` eklendi, route_prefixes: `servisler` + `servis-yedek-parcalari` - `App\Support\Permissions` → `aciklamalar()` ve `gruplar()` (9 yetki: goruntule, ekle, duzenle, sil, toplu_sil, tum_goster, mail_gonder, parca, rapor) **İterasyon 2'de**: Controllers + Routes + AsyncSelect endpoint'leri (`/api/ara/servisler`, `/api/ara/servis-yedek-parcalari`) **İterasyon 3'te**: Frontend (Takvim/Board/Tablo/FormModal/FiltreDrawer/BildirimModal/Yedek Parça sayfaları) **İterasyon 4'te**: Tanımlamalar UI + Dashboard widget + Sidebar **İterasyon 5'te**: Test + build + dev_log son --- ## 2026-06-16 — Teknik Servis Modülü (İterasyon 2: Controllers + Routes + AsyncSelect) **Yeni controller'lar:** - `app/Http/Controllers/TeknikServisController.php` — TeklifController + RandevuController birleşimi. Yöntemler: `takvim/board/tablo`, `takvimVeri` (JSON), `formJson`, `store/update/destroy/topluSil`, `durumDegistir` (board drag), `tarihDegistir` (takvim drag), `sirala`, `alanGuncelle`, `yorumEkle`, `bildir` (mail attach destekli). - `app/Http/Controllers/ServisYedekParcaController.php` — TeklifUrunController pattern. CRUD + görsel yükleme (`storage/servis-yedek-parcalari/{firmaId}/`). **Tanımlamalar generic sisteme entegre:** - `KategoriController::TIPLER` → 3 yeni: `servis-durum` (mail_sablon=true), `servis-tur`, `servis-hizmet-turu` — hepsi `modul=teknik_servis`. - Yeni endpoint: `servisDurumMailKaydet()`. **Arama (AsyncSelect):** - `AraController::servisler` ve `AraController::servisYedekParcalari` (yeni) - `AraController::cozumle` — `tip=servis-yedek-parca` ve `tip=servis` desteği eklendi. **Belge / Dosya:** - `BelgeController` — `tip=servis` eşleştirmesi. `yetkiOnEki()` helper: `servis → teknik_servis`. **Routes (`routes/web.php`):** - `Route::middleware('modul:teknik_servis')->group()` — 17 route. - `/api/ara/servisler`, `/api/ara/servis-yedek-parcalari`. - `/servis-durum/{durum}/mail` mail şablonu. - Belge regex'lerine `servis` eklendi. **İterasyon 3'te**: Frontend sayfaları. --- ## 2026-05-07 — [Faz 1 / İterasyon 1] Web Tabanlı Yeniden Yazım — Çekirdek Altyapı **Yapılanlar:** ### 1. Stack ve Mimari - **Önceki sistem** (`cari-excel-sistemi/`, Excel + VBA + Access) görsel olarak yetersiz bulundu. Kullanıcı "her yerden erişilebilir, görsel modern, geliştirilebilir" bir sistem istedi. - **Yeni stack:** Laravel 11 (PHP 8.3) + Inertia.js + React 18 + TypeScript + Tailwind CSS 3 + SQLite (dev) → MySQL (prod). - Auth: Laravel Breeze + role/permission sistemi. - Hosting hedef: cPanel (Türkiye'de yaygın, KVKK uyumlu). ### 2. Geliştirme Ortamı (Laragon Full) - **Laragon Full** kuruldu (`C:\laragon`): PHP 8.3 + MySQL 8.4 + Composer + Node 22 + Git hepsi tek paket. - Laragon menü → Tools → Path → "Add Laragon to Windows PATH" ile sistem PATH'e eklendi. - PHP `zip` extension (`php.ini` içinde `;extension=zip` → `extension=zip`) açıldı; composer paketleri zip ile indirebilsin. - composer process-timeout 0 (sınırsız) ayarlandı. ### 3. Laravel + Breeze Kurulumu - `composer create-project laravel/laravel cari-takip-web` → Laravel 11 iskelet - `composer require laravel/breeze --dev` → Breeze auth paketi - `php artisan breeze:install react --typescript` → Inertia + React + TypeScript scaffolding - `npm install --legacy-peer-deps` → 237 paket (Vite 8 / @vitejs/plugin-react peer çakışması nedeniyle legacy mode) - `npm install lucide-react axios --legacy-peer-deps` → ikonlar + HTTP client - `php artisan key:generate` → APP_KEY (eksik olunca login sayfası 500 dönüyordu) ### 4. Veritabanı - `.env` SQLite'a göre yapılandırıldı (DB_CONNECTION=sqlite, DB_DATABASE=database/database.sqlite). - `database/database.sqlite` boş dosya oluşturuldu. - **Tek büyük migration** yazıldı (`2026_05_07_000001_create_cari_takip_schema.php`) — 19 tablo: - roller, yetkiler, user_firma (M:N pivot) - users (alter: rol_id, kullanici_adi, aktif, son_giris) - firmalar - cari_kategorileri, cariler - kasalar - hareket_turleri, hareketler - personeller, mesai_kayitlari - odeme_turleri, personel_odemeleri - belgeler (polymorphic), doviz_kurlari - ozel_alanlar, ozel_alan_degerleri (kullanıcı tanımlı kolonlar) - ayarlar, sistem_loglari - Tablo isimleri Türkçe (firmalar, cariler, hareketler), kolon isimleri snake_case Türkçe (firma_id, cari_kodu, vergi_no). ### 5. Eloquent Models - `User`, `Rol`, `Yetki`, `Firma`, `Cari`, `CariKategori`, `Kasa`, `HareketTuru`, `Hareket`, `Personel`, `MesaiKaydi`, `OdemeTuru`, `PersonelOdeme`. - Relations: HasMany, BelongsTo, BelongsToMany. - Business logic methods: `Cari::bakiyeTL()`, `Kasa::bakiye()`, `Personel::donemKazanci()`, `Personel::netBorc()`, `User::yetkiKontrol()`. ### 6. Seeder (`DatabaseSeeder.php`) - Default roller: Admin, Muhasebe, Görüntüleyici (yetki matrisi ile). - Default admin kullanıcı: `admin@cari.local` / `admin123` (kullanıcı adı: admin). - Örnek firma: "Örnek Şirket A.Ş.". - Default cari kategorileri (Müşteri/Tedarikçi/Personel/Banka/Diğer). - Default hareket türleri (Tahsilat/Ödeme/Fatura Kesildi/Geldi/Çek Tahsilatı/Masraf/Personel Ödemesi). - Default ödeme türleri (Maaş/Avans/Mesai/Prim/SGK/İkramiye). ### 7. Modern UI — AppLayout.tsx - Sol panel: koyu lacivert (`bg-slate-900`), 9 menü maddesi, lucide-react ikonlar. - Aktif menü: `bg-blue-600 text-white`. - Üst bar: beyaz arka plan, sticky header, kullanıcı profili dropdown'u. - Sağ alt köşede oturum kullanıcı avatarı + isim/email. - Mobile responsive: sidebar sürgülü, hamburger menu. - Flash message'lar yeşil bantta gösterilir. ### 8. Dashboard.tsx — Modern Kart Widget'lar - **4 ana kart:** Toplam Alacak / Toplam Borç / Bu Ay Tahsilat / Bu Ay Ödeme — her biri farklı renk + lucide ikon. - **Kasa Bakiyeleri tablosu** (responsive). - **Son 10 Hareket listesi.** - **3 Hızlı Erişim kartı:** + Yeni Cari / + Yeni Hareket / + Yeni Kasa (dashed border, hover effect). ### 9. Cari Modülü Vertical Slice (TAM) - `CariController.php`: index/create/store/edit/update/destroy. Yetki kontrolü + firma izolasyonu (kullanıcı sadece kendi firmasının cari'lerini görür). - `Cari/Index.tsx`: arama + kategori filtre + 7 kolonlu tablo + sayfalama + Düzenle/Sil ikon butonları + boş hal mesajı. - `Cari/Form.tsx`: 2 panel (Genel + Vergi/İletişim) + bakiye özeti panel (sadece düzenleme modu). - Otomatik cari kodu üretimi (`120.001`, `120.002` formatında). - Cari silme: hareket varsa pasif yapılır (soft), yoksa silinir (hard). ### 10. Format Helpers (`resources/js/lib/format.ts`) - `paraFormat(value, currency)`: Intl.NumberFormat ile TR locale. - `tarihFormat(d)`, `tarihFormatUzun(d)`: TR locale tarih. **Eklenen/Değişen Dosyalar:** - `app/Http/Controllers/CariController.php`, `DashboardController.php` - `app/Models/User.php` (override), `Rol.php`, `Yetki.php`, `Firma.php`, `CariKategori.php`, `Cari.php`, `Kasa.php`, `HareketTuru.php`, `Hareket.php`, `Personel.php`, `MesaiKaydi.php`, `OdemeTuru.php`, `PersonelOdeme.php` - `database/migrations/2026_05_07_000001_create_cari_takip_schema.php` - `database/seeders/DatabaseSeeder.php` - `resources/js/Layouts/AppLayout.tsx` - `resources/js/Pages/Dashboard.tsx` - `resources/js/Pages/Cari/Index.tsx`, `Form.tsx` - `resources/js/lib/format.ts` - `resources/js/bootstrap.ts` (eksikti, axios konfigürasyonu) - `routes/web.php` - `.env` (SQLite, APP_NAME) **Bilinen Kısıtlar / TODO (Sıradaki İterasyonlar):** - **Faz 1 / Iter-2:** Kasa modülü (Controller + Index + Form), Hareket modülü. - **Faz 1 / Iter-3:** Personel modülü (liste + detay + mesai + ödeme — kasa ile entegre). - **Faz 1 / Iter-4:** Firma yönetimi, Kullanıcı yönetimi, Kategori/Tür yönetimi. - **Faz 2:** Çoklu firma seçim/geçiş (üst bar dropdown), tema toggle (koyu/açık), profil ayarları genişletilmiş. - **Faz 3:** TCMB API entegrasyonu (çoklu para birimi otomatik kur), belge ekleme, kullanıcı tanımlı özel alanlar. - **Faz 4:** Recharts ile gerçek dashboard grafikleri, raporlar (cari ekstresi, kasa raporu, maaş bordrosu PDF), Excel export. - **Faz 5:** Production deployment — cPanel ortamına taşıma talimatı (.env'i prod'a uygunlaştırma, MySQL'e geçiş migration, public_html ayarları). **Test Notu:** - Server: `php artisan serve` — http://127.0.0.1:8000 - Login: admin@cari.local / admin123 - Test akışı: Login → Dashboard (kart widget'lar görünür) → soldan "Cariler" → Yeni Cari ekle → liste güncellenir → düzenle/sil → Dashboard'da değişiklikler yansır. - Tüm Türkçe karakterler (Ç, Ğ, İ, Ö, Ş, Ü) doğru render edilir. --- --- ## 2026-05-07 — [Faz 1 / İterasyon 2] Kasa + Hareket Modülleri **Yapılanlar:** ### Git - Initial commit yapıldı (admin@cari.local — Elitnet, "Faz 1 / Iter-1" mesajı). - Local git config: user.email=elitseo59@gmail.com, user.name=Elitnet. ### Kasa Modülü (Tam Vertical Slice) - `KasaController.php` — index/create/store/edit/update/destroy + firma izolasyonu + soft/hard delete (hareket varsa pasif). - `Pages/Kasa/Index.tsx` — **kart tabanlı görünüm** (tablo değil, daha modern): - Üstte 3 kart: TRY/USD/EUR toplam bakiyeler. - Her kasa için kart: tip ikonu (Wallet/Landmark/CreditCard), ad, tip, para birimi, **güncel bakiye** (büyük, renkli), açılış bakiyesi, açıklama, Düzenle/Sil butonları. - Boş hal: dashed border içinde call-to-action. - `Pages/Kasa/Form.tsx` — Ad/Tip/Para Birimi/Açılış Bakiyesi/Açıklama + güncel bakiye özeti (sadece düzenleme). ### Hareket Modülü (Tam Vertical Slice) - `HareketController.php` — kasa/cari/tarih filtresi, `tutar_tl` otomatik hesaplama (kur × tutar). - `Pages/Hareket/Index.tsx`: - **5 kolonlu filtre bar** (tarih başlangıç/bitiş, cari, kasa) — default bu ay. - **3 kart özet:** kayıt sayısı, net TL (alacak − borç), tarih aralığı. - 8 kolonlu tablo: Tarih, Tür (renkli pill: Alacak yeşil, Borç kırmızı), Cari, Kasa, Belge No, Tutar, TL Karşılığı (ön işaretli), İşlem ikonları. - Sayfalama (50 kayıt/sayfa). - `Pages/Hareket/Form.tsx`: - Tarih + Tür + Kasa + Cari (opsiyonel) + Tutar + Para Birimi + Kur + Belge No + Açıklama. - **Canlı TL hesabı**: tutar × kur reaktif olarak alt panelde gösterilir. - TRY seçilince kur otomatik 1 ve disabled. - Tür yön'üne göre özet panelin rengi değişir (Alacak yeşil, Borç kırmızı). ### Routes - `routes/web.php` üç resource controller: cariler, kasalar, hareketler — auth middleware altında. ### Build - `npm run build` başarılı — yeni Kasa/Hareket page'leri için ek bundle'lar oluştu. - `php artisan serve` ayakta, http://127.0.0.1:8000 — HTTP 200. **Eklenen Dosyalar:** - `app/Http/Controllers/KasaController.php` - `app/Http/Controllers/HareketController.php` - `resources/js/Pages/Kasa/Index.tsx`, `Form.tsx` - `resources/js/Pages/Hareket/Index.tsx`, `Form.tsx` **Bilinen Kısıtlar:** - Kasalar arası transfer (bir kasadan diğerine para aktarma) henüz yok — Iter-3'te transfer modu eklenebilir. - Hareket kaydı silindiğinde sadece soft delete uyarısı yok; bağlı PersonelOdeme/Belge kayıtları varsa nullOnDelete tetiklenir. - Hareket düzenleme'de optimistic concurrency yok (Excel'de RowVersion vardı, web'de gerek görülmedi — iki kullanıcı aynı kaydı eş zamanlı düzenlemiyor). **Test Notu:** - Login → Cariler → cari ekle → Kasalar → kasa ekle (TL açılış 10.000) → Hareketler → tahsilat gir (cariden) → kasa bakiyesi otomatik güncellenir → cari bakiyesi güncellenir → Dashboard'a dön → kart değerleri yansır. --- --- ## 2026-05-07 — [Faz 1 / İterasyon 3] Personel Modülü (Mesai + Ödeme + Kasa Entegre) **Yapılanlar:** ### 3 Yeni Controller - `PersonelController.php` — index/create/store/edit/update/destroy + arama. Liste'de her personel için `netBorc()` hesaplanır (toplam mesai kazancı − toplam ödeme). - `MesaiController.php` — bir personel için mesai listesi (tarih aralığı), ekleme, silme. Dönem özetinde çarpanlı toplam saat ve kazanç hesaplanır. - `PersonelOdemeController.php` — **Kasa entegre transaction**: ödeme yapılınca aynı anda hem `personel_odemeleri`'ne hem `hareketler`'e (Yön=Borc, Tür="Personel Ödemesi" otomatik oluşur) yazılır. Silindiğinde bağlı kasa hareketi de DB::transaction içinde silinir. ### 4 Yeni Inertia Page - `Personel/Index.tsx` — arama + tablo (Net Borç sütunu renkli), her satırda 4 ikon buton: Mesai (saat ikonu), Ödeme (cüzdan), Düzenle, Sil. - `Personel/Form.tsx` — 3 panel (Kişisel + Ücret + İletişim) + Net Bakiye kartı (sadece düzenleme). - `Personel/MesaiYonet.tsx` — üstte personel kartı + tarih filtresi + 2 özet kart (çarpanlı toplam saat, dönem kazancı). Mavi panelde **inline yeni mesai formu** (tarih + 4 saat alanı + açıklama). Tablo: 4 saat türü ayrı kolonlarda + çarpanlı toplam. - `Personel/OdemeYonet.tsx` — üstte personel kartı + Net Borç (sağ üst). Tarih filtresi + 2 özet kart. Yeşil panelde **inline yeni ödeme formu** (tarih, kasa, tutar, ödeme türü, dönem, açıklama). Uyarı bandı: "kasaya borç hareketi olarak da işlenir". "+" butonu ile yeni ödeme türü prompt ile eklenir. ### Routes - `personeller` resource (index/create/store/edit/update/destroy). - `personeller/{personel}/mesai` (GET/POST) + delete. - `personeller/{personel}/odeme` (GET/POST) + delete. - `odeme-turleri` (POST) — yeni ödeme türü hızlı ekleme. ### Test Senaryosu (uçtan uca) 1. Login → Personeller → Yeni Personel: "Ahmet Yılmaz", saatlik 100 TL, günlük 8 saat. 2. Listede satırda Mesai ikonuna tıkla → Mesai Yönetimi açılır. 3. Mavi formdan: Bugün için 8 normal + 2 fazla mesai gir → Kaydet → liste güncellenir, dönem özeti: çarpanlı 11 saat, kazanç 1.100 TL. 4. Personeller → Ödeme ikonu → Ödeme Yönetimi. 5. Yeşil formdan: Merkez Kasa, 500 TL, "Avans" türü → Öde → kayıt eklenir, **Hareketler ekranında otomatik bir 'Personel Ödemesi' (Borç) hareketi oluşur**, **Merkez Kasa bakiyesi 500 TL düşer**. 6. Geri Personeller → Net Borç sütununda 600 TL ödenecek (1.100 kazanç − 500 ödeme). **Eklenen Dosyalar:** - `app/Http/Controllers/PersonelController.php` - `app/Http/Controllers/MesaiController.php` - `app/Http/Controllers/PersonelOdemeController.php` - `resources/js/Pages/Personel/Index.tsx`, `Form.tsx`, `MesaiYonet.tsx`, `OdemeYonet.tsx` **Bilinen Kısıtlar:** - Personel ödemesi sadece TL bazlı (TutarTL = Tutar). Personel para birimi farklıysa kur dönüşümü Faz 3'te. - Personel düzenleme'de mesai/ödeme listesi yok — ayrı sayfalar (Mesai/Ödeme ikon butonları). - Ödeme türü silme arayüzü yok — Iter-4 (Kategori/Tür yönetimi) ile gelecek. --- --- ## 2026-05-07 — [Faz 1 / İterasyon 4] Modern Bileşenler + Tam Türkçeleştirme **Yapılanlar:** ### Modern UI Bileşenleri - **`Components/Select.tsx`** — Headless UI Listbox tabanlı, native `` öğesini tetikliyor, ara pencere yok. * **Liste alanı bırakma bölgesi oldu.** Dosya sürüklenince alan mavi kesikli çerçeveli bir kaplamaya döner. İki incelik: - `dragenter/dragleave` alt elemanlarda da tetiklenir; tek boolean ile izlenirse imleç satırlar üzerinde gezerken kaplama titrer. **Derinlik sayacı** kullanıldı, yalnızca alandan gerçekten çıkılınca sıfırlanıyor. - Kaplama `pointer-events-none`; aksi hâlde kendisi `dragleave` üretip kendi kendini kapatır. - Yalnızca `dataTransfer.types` içinde `Files` varsa tepki verilir (metin/eleman sürüklemesinde kaplama açılmaz). * Yükleme yine arka plan merkezine devrediliyor; tamamlanma olayı ve "hiçbir dosya yüklenmediyse tazeleme" davranışı sayfaya taşındı. * **Bilgilendirme modalı güncellendi** (`modulBilgi.ts` → `dosya_yonetici`): yeni "Dosya yükleme" bölümü (sürükle-bırak, `+` davranışı, 10 dosya / 1 GB, arka plan yükleme, sağ alt gösterge, 3'lü eşzamanlılık), "Nasıl kullanılır" bölümüne tıklama→kayıt penceresi ve "Dosya bulunamadı" işareti eklendi, uyarılara hata satırı davranışı ve sunucu limiti notu yazıldı. NOT: Bundan sonra her modül değişikliğinde bilgilendirme modalı da güncellenecek (kullanıcı kesin zorunluluk olarak belirtti). ### Silme sonrası çift bildirim Tek bir dosya silmede birden fazla "silindi" mesajı çıkıyordu. Sebep **iki ayrı kaynak**tı: 1. Sunucu: `destroy()` / `topluSil()` → `back()->with('success', 'Dosya silindi.')` → `ToasterContainer` flash'ı bildirime çeviriyor. 2. İstemci: `router.delete(..., { onSuccess: () => Toaster.basari('Dosya silindi') })` **Düzeltme (Dosya Yöneticisi):** istemci tarafındaki elle toast kaldırıldı. Sunucu mesajı hem garanti hem daha doğru — toplu silmede gerçek adedi içeriyor ("3 dosya silindi."). `topluSil`'in `onSuccess`'i yalnızca seçimi temizliyor. **Emniyet supabı (genel):** aynı desen kod tabanında **69 yerde** var; hepsini tek tek denetlemek, sunucusu flash basmayan bir uç varsa bildirimi tamamen yok etme riski taşıyor. Bu yüzden `ToasterContainer.ekle()` içine dar pencereli tekrar koruması eklendi: aynı tip + normalleştirilmiş metin (sondaki noktalama/boşluk atılır, Türkçe küçük harfe çevrilir) **800 ms** içinde ikinci kez gelirse gösterilmez. Pencere kasıtlı olarak dar — çift bildirim aynı yanıt döngüsünde ~50 ms içinde oluşur; kullanıcının onay penceresinden geçip aynı işlemi bu sürede tekrarlaması mümkün değil, yani meşru tekrarlar bastırılmıyor. Bilgilendirme modalı: `dosya_yonetici` metni bildirim davranışını anlatmıyor, kullanıcıya görünen bir akış/sınır değişmedi — güncelleme gerekmedi. ### Para Birimleri — ekleme artık düzenlemeyle AYNI form Ekleme modalı hâlâ 4 alanlık (kod/sembol/ad/sıra) sade formdu; varsayılan işareti, TCMB kodu, kur tipi, kâr marjı ve otomatik güncelleme yalnızca kayıt oluştuktan SONRA girilebiliyordu. Kök neden: `yeniEkle` → `modulModal.ac('parabirimi','yeni')` çağırıyor, sağlayıcı da `_FormModal`'ı (sade form) mount ediyordu. Oysa `AyarModal` (düzenleme modalı) `pb === 'yeni'` modunu **zaten destekliyordu** ve o modda Notlar'ı gizliyordu — istenen form mevcuttu, sadece ekleme yolu ona bağlı değildi. * `yeniEkle` → `setDuzenle('yeni')`: ekleme ve düzenleme tek form. Sidebar'ın `?yeni=1` bağlantısı da aynı yolu kullandığı için o giriş de düzeldi. * **"Kaydet ve Yeni"** eskiden `ac('parabirimi','yeni')` ile üstte sade modalı açıyordu (yani ikinci kayıt yine eksik formla giriliyordu). Artık ekleme modunda form yerinde sıfırlanıyor, düzenleme modunda sayfa `onYeniDevam` ile modalı ekleme moduna alıyor. Başlangıç değerleri tek kaynakta: `BOS_PARA_BIRIMI`. * **TCMB canlı listesi "+"** de sade modalı açıyordu. Artık ekleme modundaysa AÇIK OLAN formu dolduruyor (üste ikinci modal açmak gereksizdi); düzenleme modundaysa seçimi saklayıp ekleme moduna geçiriyor, form açılışta okuyor. * `_FormModal.tsx` içeriği yönlendirmeye indirildi. Artık onu çağıran yok, ama sağlayıcıda `parabirimi` anahtarı kayıtlı; dosyayı silmek yerine `/para-birimleri/?yeni=1` yönlendirmesi bırakıldı ki ileride bir yol oraya düşerse kullanıcı eski/eksik formu değil doğru sayfayı görsün. * Ölü kalan `useModulModal` tanımları (sayfa + AyarModal) kaldırıldı. **Bilgilendirme modalı güncellendi** (bu sayfanınki `modulBilgi.ts`'de değil, Index içinde gömülü): ekleme-düzenleme aynı form ve Notlar'ın neden gizli olduğu, TCMB listesinden forma dolgu, "Kaydet ve Yeni" davranışı yazıldı. ### Para Birimi ekleme modalında sağdaki boşluk Modal üç sütun: Detay + Notlar (%25) + TCMB (%25). Detay sütunu ekleme modunda `md:basis-[70%]`, düzenlemede `md:basis-[50%]` idi. Ekleme modunda Notlar sütunu (`!yeniMi`) gizleniyor, ama bıraktığı **%25'i kimse devralmıyordu**: hiçbir sütunda `grow` yoktu. Toplam 70 + 25 = **%95** kalıyor, sağda %5'lik boş şerit oluşuyordu. Sabit yüzde aritmetiğini düzeltmek yerine (75 yazsak da gelecekte bir sütun daha gizlenince aynı hata döner) Detay sütunu **`md:flex-1`** yapıldı: kalan alanın tamamını emer. Düzenlemede 100−25−25 = %50, eklemede 100−25 = %75 — ikisi de kendiliğinden doğru. Ayrıca üç sütuna da `min-w-0` eklendi (flex öğesinin varsayılan `min-width:auto` değeri uzun içerikte sütunu genişletir — Dosya Yöneticisi'ndeki aynı sınıf hata). ### Kullanıcılar — firma değişikliği sonrası satırın sessizce kaybolması Şikayet: "firma seçimini değiştiriyorum, Firmalar sütunu güncellenmiyor". Okumakla yetinmeyip kontrolcü seviyesinde uçtan uca ölçüldü. İki senaryo: | Senaryo | Kayıt | Liste | |---|---|---| | Aktif firma KORUNUP başka firma eklenir | ✓ doğru | ✓ sütun güncelleniyor | | Aktif firma seçimden ÇIKARILIR | ✓ doğru | ✗ **satır komple düşüyor** | Yani ne kaydetme ne de sütun bozuktu. `kullanicilariCek()` listeyi **aktif firmaya** göre süzüyordu ve bu süzgeç BAKAN kişi sistem admin olsa bile uygulanıyordu. Kullanıcı aktif firmadan çıkarılınca kayıt başarıyla yapılıyor, "Kaydedildi" mesajı çıkıyor, ama satır listeden yok oluyordu — dışarıdan "kaydetmedi / sütun güncellenmedi / hiçbir şey çalışmıyor" olarak görünüyor. Düzeltmeler: 1. **Sistem admin için aktif firma süzgeci kaldırıldı** (`$firmaId > 0 && !$isAdmin`). Sistem admin tüm kullanıcıları yönetir; listesi firma seçiminden bağımsız olmalı. Test: aktif firma çıkarıldıktan sonra satır artık `ZZ Firma B, ZZ Firma C` ile listede görünüyor (önce "BULUNAMADI" idi). 2. **Sistem admin olmayanlar için sessizlik kaldırıldı.** Onlarda süzgeç *doğru* davranış (kullanıcı gerçekten başka firmaya taşındı), ama sebep söylenmiyordu. Kaydetme sonrası, düzenlenen kişi aktif firmada değilse bilgilendirme mesajı çıkıyor: hangi firmadan çıkarıldığı ve neden listede görünmediği yazıyor. **Bilgilendirme modalı güncellendi** (`modulBilgi.ts` → `kullanici`): yeni "Listede kimler görünür" bölümü (admin → tüm kullanıcılar, diğerleri → seçili firma), Firmalar sütununun kaydedince güncellendiği, ve uyarılara aktif firmadan çıkarma durumu eklendi. ## 2026-08-18 — Muhasebe + Stok kaldırıldı, Müşteri/Cari kurgusu başladı ### 1) yonet.php sadeleştirildi 3289 → 212 satır. Tek grup, tek buton: **Tam Deploy**. Ulaşılamaz kalan ~2500 satırlık `case` bloğu ve test-verisi planı da silindi (silinen modüllerin modellerine referans veriyorlardı). Sayfa render testiyle doğrulandı: 1 grup, 1 buton. ### 2) Muhasebe ve Stok modülleri tamamen kaldırıldı **Veritabanı** (`2026_08_18_000001_muhasebe_stok_modullerini_kaldir`): 13 tablo (cariler, kasalar, hareketler, urunler, stok_hareketleri, yorum ve tanım tabloları) düşürüldü; `personel_odemeleri.kasa_id/hareket_id` ve `musteriler.cari_id` kolonları kaldırıldı; belge/yetki/log/özel alan satırları temizlendi. `down()` bilinçli olarak boş — geri alma eski modülü diriltirdi. **Kod**: 5 controller, 13 model, 5 sayfa klasörü, 7 rapor ekranı, 7 migration, 3 seeder ve 2 konsol komutu silindi. Referans temizliği: Moduller, Permissions, routes, AuditObserver, AlanEtiketleri, AktiviteLog, Ara, Belge, Dashboard, Gorev, Kategori, Musteri, PersonelOdeme, Rapor, DosyaYonetici + frontend (ModulModalProvider, AsyncSelect, GenelArama, GorevFormModal, Dashboard.tsx, modulBilgi.ts). **Davranış değişikliği:** personel ödemesi artık kasa/muhasebe hareketi üretmiyor. **Yol boyunca çıkan latent hata:** `roller_kaldir` migration'ı SQLite'ta `users.rol_id` FK'sını sarkık bırakıyordu ("dropColumn tabloyu yeniden kurar" varsayımı güncel SQLite'ta geçersiz; Laravel yerel `DROP COLUMN` kullanıyor). Bu yüzden SONRAKİ HER kolon düşürme şema doğrulamasında patlıyordu. FK ayrıca düşürülecek şekilde düzeltildi. **Doğrulama:** sıfır veritabanında tüm migration seti baştan sona çalıştı; 13 tablonun tamamı yok, 3 bağımlı kolon yok. `route:list` 415 → 336. tsc + build temiz. ### 3) Müşteri/Cari kurgusu — ilk adım * Modül grubu **"Müşteri/Cari Yönetimi"** oldu; yetki grubu "Müşteri/Cari". * `2026_08_18_000002_cariye_ekle_isaretleri`: teklifler / yenileme_kayitlari / projeler / servisler tablolarına `muhasebelestir` + `muhasebelestirme_tarihi` ve firma+bayrak indeksi. * **`CariKaynaklari`** (tek tanım): hangi parasal modülün tutarı nereden okunur. Yeni parasal modül eklenince sadece buraya satır eklenir. * **`MusteriCariController`**: müşteri bazında alacak özeti + müşteri detayı + ortak `muhasebelestir` ucu. **Ayrı cari tablosu YOK** — tutar kaydın kendisinden okunur, kopyalanmaz; kayıt güncellenince cari kendiliğinden doğru kalır. * Ekranlar: `MusteriCari/Index` (özet + genel toplam), `MusteriCari/Detay` (döküm). * **`CariyeEkleButonu`** ortak bileşeni Teklif/Proje/Yenileme toplu işlem çubuğuna eklendi (Teknik Servis'in tablo ekranında BulkActionBar yok — sırada). * Yetkiler: `musteri_cari.goruntule`, `musteri_cari.muhasebelestir`. * **Bilgilendirme modalı** `musteri_cari` girdisiyle eklendi. ### Düzeltme — sunucuda migrate hatası (MySQL 1091) + kapsam tamamlandı **Hata:** `Can't DROP 'personel_odemeleri_kasa_id_foreign'; check that column/key exists` **Sebep (benim kusurum):** `kolonDusur()` içinde try/catch, `Schema::table()` kapanışının İÇİNDEYDİ. Blueprint komutları kuyruğa alınır ve kapanış bittikten SONRA çalıştırılır; dolayısıyla catch yalnızca "kuyruğa ekleme"yi sarmalıyor, gerçek `ALTER TABLE`'ı değil. FK yoksa MySQL 1091 veriyor ve istisna dışarı kaçıyordu. SQLite'ta hata üretmediği için lokalde görünmemişti. → try/catch `Schema::table()` çağrısının DIŞINA alındı. Migration ilk adımda patladığı için sunucuda hiçbir şey uygulanmadı ve satır `migrations` tablosuna yazılmadı; Tam Deploy tekrar çalıştırıldığında baştan geçer. **Kapsam denetimi (kullanıcı sorusu üzerine):** `musteri_id` taşıyan 9 tablo tarandı. Parasal alanı VEYA fiyatlı satır tablosu olanlar tam olarak dört: teklifler, servisler, projeler, yenileme_kayitlari — dördünde de bayrak var. Diğer beşi (randevular, musteri_sozlesmeleri, musteri_yetkilileri, musteri_yorumlari, sozlesme_imza_davetleri) ne parasal alan ne ürün satırı taşıyor; kapsam dışı olmaları doğru. **Teknik Servis arayüzü tamamlandı:** Tablo ekranında toplu seçim altyapısı (başlık + satır checkbox'ları, IndeterminateCheckbox, BulkActionBar) yoktu, kuruldu ve "Cariye Ekle / Muhasebeleştir" butonu eklendi. Artık dört modülün dördünde de hem bayrak hem buton var. ### Düzeltme 2 — MySQL 1828: FK adı VARSAYILAMAZ **Hata:** `Cannot drop column 'kasa_id': needed in a foreign key constraint 'personel_odemeleri_ibfk_2'` Önceki düzeltme (try/catch'i dışarı almak) doğruydu ama **asıl sorunu maskeledi**. Gerçek sebep: `dropForeign(['kasa_id'])` kısıt adını KURALA GÖRE üretir (`personel_odemeleri_kasa_id_foreign`). Sunucudaki kısıtın adı ise `personel_odemeleri_ibfk_2` — yani MySQL'in kendi verdiği ad. Bu, kısıtın ham SQL ile ya da bir yedekten geri yükleme sırasında oluştuğunu gösterir. Kurala göre üretilen ad bulunamayınca kısıt yerinde kalıyor, ardından kolon 1828 ile düşmüyordu. **Çözüm:** MySQL/MariaDB'de kısıt adı artık VARSAYILMIYOR, `information_schema`'dan okunuyor: kolona bağlı tüm FK'lar gerçek adlarıyla `DROP FOREIGN KEY` ediliyor, ardından kalan indeksler temizleniyor, sonra kolon düşürülüyor. MySQL dışı sürücülerde (SQLite) eski kurala-göre yol korunuyor. `roller_kaldir` migration'ı zaten bu deseni kullanıyordu ve sunucuda sorunsuz çalışmıştı; aynı desen buraya taşındı. **Not:** `Schema::disableForeignKeyConstraints()` (FOREIGN_KEY_CHECKS=0) TABLO düşürmeye izin verir ama FK'da kullanılan bir KOLONU düşürmeye izin vermez — bu yüzden açık FK temizliği zorunlu. Sıfır veritabanında (SQLite yolu) doğrulandı. MySQL dalı lokalde çalıştırılamıyor; yerel sürücü sqlite. ### Cari: ayrı bölüm kaldırıldı, müşteri satırından erişim İstek: menüde "Cari Listesi" diye ayrı bir bölüm olmasın; Müşteriler listesinde sözleşme ikonunun yanında o müşterinin carisine geçen bir ikon olsun. * **Sidebar girdisi** ve **toplu cari listesi ekranı** kaldırıldı (`MusteriCari/Index.tsx` silindi, `index()` + `musteriOzetleri()` metotları kontrolcüden çıkarıldı, `musteri-cari.index` rotası kaldırıldı). * **Müşteriler listesine cüzdan ikonu** eklendi — sözleşme ikonunun hemen yanında, `musteri_cari.goruntule` yetkisine bağlı, `/musteri-cari/{id}/` adresine gider. * Cari **detay** ekranı kaldı; geri bağlantısı artık `/musteriler/`, ayrıca bilgilendirme butonu eklendi. * **Sondaki "/" denetimi:** ilgili tüm adresler kanonik — `/musteri-cari/{id}/`, `/musteri-cari/muhasebelestir/`, `/musteriler/`, kayıt bağlantıları `${yol}/`. Rota eşleşmesi ikisi için de fiilen test edildi (POST ve GET, sondaki slash ile doğru rotaya düşüyor). * **Bilgilendirme modalı** güncellendi: bu ekrana Müşteriler listesindeki cüzdan ikonuyla girildiği ve tüm müşterileri toplayan ayrı bir ekran olmadığı yazıldı. ### Kalıntı taraması — `Firma::cariler()` ve diğerleri Bildirilen hata: `Call to undefined method App\Models\Firma::cariler()`. **Neden ilk temizlikte kaçtı:** Eloquent ilişkileri yalnızca `->cariler()` diye çağrılmaz; `withCount(['cariler'])`, `with('kasa')`, `whereHas('hareketler')` gibi **dize** olarak da anılır. Bunlar metot-çağrısı desenine takılmaz ve ancak çalışma anında patlar. `FirmaController::firmalariCek()` tam olarak bunu yapıyordu. **Tahmin yerine tarayıcı:** dize-tabanlı ilişki referansları, silinen sınıflara atıf, controller'larda tanımsız `$this->metot()` ve tanımsız rota adlarını denetleyen bir tarayıcı yazıldı (yansıma + regex). Bulunan ve düzeltilenler: * `FirmaController` — `withCount(['cariler','kasalar',...])` ve `cariler_count/kasalar_count` sıralama kolonları. * `Firma/Index.tsx` — cari/kasa sütunları, `muhasebeAcik` bayrağı, colSpan payı. * `DashboardController`, `RaporController` — ölü `use` satırları. * `Personel/OdemeYonet.tsx` — kasa seçici (`/api/ara/kasalar`), "kasaya borç hareketi işlenir" bandı, tablo Kasa sütunu, `kasa_id` state'i. (Backend'den kasa entegrasyonu kaldırılmıştı, ekran sarkıyordu.) **Duman testi:** 73 GET sayfası gerçek HTTP çekirdeğinden geçirildi. * 3 sayfa hata verdi (`/raporlar/randevu` + pdf/excel) — sebep `CONCAT` fonksiyonunun SQLite'ta olmaması. **Yerel sürücü artefaktı**, sunucu MySQL. * `bildirimler` ve `gorevler` tabloları depodaki hiçbir migration tarafından oluşturulmuyor (önceden var olan eksik; silinen 7 dosyanın hiçbirinde yoktu). Bu yüzden yerelde bu tablolara dokunan sayfalar test edilemiyor. * Kalan sayfaların tamamı açıldı. **Cari mantığı fiilen doğrulandı:** işaretli proje (tutar kolonu 1500) + işaretli teklif (satırlardan 2×250 + 1×100 = 600) → döküm 2 satır, toplam 2.100,00. İşaretsiz teklif (9×9999) dökümde ÇIKMADI. Beklenen = gerçekleşen. ### Raporlar tek çatı altında toplandı Önceden her modülün yan menüsünde ayrı bir "Raporlar" bağlantısı vardı (5 ayrı giriş). Artık tek modül, tek bağlantı, tek sayfa. * **`App\Support\Raporlar`** — tüm raporların TEK tanımı. Her rapor `modul` + `yetki` taşır; bu ikisi rapor rotalarındaki `modul:` + `yetki:` middleware çiftiyle BİREBİR aynıdır. * **`RaporController::index()`** listeyi SUNUCUDA süzer (`Raporlar::gorunur($user, $aktifModuller)`). Kullanıcının açamayacağı rapor ekrana hiç düşmez; düşse bile adres elle yazıldığında middleware engeller. Yetki kuralı tek yerde tutuluyor — istemcide ikinci bir kontrol yok, iki yerde kural tutmak ayrışmaya davetiye olurdu. * **Yan menü:** 5 modüldeki "Raporlar" girdisi kaldırıldı; yeni `raporlar` modülünde tek girdi. Görünürlük ÇOKLU yetki ifadesine bağlı (`musteri.rapor|teklif.rapor|...`) — rapor yetkilerinden en az biri yoksa menüde hiç çıkmaz. * **`User::yetkiKontrol()` çoklu yetki desteği kazandı** (`a|b` → herhangi biri). `yetki:` route middleware'i bu yazımı zaten destekliyordu; aynı sözleşme modele taşındı ki yan menü ve ekranlarda da kullanılabilsin. * Hub ekranı (`Rapor/Index.tsx`) sunucudan gelen listeyi çizer; hiç rapor yoksa sebebini açıklayan bilgilendirici kutu gösterir. **Yetki süzmesi fiilen test edildi** (3 senaryo, beklenen = gerçekleşen): | Kullanıcı | Menü | Görünen rapor | |---|---|---| | Admin | görünür | 6/6 | | Sadece `teklif.rapor` | görünür | 1/6 (yalnızca teklif) | | Hiç rapor yetkisi yok | **gizli** | 0/6 | **Bilgilendirme modalı** `raporlar` girdisiyle eklendi; hangi raporun neden göründüğü/görünmediği açıkça yazıldı. ### Raporlara ortak derinlik katmanı İstek: raporlar mümkün olduğunca ayrıntılı olsun. Altı rapora ayrı ayrı elle metrik eklemek yerine **tek bir analiz katmanı** yazıldı; birinde düzeltilip diğerinde unutulan hesap olmasın. **`App\Support\RaporAnaliz`** — bir rapordan yalnızca "taze sorgu döndüren kapanış" + tarih kolonu (+ varsa tutar kolonu) alır, şunları üretir: * **Önceki dönemle karşılaştırma** — seçili aralıkla AYNI uzunlukta, hemen öncesindeki dönem otomatik hesaplanır. Adet ve tutar için fark + yüzde + yön. Önceki dönem 0 ise yüzde **null** döner ("%∞ artış" yanıltıcı olurdu); arayüz "yeni" yazar. * **Günlük seri** — kayıt olmayan günler 0 ile doldurulur, boşluklar görünür kalır. * **Kümülatif seri** — dönem içi birikim. * **Hafta günü dağılımı** — Pazartesi→Pazar. * **Yoğunluk** — günlük ortalama, dolu/boş gün sayısı, en yoğun gün. * **Tutar istatistikleri** — toplam, ortalama, **medyan**, min, max. Sürücü farkı tek yerde: tarih ifadeleri SQLite (`strftime`) ve MySQL (`DATE_FORMAT`/`DAYOFWEEK`) için ayrı üretilir; hafta günü iki sürücüde de 0=Pazar tabanına getirilir. **Bağlandığı raporlar:** Müşteri, Teklif, Proje (tutar analizi açık — `projeler.tutar`), Görev, Randevu. Frontend'de ortak **`RaporAnalizPaneli`** bileşeni çizer. **Doğrulama (bilinen veriyle, 12 kontrol):** bu dönem 3 proje (100/300/500), önceki dönem 1 proje (200) → adet 3 vs 1 (+2, %200), tutar 900 vs 200 (+700, %350), medyan 300, ortalama 300, min 100, max 500, dolu gün 2, seri 31 gün, kümülatif son 900, hafta günü Pazartesi=2 (3 Ağustos gerçekten Pazartesi). **12/12 doğru.** Duman testi: yeni hata yok; kalan 3 hata önceden bilinen SQLite `CONCAT` eksikliği (sunucu MySQL). Bilgilendirme modalı (`raporlar`) yeni "Her raporda bulunan detay blokları" bölümüyle genişletildi; medyanın neden ortalamadan farklı okunduğu da yazıldı. ### Düzeltme — "0 / 31.999999999988425" ve blok boşlukları **1) Kesirli gün sayısı (benim hatam).** `RaporAnaliz::paket()` içinde `$basC->diffInDays($bitC) + 1` kullanılıyordu. Carbon 3'te `diffInDays()` **float** döner; `$basC` startOfDay, `$bitC` endOfDay olduğu için fark 30,99999… çıkıyor, +1 ile **31,999999999988425** oluyordu. Ekranda "Kayıt olan gün: 0 / 31.999999999988425" olarak görülüyordu. İki tarafı da gün başına sabitleyip `(int)` çevirdikten sonra +1 yapılıyor. Yan etki olarak **önceki dönem sınırı da düzeldi**: 31 günlük Ağustos için önceki dönem 30 Haziran–31 Temmuz yerine artık doğru şekilde 1–31 Temmuz. Farklı uzunluklarda doğrulandı — hepsinde tam sayı: `Ağustos=31`, `tüm yıl=365`, `tek gün=1`, `Şubat=28`. Analiz testinin 12 kontrolü de geçmeye devam ediyor. **2) Blok boşlukları.** Panel, `mb-4` kullanan kardeş blokların arasına **marjsız** giriyordu; bir sonraki bloğa yapışıyordu. Ayrıca alt bloklar (karşılaştırma / yoğunluk / istatistik / grafikler) sayfaya dağılmış gibi duruyordu. → Panel tek bir **"Dönem Analizi"** bölümüne alındı (çerçeve + başlık + dönem etiketi), köke `mb-6` verildi (kardeşler `mb-4`; panel daha yoğun olduğu için bir kademe fazlası), iç ızgara boşlukları kardeşlerle aynı ölçüye (`gap-3`) getirildi ve bölümler arası `space-y-5` yapıldı. `yazdirma-butun` sınıfıyla yazdırmada da bölünmüyor. ### Personel izinleri (zaten mevcut) + bilgilendirme modalından yetki listesi kaldırıldı **1) Personel bazlı izin ekranı ZATEN VAR — yeniden yazılmadı.** Mesai ikonuyla birebir aynı desen kurulu durumda: * Yetki: `personel.izin` (Permissions'ta tanımlı) * İkon: Personel listesinde `CalendarOff`, mesai/ödeme ikonlarının yanında * Rota: `GET personeller/{personel}/izin` → `personel.izin.karti` (+ `izin/ozet`, `izin/hak` uçları) * Ekran: `PersonelIzin/PersonelKarti.tsx` Rota eşleşmesi fiilen test edildi: `/personeller/5/izin/` → `personel.izin.karti`, `/personeller/5/mesai/` → `personel.mesai.index`. Sondaki "/" ile ikisi de doğru rotaya düşüyor. Yeni kod yazmak yerine mevcut yapı doğrulandı. **2) Bilgilendirme modalından "Gereken Yetkiler" bölümü kaldırıldı.** Modal son kullanıcıya modülün ne işe yaradığını anlatıyor; `musteri.rapor` gibi yetki kodları teknik ayrıntı ve orada gürültü yapıyordu. Veri tarafındaki `yetkiler` alanı **korundu** (silinmedi, tipte duruyor) — yalnızca ekranda çizilmiyor. Kullanılmayan `ShieldCheck` import'u da temizlendi. **Bilgilendirme kapsamı (denetlendi):** 28 konu tanımlı, 30 ekran ModulBilgi kullanıyor. Bilgilendirmesi OLMAYAN ekranlar: **Kategori/Index** ve **Ayarlar/Index** (Proje/Index yalnızca yönlendirme yapan bir ara ekran, TeknikServis/Index boş dosya — ikisi de kapsam dışı). Bu iki ekran açık eksik olarak not edildi. ### Bilgilendirme kapsamı tamamlandı Önceki turda açık eksik olarak not ettiğim iki ekrana bilgilendirme modalı eklendi: * **Tanımlamalar** (`Kategori/Index`) — konu `tanimlamalar`. İçerik: tanımların firmaya özel olduğu, sıra ve renk alanlarının nereyi etkilediği, pasife almanın eski kayıtları bozmadığı, silmeden önce bağlı kayıt sayımının gösterildiği ve bağlı kayıt varsa silmenin engellendiği. * **Sistem Ayarları** (`Ayarlar/Index`) — konu `ayarlar`. İçerik: bölümlerin ne yaptığı, sekme değiştirmenin kaydetmediği, e-posta/SMS ayarı sonrası test gönderiminin neden şart olduğu (hatalı ayar sessizce başarısız olur), görsel yüklemede önbellek yenileme, ayarların firma bazlı DEĞİL sistem geneli olduğu. Bu iki ekranda `actions` prop'u hiç yoktu; bilgilendirme butonu için eklendi. **Kapsam denetimi:** 32 ekran ModulBilgi kullanıyor. Bilgilendirmesi olmayan yalnızca iki dosya kaldı ve ikisi de gerçek ekran değil: `Proje/Index` (yalnızca `/projeler/board/` adresine yönlendiren ara ekran) ve `TeknikServis/Index` (boş dosya). **Tarama sonucu:** frontend kalıntı tarayıcısı **0 sorun** — ölü modül adresi yok, `modulBilgi.ts`'te olmayan konu anahtarı yok, tanımsız modal kodu yok. Duman testi: yeni hata yok (kalan 3 hata bilinen SQLite `CONCAT` eksikliği). ### İzinler yan menüden kaldırıldı + "modal sayfaya gitmez" kuralı **1) Personel > İzinler yan menü girdisi kaldırıldı.** İzin artık mesai/ödeme ile aynı desende: personel satırındaki ikondan (`/personeller/{id}/izin/`) açılıyor. Mesai ve ödemenin yan menüde ayrı girdisi yokken izinde olması tutarsızdı. Personel modülü menüsü artık yalnızca "Personeller". **2) YENİ KESİN KURAL — modal, kendi sayfasına giderek açılmaz.** Bir modülün ekle/düzenle modalı kullanıcı HANGİ SAYFADAYSA orada açılmalı. Modal'ı açmak için yönlendirme yapmak yasak: kullanıcı o an bir formu dolduruyorsa sayfa değişince girdiği veri kaybolur. **Bu kuralı ben ihlal etmiştim ve düzeltildi:** `ParaBirimiFormModal`, sağlayıcıdan açıldığında `/para-birimleri/?yeni=1` adresine yönlendiriyordu (iki ayrı form tutmamak için seçilmiş bir kısayoldu, yanlıştı). Doğru çözüm uygulandı: `AyarModal` + `TcmbCanliListe` ayrı dosyaya çıkarıldı (`ParaBirimi/_AyarModal.tsx`, 610 satır). Artık hem liste sayfası hem sağlayıcı AYNI ortak formu render ediyor; modal her sayfada yerinde açılıyor. `Index.tsx` 930 → 368 satıra indi. **Denetim:** `router.visit(...?yeni=1)` deseni kod tabanında **kalmadı**. tsc + build temiz, frontend kalıntı taraması 0 sorun, duman testinde yeni hata yok. Kural kalıcı hafızaya yazıldı (`feedback_modal_sayfaya_gitmez`): yeni modül eklerken modal sağlayıcıya mount edilir, ekle/düzenle formu TEK ortak bileşen olur, yönlendirme ile idare edilmez. ### Derin test verisi üretici İstek: Tanımlamalar ve Sistem Yönetimi grupları HARİÇ tüm sistemlere derin test verisi yükleyen bir buton. **`DerinTestVeriSeeder`** — kapsam: müşteri (+yetkili +iletişim +yorum), müşteri sözleşmesi, personel (+mesai +ödeme +izin), proje (+yorum), randevu, teklif (+ürün kataloğu +satır +yorum), servis (+yedek parça +satır +yorum), yenileme (+ürün +satır +yorum). **Kapsam dışı (bilinçli):** Kullanıcılar, Tanımlamalar, Para Birimleri, Firmalar, Sistem Ayarları, Dosya Yöneticisi, Günlük Kayıtları. Tasarım kararları: * Her kayıt **`TESTVERI`** etiketi taşır; temizlik bu etikete bakar, gerçek veriye asla dokunulmaz. * Kayıtlar **son 12 aya yayılır** — raporlardaki dönem karşılaştırması, günlük seri ve hafta günü dağılımı ancak böyle anlamlı çıkar. * Alt kayıtlar ana kayıtla birlikte üretilir; "boş kabuk" kayıt bırakılmaz. * Bir kısmı **`muhasebelestir`** işaretli üretilir ki müşteri cari listesi dolu gelsin. * Eksik tanım tabloları (durum/statü/tip) gerekiyorsa üretilir (bazıları NOT NULL). * Tablo/kolon yoksa o bölüm sessizce atlanır — şema farkı seeder'ı patlatmaz. Şemaya uyum sırasında düzeltilenler (gerçek kolon adları okunarak): `musteri_yetkilileri` ad+soyad (ad_soyad yok), `musteri_yetkili_iletisim.tip` (tip_kod değil), `mesai_kayitlari` normal_saat+fazla_mesai (calisilan_saat yok), yorum tablolarında metin kolonu `yorum`/`mesaj` değişkenliği, `yenileme_yorumlari.kayit_id`, tanım tablolarında NOT NULL `kod`. **Doğrulama:** tek firmada çalıştırıldı → **1.525 ilişkili kayıt** (müşteri 40, teklif 40 + 134 satır, servis 40 + 113 satır, yenileme 40 + 98 satır, proje 40, randevu 40, personel 13 + 238 mesai + 61 ödeme + 32 izin, sözleşme 20, yorumlar 321, katalog 17). İşlem rollback ile geri alındı. **`yonet.php`:** "🧪 Test Verisi" grubu eklendi — *Yükle*, *Silinecekleri Listele* (kuru çalıştırma) ve *Sil* (onay kutusu şartlı). Sayfa render testiyle doğrulandı: 2 grup, 4 buton. ## 2026-08-19 — Kasa/Banka + Cari Hareket altyapısı (FAZ 1: veri katmanı) İstek: carilere gelen ödeme / giden ödeme / tahsilat girilebilsin; kasa ve banka sistemi olsun. Fatura sonraki aşamada. ### Araştırma sonucu tasarım kararları **1) Kasa ve Banka TEK tabloda (`odeme_araclari`, `tip` alanıyla).** İkisi de "para kabı"; bakiye hesabı, hareket kaydı ve raporlama mantıkları birebir aynı. Ayrı tablo yapmak aynı kodu iki kez yazmak ve zamanla ayrıştırmak olurdu. Bankaya özgü alanlar (banka_adi, sube, hesap_no, iban) nullable olarak aynı satırda; kasada boş kalır. `acilis_bakiye` = sisteme geçmeden önceki devir. **2) `cari_hareketler` — ödeme/tahsilat tarafı.** `yon` muhasebenin temel ayrımı: `alacak` (cari borçlandı) / `borc` (borcu azaldı). `tip` iş dilindeki karşılık: tahsilat, gelen_odeme, giden_odeme. **Yön elle yazılmaz, tipten TÜRETİLİR** (model `saving` kancası) — yanlış yön girilip bakiyenin ters dönmesi mümkün değil. **3) ALACAK TARAFI BU TABLOYA YAZILMAZ.** Teklif/proje/servis/yenileme kayıtları "Cariye Ekle" ile işaretlendiğinde alacak olarak zaten okunuyor (`CariKaynaklari`). Tutarın kopyası burada da dursaydı, kayıt güncellenince iki değer ayrışırdı. Bu tablo yalnızca para hareketidir. **4) Kasa bakiyesi ile cari bakiye AYNI kayıttan türetilir** (`odeme_araci_id`), böylece mutabakat yapısal olarak bozulamaz. Dikkat edilen nokta: cari yönü ile kasa yönü TERSTİR — tahsilat carinin borcunu azaltır ama kasayı ARTIRIR. ### Yapılanlar * `2026_08_19_000001_kasa_banka_cari_hareket` migration (2 tablo + indeksler) * `App\Models\OdemeAraci` — `bakiye` accessor (açılış + giren − çıkan) * `App\Models\CariHareket` — yön türetme + `tutar_tl` otomatik hesabı ### Doğrulama (bilinen veriyle) Kasa açılış 1000, tahsilat +2500, giden ödeme −400 → **3100** ✓ Banka açılış 5000, gelen ödeme +1500 → **6500** ✓ Yönler: tahsilat/gelen_odeme = `borc`, giden_odeme = `alacak` ✓ Cariye ödenen net: 2500 + 1500 − 400 = **3600** ✓ ### SIRADA (bu turda YAPILMADI) Controller + rotalar + yetkiler, Kasalar/Bankalar liste ekranı, cari detayında hareket girişi modalı (kural gereği sayfada açılacak), cari bakiyenin "alacak (işaretli kayıtlar) − ödemeler" olarak birleştirilmesi, modül kaydı ve bilgilendirme modalı.