Użyj tego wzorca aplikacji zgłoszeń zakupowych do zaprojektowania zatwierdzeń, kontroli budżetu, zamówień zakupowych i komunikacji z dostawcami z jasnymi rolami i statusami.
Wątki mailowe i arkusze kalkulacyjne zawodzą w przewidywalny sposób. Zgłoszenia się gubią. Pliki rozrastają się do wersji „final_v7”. Zatwierdzenia odbywają się w bocznych czatach bez śladu. Gdy ktoś pyta „Czy możemy to kupić?”, odpowiedź zależy od tego, kto jest online i któremu arkuszowi ufają.
Aplikacja zgłoszeń powinna na każdym kroku jasno pokazywać status. Po otwarciu zgłoszenia trzeba od razu widzieć, kto je złożył, co chce kupić, oczekiwany koszt i co stanie się dalej. Potrzebna jest też przejrzysta historia: kto zatwierdził lub odrzucił, kiedy to zrobił i co zmieniło się później.
Przynajmniej każde zgłoszenie powinno odpowiadać na poniższe pytania bez grzebania w szczegółach:
Zakres to miejsce, w którym wiele zespołów przesadza. Zdecyduj wcześnie, czy obejmujesz tylko proces od zgłoszenia do zamówienia, czy też dalsze kroki, jak rozliczenie faktur i przyjęcie towaru. Zgłoszenie do PO to zwykle najlepszy pierwszy kamień milowy: wymusza czyste zatwierdzenia i kontrole budżetu, ale trzyma projekt w granicach.
Zachowaj pierwszą wersję prostą. Zacznij od jednego zespołu, jednej ścieżki zatwierdzeń i jasnej definicji „ukończone”. Na przykład zgłoszenia IT poniżej 1 000 USD mogą wymagać tylko zatwierdzenia menedżera, a większe zakupy kierować do finansów.
Jeśli chcesz zbudować to szybko bez pisania kodu, AppMaster jest praktyczną opcją. Możesz zamodelować dane zgłoszeń, skonfigurować kroki zatwierdzeń i wygenerować gotową aplikację webową i mobilną z tego samego wzorca.
Aplikacja zgłoszeń zakupowych żyje lub umiera dzięki uprawnieniom. Jeśli nieodpowiednia osoba może zmienić zgłoszenie po zatwierdzeniu, albo zespoły nie widzą potrzebnych informacji, proces staje się powolny i ryzykowny.
Zacznij od jasnego nazwania ról. Nazwy różnią się w firmach, ale większość aplikacji potrzebuje stabilnych odpowiedzialności: zgłaszający (tworzą zgłoszenia i odpowiadają na pytania), menedżerowie (potwierdzają potrzebę i termin), procurement (weryfikuje dostawców i tworzy PO), finanse (potwierdzają budżet i zgodność z polityką) oraz jeden lub więcej zatwierdzających (mają uprawnienia do podpisu). Niektóre procesy zawierają też kontakt do dostawcy z ograniczonym dostępem do danych zewnętrznych.
Następnie zdefiniuj, co każda rola może robić na danym etapie. Jedna reguła zapobiega wielu sporom: po przesłaniu zgłoszenia zgłaszający może edytować tylko wyjaśnienia (notatki, załączniki, szczegóły dostawy). Cena, dostawca, ilość, waluta i centrum kosztów powinny być traktowane jako pola „twarde”, których zmiana wymaga formalnej modyfikacji i ponownego zatwierdzenia.
Reguły widoczności powinny być równie jasne. Zgłaszający powinni widzieć własne zgłoszenia i ich status. Menedżerowie powinni widzieć zgłoszenia swoich bezpośrednich raportów. Procurement i finanse zwykle potrzebują widoczności międzydziałowej. Kontakty do dostawców nigdy nie powinny widzieć notatek wewnętrznych, danych o budżecie ani informacji o innych dostawcach.
Delegowanie ma znaczenie, bo zatwierdzeń nie można wstrzymywać, gdy ktoś jest nieobecny. Wspieraj planowane delegacje (urlop) i awaryjne zastępstwo (choroba). Delegacja powinna przekazywać prawa zatwierdzania, ale nie możliwość przepisania zgłoszenia.
Wspólne zgłoszenia między działami są częste (np. IT kupuje software dla Marketingu). Oddziel „zespół zgłaszający” od „właściciela centrum kosztów”. Kieruj zatwierdzenia do właściciela centrum kosztów i pokaż obie strony w rekordzie, żeby było jasne, kto zamówił, a kto płaci.
W AppMaster możesz zamodelować role, własność rekordów i akcje zależne od etapu w modelu danych i procesach biznesowych, dzięki czemu te same reguły będą obowiązywać na ekranach webowych i mobilnych.
Dobra aplikacja zgłoszeń zakupowych zaczyna się od przejrzystego modelu danych. Jeśli tabele są czytelne, zatwierdzenia, kontrole budżetu i zamówienia zakupowe łatwiej zautomatyzować i raportować.
Większość zespołów obsłuży większość przypadków niewielkim zestawem encji:
Dla Requests dodaj pola, które pomagają w routingu i redukują dopytywania: zgłaszający, dział, centrum kosztów, data potrzebna, uzasadnienie biznesowe i załączniki (oferty, specyfikacje, zrzuty ekranu). Proste odniesienie do preferowanego dostawcy pomaga, nawet jeśli wybór dostawcy potwierdzony będzie później.
Statusy działają najlepiej, gdy są eksplicytne i podparte znacznikami czasu. Trzymaj jedno pole statusu w Requests (Draft, Submitted, Approved, Rejected, Ordered, Closed) i zapisuj kluczowe daty jak submitted_at, approved_at, rejected_at, ordered_at i closed_at. Ułatwia to raportowanie (czas cyklu, przeterminowania, wąskie gardła) bez zgadywania z logów.
Dla PurchaseOrders oddziel nagłówek PO (numer, dostawca, ship-to, bill-to, warunki płatności) od linii PO i połącz je z oryginalnym zgłoszeniem i pozycjami. To śledzenie ma znaczenie, gdy ceny się zmieniają.
Zatwierdzenia to twój ślad audytu, ale zwykle potrzebujesz więcej niż „zatwierdzono/odrzucono”. Zapisuj kto działał, kiedy, jaką podjął decyzję i dlaczego.
Lekka metoda to tabela Activity/Audit, która zapisuje actor_user_id, entity_type, entity_id, action, old_value, new_value i created_at. W AppMaster mapuje się to czysto w Data Designer i można wypełniać automatycznie z procesów biznesowych, dzięki czemu każda zmiana jest śledzona.
Aplikacja zadziała tylko wtedy, gdy wszyscy używają tych samych danych o dostawcach. Traktuj tabelę dostawców jako jedyne źródło prawdy, a nie pole, które ludzie przepisywać będą w każdym zgłoszeniu. Gdy dane dostawcy są w jednym miejscu, zatwierdzenia idą szybciej, a finanse widzą mniej niespodzianek.
Zacznij od rekordu dostawcy zawierającego podstawy, których używasz: nazwa prawna, nazwa wyświetlana, NIP (jeśli używasz), domyślna waluta, adres do faktury i warunki płatności. Przechowuj główny e-mail działu AP i pozwól na wielu kontaktów, żeby używać właściwej osoby do ofert vs faktur.
Dodaj status dostawcy, aby aplikacja mogła konsekwentnie blokować ryzykowne zakupy: Active (może być wybrany), Pending review (dozwolony, ale kierowany do dodatkowej weryfikacji) i Blocked (nie można użyć bez przeglądu).
Śledzenie komunikacji zapobiega pytaniu „kto ostatnio do nich pisał?”. Stwórz encję Communication (lub VendorInteraction) powiązaną z Vendor i, jeśli to możliwe, z konkretnym Request, Quote lub Purchase Order. Każdy rekord powinien zawierać kanał (email, telefon, spotkanie), kierunek (outbound/inbound), znacznik czasu, właściciela i krótkie podsumowanie. Jeśli zbierasz oferty, przechowuj je jako strukturalne rekordy (kwota, waluta, data ważności) i dołącz pliki, gdy potrzeba.
Kilka reguł zwykle utrzymuje dane dostawców w czystości bez spowalniania procesu:
Jeśli budujesz to w AppMaster, możesz zamodelować Vendor, VendorContact i VendorCommunication w Data Designer i wyświetlić oś czasu na ekranie zgłoszenia i PO, tak aby pełna historia była dostępna jednym kliknięciem.
Kontrola budżetu odpowiada na proste pytanie: czy mamy wystarczające zatwierdzone środki na to zgłoszenie teraz? Zdecyduj wcześnie, czy firma traktuje budżet jako twardą blokadę (nie można iść dalej) czy ostrzeżenie (można kontynuować, ale potrzebne jest dodatkowe zatwierdzenie). Ta jedna decyzja zmienia całe doświadczenie zgłaszających i zatwierdzających.
Budżet może pochodzić z różnych źródeł, więc wyraźnie określ źródło. Typowe opcje to roczny budżet działu, budżet projektu lub miesięczny limit dla centrum kosztów. Jeśli zgłoszenie może być rozdzielone między źródła, zapisz kwoty podzielone według źródła, aby raportowanie pozostało czyste.
Aby uniknąć niespodzianek, oblicz oczekiwany wydatek tak samo, jak zrobi to później dział finansów. Aplikacja zgłoszeń jest użyteczna tylko wtedy, gdy wszyscy widzą tę samą liczbę przed zatwierdzeniem.
Prosta lista kontrolna obliczeń, którą większość zespołów stosuje, obejmuje sumę pozycji (ilość x cena jednostkowa), rabaty, podatek, koszty wysyłki i obsługi oraz konwersję walut (zapisz kurs i datę kursu). Następnie porównaj oczekiwany wydatek z dostępnym budżetem (budżet minus już zarezerwowane kwoty). Jeśli śledzisz rezerwacje, uwzględnij oczekujące zgłoszenia i otwarte PO, a nie tylko opłacone faktury.
Gdy budżet jest niewystarczający, nie zmuszaj zgłaszającego do zgadywania. Wybierz jedną ścieżkę i zakoduj ją w workflow: skieruj do właściciela budżetu, pozwól na jednorazowe obejście z zatwierdzeniem finansów, zwróć zgłoszenie z zadaniem „szczegóły budżetu” albo automatycznie odrzuć kategorie, które zawsze wymagają budżetu.
Przykład: zespół prosi o nowy pakiet laptopa. Aplikacja oblicza koszt pozycji plus podatek i wysyłkę, przelicza na walutę działu i sygnalizuje, że dostępne jest tylko 900 USD wobec żądanych 1 150 USD. Jeśli traktujesz to jako ostrzeżenie, może nadal pójść do menedżera, ale zatwierdzenie finansowe staje się obowiązkowe.
W AppMaster możesz zamodelować źródła budżetu w Data Designer i uruchomić kontrolę jako krok w Business Process przed pierwszą decyzją zatwierdzającą.
Zatwierdzenia to miejsce, gdzie aplikacja albo oszczędza czas, albo zamienia się w powolny przekaźnik skrzynek odbiorczych. Utrzymaj domyślną ścieżkę prostą, a dodawaj reguły tylko tam, gdzie zapobiegają realnemu ryzyku.
Zacznij od zdefiniowania, co każde zatwierdzenie chroni. Typowy zestaw to zatwierdzenie menedżera (potrzeba i priorytet), zatwierdzenie finansów (budżet i księgowość) i zatwierdzenie procurement (dostawca i metoda zakupu). Dodaj bezpieczeństwo i zgodność tylko wtedy, gdy konkretne kategorie lub dostawcy tego wymagają.
Reguły routingu powinny być przewidywalne. Ludzie powinni móc zgadnąć, co stanie się dalej, zanim klikną Submit. Typowe czynniki routingu to progi kwotowe, routing według kategorii (software do security, kontrakty do legal), poziom ryzyka dostawcy, zasady działu lub centrum kosztów oraz rodzaj zakupu (CapEx vs OpEx, subskrypcja vs jednorazowy zakup).
Używaj sekwencyjnych zatwierdzeń, gdy kolejność ma znaczenie. Na przykład finanse mogą zablokować zgłoszenie brakujące centrum kosztów, więc lepiej wychwycić to wcześniej niż angażować procurement. Używaj zatwierdzeń równoległych, gdy zespoły mogą przeglądać niezależnie, np. security i legal sprawdzające standardowy zakup SaaS, podczas gdy finanse kontrolują budżet.
Zaplanuj czystą pętlę korekcyjną. Gdy zatwierdzający odsyła zgłoszenie do poprawy, zgłaszający powinien dodać brakujące informacje i ponownie wysłać bez utraty historii. Trzymaj dziennik zatwierdzeń ze znacznikami czasu, komentarzami i wersją kluczowych pól takich jak kwota, dostawca i kategoria.
Przykład: SaaS za 12 000 USD kieruje się najpierw do menedżera i finansów. Po obu zatwierdzeniach security i procurement działają równolegle. Jeśli security zgłosi brakujące informacje o przetwarzaniu danych, zgłoszenie wraca do zgłaszającego, a po poprawce wraca do tego samego kroku z zachowanym śladem audytu.
Jeśli budujesz to w AppMaster, zamodeluj stany workflow i przejścia w Business Process, aby routing był widoczny i łatwy do dopasowania wraz z ewolucją polityki.
Dobry przepływ utrzymuje ruch zgłoszeń bez rozmywania szczegółów. Zbierz wystarczająco informacji na początku, potem zamroź to, co ważne, gdy zaczynają się przeglądy.
Praktyczna sekwencja dla większości zespołów wygląda tak:
Przykład: zespół wsparcia prosi o 10 nowych słuchawek. Załączają ofertę, wybierają kategorię IT Supplies i wysyłają zgłoszenie. Aplikacja sprawdza budżet IT, kieruje do kierownika zespołu (poniżej 1 000 USD) i potem do finansów (powyżej 500 USD). Po zatwierdzeniu PO jest generowane i wysyłane, a kupujący loguje potwierdzenie i datę dostawy.
W narzędziu no-code takim jak AppMaster zwykle przekłada się to na kilka ekranów (Draft, Review, PO) oraz Business Process, który blokuje pola, uruchamia logikę budżetową i tworzy rekord PO automatycznie.
Zamówienie zakupowe (PO) jest użyteczne tylko wtedy, gdy jest spójne, możliwe do śledzenia i odporne na przypadkowe zmiany. W twoim workflow PO powinno stać się stabilnym rekordem, któremu dostawcy i finanse mogą zaufać.
Generuj numer PO, gdy PO jest oficjalnie wysyłane do dostawcy, a nie gdy ktoś zaczyna je szkicować. Szkice są kasowane, restartowane i łączone — stąd luki i duplikaty.
Aby uniknąć duplikatów, przechowuj następny numer PO w jednym kontrolowanym miejscu i przydzielaj go w atomowym kroku (jedna akcja, która albo się powiedzie w całości, albo nie). Jeśli potrzebujesz przyjaznych numerów, dodaj prefiks (np. jednostka prawna lub rok), ale zachowaj licznik jako część unikalną.
Podziel PO na nagłówek i pozycje. Nagłówek trzyma kontekst; pozycje — to, co kupujesz.
Trzymaj nagłówek skupiony: dostawca i kontakt, ship-to i bill-to, waluta, warunki płatności, oczekiwana data dostawy, status (Draft, Issued, Acknowledged, Closed) i odniesienie do oferty.
Pozycje powinny być na tyle szczegółowe, aby później dopasowywać faktury: opis, ilość, jednostka, cena jednostkowa, podatek, rabat i centrum kosztów lub kod budżetowy. Sumy powinny być obliczane, nie wpisywane ręcznie.
Zdecyduj z góry, kiedy dopuszczalna jest rewizja. Małe zmiany, jak data dostawy czy notatki, mogą być rewizją (np. PO-1042 v2) z jasnym łączeniem „zastępuje v1”. Duże zmiany, jak dostawca, waluta lub istotna zmiana całkowitej kwoty, zwykle wymagają „anulowania i ponownego wystawienia”, żeby nikt nie wysłał towaru na podstawie niewłaściwego dokumentu.
Przykład: zgłoszenie zatwierdzone na 10 laptopów, ale oferta zmienia czas realizacji z 2 tygodni na 8 tygodni. Utwórz rewizję z zaktualizowaną datą dostawy i zachowaj oryginalne szczegóły oferty, aby PO zawsze odpowiadało temu, na co się umówiono.
Jeśli budujesz to w AppMaster, zamodeluj nagłówek PO, pozycje i wersje PO jako oddzielne encje, tak aby rewizje były czyste i audytowalne.
Powiadomienia decydują, czy wewnętrzny proces zakupowy jest płynny, czy zamienia się w polowanie na wątki. Traktuj wiadomości jako część procesu i powiąż je z zmianą statusu lub jasnym następnym zadaniem.
Zacznij od niewielkiego zestawu wewnętrznych aktualizacji, żeby ludzie ich nie ignorowali: zatwierdzono/odrzucono, kontrola budżetu nie powiodła się lub wymaga wyjaśnień, utworzono PO i gotowe do wysłania, zatwierdzenie przeterminowane lub data dostawy przeterminowana, oraz PO zmienione lub anulowane.
Każde powiadomienie powinno być czytelne w 10 sekund. Używaj spójnego szablonu z tytułem zgłoszenia, całkowitą kwotą, aktualnym statusem i dokładnie tym, co odbiorca ma zrobić dalej. Dla zatwierdzających dołącz krótkie uzasadnienie wydatku i najważniejsze pozycje.
Komunikacja z dostawcą też powinna być ustrukturyzowana. Dostawcy głównie potrzebują PO, zmian PO, anulacji i pytań o dostawę. Zapisuj każdą wiadomość wychodzącą i przychodzącą na wątku dostawcy dla danego PO lub zgłoszenia. Śledź wyniki prostymi polami jak status (draft, sent, delivered, failed), vendor_response (none, replied, bounced), follow_up_needed (yes/no) i follow_up_date.
Przykład: zgłoszenie laptopów jest zatwierdzone, PO wysłane, a dostawca odpowiada, że model jest niedostępny. Aplikacja loguje odpowiedź, ustawia follow_up_needed na yes i powiadamia zgłaszającego o konieczności wyboru alternatywy. W AppMaster możesz powiązać zmiany statusów z krokami wysyłki e-mail/SMS/Telegram i zapisać wynik wiadomości razem z PO.
Największe ryzyko to nie brak funkcji, lecz tworzenie niewłaściwych reguł i uczenie firmy obchodzenia ich.
Jednym z częstych błędów jest zamienienie zgłoszenia w labirynt statusów. Jeśli ludzie nie potrafią rozróżnić "Pending validation" od "Under review", przestają aktualizować system i dane stają się szumem. Trzymaj statusy powiązane z jasnymi działaniami i właścicielami. Każdy status powinien odpowiadać na jedno pytanie: „Co dalej i kto to zrobi?”.
Inną pułapką są zatwierdzenia bez właściciela lub terminu. Zgłoszenia utkną, gdy zatwierdzający jest na urlopie lub rola jest niejasna („Finanse” to nie jest osoba). Dodaj zapasowe pokrycie i prostą oczekiwaną ramę czasową, nawet jeśli nie jest formalna.
Te błędy powodują najwięcej pracy:
Edycje po zatwierdzeniu zasługują na szczególną uwagę, bo „niewinne” zmiany często zwiększają ryzyko. Jeśli ktoś uzyskał zgodę na 10 laptopów po 900 USD, a potem zmienia model na droższy lub zwiększa ilość, możesz mieć zatwierdzenia, które nie odzwierciedlają faktycznego zakupu.
Nie traktuj walidacji budżetu jako pojedynczego pola tak/nie. Finanse zwykle dbają o sposób raportowania wydatków: dział, projekt, konto księgowe i okno czasowe. Jeśli twoja aplikacja sprawdza budżet miesięcznie, a finanse raportują kwartalnie, „dostępny budżet” będzie zawsze wyglądał nieprawidłowo.
Jeśli budujesz to w AppMaster, zablokuj kluczowe pola po zatwierdzeniu i zapisuj każde odstępstwo jako zdarzenie (kto, kiedy, co zmienił i dlaczego). Ten ślad audytu ratuje przy sporach i audytach.
Przed uruchomieniem spisz podstawy. Większość „chaosu zatwierdzeń” pojawia się dlatego, że brakuje jednej małej reguły lub wymaganego pola.
Prosty checklist przed startem:
Gdy te reguły są gotowe, dodaj szybkie walidacje uruchamiane przed przejściem zgłoszenia dalej: wybór dostawcy (lub jasna ścieżka nowego dostawcy), pokrycie budżetu dla właściwego okresu, dowód cenowy, kompletne dane wysyłki/fakturowania i konkretne uzasadnienie biznesowe.
Przykładowy scenariusz: kierownik zespołu składa zgłoszenie laptopa dla nowego pracownika, który zaczyna w przyszłym tygodniu. Wybiera preferowanego dostawcę, dołącza ofertę i przypisuje właściwe centrum kosztów. Menedżer zatwierdza, bo pasuje do planu zatrudnienia. Finanse zatwierdzają po pozytywnej kontroli budżetu. Procurement tworzy PO, wysyła je do dostawcy i zapisuje potwierdzenie oraz oczekiwaną datę dostawy w tym samym rekordzie, aby zgłaszający mógł śledzić postęp bez dodatkowych maili.
Kolejne kroki: zaprojektuj model danych i reguły workflow, przetestuj z małym zespołem pilotażowym i jedną-dwiema kategoriami zakupów. W AppMaster możesz zbudować tabele w Data Designer i zmapować logikę routingu w Business Process Editor. Przeprowadź krótki pilotaż, sprawdź, gdzie zgłoszenia utknęły, zaostrz wymagane pola i potem rozszerz wdrożenie. Jeśli chcesz zobaczyć, jak ten pomysł przekłada się na faktyczną budowę aplikacji, AppMaster (appmaster.io) jest zaprojektowany do tworzenia wewnętrznych narzędzi z logiką zatwierdzeń, API oraz interfejsami web i natywnymi z tego samego modelu.
What should be the first milestone for a procurement request app?Start with request to PO. It forces clear approvals, budget checks, and traceability without dragging you into invoice matching and receiving right away. You can add downstream steps after the team trusts the first milestone.
Which request statuses should we use so people don’t get confused?Use a small, explicit set like Draft, Submitted, Approved, Rejected, Ordered, and Closed. Each status should clearly indicate who owns the next step and what action is expected, so nobody has to interpret vague labels.
How do we stop people from changing price or vendor after approval?Lock key fields at submission and require a formal change that triggers re-approval for anything that affects risk or spend, such as vendor, currency, quantity, unit price, cost center, or total. Allow only clarifications like notes, attachments, or delivery details without restarting the whole process.
What roles and permissions are essential in a procurement request workflow?Define roles first, then define what each role can do at each stage. A simple default is: requesters see and edit their own drafts, managers see direct reports, and finance/procurement have cross-department visibility, while vendor contacts never see internal notes or budget data.
How should approval delegation work when someone is on vacation?Make delegation a built-in feature, not an exception. Delegation should transfer approval rights for a time window, but it should not allow the delegate to rewrite the request content, so accountability stays intact.
How do we handle cross-department requests like IT buying for Marketing?Separate who requested the purchase from who pays for it. Route approvals to the cost center owner even if the requester is from another team, and store both parties on the record so it’s always clear who initiated and who is accountable for budget.
What’s the simplest way to implement budget checks that finance will trust?Calculate expected spend the same way finance will later, including tax, shipping, discounts, and currency conversion with a stored rate and date. Decide upfront whether insufficient budget blocks the workflow or allows escalation with an extra approval step.
How do we keep vendor data clean and prevent risky purchases?Keep a vendor master table as the single source of truth, and select vendors from a list rather than free text. Add a vendor status like Active, Pending review, and Blocked so risky vendors are consistently routed or prevented without relying on memory.
When should we generate a PO number, and how do we avoid duplicates?Generate the PO number only when the PO is officially issued, not when someone starts drafting. Assign it in a single controlled step to avoid duplicates, and keep the PO header and line items structured so totals are calculated rather than manually typed.
Can we build this without coding, and what does AppMaster help with?Yes, if you need a fast build without writing code. With AppMaster, you can model the data, define stage-based permissions and approval routing, and generate production-ready web and native mobile apps from the same model, which helps keep the workflow consistent across devices.
21 sty 2026
8 min
20 sty 20268 min
20 sty 20268 minEksperymentuj z AppMaster z darmowym planem.
Kiedy będziesz gotowy, możesz wybrać odpowiednią subskrypcję.
