Zbuduj aplikację webową do zarządzania cennikami dostawców i umowami

Co aplikacja powinna rozwiązać (i dla kogo)

Chaos związany z cenami i umowami dostawców zwykle wygląda podobnie: cenniki krążą w mailach jako arkusze, „final_FINAL” PDF-y leżą na współdzielonych dyskach, i nikt nie jest pewien, które warunki są aktualne. Efekt jest przewidywalny — używanie przeterminowanych cen w zamówieniach, niepotrzebne spory z dostawcami i przegapione odnowienia.

Problemy biznesowe do naprawienia

Dobra aplikacja powinna scentralizować źródło prawdy dla cenników dostawców i umów, oraz sprawić, by zmiany były śledzone end-to-end. Powinna redukować:

• Ręczne przepisywanie między arkuszami, ERP i skrzynkami mailowymi
• Błędy cenowe spowodowane przestarzałymi wersjami
• Przegapione odnowienia i terminy wypowiedzenia
• Czas spędzony na poszukiwaniu najnowszego podpisanego dokumentu lub aneksu

Dla kogo jest aplikacja

Projektuj system wokół ludzi, którzy co tydzień pracują z cenami i warunkami:

• Zakupy (Procurement): importuje cenniki, negocjuje zmiany, śledzi daty obowiązywania
• Finanse/Accounts Payable: weryfikuje ceny na fakturach, sprawdza waluty, jednostki, podatki/opłaty
• Dział prawny/Compliance: przechowuje podpisane umowy, aneksy i wymagane klauzule
• Osoby zatwierdzające (management): przeglądają i zatwierdzają zmiany cen/warunków
• Administratorzy: zarządzają użytkownikami, rolami, danymi nadrzędnymi dostawców i szablonami

Metryki sukcesu, które pokażą, że to działa

Wybierz kilka mierzalnych celów wcześnie:

• Czas publikacji aktualizacji cen (np. z 2 dni do 2 godzin)
• Wskaźnik błędów przy imporcie i liczba ręcznych poprawek na upload
• Skuteczność przypomnień o odnowieniach (np. % umów z alertami przed terminem wypowiedzenia)
• Wskaźnik rozbieżności cen (niespójności faktura/PO powiązane z ważnością ceny)

Co oznacza „gotowe”: pierwsze wydanie vs później

Dla pierwszego wydania celuj w scentralizowane rekordy dostawców, import cenników z walidacją, przechowywanie umów z kluczowymi datami, podstawowe zatwierdzanie, wyszukiwanie i ślad audytu.

Późniejsze iteracje mogą dodać głębsze integracje z ERP, biblioteki klauzul, automatyczne dopasowanie faktur, organizacje wielojednostkowe i zaawansowane dashboardy raportowe.

Wymagania i mapowanie workflow

Zanim naszkicujesz ekrany czy tabele, odwzoruj, co się faktycznie dzieje od momentu, gdy dostawca wysyła cennik, do chwili, gdy ktoś składa zamówienie z jego użyciem. To zapobiega budowaniu ogólnego „repozytorium dokumentów”, gdy potrzebujesz kontrolowanego systemu cenowego.

Mapuj obecny workflow (as-is)

Zacznij od przejścia prawdziwego przykładu z procurement, finansami i prawnym. Zarejestruj przekazania i artefakty na każdym etapie:

• Otrzymanie cennika (email, portal, arkusz, EDI) → zarejestruj datę odbioru i źródło
• Przegląd i negocjacje → zapisuj pytania, kontrpropozycje i uzgodnione zmiany
• Zatwierdzenie cen i warunków → zidentyfikuj punkty decyzyjne i wymagane podpisy
• Podpisanie i przechowanie dokumentów → powiąż warunki z obowiązującym cennikiem
• Eksploatacja i odnowienia → monitoruj wygaśnięcia, zmiany cen i wyjątki

Prosty diagram swimlane (Dostawca → Kupujący/Procurement → Prawny → Finanse → Operacje) często wystarcza.

Zidentyfikuj kluczowe decyzje i role (kto co może)

Wypisz decyzje, które zmieniają wynik biznesowy i przypisz jasnych właścicieli:

• Kto może zatwierdzić nowy cennik vs aneks do umowy?
• Kto może edytować pola cenowe (waluta, jednostki, MOQ, lead time), a kto tylko zgłasza zmiany?
• Kto może przeglądać poufne klauzule umowy (terminy płatności, klauzule odpowiedzialności), a kto powinien mieć ograniczony dostęp?

Zauważ też, gdzie zatwierdzenia zależą od progów (np. >5% wzrost wymaga akceptacji finansów), żeby zakodować te reguły później.

Zdefiniuj wymagane wyniki (co ludzie muszą osiągnąć)

Zapisz dokładne pytania, na które aplikacja musi odpowiadać od pierwszego dnia:

• „Jaka jest aktualna cena dla pozycji X od dostawcy Y, obowiązująca dziś?”
• „Które umowy wygasają w ciągu następnych 60/90 dni i kto jest właścicielem odnowienia?”
• „Gdzie mamy wyjątki: przeterminowane ceny nadal używane, brakujące MOQ, niezgodności walut?”

Te wyniki powinny napędzać pola danych, wyszukiwanie i raporty — nie odwrotnie.

Zarejestruj problemy i przypadki brzegowe wcześnie

Dane zakupowe są chaotyczne. Jawnie udokumentuj powszechne wyjątki:

• Częściowe aktualizacje (dostawca aktualizuje 20 SKU, nie cały katalog)
• Wiele walut i założenia FX
• MOQ, rozmiary opakowań, jednostki (sztuka vs skrzynka) i zaokrąglanie
• Nakładające się daty obowiązywania lub korekty z datą wsteczną

Traktuj tę listę jako kryteria akceptacji dla importu i zatwierdzeń, aby system wspierał rzeczywistość zamiast wymuszać obejścia.

Architektura wysokiego poziomu i podział modułów

Dobra architektura dla cenników i umów dostawców polega mniej na modnych wzorcach, a bardziej na redukcji kosztów koordynacji przy pozostawieniu przestrzeni na rozwój.

Podejście do budowy: zaczynaj prosto, ewoluuj celowo

Dla większości zespołów (1–6 inżynierów) najlepszym punktem startowym jest modularny monolit: jedna wdrażalna aplikacja z wyraźnie oddzielonymi modułami i granicami. Zapewnia szybszy rozwój, prostsze debugowanie i mniej elementów operacyjnych.

Przejdź do usług dopiero gdy masz jasny powód — np. duże obciążenia importu wymagające niezależnego skalowania, wiele zespołów pracujących równolegle lub wymogi izolacji. Typowa ścieżka: modularny monolit → wyodrębnij zadania importu/przetwarzania i dokumentów do workerów → opcjonalne podzielenie obciążonych domen na usługi.

Jeśli chcesz przyspieszyć pierwszy działający prototyp (ekrany, workflow i RBAC) bez długiego cyklu budowy, platforma vibe-coding taka jak Koder.ai może pomóc wygenerować bazę React + Go + PostgreSQL ze speca chatowego, a następnie szybko iterować nad importami, zatwierdzeniami i śladem audytu. Dla zespołów zakupowych oznacza to wcześniejsze walidowanie workflowów z prawdziwymi użytkownikami — zanim zaczniesz nadbudowywać funkcje.

Moduły rdzeniowe (minimum, które pozostaje zrozumiałe)

Projektuj aplikację wokół kilku stabilnych domen:

• Suppliers: profil dostawcy, kontakty, identyfikatory, status
• Catalog (Items/Materials): wewnętrzny master pozycji i mapowanie do kodów dostawcy
• Price Lists: nagłówki (dostawca, okres ważności) i pozycje (ceny, jednostki, waluty), plus historia importów
• Contracts: rekordy umów, powiązani dostawcy, objęte pozycje/kategorie, kluczowe daty i dokumenty
• Approvals & Governance: kroki przeglądu, podpisy, komentarze i historia decyzji
• Reporting: wyszukiwanie, eksporty, widoki wydatków/cen i migawki operacyjne

Niech każdy moduł odpowiada za własne reguły i dostęp do danych. Nawet w monolicie egzekwuj granice w kodzie (pakiety, nazewnictwo, jasne API między modułami).

Planuj integracje wcześnie (nawet jeśli nie budujesz ich od razu)

Integracje zmieniają przepływ danych, więc zostaw wyraźne punkty rozszerzeń:

• SSO (SAML/OIDC) do uwierzytelniania i provisioningu użytkowników
• ERP/systemy finansowe dla ID dostawców, mastera pozycji i wypychania zatwierdzonych cen
• Email/kalendarz dla przypomnień o odnowieniach i powiadomień o akceptacjach
• Podpis elektroniczny (opcjonalnie) do finalizowania aneksów i nowych umów

Wymagania niefunkcjonalne (ustaw cele przed wdrożeniem)

Zdefiniuj mierzalne oczekiwania z góry:

• Wydajność: typowe wyszukiwania w \u003c2 sekundy; importy przetwarzane asynchronicznie z widocznością postępu
• Dostępność: wyraźny cel uptime i zaplanowane okna konserwacji
• Backupy i odzyskiwanie: automatyczne kopie, ćwiczenia przywracania i retencja zgodna z polityką
• Audytowalność: niezmienny zapis zdarzeń dla importów, zatwierdzeń i zmian w umowach, z identyfikacją użytkownika i znacznikiem czasu

Model danych: encje, relacje i wersjonowanie

Czysty model danych to to, co utrzymuje aplikację zakupową wiarygodną. Gdy użytkownicy pytają: „Jaka cena była ważna 3 marca?” albo „Która umowa regulowała to zamówienie?”, baza powinna odpowiedzieć bez wątpliwości.

Kluczowe encje (minimum, na którym polegasz)

Zacznij od małego zestawu dobrze zdefiniowanych rekordów:

• Supplier: konto dostawcy (nazwa, kod dostawcy, status, domyślna waluta, warunki płatności)
• Contact: osoby u dostawcy (wiele na dostawcę)
• Item/SKU: to, co kupujesz (kod, opis, kategoria, jednostka miary)
• PriceList: lista dostarczona przez dostawcę lub uzgodniona taryfa (nazwa, daty obowiązywania, waluta, źródło pliku, status)
• PriceLine: pozycje w cenniku (pozycja, cena jednostkowa, progi/MOQ jeśli dotyczy, flagi podatkowe)
• Contract: umowa handlowa (numer kontraktu, dostawca, daty start/koniec, ustawienia odnowienia, status)
• Term: strukturalne klauzule (lead time, gwarancja, dostawa, poziomy usług) do wyszukiwania/raportów

Relacje, które wszystko łączą

Modeluj relacje tak, by odzwierciedlały pracę kupujących:

• Supplier → Contracts: jeden dostawca może mieć wiele umów
• Supplier → PriceLists: jeden dostawca może dostarczać wiele cenników w czasie
• Contract → PriceLists (opcjonalne, ale użyteczne): powiąż umowę z cennikiem(i), które reguluje
• Item/SKU → PriceLines: jedna pozycja może występować w wielu price lines (u różnych dostawców, walutach, datach)

Jeśli wspierasz wiele lokalizacji dostawy lub jednostek biznesowych, rozważ dodanie koncepcji Scope (np. firma, site, region) przypisywanej do umów i cenników.

Wersjonowanie: nie nadpisuj historii

Unikaj edytowania „live” rekordów w miejscu. Zamiast tego:

• Wersjonowanie cenników: każdy import tworzy nową wersję PriceList (lub nowy rekord PriceList z wspólnym identyfikatorem rodziny). Poprzednie wersje zachowaj jako tylko do odczytu.
• Aneksy umów: zapisuj każdy aneks jako nową wersję z własną datą obowiązywania. Widok „aktualny” to po prostu najnowsza zatwierdzona wersja.

To ułatwia pytania audytowe: możesz odtworzyć, co i kiedy zostało zatwierdzone oraz co się zmieniło.

Dane referencyjne i reguły unikalności

Trzymaj dane referencyjne w dedykowanych tabelach, by uniknąć bałaganu w polach tekstowych:

• Currency, Unit of Measure, Tax Code, i (jeśli wysyłasz międzynarodowo) Incoterms

Wymuszaj identyfikatory, by zapobiec cichym duplikatom:

• Kod dostawcy unikalny w systemie
• Kod pozycji unikalny (albo unikalny per katalog/źródło)
• Numer kontraktu unikalny per dostawca (lub globalnie — wybierz i egzekwuj konsekwentnie)

Import cenników: szablony, walidacja i obsługa błędów

Cenniki zwykle przychodzą w arkuszach, które nie były tworzone pod maszyny. Płynny flow importu to różnica między „użyjemy aplikacji” a „dalej wysyłamy Excel e-mailem”. Celem: robić uploady wyrozumiałymi, ale zapisywać dane surowo.

Obsługiwane formaty i pobieralny szablon

Obsługuj CSV i XLSX od dnia 1. CSV jest świetne do eksportów z ERP i narzędzi BI; XLSX to format, który dostawcy najczęściej wysyłają.

Daj pobieralny szablon, który odzwierciedla model danych (zmniejsza zgadywanie). Zawierać powinien:

• Pierwszy wiersz z dokładnymi nazwami kolumn
• Przykładowy wiersz pokazujący poprawne wartości (waluta, jednostka, data)
• Opcjonalny arkusz „notes” (dla XLSX) wyjaśniający każdą kolumnę

Wersjonuj szablon (np. Template v1, v2), aby go rozwijać bez łamania procesów.

Reguły mapowania: wymagane vs opcjonalne kolumny

Zdefiniuj reguły mapowania jawnie i pokaż je w UI podczas uploadu.

Popularne podejście:

• Wymagane kolumny: identyfikator dostawcy, item/SKU, cena, waluta, jednostka miary, data rozpoczęcia obowiązywania
• Opcjonalne: data zakończenia, minimalna ilość zamówienia, lead time, opakowanie, incoterms, komentarze
• Wartości domyślne (dla dostawcy lub uploadu): waluta, jednostka, data startu = „dziś”, data końca pusta

Jeśli pozwalasz na kolumny niestandardowe, traktuj je jako metadata i przechowuj oddzielnie, aby nie zaśmiecały schematu cenowego.

Reguły walidacji, które zapobiegają złym danym

Uruchamiaj walidacje zanim cokolwiek zostanie zatwierdzone:

• Formaty numeryczne: odrzucaj nie-numeryczne komórki z ceną; normalizuj separatry tysięcy; egzekwuj nieujemne ceny
• Kody walut: waliduj względem ISO 4217 (np. USD, EUR)
• Zakresy dat: data rozpoczęcia wymagana; data zakończenia po dacie rozpoczęcia; zapobiegaj nakładaniu się zakresów dla tej samej pozycji, jeśli reguły tego wymagają
• Duplikaty wierszy: wykrywaj identyczne klucze (np. supplier + SKU + start date + currency + unit). Zdecyduj, czy duplikaty są błędem czy „ostatni wygrywa” (błąd jest bezpieczniejszy)

Rób walidacje zarówno na poziomie wiersza (ten wiersz jest zły), jak i na poziomie pliku (upload koliduje z istniejącymi rekordami).

Obsługa błędów: podgląd, komunikaty per wiersz i ponowny upload

Dobre doświadczenie importu wygląda tak: Upload → Podgląd → Popraw → Potwierdź.

Na ekranie podglądu:

• Pokaż tabelę z wyróżnionymi komórkami i jasnymi komunikatami (np. „Nieprawidłowy kod waluty: US$”)
• Pozwól pobrać raport błędów (CSV) z dodatkową kolumną „error”
• Zapewnij flow fix-and-reupload, które zachowuje wybory mapowania z ostatniej próby

Unikaj „odrzucenia całego pliku przez jeden błędny wiersz”. Zamiast tego pozwól użytkownikowi wybrać: importuj tylko poprawne wiersze albo zablokuj aż wszystkie błędy będą naprawione, w zależności od governance.

Przechowuj surowe uploady dla śladu

Dla audytowalności i łatwego przetwarzania zapisz:

• Oryginalny surowy plik (dokładne bajty), z sumą kontrolną i tożsamością uploader'a
• Parsowane wiersze i wyniki walidacji (w tym błędy)
• Konfigurację importu (wersja szablonu, mapowanie kolumn, wartości domyślne)

To daje obronny ślad w sporach („co i kiedy zaimportowaliśmy?”) i umożliwia ponowne przetworzenie, gdy reguły walidacji się zmienią.

Rekordy umów: warunki, dokumenty i aneksy

Rekord umowy powinien być czymś więcej niż segregatorem plików. Potrzebuje wystarczająco dużo ustrukturyzowanych danych, by napędzać odnowienia, zatwierdzenia i raporty — a jednocześnie ułatwiać znajdowanie podpisanych dokumentów.

Podstawowe warunki umowy (pola strukturalne)

Zacznij od pól odpowiadających na często zadawane pytania:

• Data rozpoczęcia i zakończenia umowy
• Typ odnowienia (auto-renew, fixed term, evergreen) i długość odnowienia
• Okres wypowiedzenia (np. „60 dni przed końcem”) i kto musi być powiadomiony
• Warunki płatności (Net 30/45/60, rabat za wcześniejszą płatność) i zasady fakturowania
• Właściciel umowy, kontakt u dostawcy i interesariusze wewnętrzni

Trzymaj notatki jako tekst wolny dla przypadków brzegowych, ale normalizuj wszystko, co będziesz filtrować, grupować lub na co będziesz wysyłać alerty.

Dokumenty, załączniki i retencja

Traktuj dokumenty jako element pierwszej klasy powiązany z umową:

• Podpisana umowa (PDF)
• Aneksy/dodatki
• Zakresy prac, taryfy, certyfikaty ubezpieczeniowe, dokumenty zgodności

Przechowuj metadane dla każdego pliku: typ dokumentu, data obowiązywania, wersja, uploader i poziom poufności. Jeśli organizacja ma wymagania retencyjne, dodaj pola typu „retention until” i „legal hold”, by aplikacja mogła zabronić usunięcia i wspierać audyty.

Aneksy i śledzenie klauzul

Aneksy nie powinny nadpisywać historii. Modeluj je jako datowane zmiany, które albo wydłużają warunki (nowa data końcowa), albo korygują warunki komercyjne, albo zmieniają zakres.

Gdzie to możliwe, przechowuj kluczowe klauzule jako dane strukturalne dla alertów i raportów — przykłady: możliwość wypowiedzenia bez powodu (Y/N), formuła indeksacji, kary serwisowe, limit odpowiedzialności, wyłączność.

Jedna umowa, wielu dostawców lub lokalizacji

Jeśli kupujesz centralnie, ale działasz w wielu lokalizacjach, wspieraj powiązanie jednej umowy z wieloma site/units, z opcjonalnymi nadpisaniami na poziomie site (np. adres rozliczeń, warunki dostawy). Podobnie pozwól jednej umowie dotyczyć podmiotu nadrzędnego i jego spółek zależnych, zachowując jasne pole „strona kontraktowa” dla zgodności.

Workflow akceptacji i governance

Akceptacje to moment, w którym cenniki i umowy stają się obronne. Jasny workflow redukuje pytania „kto to zatwierdził?” i tworzy powtarzalną ścieżkę od zgłoszenia dostawcy do używalnych, zgodnych danych.

Przepływ statusów (utrzymuj go jawnie)

Użyj prostego, widocznego lifecycle dla cenników i rekordów umów:

Draft → Review → Approved → Active → Expired/Terminated

• Draft: edytowalny przez zgłaszającego; nieużywany do zamówień.
• Review: zablokowany do edycji poza żądanymi zmianami; recenzenci weryfikują kompletność i zgodność z polityką.
• Approved: decyzja zarejestrowana; gotowe do aktywacji według reguł daty.
• Active: obowiązuje przy zamawianiu; zmiany wymagają nowej rewizji i zatwierdzenia.
• Expired/Terminated: tylko do odczytu; przechowywane dla raportów i audytu.

Role i odpowiedzialności

Zdefiniuj obowiązki w aplikacji (nie w wiedzy plemiennej):

• Submitter (Procurement/Manager): przesyła cenniki, przygotowuje warunki, odpowiada na komentarze recenzentów
• Reviewer (Category/Finance): sprawdza ceny, jednostki, waluty i zgodność komercyjną
• Approver (Właściciel budżetu): ostateczna decyzja dla wpływu komercyjnego
• Legal: wymagany recenzent/akceptujący dla języka umów i dokumentów
• Admin: konfiguruje progi, reguły trasowania i zarządza uprawnieniami — domyślnie nie powinien zatwierdzać treści biznesowych

Reguły dla zmian cen (zapobiegaj cichej erozji kosztów)

Dodaj polityki, które automatycznie wywołują dodatkowe kroki akceptacji:

• Zatwierdzenia progowe: np. jeśli dowolna pozycja wzrośnie >5% albo całkowity wpływ na kategorię przekracza $10,000, skieruj do wyższego approvera
• Trasowanie według kategorii: strategiczne kategorie (IT, logistyka) mogą zawsze wymagać prawnego + właściciela budżetu
• Obsługa wyjątków: pozwól na override tylko z obowiązkowym powodem i załącznikiem

Decyzje gotowe do audytu: komentarze, powody i dowody

Każde zatwierdzenie lub odrzucenie powinno rejestrować:

• decyzję (zatwierdź/odrzuć/zaproś do zmian)
• kod powodu + pole tekstowe
• znacznik czasu, aktora i dotkniętą rewizję
• powiązane dowody (PDF z maila, pismo od dostawcy, notatki ze spotkania)

Eskalacja, timeouty i rozliczalność

Ustaw SLA, aby zatwierdzenia się nie blokowały:

• automatyczne przypomnienia po 24/48 godzinach
• eskalacja do zastępczego approvera po określonym czasie
• widoczność przez „Moje oczekujące zatwierdzenia” i raport zaległych

Governance działa najlepiej, gdy jest zbudowane w workflow, a nie egzekwowane po fakcie.

UX: ekrany, wyszukiwanie i raportowanie

Aplikacja zakupowa odnosi sukces lub porażkę w tym, jak szybko ludzie uzyskają proste odpowiedzi: „Jaka jest aktualna cena?”, „Która umowa reguluje ten przedmiot?” i „Co się zmieniło od zeszłego kwartału?” Projektuj UI wokół tych workflowów, nie tabel bazy danych.

Szybkie znajdowanie informacji: wyszukiwanie i filtry

Daj dwa główne punkty wejścia w górnej nawigacji:

• Wyszukiwanie dostawców (nazwa, NIP/kod dostawcy, status, kategoria)
• Wyszukiwanie pozycji (SKU/nr katalogowy, opis, producent, jednostka)

Na stronach wyników stosuj filtry pasujące do codziennej pracy: data obowiązywania, status umowy (draft/active/expired), jednostka biznesowa, waluta i „ma oczekujące akceptacje”. Trzymaj filtry widoczne i możliwe do usunięcia jako chipy, by nietechniczni użytkownicy się nie gubili.

Kluczowe ekrany do zaprojektowania najpierw

Profil dostawcy powinien być hubem: aktywne umowy, najnowszy cennik, otwarte spory/notatki i panel „ostatnia aktywność”.

Widok umowy powinien odpowiadać „Co możemy kupować, na jakich warunkach i do kiedy?” Pokaż kluczowe warunki (incoterms, warunki płatności), załączone dokumenty i oś czasu aneksów.

Porównanie cenników to miejsce, gdzie użytkownicy spędzają czas. Pokaż aktualne vs poprzednie obok siebie z:

• Datami obowiązywania (i „ceny przyszłe”)
• Zmianami per pozycja (wartościowo i procentowo)
• Wyróżnieniami nowych/usuniętych pozycji

Raporty i eksporty

Raporty powinny być użyteczne, nie dekoracyjne: „wygasa za 60 dni”, „największe wzrosty cen”, „pozycje z wieloma aktywnymi cenami”. Oferuj eksport do CSV dla finansów i PDF do udostępniania/akceptacji, z tymi samymi filtrami, aby eksport odpowiadał widokowi użytkownika.

Utrzymuj prostotę i samowyjaśnialność

Używaj jasnych etykiet („Data obowiązywania”, nie „Validity start”), inline help przy trudnych polach (jednostki, waluta) i stanów pustych, które wyjaśniają kolejne kroki („Załaduj cennik, aby zacząć śledzić zmiany”). Krótka lista onboardingu na /help zmniejszy czas szkolenia.

Bezpieczeństwo, uprawnienia i ślad audytu

Bezpieczeństwo łatwiej zaprojektować w workflowie niż dorabiać później. Cel prosty: ludzie widzą i zmieniają tylko to, za co są odpowiedzialni, a każda istotna zmiana jest śledzona.

Role i uprawnienia (zasada najmniejszych przywilejów)

Zacznij od małego, jasnego modelu ról i mapuj go do akcji, nie tylko ekranów:

• Viewer: dostęp tylko do odczytu do zatwierdzonych cenników i aktywnych umów
• Editor: tworzy szkice, przesyła dokumenty, przygotowuje importy, naprawia błędy walidacji
• Approver: zatwierdza/odrzuca szkice, blokuje daty obowiązywania, podpisuje aneksy
• Admin: zarządza użytkownikami, rolami, danymi referencyjnymi i ustawieniami systemowymi

Uprawnienia trzeba egzekwować po stronie serwera dla każdego endpointu (UI alone nie wystarczy). Jeśli organizacja jest złożona, dodaj reguły scope (np. per dostawca, jednostkę lub region).

Obsługa danych wrażliwych

Zdecyduj wcześnie, co wymaga dodatkowej ochrony:

• Pliki umów (PDFy, skany): szyfruj w spoczynku, ogranicz pobieranie i opcjonalnie dodawaj watermark
• Dane bankowe: przechowuj w oddzielnym, silniej chronionym obszarze; ogranicz widoczność do wąskiej roli finansów
• Widoczność cen: rozważ ukrywanie marż lub specjalnych cen przed szerokim audytorium; wspieraj widoki „wewnętrzne vs dla dostawcy”, jeśli potrzeba

Ślad audytu: kto zmienił co i jak

Zbieraj niezmienny log audytu dla kluczowych encji (umowy, warunki, pozycje cenowe, zatwierdzenia): kto, co się zmieniło (przed/po), kiedy i źródło (UI/import/API). Rejestruj nazwę pliku importu i numer wiersza, aby można było precyzyjnie śledzić i korygować błędy.

Uwierzytelnianie i sesje

Wybierz jedną główną metodę logowania:

• SSO (SAML/OIDC) dla użytkowników korporacyjnych, lub hasło + MFA dla mniejszych zespołów

Dodaj rozsądne polityki sesji: krótkotrwałe tokeny dostępu, bezpieczne ciasteczka, timeouty nieaktywności i wymuszanie ponownej weryfikacji dla wrażliwych akcji (np. eksport cen).

Podstawy zgodności (bez obiecywania niemożliwego)

Celuj w praktyczne kontrole: najmniejsze przywileje, scentralizowane logowanie, regularne backupy i testy przywracania. Traktuj logi audytu jak zapisy biznesowe — ogranicz ich usuwanie i zdefiniuj politykę retencji.

Reguły cenowe: daty obowiązywania, waluty i jednostki

Cena rzadko bywa „jedną liczbą”. Aplikacja potrzebuje jasnych reguł, by kupujący, AP i dostawcy uzyskali tę samą odpowiedź na pytanie: jaka jest cena dziś dla tej pozycji?

Datowanie obowiązywania (start/end, ceny przyszłe, nakładania)

Przechowuj ceny jako rekordy z ograniczeniem czasowym z datą rozpoczęcia i opcjonalną datą zakończenia. Pozwól na wiersze z datą przyszłą (np. podwyżki od następnego kwartału) i zdefiniuj, co oznacza „bez daty końcowej” (zazwyczaj: ważne do zastąpienia).

Nakładania obsługuj świadomie:

• Odrzucaj nakładania domyślnie przy imporcie (najlepsze dla governance)
• Pozwalaj z precedencją gdy potrzeba (np. ceny promocyjne), ale wymagaj powodu i akceptacji

Praktyczna reguła: jedna aktywna cena bazowa na supplier-item-currency-unit w danym momencie; wszystko inne musi być jawnie oznaczone jako override.

Definiowanie „aktualnej ceny”

Gdy istnieje kilka kandydatów, zdefiniuj uporządkowany wybór, np.:

1. Cena pokrywana przez umowę (jeśli umowa jest aktywna i pozycja jest w zakresie)
2. Zatwierdzony override (promocja/wyjątek) w obrębie dat
3. Standardowy cennik dostawcy w obrębie dat
4. Fallback lub stan „brak ceny” (wymaga akcji użytkownika)

Jeśli masz preferowanych dostawców, dodaj pole priorytet dostawcy używane tylko, gdy istnieje wiele ważnych dostawców dla tej samej pozycji.

Strategia wielowalutowa

Wybierz, czy przechowywać:

• Zapisany kurs FX per rekord ceny (najlepsze dla audytowalności; odtwarza historyczne decyzje)
• Konwersję na żywo (użyteczne do dashboardów; ciągle przechowuj oryginalną walutę)

Wiele zespołów robi oba: trzyma cenę w walucie dostawcy plus „as-of” wartość przeliczoną do raportów.

Zaokrąglanie i konwersje jednostek

Zdefiniuj normalizację jednostek (np. sztuka vs karton vs kg) i trzymaj współczynniki konwersji wersjonowane. Stosuj reguły zaokrąglania konsekwentnie (liczba miejsc po przecinku waluty, minimalne kroki cenowe) i jasno określ, kiedy następuje zaokrąglenie: po konwersji jednostek, po konwersji FX i/lub przy ostatecznym rachunku linii.

Odnowienia, alerty i pulpity operacyjne

Odnowienia to miejsce, gdzie wartość umowy jest wygrywana lub przegrywana: przegapione terminy, ciche automatyczne odnowienia i negocjacje na ostatnią chwilę często prowadzą do niekorzystnych warunków. Twoja aplikacja powinna traktować odnowienia jak proces zarządzalny z jasnymi datami, odpowiedzialnymi właścicielami i widocznymi kolejkami operacyjnymi.

Oś czasu odnowienia i przypomnienia

Modeluj odnowienie jako zestaw kamieni milowych powiązanych z każdą umową (oraz opcjonalnie z konkretnymi aneksami):

• Data końcowa (expiration)
• Termin wypowiedzenia (najpóźniejsza data na anulowanie/renegocjację)
• Start okna odnowieniowego (kiedy powinno się zacząć sourcing)

Buduj przypomnienia wokół tych kamieni. Praktyczny domyślny schemat to kadencja 90/60/30 dni przed kluczowym terminem (termin wypowiedzenia zwykle najważniejszy), plus alert w dniu.

Kanały powiadomień i dostawa

Zacznij od dwóch kanałów:

• Powiadomienia w aplikacji dla codziennych kolejek roboczych
• Email dla pilnych przypomnień

Opcjonalnie wspieraj eksport pliku ICS (per umowa lub per użytkownik), aby właściciele mogli subskrybować w Outlook/Google Calendar.

Rób powiadomienia akcyjnymi: zawieraj nazwę umowy, dostawcę, dokładny termin i głębokie odwołanie do rekordu.

Właścicielstwo i eskalacja

Alerty kieruj do:

• Właściciela umowy (pierwszorzędny)
• Właściciela kategorii (wtórny, jeśli inny)
• Backup owner (dla pokrycia)

Dodaj reguły eskalacji: jeśli primary nie potwierdzi w X dni, powiadom backup lub managera. Rejestruj czas „acknowledged”, żeby alerty nie stały się szumem.

Pulpity operacyjne, które napędzają pracę

Dashboardy powinny być proste, filtrowalne i zależne od roli:

• Umowy wygasające wkrótce (30/60/90 dni, inkl. terminów wypowiedzenia)
• Umowy z zaległymi zadaniami odnowieniowymi (niepotwierdzone lub przeterminowane)
• Cenniki oczekujące na akceptację (wiek, właściciel, dostawca)

Każdy widget powinien linkować do ukierunkowanej listy z wyszukiwaniem i eksportem, aby dashboard był punktem startu do działania — nie tylko raportowania.

Plan MVP, testy i lista kontrolna wdrożenia

MVP dla cenników i umów powinno udowodnić jedną rzecz: zespoły mogą bezpiecznie załadować ceny, szybko znaleźć właściwą umowę i ufać zatwierdzeniom oraz śladowi audytu.

Zakres MVP (must-haves)

Zacznij od cienkiego, end-to-end workflow zamiast wielu cech izolowanych:

• Podstawy Supplier + item master: dostawcy, produkty/usługi, jednostki, waluty
• Import cenników: jeden lub dwa szablony (CSV/XLSX), podgląd, mapowanie pól (jeśli potrzeba), walidacja i jasny raport błędów
• Rekord umowy: kluczowe daty (start/koniec, okres wypowiedzenia, typ odnowienia), załączniki i powiązanie z dostawcą oraz wersjami cenników
• Akceptacje: prosty workflow (Draft → Review → Approved) z RBAC i logiem audytu
• Wyszukiwanie + raportowanie: globalne wyszukiwanie (dostawca, SKU, ID umowy) i jeden eksport „aktualnych zatwierdzonych cen”

Jeśli chcesz iść szybko z małym zespołem, rozważ użycie Koder.ai do wygenerowania szkieletonu produktu (frontend React, backend Go, PostgreSQL) i iterowania w trybie planowania z zakupami/prawnym. Weryfikujesz workflow (importy → zatwierdzenia → ślad audytu → alerty o odnowieniach), a potem eksportujesz kod źródłowy, kiedy będziesz gotów go umocnić.

Plan testów (co psuje się w realnym świecie)

Skup testy tam, gdzie błędy są kosztowne:

• Testy walidacji importu: brak wymaganych kolumn, nieprawidłowe waluty/jednostki, duplikaty wierszy, nakładania dat, ceny ujemne, mieszane separatory dziesiętne
• Testy uprawnień: kto może importować, zatwierdzać, edytować po zatwierdzeniu i przeglądać wrażliwe załączniki
• Testy workflow: ponowna akceptacja po edycji, wymagane komentarze przy odrzuceniu, zapisy audytu tworzone przy każdej zmianie stanu

Wdrożenie i deployment

Użyj środowiska staging z danymi zbliżonymi do produkcji (sanityzowanymi). Wymagaj checklisty: włączone backupy, przetestowane skrypty migracji i plan rollbacku (wersjonowane migracje DB + możliwość przywrócenia deployu).

Dodaj monitoring dla błędów importu, wolnych zapytań wyszukiwania i wąskich gardeł w akceptacjach.

Iteruj po uruchomieniu

Przeprowadzaj 2–4‑tygodniowy cykl feedbacku z procurement i finansami: najczęstsze błędy importu, brakujące pola w umowach i wolne ekrany. Kolejne kandydatury: integracje ERP, portal dla dostawców, analityka oszczędności i zgodności.

Suggested internal reads: /pricing and /blog.