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ışv2'de ayrı Expense kaydı var; ancak StockEntry veya belirli bir alışa yapısal bağ yok. Gümrük/nakliye gibi maliyetlerin lota dağıtımı hâlâ açık.
İade → satıcıv1'de TransactionType.STOCK_RETURN ölüdür. v2'de /logistics/stock/supplier-returns ve stockSupplierReturns koleksiyonu vardır; alış satırına ve StockEntry kimliğine bağlanır, stockExits kaydını ADJUSTMENT + supplierReturnId ile yazar ve tedarikçi carisine STOCK_RETURN hareketi düşer.

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ı. v2, alış faturası satırından tedarikçiye iadeyi ayrı belge, stok çıkışı ve cari hareketiyle kısmen kapattı. Açık kalan ana boşluklar: v1 PlatformInvoice ile eski StockEntry arasında gerçek bağ olmaması, satış iadesinin geldiği alışa/satıcıya geri izlenememesi ve giderin alış/satış kaydına bağlanmaması.

v2 uygulaması: iade ayrı 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 v2 bu deseni stockSupplierReturns ile uyguladı. Belge, purchaseId, alış satır numarası, entryId, miktar, maliyet, KDV, oluşan exitId ve cari hareket kimliklerini taşır. BuyerOrderReturn'deki durum/geçmiş/medya deseni tekrarlanmaz. Bağlar ObjectId alanlarıdır fakat şemada Mongoose ref tanımlı değildir; zincir uygulama kodu tarafından korunur.

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)?
  • stockSupplierReturns içindeki purchaseId, entryId ve exitId alanları gerçek Mongoose ref ilişkilerine çevrilmeli mi?
  • Giderin alışa/satışa bağlanması her zaman isteğe bağlı mı olacak, yoksa bazı gider kategorileri için zorunlu mu?

Açık kalan iş

Bu bağlantılar v2'nin domain ayrımıyla tek başına çözülmez; iki servisin paylaştığı belge ve şema sözleşmesini etkiler. Değişiklikler Sipariş taraf ilişkileri, Yeni ihtiyaçlar ve Geçiş ve veri sahipliği ile birlikte ele alınmalıdır.