W tym artykule
OPAK KREFT produkuje opakowania z tektury falistej na zamówienie — wszystko custom, bez katalogu standardowego. Trzydzieści lat na rynku, własna hala pod Gdańskiem, około trzech tysięcy pozycji w systemie i dwieście firm w bazie odbiorców. Kiedy zaczęło obowiązywać rozporządzenie PPWR, odbiorcy B2B zaczęli prosić o deklaracje zgodności. Nie było ich z czego wystawić.
Dane potrzebne do dokumentów istniały, tylko rozsypane: składy tektur w Excelu, parametry surowca w cennikach trzech dostawców, rozkroje w programie bez API, a reszta w głowie właściciela. Papiery robił w niedziele. Dziś biuro wystawia komplet dokumentów z wyboru indeksu surowca i konstrukcji, a wystawiony dokument jest zamrożony razem z danymi, na których powstał.
- 1
~3 000 pozycji, kilkadziesiąt deklaracji
Jednostką zgodności okazał się typ opakowania, nie indeks. To rozstrzygnięcie zmieniło wolumen dokumentów o dwa rzędy wielkości.
- 2
Dokument zamrożony po wystawieniu
Bajty i suma kontrolna zapisane w bazie. Zmiana gramatury u dostawcy nie zmienia PDF-a, który poszedł do odbiorcy.
- 3
Bez wymiany systemu
Subiekt został przy fakturowaniu. Dokumenty PPWR powstają obok, na danych o surowcach i konstrukcjach.
Firma i skala
Produkcja rusza od 1992 roku, obecna hala jest własna, a asortyment w całości robiony na zamówienie. W szczycie sezonu — wrzesień i kwiecień — przez zakład przechodzi około 180 zleceń miesięcznie. Po planowanym zakupie maszyn ma ich być blisko dwa razy tyle. W systemie leży ponad trzy tysiące pozycji, a po rozbiciu wkładek na osobne indeksy będzie ich około pięciu tysięcy.
Na produkcji pracują dwie–trzy osoby, w biurze obsługa klienta. To ważna liczba, bo przy takiej obsadzie każda godzina papierologii jest godziną zabraną komuś, kto jest potrzebny gdzie indziej. Właściciel odpowiada w firmie za wszystkie role naraz i sam nie zamierza być użytkownikiem systemu — wartość musiała być widoczna dla biura i dla produkcji, nie dla niego.
Punkt odniesienia dla „software, który zawiódł” mieli własny: branżowy program dla kartonażu kupiony przez konkurencję za kwotę rzędu dwustu tysięcy złotych i odstawiony po wdrożeniu. To ustawiło całą rozmowę — nie sprzedawaliśmy systemu, tylko jeden działający dokument, i dopiero na nim budowaliśmy dalej. Zasada, którą klient sam sformułował: rewolucji nie robimy, robimy rozbudowę.
Problem: dane w trzech plikach, dokument w czwartym
Karta techniczna opakowania z tektury falistej ma kilkanaście pól i prawie żadne z nich nie jest wpisywane od zera. Prawie wszystkie są przepisywane — z innego pliku, z cennika albo z pamięci. Przy jednym dokumencie to nie problem. Przy kilkuset rocznie, przy trzech dostawcach kodujących skład po swojemu i przy parametrach zmieniających się co kwartał, to jest etat.
- Składy tektur — arkusz z indeksami surowca, gramaturami i składem warstw, prowadzony ręcznie i rozjeżdżający się z cennikami dostawców.
- Parametry z cenników trzech dostawców — każdy w innym formacie i z inną konwencją oznaczeń; część wartości nie występowała w nich wcale.
- Rozkroje w osobnym programie, bez API i bez możliwości pobrania rysunku do dokumentu handlowego.
Do tego doszło nieporozumienie, które kosztuje najwięcej czasu w całej branży: przekonanie, że karta techniczna wyczerpuje temat. Nie wyczerpuje — PPWR wymaga trzech różnych dokumentów, a karta jest tym jedynym, którego rozporządzenie w ogóle nie wymaga. Dokumentacja techniczna zostaje u wytwórcy, deklaracja zgodności idzie do odbiorcy, a karta jest specyfikacją handlową.
Rozstrzygnięcie, które zmieniło cały projekt
Największe pytanie brzmiało: ile tych dokumentów trzeba wystawić. Przy trzech tysiącach pozycji w systemie odpowiedź „tyle, ile indeksów” oznaczała projekt, którego nie da się dowieźć ani obsłużyć. Rozstrzygnął to sam klient, na przykładzie jednej wystawionej dostawy.
Czyli: karta techniczna powstaje per produkt, a deklaracja per kombinację konstrukcji, sortu tektury i dostawcy. Różnica w wymiarach nie tworzy nowego typu opakowania. Zakład, który realnie pracuje na kilkunastu sortach i kilku klasach konstrukcji, wystawia kilkadziesiąt deklaracji — nie kilka tysięcy.
Karta techniczna: wybierasz indeks, reszta się liczy
Edytor karty ma dwie kolumny: formularz i podgląd dokumentu odświeżany na bieżąco. Operator wybiera indeks surowca i konstrukcję, a skład, gramatura, ECT, grubość i typ fali wchodzą z bazy. To jest cały mechanizm i cała oszczędność — pola, które wcześniej przepisywano z trzech plików, przestają być wpisywane.
Z geometrii konstrukcji liczą się wymiary zewnętrzne i masa z tolerancją. Odbiorca planuje z wymiaru wewnętrznego, bo w nim mieści się towar, a logistyka liczy z zewnętrznego — więc karta musi podawać oba. Masę weryfikowaliśmy na jednym zważonym pudle, bo wzór z domyślnej geometrii potrafi rozminąć się z rzeczywistością o kilkadziesiąt procent przy nietypowych klapach.
Schemat rozkroju rysuje się w SVG z wymiarów i geometrii konstrukcji. To był świadomy objazd: rysunki z katalogu konstrukcji są objęte licencją, a klient potrzebował ich na dokumencie handlowym. Efekt uboczny okazał się cenniejszy niż sam rysunek — skoro schemat powstaje z wymiarów, to te same dane liczą pole rozkroju, a z pola liczy się masa i zużycie materiału.
Deklaracja zgodności: grupowanie zamiast mnożenia
Deklaracja powstaje wg wzoru z załącznika VIII i obejmuje typ opakowania. Zamiast wystawiać ją osobno dla każdej pozycji, zaznacza się karty tego samego odbiorcy leżące na tej samej konstrukcji i tej samej tekturze — i wychodzi jeden dokument. Data wystawienia jest edytowalna wstecz, bo biuro musiało zacząć wystawiać dokumenty wcześniej, niż system był gotowy przyjąć komplet danych.
Numer deklaracji trafia obok pozycji na dokumencie sprzedaży. Dzięki temu odbiorca wiąże dostawę z dokumentem bez pytania biura — a to był jeden z powodów, dla których klient w ogóle chciał to zrobić: żeby klienci przestali dzwonić po dokumenty.
Niezmienne archiwum, czyli dlaczego folder nie wystarcza
Dokumentację i deklaracje trzyma się pięć lat dla opakowań jednorazowych i dziesięć lat dla wielokrotnego użytku. To nie jest funkcja, to jest zobowiązanie — i to ono przewraca rozwiązanie oparte na dysku sieciowym. Odbiorca poprosi o dokument, który dostał w marcu. Jeśli w międzyczasie dostawca zmienił gramaturę, dokument wygenerowany dziś z tych samych danych będzie inny.
Dlatego wystawienie dokumentu zapisuje wyrenderowany PDF razem z jego sumą kontrolną, a nie tylko dane w bazie. Po wystawieniu edycja jest zablokowana — poprawka wychodzi jako nowa wersja z własnym numerem, a stara zostaje zamknięta. Zweryfikowaliśmy to wprost: zmiana gramatury surowca w bazie nie zmienia bajtów dokumentu, który już poszedł.
Zasada, która nie jest funkcją
Najważniejsza decyzja w tym wdrożeniu nie dotyczy kodu. Dotyczy tego, czego generator nie robi. Narzędzia i szablony krążące po branży wypełniają pola, dla których nie ma źródła — a pod dokumentem jest podpis wytwórcy, nie autora szablonu.
- Wartości wchodzą z deklaracji dostawcy surowca, a nie z domysłu. Generator nie ma prawa napisać czegoś, czego nie ma w żadnym dokumencie źródłowym.
- Pole bez pokrycia zostaje puste albo z wpisem „do potwierdzenia”. Nigdy „Tak”.
- Wartość domyślna, przyjęta przez klienta na własną odpowiedzialność, jest na dokumencie oznaczona przypisem — inaczej po pół roku nikt nie odróżni jej od wartości potwierdzonej dokumentem.
Jak to zbudowaliśmy
Aplikacja stoi na Open Mercato — naszym otwartym szkielecie do systemów szytych na miarę. Powstały trzy moduły domenowe: baza surowców, słownik konstrukcji i generator dokumentów. Nazwy modułów są generyczne, nie klienckie, bo ten sam zestaw obsłuży kolejnego producenta opakowań bez przepisywania — a to była tania inwestycja w opcję, nie osobny projekt.
PDF renderuje headless Chromium z tego samego szablonu, który widać w podglądzie — jeden układ zamiast dwóch rozjeżdżających się implementacji. Uprawnienia rozdzielają biuro od produkcji: produkcja nie ma dostępu do kart technicznych, bo karta jest dokumentem dla odbiorcy, a na halę idą uwagi ze zlecenia. To rozstrzygnięcie skróciło zakres.
Tempo narzucił klient i to była dobra decyzja. Wrzesień to szczyt jego sezonu, więc horyzont postawienia całego programu rozłożył się na miesiące, a nie tygodnie. Wdrażamy etapami, z pilotażem na jednym odbiorcy i jednej maszynie — zamiast wielkiego startu, po którym system stoi nieużywany. To dokładnie ten wzorzec, którego chcieli uniknąć.
Czego to nie robi
Uczciwa lista granic jest częścią tego wdrożenia, nie przypisem do niego. Trzy rzeczy zostają jawnie poza zakresem:
- Odpowiedzialność merytoryczna za treść dokumentów. Dostarczamy silnik, formuły i szablony. To, co firma deklaruje, jest jej oświadczeniem i jej ryzykiem.
- Interpretacja przepisów. Nie jesteśmy kancelarią. Normy mówią między innymi o dopuszczalnym udziale pustej przestrzeni w opakowaniu transportowym, a kontrolujący może kwestionować sam dobór tektury — tego żaden generator nie rozstrzygnie.
- Dane, których nie ma. Dopóki deklaracje od części dostawców nie przyszły, odpowiadające im pola zostają puste. Nie zgadujemy.
Zabezpieczeniem po stronie klienta jest standaryzacja: ograniczenie do jednego dostawcy per materiał i mniejsza liczba sortów. Mniej kombinacji to mniej dokumentów do wystawienia i do obrony — i to jest decyzja biznesowa, nie techniczna.
Co dalej
Dokumenty były pierwszym etapem i zostały wybrane właśnie dlatego, że są najkrótszą drogą do czegoś, co działa. Ale dane, które musiały powstać po drodze — baza sortów tektury, słownik konstrukcji, powiązanie odbiorcy z dokumentem — są fundamentem reszty systemu, a nie jednorazową łatką pod termin. Te same rekordy obsłużą zlecenia produkcyjne, etykiety i magazyn.
W kolejce jest repozytorium dokumentów pogrupowane po odbiorcy, a potem panel, w którym odbiorca sam pobiera swoje dokumenty. Więcej o tym, jak podchodzimy do systemów dla produkcji, znajdziesz na stronie dla branży produkcyjnej, a skrócony opis wdrożenia — w karcie realizacji.
Mateusz Kozłowski
Założyciel flowbiz · Ekspert automatyzacji procesów
Wdrażam automatyzacje, integracje i AI w średnich firmach na Pomorzu i w Kujawsko-Pomorskiem.
