Jubi-Prog - system magazynowy salonu jubilerskiego zamiast desktopowego JUBI 2.20

Punkt wyjścia

Ten sam klient ma u nas już sklep WooCommerce z wyszukiwarką diamentów i bota, który prowadzi mu blog. Sklep obsługuje to, co widać z zewnątrz. Ten projekt jest o tym, co dzieje się po drugiej stronie lady.

Salon jubilerski prowadzi kilka ewidencji naraz i każda rządzi się czym innym. Towar na stanie to numer, metal, próba, masa, cena zakupu i marża. Zlecenie to termin, zadatek i cudza własność w rękach jubilera. Komis to umowa z osobą, która zostawia swój wyrób do sprzedaży. Skup złota od osoby fizycznej to transakcja, przy której zbiera się dane wrażliwe. Raty, zadatki, bony i faktury to jeszcze cztery osobne rzeczy.

Punktem wyjścia był desktopowy JUBI 2.20, program instalowany na stanowisku w salonie. Przy takim układzie dostęp do danych kończy się tam, gdzie stoi komputer, kopia zapasowa zależy od tego jednego dysku, a wszystko, czego program nie drukuje, ktoś przepisuje ręcznie.

Decyzje, które ukształtowały projekt

Aplikacja webowa, nie kolejny program na jednym komputerze

System jest stroną, którą otwiera się w przeglądarce - z lady, z zaplecza i z domu. Baza jest jedna, backup robi się w nocy po stronie serwera, a wersji „u mnie jest nowsza” nie ma, bo nie ma czego instalować. Kosztem jest zależność od sieci i od tego, że serwer stoi: przy programie na dysku awaria internetu nie zatrzymuje pracy, tutaj zatrzymuje. Ta wymiana jest świadoma, a nie przemilczana - wybór między WordPressem a aplikacją pisaną od zera rozkładamy na czynniki w tekście o tym, kiedy bierze się WordPressa, a kiedy Next.js.

Trzynaście modułów, jedna warstwa wspólna

Każdy rodzaj ewidencji ma własny moduł i własny formularz, bo komis naprawdę potrzebuje innych pól niż skup złota. Wspólne są cztery rzeczy: numeracja, wydruki, zgody RODO i historia zmian. Gdyby trzymać je osobno w każdym module, po pół roku istniałoby trzynaście wariantów tego samego wydruku i trzynaście miejsc, w których trzeba poprawić adres firmy.

Dokumenty generuje program, nie człowiek w edytorze tekstu

Pięć wzorów - zlecenie, umowa komisowa, umowa skupu metalu, faktura i karta złocenia - powstaje w kodzie przez jsPDF. Umowy mają paragrafy, kwotę słownie, klauzulę informacyjną i miejsca na podpisy. Zlecenie wychodzi w dwóch kopiach na jednej kartce A4 z kodem kreskowym Code128.

To nie jest wygoda, tylko powtarzalność. Dokument składany ręcznie w Wordzie różni się między egzemplarzami dokładnie tam, gdzie nie powinien: w dacie, w kwocie, w akapicie, który ktoś skasował, bo „nie mieściło się na stronie”.

Zgoda RODO jako pole, które blokuje zapis

Przy zleceniu i przy transakcji metalem checkbox zgody jest wymagany do zapisu. Można to było zrobić jako kartkę do podpisu obok programu - i wtedy po roku nie ma jak sprawdzić, przy których transakcjach ją odebrano. Pole w bazie odpowiada na to pytanie zawsze, a klauzula jedzie automatycznie na wydruk.

Historia zmian od pierwszego dnia, nie po pierwszym sporze

Osobny moduł zapisuje każde dodanie, edycję, usunięcie, sprzedaż, pożyczenie, transakcję metalem, rozliczony zadatek i wysłany SMS - z datą, obiektem i szczegółem. Audyt dopisany po fakcie ma jedną wadę: zaczyna się w dniu wdrożenia, a pytania dotyczą zwykle tego, co było wcześniej.

Etykiety przez lokalny serwis drukarki

Etykiety jubilerskie 50×10 mm z numerem i kodem QR drukuje DYMO LabelWriter 550, przez serwis DYMO Connect działający na komputerze kasjera pod https://localhost:41951. Serwis ma certyfikat self-signed, więc przeglądarka blokuje połączenie, dopóki użytkownik raz ręcznie go nie zaakceptuje - i trzeba to powtórzyć po zmianie przeglądarki albo reinstalacji sterownika. To jest realna niedogodność integracji i jest opisana w instrukcji dla stanowiska, a nie zamieciona pod dywan.

SMS na gotowych szablonach

Zawiadomienie o gotowym wyrobie to zdanie, które pisze się kilkanaście razy w tygodniu. Szablony siedzą w ustawieniach, mają znaczniki numeru zlecenia, nazwiska i terminu, a wysyłka idzie przez SMSAPI i ląduje w historii. Treść zawsze można nadpisać ręcznie - szablon ma skracać pisanie, nie zabierać możliwości napisania czegoś innego.

Co z tego wyszło

System działa w salonie i jest rozwijany dalej: trzynaście modułów, 29 ekranów, 66 endpointów API, pięć wzorów dokumentów PDF, 84 commity od kwietnia do września 2026.

Uczciwa uwaga do tych liczb: to jest opis zakresu, a nie dowód oszczędności. Nie mierzyliśmy, ile minut zajmowało wystawienie umowy komisowej przed wdrożeniem, więc nie napiszemy, że skróciliśmy je o połowę. Policzalne jest co innego - że umowa, faktura, etykieta i zawiadomienie SMS-em wychodzą dziś z tego samego miejsca co ewidencja, i że każda zmiana zostawia ślad w historii.

Zrzuty w galerii pochodzą z instancji demonstracyjnej z danymi wymyślonymi na potrzeby tej strony. Ewidencja klientów salonu nie opuszcza systemu i nie trafia do portfolio - to samo dotyczyłoby każdego systemu, który dla kogoś budujemy.

Technicznie

Next.js 16 (App Router) z React 19 i TypeScriptem, Tailwind CSS 4 i shadcn/ui na froncie. Dane w PostgreSQL 16 przez Prismę 7. Sesje na iron-session w ciasteczku httpOnly, hasło hashowane bcryptem, middleware odcina każdą ścieżkę poza logowaniem i odczytem plików. Zdjęcia przechodzą przez sharp do WebP, a pliki HEIC z iPhone’a konwertuje przeglądarka, zanim cokolwiek poleci na serwer. PDF-y składa jsPDF z jsbarcode (Code128) i qrcode (etykiety DYMO). Całość jedzie w Docker Compose na VPS za nginksem, pod program.jubilerpagacz.pl, z nocnym zrzutem bazy o 3:00.