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

Uçtan uca izlenebilirlik

Alış ve satış aynı güçte bağlanmalı

Sipariş taraf ilişkileri sadece satış tarafını (order'ın kendisini) inceledi. Burada iki yönü birden ele alıyoruz: alış (satıcıdan giren mal) ve satış (alıcıya giden mal). Hedef: fatura, gider ve iade her iki tarafta da aynı sağlamlıkta bağlanabilsin.

Alış tarafı (satıcıdan giren mal)

BağlantıBugünkü durum
Satıcı → Stok girişiVar — StockEntry.seller
Alış faturası → Stok girişiYok — PlatformInvoice'ta sadece stockProcessed: boolean bayrağı var; hangi StockEntry(ler)'i oluşturduğuna dair gerçek bir referans yok
Gider → alışHenüz yok — Yeni ihtiyaçlar'daki gider kaydı, isteğe bağlı olarak bir StockEntry'e/alışa bağlanabilmeli (ör. gümrük, nakliye gideri)
İade → satıcıYok / ölü kod — financial'da TransactionType.STOCK_RETURN ("Satıcıya ürün iadesi") tanımlı ama kodda hiçbir yerde tetiklenmiyor; stock modülündeki StockExitType (SALE, FIRE, ADJUSTMENT) arasında satıcıya iade diye bir tip yok

Satış tarafı (alıcıya giden mal)

BağlantıBugünkü durum
Stok çıkışı → SiparişVar — StockExit.buyerOrder, item bazlı stockExitReference
Satış faturası → SiparişGevşek referans — bkz. Sipariş taraf ilişkileri
Gider → satışHenüz yok — teslimat/kargo gibi sipariş özelinde oluşan bir gider bağlanabilmeli
İade → SiparişVar, sağlam — BuyerOrderReturn.buyerOrder (ref), item bazlı orderProductId (ref BuyerOrderProduct); tamamlanınca financial-buyer.service.ts üzerinden REFUND_BALANCE_FOR_RETURN ile cari iadesi tetikleniyor
İade → kaynak stok girişi / satıcıYok — ReturnRequestItem sadece ürünün anlık görüntüsünü (ReturnRequestProductSnapshot) tutuyor; geldiği StockEntry'e veya satıcıya referans yok. Kusurlu ürün iadesi satıcıya otomatik yansıtılamıyor.

Sonuç

Satış tarafı (stok çıkışı → sipariş → iade) kendi içinde zaten iyi bağlı. Asıl boşluk alış tarafında: alış faturası stoğa bağlanmıyor, satıcıya iade hiç uçtan uca modellenmemiş (dead code + eksik stok çıkış tipi), ve satış iadesi geldiği alışa/satıcıya geri izlenemiyor. Gider de her iki tarafa da — sabit company/warehouse kapsamının yanında — isteğe bağlı olarak bağlanabilmeli.

Karar: iade bir "tür", ayrı ama referanslı bir kayıt

İade, ileri yöndeki hareketin (alış ya da satış) ters kaydı olduğu için kendi başına ilgisiz bir şey değil — her zaman hangi ileri kaydı tersine çevirdiğini bilen, o türden bir kayıt. Satış tarafında bu prensip zaten kurulu: BuyerOrderReturn ayrı bir koleksiyon ama orijinal BuyerOrder'a gerçek bir referansla bağlı (kendi status, history, medya alanları olduğu için BuyerOrder'a tek bir orderType alanıyla birleştirilmiyor — karar: ayrı-ama-referanslı yapı korunuyor).

Alış tarafında da aynı desen kurulmalı: satıcıya iade, StockExitType'a yeni bir değer (RETURN_TO_SELLER) ya da StockEntry'ye gömülü bir type alanı olarak değil, BuyerOrderReturn'e benzer ayrı bir model (ör. StockEntryReturn) olarak kurulmalı — orijinal StockEntry'e gerçek bir referansla bağlı. Böylece iki taraf da aynı prensibi paylaşır: iade her zaman kendi kaydı, ama hep bir ileri kayda referans veriyor.

Karar: Bu yeni model basit tutulacak — BuyerOrderReturn'deki status/history/medya deseni burada tekrarlanmayacak. Sadece orijinal StockEntry'e referans, miktar ve gerekçe yeterli.

Açık noktalar

  • PlatformInvoice'a StockEntry'e gerçek bir referans eklenmeli.
  • ReturnRequestItem'a kaynak StockEntry/satıcı referansı eklenmeli mi (kusurlu ürünü satıcıya bildirebilmek için)?
  • Giderin alışa/satışa bağlanması her zaman isteğe bağlı mı olacak, yoksa bazı gider kategorileri için zorunlu mu?

Sıradaki adım

Bu bulgular, hedef modül şeması ve Prisma/Mongo şema taslağı planlanırken Sipariş taraf ilişkileri ve Yeni ihtiyaçlar ile birlikte ele alınacak.