Case study
Open Mercato
Procesy

Dokumenty PPWR u producenta opakowań z tektury

Jak OPAK KREFT zamienił składanie kart technicznych i deklaracji zgodności z trzech plików na generator z niezmiennym archiwum

Mateusz KozłowskiMateusz Kozłowski13 min
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.

Edytor karty. Wybór indeksu surowca zaciąga parametry tektury, a podgląd dokumentu odświeża się na bieżąco.

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.

Karta wystawiona. Blok PPWR, parametry tektury i rozkrój na jednej stronie A4 — z przypisem przy każdej wartości domyślnej.

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.

Deklaracja zgodności UE. Siedem punktów wymaganych wzorem; dane wytwórcy i przedmiot deklaracji wchodzą z bazy.

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.

Rejestr wystawionych dokumentów. Numer z sekwencji dziennej, powiązanie z odbiorcą i sortem oraz suma kontrolna pliku.

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

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.

Mateusz z flowbiz - ekspert automatyzacji

Bezpłatna Konsultacja

Policzmy, ile kosztuje Cię dzisiejszy proces

30 minut rozmowy, a w 24 h działający prototyp Twojego rozwiązania. Bez technicznego żargonu, bez ukrytych kosztów i bez zobowiązania na cokolwiek dalej.

Bezpłatna konsultacja (30 min) - nazywamy najdroższe wąskie gardło

Działający prototyp w 24 h - zobaczysz rozwiązanie, zanim cokolwiek zamówisz

Wycena fixed price na piśmie - dopiero po prototypie, bez niespodzianek