DoğruTeklif’i İnşa Ederken #02: RFQ veri modelinin temelleri

Bir RFQ formdan fazlasıdır

Teklif talebi ilk bakışta başlık, açıklama, miktar ve son tarih alanlarından oluşan bir form gibi görünür. Oysa gerçek süreçte talep yayınlandıktan sonra sorular gelir, teknik dosya güncellenir, termin değişir ve bazı tedarikçiler davet edilirken bazıları kapsam dışı kalır.

Bu nedenle RFQ'yu tek bir satır değil; sürümü, durumu, katılımcıları ve olay geçmişi olan bir iş nesnesi olarak modelliyoruz. Değişiklik yapıldığında yalnızca son değer değil, teklif verenlerin hangi bilgiye göre karar verdiği de önemlidir.

Durum makinesi iş kurallarını görünür kılar

Taslak, yayınlandı, soru-cevap, teklif toplama kapandı, değerlendirme ve sonuçlandı gibi durumlar yalnızca arayüz etiketi değildir. Her durum hangi işlemlerin yapılabileceğini belirler.

Örneğin kapanmış bir talebe yeni teklif eklenemez; önemli bir teknik revizyon yapıldığında mevcut tekliflerin yeniden onaylanması gerekebilir. Bu kuralları dağınık ekran kontrolleri yerine açık bir durum makinesinde toplamak, hem backend hem kullanıcı deneyimini daha öngörülebilir yapar.

Karşılaştırılabilir veri

Teklifleri yalnızca toplam fiyat üzerinden sıralamak yanıltıcıdır. Para birimi, vergi, teslim şekli, termin, minimum sipariş, ödeme koşulu ve teknik sapmalar aynı bağlamda tutulmalıdır.

Veri modelindeki temel ayrım şudur:

• Alıcının talep ettiği şartlar
• Tedarikçinin kabul ettiği veya değiştirdiği şartlar
• Sistem tarafından hesaplanan karşılaştırma değerleri
• Tarafların eklediği açıklama ve belgeler

Bu ayrım sayesinde sistem fiyatı normalize edebilir fakat ticari kararı kullanıcı adına gizlice vermez. DoğruTeklif'in hedefi “en ucuzu seçmek” değil; farklı tekliflerin gerçekten aynı ihtiyaca cevap verip vermediğini görünür hale getirmektir.