# Şube yapısı — spec

*v0.6 · 20.10.2026 · EGT-219 · Kararların kaynağı: `proje-haritasi.md` §4.4 «Şubeler: tek merkez 3E Group» (Sets, 19–20.10.2026) · AD-09, AD-21, AD-23, AD-25, AD-26 · İlgili: EGT-216 (potansiyel müşteri, kapsamı bu yapıyla çalışır), EGT-220 (kiracısız erişim logu)*

Bu belge **şube** kavramının tek kaynağıdır: şube nedir, nasıl kurulur, ne yapabilir, şube üyesi neyi görür ve neyi göremez. Her satır ya Sets'in 19–20.10.2026 kararlarından ya da referansı verilen AD maddesinden gelir. **Varsayımla doldurulmuş satır yoktur;** kararı verilmemiş her nokta §11'de açık soru olarak durur ve spec onu kapatmadan heyete gitmez.

**Var olma sebebi:** 3E tek merkezdir (3E Group). İzmit'te bağımsız bir ekip oradaki satışları üstlenecek; İzmir'deki şirkete ayrı bir arayüz ya da tam erişim verilmeyecek, 3E Eğitim içinde ayrı bir grup olarak çalışacak. *"Tek merkez 3E Group olsun, diğerleri branch gibi çalışsın ve sadece verilen işleri yapabilsin."* (Sets, 19.10.2026)

**Kapsam dışı** (adresi §12'de): şubeye özel fiyat listesi · müşteri portalında şube kavramı · e-fatura entegrasyonu.

---

## 1. Bugünkü durum (koddan ölçüldü, 19–20.10.2026)

| Konu | Durum | Kanıt |
|---|---|---|
| Grup ağacı, üyelik seviyeleri (`director` / `group_manager` / `staff`), `own`/`group`/`all` kapsamı | ✓ var | AD-23, `app/Support/Authorization/ScopeResolver.php` |
| Canlı ağaç | Operasyon (kök) → Satış · Planlama · Eğitmen kadrosu; şube düğümü yok | production, 20.10.2026 |
| Ağacın yönetildiği yer | backoffice, `groups` kaynağı (Filament) | `php artisan route:list` |
| Müşteri görünürlüğü | `customer.view.all` yoksa yalnız atanmış firmalar, veritabanı seviyesinde | `SessionScopeResolver` |
| Teklif, potansiyel müşteri, kullanıcı, talep | kayıt sahibinin/üyeliğin kapsamına göre daralıyor | `SalesQuotes`, `PotentialCustomersInReach`, `OfficeUsers`, `TrainingRequestQueue` |
| Planlanan eğitim | kapsam (`training_scopes`) **yalnız talepten** planlanan eğitime yazılıyor; kapsamsız eğitim herkese, açık eğitim herkese görünüyor | `PlanTrainingRequest`, `TrainingsInScope`, `VisibleTrainings` |
| Eğitmen seçimi | kapsam okumuyor | `EligibleInstructors`, `PlanningCandidates`, `OfficeInstructors` |
| `training.assign_instructor.{group,all}` | tanımlı, okuyan kod yok | `config/authorization.php` |
| Takvimim, Satış kokpiti | kapısı teklif politikası (`Quote::viewAny`) | `OfficeNavigation`, `SalesAgendaController` |
| Mali tablo | `financial.view` kapsamsız; tüm şirketin rakamı | `FinancialOverview` |
| Yetki verme tavanı | verenin sahip olmadığı yetki verilemez (`Ceiling`) | `app/Support/Authorization/Ceiling.php`, AD-23 güvenlik kuralı 1 |

---

## 2. Şube nedir

### 2.1 Bir şube kaydı ve dikey düğümleri

⛔ *(Sets, 20.10.2026)* **Şube ayrı bir kayıttır** («İzmit», «İzmir»). Seçilen her yetenek için ilgili dikeyin altında şubenin düğümü açılır:

```
Operasyon (merkez)
├── Satış
│   ├── İzmit        ← İzmit'in satış yeteneği
│   └── İzmir        ← İzmir'in satış yeteneği
├── Planlama
│   └── İzmir        ← İzmir'in planlama yeteneği
└── Eğitmen kadrosu
    └── (Antalya)    ← eğitmen yeteneği olan şube
```

AD-23'ün dikey-önce ağacı ve tek kapsam çözümleyicisi **değişmez**. Satış Direktörü tüm satışı (merkez + şubeler) görmeye devam eder; İzmit'in satış düğümüne üye olan kişi yalnız İzmit'in satış kayıtlarını görür.

### 2.2 Üç yetenek, sabit şube tipi yok

⛔ *(Sets, 20.10.2026)* *"Branch'ler 3 işi de yapabilsin yetenek olarak … branch kurulurken neleri yapabileceği seçilsin."*

| Yetenek | Ne demek | Açtığı düğüm |
|---|---|---|
| **Satış** | müşteri, potansiyel müşteri, teklif | Satış → {şube} |
| **Planlama** | eğitim planlama | Planlama → {şube} |
| **Eğitmen** | şubenin kendi eğitmen kadrosu | Eğitmen kadrosu → {şube} |

### 2.3 Menüler şubeye göre değişmez

⚠ *(Sets'in sorusu üzerine netleşti, 20.10.2026)* Menü kalemleri **yetkiden** çizilir (`OfficeNavigation`); şubeye özel kalem yoktur. Daralan, kalemlerin **içindeki kayıtlardır**.

---

## 3. Yetenek bir yetki tavanıdır

⛔ *(Sets, 20.10.2026)* Bir şubede bir yetenek kapalıysa:

1. o yeteneğin düğümü açılmaz;
2. şubenin üyelerine o yeteneğin yetkileri **verilemez** — yetki ekranı o kutuları kapalı gösterir, gerekçesini yazarak;
3. yanlışlıkla verilmiş (ya da yetenek sonradan kapatılmış) bir yetki **çalışmaz**: izin kontrolü, kişinin yalnız şube üyesi olduğu durumda o yeteneğin yetkilerini reddeder.

Hangi yetkinin hangi yeteneğe ait olduğu §11 S-1'dedir.

⛔ **Tavan düğüm başına işler** *(Sets, 20.10.2026 — heyet 815 F-5)*. Bir yetki, kişinin yalnız o yeteneği açık olan düğümlerinden erişilen kayıtlarda çalışır. İzmit'te satış, İzmir'de planlama üyeliği olan kişi İzmir'in eğitimlerini planlar, İzmit'inkileri planlayamaz; İzmir'de teklif yazamaz. Merkezdeki üyelik (yetenek sınırı olmayan dikey düğümler) tavana takılmaz.

---

## 4. Şubenin kurulması ve yaşam döngüsü

⛔ *(Sets, 20.10.2026)* **Şube backoffice'te kurulur, yetenekleri orada seçilir** — grup ağacının bugün yönetildiği yer. Ofiste şube kurma ekranı yoktur.

| Eylem | Sonuç |
|---|---|
| Şube kur | ad + yetenekler; her yetenek için düğüm açılır |
| Yetenek ekle | ilgili düğüm açılır |
| Yetenek kaldır | ⛔ *(Sets, 20.10.2026)* önce **uyarı**: düğümde kimin ve hangi açık işin olduğu ad ad yazılır; ardından merkeze taşıma için **atama soruları** sorulur (kişi hangi merkez düğümüne, açık teklif/eğitim/potansiyel müşteri kime); cevaplar verildiği anda taşınır ve yetenek kaldırılır. *"Kaldırma yapılacaksa bir gerekçesi vardır."* |
| Şubeyi kapat | ⛔ *(Sets, 20.10.2026)* yetenek kaldırmayla **aynı akış**: uyarı → atama soruları → taşı → kapat. Kişi silinmez (AD-23), kayıt silinmez (AD-11). |

Her eylem audit'lenir (AD-06; backoffice yönetim işlemi).

---

## 5. Kişiler ve kullanıcı açma

⛔ *(Sets, 20.10.2026)* *"Eğer kullanıcı açma ve yetki düzenleme yetkisi varsa yapabilsin kendi şubesine, bu yetkileri yoksa yapamasın."*

Bu AD-23'ün kendi kuralıdır ve bugün kodda vardır: kullanıcı açma yetkisi açık izinden gelir (`user.create.group`), kapsam üyeliğin düğümüyle sınırlıdır. Şube yöneticisi:

- yalnız kendi şubesinin düğümlerine kişi yerleştirir;
- yalnız sahip olduğu ve **şubenin yeteneklerinin izin verdiği** yetkileri verebilir (§3 tavanı + `Ceiling`);
- şube dışına kişi açamaz, şube dışındaki kişiyi göremez.

---

## 6. Ne görülür — kayıt türüne göre

| Kayıt | Şube üyesi neyi görür | Kaynak |
|---|---|---|
| **Müşteri** | yalnız kendisine atanmış firmalar (bugünkü kural). ⛔ **Firmayı açan kişi o firmaya kendiliğinden atanır** — bugün atanmıyor ve `customer.view.all`'u olmayan şube satışçısı açtığı firmayı göremiyor (EGT-219 kapsam maddesi 5, heyet 815 F-1; EGT-216'da potansiyel müşteriden dönüşümde zaten böyle) | `SessionScopeResolver`, `OnboardCustomer` |
| **Kullanıcı** | yalnız kendi kapsamındaki düğümlerin üyeleri; şube dışındaki kişi listede de detayda da yoktur (§5) | `OfficeUsers`, `UserPolicy` |
| **Potansiyel müşteri** | sahibi şubesinde olanlar (kapsamına göre) | EGT-216, `PotentialCustomersInReach` |
| **Teklif** | sahibi şubesinde olanlar (kapsamına göre) | `SalesQuotes`, `QuotePolicy` |
| **Talep** | bugünkü kural (kapsam + atanmış firma) | `TrainingRequestQueue` |
| **Şubenin planladığı eğitim** | ⛔ *planlarken seçilir* (Sets, 20.10.2026) — §7.1 | |
| **Merkezin planladığı kapalı eğitim** | ⛔ *planlarken seçilir* (Sets, 20.10.2026) — §7.2 | |
| **Herkese açık eğitim** | ⛔ *eğitim başına seçilir* (Sets, 20.10.2026) — §7.2 | |
| **Kapsamsız (eski) eğitim** | ⛔ **yalnız merkeze** görünür *(Sets, 20.10.2026: "kapsam ayarı yapmadıysa sadece merkeze gözüksün")*. Mevcut eğitimlerin verisi yeniden yazılmaz; bu durum teslimde Tayfun'a açıkça yazılır | |
| **Eğitmen** | §8 | |
| **Takvimim, Satış kokpiti** | ⛔ teklif **ya da** potansiyel müşteri yetkisiyle açılır; kişi **yalnız kendisiyle ilgili** verileri görür *(Sets, 20.10.2026)* | |
| **Mali tablo** | §9 | |

---

## 7. Eğitimin görünürlüğü

### 7.1 Şubenin planladığı eğitim

⛔ *(Sets, 20.10.2026)* **Kimin göreceği planlarken seçilir.** Planlama formu, talep formunun bugün taşıdığı kapsam seçimini (`kişi` / `grup` / `herkes`) taşır.

⛔ *(Sets, 20.10.2026)* *"Kendi şubesi olarak açılsın, merkez seçebilmek için yetkisi varsa seçebilsin yoksa onay gereksin."*

- Form **yalnız kendi şubesi** seçili açılır.
- Kapsamı şubenin dışına (merkez ya da başka şube) genişletmek **ayrı bir yetkidir**; yetkisi olan doğrudan seçer.
- Yetkisi olmayan seçebilir ama genişletme **onaya düşer**; onaylanana kadar eğitim yalnız kendi şubesine görünür. ⛔ **Merkezin Planlama Direktörü onaylar** *(Sets, 20.10.2026)*: onay kuyruğuna düşer, kimse kendi isteğini onaylayamaz (AD-23 güvenlik kuralı 2).

### 7.2 Merkezin planladığı eğitim — açık da kapalı da

⛔ *(Sets, 20.10.2026)* **Eğitim başına seçilir:** merkez eğitimi planlarken — herkese açık da olsa, belirli firmalar için kapalı da olsa — hangi şubelerin göreceğini seçer.

⚠ Bu, bugünkü «açık eğitim herkese görünür» ve «kapalı eğitim o firmalara atanmış satışçıya görünür» kurallarını **şubeler için** değiştirir; merkezin içindeki görünürlük değişmez (§11 S-5 ile birlikte okunur).

---

## 8. Eğitmenler

| Durum | Kural | Kaynak |
|---|---|---|
| Şubede **eğitmen** yeteneği var | şubenin eğitmenleri Eğitmen kadrosu → {şube} düğümündedir; şube planlamacısı kendi eğitmenlerini atar | §2.2 |
| Şubede eğitmen yeteneği **yok**, planlama var | ⛔ planlamacı **yalnız merkezin o şubeye açtığı eğitmenleri** atar *(Sets, 20.10.2026)* | |
| Merkez planlamacısı | ⛔ şube eğitmenlerini **atayabilir, kapsamı yetiyorsa** *(Sets, 20.10.2026)* |
| Aday listesi hangi yetkiyle | ⛔ **eğitmen atama yetkisiyle** (`training.assign_instructor`, planlama yeteneğine ait) *(Sets, 20.10.2026 — heyet 815 F-6)*: aday listesi açılan eğitmenleri ad, yetkinlik ve müsaitlikle gösterir; eğitmen dosyasını açmaz. `instructor.view` (eğitmen yeteneğine ait) bu listeyi açmak için gerekmez. | |

«Açtığı» merkezin bir eğitmen × şube eşlemesi tutması demektir. ⛔ **Ofiste, eğitmen dosyasında seçilir** *(Sets, 20.10.2026)*: eğitmenin dosyasında hangi şubelere açık olduğu işaretlenir. ⚠ Bu alanın çizilmiş tasarımı yoktur; ⛔ **mevcut parçalarla** kurulur *(Sets, 20.10.2026)* — eğitmen dosyasına mevcut çoklu seçim bileşeniyle «Açık olduğu şubeler» alanı.

---

## 9. Mali tablolar

⛔ *(Sets, 20.10.2026)* *"Şube eğer açılırsa kendi mali tablolarını görebilir ama bu yetki verilmezse göremez. Merkez tarafında da şube bazlı kırılımı görebilmemiz gerekir raporlarda."*

- Mali tabloyu görmek **ayrı bir yetkidir** (bugünkü `financial.view`); şubeye verilirse şube **yalnız kendi** rakamlarını görür.
- Merkez raporları **şube kırılımı** gösterir.
### 9.1 3E şirketleri — fatura kesen tüzel kişiler

⛔ *(Sets, 20.10.2026)* Fatura kesen şirket şubeden ayrı bir kavramdır: 3E Group'un altında birden fazla tüzel kişi vardır (3E Danışmanlık, STTMGD, 3E Akademi…) ve *"biz bu firmalardan biri üzerinden fatura kesebilmek istiyoruz"* talebi şube talebiyle aynı şeydir — *"olması gereken oluyor."*

- Backoffice'te **3E şirketleri** listesi tanımlanır: unvan, vergi dairesi, vergi numarası, adres, antet ve **kendi fatura serisi**. Bugünkü tek kimlik (`config/business.php` → `company.*`) bu listenin ilk kaydı olur.
- ⛔ **Ayrı şirket, ayrı seri** *(Sets, 20.10.2026: "ayrı firma için ayrı seri olmak zorunda")*. Her şirketin numarası kendi sırasını izler.
- ⚠ **Ölçüldü (20.10.2026) — spec'in ilk hâli gerçeğe uymuyordu:** bugünkü `FT-2026-7K4M` bir **referans kodudur**, bilerek rastgele üretilir (R-2, `ReferenceCode::generate`) ve yasal fatura numarası değildir; sıralı numara ve **fatura belgesi** sistemde hiç yoktur; şirket kimliğinde vergi numarası alanı yoktur (`company.*`). ⛔ *(Sets, 20.10.2026)* *"Şimdi sıralı numara + belgeyi yapalım, belge için brief ver ben tasarımcıya ileteyim."*
- **Fatura numarası** = şirketin 3 harfli seri öneki + yıl + 9 haneli sıra (`ABC2026000000042`) *(Sets, 20.10.2026)*. Fatura **kesildiği anda** verilir; numara boşluksuz ve tekrarsızdır; iptal edilen fatura numarasını korur (yeni numara yeniden kesilen faturanındır). Referans kodu (`FT-…`) ayrıca kalır — sistem içi koddur, telefonda söylenendir. ⚠ Biçim bilinen e-fatura biçimidir; muhasebeci teyidi Sets'tedir.
- **Bu özellikten önce kesilmiş faturalar** (heyet 818 F-1): ⚠ ölçüldü — **production'da kesilmiş fatura yoktur** (0, 20.10.2026); yalnız geliştirme ve local prod ortamlarında demo faturalar vardır. Kural: sıralı numara **geriye dönük verilmez**; bu faturalar numarasız kalır ve belgede «numarasız (eski kayıt)» basılır. Her şirketin serisi kendi ilk faturasında 1'den başlar. Numarasız eski faturanın iptali yeni bir numara doğurmaz; yerine kesilen fatura normal sırayla numara alır.
- **Fatura belgesi** yazılır: brief `docs/design/fatura-belgesi-brief.md`, tasarım tasarımcıdan gelecek. Belge kesilmiş ve iptal edilmiş faturada açılır (ofis + müşteri portalı); faturaya sabitlenen şirket kimliğiyle basılır.
- Şirket kaydı ayrıca **banka hesaplarını** (banka · şube · IBAN, birden fazla) ve belgedeki **yasal ibare** metnini taşır *(Sets, 20.10.2026)*; ikisi de belgeye basılır. İbare metni Sets'ten gelecek.
- Şahıs müşterinin T.C. kimlik numarası belgede **açık** basılır *(Sets, 20.10.2026)*; hassas alan okuması olduğu için belgenin her açılışı **erişim loguna** yazılır (kırmızı çizgi 13, AD-21).
- ⛔ **Şube kurulurken şirketi seçilir** *(Sets, 20.10.2026)*. Merkezin de bir şirketi vardır.

### 9.2 Faturayı kim keser

- Varsayılan: faturanın **gelir şubesinin** (§9.3) şirketi.
- ⛔ **Faturayı kesen kişi, yetkisi varsa, başka bir 3E şirketini seçer** *(Sets, 20.10.2026)*. Bu ayrı bir yetkidir (yeteneğe bağlı değil, §11.1).
- ⛔ Seçilen şirket **fatura kesildiği anda belgeye sabitlenir** — unvan, vergi numarası, antet ve seri numarası o anın kopyasıdır (heyet 815 F-2). Kesildikten sonra şirket de gelir şubesi de değişmez; düzeltme **iptal + yeniden kesim** ile yapılır (fatura iptali bugün de böyledir). İptal ve iade, iptal edilen faturanın şirketiyle yapılır.
- Teklif belgesi teklifi yazanın şubesinin şirketinin unvanı ve antetiyle çıkar; teklifte şirket değişikliği de aynı yetkiyle yapılır. Müşteri teklifle faturayı aynı şirketten görür — fatura anında şirket değiştirilirse bu bilerek yapılmış bir seçimdir ve audit'e yazılır.
- e-fatura entegrasyonu bugün yoktur (AD-12); geldiğinde gönderici faturaya sabitlenen şirkettir.

### 9.3 Gelir hangi şubenin

⛔ *(Sets, 20.10.2026 — önerinin kabulü)* Her faturada **«gelir hangi şubenin»** alanı vardır.

| Soru | Kural |
|---|---|
| Değer kümesi | merkez ya da bir şube (heyet 815 F-3) |
| Teklifli fatura varsayılanı | teklifi yazan kişinin şubesi |
| Teklifsiz fatura (serbest kalem, bağımsız katılımcı) varsayılanı | faturayı kesen kişinin şubesi |
| Mevcut faturalar | **merkez** (veri yeniden yazılmaz; alan boşsa merkez okunur — kapsamsız eğitim kuralıyla aynı) |
| Değiştirme | fatura **kesilmeden önce**, faturayı kesen kişi (`invoice.create`); kesildikten sonra §9.2 |
| Audit | her değişiklik |

Şubenin mali tablosu, merkezin şube kırılımı ve fatura görme kapsamı (S-12) bu alana dayanır.

### 9.4 Gider hangi şubenin

⛔ *(Sets, 20.10.2026 — heyet 815 F-4)* *"Eğitim planlamasını 3E merkez yaptı, İzmir şubesinin eğitmenleri ile eğitimi verdi, faturayı da siz kesin dedi. Bu noktada kimin olacak bu? Bence seçebilmeleri gerekir."*

- Her **eğitimde** «gider hangi şubenin» alanı vardır; eğitimin giderleri (eğitmen hakedişi, onaylı masraf, eğitim maliyet kalemleri — `FinancialOverview`'un üç gider akışı) bu şubeye yazılır.
- Varsayılanı eğitimi **planlayan** şubedir (merkez planladıysa merkez); planlama yetkisi olan değiştirir; değişiklik audit'lenir.
- Mevcut eğitimler **merkez**.
- Marj (gelir − gider) şubeye göre §9.3 ve §9.4'ün birlikte okunmasıyla çıkar; bir eğitimin geliri ile gideri farklı şubelerde olabilir ve bu bilerek görünür.

### 9.5 Şube kapanınca ya da yetenek kalkınca mali kayıtlar

⛔ (heyet 815 F-8) Kesilmiş faturalar sabitlenen şirketiyle ve gelir şubesiyle **tarihçede kalır**; kapanış onları yeniden yazmaz. Şirket şubeden ayrı bir kayıt olduğu için şube kapanması şirketi kapatmaz. Kapanıştan sonraki iptal/iade, faturanın kendi şirketiyle yapılır. Kapanan şubenin raporları geçmiş dönemler için okunabilir kalır. Henüz kesilmemiş faturalar ve gider şubesi kapanan şube olan açık eğitimler, §4'ün atama sorularına girer.

## 10. Kabul kriterleri (taslak)

1. Backoffice'te şube ad ve yeteneklerle kurulur; seçilen her yetenek için doğru dikeyin altında düğüm açılır.
2. Yalnız şube düğümüne üye kişi, her listede yalnız kendi şubesinin kayıtlarını görür (§6 tablosunun her satırı ayrı test).
3. Şubede kapalı bir yeteneğin yetkisi o şubenin üyesine verilemez; ekran nedenini yazar; verilmiş olsa bile çalışmaz.
4. Şube yöneticisi yalnız kendi şubesine ve yalnız yetkisi varsa kullanıcı açar.
5. Şube planlamacısı eğitimi planlarken kimin göreceğini seçer.
6. Merkez açık eğitim açarken hangi şubelerin göreceğini seçer; seçilmeyen şube o eğitimi görmez.
7. Eğitmen yeteneği olmayan şubenin planlamacısı yalnız merkezin o şubeye açtığı eğitmenleri atayabilir.
8. Şube, yetkisi varsa yalnız kendi mali rakamlarını görür; merkez raporlarında şube kırılımı vardır.
9. Merkez kullanıcılarının bugünkü görünürlüğü **değişmez** (geri dönük uyumluluk; §11 S-5 ile birlikte).
10. Şubeden yetenek kaldırma ve şubeyi kapatma, düğümde kişi ya da açık iş varken önce uyarır ve ad ad listeler — açık işe kesilmemiş faturalar ve gider şubesi o şube olan açık eğitimler dahildir; atama soruları cevaplanmadan hiçbir şey taşınmaz; cevaplanınca taşınır ve işlem tamamlanır. Kişi ve kayıt silinmez.
11. Kapsamı ayarlanmamış eğitim yalnız merkeze görünür; şubeye görünmez.
12. Takvimim ve Satış kokpiti teklif ya da potansiyel müşteri yetkisiyle açılır ve kişiye yalnız kendisiyle ilgili kalemleri gösterir.
13. Şube planlamacısının planlama formu «kendi şubesi» seçili açılır; şube dışına genişletme, yetkisi yoksa merkezin Planlama Direktörüne onaya düşer ve onaylanana kadar eğitim yalnız şubeye görünür.
14. Merkez planlamacısı, kapsamı yetiyorsa şube eğitmenini atar.
15. Eğitmen dosyasında eğitmenin hangi şubelere açık olduğu seçilir; eğitmen yeteneği olmayan şubenin planlamacısı yalnız bunları görür.
16. Her faturada «gelir hangi şubenin» alanı vardır (merkez ya da bir şube): teklifli faturada varsayılanı teklifi yazanın şubesi, teklifsiz faturada faturayı kesenin şubesi, alanı boş olan mevcut faturada merkezdir; kesimden önce değiştirilebilir, kesimden sonra değişmez; her değişiklik audit'lenir; şube mali tablosu, merkez kırılımı ve fatura kapsamı bu alana göre çalışır.
17. Fatura yetkisi kapsamlıdır (`own`/`group`/`all`); şube üyesi yetkisi kadarını görür.
18. Backoffice'te 3E şirketleri tanımlanır, şube kurulurken şirketi seçilir; fatura varsayılan olarak gelir şubesinin şirketiyle, yetkisi olan seçtiğiyle kesilir; şirket ve seri numarası kesim anında belgeye sabitlenir ve sonradan değişmez.
26. Kesilen faturaya şirketin serisinden sıralı, boşluksuz ve tekrarsız bir fatura numarası verilir; eşzamanlı iki kesim aynı numarayı alamaz; iptal edilen fatura numarasını korur. Bu özellikten önce kesilmiş fatura numarasız kalır, belgede «numarasız (eski kayıt)» basılır ve seriyi etkilemez.
27. Kesilmiş ve iptal edilmiş fatura ofiste ve müşteri portalında belge olarak açılır; belge faturaya sabitlenen şirket kimliğini, banka hesaplarını ve yasal ibareyi basar; iptal edilmiş fatura «İPTAL EDİLDİ» işaretiyle okunur kalır; şahıs müşterinin kimlik numarası açık basılır ve açılış erişim loguna yazılır.
19. Her eğitimde gider şubesi vardır (varsayılan planlayan şube); şube mali tablosu ve merkez kırılımı gelir ve gideri bu iki alana göre gösterir.
20. Firmayı açan kişi o firmaya kendiliğinden atanır ve firmayı görür.
21. Menüler şubeye göre değişmez: aynı yetkideki merkez ve şube kullanıcısı aynı menü kalemlerini görür; yalnız içerik daralır.
22. Şube üyesi kullanıcı listesinde ve detayında şube dışındaki kişiyi görmez.
23. İki şubede üyeliği olan kişide yetenek tavanı düğüm başına işler.
24. Eğitmen yeteneği olmayan şubenin planlamacısı, açılan eğitmenleri eğitmen atama yetkisiyle aday listesinde görür; eğitmen dosyasını açamaz.
25. Şube kapandıktan sonra o şubeye yazılmış kesilmiş faturalar, sabitlenen şirketi, seri numarası ve gelir şubesiyle değişmeden kalır; şirket kaydı kapanmaz; kapanan şubenin geçmiş dönem raporları okunabilir; kapanış sonrası iptal/iade faturanın kendi şirketiyle yapılır.

---

## 11. Açık kalanlar — hepsi kapandı (20.10.2026)

| # | Soru | Neden gerekli |
|---|---|---|
| S-1 | ✅ *kapandı (20.10.2026)* — §11.1 |
| S-2 | ✅ *kapandı* — §4 |
| S-3 | ✅ *kapandı* — §4 |
| S-4 | ✅ *kapandı* — §7.2 |
| S-5 | ✅ *kapandı* — §6 |
| S-6 | ✅ *kapandı* — §6 |
| S-7 | ✅ *kapandı* — §7.1 |
| S-8 | ✅ *kapandı* — §8 |
| S-9 | ✅ *kapandı* — §8 |
| S-10 | ✅ *kapandı* — §9.3 |
| S-11 | ✅ *kapandı* — §7.1 |
| S-12 | ✅ *kapandı* — fatura yetkisine kapsam eklenir (`own`/`group`/`all`), şube üyesi yetkisi kadarını görür *(Sets, 20.10.2026: "yetkisi kadarını")*. Bir faturanın kimin kapsamında olduğu §9.3'e bağlıdır; `own` = faturayı kesen kişinin kendi faturaları, `group` = gelir şubesi kişinin kapsamındaki faturalar, `all` = tümü (heyet 815 F-3). |
| S-13 | ✅ *kapandı* — §9.1 |
| S-14 | ✅ *kapandı* — §9.2 |

---

### 11.1 S-1 için öneri — yetenek × yetki

⚠ Sets 20.10.2026'da öneriyi bir düzeltmeyle kabul etti (aşağıda).

| Yetenek | Yetkiler (temel adlar; kapsam eki ayrıca) |
|---|---|
| **Satış** | `customer.view`, `customer.create`, `customer.update`, `customer.deactivate`, `potential_customer.*`, `quote.view`, `quote.create`, `quote.update`, `quote.approve`, `discount_limit.approve`, `training_request.view`, `training_request.create`, `training.manage_participants`, `training.announce`, `content_package.view`, `content_package.grant`, `user.assign_customers` |
| **Planlama** | `training.create`, `training.update`, `training.approve`, `training.cancel`, `training.cancel_approve`, `training.assign_instructor`, `training.notify_ministry`, `training.recording.view`, `training.recording.record`, `training_request.update`, `supplier.view`, `supplier.create`, `supplier.update` |
| **Eğitmen** | `instructor.view`, `instructor.update`, `instructor.request_documents`, `instructor.reveal_identifier`, `instructor.view_ledger`, `instructor.record_payment`, `expense.approve` |
| **Yeteneğe bağlı değil** (yetkisi verilirse her şube üyesinde çalışır) | `training.view` (satış da planlanmış eğitimi görmeli), `user.view`, `user.create`, `user.update`, `user.deactivate`, `user.assign_permissions` (§5), `document.view`, `document.upload`, `document.download`, `document.view_special_category`, `financial.view` (§9), `analytics.view`, `audit.view`, `invoice.*`, `institution_document.*`, `document_template.*` |

⛔ *(Sets, 20.10.2026)* *"Eğer yetki varsa fatura, kurum belgesi gibi şeyleri de görebilmesi gerekir."* Öneride «şubeye verilmez» diye ayrılan satır kaldırıldı: fatura, kurum belgesi ve belge şablonu yetkileri şube üyesine verilebilir. ⚠ Faturanın **hangi şubeninkini** göstereceği §9.3'e bağlıdır (bugün faturalar kapsamsızdır). Fatura kesen şirketi değiştirme (§9.2) ayrı bir yetkidir ve yeteneğe bağlı değildir.

## 12. Kapsam dışı — adresi yazılı

| Konu | Adres |
|---|---|
| Şubeye özel fiyat listesi | istenmedi; fiyat listesi tektir (fiyatlama-spec) |
| e-fatura entegrasyonu | AD-12; entegratör gelince gönderici §9.2'deki kimlik olur |
| Müşteri portalında şube kavramı | portal şubeyi bilmez; firma merkeze de şubeye de aynı firmadır |

## 13. Revizyon geçmişi

| Sürüm | Tarih | Değişiklik |
|---|---|---|
| v0.1 | 20.10.2026 | Taslak; §11'deki on soru açık |
| v0.2 | 20.10.2026 | Sets'in 14 kararı işlendi (S-1…S-14); §9.1 gelir ataması, §9.2 fatura kesen şirket, kabul kriterleri 10–18 |
| v0.3 | 20.10.2026 | Heyet 815 (REJECTED, F-1…F-8) + Sets'in dört kararı: §9 yeniden yazıldı — 3E şirketleri ayrı kavram (şubeye seçilir, yetkiyle faturada değişir, kesimde sabitlenir, ayrı seri), gelir alanının değer kümesi/varsayılanları/mevcut faturalar, gider şubesi eğitimde seçilir, kapanışta mali kayıtlar; §3 tavan düğüm başına; §6 açanın atanması ve kullanıcı satırı; §8 aday listesi atama yetkisiyle; kriterler 18–24 |
| v0.4 | 20.10.2026 | Heyet 816 F-1: kriter 16 §9.3'ün üç varsayım dalını, kriter 10 kapanıştaki mali kalemleri sayar; kriter 25 §9.5'in dört iddiası |
| v0.5 | 20.10.2026 | Plana başlarken ölçüldü: fatura no rastgele referans kodu, fatura belgesi yok, vergi no alanı yok. Sets kararı: sıralı numara (3 harf + yıl + 9 hane) ve belge şimdi; banka hesapları ve yasal ibare şirkette; TCKN belgede açık + erişim logu; brief `docs/design/fatura-belgesi-brief.md`; kriter 26–27 |
| v0.6 | 20.10.2026 | Heyet 818 F-1: eski faturalar — production'da 0 fatura (ölçüldü); geriye dönük numara verilmez, numarasız kalır; seri 1'den başlar; kriter 26'ya eklendi |