# Satıştan planlamaya talep — iki ekran · tasarım brief'i *31.07.2026 · Sets'in talebi · kaynak: çatı §10, §148–152, `planlama-spec.md` §2.3/§7/P-37, `docs/design/musteri-portali-brainstorm.md` K-18/K-19/K-20* İki ekran isteniyor: satışçının **talep açtığı** ekran, ve bu taleplerin **listelendiği** ekran. Listede planlamacı *"bunu plana çevir"* dediğinde, plan sayfası talepteki bilgilerle **dolu** açılır. Bugün elde hiçbiri yok. Veri tarafı yarım var (`training_requests`), ama aşağıdaki §6'da yazdığı gibi bu ekranların istediği şekli taşımıyor — tablo bu brief'e göre yeniden kurulacak. --- ## 1. Neden var: satışçı eğitim yaratamaz ⛔ Çatı §102: *"planlamacının oluşturmadığı hiçbir eğitim için satışçı işlem yapamaz."* Satışçının teklif hazırlarken bir eğitimi görebilmesi için planlamacının onu **planlamış** olması gerekir. Ama müşteriyle temas noktası satışçıdır. Talep ondan doğar. Bu yüzden satışçının kapısı "eğitim yaratma" değil **"talep açma"**dır: talep planlamacının kuyruğuna düşer, planlamacı planlar, satışçı sonra o planlanmış eğitim üzerinden teklif keser. **Gerçek senaryo** *(Sets, 31.07.2026 — ekranın varlık sebebi budur)*: > İskenderun bölgesinde bir potansiyel görülüyor: 3 ay sonra çok sayıda sertifika süresi doluyor. Satışçılar planlamaya bildiriyor — *"İskenderun tarafında şu eğitimler için açık eğitim planlayalım, biz müşterileri aramaya başlayalım."* Planlama açık eğitim programını hazırlıyor, satışçılar bunu potansiyel müşterilere pazarlıyor. Yani talep **tek müşteriden gelmek zorunda değildir**; bir bölge ve bir zaman aralığı için de açılır. Ekranın şekli bunu taşımalı. --- ## 2. ⛔ "Açık eğitim" ne demek — yaygın yanlış anlama **Açık/kapalı ayrımı, eğitimin SATIŞÇILARA görünürlüğünü belirler; müşterilere değil** *(Sets, 31.07.2026)*. - **Açık** — tüm satışçılara görünür, herhangi bir müşteriye satılabilir - **Kapalı** — belirli firmaya/firmalara özel ⛔ **Müşterinin önüne bizim plan ya da eğitim listemiz ASLA düşmez.** Müşteri portalında "açık eğitimlere kayıt ol" diye bir yer yoktur. Tanıtım en fazla **mailing** ile yapılır; panelden kendi kendine kayıt yoktur. İleride böyle bir şey planlanırsa ayrıca kurgulanır. ⚠ **Bu, `16 Musteri Belgeler`'de çizili "Açık eğitim duyuruları · `/portal/acik-egitimler`" bloğunu kapsam dışı bırakır.** Tasarım Uygulama Protokolü gereği sapma yalnız Sets söylediğinde olur — bu, **söylenmiş ve onaylanmış** bir sapmadır (31.07.2026). `16`'nın geri kalanı (sertifikalar, içerik paketleri, faturalar) aynen geçerlidir. ⚠ **İleriye dönük not — bugün tasarlanmıyor, ama kontrol buna hazır dursun.** Sonraki bir turda görünürlüğe üçüncü bir değer eklenmesi planlanıyor: *"müşterilere de görünsün"*. O geldiğinde müşteri panelinde "planlanmış ve yer olan açık eğitimler" listesi ve yanında "teklif al" eylemi olacak. **Bu turda çizilmez**; yalnız açık/kapalı kontrolü iki değerli bir anahtar yerine üçüncüyü kaldırabilecek bir kontrol olsun (Sets, 31.07.2026 — bilinçli erteleme). ⚠ Açık eğitim de **satış sürecinden ve faturalaşmadan** geçer. "Açık" olması teklifsiz olduğu anlamına gelmez — her koltuk yine teklif → onay → fatura zincirinden gelir. --- ## 3. Ekran A — Talep oluşturma (satışçı) Satışçının doldurduğu alanlar: | Alan | Not | |---|---| | **Hangi eğitimler** | ⚠ **Çoğul.** Bir talep birden çok eğitim tanımı taşır ("şu üç eğitim için"). Aranabilir çoklu seçim; mevzuata göre gruplu (`65`'teki desenin aynısı) | | **Hangi bölge** | Serbest metin **değil** — il seçimi. Planlamacı buna göre yer arayacak | | **Hangi tarihler** | Bir aralık ("3 ay sonra", "Mart'ın ilk yarısı"). Kesin gün değil — kesin günü planlamacı koyar | | **Açık mı kapalı mı** | §2'deki anlamıyla: satışçılara mı açık, belirli firmaya mı özel | | **Kimin göreceği** | ⚠ **Sonradan eklendi** *(Sets, 31.07.2026 — K-30)*: açık talepte bile görünürlük kapsamlıdır. *"Tüm satışçılar görsün"* ya da *"şu grup / seçili satışçılar görsün"*. Yalnız İzmit grubunu ilgilendiren bir program diğer satışçıları meşgul etmemeli. Grup, ofis kullanıcı ağacıdır — yeni kavram değil | | **Davet edilecek firmalar** | Yalnız **kapalı** seçilince görünür. Çoklu firma seçimi ⚠ satışçı yalnız **atandığı** firmaları görür (AD-23, P-37) | | **Tahmini katılımcı sayısı** | Planlamacının kontenjan kararına girdi | | **Not / gerekçe** | *"İskenderun'da 30 kişinin sertifikası Mart'ta doluyor"* — planlamacının önceliklendirmesi buna bakar | Talebin kendisi bir **referans kodu** taşır (AD-19) — satışçı ile planlamacı aynı şeyden bahsettiğini bilsin. ⚠ Kapalı seçilip firma seçilmemesi, ya da açık seçilip firma seçilmesi **çelişkidir**; ekran bunu ilk anda göstermeli, kaydettikten sonra değil. ## 4. Ekran B — Talep listesi (planlamacı + satışçı, farklı kapsamla) Bir kuyruk. Her satır: referans kodu · eğitimler · bölge · tarih aralığı · açık/kapalı · talep eden · bekleme süresi · statü. - **Planlamacı** hepsini görür ve **"Bunu plana çevir"** der → plan sayfası (`24`) talepteki bilgilerle **dolu** açılır: eğitimler seçili, bölge seçili, tarih aralığı önerilmiş, kapalıysa firmalar bağlı. Planlamacı üstünde çalışır ve kaydeder. - **Satışçı** yalnız **atandığı firmaların** taleplerini görür (P-37) ve kendi açtığının nerede olduğunu takip eder. ⛔ **Bekleme süresi ve SON HAMLE satırda görünür** *(Sets, 31.07.2026 — pazarlıksız)*. İkisi ayrı bilgidir ve ikisi de gerekir: - **Ne kadardır bekliyor** — "9 gündür bekliyor" - **Son hamleyi kim yaptı, ne dedi** — *"Satışçı, Pzt: teklife dönüşünüzü bekliyorum"* · *"Müşteri, Çrş: haftaya salıya kadar izindeler, dönünce cevap verecekler"* Gerekçe Sets'in kendi cümlesi: *"bu noktada giren kişi de en azından neyi beklediğini görmüş olur."* Yalnız süre gösteren bir satır **yanıltıcıdır** — dokuz gün bekleyen bir talep, cevabı gelmiş ve topu bizde olan bir talep de olabilir, karşı taraftan haber beklenen bir talep de. İkisi aynı görünürse yanlış olanı kovalanır. ⚠ **Satırdan hatırlatma eklenebilmeli.** Yukarıdaki örnekte doğru hamle, satışçının *"salı günü hatırlatılacak"* diye görev açmasıdır — ekran bunu bir tık uzakta tutmalı, yoksa hatırlatma satışçının aklında kalır ve orada kaybolur. Görev altyapısı mevcut (`tasks`). ⚠ **Aynı ilke teklif tarafında da geçerlidir** (`13`/`31`): orada da bekleyen taraf ve son hamle görünür olmalı. Sets'in örneği zaten bir teklif yazışmasıydı. ⚠ Planlamacının **reddetme** yolu da olmalı, gerekçesiyle — talep karşılıksız kalmaz (`training_requests.decline_reason` bugün de var). Statüler: `açık` → `planlandı` (bir eğitime/pakete bağlandı) → ya da `reddedildi`. ## 5. Hangi ekranın içinde yaşayacak `planlama-spec.md:545` kuyruğu `20 Planlamaci Sorgulama` içine koymuş. **Ekran B için bu geçerli** — planlamacının sorgulama ekranı zaten "nerede ne kadar potansiyel var" sorusunu cevaplıyor, talep kuyruğu onun doğal komşusu. **Ekran A ayrıdır** ve satışçının tarafındadır: talep, satışçı müşteriyle konuşurken doğar. Tasarımcı bunun satışçı panelinde nereden açıldığına karar versin (`30 Satisci Dashboard`'dan mı, `32 Satisci Musteri Karti`'ndan mı, ikisinden de mi). ## 6. ⚠ Geliştiriciye not — mevcut tablo bu şekli taşımıyor `training_requests` (`2026_08_14_000500`) bugün şunu varsayıyor: **tek müşteri, tek eğitim tanımı**. | Bugün | Bu brief'in istediği | |---|---| | `tenant_id` **NOT NULL** + `customers` FK + `TenantPolicy::apply` (RLS) | Açık talebin müşterisi **yok** — tablo bunu reddediyor | | tek `training_definition_id` | **çoğul** eğitim | | `location_note` serbest metin | **il seçimi** | | görünürlük alanı yok | **açık/kapalı** | | davet listesi yok | **çoklu firma** | ⛔ Bu, mevcut tabloya kolon eklemek değil: talebin **sahibi değişiyor**. Müşteriden gelen talep tenant-kapsamlı kalır; satışçıdan gelen talep **ofis tarafında** yaşar ve kapsam kontrolüyle açılır — K-22'nin (teklif ofiste yaşar, müşteriye açılır) aynısı. ⚠ RLS politikası değişikliği kırmızı çizgi 1'e (tenant data leak) dokunur; şema kararı plan aşamasında yazılacak ve ayrıca gözden geçirilecek.