TEKNİK — TEMEL MODÜL

Altındaki her şey buna bağlı. Burada tanımlanan veri olmadan ne sipariş, ne üretim, ne de test başlayabilir.

Şubat 2026 • Solen Kablo • Yaşayan Doküman

1. TEKNİK NE YAPAR

Teknik modülü, tüm fabrikanın bağlı olduğu beş soruyu yanıtlar:

1. Hangi kabloları üretebiliriz? — Cable Playground tasarımları yapar. Cable Database onaylanan sonuçları saklar. Her kablo, kesin parametrelerle sıralı makine adımları olarak tanımlanır.
2. Hangi makinelerimiz var? — Makine Yönetimi, 7 makine tipini fiziksel kapasiteleriyle (hız aralıkları, çap limitleri, kalınlık aralıkları) kayıt altına alır. Playground bunları kullanarak tasarımın fiziksel olarak üretilebilir olduğunu doğrular.
3. Hangi kalite standartları karşılanmalı? — Standart Yönetimi her testi (IEC-EN, UL, SLN) parametreleri, geç/kal kriterleri ve test frekanslarıyla tanımlar. Bunlar kablo tasarımlarına bağlıdır — her tasarım hangi üretim adımında hangi testlerin gerektiğini bilir.
4. Kablonun üzerine ne yazılır? — Markalama, ekstrüderin üretim sırasında yazdığı sıralı kelime dizilerini tanımlar (şirket adı, standart, voltaj, kesit vb.).
5. Makineleri kim kullanır? — Operatör Yönetimi, üretim oturumlarına atanan operatörlerin kaydını tutar.

2. VERİ AKIŞI

Veri tek yönde akar: Teknik’ten dışarıya. Her alt modülün sistemi nasıl beslediği aşağıda gösterilmiştir.

Kablo Veritabanı birleşme noktasıdır. Tamamlanmış tasarımı yapılandırılmış JSON olarak saklar: eksiksiz üretim akışı, oluşturulacak her yarı mamul, hammadde listesi ve tüm test gereksinimleri. Sipariş malzeme ihtiyacını hesaplarken veya Üretim iş kartları oluştururken Kablo Veritabanı’ndan okur — asla doğrudan Playground veya Makinelerden değil.

3. VERİTABANI KATMANI

Teknik modülüne 12 tablo hizmet eder. Dört gruba ayrılırlar:

Makine Tabloları (7)

Her makine tipi için bir tablo. Her biri o makinenin fiziksel kapasitesini min/maks/artış aralıkları olarak saklar. Sistem bu aralıklarda ilerleyerek açılır menü seçeneklerini oluşturur.

Her yapılandırılabilir parametrenin veritabanı seviyesinde CHECK kısıtlaması vardır: max > min, increment > 0, min ≥ 0. Bu, geçersiz makine konfigürasyonlarının kaydedilmesini imkansız kılar — veritabanı fiziksel tutarlılığı kendi başına zorlar.

Tasarım Tabloları (3)

İlişki: CableDesign → birden fazla DesignStep (kademeli silme) → tamamlamada bir CableDatabase kaydı. Kablo Veritabanı her şeyi denormalize JSON blob’ları olarak saklar — bilerek. Malzeme Hesaplayıcı bir sipariş için bakır gereksinimini hesaplaması gerektiğinde, cable_database’den tek bir satır okur ve hiçbir join olmadan eksiksiz üretim akışına sahip olur.

Kalite Tabloları (2)

Bir test standardının N parametresi vardır (kademeli silme). Playground’da bir tasarım adımına test atanırken, standart ID ve frekans (başlangıç/bitiş/her makara) adımın JSON’ına gömülür. Bu, Kablo Veritabanı’nın tam test haritasını taşıması demektir — Lab, üretim sırasında Teknik’i sorgulamadan neyi ne zaman test edeceğini bilir.

Destekleyici Tablolar

4. BACKEND MİMARİSİ

Teknik backend’i /api/teknik/ altına monte edilmiş 6 route dosyası ve Playground’un simülasyon motorunu çalıştıran 6 yardımcı modülden oluşur.

Route Dosyaları

Playground Motoru (6 yardımcı modül)

Cable Playground basit bir CRUD sayfası değildir — tamamen bellekte çalışan bir gerçek zamanlı simülasyon motorudur. İşte onu çalıştıran modüller:

5. FRONTEND

/teknik/* altında 7 sayfa, canTeknik erişim bayrağıyla korunur. Tüm sayfalar Ant Design Pro’nun ProTable bileşenini Türkçe yerel ayar, istemci taraflı arama ve bulanık arkaplan modallarıyla kullanır.

Cable Playground tek başına frontend kodunun yarısından fazlasını oluşturur. Modüler bir bileşen sistemi olarak inşa edilmiştir: usePlayground hook’u durum ve API çağrılarını yönetir, FlowCanvas SVG diyagramını çizer, MachineLibrary yan panel paletidir, ConfigurationDrawer 6 makineye özgü formu barındırır (1.215 satır) ve ProgressionPanel gerçek zamanlı malzeme takibini gösterir.

6. ALT MODÜLLER

Aşağıdaki bölümler her alt modülü tam detayıyla belgeler — her form alanı, her API endpoint, her veritabanı sütunu, her doğrulama kuralı ve arkasındaki tasarım kararları. Temel veriden onu tüketen araçlara doğru sıralanmıştır.

6.1 MAKİNE YÖNETİMİ

Bir kablo tasarlamadan önce, sisteme fabrikanın hangi makinelere sahip olduğunu söylemeniz gerekir. Makine Yönetimi, üretim katındaki her fiziksel makinenin kaydıdır — markası, modeli ve en önemlisi kapasite aralıkları. Bu aralıklar (hız min/maks, çap min/maks vb.) sistem genelinde açılır menü seçenekleri oluşturmak ve bir kablo tasarımının fiziksel olarak üretilebilir olduğunu doğrulamak için kullanılır.

6.1.1 Yedi Makine Tipi

Fabrikanın üretim hattı, kablo imalat sürecinde her biri belirli bir adımı gerçekleştiren 7 makine tipinden oluşur:

6.1.2 Veritabanı Şeması

7 tablo, her makine tipi için bir tane. Hepsi ortak bir yapıyı (id, brand, model, is_active, created_by, zaman damgaları) ve tipe özgü parametre sütunlarını min/maks/artış üçlüleri olarak paylaşır.

Ortak Sütunlar (7 tablonun tamamı)

Kabatel Çekme — kabatel_cekme_machines

Kalaylama — kalaylama_machines

İncetel Çekme — incetel_cekme_machines

Buncher — buncher_machines

Extruder — extruder_machines

E-beam — ebeam_machines

Aktarma — aktarma_machines

Yapılandırılabilir parametre yok. Sadece ortak sütunlar (brand, model, is_active, zaman damgaları). Ortak olanlar dışında CHECK kısıtlaması yok.

6.1.3 Seçenek Üretimi — Temel Mekanizma

Tüm Makine Yönetimi → Playground hattını çalıştıran mekanizma budur. Playground bir makine parametresi için açılır menü seçenekleri göstermesi gerektiğinde, /options endpoint’ini çağırır; bu da min/maks/artış aralığında ilerleyerek geçerli her değeri döndürür.

def generate_dropdown_options(min_val, max_val, increment):
    options = []
    current = min_val
    while current <= max_val:
        options.append(round(current, 4))  # Kayan nokta kaymasını önle
        current += increment
    return options

# Örnek: speed_min=5, speed_max=25, speed_increment=5 olan makine
# → [5.0, 10.0, 15.0, 20.0, 25.0]

Özel durumlar:

• Tam sayı aralıkları (İncetel Çekme & Buncher girdi sayıları): Float adımlama yerine list(range(min, max + 1)) kullanır — çünkü 3.5 girdi tel olamaz.
• Sabit kodlanmış değerler (Buncher büküm yönü): Doğrudan ["S", "Z"] döndürür — kablo imalatında sadece iki olası büküm yönü vardır.
• Seçenek yok (Aktarma): Hiç /options endpoint’i yoktur — yapılandırılacak bir şey yok.

6.1.4 API Endpoint’leri

Toplam 38 endpoint. Her makine tipi tutarlı bir düzen izleyen 5–6 endpoint alır (Aktarma’nın /options’ı yoktur).

Makine tipi başına düzen ({type} yerine örn. kabatel-cekme)

Ortak endpoint’ler

Tip başına seçenek yanıt şekilleri

6.1.5 Yetki Modeli

Hem eski user_type sistemini hem de granüler yetki sistemini destekleyen check_permission_smart() kullanır:

6.1.6 Frontend — Makineler Sayfası

Tek dosya: pages/Teknik/Machines/index.tsx (726 satır). Route: /teknik/machines, canTeknik erişim bayrağıyla korunur.

Sayfa Yapısı

7 Tabs içeren bir Card’ı saran PageContainer — her makine tipi için bir sekme. Sekme değiştirme o tip için makine listesini getirir ve arama metnini sıfırlar. Varsayılan sekme: Kabatel Çekme.

Tablo Sütunları

Her sekme, şu temel sütunlara sahip bir ProTable ve tipe özgü sütunlar gösterir:

Arama & Sayfalama

Arama istemci tarafındadır: metin girişi yüklü listeyi ID, marka, model veya durum (“aktif”/“pasif”) üzerinden filtreler. Makine sayıları küçük olduğundan (genellikle tip başına <50) sunucu tarafı arama gereksizdir.

Sayfalama varsayılan 10 satır, seçenekler [10, 20, 50, 100]. Toplam “X-Y / Z kayıt” olarak gösterilir.

CRUD Akışı

Oluşturma:

1. Araç çubuğunda “Yeni Makine Ekle” butonuna tıkla
2. “Yeni Makine Ekle” başlıklı modal açılır (600px, bulanık arkaplan)
3. Form aktif sekmeye (makine tipine) göre dinamik alanlar gösterir
4. Gönderimde: POST /api/teknik/machines/{type} form değerleriyle
5. Sistem alanları (id, created_at, updated_at, created_by, input_type, input_code, accepted_input_codes) otomatik olarak hariç tutulur
6. Başarıda: “Makine başarıyla eklendi!” bildirimi, modal kapanır, liste yenilenir

Düzenleme:

1. İşlemler sütununda düzenle ikonuna tıkla
2. “Makine Düzenle” başlıklı modal açılır, mevcut değerlerle doldurulmuş
3. Gönderimde: PUT /api/teknik/machines/{type}/{id} sadece değişen alanlarla
4. Başarıda: “Makine başarıyla güncellendi!” bildirimi, modal kapanır, liste yenilenir

Silme:

1. İşlemler sütununda sil ikonuna tıkla
2. Popconfirm sorar: “Bu makineyi devre dışı bırakmak istediğinize emin misiniz?”
3. Makine zaten pasifse sil butonu devre dışıdır
4. Onayda: DELETE /api/teknik/machines/{type}/{id}
5. Başarıda: “Makine devre dışı bırakıldı!” bildirimi, liste yenilenir

Makine Tipine Göre Form Alanları

Form, aktif sekmeye göre renderFormFields() ile dinamik olarak oluşturulur. Ortak alanlar (Marka, Model) tüm tipler için görünür. Tipe özgü alanlar uygun min, step ve Türkçe etiketlerle InputNumber kullanır:

6.1.7 Servis Katmanı (Frontend)

API çağrıları services/teknik/index.ts içinde sarmalanmıştır ve URL dönüşümü yapılır: makine tipi adındaki alt çizgiler URL yolu için tire ile değiştirilir.

// kabatel_cekme → URL'de kabatel-cekme olur
export async function getMachines(type: MachineType) {
  return request(`/api/teknik/machines/${type.replace('_', '-')}`);
}

export async function createMachine(type: MachineType, data: any) {
  return request(`/api/teknik/machines/${type.replace('_', '-')}`, {
    method: 'POST', data
  });
}

// updateMachine (PUT), deleteMachine (DELETE) için aynı düzen
// getMachineDropdown, Playground kullanımı için /{id}/dropdown çağrır

6.1.8 Diğer Alt Modüllerle Bağlantılar

6.2 STANDART YÖNETİMİ

Satılan her kablo, uluslararası standart kuruluşları (IEC, CENELEC) veya müşteri tarafından tanımlanan kalite testlerini geçmelidir. Standart Yönetimi, bu testlerin tanımlandığı yerdir — neyin ölçüleceği, kaç numune alınacağı, hangi parametrelerle ve referans standart numarasının ne olduğu. Bu tanımlar daha sonra kablo tasarımlarına gömülür, böylece Lab modülü üretim sırasında tam olarak neyi ne zaman test edeceğini bilir.

6.2.1 Veri Modeli

Üç tablo birlikte çalışır: standartlar neyin test edileceğini, parametreler her test içinde neyin ölçüleceğini, sonuçlar ise üretimden gerçek ölçümleri saklar.

test_standards

Benzersizlik kısıtlaması: (standard_category, test_name, standard_number) — aynı standart kuruluşu içinde tekrarlanan test tanımlarını önler.

test_parameters

Benzersizlik kısıtlaması: (test_standard_id, parameter_name) — tek bir test içinde tekrarlanan parametre adları olmaz.

test_results

Ölçüm depolama: measurements sütunu bir JSON dizisi saklar. Her giriş parameter (ad), values (float dizisi), isteğe bağlı unit ve isteğe bağlı parametre başına result içeren bir MeasurementData nesnesidir. Modelin yardımcı metodları vardır: get_measurements() JSON’ı ayrıştırır, set_measurements() serileştirir ve evaluate_result() tüm zorunlu parametrelerin değerleri olup olmadığına göre PASS/FAIL/PENDING döndürür.

6.2.2 İlişkiler

Silme davranışı akıllıdır: bir standardın test sonuçları varsa, sonuç izlenebilirliğini korumak için soft delete yapılır (is_active = false). Sonuçları yoksa hard delete yapılır. Parametreler her zaman kademeli silinir — bir standardı silmek tüm parametrelerini kaldırır.

6.2.3 API Endpoint’leri

Üç gruba ayrılmış 12 endpoint: standart CRUD, parametre yönetimi ve test sonuçları.

Test Standartları

Test Parametreleri

Test Sonuçları

Referans Verileri

6.2.4 Test Frekansları — Testler Ne Zaman Çalışır

Playground’da bir kablo tasarım adımına test atanırken, kullanıcı Lab’a üretim sırasında testi ne zaman yapacağını söyleyen bir frekans seçer:

6.2.5 Standartlar Kablo Tasarımlarına Nasıl Bağlanır

Bu kritik entegrasyon noktasıdır. Playground bir makine adımını yapılandırırken, testler tasarımın standart kategorisine göre getirilir ve filtrelenir:

# db_integration.py içinde — tasarımın standardıyla eşleşen testleri getirir
def get_tests_by_standard(db, standard):
    # Frontend kodunu veritabanı kategorisine eşler
    category_map = {'EN': 'IEC-EN', 'UL': 'UL', 'SLN': 'SLN'}
    category = category_map.get(standard, standard)

    standards = db.query(TestStandard).filter(
        TestStandard.standard_category == category,
        TestStandard.is_active == True
    ).all()
    return [{'id': s.id, 'test_name': s.test_name, ...} for s in standards]

Tasarım tamamlandığında, atanan testler cable_database.test_requirements içinde JSON dizisi olarak saklanır:

# cable_database.test_requirements içindeki depolama formatı
[
  {
    "step": 3,
    "machine_type": "extruder",
    "test_id": 12,
    "test_name": "Çekme Dayanımı",
    "standard_number": "EN 50618",
    "frequency": "her_ikisi"
  }
]

6.2.6 Yetki Modeli

Not: lab_user burada Makine Yönetimi’nden daha geniş erişime sahiptir — bu bilerek yapılmıştır çünkü laboratuvar personeli standartlar sisteminin birincil kullanıcılarıdır.

6.2.7 Frontend — Standartlar Sayfası

Tek dosya: pages/Teknik/Standards/index.tsx (553 satır). Route: /teknik/standards.

Sayfa Yapısı

Oluşturma/düzenleme için bir ProTable ve modal içeren PageContainer. Sekme yok — tüm standartlar tek tabloda gösterilir, kategori renk kodlu etiketlerle ayırt edilir.

Tablo Sütunları (9)

Oluşturma/Düzenleme Modalı (800px, bulanık arkaplan)

Modal 7 form alanı ve dinamik parametre listesi içerir:

Parametre Yönetimi (modal içinde)

“Test Parametreleri” ayırıcısının altında her parametre iki alanlı küçük bir Card olarak gösterilir:

• Parametre Adı — Input, placeholder “Parametre Adı (örn: Çekme Dayanımı, Uzama, Direnç)”
• Birim — Input, placeholder “Birim (örn: N/mm², %, ohm/km)”

“Parametre Ekle” butonu (kesikli çizgi, tam genişlik) yeni boş parametre kartı ekler. Her kartın başlığında sil butonu vardır. Sıra otomatik olarak sıralı atanır. Güncellemede, mevcut tüm parametreler yeni setle değiştirilir (tümünü sil + yenilerini oluştur).

CRUD Akışı

Oluşturma: “Yeni Test Standardı” tıkla → Modal açılır → Kategori, ad, standart numarası doldur → İsteğe bağlı parametre ekle → “Ekle” tıkla → POST /api/teknik/standards/tests → “Test standardı başarıyla eklendi!” → Modal kapanır, liste yenilenir.

Düzenleme: Düzenle ikonuna tıkla → Modal önceden doldurulmuş açılır → Alanları/parametreleri değiştir → “Güncelle” tıkla → PUT /api/teknik/standards/tests/{id} → “Test standardı başarıyla güncellendi!” → Modal kapanır, liste yenilenir.

Silme: Sil ikonuna tıkla → Popconfirm “Bu standardı devre dışı bırakmak istediğinize emin misiniz?” → DELETE /api/teknik/standards/tests/{id} → “Test standardı devre dışı bırakıldı!” → Liste yenilenir. Zaten pasif standartlar için sil butonu devre dışı.

Arama & Sayfalama

Arama istemci tarafındadır (200px yuvarlak giriş). ID, kategori, test adı, standart numarası, test tipi, numune sayısı ve durum (aktif/pasif) üzerinde arar. Sayfalama varsayılan 10 satır, [10, 20, 50, 100] seçenekleriyle. ID azalan sırada (en yeni önce).

6.2.8 Diğer Alt Modüllerle Bağlantılar

6.3 OPERATÖR YÖNETİMİ

Üretim operatörleri fabrika katında makineleri çalıştıran kişilerdir. Sistem girişine ihtiyaçları yoktur — sadece bir kayıt defterindeki isimlerdir ve birisi üretim çalıştırması başlattığında üretim oturumlarına atanırlar. Teknik’in en basit alt modülüdür (284 satır frontend, 4 endpoint), ama verisi her üretim oturumunda, her iş kartında ve her yarı mamul kaydında görünür.

6.3.1 Veritabanı Şeması

production_operators

Tablonun tamamı bu. Beş sütun. Foreign key yok, ilişki yok, JSON blob yok. name üzerindeki UNIQUE kısıtlaması tek iş kuralıdır — aynı isimde iki operatör olamaz.

6.3.2 API Endpoint’leri

/operators altında 4 endpoint. Özellikle, kimlik doğrulama dışında rol kontrolü yoktur — giriş yapmış herkes operatörleri yönetebilir. Pydantic şemaları da yok; route’lar ham sözlük kabul eder ve döndürür.

Doğrulama Detayları

6.3.3 Operatörler Üretimde Nasıl Kullanılır

Basit isim kaydının kritik hale geldiği yer burasıdır. Bir üretim oturumu başladığında, operatör atanır ve adı doğrudan oturum kaydında saklanır:

# production_routes.py içinde — üretim oturumu başlatma
if request.operator_id:
    prod_operator = db.query(ProductionOperator).filter(
        ProductionOperator.id == request.operator_id
    ).first()
    if prod_operator:
        operator_name = prod_operator.name

# production_sessions tablosunda saklanır:
# operator_id  → current_user.id (users’a FK, DB bütünlüğü için)
# operator_name → prod_operator.name (denormalize, geçmiş için)

Çift Depolama Düzeni

Üretim oturumları operatör bilgisini iki şekilde saklar:

Bu ayrım, sistemin hem kimin giriş yaptığını (kullanıcı hesabı, operator_id FK olarak saklanır) hem de hangi üretim operatörünün makineyi fiziksel olarak çalıştırdığını (bu kayıttan gelen isim, operator_name olarak saklanır) takip etmesinden dolayı vardır. Operatör, üretim müdürü tarafından önceden planlanmış bir iş kartı için üretim oturumu başlatırken açılır menüden kendi adını seçer.

Üretim Yaşam Döngüsünde Operatör

• Oturum Başlatma: Üretim sayfası GET /operators/list?active_only=true ile operatörleri getirir. Operatör, önceden planlanmış iş kartını başlatmadan önce açılır menüden kendi adını seçer. Başlamak için zorunlu.
• Oturum İçi Değişiklik: Operatörler oturum sırasında POST /production/update-operator ile değiştirilebilir — vardiya değişimleri için kullanışlı.
• Yarı Mamul Takibi: Stok sayfaları yarı mamul kayıtlarını onları üreten üretim oturumunun operator_name’iyle zenginleştirir.
• Geçmiş: Üretim geçmişi sayfaları tamamlanan her oturum için operatör adını gösterir.

6.3.4 Frontend — Operatör Sayfası

Tek dosya: pages/Teknik/OperatorYonetimi/index.tsx (284 satır). Route: /teknik/operator-yonetimi. Tüm Teknik modülündeki en küçük sayfa.

Tablo Sütunları (3)

Durum sütunu yok, zaman damgası yok. Sadece isim. is_active ve created_at/updated_at alanları veri arayüzünde var ama gösterilmiyor.

Oluşturma/Düzenleme Modalı (400px, bulanık arkaplan)

Tek alan:

CRUD Akışı

Oluşturma: “Yeni Operatör” tıkla → Modal (400px) → İsim gir → “Oluştur” tıkla → POST /api/operators/create → “Operatör oluşturuldu” → Modal kapanır, liste yenilenir.

Düzenleme: Düzenle ikonuna tıkla → Modal önceden doldurulmuş → İsmi değiştir → “Güncelle” tıkla → PUT /api/operators/{id} → “Operatör güncellendi” → Modal kapanır, liste yenilenir.

Silme: Sil ikonuna tıkla → Popconfirm “Operatörü silmek istediğinize emin misiniz?” → DELETE /api/operators/{id} → “Operatör silindi” → Liste yenilenir.

Arama & Sayfalama

Arama istemci tarafındadır (200px giriş). Ad ve ID üzerinden filtreler (büyük/küçük harf duyarsız). Sayfalama varsayılan 20 satır (operatör listesi kısa olduğundan diğer sayfalardan yüksek), [10, 20, 50, 100] seçenekleriyle.

Operatörler Üretim Sayfalarında Nasıl Görünür

Üretim sayfaları (KabatelÇekme, Kalaylama vb.) operatör seçimini iki durumda gösterir:

• Oturum öncesi: UserOutlined ikonlu Select açılır menü, placeholder “Operatör seçin”, GET /operators/list?active_only=true’den doldurulur. “Üretime Başla” butonunu etkinleştirmek için zorunlu.
• Oturum sırasında: Mevcut operatör adını gösteren kart ve oturum içi değişiklikler için tüm operatörleri tıklanabilir kartlar olarak listeleyen bir modal açan “Değiştir” butonu.

6.3.5 Diğer Alt Modüllerle Bağlantılar

6.4 Markalama (Kablo Markalama)

Fabrikadan çıkan her metre kablonun kılıfı üzerine fiziksel olarak metin basılır — firma adı, standart, gerilim değeri, kesit, üretim yılı. Markalama, ekstrüder makinesinin üretim sırasında kabloya bastığı bu markalama şablonlarını yöneten alt modüldür: sıralı kelime/segment dizileri.

6.4.1 Veritabanı Şeması

Tek tablo. Minimal tasarım.

Temel Kısıtlamalar

• UNIQUE isim: İki markalama şablonu aynı ismi paylaşamaz. Hem veritabanı seviyesinde (unique index) hem de uygulama seviyesinde (oluşturma/güncelleme öncesi tekrar kontrolü) uygulanır.
• Foreign key yok: markings tablosunda FK yoktur. Bunun yerine Sipariş modülündeki order_cables.marking_id bu tabloya referans verir. İlişki tüketici tarafındadır, burada tanımlanmamıştır.

6.4.2 API Endpoint’leri

/api/teknik/markings altında altı endpoint:

Doğrulama Detayları

Silme Davranışı

Silme endpoint’i kalıcı silmedir (db.delete(marking)). Standart Yönetimi’nden farklı olarak akıllı silme mantığı yoktur. Bir markalama mevcut siparişler tarafından referans alınıyorsa, o siparişler marking_id tam sayısını tutar ama markalama kaydı silinmiş olur. Daha güvenli iş akışı, /toggle-status endpoint’ini kullanarak durumu pasife çevirmektir; bu, yeni siparişlerde marklamayı gizlerken geçmiş sorgular için kaydı korur.

6.4.3 Pydantic Şemaları

6.4.4 Dinamik Değişkenler

Markalama kelimeleri üretim sırasında çözümlenen dört çalışma zamanı değişkeni destekler:

Değişken çözümleme üretim/ekstrüzyon katmanında yapılır, bu alt modülde değil. Markalama şablonları sadece yer tutucu sözdizimiyle saklar. Frontend bunları formda yardımcı metin olarak gösterir: “Değişkenler: {CABLE_SIZE}, {ORDER_NO}, {YEAR}, {METER}”.

6.4.5 Yetki Modeli

Makinelerden (production_manager izni olan) veya Standartlardan (lab_user izni olan) farklı olarak, Markalama yazma işlemleri yalnızca super_admin ile sınırlıdır. check_permission_smart fonksiyonu hem rolü hem de ayrıntılı yetki anahtarını doğrular. Durum değiştirme endpoint’i istisnadır — kimliği doğrulanmış herkes bir marklamayı aktifleştirebilir/pasifleştirebilir.

Yetki Manifesti (Frontend)

Frontend yetki sistemi Markalama sayfası için 5 buton tanımlar:

• access_page — Markalama sayfasını görüntüleyebilir
• view_markings — Markalama listesini görebilir
• create_marking — Yeni markalama ekleyebilir
• edit_marking — Mevcut marklamaları düzenleyebilir
• delete_marking — Marklamaları kalıcı olarak silebilir (kritik)

6.4.6 Frontend — Sayfa Yapısı

Tek dosya: src/pages/Teknik/Markalama/index.tsx (374 satır). Rota: /teknik/markalama.

Tablo Sütunları (4)

Oluşturma/Düzenleme Modalı

Modal iki form bölümüne sahiptir:

1. İsim Alanı

• <Input> ile yer tutucu “ör: SOLEN BEAM Standard”
• Zorunlu doğrulama

2. Kelimeler (Dinamik Liste)

• Dinamik ekleme/kaldırma için Ant Design <Form.List> kullanır
• Her kelime numaralı satırdır: 1., 2., 3.… 550px genişlikte giriş
• Minimum 1 kelime özel validator ile zorunlu
• Kırmızı <MinusCircleOutlined> ile kelime kaldırma (sadece 1 kelime kaldığında gizlenir)
• Altta kesikli “Kelime Ekle” butonu ile yeni satır ekleme
• Oluşturmada bir boş kelime slotu ile başlar
• Düzenlemede mevcut tüm kelimeleri ön doldurur
• Etiket’te değişken ipucu metni: “Değişkenler: {CABLE_SIZE}, {ORDER_NO}, {YEAR}, {METER}”

CRUD Akışı

Arama & Sayfalama

Arama istemci tarafındadır (200px yuvarlak giriş). İsim, durum metni (aktif/pasif) ve kelime sayısı üzerinden filtreler. Sayfalama varsayılan 10 satır, [10, 20, 50, 100] seçenekleriyle. “X-Y / Z kayıt” toplamını gösterir.

6.4.7 Marklamalar Sistemde Nasıl Akar

Markalama şablonları referans verileridir. Teknik modülünde bir kez oluşturulur ve siparişten üretime giden hatta iki kritik noktada tüketilir:

Adım 1: Sipariş Oluşturma (Sipariş Modülü)

Sipariş oluşturma formunda her kablo girişinin bir “Markalama” açılır menüsü (aranabilir <Select>) vardır. Sadece aktif marklamaları gösterir. Kullanıcı birini seçer ve marking_id order_cables.marking_id’ye (tam sayı FK) kaydedilir. Bir kablonun sipariş formunda “tamamlanmış” sayılması için markalama seçimi zorunludur.

// Sipariş formu kablo tamamlanma kontrolü (SiparisOlustur/index.tsx)
const isComplete = hasDesign && hasMeters && hasMakara
  && hasMarking && hasPrice && hasCurrency && materialsComplete;

Adım 2: İş Kartı Üretimi & Üretim Planlama

Sipariş onaylandığında ve iş kartları üretildiğinde:

work_card_generator.py servisi her kablonun marking_id’sini Marking tablosunu sorgulayarak gerçek markalama adına çözümler. Hem marking_id hem de marking_name ekstrüder iş kartının material_details JSON’una gömülür:

# work_card_generator.py — ekstrüder material_details
{
    'marking_id': cable_data.get('marking_id'),    # Tam sayı FK
    'marking_name': cable_data.get('marking_name'), # Çözümlenmiş metin
    'tests': ex_tests,
    'breakdown': [],
    ...
}

Adım 3: Üretim Planlama Görüntüsü

Üretim Planlama sayfası ekstrüder iş kartının material_details’ini okur ve markalama adını kart arayüzünde gösterir:

// Production/Planning/index.tsx
{materialDetails.marking_name && (
  <div>
    <div style={{ fontSize: 10, fontWeight: 600 }}>Markalama</div>
    <div style={{ fontSize: 11 }}>{materialDetails.marking_name}</div>
  </div>
)}

Adım 4: Sipariş Detay Görünümü

Mevcut bir sipariş görüntülenirken detay sayfası marklamayı gösterir. order_routes.py endpoint’i marking_id’yi sorgu zamanında isme çözümler:

# order_routes.py — markalama çözümleme
marking_name = None
if cable.marking_id:
    marking = db.query(Marking).filter(Marking.id == cable.marking_id).first()
    marking_name = marking.name if marking else None

Bu desen order_routes.py’da iki kez geçer: bir kez tek sipariş detay endpoint’i için, bir kez iş kartı üretimi veri çıkarma için.

6.4.8 Veri Depolama Düzeni — ID vs İsim

6.4.9 Diğer Alt Modüllerle Bağlantılar

6.5 & 6.6 Kablo Tasarım (Cable Playground) & Kablo Veritabanı (Cable Database)

Bu iki alt modül birlikte belgelenir çünkü ayrılmazdır: Playground, gerçek fabrika makineleri kullanılarak kabloların adım adım tasarlandığı yerdir ve Kablo Veritabanı, tamamlanmış tasarımların kalıcı olarak saklandığı depodur. Sistemdeki diğer tüm modüller — Siparişler, Üretim Planlama, İş Kartları, Malzeme Hesaplamaları, Stok — nihayetinde Playground’un oluşturup Kablo Veritabanı’na kaydettiği kayıtlara bağlıdır.

6.5.1 Temel Kavram — Kablo Tasarımı Nasıl Çalışır

Kablo imalatı katı bir sıralı hat izler. Ham bakır (8mm filmaşin) ilk makineye girer ve 6 makine türü üzerinden ilerleyerek bitmiş kabloya dönüşür. Playground bu sürecin tamamını dijital olarak simüle eder.

Altı Makine Türü (sırasıyla)

Makine Akış Kısıtlamaları

Her makine her makineden sonra gelemez. Sistem yönlü bir graf uygular:

Kritik döngü yetenekleri:

• Buncher → Buncher: Çok aşamalı bükme (bükülmüş tel tekrar bükülebilir)
• Extruder → Extruder: Çok katmanlı ekstrüzyon (önce izole, sonra kılıf)
• Extruder → Buncher: Çok damarlı kablolar (tek damarları izole et, birlikte bük, sonra kılıfla)

# Makine akış kısıtlamaları (playground_session.py)
MACHINE_FLOW = {
    'kabatel_cekme': ['kalaylama'],
    'kalaylama':     ['incetel_cekme', 'buncher'],
    'incetel_cekme': ['buncher', 'extruder'],
    'buncher':       ['extruder', 'buncher'],    # Kendi döngüsü!
    'extruder':      ['ebeam', 'extruder'],      # Kendi döngüsü!
    'ebeam':         []                          # Son
}

6.5.2 Backend Mimarisi — Motor

Playground backend’i toplam ~4.700 satır olan 8 Python dosyasından oluşur:

Oturum Yönetimi (Bellekte)

Oturumlar bir Python sözlüğünde saklanır (_active_sessions: Dict[str, PlaygroundSession]). Her oturum içerir:

• session_id: UUID v4
• standard: EN / UL / SLN (oturum başlangıcında seçilir)
• cross_section: ör. “6mm²” (oturum başlangıcında seçilir)
• steps: DesignStep dataclass örneklerinin listesi
• progression: Tüm öğeleri takip eden ProgressionManager örneği
• history_stack / redo_stack: Geri al/yinele için StateSnapshot listeleri (maks 50)
• autosave: varsayılan olarak açık, 30 saniyelik aralık, kaydedilmemiş değişiklikleri izler

İlerleme Paneli — Tasarımın Kalbi

ProgressionManager, ProgressionItem nesnelerinin bir listesini tutar. Her öğe, imalatın herhangi bir aşamasındaki fiziksel bir ürünü (tel, bükülmüş tel, kablo) temsil eder:

# ProgressionItem alanları
{
    'id': 'uuid',                    # Benzersiz tanımlayıcı
    'code': 'KC_18',                 # Deterministik ürün kodu
    'quantity': 21,                  # Mevcut kullanılabilir miktar
    'original_quantity': 21,         # İlk üretildiğindeki miktar
    'structure': '1.8mm',            # Yapı formülü
    'specification': '1.8mm Tel',    # Okunabilir ad
    'status': 'active' | 'inactive', # Inactive = tamamen tüketildi
    'produced_by_step': 1,           # Hangi adım oluşturdu
    'consumed_by_steps': [2],        # Bundan tüketen adımlar
    'machine_type': 'kabatel_cekme', # Kaynak makine
    'properties': { ... }            # Makineye özel veri
}

Temel kurallar:

• Oturum her zaman bir öğeyle başlar: RAW_COPPER_8MM (8mm filmaşin, miktar 1)
• Bir adım öğe tükettiğinde miktarları azalır. 0’a düştüğünde durum inactive olur.
• Bir adım öğe ürettiğinde yeni ProgressionItem’lar oluşturulup eklenir.
• Her makine türünün tüketim/üretim mantığını yöneten kendi process_* metodu vardır.
• Aynı kodlu öğeler birleştirilir (miktar toplanır) — paralel süreç çıkışları hariç.

Miktar Takibi Örneği — 6mm² Kablo

Checkpoint/Geri Yükleme ile Atomik İşlemler

Her konfigürasyon denemesi atomik bir işlemle sarılır:

StateSnapshot, oturumun tam durumunu yakalar (adımlar + ilerleme öğeleri + tüketim günlüğü + adım sayaç). Başarısızlıkta oturum tam olarak önceki durumuna geri yüklenir.

6.5.3 API Endpoint’ler — 30+ Endpoint

Oturum Yönetimi

Adım Yönetimi

Form Verileri (makine türüne göre)

Makine Konfigürasyonu (türe göre)

Kapasite Kesişimi

Geri Al/Yinele & Otomatik Kaydetme

Doğrulama & Sonlandırma

6.5.4 Makine Konfigürasyon Şemaları

Her makine türünün form alanlarını sırasıyla tanımlayan bir Pydantic şeması vardır:

6.5.5 Kapasite Kesişimi — Çoklu Makine Esnekliği

Kullanıcı bir adım için birden fazla alternatif makine seçtiğinde, sistem kapasite aralıklarının kesişimini hesaplar. Açılır menülerde yalnızca seçilen tüm makinelerin üretebileceği değerler görünür.

# Makine A hız seçenekleri: [5, 10, 15, 20, 25]
# Makine B hız seçenekleri: [10, 15, 20, 25, 30]
# Kesişim: [10, 15, 20, 25]
# Bu, kesişimdeki herhangi bir değerin seçilen
# HERHANGI BİR makinede üretilebileceği anlamına gelir → üretim esnekliği

Bu, kullanıcı konfigürasyon çekmecesinde bir makine onay kutusunu her işaretlediğinde veya kaldırdığında POST /calculate-intersection/{machine_type} üzerinden dinamik olarak çağrılır.

6.5.6 Deterministik Kod Üretimi

CableCodeGenerator, aynı ürünlerin her zaman aynı kodu almasını sağlar; bu stok yönetimi için kritiktir:

Tam spesifikasyonlardan (product_type + machine_type + girişler + çıkışlar + parametreler) deterministlik için sort_keys=True ile SHA256 spec_hash hesaplanır. Aynı hash’e sahip bir ürün product_codes’da zaten varsa, mevcut system_code döner. Yoksa çakışma yönetimiyle (sıra eki _001, _002 vb.) yeni bir kod üretilir.

6.5.7 Özel Kablo Türleri

İkiz Kablolar (Extruder)

Extruder, ikiz/üçüz kablolar için çoklu giriş destekler. Yapıda || ayırıcısı kullanılır: (kablo1 || kablo2)+SHT_0.8mm. Frontend ||’dan ikiz sayısını tespit eder ve Türkçe adlar üretir: İkiz, Üçüz, Dördüz, Beşiz.

Çok Damarlı Kablolar (Extruder → Buncher → Extruder)

Çok damarlı kablolar için akış döngü yapar: Extruder tek damarları izole eder, Buncher izoleli damarları gruplar, sonra Extruder dış kılıfı uygular. Sistem bunu yapı formülündeki INS_ desenlerinden tespit eder.

E-beam Kablolar (Katalizörsüz)

E-beam çapraz bağlama, kimyasal katalizörün yerini alır. Form entegrasyonu, katalizörlü kabloları E-beam giriş açılır menüsünden tamamen gizler — geçersiz kombinasyonları önlemek için hiç gösterilmezler.

6.5.8 Frontend — Playground Sayfası

Ana dosya: src/pages/Teknik/CablePlayground/index.tsx (947 satır), 7 bileşen dosyası ve 1 özel hook ile.

Oturum Başlatma Akışı

Makine Konfigürasyon Akışı

CRUD Akışı

Playground geleneksel bir CRUD sayfası değildir. Oturum tabanlı bir üretim simülasyon motorudur. “Oluşturma” tek bir form göndermesi değil, çok adımlı bir tasarım sürecidir.

Oluştur (Kablo Tasarla):

1. “Oturum Başlat” butonuna tıkla → Modal standart (EN/UL/SLN) ve kesit sorar
2. POST /playground/start → Bellekte oturum oluşturulur, ilerleme panelinde başlangıç girdisi olarak 8mm filmaşin belirir
3. Kütüphaneden makineyi canvas’a sürükle → POST /playground/steps/add → oturuma adım eklenir
4. Makine düğümüne tıkla → GET /playground/form-data/{tür} → ConfigurationDrawer açılır (1.215 satırlık bileşen)
5. Gerçek makineleri seç (onay kutuları) → POST /playground/calculate-intersection → açılır listeler yalnızca tüm seçilen makinelerin üretebileceği değerlerle güncellenir
6. Konfigürasyon formunu doldur → POST /playground/configure/{tür}/{adım} → ilerleme paneli yeni çıktılar + miktarlarla güncellenir
7. Her üretim makinesi için 3–6 adımları tekrarla (KC → KL → IC → BN → EX → isteğe bağlı E-beam)
8. Sistem POST /playground/autosave ile otomatik kaydeder (her değişiklik geri al/yinele için bir kontrol noktası oluşturur)
9. “Sonlandır” butonuna tıkla → POST /playground/finalize → atomik veritabanı işlemi cable_designs, design_steps ve cable_database tablolarına aynı anda yazar. Deterministik SHA-256 kod üretilir. Oturum yok edilir.

Oku (Oturumu Devam Ettir):

1. Mevcut oturumlar bellekte kalır. Sayfayı yenile → GET /playground/status aktif oturum kontrol eder
2. Oturum varsa: canvas son kontrol noktasından tam ilerleme durumuyla geri yüklenir

Geri Al / Yinele (Oturum İçi):

1. Geri Al’a tıkla → POST /playground/undo → oturum önceki kontrol noktasına geri döner
2. Yinele’ye tıkla → POST /playground/redo → oturum sonraki kontrol noktasına ilerler
3. Her yapılandır/ekle/kaldır eylemi atomik bir kontrol noktası oluşturur. Geri alma yığını oturum içinde sınırsızdır.

Sil (Adım Kaldır):

1. Canvas’taki makine düğümüne sağ tıkla → “Kaldır”
2. POST /playground/steps/remove → adım oturumdan kaldırılır, ilerleme yeniden hesaplanır, kontrol noktası oluşturulur
3. Aşağı akış bağımlılıkları olan bir adımı kaldırmak, bu adımların da zincirleme kaldırılmasını tetikler

6.6 Kablo Veritabanı (Cable Database)

6.6.1 Ne Kaydedilir — Sonlandırma Süreci

Kullanıcı Playground’da “Sonlandır” düğmesine bastığında, sistem tek bir veritabanı işleminde üç şey kaydeder:

6.6.2 Veritabanı Şeması — 4 Tablo

cable_designs

design_steps

Benzersiz kısıt: (design_id, step_number, parallel_group)

cable_database — Ana Kayıt

product_codes — Stok Yönetimi Köprüsü

6.6.3 Kablo Veritabanı API — 15+ Endpoint

6.6.4 Frontend — Kablo Veritabanı Sayfası

Tek dosya: src/pages/Teknik/CableDatabase/index.tsx (691 satır). Rota: /teknik/kablo-veritabani.

CRUD Akışı

Kablo Veritabanı esas olarak okuma ağırlıklı, bir kez yaz deposudur. Kablolar yalnızca Playground sonlandırması yoluyla girer — manuel “kablo oluştur” formu yoktur.

Oluştur (Playground Sonlandırması Yoluyla):

1. Kullanıcı Playground’da tasarımı sonlandırır → POST /playground/finalize
2. Backend fiziksel özelliklerin SHA-256 hash’i ile deterministik kablo kodu üretir
3. Kod zaten varsa: sonlandırma reddedilir (aynı kablo zaten kayıtlı)
4. Kod yeniyse: atomik işlem cable_designs + design_steps + cable_database satırlarını tek seferde yazar
5. teknik odasına WebSocket yayını → tüm bağlı kullanıcılarda Kablo Veritabanı tablosu yenilenir

Oku:

1. /teknik/kablo-veritabani sayfasını aç → GET /cable-database → ProTable tüm kabloları display_name, cable_code, standart, kesit, durum ile listeler
2. İstemci tarafı arama kablo kodu, tür veya kesite göre filtreler
3. Kablo satırına tıkla → Detay Çekmecesi üç sekmeli açılır:
   • Üretim Akışı: GET /cable-database/{kod}/production-flow → Ant Design Timeline ile her üretim adımının görselleştirilmesi
   • Yarı Mamul Ürünler: GET /cable-database/{kod}/half-products → özellikleriyle tüm ara ürünler
   • Gereksinimler: GET /cable-database/{kod}/requirements → hammaddeler (bakır, kalay, plastik, katalist, boya) + test gereksinimleri
4. Diğer modüller kablo verilerini özel endpoint’ler üzerinden okur: /full (malzeme hesaplayıcı), /parsed-structure (sipariş formları)

Geçici Silme (Devre Dışı Bırakma):

1. Tablo satırındaki devre dışı bırakma ikonuna tıkla (super_admin veya production_manager yetkisi gerekir)
2. Onay diyalogu uyarısı
3. PUT /cable-database/{kod}/deactivate → is_active = false olarak ayarlanır
4. Kablo varsayılan liste görünümlerinden kaybolur (active_only=false filtresiyle hala erişilebilir). Bu kablo koduna referans veren aşağı akış modülleri çalışmaya devam eder — devre dışı bırakma yeni siparişlerin bunu kullanmasını engeller.

Kalıcı Silme:

1. Kalıcı silme ikonuna tıkla (yalnızca super_admin yetkisi gerekir)
2. Güçlü uyarı metniyle onay diyalogu
3. DELETE /cable-database/{kod}/permanent
4. Backend cable_database kaydını + ilişkili cable_designs + design_steps’i siler (cascade)
5. WebSocket yayını → tüm bağlı kullanıcılarda tablo yenilenir
6. Tehlike: Bu yıkıcı bir işlemdir. Aktif siparişler veya iş kartları bu kablo koduna referans veriyorsa, bu referanslar yetim kalır.

Güncelle (Stok Seviyesi — Ürün Kodları):

1. Ürün kodları görünümüne git → GET /products/codes
2. Üründe stok düzenle’ye tıkla → PUT /products/{kod}/stock (super_admin, production_manager veya operator gerekir)
3. O yarı mamul/nihai ürün için stock_level alanını günceller
4. Stok güncellemeleri için WebSocket yayını yok — yoklama tabanlı

6.6.5 Kablo Veritabanı Sistemin Geri Kalanını Nasıl Besler

7. SONUÇ

7.1 Bu Belgenin Kapsamı

Bu derin analiz, Teknik modülünü altı alt modül boyunca, üst düzey mimariden bireysel kod satırlarına kadar inceledi:

7.2 Mimari İlkeler

Teknik modülü boyunca birkaç tasarım ilkesi tekrarlanır ve modülün karakterini tanımlar:

7.3 Sayılarla

7.4 Teknik Fabrikayı Nasıl Besler

Her kablo siparişi, Kablo Veritabanı’ndan bir cable_code’a referans verir. Her iş kartı, production_flow JSON’undan üretilir. Her malzeme hesaplaması, half_products özelliklerini okur. Her kalite testi, Teknik’te tanımlanan standart hiyerarşisinden atanır. Kablo üzerine basılan markalama, Markalama alt modülünden gelir. Kabloları üreten makineler, Makine Yönetimi’nde saklanan kapasitelere karşı doğrulanır.

Kısacası: Teknik yanlışsa, aşağıdaki her şey yanlıştır. Bu yüzden Playground atomik işlemler, kapasite doğrulaması ve deterministik kod üretimi kullanır — Kablo Veritabanı’na giren her şeyin üretime hazır ve doğru olduğunu garanti etmek için.

7.5 Son Söz