Tedarikçi Fiyat Listeleri ve Sözleşmelerini Yönetecek Bir Web Uygulaması Oluşturun

Uygulama Ne Çözmeli (ve Kimler İçin)

Çoğu tedarikçi fiyatlandırma ve sözleşme kaosu aynı şekilde görünür: fiyat listeleri e-postalanmış elektronik tablollarda kalır, “final_FINAL” PDF’ler paylaşılan sürücülerde durur ve kimse hangi koşulların geçerli olduğundan tam emin değildir. Sonuçlar tahmin edilebilir—geçersiz fiyatların siparişlerde kullanılması, tedarikçilerle önlenebilir anlaşmazlıklar ve fark edilmeden geçen yenilemeler.

Düzeltilecek iş problemleri

İyi bir web uygulaması tedarikçi fiyat listeleri ve sözleşmeler için merkezi bir kaynak oluşturmalı ve değişiklikleri uçtan uca izlenebilir kılmalıdır. Azaltmalıdır:

• Elektronik tablolar, ERP’ler ve gelen kutuları arasında manuel kopyalamayı
• Güncel olmayan versiyonlardan kaynaklanan fiyatlama hatalarını
• Kaçırılan yenilemeler ve ihbar sürelerini
• En son imzalı belge veya ek için harcanan zamanı

Uygulama kimler için

Sistemi fiyatlandırma ve koşullarla her hafta ilgilenen kişiler etrafında tasarlayın:

• Satınalma (Procurement): fiyat listelerini içe aktarır, güncellemeleri pazarlık eder, yürürlük tarihlerini takip eder
• Finans/Ödeme (Finance/AP): faturalandırılmış fiyatları doğrular, para birimlerini, birimleri, vergileri/ücretleri kontrol eder
• Hukuk/Uyum (Legal/Compliance): imzalı anlaşmaları, ekleri, gereken maddeleri saklar
• Onay verenler (Yönetim): fiyat/koşul değişikliklerini gözden geçirir ve onaylar
• Yöneticiler (Admins): kullanıcıları, rolleri, tedarikçi ana verisini, şablonları yönetir

Başarı ölçütleri (işlediğini gösterecek)

Erken birkaç ölçülebilir hedef seçin:

• Fiyat güncellemesini yayımlama süresi (örn. 2 günden 2 saate düşürmek)
• Import hata oranı ve yükleme başına yapılan manuel düzeltme sayısı
• Yenileme hatırlatma isabet oranı (örn. ihbar süresi öncesinde uyarı gönderilen sözleşmelerin %’si)
• Fiyat tutarsızlığı oranı (fatura/Satınalma Emirleri uyumsuzlukları)

"Tamamlanmış" ne demek: ilk sürüm vs sonraki

İlk sürüm için, merkezi tedarikçi kayıtları, doğrulama ile fiyat listesi importu, ana tarihlerle sözleşme saklama, temel onay, arama ve denetim izi hedefleyin.

Sonraki yinelemeler daha derin ERP entegrasyonları, madde kütüphaneleri, otomatik fatura eşleştirme, çoklu kuruluş desteği ve gelişmiş raporlama panoları ekleyebilir.

Gereksinimler ve İş Akışı Eşlemesi

Ekranları veya tabloları çizmeye başlamadan önce, bir tedarikçi fiyat listesi gönderdiği andan birinin buna göre sipariş verdiği ana kadar aslında neler olduğunu eşleyin. Bu, gerçekten kontrollü bir fiyatlama sistemi gerektiğinde genel bir “belge deposu” inşa etmenizi engeller.

Mevcut iş akışını eşleyin (as-is)

Önce satınalma, finans ve hukuk ile gerçek bir örnek üzerinden yürüyün. Her adımda devralmaları ve artefaktları yakalayın:

• Fiyat listesi alınır (e-posta, portal, elektronik tablo, EDI) → alım tarihini ve kaynağı kaydedin
• İnceleme ve pazarlık → soruları, karşı teklifleri ve kabul edilen değişiklikleri kaydedin
• Fiyat ve koşulları onaylayın → karar noktalarını ve gereken imzaları belirleyin
• Sözleşmeyi imzalayıp saklayın → koşulları yürürlükteki fiyat listesiyle ilişkilendirin
• İşletme ve yenileme → sona erme, fiyat değişiklikleri ve istisnaları izleyin

Basit bir yüzme şeridi diyagramı (Supplier → Buyer/Procurement → Legal → Finance → Operations) genellikle yeterlidir.

Kilit kararları ve rollerin kim olduğunu belirleyin (kim ne yapabilir)

İş sonuçlarını değiştiren kararları listeleyin ve net sahipler atayın:

• Kim yeni bir fiyat listesini onaylayabilir, kim bir sözleşme ekini onaylayabilir?
• Kim fiyat alanlarını (para birimi, birimler, MOQ, tedarik süresi) düzenleyebilir, kim sadece değişiklik talep edebilir?
• Kim hassas sözleşme koşullarını (ödeme koşulları, sorumluluk maddeleri) görebilir, kim kısıtlanmalı?

Ayrıca onayların eşiklere göre farklılaştığı yerleri not edin (örn. %5’ten büyük artış finans onayı gerektirir) ki bu kuralları sonra kodlayabilesiniz.

Gerekli çıktıları tanımlayın (insanların yapılması gerekenleri)

Uygulamanın ilk günde cevaplaması gereken kesin soruları yazın:

• “T bugün itibarıyla tedarikçi Y’den X kalemi için geçerli fiyat nedir?”
• “Hangi sözleşmeler önümüzdeki 60/90 gün içinde sona eriyor ve yenileme kimde?”
• “Hangi istisnalarımız var: geçerli olmayan fiyatların kullanımı, eksik MOQ’lar, para birimi uyumsuzlukları?”

Bu çıktılar veri alanlarını, aramayı ve raporları yönlendirmeli—tersine değil.

Ağrı noktalarını ve uç durumları erken yakalayın

Satınalma verisi dağınıktır. Yaygın istisnaları açıkça belgeleyin:

• Kısmi güncellemeler (tedarikçi 20 SKU güncelliyor, tam kataloğu değil)
• Birden fazla para birimi ve döviz varsayımları
• MOQ’lar, paketleme boyutları, birimler (adet vs kutu) ve yuvarlama
• Çakışan yürürlük tarihleri veya geriye dönük düzeltmeler

Bu listeyi import ve onay için kabul kriterleri olarak ele alın, böylece sistem gerçekliği destekler, çalışma yolları zorlamaz.

Yüksek Seviyeli Mimari ve Modül Dağılımı

Tedarikçi fiyat listeleri ve sözleşmeler için iyi bir mimari trendlerden çok koordinasyon yükünü azaltmak ve büyümeye açık kapı bırakmakla ilgilidir.

İnşa yaklaşımı: basitle başla, kasıtlı evril

Çoğu ekip (1–6 mühendis) için en iyi başlangıç noktası bir modüler monolit: açık sınırları ve modülleri olan tek dağıtılabilir uygulama. Daha hızlı geliştirme, daha basit hata ayıklama ve daha az operasyonel bileşen elde edersiniz.

Açık bir neden olmadıkça (örn. yoğun import yükleri, bağımsız ölçekleme ihtiyacı, paralel çalışan çoklu ekipler veya sıkı izolasyon gereksinimleri) servislere geçmeyin. Yaygın yol: modüler monolit → import/işleme ve belge iş yüklerini background worker’lara çıkar → gerekirse yüksek trafikli alanları servislere ayır.

Eğer ilk çalışan prototipi (ekranlar, iş akışları ve rol tabanlı erişim) hızla hızlandırmak istiyorsanız, yapılandırılmış bir sohbet spesifikasyonundan React + Go + PostgreSQL tabanını üretebilen bir platform olan Koder.ai size yardımcı olabilir. Bu, genellikle importlar, onaylar ve denetim izlerini gerçek kullanıcılarla daha erken doğrulamak için kullanışlıdır—fazla inşa etmeden önce gerçek akışları test etmenizi sağlar.

Çekirdek modüller (anlaşılır kılan minimum set)

Uygulamayı birkaç sabit alana göre tasarlayın:

• Suppliers: tedarikçi profili, kişiler, tanımlayıcılar, durum
• Catalog (Items/Materials): dahili ürün ana verisi ve tedarikçi ürün kodlarıyla eşleme
• Price Lists: başlıklar (tedarikçi, geçerlilik dönemi) ve satırlar (fiyatlar, birimler, para birimleri) ile import geçmişi
• Contracts: sözleşme kayıtları, ilişkilendirilen tedarikçiler, kapsanan maddeler/kategoriler, ana tarihler ve ilişkili belgeler
• Approvals & Governance: inceleme adımları, onay, yorumlar ve karar geçmişi
• Reporting: arama, dışa aktarma, harcama/fiyat görüntüleri ve operasyonel özetler

Her modülü kendi kuralları ve veri erişimi için sorumlu tutun. Monolit içinde bile kodda sınırlar (paketler, adlandırma ve modüller arası net API’ler) uygulayın.

Entegrasyonları erken planlayın (gün 1 yapmasanız bile)

Entegrasyonlar veri akışını değiştirir; bu yüzden genişletme noktaları ayırın:

• SSO (SAML/OIDC) için kimlik doğrulama ve kullanıcı tedariki
• ERP/finans sistemleri için tedarikçi kimlikleri, ürün ana verisi ve onaylı fiyatların push’lanması
• E-posta/takvim için yenileme hatırlatmaları ve onay bildirimleri
• Belge imzalama (opsiyonel) ekler ve yeni anlaşmaları sonlandırmak için

Fonksiyonel olmayan ihtiyaçlar (göndermeden önce hedefleri belirleyin)

Ölçülebilir beklentileri baştan tanımlayın:

• Performans: yaygın aramalar <2 saniye; importlar eşzamansız işlenirken ilerleme görünürlüğü
• Kullanılabilirlik: net çalışma süresi hedefi ve planlı bakım pencereleri
• Yedekleme & kurtarma: otomatik yedekler, geri yükleme tatbikatları ve saklama politikasına uygun tutma
• Denetlenebilirlik: importlar, onaylar ve sözleşme değişiklikleri için değişmez olay geçmişi; kullanıcı ve zaman damgası ile izlenebilirlik

Veri Modeli: Varlıklar, İlişkiler ve Versiyonlama

Temiz bir veri modeli satınalma uygulamasını güvenilir kılar. Kullanıcılar “3 Mart’ta hangi fiyat geçerliydi?” veya “O satın almayı hangi sözleşme yönetti?” diye sorduğunda veritabanı cevap verebilmelidir.

Çekirdek varlıklar (güveneceğiniz minimum)

Küçük bir iyi tanımlanmış kayıt setiyle başlayın:

• Supplier: satıcı hesabı (isim, tedarikçi kodu, durum, varsayılan para birimi, ödeme koşulları)
• Contact: tedarikçideki kişiler (her tedarikçi için birden fazla)
• Item/SKU: satın alınan şey (ürün kodu, açıklama, kategori, ölçü birimi)
• PriceList: tedarikçi tarafından sağlanan liste veya pazarlıklı tarif (isim, yürürlük tarihleri, para birimi, dosya kaynağı, durum)
• PriceLine: bir listede yer alan fiyatlar (ürün, birim fiyat, kırılımlar/MOQ varsa, vergi bayrakları)
• Contract: ticari anlaşma (sözleşme numarası, tedarikçi, başlangıç/bitiş tarihleri, yenileme ayarları, durum)
• Term: aranıp raporlanmasını istediğiniz yapılandırılmış maddeler (tedarik süresi, garanti, teslimat, hizmet seviyeleri)

Her şeyi bağlı tutan ilişkiler

Alıcıların çalışma şeklini yansıtacak ilişkiler modelleyin:

• Supplier → Contracts: bir tedarikçinin birçok sözleşmesi olabilir
• Supplier → PriceLists: bir tedarikçinin zaman içinde birden fazla fiyat listesi olabilir
• Contract → PriceLists (opsiyonel ama faydalı): bir sözleşmeyi yöneten fiyat listelerini ilişkilendirin
• Item/SKU → PriceLines: bir ürün birçok fiyat satırında yer alabilir (farklı tedarikçiler, para birimleri, yürürlük tarihleri)

Birden çok sevkiyat noktası veya işletme birimi destekliyorsanız, sözleşme ve fiyat listelerine eklenebilecek bir Scope (şirket, site, bölge) kavramı eklemeyi düşünün.

Versiyonlama: geçmişi silmeyin

Canlı kayıtları yerinde düzenlemekten kaçının. Bunun yerine:

• Fiyat listesi versiyonlaması: her import yeni bir PriceList versiyonu oluşturur (veya ortak bir “aile” kimliğiyle yeni PriceList kaydı). Önceki versiyonlar salt okunur kalsın.
• Sözleşme ekleri: her ek yeni bir versiyon olarak saklansın; kendi yürürlük tarihi ve ilişkilendirilmiş belgeleri olsun. “Güncel” sözleşme görünümü en son onaylı versiyondur.

Bu, audit sorularını kolaylaştırır: ne zaman onaylandığını ve nelerin değiştiğini yeniden inşa edebilirsiniz.

Referans verisi ve benzersizlik kuralları

Referans verisini ayrı tablolarda tutun, serbest metin kirliliğini önleyin:

• Currency, Unit of Measure, Tax Code ve (uluslararası gönderim varsa) Incoterms

Sessiz çoğaltmaları önlemek için tanımlayıcıları zorlayın:

• Supplier code sistem genelinde benzersiz
• Item code benzersiz (veya katalog/kaynağa göre benzersiz)
• Contract number tedarikçi başına benzersiz (veya global—tutarlı bir politika seçip uygulayın)

Fiyat Listesi Importu: Şablonlar, Doğrulama ve Hata Yönetimi

Fiyat listeleri genellikle makineler için tasarlanmamış elektronik tablolarda gelir. Sorunsuz bir import akışı, “uygulamayı kullanacağız” ile “Excel gönderimini sürdüreceğiz” arasındaki farktır. Hedef: yüklemeyi hoşgörülü, kaydedilen veriyi katı yapmak.

Desteklenen formatlar ve indirilebilir şablon

Gün 1 için CSV ve XLSX destekleyin. CSV ERP’lerden ve BI araçlarından dışa aktarımlar için iyidir; XLSX tedarikçilerin gerçekten gönderdiği şeydir.

Veri modelinizi yansıtan bir indirilebilir şablon sağlayın (ve tahminleri azaltın). İçersin:

• Kesin sütun adlarını içeren ilk satır
• Geçerli değerleri gösteren örnek satır (para birimi, birim, tarih)
• Her sütunu açıklayan opsiyonel bir "notlar" sayfası (XLSX için)

Şablonu versiyonlayın (örn. Template v1, v2) ki süreçleri kırmadan evrimleşebilsin.

Eşleme kuralları: zorunlu vs isteğe bağlı sütunlar

Eşleme kurallarını açıkça tanımlayın ve yükleme sırasında UI’da gösterin.

Yaygın yaklaşım:

• Zorunlu sütunlar: tedarikçi tanımlayıcısı, item/SKU, fiyat, para birimi, ölçü birimi, geçerlilik başlangıç tarihi
• İsteğe bağlı sütunlar: geçerlilik bitiş tarihi, minimum sipariş miktarı, tedarik süresi, paketleme, incoterms, notlar
• Varsayılan değerler (tedarikçi veya yükleme başına): para birimi, birim, başlangıç tarihi “bugün”, bitiş boş

Özel sütunlara izin verirseniz, bunları metadata olarak saklayın ki çekirdek fiyat şemasını kirletmesinler.

Kötü veriyi engelleyen doğrulama kuralları

Hiçbir şey kaydedilmeden önce doğrulama çalıştırın:

• Sayısal formatlar: sayısal olmayan fiyat hücrelerini reddedin; binlik ayırıcıları normalize edin; negatif olmayan fiyat zorlayın
• Para birimi kodları: ISO 4217’ye karşı doğrulayın (örn. USD, EUR)
• Tarih aralıkları: başlangıç tarihi zorunlu; bitiş başlangıçtan sonra olmalı; aynı ürün için çakışan yürürlük aralıklarını önleyin (kural gerektiriyorsa)
• Yinelenen satırlar: aynı anahtarları (örn. supplier + SKU + start date + currency + unit) tespit edin. Yinelenenler hata mı yoksa "sonuncu geçer" mi kararı verin (hata daha güvenlidir)

Hem satır düzeyinde doğrulama (bu satır hatalı) hem de dosya düzeyinde doğrulama (bu yükleme mevcut kayıtlarla çelişiyor) yapın.

Hata yönetimi: önizleme, satır düzeyi geri bildirim ve yeniden yükleme

İyi bir import deneyimi şöyle görünür: Yükle → Önizle → Düzelt → Onayla.

Önizleme ekranında:

• Hücreleri vurgulayarak ve net mesajlar göstererek bir tablo sunun (örn. “Invalid currency code: US$”)
• Ekstra bir “error” sütunu ile hata raporu (CSV) indirme imkanı verin
• Son denemeden eşleme seçimlerini koruyan düzelt ve yeniden yükle akışı sağlayın

“Tüm dosyayı tek kötü satır için başarısız kıl”dan kaçının. Bunun yerine kullanıcılara seçim hakkı verin: geçerli satırları içe al veya tüm hatalar düzeltilene kadar engelle—yönetim kararına göre.

İzlenebilirlik için ham yüklemeleri saklayın

Denetim ve yeniden işlem kolaylığı için saklayın:

• Orijinal ham dosya (kesin baytlar), checksum ve yükleyen kimliği ile
• Ayrıştırılmış satırlar ve doğrulama sonuçları (hatalar dahil)
• Import konfigürasyonu (şablon versiyonu, sütun eşlemesi, varsayılanlar)

Bu, anlaşmazlıklarda savunulabilir bir iz oluşturur (“neyi, ne zaman içe aldık?”) ve doğrulama kuralları değiştiğinde yeniden işlemeye izin verir.

Sözleşme Kayıtları: Koşullar, Belgeler ve Ekler

Bir sözleşme kaydı sadece dosya dolabı olmamalı. Yenilemeleri, onayları ve raporlamayı yönlendirecek kadar yapılandırılmış veri içermeli—aynı zamanda imzalı belgeleri kolay bulunur kılmalıdır.

Temel sözleşme maddeleri (yapılandırılmış alanlar)

Satınalmanın her hafta aldığı soruları cevaplayan alanlarla başlayın:

• Sözleşme başlangıç ve bitiş tarihi
• Yenileme tipi (otomatik yenileme, belirli süre, evergreen) ve yenileme süresi
• İhbar süresi (örn. “bitiş tarihinden 60 gün önce”) ve kim bilgilendirilmeli
• Ödeme koşulları (Net 30/45/60, erken ödeme indirimi) ve faturalama kuralları
• Sözleşme sahibi, tedarikçi iletişimi ve iç paydaşlar

Karmaşık durumlar için serbest metin notları tutun; ancak filtreleyeceğiniz, gruplayacağınız veya uyarı üreteceğiniz her şeyi normalize edin.

Belgeler, ekler ve saklama

Belgeleri sözleşmeye bağlı birinci sınıf öğeler olarak ele alın:

• İmzalı anlaşma (PDF)
• Ekler/ilaveler
• İş tanımları, fiyat çizelgeleri, sigorta belgeleri, uyumluluk dokümanları

Her dosya için meta verisi saklayın: belge türü, yürürlük tarihi, versiyon, yükleyen ve gizlilik seviyesi. Kuruluşun saklama gereksinimleri varsa “retention until” ve “legal hold” gibi alanlar ekleyin ki uygulama silmeyi engellesin ve denetimleri desteklesin.

Ekler ve madde takibi

Ekler geçmişi silmemeli. Bunları tarihlendirilmiş değişiklikler olarak modelleyin: süre uzatma, ticari koşullarda ayarlama veya kapsam ekleme/çıkarma.

Mümkün olduğunda, fesih hakkı, endeksleme formülü, hizmet kredileri, sorumluluk sınırı, münhasırlık gibi ana maddeleri yapılandırılmış veri olarak yakalayın ki uyarı ve raporlama mümkün olsun.

Bir sözleşme, birçok tedarikçi veya site

Merkezi satın alma yapıyor ama birçok lokasyonda işletiyorsanız, tek bir sözleşmeyi birden fazla site/iş birimine bağlama ve site düzeyinde (fatura adresi, teslim koşulları gibi) istisnalar ekleme desteği verin. Benzer şekilde, bir sözleşmenin ana tedarikçi ve bağlı iştirakleri kapsamasına izin verin, ancak uyumluluk için net bir "sözleşmeye taraf" tutun.

Onay İş Akışı ve Yönetişim

Onaylar fiyat listeleri ve sözleşmelerin savunulabilir hale geldiği yerdir. Net bir iş akışı “bunu kim onayladı?” tartışmalarını azaltır ve tedarikçi gönderisinden kullanılabilir, uyumlu veriye tekrar edilebilir bir yol yaratır.

Durum akışı (açık tutun)

Fiyat listeleri ve sözleşme kayıtları için basit, görülebilir bir yaşam döngüsü kullanın:

Draft → Review → Approved → Active → Expired/Terminated

• Draft: gönderici tarafından düzenlenebilir; satın alma için kullanılmaz.
• Review: yalnızca istenen değişikliklerle düzenlenebilir; gözden geçirenler tamamlığı ve politika uygunluğunu kontrol eder.
• Approved: karar kaydedilir; tarih kurallarına göre aktif hale getirilmeye hazır.
• Active: sipariş için geçerli; değişiklikler yeni revizyon ve onay gerektirir.
• Expired/Terminated: salt okunur; raporlama ve denetim için saklanır.

Roller ve sorumluluklar

Uygulamada sorumlulukları tanımlayın (yerel bilgiye bırakmayın):

• Gönderen (Submitter — Procurement/Supplier manager): fiyat listelerini yükler, sözleşme taslakları hazırlar, inceleme yorumlarına yanıt verir
• İnceleyen (Reviewer — Category/Finance): fiyatları, birimleri, para birimlerini ve ticari uyumu kontrol eder
• Onaylayan (Approver — Budget owner): ticari etkisi olan kararları sonlandırır
• Hukuk (Legal): sözleşme dili, belgeler ve ekler için gerekli gözden geçiren/onaylayandır
• Admin: eşik kurallarını, yönlendirme kurallarını ve izinleri yapılandırır—varsayılan olarak iş içeriğini onaylamamalıdır

Fiyat değişikliği kuralları (gizli maliyet artışlarını önleyin)

Ek onay adımları tetikleyen politika odaklı kontroller ekleyin:

• Eşik onayları: örn. herhangi bir satır öğesi >%5 artıyorsa veya toplam kategori harcama etkisi 10.000 $’ı geçiyorsa daha üst onaylayıcıya yönlendir
• Kategori bazlı yönlendirme: stratejik kategoriler (IT, lojistik) her zaman hukuk + bütçe sahibini gerektirebilir
• İstisna yönetimi: geçersiz kılmalara sadece zorunlu neden ve ek ile izin verin

Denetime hazır kararlar: yorumlar, nedenler ve kanıt

Her onay/reddetme aşağıdakileri yakalamalı:

• karar (onay/reddet/değişiklik talebi)
• neden kodu + serbest metin açıklama
• zaman damgası, aktör ve etkilenen revizyon
• bağlantılı kanıt (e-posta PDF’si, tedarikçi yazısı, toplantı notları)

Yükseltme, zaman aşımı ve hesap verebilirlik

Onayların tıkanmaması için hizmet düzeyi beklentileri belirleyin:

• 24/48 saatte otomatik hatırlatmalar
• belirli süre sonra yedek onaylayıcıya yönlendirme
• “Bekleyen onaylarım” kuyruğu ve gecikmiş raporu ile görünürlük

Yönetişim, iş akışına gömüldüğünde en iyi şekilde çalışır—sonradan zorla değil.

Kullanıcı Deneyimi: Ekranlar, Arama ve Raporlama

Bir satınalma uygulamasının başarısı basit sorulara ne kadar hızlı cevap verdiğiyle ölçülür: “Güncel fiyat nedir?”, “Hangi sözleşme bu maddeyi yönetiyor?” ve “Geçen çeyrekte neler değişti?” UI’ı bu iş akışlarına göre tasarlayın, veritabanı tablolarına göre değil.

Bilgiyi hızlı bulun: arama ve filtreler

Üst gezinmede iki ana giriş noktası sunun:

• Supplier arama (isim, vergi kimliği/tedarikçi kodu, durum, kategori)
• Ürün arama (SKU/parça no, açıklama, üretici, birim)

Sonuç sayfalarında sözleşme filtreleri gerçek işlerle eşleşecek şekilde olsun: yürürlük tarihi, sözleşme durumu (taslak/aktif/sona ermiş), iş birimi, para birimi ve “bekleyen onayı var” gibi. Filtreleri görünür tutun ve çıkarılabilir chip’ler olarak gösterin.

İlk tasarlanacak önemli ekranlar

Tedarikçi profili merkez olmalı: aktif sözleşmeler, en son fiyat listesi, açık anlaşmazlıklar/notlar ve “son etkinlik” paneli.

Sözleşme görünümü “Ne satın alabiliriz, hangi koşullarda, ne zamana kadar?” sorusunu yanıtlamalı. Ana maddeleri (incoterms, ödeme koşulları), ekleri ve eklerin zaman çizelgesini gösterin.

Fiyat listesi karşılaştırması kullanıcıların zamanının geçtiği yerdir. Mevcut vs önceki yan yana gösterin:

• Yürürlük tarihleri (ve “gelecekte”ki fiyatlar)
• Kalem bazında farklar (mutlak ve % değişim)
• Yeni/çıkarılan kalemleri vurgulama

Raporlama ve dışa aktarmalar

Raporlar eyleme dönüştürülebilir olmalı: “60 gün içinde sona eriyor”, “en büyük fiyat artışları”, “birden fazla aktif fiyatı olan ürünler”. Finans için CSV, paylaşım/onay için PDF dışa aktarma sunun; filtreler aynı şekilde uygulanmalı ki dışa aktarılan veri görünenle eşleşsin.

Basit ve açıklayıcı tutun

Açık etiketler kullanın (“Effective date” yerine “Yürürlük tarihi”), karmaşık alanlarda inline yardım, ve boş durumlar için bir sonraki adımı açıklayan mesajlar (“Fiyat listesi yükleyerek değişiklikleri takip etmeye başlayın”). Kısa bir yönlendirme kontrol listesi /help üzerinde eğitim süresini azaltır.

Güvenlik, İzinler ve Denetim İzi

Güvenlik, iş akışına baştan entegre edildiğinde daha kolaydır. Hedef: insanlar sadece sorumlu olduklarını görsün/değiştirsin ve her önemli değişiklik izlenebilir olsun.

Roller ve izinler (en az ayrıcalık)

Küçük, net bir rol modeliyle başlayın ve eylemlere eşleyin, sadece ekranlara değil:

• Viewer: onaylı fiyatlar ve aktif sözleşmeler için salt okunur
• Editor: taslak oluşturur, belge yükler, import hatalarını düzeltir
• Approver: taslakları onaylar/reddeder, ekleri kilitler
• Admin: kullanıcıları, rolleri, referans veriyi ve sistem ayarlarını yönetir

İzinler her uç nokta için sunucu tarafında uygulanmalı (sadece UI yetkisi yeterli değildir). Kuruluş karmaşıksa, kapsam kuralları (tedarikçi/iş birimi/bölge bazlı) ekleyin.

Hassas veri işleme

Başta hangi verilerin ekstra korunması gerektiğine karar verin:

• Sözleşme dosyaları (PDF’ler, taramalar): dinlenme halinde şifreleme, indirme kısıtlama ve isteğe bağlı watermark
• Banka detayları: ayrı, daha kısıtlı bir alanda saklanmalı; görünürlük dar bir finans rolü ile sınırlandırılmalı
• Fiyat görünürlüğü: marjlar veya özel fiyatlar geniş kitlelerden gizlenebilir; gerekirse “iç vs tedarikçi tarafı” görünümleri destekleyin

Denetim izi: kim neyi nasıl değiştirdi

Ana varlıklar (sözleşmeler, maddeler, fiyat öğeleri, onaylar) için değişmez bir denetim kaydı tutun: kim, neyi (önce/sonra), ne zaman ve kaynak (UI/import/API). Import dosyası adı ve satır numarasını kaydedin ki sorunlar izlenip düzeltilebilsin.

Kimlik doğrulama ve oturum temelleri

Birincil giriş yöntemini seçin:

• Kurumsal kullanıcılar için SSO (SAML/OIDC) veya daha küçük ekipler için şifre + MFA

Mantıklı oturum kontrolleri ekleyin: kısa ömürlü erişim token’ları, secure cookie, boşta kalma zaman aşımı ve hassas eylemler için yeniden kimlik doğrulama (örn. fiyat dışa aktarma).

Uyum temelleri (abartmadan)

Pratik kontroller hedefleyin: en az ayrıcalık, merkezi loglama, düzenli yedekler ve testli geri yükleme prosedürleri. Denetim kayıtlarını iş kaydı olarak ele alın—silme kısıtlaması ve saklama politikası tanımlayın.

Fiyat Kuralları: Yürürlük Tarihleri, Para Birimleri ve Birimler

Fiyat nadiren tek bir sayı olur. Uygulama alıcı, AP ve tedarikçi için aynı cevabı vermeli: bugün bu madde için fiyat nedir?

Yürürlük tarihleme (başlangıç/bitiş, gelecek fiyatlar, çakışmalar)

Fiyatları zamanla sınırlı kayıtlar olarak saklayın: başlangıç tarihi ve opsiyonel bitiş tarihi. Gelecekte tarihli satırlara (örn. gelecek çeyrek artışları) izin verin ve “açık uç”un ne anlama geldiğini tanımlayın (genelde: yerine başka bir kayıt gelene kadar geçerli).

Çakışmalar kasıtlı olarak ele alınmalı:

• Varsayılan olarak çakışmaları import sırasında reddet (yönetişim için en iyisi)
• Gerekirse öncelik kuralı ile izin ver, ancak sebep ve onay gerektir

Pratik bir kural: aynı anda bir tedarikçi-ürün-para birimi-birim için bir temel fiyat olsun; diğer tüm durumlar açıkça override olarak işaretlensin.

“Güncel fiyatı” tanımlama

Birden fazla aday varsa sıralı bir seçim tanımlayın, örn:

1. Sözleşme kapsamlı fiyat (sözleşme aktif ve ürün kapsamda ise)
2. Yürürlük aralığında onaylı override (promosyon/istisna)
3. Yürürlük aralığında standart tedarikçi fiyat listesi
4. Yedek veya “fiyat yok” durumu (kullanıcı müdahalesi gerekli)

Sürekli tercih edilen tedarikçileriniz varsa, aynı maddede birden fazla geçerli tedarikçi olduğunda kullanılacak tedarikçi önceliği alanı ekleyin.

Çoklu para birimi stratejisi

Depolamayı seçin:

• Fiyat kaydı başına saklanmış FX oranı (denetlenebilirlik için en iyi; geçmiş kararları yeniden üretir)
• Canlı FX dönüşümü (panolar için kullanışlı; yine de orijinal para birimini saklayın)

Birçok ekip her ikisini yapar: tedarikçi fiyatını orijinal para biriminde saklayın ve raporlama için “as-of” dönüştürülmüş bir değer ekleyin.

Yuvarlama ve birim dönüşümleri

Birim normalizasyonunu (adet vs kasa vs kg) ve dönüşüm faktörlerini versiyonlayın. Yuvarlama kurallarını tutarlı uygulayın (para birimi ondalık hassasiyeti, minimum fiyat artış adımları) ve yuvarlamanın ne zaman gerçekleştiğini açıkça belirtin: birim dönüşümünden sonra mı, FX dönüşümünden sonra mı, yoksa nihai satır toplamında mı.

Yenilemeler, Uyarılar ve Operasyon Panoları

Yenilemeler sözleşme değerinin kazanıldığı veya kaybedildiği yerdir: kaçırılan ihbar dönemleri, gizli otomatik yenilemeler ve son dakika pazarlıkları genellikle olumsuz sonuçlara yol açar. Uygulamanız yenilemeleri yönetilen bir süreç olarak ele almalı: net tarihler, hesap sahibi ve görünür operasyonel kuyruklar.

Yenileme zaman çizelgesi ve hatırlatmalar

Yenilemeyi her sözleşme (ve opsiyonel olarak belirli ekler) için kilometre taşları seti olarak modelleyin:

• Bitiş tarihi (expiration)
• İhbar süresi son tarihi (iptal/pazarlık için son tarih)
• Yenileme pencere başlangıcı (kaynak arama ne zaman başlamalı)

Bu kilometre taşlarına dayalı hatırlatmalar oluşturun. Pratik bir varsayılan: kritik ihbar tarihinden önce 90/60/30 gün ritmi ve ayrıca “gününde” uyarı.

Bildirim kanalları ve iletim

İki kanal ile başlayın:

• Günlük iş kuyrukları için in-app bildirimleri
• Zaman duyarlı hatırlatmalar için e-posta

Opsiyonel olarak bir sözleşme veya kullanıcı için ICS takvim dosyası dışa aktarma desteği verin ki Outlook/Google Calendar’a abone olabilsinler.

Bildirimleri eyleme dönük yapın: sözleşme adı, tedarikçi, kesin son tarih ve kayda derin bağlantı ekleyin.

Sahiplik ve yükseltme

Uyarılar şunlara gitmeli:

• Sözleşme sahibi (birincil)
• Kategori sahibi (farklıysa ikincil)
• Yedek sahibi (kapsama için)

Birincil onaylamazsa X gün içinde yedeğe veya yöneticisine yükseltme kuralları ekleyin. “Onaylandı” zaman damgası takibi ekleyin ki uyarılar arka plan gürültüsüne dönüşmesin.

Operasyon panoları işi harekete geçiren

Panolar basit, filtrelenebilir ve rol-odaklı olmalı:

• Yakında süresi dolan sözleşmeler (30/60/90 gün, ihbar tarihleri dahil)
• Yenileme görevleri gecikmiş olan sözleşmeler
• Onay bekleyen fiyat listeleri (yaş, sahip, tedarikçi)

Her widget filtrelenmiş bir liste görünümüne ve dışa aktarma bağlantısına sahip olmalı ki pano eyleme başlamak için bir başlangıç noktası olsun—sadece raporlama değil.

MVP Planı, Test ve Yayılım Kontrol Listesi

Tedarikçi fiyat listeleri ve sözleşmeler için bir MVP bir şeyi kanıtlamalı: ekipler fiyatları güvenle yükleyebiliyor, doğru sözleşmeyi hızlıca buluyor ve onaylar ile denetim geçmişine güvenebiliyor.

MVP kapsamı (olmazsa olmazlar)

İzleyin: uçtan uca ince ama eksiksiz bir akış—çok sayıda izole özellik yerine:

• Supplier + ürün ana verisi: tedarikçiler, ürün/hizmetler, birimler, para birimleri
• Fiyat listesi importu: bir veya iki şablon (CSV/XLSX), önizleme, alan eşleme (gerekirse), doğrulama ve net hata raporu
• Sözleşme kaydı: ana tarihler (başlangıç/bitiş, ihbar süresi, yenileme tipi), ekler ve tedarikçi ile fiyat listesi versiyonlarına bağlantı
• Onaylar: basit bir iş akışı (Draft → Review → Approved) ile rol tabanlı izinler ve denetim kaydı
• Arama + raporlama: global arama (tedarikçi, SKU, sözleşme ID) ve “mevcut onaylı fiyatlar” için bir dışa aktarım

Hızlı ilerlemek isteyen küçük ekipler için, ilk iskeleti (React frontend, Go backend, PostgreSQL) Koder.ai kullanarak ayağa kaldırıp procurement/legal paydaşlarıyla doğrulamak sonra kodu sertleştirmek hızlı bir yol olabilir.

Test planı (gerçekte ne kırılır)

Hataların maliyetli olduğu yerlere odaklanın:

• Import doğrulama testleri: eksik zorunlu sütunlar, geçersiz para birimleri/birimler, yinelenen satırlar, tarih çakışmaları, negatif fiyatlar, karışık ondalık ayırıcılar
• İzin testleri: kim import edebilir, kim onaylayabilir, onaydan sonra kim düzenleyebilir, hassas ekleri kim görebilir
• İş akışı testleri: düzenleme sonrası yeniden onay, reddetme yorumlarının zorunlu olması, her durum değişikliği için denetim girdisi oluşturulması

Yayılım ve dağıtım

Staging ortamında production’a benzeyen (anonimleştirilmiş) veri seti kullanın. Kontrol listesi: yedekler etkin, migration script’leri prova edilmiş ve geri alma planı (versiyonlanmış DB migration’ları + dağıtım geri alma) hazır olsun.

Import hataları, aramada yavaş sorgular ve onay darboğazları için izleme kurun.

Lansmandan sonra yineleme

Satınalma ve finans ile 2–4 haftalık geri bildirime dayalı döngü çalıştırın: importlardaki en yaygın hatalar, sözleşmelerde eksik alanlar ve yavaş ekranlar. Sonraki öncelikler: ERP entegrasyonları, tedarikçi portalı yüklemeleri, tasarruf ve uyum analitikleri.

Suggested internal reads: /pricing and /blog.