Are you an LLM? Read llms.txt for a summary of the docs, or llms-full.txt for the full context.
Skip to content

Yeni ihtiyaçlar

Planlama sırasında ortaya çıkanlar

Bu sayfa, v2 planlanırken ortaya çıkan ve mevcut kodda karşılığı olmayan (ya da eksik kalan) ihtiyaçları toplar. Bunlar Alan haritası'ndaki mevcut modül sınıflandırmasını etkiler; hedef yapı çizilirken hesaba katılmalı.

Muhasebe: gider (expense) takibi

Bugün FinancialAccount / AccountTransaction (Mongo) sadece sipariş, alıcı ve satıcı tedariki eksenli hareketleri modelliyor. TransactionType enum'undaki 20 değerin hepsi bir siparişe, cari bakiyeye veya satıcıdan stok tedarikine bağlı (STOCK_PURCHASE, REFUND_BALANCE_FOR_ORDER, REWARD, vb.). Kira, maaş, fatura gibi genel işletme gideri kavramı yok.

  • İhtiyaç: Cari tarafına bir gider/expense kaydı eklenmeli.
  • Kapsam: Karar verildi — gider hem Company hem Warehouse seviyesinde tutulabilmeli. Hangisinin kullanılacağı operasyona göre değişir (bazı giderler tek bir depoya özgüdür — kira, elektrik; bazıları şirket geneline yayılır — merkezi bir hizmet, toplu bir fatura). Çalışma izni için kurulan aynı kapsam deseni (Company veya Warehouse'a bağlanabilen, ikisi birlikte zorunlu olmayan alan) burada da kullanılabilir.
  • Rol kısıtı: Gider ekleme/görme gibi işlemler sadece belirli rollere açık olmalı — mevcut Permission sistemi ("ne yapabilir") ile çalışma izni ("hangi company/warehouse'da") birlikte bunu sağlayabilir.
  • Kategori yönetimi: Karar verildi — gider kategorileri sabit bir enum değil, admin tarafından eklenip düzenlenebilen dinamik bir tablo olacak (bugünkü PriceSource, CompanyType gibi admin-CRUD modellerine benzer). Kurulumda önceden tanımlı (predefined) kategorilerle seed edilecek; admin sonradan yenilerini ekleyebilecek.

Açık sorular:

  • Mevcut AccountTransaction koleksiyonuna yeni bir TransactionType olarak mı eklenecek, yoksa ayrı bir model mi olacak?
  • report modülündeki finansal raporlara (FinancialAccountReport) nasıl yansıyacak — Company ve Warehouse bazlı giderler tek bir toplam raporda nasıl birleştirilecek?

Satış-alış arası izlenebilirlik (ürün yolculuğu)

Bugün stock modülünde FIFO zinciri veri seviyesinde zaten bağlı:

  • StockEntry.seller → ürün hangi satıcıdan geldi
  • StockExit.stockEntryReferences[] → çıkış hangi giriş lot(lar)ından tüketildi (FIFO)
  • StockExit.buyerOrder → çıkış hangi siparişe gitti

Yani "bu ürün şu satıcıdan geldi, şu siparişe gitti" zinciri veride kurulu, ama bunu uçtan uca gösteren keşfedilebilir bir görünüm/uç nokta yok. Bugün bu iz sürme resmi olarak HKS'ye (dış sistem) bildiriliyor; iç sistemde aynı düzeyde bir izlenebilirlik sağlanmıyor.

Asıl can alıcı nokta stok zincirinde değil — orası zaten sağlam. Sipariş sürecindeki tüm tarafların (fatura, cari dahil) order'a ne kadar sağlam bağlı olduğunun tam dökümü için: Sipariş sürecindeki taraf ilişkileri. Alış tarafının (satıcıdan giren mal) ve iki yönlü iadenin aynı incelemesi için: Uçtan uca izlenebilirlik.

  • İhtiyaç: "Bu ürün nereden geldi, nereye gitti" sorusuna iç sistemden de cevap verebilen bir görünüm — muhtemelen report ya da stock altında yeni bir "ürün yolculuğu" uç noktası.

Açık sorular:

  • Bu görünüm tekil ürün/parti (lot) seviyesinde mi, yoksa toplu rapor seviyesinde mi olacak?
  • Hangi roller görebilecek?
  • HKS'nin zaten sağladığı resmi izlenebilirlikle iç sistemin ilişkisi ne olacak — aynı veriyi tekrar mı üretecek, yoksa onu tamamlayan bir iç görünüm mü olacak?

Sıradaki adım

Bu iki ihtiyaç, Alan haritası'ndaki muhasebe ve satış/lojistik alanlarının sınırlarını etkiliyor; hedef modül şeması çizilirken ayrıca ele alınacak.