Sipariş sürecindeki taraf ilişkileri
Sipariş sürecindeki taraflar üç farklı şekilde BuyerOrder'a bağlanıyor — hepsi aynı güçte değil:
- Gerçek ilişki (Mongoose
ref): sorgulanabilir,populateedilebilir. - Anlık kopya (embedded copy): o an nasıl göründüğünü saklar; canlı kayda geri dönüş yok.
- Gevşek referans (düz string ID): iki taraf da aynı ID'yi metin olarak tutar, ama veritabanı seviyesinde bir bağ yok — populate edilemez, sadece uygulama kodu ID'yi elle eşler.
Taraf taraf durum
| Taraf | Order'a bağlanma şekli | Not |
|---|---|---|
| Buyer | Anlık kopya (BuyerCopy, buyerAddress, buyerInvoiceAddress) | Sipariş anındaki alıcı/adres bilgisini dondurur — bilinçli tasarım. |
| Warehouse | Anlık kopya (WarehouseCopy) | Aynı şekilde dondurulmuş. |
| Officer | Anlık kopya (pickerOfficer, buyerOfficers) | Aynı şekilde dondurulmuş. |
| Seller | Yok — doğrudan bağ yok | Sadece StockEntry.seller üzerinden dolaylı (2 sıçrama), otomatik populate edilmiyor. |
| Payment | Gerçek ilişki, tek yönlü — purchase.payment: ObjectId ref 'Payment' | Ters yönde Payment.orderId sadece string, ref tanımlı değil — Payment'tan Order'a populate edilemez. |
| Transfer | Gerçek ilişki — transfers[] ve item bazlı transfer, ref: 'BuyerOrderTransfer' | İki yönde de sorgulanabilir. |
| Stock (yeni) | Gerçek ilişki — item bazlı stockEntryReferences[] (ref: 'StockEntry'), stockExitReference (ref: 'StockExit') | Bu zincir zaten StockEntry.seller'a kadar uzanıyor — bkz. Yeni ihtiyaçlar. |
| Stock (eski) | Gerçek ilişki — stockInReferences[], stockOutReference | Legacy sistemin paralel kalıntısı. |
| Invoice | Gevşek referans — Order tarafında sadece düz bir özet (BuyerOrderInvoice: documentNo, uuid, tutar); Invoice tarafında invoiceLineReferences[].referenceId sadece string, ref yok | İki yönde de gerçek ilişki yok. |
| Financial / Cari | Gevşek referans — AccountTransaction.referenceId / referenceType sadece string, ref yok, referenceType için enum bile tanımlı değil (yorum satırında "ORDER, PAYMENT vs." yazıyor) | En gevşek bağ burada. |
| Product (catalog) | Kopya (productId: number) | Mongo→MySQL arası olduğundan native ref zaten mümkün değil. |
Sonuç
Karışık bir tablo: Payment, Transfer ve Stock tarafı gerçek Mongoose ilişkileriyle bağlı — sorgulanabilir, zincirlenebilir. Invoice ve Financial/Cari tarafı ise gerçekten tekil yaşıyor — order ile aralarında veritabanı seviyesinde hiçbir bağ yok, sadece iki ayrı koleksiyonda aynı ID'nin metin olarak durmasına güveniliyor. Ayrıca bu iki modül birbirinden habersiz, aynı problemi (gevşek referans) farklı şekilde çözmüş: invoice bir type enum'u tanımlamış (InvoiceLineReferenceType.ORDER), financial ise referenceType için enum bile tanımlamamış.
Bu, Yeni ihtiyaçlar sayfasındaki "satış-alış izlenebilirliği" ihtiyacının asıl can alıcı noktası: stok zinciri zaten sağlam, ama fatura ve cari tarafı sipariş sürecinden yapısal olarak kopuk.
Açık soru
v2'de Invoice.invoiceLineReferences ve AccountTransaction.referenceId/referenceType alanlarının gerçek Mongoose ObjectId + ref ilişkilerine çevrilmesi (ya da en azından iki modülün ortak, tutarlı bir "discriminated reference" deseni kullanması) gündeme alınmalı.
Bu sayfa sadece satış tarafını (order'ın kendisini) inceliyor. Alış tarafı (satıcıdan giren mal) ve iki yönlü iade için: Uçtan uca izlenebilirlik.