Yeni ihtiyaçlar

Bu sayfa ilk v2 planında ortaya çıkan ihtiyaçların çalışan v2'deki durumunu izler. Bazı ihtiyaçlar artık kodda karşılık buldu; bazıları paylaşılan veri modelinde veya görünür API yüzeyinde hâlâ açıktır.

Muhasebe: gider takibi

v1 cari modeli sipariş, alıcı ve tedarik hareketleri etrafında kuruluydu; genel işletme giderini ayrı bir kavram olarak taşımıyordu. v2'nin Kasa ve Banka yüzeyi bu ihtiyacı cari hareketine yeni bir tür ekleyerek değil, ayrı ilişkisel yapılarla karşılar:

• Expense: giderin kategorisi, alacaklısı, tutarı, tarihi ve belgesi
• MoneyAccount: kasa veya banka hesabı
• MoneyMovement: para hesabındaki hareket
• PayablePayment: ödenecek kayda yapılan ödeme

Bu tabloların şeması v1 Prisma dosyasındadır ve migration v1'den gelir; iş kuralları ve yazma yolları yalnız v2'dedir. Bakiye yazmalarının kapısı MoneyBookService'tir.

İlk plandaki Company veya Warehouse kapsamı uygulanmadı; Company modeli bugün yoktur. Dinamik gider kategorisi için ayrı bir yönetim tablosu yerine Expense.category metin alanı kullanılır. Bu nedenle açık kalan sorular şunlardır:

• Giderlerin depo veya ilerideki şirket kapsamına nasıl bağlanacağı
• Kategori sözlüğünün yönetilebilir bir modele dönüşüp dönüşmeyeceği
• Giderlerin alan raporlarına ve tedarik maliyetine nasıl yansıyacağı

Yetki ve bugünkü depo kapsamı için Planlanan şirket ve depo hiyerarşisi sayfasındaki “v2 bugün” bölümüne bakın.

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. v2 ayrıca stockSupplierReturns ile alış satırından tedarikçiye iade zincirini kurar. Bugün bu iz sürme resmi olarak HKS'ye (dış sistem) bildiriliyor; iç sistemde bütün yönleri tek görünümde birleştiren 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. v2 alan kuralına göre bu, bağımsız report modülünde değil verinin sahibi logistics altında veya onun yayımladığı servis üzerinden kurulmalıdır.

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

Giderin temel kaydı tamamlandı; kapsam, raporlama ve ürün yolculuğu görünümü açık kalıyor. Paylaşılan şemada değişiklik gerekiyorsa önce v1'de migration üretilmeli, sonra v2 Prisma aynası güncellenmelidir. Bu sınır Geçiş ve veri sahipliği sayfasında açıklanır.