# Eğitmen, ücretler ve eğitmen ataması — spec

*28.07.2026 · Sets'in tanımı (ofis turu tasarım oturumu) · çatı §5, §105-106, §174, §181, §185, §187, §219; Y-2016 md.7-8, md.13/j; YÖN-2019 md.6*

Bu belge eğitmen dosyasının, eğitmen ücret yapısının ve **eğitmen atama/onay akışının** tek kaynağıdır. Her satır ya Sets'in 28.07.2026 tarihli tanımından ya da referansı verilen mevzuat maddesinden gelir. Kabul kriterleri §10'da, açık kalanlar §11'de; **varsayımla doldurulmuş satır yoktur.**

**Kapsam dışı:** yoklama (çatı §188), sınav notu (§131), tedarikçi teklif tarihçesi (çatı §11 — MVP manuel giriş). Bunlar kendi turlarında yazılır; buradaki kararlar onlara girdi verir.

---

## 1. Eğitmen bir ofis kullanıcısıdır

Eğitmen ayrı bir kimlik alanı değildir — **ofis kullanıcısıdır** ve ofis kimlik alanının auth kurallarına tabidir (`ofis-onyuz-spec.md`). Rol olarak `instructor` taşır ve eğitmen paneli bu rolün gördüğü yüzdür.

⚠ **Eğitmen kaydı, kullanıcı kaydının aynısı değildir.** Kullanıcı "kim giriş yapabilir" sorusunun cevabıdır; eğitmen dosyası mevzuatın sorduğu soruların (hangi belge, ne zamana kadar, kaç kuruluşta) cevabıdır. İkisi bire bir ilişkilidir ama aynı tabloda yaşamazlar: bir eğitmen işten ayrıldığında kullanıcısı pasifleşir (AD-23), mevzuat dosyası **durur** — geçmiş eğitimlerin kim tarafından verildiği sorusu 5 yıl sonra da sorulur.

### 1.1 Kategoriler

Çatı §174: **sürekli · bağımsız-sözleşmeli · proje bazlı.**

| Türkçe | Kod |
|---|---|
| Sürekli | `permanent` |
| Bağımsız-sözleşmeli | `contracted` |
| Proje bazlı | `project_based` |

Kategori iki şeyi belirler: **baz ücretin geldiği tarife** (§4.2) ve raporlamadaki kırılım. Yetki farkı yaratmaz — üçü de aynı eğitmen panelini görür.

### 1.2 Kadro değişikliği bildirimi

Y-2016 md.13/j: eğitici kadrosundaki her değişiklik **15 gün içinde** İdareye bildirilir; aksi hâlde idari para cezası (çatı §219).

Eğitmen işe alım ve ayrılışında sistem **bildirim görevi açar**. ⚠ Görev açar — bildirim *göndermez*. Bildirim KUMS üzerinden insan eliyle yapılır; sistemin işi, yapılması gerektiğini kimsenin unutmayacağı bir yere yazmaktır. 15 günlük süre **admin-tanımlı ayardır** (AD-08), koda gömülmez.

## 2. Eğitmen dosyası — mevzuattan gelen alanlar

Hiçbiri koda sabit yazılmaz; hepsi **eğitim tanımının ve eğitmen kaydının admin-tanımlı alanlarıdır** (AD-27, kırmızı çizgi 14). Mevzuat kaydı bunları madde referanslı **uyarı** olarak hatırlatır.

⚠ **Kaynak sütunu ne dediğini birebir söyler:** `Y-2016` / `YÖN-2019` yazan satırlar `mevzuat/` içindeki resmî metinden doğrulanmıştır; `çatı §…` yazan iki satır (Bakanlık eğitmen onayı, CTU/CSS evrakları) **çatı dokümanından gelir ve madde referansı taşımaz**. İkisini tek cümleyle "mevzuattan doğrulanmıştır" diye toplamak, doğrulanmamış iki satırı doğrulanmış göstermek olurdu.

| Alan | Kaynak | Sistemin işi |
|---|---|---|
| Bakanlık eğitmen onayı + eğitmen ID | çatı §11 | Kayıtta zorunlu alan |
| Eğitici belgesi ve geçerlilik tarihi (5 yıl) | Y-2016 md.7/3 | Bitiş tarihi takip edilir, süresi dolmadan uyarı |
| CTU / CSS ek evrakları | çatı §14 | İlgili eğitim ailesinde evrak zorunluluğu |
| Görev yaptığı yetkilendirilmiş kuruluş sayısı | Y-2016 md.7/5 — **en fazla iki** | Kayıtta kontrol edilir |
| Son eğitim verme tarihi | **Y-2016 md.8/1** — 5 yıllık belge süresinde hiç eğitim faaliyetinde bulunmayanın belgesi yenilenmez, eğitici eğitimine yeniden katılır | Sistem türetir, uyarır |
| Yetkinlik kapıları (CTU Kod, fumigasyon) | YÖN-2019 md.6/4-5 | Eğitim ailesi × eğitmen yetkinliği eşleşmesi |

⚠ **"Son eğitim verme tarihi" hesaplanan bir alandır, girilen değil.** Elle girilebilir bir alan olsaydı, doğruluğu birinin güncellemeyi hatırlamasına bağlı olurdu — ve yanlış olduğu, belge yenilenmediğinde anlaşılırdı.

### 2.1 Dosyadaki hassas veri

Çatı §10 eğitmen kaydına **TCKN, kimlik, ehliyet, SGK sicil numarası** koyar. Bunlar mevzuat alanları değil, kişisel verilerdir ve kendi rejimleri vardır:

- **Şifrelenir** (AD-05) — eğitmen kaydı bu bakımdan katılımcı kaydından farklı değildir
- **Görüntülenmesi erişim loguna yazılır** (AD-21, kırmızı çizgi 13: *hassas kayda dokunan her okuma loglanır*)
- **Maskeli gösterilir** (kırmızı çizgi 13); açık görüntüleme ayrı bir eylemdir ve o eylem loglanır
- Erişim, eğitmen kaydını görme yetkisiyle **aynı şey değildir** — ücret bilgisini görebilen herkesin SGK sicilini görmesi gerekmez

⚠ Bu satırlar spec'e sonradan eklendi: §2'nin ilk hâli mevzuat alanlarını sayıp kişisel verileri hiç anmıyordu. Eğitmen dosyasının tek kaynağı olduğunu iddia eden bir belgenin dosyadaki en korunaklı veriyi atlaması, o verinin korunmasız kalmasının en olağan yoludur.

## 3. Uygunluk — planlamacının görmediği şey

**Karar (Sets, 28.07.2026):** *"eğitmende problem varsa bu planlamacıya kadar gelmemeli… planlamacı sadece ve sadece uygun olan eğitmenleri görebilir ve atayabilir."*

Uygunluk **türetilmiş bir durumdur** ve **eğitimin tarihinde** değerlendirilir — bugünkü tarihte değil. 3 hafta sonraki eğitim için, 2 gün sonra belgesi dolacak eğitmen **uygun değildir** ve listede hiç görünmez.

⚠ Bu, "uyarı gösterip devam ettirmek"ten farklı bir karardır ve bilinçlidir: *"zaten bunları engelleyebilmek için sistem kuruyoruz."* Uygunluk kapısı planlamacıya sorulmaz, uygulanır.

### 3.1 Uygunluğu bozan şeyler

| Bayrak | Kaynak |
|---|---|
| Eğitici belgesinin süresi eğitim tarihinde dolmuş olacak | Y-2016 md.7/3 |
| Belge iptal edilmiş | — |
| İki yetkilendirilmiş kuruluş sınırı aşılmış | Y-2016 md.7/5 |
| **Eğitim ailesinin yetkinlik kapısını taşımıyor** | YÖN-2019 md.6/4-5 |

⛔ **Yetkinlik kapısı uyarı değil, kapıdır.** YÖN-2019 md.6/4-5 *"veremez"* der: CTU Kod eğitmeni olmayan görev 4 ve 11'i, fumigasyon eğitmeni olmayan görev 12'yi veremez. Uygunluk felsefesinin ("planlamacıya sorulmaz, uygulanır") en sert mevzuat kuralını dışarıda bırakması tutarsız olurdu — **yetkinliği eşleşmeyen eğitmen o eğitimin aday listesinde görünmez.**

⚠ Kapının **davranışı** burada tanımlıdır; eğitim ailesi × yetkinlik eşleşmesinin **veri modeli** eğitim tanımı turuna aittir (§11). Model gelene kadar bu kapı çalışmaz — bu bir eksik değil, sıralama; ama kapının varlığı plan aşamasında unutulamaz.

### 3.1.1 Üçüncü kaynak: eğitmenin kendi bildirdiği müsaitlik *(Sets, 30.07.2026)*

Yukarıdaki tablo mevzuatı sayar; §6.5 çakışmayı sayar. Üçüncüsü kişinin kendisidir: **eğitmen çalışamayacağı günleri girer ve o tarihlerde aday listesinde görünmez.**

⚠ Aynı rejim: planlamacıya sorulmaz, uygulanır. Uygunluk felsefesinin ("problem planlamacıya kadar gelmemeli") mantıksal devamıdır — bir eğitmenin izinli olduğunu planlamacının bilip atlaması gereken bir şey yapmak, tam olarak kaçınılan durum.

⛔ **Gerekçe opsiyoneldir ve planlamacıya gösterilmez.** "Neden izinlisin" planlamacının sorusu değildir; listede görünmeyen birinin sebebini göstermek, §6.3'ün yokluğu hiç açıklamama gerekçesiyle çelişirdi.

⚠ **Girilen izin kesinleşmiş atamayı düşürmez.** Kabul ettiği eğitimin üstüne izin giren eğitmen takvimini düzeltiyordur, işi iptal etmiyordur — o yol §6.10'dur ve planlamacıdan geçer. Sessiz düşürme, bir eğitimin eğitmenini kimseye haber vermeden almak olurdu.

⚠ Çakışma **örtüşmeyle** sayılır, kapsamayla değil: izninin son gününde başlayan eğitim veremediği bir eğitimdir.

### 3.2 Sorumluluk nerede

Bir bayrak kalktığı anda eğitmen **atanabilir listesinden çıkar**. Uyarı **Eğitim Direktörü ve Operasyon Direktörünün** önüne düşer, planlamacının değil. Planlamacının işi eğitmen uygunluğunu takip etmek değildir.

### 3.3 Planlanmış eğitimler ne olur

Öngörülebilir kayıp (belge süresinin dolması) zaten planlama anında engellenmiştir — o eğitmen o tarih için hiç listelenmemiştir.

Uyarı yalnız **öngörülemeyen kayıp** için üretilir: belgenin iptal edilmesi, ikinci kuruluş kaydının sonradan açılması (Y-2016 md.7/5). Bu durumda o eğitmenin **gelecekteki kesinleşmiş atamaları** listelenir ve iki direktöre düşer.

## 4. Ücret yapısı

Çatı §185: *"global tarife; eğitmen-özel ücret globali override eder; işlem bazında override edilebilir."* Üç katman aynen korunur. ⚠ Çatının *"teklif/mali ekranda"* ifadesi 28.07.2026'da revize edildi — gerekçesi §4.4'te.

### 4.1 Birim: saatlik veya günlük — eğitmen bazında

Bir eğitmenin ücreti **ya saatlik ya günlük** tanımlanır; hangisi olduğu eğitmenin kendi kaydında seçilir *(Sets, 28.07.2026)*. Sistem ikisini birbirine çevirmeye çalışmaz.

⚠ Çevirmemesinin sebebi fiyatlamadaki 8 saat = 1 gün eşitliğinin (fiyatlama-spec §1) **satış tarafının bandı** olmasıdır; eğitmenle yapılan anlaşma buna uymak zorunda değildir. İkisini tek birime indirmek, sözleşmede yazmayan bir dönüşümü maliyet hesabına sokmak olurdu.

#### Hakediş nasıl hesaplanır *(Sets, 30.07.2026 — netleştirme)*

**Eğitim saati × saat ücreti.** Birim saatlikse doğrudan; günlükse **eğitim günü × günlük ücret**. ⛔ Sistem hâlâ **çevirmez** (§4.1) — çeviren şey, tarifeyi giren kişidir.

⚠ Yarım günleri saatlik birim çözer. Sets'in yaklaşımı: *"onlara direkt olarak günlük eğitmen ücretini saatlik girmelerini söyleyeceğim; böylece 12 saatlik eğitimde 1,5 gün hakediş verme imkânları olur."* Yani günlük ₺9.600 çalışan bir eğitmen saatlik ₺1.200 girer ve 12 saatlik eğitim ₺14.400 = 1,5 gün eder. Bu bir **veri girişi tercihi**, kodda bir dönüşüm değil.

⛔ **Hakedişin dayanağı donar.** Kaydedilen satır *"2 gün × ₺9.500"* ya da *"12 saat × ₺1.200"* olarak dayanağını taşır; tarife sonradan değişince geçmiş hakediş değişmez (AD-11). Türetilen bir rakam, geçen yılın kazancını sessizce yeniden yazardı.

### 4.2 Global tarife kategori bazlıdır

Baz ücret **kategori başına** tanımlanabilir *(Sets, 28.07.2026)* — sürekli, bağımsız-sözleşmeli ve proje bazlı eğitmenin baz ücreti ayrıdır. Backoffice'te *Eğitmen ayarları* sayfası bunları tutar.

### 4.3 Eğitmen-özel override

Eğitmen kaydında ücret alanı boşsa kategori tarifesi geçerlidir; doluysa o geçerlidir. ⚠ Fiyat matrisindeki türetilmiş/ezilmiş ayrımının aynısı (fiyatlama-spec §2.2): **ekran hangisinin hangisi olduğunu göstermek zorundadır**, yoksa tarifeyi değiştirenler kimin etkilendiğini bilemez.

### 4.4 İşlem bazında override — planlamada, satışta değil

Planlamacı bir atamada ücreti tek seferlik değiştirebilir. Bu değişiklik **atamanın üzerinde yaşar**, eğitmen kaydına yazılmaz.

⚠ **Çatı §185 revizyonu (Sets, 28.07.2026).** Çatı bu üçüncü katmanı *"teklif/mali ekranda"* konumlandırıyordu. Yeri **planlamadır**: *"satışçı mevcut ücretlerle oynayamaz, sadece müşteriye indirim tanımlayabilir. Bunun dışındakiler planlamacı ne ayarladıysa o şekilde gelir. Eğer bir revize gerekirse planlamacının yapması gerekir."*

Gerekçe çatı §181'in kendi ayrımıyla aynı: **fiyat satışın, maliyet planlamanın işidir.** Satışçının maliyeti değiştirebilmesi, kâr = fiyat − maliyet denklemini tek elden yazılabilir hâle getirirdi. Satışçı maliyeti **görür** (§8.2), değiştiremez.

## 5. Masraf ayarları

Backoffice'te *Eğitmen ayarları* altında, hepsi admin-tanımlı (AD-08, kırmızı çizgi 9):

- **Km başına destek tutarı**
- **Masraf limitleri** kalem türü başına (çatı §187: "max tutar")
- **Fiş/fatura zorunluluğu** kalem türü başına

Eğitmen kaydında bunların hepsi **override edilebilir** *(Sets, 28.07.2026)* — global ayar tabandır, eğitmenle yapılan anlaşma üstündedir.

⚠ **Km desteği kendi aracına bağlı değildir.** *"Uçakla gitti, araba kiraladı. Burada da km desteği devreye girebilir"* (Sets). Km desteği bağımsız bir kalemdir; hangi ulaşım biçimiyle birlikte kullanılacağına planlamacı karar verir.

## 6. Eğitmen ataması — ihtiyaç, teklif, onay

Bu §, oturumun en büyük kararıdır ve bugünkü tek-eğitmen ihtiyacını da kapsayan **genel model**dir.

### 6.1 Model

```
Eğitim  →  atama isteği (kaç eğitmen)  →  N adaya teklif  →  kabul  →  kesinleşmiş atama
```

⚠ Tek eğitmene sormak bu modelin `N=1` hâlidir. **İki ayrı akış yazılmaz.** Modeli baştan çoklu kurmanın sebebi, sonradan kurmanın tablo değiştirmek anlamına gelmesidir *(Sets, 28.07.2026: "şimdiden bu yapı da hazır olursa rahat ederiz")*.

Kaç eğitmen gerektiğini **planlamacı belirler** (çatı §105: çoklu eğitmen gerektiren durumları belirlemek planlamacının sorumluluğunda).

### 6.2 İki mod — istek bazında seçilir

| Mod | Kod | Ne zaman |
|---|---|---|
| İlk kabul eden alır | `first_accepted` | Acil boşluk, hızlı kapanması gereken plan |
| Kabul edenler arasından seçim | `selection` | Maliyet/deneyim karşılaştırılacaksa |

⚠ **Global ayar değil, istek bazında seçim.** Aynı firma iki durumu da yaşar; birini ayar yapıp diğerini kaybetmemek için mod atama isteğinin kendi alanıdır.

`selection` modunda seçimi **operasyon** yapar ve seçim ekranı kabul edenlerin **maliyetini yan yana gösterir** — seçimin yarısı maliyet kararıdır.

#### `selection` modunun yaşam döngüsü

⚠ İki modun akışı kabul noktasından sonra ayrışır; `selection` için dört soru ayrıca cevaplanır.

| Soru | `first_accepted` | `selection` |
|---|---|---|
| Kontenjanı ne kapatır | Kabul | **Seçim** |
| Kabul edenin durumu | `accepted` → kesinleşmiş atama | `accepted` (kabul etti, henüz seçilmedi) |
| Kabul eden ama seçilmeyen | — | **`not_selected`** — kendi terminal durumu; `withdrawn` değildir, çünkü teklif geri çekilmedi, eğitmen cevap verdi |
| Takvim ne zaman bloke olur | Kabulde | **Seçimde** |

⛔ **Uygunluk ve çakışma `selection` modunda iki kez değerlendirilir** — kabul anında *ve* seçim anında. Arada gün geçer; kabul ederken uygun olan eğitmen seçilirken uygun olmayabilir. Yalnız kabule bakmak, seçimi doğrulanmamış bir veriyle yapmak demektir.

⚠ **Ama iki kontrolün ağırlığı aynı değildir** ve çakışmanın kaynağı her ikisinde de tektir: **kesinleşmiş atamalar.**

| An | Ne yapar |
|---|---|
| **Kabul** | Erken filtre: eğitmenin o tarihlerde **kesinleşmiş** bir ataması varsa kabul reddedilir — yapamayacağı bir işi kabul etmesinin kimseye faydası yok |
| **Seçim** | Bağlayıcı kontrol: aynı bakış tekrarlanır, çünkü arada başka bir eğitim kesinleşmiş olabilir |

⛔ **Başka bir teklifi kabul etmiş olmak çakışma değildir.** Seçim bekleyen bir kabul kimseyi bağlamaz; onu engel saymak *"bekleyen teklif bloklamaz"* kuralının kendisini delerdi (§6.5).

⚠ Kabul eden ama seçilmeyen eğitmene de **haber gider** (§6.8 ile aynı gerekçe) — cevap verip karşılık alamamak, hiç sorulmamaktan kötüdür.

### 6.3 Aday listesi — iki filtre

Liste iki filtrenin kesişimidir:

**1. Kapsam — planlamacının havuzu ya da tümü** *(Sets, 28.07.2026)*. AD-23 zaten kuruyor: *"eğitmen → planlamacı ataması simetriktir: geçici havuz, süreli veya süresiz; süre dolunca otomatik geri çekilir; geri çekilen eğitmenin mevcut planlanmış eğitimleri korunur, yalnız yeni planlama yapılamaz."*

Planlamacı başına **ayar**: kendi havuzundaki eğitmenleri görür, ya da tümünü. Sets'in örneği: *"yarın İzmit ofisi kuruldu, İzmit'in planlamacısı var, İzmit planlamacısına İzmit eğitmen havuzunu verdik."*

⚠ Havuz mekanizması **bu spec'te icat edilmiyor**, AD-23'ün ağacından geliyor. Eğitmen kaydında ağaca paralel ikinci bir "sorumlu" alanı **açılmaz** — "bu eğitmen kimin kapsamında" sorusunun tek cevabı AD-23 kapsam çözümleyicisidir. (§7.8'deki `approve_group` da aynı çözümleyiciyi kullanır.)

**2. Uygunluk** — yalnız **o eğitim tarihinde uygun** eğitmenler (§3). Uygunluk **kabul anında yeniden** değerlendirilir: teklifle kabul arasında bir belge düşmüş olabilir.

### 6.4 Kabul atomiktir

⛔ Kontenjan **veritabanı seviyesinde** kapanır (kilit + kısıt), uygulama katmanındaki bir "doldu mu" kontrolüyle değil.

Gerekçe: `first_accepted` modunda iki eğitmen aynı saniyede kabule basarsa, uygulama katmanı kontrolü ikisini de kabul eder ve iki eğitmen aynı eğitime gider. Bu, ekranın nezaketine bırakılabilecek bir şey değildir.

### 6.5 Bekleyen teklif takvimi bloklamaz, kabul bloklar

Bekleyen teklif eğitmeni meşgul saymaz — aksi hâlde 4 adaya 3 eğitim teklif edildiğinde herkes birbirini kilitler.

**Çakışma, atamayı kesinleştiren eylemde kontrol edilir** — ve o eylem moda göre değişir:

⛔ **Çakışmanın kaynağı tektir: kesinleşmiş atamalar.** Bekleyen teklif de, seçim bekleyen kabul de çakışma üretmez.

| Mod | Kesinleştiren eylem | Kabulde | Seçimde |
|---|---|---|---|
| `first_accepted` | Kabul | **Bağlayıcı** — çakışan kesinleşmiş atama varsa kabul reddedilir (*"bu tarihlerde başka bir eğitime atandınız"*) | — |
| `selection` | Seçim | **Erken filtre** — aynı kontrol; yapamayacağı işi kabul etmesinin faydası yok | **Bağlayıcı** — arada başka eğitim kesinleşmiş olabilir; çakışan eğitmen seçilemez (*"bu eğitmen çakışan bir eğitime atandı"*) |

⚠ **Kural tektir, bağlayıcı olduğu an farklıdır:** takvimi bloklayan şey kesinleşmiş atamadır (§6.2) ve çakışma tam olarak orada doğar. `selection` modunda başka bir kabulü çakışma sebebi saymak, henüz kimseye bağlanmamış bir cevabı blok gibi davranmaya zorlardı — aynı eğitmen üç eğitime aday gösterilebilir ama yalnız birine cevap verebilir hâle gelirdi.

⚠ Bunun bedeli açıktır ve kabul edilmiştir: `selection` modunda bir eğitmen iki eğitimi birden kabul edebilir, ikisine birden **seçilemez**. Seçimi yapan bunu ekranda görür.

⚠ Planlamacı ekranı **bekleyen ile kesinleşmişi ayırt eder** — neyin kesin neyin askıda olduğu görünmeden plan yapılamaz.

### 6.6 Herkes onaylar

**Üç kategori de onaylar** *(Sets, 28.07.2026)*, kadrolu dahil. Gerekçe Sets'in kendi ifadesiyle iki başlıklı: *"hem bizim elimizde kayıt olsun hem de daha bildirmediği acil bir durumu çıkmış olabilir, reddeder böylece biz gereksiz bekleme durumunda kalmayız."*

Kadrolu eğitmen için onay, işi sorgulatmak değildir — **haber verilmemiş bir durumun ortaya çıktığı andır**. Ret bir bilgi kaynağıdır, engel değil.

**Redde gerekçe zorunludur.** Gerekçesiz ret yalnız bir boşluktur; gerekçeli ret operasyonun gördüğü sinyaldir (aynı eğitmenin üçüncü kez aynı sebeple reddetmesi ancak böyle görünür).

### 6.7 Cevapsızlık — asıl tehlike bu

Ret hemen bilinir; **cevapsızlık bilinmez.** Planlamacı eğitimin kapandığını sanar ve eğitim günü öğrenir. Çoklu teklifte daha da kritiktir: 4 adaydan 3'ü susarsa kontenjan hiç dolmaz.

- **Süre:** varsayılan **3 iş günü**; **planlamacı istek bazında değiştirebilir** *(Sets, 28.07.2026)*. Varsayılan admin ayarıdır (AD-08), planlamacının girdiği değer o isteğin üzerinde yaşar.
- **Yükseltme:** süre dolunca **Eğitim Direktörü + Operasyon Direktörüne** düşer, planlamacıya değil — çözüm (başka eğitmen, tarih değişikliği) planlamacının üstündedir

⚠ **Süre her teklifin kendi gönderim anından işler.** Adaylara teklif farklı zamanlarda gidebilir; tek bir istek-seviyesi sayaç, geç eklenen adayı haksız yere geçmiş sayardı.

⛔ **"İş günü" diye bir hesap yok; süreler TAKVİM GÜNÜ sayılır** *(Sets, 18.08.2026 — EGT-43 Won't fix)*. Bu bir uygulama borcu olarak duruyordu; borç ödenmedi, **kalem iptal edildi**: *"resmî böyle bir liste yok, böyle bir yapıya ihtiyacımız da yok. Lojistik sektörü 7/24/365 çalışan bir sektör zaten; tatil günü ise o gün kendileri ayarlarlar iş akışlarını."* Yani buradaki "3 iş günü" **3 takvim günü** demektir; hafta sonu da atlanmaz. Aynı karar AD-23 onay eskalasyonu ve bakanlık bildirim süreleri için de geçerlidir.

#### Tüm adaylar reddederse

**Alert düşer** *(Sets, 28.07.2026)*: *"tüm adaylar reddetti."* Atama isteği `escalated` olur.

⚠ **Sonrası sistemin işi değildir.** Tarih değiştirerek, başka eğitmen deneyerek, dışarıdan sözleşmeli eğitmen bularak — bu bir ofis içi işleyiş kararıdır. Sistemin görevi durumu görünür kılmak; çözümü dayatmak değil.

### 6.8 Kaybedenlere haber gider — otomatik ve hemen

Kontenjan dolduğu anda açık kalan teklifler kapanır (`withdrawn`) ve **bildirim gider**.

⚠ *"Kabul ettim, sonra sessizlik"* bağımsız eğitmeni kaybetmenin en hızlı yoludur.

### 6.9 Kabul bir bilgi kapısıdır

Kabul edilene kadar eğitmen **kararını verebilecek kadarını görür, fazlasını görmez.**

| Kabul öncesi | Kabul sonrası |
|---|---|
| Eğitim adı ve kapsamı, tarih, yer, süre, kendi ücreti | Otel, bilet, ulaşım bilgileri · eğitim dokümanları · **katılımcı listesi** |

⛔ **Katılımcı listesi kabul sonrasıdır.** Katılımcı adı, kurumu ve kimlik bilgisi müşterinin kişisel verisidir; *"kabul etmemiş bir eğitmenin müşterinin verisini görmesi için hiçbir sebep yok"* gerekçesi doküman için neyse katılımcı için de odur. Kabul öncesi yalnız **katılımcı sayısı** görünür — kararı vermek için gereken budur.

Erişim AD-21 kapsamında loglanır (kırmızı çizgi 13: hassas kayda dokunan her okuma).

### 6.10 Esaslı değişiklikte onay yenilenir

Kabul sonrası eğitimin **tarihi kayarsa veya yeri değişirse** onay yeniden istenir.

⛔ Aksi hâlde elimizde, eğitmenin kabul etmediği bir işe *"kabul etti"* diyen bir kayıt kalır — bu, kaydın hiç olmamasından kötüdür. Kabul, imzalı bir taahhüt niteliğindedir (özellikle `contracted` ve `project_based` için) ve neyin kabul edildiği kaydın parçasıdır.

**Esaslı değişiklik tanımı admin-tanımlı değildir, kural olarak sabittir:** eğitim tarihi ve eğitim yeri. Bunlar dışındaki değişiklik onayı düşürmez.

#### Yenileme penceresinde ne olur

| Soru | Cevap |
|---|---|
| Atama kesinleşmiş sayılır mı | **Hayır** — durum `reconfirming`. Eğitim §6.11 anlamında satılabilir olmaktan çıkar |
| Takvim bloğu sürer mi | **Evet** — eğitmenin takvimi tutulmaya devam eder; blok düşerse yerine başkası girer ve eğitmen onaylarsa iki eğitime birden bağlanmış olur |
| Cevapsızlık süresi işler mi | **Evet**, §6.7 aynen — yükseltme de aynı |
| Eğitmen reddederse | Atama **düşer**, §6.7'nin yükseltmesi devreye girer |

⛔ **Eğitim satılmış / müşteri onaylamışken eğitmen yenilemeyi reddederse bu bir ALERT'tir**, sıradan bir boşluk değil: müşteriye taahhüt edilmiş bir eğitimin eğitmeni yoktur. Operasyon Direktörü + Eğitim Direktörü + **satış** bilgilendirilir — satışın haberi olmadan müşteriye söz verilmiş bir tarih savunulamaz.

⚠ Bu, tarih/yer değişikliğinin **maliyeti** olduğu anlamına gelir ve bilinçlidir: değişiklik ucuz görünmemelidir.

### 6.11 Satılabilirlik

⛔ **Atama kesinleşmeden eğitim satılabilir hâle gelmez.** Çatı §106/3 zaten *"planlama yapılmadan teklif süreci başlamaz"* diyor; çoklu teklif bunu somutlaştırıyor: adayların ücretleri farklıysa planlanan maliyet kabule kadar bir **aralıktır**, ve aralık üzerinden teklif verilmez.

Planlamacı ekranındaki durum bunu açıkça söyler: *"2 kişi bekleniyor, 1 kesinleşti."*

### 6.12 Durum sözlüğü

Atama isteği: `open` · `filled` · `escalated` · `cancelled`
Teklif: `pending` · `accepted` · `not_selected` · `declined` · `expired` · `withdrawn`
Kesinleşmiş atama: `confirmed` · `reconfirming` · `cancelled`

⚠ Kesinleşmiş atama **hard delete edilmez** (AD-11, kırmızı çizgi 12); iptal edilir, gerekçesiyle. Kabul/ret/iptal olayları audit'lenir (AD-06) — kabul, taahhüt kaydı olduğu için zaman damgası ve kimlik taşır.

### 6.13 Görüşme uygulama içindedir, mailde değil

**Karar (Sets, 28.07.2026):** *"eğitmenler ile görüşmeler in-app gerçekleşecek… mail ile maksimum bildirim gidebilir."*

Eğitmen bildirimi alır, **panele girer**: takvimini, yeri, eğitimi, kendi ücretini görür ve orada kabul eder ya da reddeder.

⚠ Bu bir tercih değil, **kabulün delil değerinin şartıdır.** AD-20'nin birinci güvenlik sınırı zaten *"gelen mail doğrulanmamış içeriktir; hiçbir iş aksiyonunu otomatik tetiklemez"* diyor ve müşteri teklif onayında aynı karar verilmişti (AD-14: onay yalnız panelden). Mailden gelen bir *"kabul ediyorum"* atamayı kesinleştiremez — kimliği doğrulanmamıştır ve neyin kabul edildiği kayıtta değildir.

Mail yalnız **çağırır**: *"size bir eğitim teklifi var."*

### 6.14 Evrak görevini operasyon başlatır *(Sets, 30.07.2026)*

⛔ **Eğitmen kaydı açıldığında sahibinin yüklemesi gereken evraklar görev olarak düşer** ve operasyon sonradan da isteyebilir. Bu bir kolaylık değil, dosyanın var olma şartıdır: Y-2016 md.13/j kadro değişikliğini 15 gün içinde bildirmeyi ister ve hiç istenmemiş evrakla o bildirim hazırlanamaz.

⚠ Görev **sahibine** düşer, operasyona değil. Operasyonun listesindeki bir görev "birini kovala" demektir; kâğıdı borçlu olan kişiye düşen görev işin kendisidir.

⚠ Aynı evrak iki kez istenirse ikinci görev açılmaz. Bir operatörün tekrar basması işlemsizdir, birinin listesinde iki özdeş satır değil.

⚠ **Dosyayı okumak ile evrak istemek ayrı izinlerdir** (`instructor.view`, `instructor.request_documents`): ilki rutin, ikincisi başkasına iş çıkarır.

⛔ Eğitmenin **kendi paneli hiçbir izne bağlı değildir**. Orada gördüğü her şey kendi kaydıdır ve sahiplik o soruyu zaten cevaplamıştır; ayrıca bir izin, yanlış kişiye verildiği gün kazanan cevap olurdu. Eğitmen kaydı olmayan panelde **404** görür — 403 değil, çünkü o ekranlar onun için yoktur.

---

## 7. Planlama maliyet kalemleri

**Karar (Sets, 28.07.2026):** *"planlamacı planlamayı yaparken kalemleri ekler, ulaşım, araç kiralama, km desteği, konaklama diye kalem kalem ekler. satışçıda toplam maliyeti görmüş olur böylece."*

- Maliyet kalemleri **eklenebilir**; sabit bir form alanı seti değil
- Kalem türleri **kontrollü sözlükten** gelir (admin-tanımlı liste, AD-08) — serbest metin değil, çünkü *"hangi alanlarda ek sorunla karşılaşıyoruz"* sorusu ancak türler tutarlıysa cevaplanır

### 7.1 Eğitmen ücreti planlanan maliyettir

⚠ **Eğitmen ücreti sonradan doğan bir tutar değil, planlanan maliyetin kalemidir** *(Sets, 28.07.2026)*. Tutar bellidir (§4) ve o eğitim için **override edilebilir** — normalde 5.000 olan bir eğitmen ücreti, özel bir anlaşma ya da durum sebebiyle o eğitimde 7.500 yazılabilir. Override planlama anında yapılır ve kalemin **planlanan** tutarıdır (§7.2); sonradan değişirse gerçekleşene yazılır, planlanan olduğu gibi kalır.

### 7.2 Her kalem iki tutar taşır: planlanan ve gerçekleşen

**Karar (Sets, 28.07.2026).** Maliyet kalemi tek bir sayı değildir:

| Alan | Ne | Değişir mi |
|---|---|---|
| **Planlanan** | Planlama anındaki tutar — normal akışta **alınmış bir teklif** | ⛔ Geriye dönük **asla** değişmez |
| **Gerçekleşen** | Kesinleşen tutar | Netleştiğinde yazılır/düzeltilir |

**Normal akış tekliftir** *(Sets)*: *"İskenderun'da eğitim var, telefonla ya da maille acente/otelden fiyat alınır, bu fiyat sisteme girilir."*

**Kalem girilirken hangisi olduğu seçilir:** teklifi alınmış ve **ödemesi 3E tarafından yapılacak** bir kalem doğrudan **gerçekleşen** olarak kaydedilebilir — tutar zaten kesindir. Diğer hâllerde **planlanan** yazılır; netleştiğinde **operasyon ya da planlama** gerçekleşeni girer.

⚠ **Sapma türetilir, ayrıca girilmez:** `sapma = gerçekleşen − planlanan`. İşaretlidir — eksi de olabilir artı da. Sıfırdan farklı her sapma **gerekçe ister**.

⛔ **Doğrudan gerçekleşen girilen kalemde planlanan boş bırakılmaz, aynı tutar yazılır** (sapma = 0). O kalem planın *ta kendisidir*; planlananı boş bırakmak onu aşağıdaki "planda hiç yoktu" sınıfına düşürür ve planlama kalitesi ölçümünü bozardı.

⚠ **Planda hiç olmayan kalem** ise gerçekten **planlananı boş** gelen kalemdir — planlama anında kimsenin öngörmediği harcama. Rapor ikisini ayırır: *"o kalemde sapma"* ile *"planda hiç yoktu"* farklı sorulardır.

Bu yapı §7.2'nin üç sorusunu birlikte cevaplar:

1. **Planlamacı düzgün planlama yaptı mı?** → sapmaların toplamı ve dağılımı
2. **Gerçek kârlılık ne?** → gerçekleşenlerin toplamı
3. **Hangi alanlarda tekrar tekrar sorun çıkıyor?** → kalem türü bazında sapma

⛔ **Neden iki alan, tek "güncellenen tutar" değil:** tek alan olsaydı planlanan tutar üzerine yazılır ve *"planlama iyi miydi"* sorusu sonsuza dek cevapsız kalırdı. Denetimde *"bu eğitimi kaç liraya planladık"* sorusunun cevabı, gerçekleşenden bağımsız durmak zorundadır.

### 7.3 Onay bir kilit değildir

Sets'in örneği: planlamacı eğitmen ücretini 5.000 olarak onaylattı, sonra telefon geldi — 6.000 olacaktı. Yapılacak şey planlamayı sıfırdan kurmak değil, **o kalemin gerçekleşenine 6.000 yazmaktır**, gerekçesiyle.

⚠ Gerekçe Sets'in kendi cümlesi: *"boşu boşuna sıfırdan yeni planlama yapmak zorunda kalmasınlar."* Planlanan 5.000 olarak kalır; sapma +1.000 olarak görünür.

⚠ Aynı mekanizma eksi yönde de çalışır: planlanan 5.000, gerçekleşen 4.000 → sapma −1.000. Kârlılık artık tek yönde sapmalı raporlanmıyor; *"500 fazla harcadı"* kadar *"500 az harcadı"* da planlama kalitesinin bilgisidir.

⚠ Gerçekleşen yazmak/düzeltmek **§7.5'in onay kuralına tabidir** ve onaya tabi olmasa bile bildirim üretir.

### 7.4 Planlama onayı — global ayar + planlamacı bazında ayar

**Karar (Sets, 28.07.2026):** iki katman.

**Global (backoffice):**

| Değer | Kod |
|---|---|
| Tüm eğitimler onaya tabidir | `always` |
| Tutarın üzerindekiler onaya tabidir | `above_threshold` (+ tutar) |
| Onay gerekmez | `never` |

**Planlamacı bazında (operasyon direktörü, kullanıcı oluştururken veya sonradan):** aynı üç değer + *"global ayarı kullan"*. Boşsa global geçerlidir.

#### Daraltma serbest, genişletme onaya gider

**Karar (Sets, 28.07.2026) — AD-09 revizyonu.** AD-09 *"genişletme denemesi hata verir"* diyordu. Yeni kural:

| Yön | Ne olur |
|---|---|
| **Daraltma** (global `never` → planlamacı `always`, ya da daha düşük eşik) | Doğrudan uygulanır |
| **Genişletme** (global `always` → planlamacı `never`, ya da daha yüksek eşik) | **Engellenmez — onaya gider** |

Gerekçe Sets'in kendi örneğidir: *"patronla konuştu, patron dedi ki tamam bizim maks. indirim %25 ama siz bu müşteriye %30 yapın. Yapamayacaklar mı? İş sürecini kilitleyecek bir hamle yapmayız, onaya tabi olur."*

⚠ **Bu bir gevşetme değil, doğru yere koyma.** Sert kapı iki şey üretiyordu: (a) gerçek hayatta verilmiş bir kararı sistemin dışında yaptırmak — telefonla, e-postayla, kayıtsız; (b) istisnanın hiçbir yerde iz bırakmaması. Onaya bağlamak istisnayı **hem mümkün hem kayıtlı** kılar.

⛔ **Bu revizyon AD-09'un tamamını değiştirmez.** *"Backoffice üretir, ofis tüketir"* ve tanım tablolarına yazmanın backoffice'e ait olması aynen durur. Değişen tek şey **iş parametresinin genişletilmesinin sonucudur**: hata değil, onay. ⚠ İş parametresi sayısal olmak zorunda değildir — bir eşik kadar seçenekli bir politika değeri de (`always` → `never`) bu kapsamdadır; sınır **iş parametresi ↔ yetki/tenant sınırı** ayrımıdır, sayı ↔ seçenek ayrımı değil.

⚠ **Etki alanı bu spec'ten büyüktür.** Aynı kural satışçı indirim tavanı için de geçerlidir; `app/Support/Business/DiscountCeiling.php` bugün genişletmeyi sessizce kabul ediyor (onaya da göndermiyor) — ayrı bir iş kalemi (**EGT-58**).

⚠ Eşik **tutarla birlikte seyahat eder**: `above_threshold` seçen her katman kendi tutarını taşır.

⛔ **Karşılaştırmanın tabanı tek cümleyle tanımlıdır: kalem başına *gerçekleşen varsa gerçekleşen, yoksa planlanan* — bunların toplamı.** Yalnız planlananları toplamak, doğrudan gerçekleşen girilen kalemleri (§7.2 — normal akışın önemli bir parçası) hiç saymazdı; tüm kalemleri teklifli girilmiş bir eğitim eşiğin altında görünüp onaydan kaçardı.

#### Onay nereden yürür

**Ortak omurga, ayrı havuz** *(Sets, 28.07.2026 — AD-23 revizyonu)*. Planlama onayı **yeni bir mekanizma değildir**: AD-23'ün onay motoru üzerinde bir kayıt tipidir. Dört göz kuralı, üst yöneticinin onaylayabilmesi + silsile bildirim, 1 iş günü alarmı ve audit oradan gelir.

**Ayrı olan:** kendi ekranı (*Bekleyen planlama onayları*), kendi yetkisi (`training.approve`), kendi filtresi, kendi gösterdiği tablo. Masraf onayı (§7.8) da öyle — ayrı havuz, aynı omurga.

⚠ Ayrı havuz olmasının sebebi kullanılabilirliktir: tür seçmeli tek bir onay listesi filtrelenemez ve yetki kırılımı tanımlanamaz. ⚠ Omurganın ortak olmasının sebebi ise sapmadır: dört göz ve eskalasyon üç kez yazılırsa üçü aynı gün doğru olur, altı ay sonra biri düzeltilir ikisi unutulur.

### 7.5 Sapmanın onayı planlamadan miras alınır

**Karar (Sets, 28.07.2026):** *"eğer planlanan eğitim onaya tabi ise her şey onaya tabi olur, değilse olmaz."*

Sapma için ayrı bir onay kuralı **yoktur**; §7.4'ün sonucu neyse gerçekleşen tutarın yazılması/düzeltilmesi de odur.

⚠ Ayrı bir eşik koymamanın sebebi, iki onay kuralının zamanla birbirinden sapması ve *"bu neden onaya gitti"* sorusunun cevapsız kalmasıdır.

⚠ `above_threshold` modunda eşik **toplam maliyete** bakar, tek tek kaleme değil. Toplamın tanımı §7.4'tekiyle aynıdır: **kalem başına gerçekleşen varsa gerçekleşen, yoksa planlanan.** Eşiğin altında planlanan bir eğitim, sapmalarla eşiği aşarsa **o noktada onaya gider**. Aksi hâlde eşik, planlamayı bilerek altta bırakıp farkı sonradan kapatarak aşılabilir hâle gelirdi — indirim limitinde kalem/toplam çift kontrolünün varlık sebebiyle aynı gerekçe (`fiyatlama-spec.md` §4.2).

**Onay ile bildirim aynı şey değildir.** Onaya tabi olmasa bile bu tür değişikliklerin **tamamı bilgi olarak üstlere gider** *(Sets, 28.07.2026)*: *"planlanan dışında kalem eklendi"*, *"eğitmen ücreti kaleminde sapma oluştu"*. Bildirim Eğitim Direktörü ve Operasyon Direktörüne düşer; onay beklemez, sadece haber verir.

### 7.6 Eğitmen masrafı iki yere birden yazılır

**Karar (Sets, 28.07.2026):** *"2'si de evet."* Onaylanan eğitmen masrafı (çatı §187 — fiş/faturayla girilen otel, yol, yemek) **iki kayda birden** düşer:

1. **Eğitmenin carisine — her zaman, tam tutarıyla.** Eğitmen o parayı cebinden çıkardıysa 3E ona borçludur; planlanmış olup olmaması borcu değiştirmez. *"Ne kadar ödedik, ne kadar bekleyen var."*
2. **Eğitimin maliyetine — ilgili kalemin gerçekleşeni olarak** (§7.2). *"Eğitimin tam maliyetini görebiliyor olacağız"* — ve tam maliyet, aynı harcamayı iki kez sayan maliyet değildir.

⚠ İkinci maddenin §7.2'ye oturması çifte sayma sorununu **aritmetik olmaktan çıkarır**: onaylanan masraf planlananın üstüne yeni bir tutar eklemez, kalemin **gerçekleşen tarafını** besler.

| Durum | Eğitmenin carisine | Eğitim maliyetine |
|---|---|---|
| Planda `paid_by_instructor` kalem var | Tam tutar | O kalemin **gerçekleşenine eklenir**; sapma türetilir (artı da eksi de) |
| Planda hiç karşılığı yok | Tam tutar | **Planlananı boş** yeni kalem; gerçekleşen = masraf tutarı |
| Planda `paid_by_company` kalem var (3E ödedi) | — | — → **mükerrer adayı, onaylayan reddeder** (§7.8) |

⛔ **Gerçekleşen birikir, üzerine yazılmaz.** Bir kaleme birden çok fiş düşmesi normaldir: üç günlük eğitimde *yemek* kalemine 400 + 500 + 450 gelir. Gerçekleşen, o kaleme bağlı **onaylanmış masrafların toplamıdır**; ikinci fiş birinciyi silmez. Üzerine yazan bir kural, eğitmene eksik ödemenin en sessiz yolu olurdu.

⚠ Bunun sonucu olarak §7.8'in mükerrer sinyali *"gerçekleşeni dolu"* değildir — dolu olması normaldir. Sinyaller şunlardır:

- Masrafın karşılık geldiği kalem **`paid_by_company`** (3E zaten ödedi)
- Birikim **planlananı aşıyor** — meşru olabilir (fiyat arttı), mükerrer de olabilir; onaylayan bakar

⚠ **Fiş kaynaklı sapmada gerekçe fişin kendisidir.** K-13'ün istediği gerekçe, masraf onay akışında ayrı bir adım değildir: onaylanan masraf kaydı (fiş/fatura eki + onaylayan + zaman) sapmanın gerekçesidir. Ayrı bir metin kutusu, aynı bilgiyi ikinci kez yazdırmaktan başka bir şey yapmazdı.

⚠ Bu bir çift kayıt değil, **iki farklı soruya bakan tek olayın iki yüzü**: biri *"bu eğitim bize kaça mal oldu"*, diğeri *"bu eğitmene ne borçluyuz"*. Tek yere yazılsaydı diğer soru cevapsız kalırdı.

⚠ Her masraf iki tarafa da **tam tutarıyla** girer; farklı olan ne yaptığıdır: cariye borç ekler, maliyette kalemin **gerçekleşenini** besler. Planlanan 5.000, tek fiş 4.000 ise: cariye 4.000, kalemin gerçekleşeni 4.000, sapma −1.000 — ve bu sapma görünür.

**Bunun ürettiği karar gücü** *(Sets'in kendi örneği)*: eğitim başına ortalama ek masraf, kalem türüne göre kırılım. Gidilen her yerde yemek masrafı yüksek çıkıyorsa operasyon *"oteli yemek dahil anlaşalım"* kararını bu tabloya bakarak verir. Kalem türü sözlüğü (§7) tam olarak bunun için kontrollüdür.

#### Çifte saymayı çözen şey ödeme sorumlusudur

**Karar (Sets, 28.07.2026).** Her planlanan maliyet kalemi **ödemeyi kimin yaptığını** taşır:

| Değer | Anlamı |
|---|---|
| `paid_by_company` | Ödemesi 3E tarafından yapıldı |
| `paid_by_instructor` | Eğitmen ödeyecek, 3E ona masraf olarak ödeyecek |

Sets'in senaryosu: *"biz teklifi aldık otelden, ödemesini yapmadık, eğitmen gittiğinde yaptı — o zaman bizim eğitmene yapmamız gerekir."*

⚠ **Bu, çifte saymayı uyanıklıkla değil yapıyla çözer.** `paid_by_company` işaretli bir kaleme karşılık gelen eğitmen masrafı **beklenmeyen** bir masraftır ve onay ekranında öyle işaretlenir; `paid_by_instructor` işaretli kalemin masraf olarak gelmesi **beklenen** akıştır ve eğitimin maliyetini artırmaz — planlanan kalemin karşılığıdır, tekrarı değil.

⚠ Aynı zamanda **eğitmen carisini doğru kurar**: 3E'nin ödediği otel eğitmene borç doğurmaz, eğitmenin ödediği otel doğurur. Bu ayrım olmadan cari ya şişer ya eksik kalır.

**Mükerrer masrafta ne olur** *(Sets, 28.07.2026)*: **onaylayan reddeder.** Sistem otomatik mahsup yapmaz — hangi harcamanın hangisiyle aynı olduğu bir insan kararıdır ve yanlış otomatik mahsup, sessizce eksik ödenmiş bir eğitmen demektir. Sistemin görevi **kararı bilgiye dayandırmaktır** (§7.8).

⚠ **Gerçek kârlılık eğitim bittiğinde kesinleşmez, masraflar kapandığında kesinleşir.** Masraf günler sonra gelir. Eğitimin maliyeti bu yüzden bir süre daha *açık* durumdadır ve raporlar bunu **"kesinleşmedi"** olarak gösterir — kesinleşmemiş bir kâr rakamını kesinmiş gibi göstermek, yanlış rakamdan daha kötüdür.

### 7.7 Eğitmen carisi — kayıtlardan doğar, kayıt elle de girilebilir

Çatı §187: *"eğitmenler cari bazlı tutulur, ödendi/ödenmedi takibi zorunlu."*

⚠ **Cari bir veri girişi ekranı değildir** *(Sets, 28.07.2026)*: *"cari ödemesini girmek diye bir şey yok — sistemde kayıtlı olan bilgilerden oluşuyor cari kayıtları zaten."*

**Borç tarafı türetilir:**

| Kaynak | Ne zaman doğar |
|---|---|
| Eğitmen hakedişi | Verdiği eğitim kayıtlı — ücret (§4) ve varsa işlem override'ı üzerinden |
| Onaylanan masraf | §7.6 onayıyla |

**Hakedişin doğduğu an** *(Sets, 30.07.2026 — netleştirme)*: eğitim **gerçekleşip evrakları eksiksiz yüklendikten ve onaylandıktan** sonra. Masraf ise **onaylandığında** doğar. İkisi de onay sonrası cari'de görünür; onay öncesi hiçbiri bakiyeye girmez.

#### ⛔ Elle kayıt girilebilir — 30.07.2026 düzeltmesi

Bu bölüm *"elle borç satırı açılmaz"* diyordu. **Yanlış okunmuş bir kural**: kastedilen *"cari birinin hatırladıklarından oluşmaz"*, *"saha gerçeği sisteme girilemez"* değil.

**Karar (Sets, 30.07.2026):** operasyon **elle cari kaydı girebilir.** Saha gerçeği: *"sahada patronla beraberler, patron nakit para aldı üstünde olmadığı için şirkete dedi ki carisine 'elden nakit alındı' diye girin, ben onaylarım."*

Değişmeyen şey ve kuralın asıl koruduğu şey: **her cari satırının arkasında sistemde bir KAYIT vardır** — notu, girenin adı, zamanı ve denetim izi ile. Değişen şey, o kaydın kaynağının yalnız hakediş ve masraf onayı olması zorunluluğudur.

| Elle girilen | Ne yapar |
|---|---|
| *"Diğer"* kaleminden masraf kaydı | Borç doğurur — notu zorunlu |
| Ödeme kaydı (elden nakit dahil) | Borcu azaltır — **dağıtımı zorunlu** (aşağıda) |

⚠ Elle girilen kayıt **onaya tabidir** (§7.8) ve *"patron onaylar"* cümlesinin sistemdeki karşılığı budur. Onaysız elle kayıt bakiyeye girmez.

⛔ Elle girilen kaydın **notu zorunludur**. Gerekçesiz bir cari hareketi, tam olarak bu bölümün reddettiği şeydir: kimsenin açıklayamadığı bir rakam.

#### Ödeme kaydı — hangi kalemleri kapattığı seçilir

Operasyon ödemeyi yaptığında **eğitmen sayfasından bilgi olarak girer**. ⛔ Ve girerken **ödemenin hangi kalemleri kapsadığını seçer** *(Sets, 28.07.2026)*.

Sets'in örneği: 30.000 eğitim hakedişi + 3.000 masraf var, 6.000 ödendi. Bu 6.000'in ne kadarı masraf ne kadarı hakediş — **ödemeyi giren tanımlar**, sistem tahmin etmez.

⚠ Dağıtımsız bir ödeme kaydı *"6.000 ödendi"* der ve *"neyin 6.000'i"* sorusunu cevapsız bırakır. Eğitmen *"masraflarımı ödemediniz"* dediğinde, dağıtımsız bir cari bunu ne doğrulayabilir ne çürütebilir. Hakediş ile masrafın vergi ve muhasebe muamelesi de aynı değildir.

⚠ Ödeme kaydı **finansal bir işlemdir**: yetkiye bağlıdır, audit'lenir (AD-06, kırmızı çizgi 13) ve **silinmez** — yanlış girilen ödeme iptal/düzeltme kaydıyla yönetilir (AD-11, kırmızı çizgi 12), tıpkı masraf gibi.

### 7.8 Bekleyen masraf onayları

Ayrı bir ekran *(Sets, 28.07.2026)*. Yalnız yetkisi olan görür — **yetki adı üzerinden, role gömülü değil** (AD-28).

**İki ayrı yetki** *(Sets, 28.07.2026)*:

| Yetki | Anlamı |
|---|---|
| `expense.approve_all` | Herhangi bir eğitmenin masrafını onaylayabilir |
| `expense.approve_group` | Yalnız **kendisine bağlı** eğitmenlerin masrafını onaylayabilir |

Böylece grup sorumlusu da direktör de aynı ekranı kullanır, gördükleri küme farklıdır.

⚠ İsimlendirme keyfî değil: `config/authorization.php:14` zaten *"the level that Spec 3 adds (`own` / `group` / `all`) will extend the format"* diyor. Yeni bir kapsam sözdizimi icat etmiyoruz, kayıtlı olanı kullanıyoruz.

⚠ **"Kendisine bağlı" ne demek — cevabı AD-23'tedir, burada değil.** AD-23 tek grup ağacı kurar (`Eğitmen Kadrosu → İzmit Eğitmenleri`) ve *"kişinin üyeliklerinden erişilebilen düğümler + altları"* diye tek bir kapsam çözümleyicisi tanımlar. `approve_group` o çözümleyiciyi kullanır.

⛔ **Eğitmen kaydında ağaca paralel ikinci bir "sorumlu" alanı açılmaz.** *"Bu eğitmen kimin kapsamında"* sorusuna iki mekanizma iki farklı cevap verirse hangisinin doğru olduğu sorusu hiç kapanmaz. Aynı çözümleyici §6.3'ün aday listesi kapsamını da belirler.

⚠ **Ön koşul bedava değil:** AD-23'ün ağacı bugün **kodda yok** (`database/migrations` içinde grup/üyelik tablosu yok — 28.07.2026 kontrolü). `approve_group` ağaç olmadan yazılırsa **boş küme** döner ve kimse fark etmez. Ağaç, kullanıcı oluşturma turunun işidir ve bu spec onun tüketicisidir.

⛔ **Kimse kendi masrafını onaylayamaz**, yetkisi ne olursa olsun. Eğitim veren bir direktör hem masrafı giren hem onaylayan olabilirdi; bu, onay adımını tamamen anlamsız kılar. Kendi hesabına dokunmayı reddetme deseni projede zaten var (`ChangeOfficeAccountStatus` — kişi kendi hesabını kilitleyemez).

#### Ekran karar verdirmek için kurulur, kayıt göstermek için değil

**Karar (Sets, 28.07.2026):** *"onay ekranında eğitime dair tabloyu net koyarız — hangi kalemler ne şekilde planlanmış, o ana kadar hangi masraflar onaylanmış vs. Böylece masrafı onaylama kararını bilgiye dayalı verir, hata riski azalır."*

Ekranın göstermek zorunda oldukları:

| Ne | Neden |
|---|---|
| Eğitmen, eğitim, kalem türü, tutar, fiş/fatura eki | Kaydın kendisi |
| **Eğitimin kalemleri: planlanan, gerçekleşen ve ödeme sorumlusu** (§7.2, §7.6) | Mükerrer adayı iki sinyalden çıkar (§7.6): masrafın karşılık geldiği kalem **`paid_by_company`**, ya da birikim **planlananı aşıyor** |
| **O ana kadar onaylanmış masraflar** | Aynı gecenin ikinci kez gelmesi ancak böyle görülür |
| **Admin limitini aşıyor mu** (çatı §187 "max tutar") | ⚠ Limit aşımı **engellenmez, işaretlenir**; çatı 2. tur karar #7'deki indirim limiti kararıyla aynı çizgi — sınırı aşan şey durdurulmaz, onaya gider |

⚠ Mükerrer tespiti bir insan kararıdır (§7.6) — ama **bilgisiz verilen insan kararı kura çekmektir.** Ekranın işi kararı vermek değil, verilebilir kılmaktır.

**Red gerekçeli olur.** Onay ve ret audit'lenir (AD-06); masraf eki kişisel veri içerebileceğinden görüntülenmesi erişim logu kapsamındadır (AD-21). Onaylanmış masraf **silinmez**, iptal/düzeltme ile yönetilir (AD-11, kırmızı çizgi 12).

### 7.9 Masraf girişi — eğitmenin kendi ekranı

*(Sets, 30.07.2026 — kapsam revizyonu. Bu spec masraf **girişini** kapsam dışı bırakmıştı; §7.6–7.8 yalnız onayı ve maliyete yansımasını tanımlıyordu.)*

**Karar:** *"masraflarım sayfası olmak zorunda."*

⛔ **Gerekçe, girişin olmamasının ne ürettiğidir.** Onay ekranı yazılsa bile onaylanacak kayıt hiçbir yerden doğmuyordu: yolda otel parası ödeyen eğitmenin elindeki tek yol fişin fotoğrafını birinin telefonuna göndermekti. O fotoğraf audit'lenmez, onaylanamaz, carinin girdisi olamaz ve *"otel parasını ödediniz mi"* sorusunu kimse cevaplayamaz. §7.7'nin türetilmiş borcu (hakediş + **onaylı masraf**) girişsiz bir yarım denklemdir.

**Ekran (`/egitmen/masraflarim`):** kendi masraf kayıtları, üç toplam (onay bekleyen / onaylanan / reddedilen), yeni kayıt formu ve **geri çekme**.

**Bir masraf kaydının alanları:** kalem türü *(yönetilen liste, AD-08 — konaklama, ulaşım, yemek, km desteği, diğer; km desteği kendi kalemidir, §5)*, tutar, harcama tarihi, **ilgili eğitim (zorunlu değil)**, açıklama, **fiş/fatura (bir veya birkaç)**.

| Karar | Neden |
|---|---|
| İlgili eğitim **boş bırakılabilir** | Her harcama bir eğitime ait değildir; zorunlu kılmak en yakın eğitimi seçtirir, bu boş kolondan kötüdür |
| Eğitim listesi **yalnız kişinin kesinleşmiş atamaları** | Başkasının eğitimine masraf yazmak o eğitimin maliyetini taşır (§7.6) — token 404 ile reddedilir |
| **Limit aşımı engellenmez, işaretlenir** | K-19. Para zaten harcandı; girişi reddetmek harcamayı geri almaz, kaydı yine telefona gönderir. Sınır onaylayanın ekranında (§7.8) |
| **Fiş zorunluluğu ayardan okunur** (`business.expense.receipt_required`) | AD-08, kırmızı çizgi 9 — koda gömülü kural değil |
| Geçmiş tarih serbest, **gelecek tarih reddedilir** | Para önce harcanır sonra bildirilir; geçen haftanın otel faturasını reddetmek onu fotoğrafa geri gönderirdi |
| Kayıt **silinmez, geri çekilir** (`withdrawn`) | AD-11, kırmızı çizgi 12. *"Hiç talep olmadı"* ile *"talep geri çekildi"* ayrı cümlelerdir |
| Geri çekme **yalnız karar verilmemiş kayıtta** | Onaylanan zaten borçtur, reddedilen zaten birinin gerekçeli cevabıdır — trigger da reddeder |
| Ret **gerekçesiz olamaz** (CHECK) | §7.8'in kuralı, onay ekranı başka turda yazılsa bile veritabanında durur |

⚠ **Onay tarafı hâlâ EGT-28'in işidir.** Bu tur kaydı doğurur ve `submitted` durumunda bırakır; `approved`/`rejected` geçişini yapacak ekran, cariye yazma (§7.7) ve maliyet kalemine işleme (§7.6) o turda yazılır. Kayıt bugünden **karar kolonlarıyla** doğar: sonradan eklenseydi arada girilen her masrafın kararı kayıtsız kalırdı.

## 8. Yazışma — kayda bağlanır

### 8.1 Karar

Planlamacı otel/acente/araç tedarikçileriyle **panel üzerinden yazışır**; teklif tarafındaki mekanizmanın (AD-20, Postmark inbound) aynısı kullanılır. Not alma da aynı şekilde.

Gerekçe: *"planlamacı gelmedi ya da başka bir şey oldu, en azından eğitim planlamasına bakan tam olarak nerede kalındığını, nelerin teklifi alındı, nelerin fiyatında hangi aşamada olduğunu net olarak görmüş olur"* (Sets). Bu, çatı §11'deki *"anlaşmalı tedarikçiler: teklif alınıp eğitime işlenir — bölgesel fiyat tarihçesi oluşur"* kararının yazışma ayağıdır.

**Maliyet kalemi, dayandığı yazışmaya bağlanır** — bir tutarın nereden geldiği sorusunun cevabı sistemde durur.

### 8.2 Eğitim merkezdir — görünürlük ayrı bir katmandır

**Karar (Sets, 28.07.2026):** *"günün sonunda bunların hepsi eğitimin verileri. kimin neyi ne kadar görebileceği ayrı bir konu… hepsi aynı eğitime bakıyor, sadece kendi ile alakalı kısımları görüyor."*

Planlama süreci, maliyetler, yazışmalar, eğitmen, tarih, içerik, satış — hepsi **aynı eğitimin verisidir**. Veri modelinde bunları ayıran bir hat yoktur; ayıran şey **yetkidir**.

⛔ Bunun pazarlıksız sonucu: **görünürlük tabloyla çözülmez.** "Satışçı bunu görmesin" diye veriyi başka bir kayda taşımak, aynı veriyi iki yerde tutmaya ve birinin diğerinden sapmasına yol açar. Kim ne görüyor sorusunun tek cevabı policy'dir (çatı §178/1).

Roller AD-23 ağacının adlarıdır (`Operasyon Direktörü` · `Satış Direktörü` · `Eğitim Direktörü` · satış/planlama yöneticileri · satışçı · planlamacı · eğitmen).

| Kim | Ne görür | Ne görmez |
|---|---|---|
| **Operasyon Direktörü** | Eğitimin tamamı — planlama süreci, maliyetler, yazışmalar, cari | — |
| **Eğitim Direktörü** (planlama dikeyinin başı) | Kapsamındaki eğitimlerin tamamı; eğitmen uygunluk uyarıları | Satış dikeyinin kendi iç verisi |
| **Planlamacı** | Planlama, maliyet kalemleri, tedarikçi yazışması, havuzundaki uygun eğitmenler | Eğitmen uygunluk **sorunları** (§3) |
| **Satış Direktörü / satış yöneticisi** | Satışçının gördüğü her şey, kapsamı kadar | Planlama yazışması |
| **Satışçı** | **Maliyetler** (kâr = fiyat − maliyet, çatı §181), eğitim bilgileri | Planlama yazışması; maliyeti **değiştiremez** (§4.4) |
| **Eğitmen** | Kabul öncesi: eğitim, tarih, yer, katılımcı **sayısı**, kendi ücreti. Kabul sonrası: otel/bilet/doküman/katılımcı listesi. Her zaman: **kendi masrafları ve kendi carisi** | Eğitimin maliyeti, başka eğitmenlerin rakamları |
| **Müşteri** | Eğitim içeriği, eğitmen, tarih, yer, kendi teklifi | Maliyetler, yazışmalar, planlama süreci |
| **Katılımcı** | Kendi eğitimi, tarih, yer, kendi katılım/sertifika kaydı | Bu spec'teki her şey — maliyet, yazışma, planlama, eğitmen ücreti |

⚠ Satışçı **maliyeti görür ama planlama yazışmasını görmez** *(Sets, 28.07.2026)*. Çelişki değil: satışın kâr hesabı için tutara ihtiyacı vardır, otel pazarlığının içeriğine yoktur.

⚠ **Direktörlük ek yetki alanı değildir** (AD-23): direktör kendi dikeyinin en üstüdür, fazlası değil. Mali tabloları görmek **ayrı bir yetkidir** ve varsayılan olarak operasyon direktöründedir. Yukarıdaki tablo ağaç kapsamının *üstüne* nesne yetkisiyle çalışır — dikeyler arası akış (satışçının planlanmış eğitimi görmesi) ağacı gevşeterek değil, nesne yetkisiyle çözülür.

### 8.3 AD-20 revizyonu: yazışma teklife değil, kayda bağlanır

AD-20 bugün yazışmayı **teklife** bağlıyor. Planlamacı yazıştığında ortada teklif yoktur — planlanan eğitim vardır.

**Yeni kural:** yazışma bir **kayda** bağlanır; kayıt türü **eğitim** veya **teklif** olur.

⚠ Bu bir *erişim* ayrımı değil, **hangi konuşma olduğu** ayrımıdır. Çatı §5'e göre açık eğitim *"belli bir bölgede tüm firmalara açık"* — tek eğitim, N müşteri, N ayrı teklif. Bir müşterinin cevap maili hangi teklife ait olduğunu söylemek zorundadır; "eğitime" demek yetmez. AD-20'nin referans kodlu Reply-To kurgusu tam olarak bunu çözer.

Teklif eğitime bağlıdır (ne satıldığı); yazışma da bağlı olduğu kaydın altında yaşar. İkisi de aynı eğitimin verisidir — §8.2.

#### Kanal referans koduyla çözülür

**Karar (Sets, 28.07.2026):** planlama yazışması da **kendi referans kodu** üzerinden yürür. Nasıl ki satış trafiği teklif kodu üzerinden takip ediliyor, planlama trafiği de kendi kodundan takip edilir.

Mekanizma AD-20'nin kurgusudur ve **yeni altyapı gerektirmez**: inbound subdomain **catch-all** dinlendiği için adresler önceden tanımlanmaz; gelen mailin `To` local-part'ındaki kod hangi kayda ait olduğunu söyler. Ön ek farklı → kayıt farklı.

⚠ **Kod formatı AD-19'a tabidir:** `PREFIX-YYYY-XXXX`, prefix **tam iki harf** (üç harf YouTrack anahtarlarıyla karışır), rastgele son ek, ardışık numara yasak. Kayıtlı prefix'ler bugün `EG` (eğitim), `TK` (teklif), `FT` (fatura) — `config/reference_codes.php`. **`PL` henüz kayıtlı değildir**; kapanış adresi plan aşamasıdır.

⚠ **Benzersizlik ön ekten bağımsızdır** (AD-19): son ek `(yıl, son ek)` uzayında tekilleşir. `PL-2026-7K4F` üretildiği anda `EG-2026-7K4F` de rezerve olmuş sayılır — çünkü dönüşümde son ek korunmak zorundadır ve yeniden üretilemez. Bu olmadan, plandan doğmayan bir eğitim için bağımsız üretilen kod, sonradan onaylanacak bir planın hedef kodunu kapatabilirdi.

**Planlama kendi kodunu taşır: `PL`** *(Sets, 28.07.2026)*.

Gerekçe Sets'in tespiti: **planlama onaylanmadan "eğitim" oluşmaz** — planlama, eğitim öncesi bir süreçtir ve yazışması o sürecin yazışmasıdır. (Kayıt düzeyinde çatı §105 bunu *"internal'da draft/planlanmış olarak tutar"* diye söylüyor: aynı kayıt, iş anlamında henüz eğitim değil.)

**Onayda kod eğitime aktarılır:** `PL-2026-7K4F` → `EG-2026-7K4F`. Rastgele son ek korunur, ön ek değişir. Böylece *"EG-2026-7K4F'in planlaması PL-2026-7K4F"* bilgisi sistemsel olarak taşınır; iki kayıt eşlemesi tutmaya gerek kalmaz.

⛔ **Eski adres ölmez, yönlendirir.** Onay sonrası `pl-2026-7k4f@` adresine gelen bir acente cevabı aynı kayda düşer. AD-19'un *"kod değişmez"* kuralının amacı dışarıdaki tarafın elindeki kodun geçersizleşmemesidir; ön ek değişimi bunu bozmadığı sürece istisna güvenlidir — AD-19'a bu tek istisna olarak yazıldı.

⚠ Yeni bir **subdomain** açmak gerekmez ve gerekmemesi tercih edilir: AD-20'nin Postmark kısıtı gereği her yeni subdomain = yeni Postmark server + ayrı webhook. Aynı catch-all üzerinde farklı ön ek, sıfır altyapı maliyetiyle aynı ayrımı verir.

Erişim kaydın kendi yetkisinden gelir; ayrı bir yazışma yetkisi tanımlanmaz, aksi hâlde iki yetki modeli birbirinden sapar.

### 8.4 AD-20'nin güvenlik sınırları aynen geçerlidir

Gelen mail **doğrulanmamış içeriktir** ve hiçbir iş aksiyonunu otomatik tetiklemez. Acentenin *"onaylıyorum"* maili bir maliyet kalemi oluşturmaz; planlamacı kalemi kendi girer. Mail yalnız yazışma kaydıdır.

## 9. Ekranlar

| Ekran | Panel | İçerik |
|---|---|---|
| Eğitmen ayarları | Backoffice | Kategori bazlı baz tarifeler, km desteği, masraf limitleri, fiş zorunlulukları, cevap süresi, **global planlama onay kuralı** (§7.4) |
| Eğitmen kaydı | Ofis (Operasyon Dir. / Eğitim Dir.) | Kimlik + mevzuat dosyası + hassas veri (maskeli, §2.1) + ücret/masraf override'ları |
| Eğitmen uygunluk uyarıları | Ofis (Eğitim Dir. + Operasyon Dir.) | Bayrak kalkan eğitmenler, etkilenen gelecek atamalar |
| Eğitmen atama | Ofis (planlamacı) | Uygun aday listesi, ihtiyaç adedi, mod seçimi, bekleyen/kesinleşmiş ayrımı |
| Aday seçimi | Ofis (operasyon) | `selection` modunda kabul edenler + maliyetleri |
| Atama teklifi | Ofis (eğitmen) | Uygulama içinde kabul / gerekçeli ret (§6.13); kabulden sonra otel, bilet, doküman, katılımcı listesi |
| Planlama maliyeti | Ofis (planlamacı) | Kalem ekleme: planlanan/gerçekleşen + **ödeme sorumlusu**, sapma + gerekçe, yazışma bağı |
| Planlamacı ayarları | Ofis (Operasyon Dir.) | Kullanıcı oluştururken/sonradan: **eğitmen görünürlüğü** (havuzum / tümü, §6.3) + planlama onay kuralı ve eşiği (§7.4) |
| Bekleyen planlama onayları | Ofis (`training.approve`) | Kendi havuzu; AD-23 omurgası üzerinde (§7.4) |
| **Bekleyen masraf onayları** | Ofis (Operasyon Dir. + yetkililer) | Masraf, fiş, limit aşımı işareti, eğitimin kalemleri **planlanan + gerçekleşen + ödeme sorumlusuyla**, o ana kadar onaylanmış masraflar; onay/gerekçeli ret |
| Eğitmen carisi | Ofis (mali yetki) | Türetilmiş borç (hakediş + onaylı masraf), **kalem seçimli ödeme kaydı**, eğitim bazlı kırılım |
| Masraf analizi | Ofis (Operasyon Dir.) | Eğitim başına ortalama ek masraf, kalem türü ve bölge kırılımı |
| **Masraflarım** | Ofis (eğitmen) | Kendi masraf kayıtları, üç toplam, yeni kayıt (tür/tutar/tarih/eğitim/fiş), geri çekme (§7.9) |
| Eğitmen kendi carisi | Ofis (eğitmen) | Kendi hakedişi, masrafları, ödenen/açık bakiyesi (§8.2) |

## 10. Kabul kriterleri

Plan aşaması neyin kanıtlanacağını buradan okur. Her satır gözlemlenebilir bir davranıştır.

| # | Kriter |
|---|---|
| K-1 | Eğitim tarihinde belgesi dolmuş / iptal edilmiş / iki kuruluş sınırını aşmış / yetkinlik kapısını taşımayan eğitmen aday listesinde **görünmez** (§3.1) |
| K-2 | Planlamacı, ayarına göre yalnız havuzundaki veya tüm uygun eğitmenleri görür (§6.3) |
| K-3 | `first_accepted` modunda kontenjan dolduktan sonraki kabul **veritabanı seviyesinde** reddedilir; eşzamanlı iki kabulden yalnız biri geçer (§6.4) |
| K-4 | Çakışmanın tek kaynağı **kesinleşmiş atamalardır**; bekleyen teklif ve seçim bekleyen kabul çakışma üretmez (§6.5) |
| K-5 | `selection` modunda kontenjanı seçim kapatır; kabul edip seçilmeyen teklif `not_selected` olur ve bildirim alır (§6.2) |
| K-6 | `selection` modunda uygunluk ve çakışma **hem kabulde hem seçimde** değerlendirilir; kabulde erken filtre, **seçimde bağlayıcıdır** (§6.2) |
| K-7 | Süresi dolan teklif `expired` olur ve Eğitim + Operasyon Direktörüne yükselir; süre her teklifin kendi gönderim anından işler (§6.7) |
| K-8 | Tüm adaylar reddederse istek `escalated` olur ve alert üretir (§6.7) |
| K-9 | Kontenjan dolduğunda açık teklifler `withdrawn` olur ve bildirim gider (§6.8) |
| K-10 | Kabul öncesi eğitmen katılımcı **sayısını** görür, listesini görmez; kabul sonrası otel/bilet/doküman/liste açılır ve erişim loglanır (§6.9) |
| K-11 | Tarih veya yer değişince atama `reconfirming` olur, satılabilirlik düşer, takvim bloğu sürer; ret hâlinde satış dahil üç tarafa alert gider (§6.10) |
| K-12 | Kabul/ret yalnız uygulama içinden yapılabilir; mail hiçbir atama durumunu değiştirmez (§6.13) |
| K-13 | Sıfırdan farklı sapma gerekçesiz kaydedilemez; planlanan tutar geriye dönük **hiçbir yoldan** değişmez; sapma işaretlidir (± ikisi de kaydedilir) (§7.2–7.3) |
| K-14 | Planlamacı ayarı globali daraltıyorsa doğrudan uygulanır, genişletiyorsa onaya gider — engellenmez (§7.4) |
| K-15 | Eşik aşımı **toplam maliyete** bakar — taban: kalem başına *gerçekleşen varsa gerçekleşen, yoksa planlanan*; sapmalarla eşiği aşan eğitim o noktada onaya gider (§7.4–7.5) |
| K-16 | Onaya tabi olmayan değişiklikte bile Eğitim + Operasyon Direktörüne bilgi bildirimi gider (§7.5) |
| K-17 | Her kalem `paid_by_company` / `paid_by_instructor` taşır; onaylanan masraf **cariye tam tutarıyla eklenir** ve ilgili kalemin **gerçekleşenine eklenir** (birikir, üzerine yazmaz); karşılığı yoksa planlananı boş yeni kalem açar (§7.6) |
| K-18 | Masraf onay ekranı eğitimin kalemlerini **planlanan, gerçekleşen ve ödeme sorumlusu** sütunlarıyla, o ana kadar onaylanmış masrafları ve limit aşımı işaretini gösterir; `paid_by_company` kaleme karşılık gelen ve birikimi planlananı aşan masraflar işaretlenir (§7.8) |
| K-19 | Limit aşan masraf engellenmez, işaretlenir (§7.8) |
| K-20 | Kimse kendi masrafını onaylayamaz; `approve_group` kapsamı AD-23 çözümleyicisinden gelir (§7.8) |
| K-21 | Cari **her zaman bir kayıttan** doğar: hakediş (eğitim gerçekleşip evrakı onaylandıktan sonra), onaylı masraf, ya da **elle girilen onaylı kayıt** — notu, gireni ve denetim iziyle. Gerekçesiz hareket yoktur *(30.07.2026 düzeltmesi)* (§7.7) |
| K-22 | Ödeme kaydı hangi kalemleri kapattığı seçilmeden kaydedilemez (§7.7) |
| K-23 | Satışçı maliyeti görür, değiştiremez; planlama yazışmasını hiç görmez (§4.4, §8.2) |
| K-24 | Eğitmen dosyasındaki TCKN/SGK maskeli gelir; açık görüntüleme ayrı eylemdir ve erişim loguna yazılır (§2.1) |
| K-25 | Kesinleşmiş atama, onaylanmış masraf ve ödeme kaydı hard delete edilemez (§6.12, §7.7, §7.8) |

## 11. Açık kalanlar

| # | Ne | Not |
|---|---|---|
| 1 | Tedarikçi kaydı | Otel/acente/araç tedarikçileri ayrı bir kayıt mı, yoksa yazışma adresi olarak mı yaşıyor? Çatı §11 "MVP: manuel giriş" diyor; bölgesel fiyat tarihçesi istenirse kayıt gerekir. |
| 2 | Yetkinlik kapılarının veri modeli | YÖN-2019 md.6/4-5 eşleşmesi eğitim ailesi × eğitmen yetkinliği matrisidir; AD-27 gereği admin-tanımlı olacak, **şeması eğitim tanımı turunda çözülür**. |
| 3 | ~~Resmî tatil takvimi~~ | ⛔ **Kapandı, yapılmayacak** *(Sets, 18.08.2026, EGT-43 Won't fix)*. §6.7'nin "3 iş günü"sü **3 takvim günü** olarak okunur; hafta sonu ve resmî tatil atlanmaz. Aynı karar AD-23 için de geçerli — o da bu takvimin tüketicisiydi. |