Tedarikçi fiyat listeleri ve sözleşmeler için web uygulaması oluşturma adım adım planı: importlar, onaylar, yenilemeler, denetim izi ve güvenli kullanıcı erişimi.
Ç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.
İ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:
Sistemi fiyatlandırma ve koşullarla her hafta ilgilenen kişiler etrafında tasarlayın:
Erken birkaç ölçülebilir hedef seçin:
İ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.
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.
Önce satınalma, finans ve hukuk ile gerçek bir örnek üzerinden yürüyün. Her adımda devralmaları ve artefaktları yakalayın:
Basit bir yüzme şeridi diyagramı (Supplier → Buyer/Procurement → Legal → Finance → Operations) genellikle yeterlidir.
İş sonuçlarını değiştiren kararları listeleyin ve net sahipler atayın:
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.
Uygulamanın ilk günde cevaplaması gereken kesin soruları yazın:
Bu çıktılar veri alanlarını, aramayı ve raporları yönlendirmeli—tersine değil.
Satınalma verisi dağınıktır. Yaygın istisnaları açıkça belgeleyin:
Bu listeyi import ve onay için kabul kriterleri olarak ele alın, böylece sistem gerçekliği destekler, çalışma yolları zorlamaz.
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.
Ç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.
Uygulamayı birkaç sabit alana göre tasarlayın:
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 veri akışını değiştirir; bu yüzden genişletme noktaları ayırın:
Ölçülebilir beklentileri baştan tanımlayın:
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.
Küçük bir iyi tanımlanmış kayıt setiyle başlayın:
Alıcıların çalışma şeklini yansıtacak ilişkiler modelleyin:
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.
Canlı kayıtları yerinde düzenlemekten kaçının. Bunun yerine:
Bu, audit sorularını kolaylaştırır: ne zaman onaylandığını ve nelerin değiştiğini yeniden inşa edebilirsiniz.
Referans verisini ayrı tablolarda tutun, serbest metin kirliliğini önleyin:
Sessiz çoğaltmaları önlemek için tanımlayıcıları zorlayın:
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.
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:
Şablonu versiyonlayın (örn. Template v1, v2) ki süreçleri kırmadan evrimleşebilsin.
Eşleme kurallarını açıkça tanımlayın ve yükleme sırasında UI’da gösterin.
Yaygın yaklaşım:
Özel sütunlara izin verirseniz, bunları metadata olarak saklayın ki çekirdek fiyat şemasını kirletmesinler.
Hiçbir şey kaydedilmeden önce doğrulama çalıştırın:
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.
İyi bir import deneyimi şöyle görünür: Yükle → Önizle → Düzelt → Onayla.
Önizleme ekranında:
“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.
Denetim ve yeniden işlem kolaylığı için saklayın:
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.
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.
Satınalmanın her hafta aldığı soruları cevaplayan alanlarla başlayın:
Karmaşık durumlar için serbest metin notları tutun; ancak filtreleyeceğiniz, gruplayacağınız veya uyarı üreteceğiniz her şeyi normalize edin.
Belgeleri sözleşmeye bağlı birinci sınıf öğeler olarak ele alın:
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 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.
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.
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.
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
Uygulamada sorumlulukları tanımlayın (yerel bilgiye bırakmayın):
Ek onay adımları tetikleyen politika odaklı kontroller ekleyin:
Her onay/reddetme aşağıdakileri yakalamalı:
Onayların tıkanmaması için hizmet düzeyi beklentileri belirleyin:
Yönetişim, iş akışına gömüldüğünde en iyi şekilde çalışır—sonradan zorla değil.
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.
Üst gezinmede iki ana giriş noktası sunun:
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.
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:
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.
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, 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.
Küçük, net bir rol modeliyle başlayın ve eylemlere eşleyin, sadece ekranlara değil:
İ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.
Başta hangi verilerin ekstra korunması gerektiğine karar verin:
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.
Birincil giriş yöntemini seçin:
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).
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 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?
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ı:
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.
Birden fazla aday varsa sıralı bir seçim tanımlayın, örn:
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.
Depolamayı seçin:
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.
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 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.
Yenilemeyi her sözleşme (ve opsiyonel olarak belirli ekler) için kilometre taşları seti olarak modelleyin:
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ı.
İki kanal ile başlayın:
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.
Uyarılar şunlara gitmeli:
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.
Panolar basit, filtrelenebilir ve rol-odaklı olmalı:
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.
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.
İzleyin: uçtan uca ince ama eksiksiz bir akış—çok sayıda izole özellik yerine:
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.
Hataların maliyetli olduğu yerlere odaklanın:
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.
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.
Önce iki şeyi merkezileştirin: fiyat listesi versiyonları ve sözleşme versiyonları.
Çoğu ekip için modüler monolit: tek dağıtılabilir uygulama, net ayrılmış modüller (Suppliers, Price Lists, Contracts, Approvals, Reporting).
Ağır işler için background worker’lar (importlar, belge işleme, bildirimler) ayrılmalı; mikroservislere sadece açık bir gerekçe olduğunda geçin.
Minimum seti modelleyin:
Önemli bağlantılar:
Üzerine yazmayın — versiyonlayın:
“Güncel” sorgusu: seçilen tarihte onaylı en son versiyon.
“Hoşgörülü yükleme, kaydedilen veride sıkılık” hedefini izleyin:
Ham dosyayı + eşlemeyi + doğrulama sonuçlarını denetim için saklayın.
Yaygın kurallar:
Eğer çakışmalara izin verilecekse (promosyon/istisna) sebep ve onay zorunlu olsun.
Açık, tutarlı bir yaşam döngüsü kullanın:
Hem fiyat listeleri hem sözleşme versiyonları için aynı modeli uygulayın ki kullanıcılar tek bir deseni öğrensin.
Basit bir rol modeliyle başlayın ve sunucu tarafında zorunlu kılın:
Gerektiğinde kapsam tabanlı izinler (iş birimi/bölge/tedarikçi) ekleyin; sözleşme PDF’leri ve banka bilgileri gibi hassas verileri daha sıkı koruyun.
Ana kilometre taşlarını modelleyin ve uyarıları eyleme geçirilebilir yapın:
Panoların örnek widget’ları:
Her widget filtrelenmiş bir liste görünümüne ve dışa aktarma seçeneğine bağlanmalı.
