In this article
OPAK KREFT makes corrugated board packaging to order — everything custom, no standard catalogue. Thirty years in business, its own plant near Gdańsk, around three thousand items in the system and two hundred customers on file. When the PPWR regulation started to apply, B2B customers began asking for declarations of conformity. There was nothing to issue them from.
The data existed, only scattered: board compositions in a spreadsheet, material parameters in three suppliers' price lists, blanks in a program with no API, and the rest in the owner's head. He did the paperwork on Sundays. Today the office issues a full set of documents from one material index and one construction, and an issued document is frozen together with the data it was built from.
- 1
~3,000 items, a few dozen declarations
The unit of conformity turned out to be the packaging type, not the SKU. That call changed the document volume by two orders of magnitude.
- 2
Frozen once issued
Bytes and checksum stored in the database. A grammage change at the supplier does not alter the PDF that went to the customer.
- 3
No system replacement
The ERP kept invoicing. PPWR documents are produced alongside it, on material and construction data.
The company and the scale
Production goes back to 1992, the plant is owned outright, and the entire range is made to order. At the seasonal peak — September and April — around 180 orders a month pass through the works. After the planned machine purchase that should roughly double. The system holds over three thousand items, and once inserts are split into separate indexes there will be around five thousand.
Two or three people work in production, plus customer service in the office. That number matters, because at that headcount every hour of paperwork is an hour taken from someone needed elsewhere. The owner covers every role in the company and does not intend to be a system user himself — the value had to be visible to the office and to production, not to him.
They had their own reference point for „software that failed”: an industry program for board converting bought by a competitor for something in the region of two hundred thousand złoty and shelved after the rollout. That framed the whole engagement — we did not sell a system, we sold one working document, and built on it from there. The rule the client formulated himself: no revolution, an extension.
The problem: data in three files, the document in a fourth
A corrugated packaging datasheet has a dozen or so fields and almost none of them is typed from scratch. Almost all of them are copied — from another file, from a price list, or from memory. On one document that is not a problem. On several hundred a year, with three suppliers each coding composition their own way and parameters changing every quarter, it is a full-time job.
- Board compositions — a spreadsheet of material indexes, grammages and layer make-up, maintained by hand and drifting away from the suppliers' price lists.
- Parameters from three suppliers' price lists — each in a different format and naming convention; some values did not appear in them at all.
- Blanks in a separate program, with no API and no way to pull a drawing into a commercial document.
On top of that came the misunderstanding that costs the industry the most time: the belief that a datasheet settles the matter. It does not — PPWR calls for three different documents, and the datasheet is the one the regulation does not require at all. Technical documentation stays with the manufacturer, the declaration of conformity goes to the customer, and the datasheet is a commercial specification.
The call that changed the whole project
The big question was how many of these documents had to be issued. With three thousand items in the system, the answer „as many as there are SKUs” meant a project that could be neither delivered nor operated. The client settled it himself, on the example of one delivery note.
So: a datasheet is produced per product, and a declaration per combination of construction, board grade and supplier. A difference in dimensions does not create a new packaging type. A plant that realistically runs a dozen grades and a handful of construction classes issues a few dozen declarations — not a few thousand.
The datasheet: pick an index, the rest is calculated
The datasheet editor has two columns: the form and a live document preview. The operator picks a material index and a construction, and composition, grammage, ECT, thickness and flute type come from the database. That is the whole mechanism and the whole saving — the fields previously copied from three files stop being typed.
External dimensions and weight with tolerance are calculated from the geometry of the construction. The customer plans from the internal dimension, because that is where the goods go, and logistics works from the external one — so the sheet has to carry both. We verified the weight on one weighed box, because a formula based on default geometry can miss reality by tens of per cent on unusual flaps.
The blank diagram is drawn in SVG from the dimensions and construction geometry. That was a deliberate detour: catalogue construction drawings are licensed, and the client needed one on a commercial document. The side effect turned out to be worth more than the drawing — since the diagram is generated from dimensions, the same data yields the blank area, and from the area come weight and material consumption.
The declaration: grouping instead of multiplying
The declaration follows the Annex VIII template and covers a packaging type. Instead of issuing one per line, you select the datasheets of the same customer sitting on the same construction and the same board — and out comes a single document. The issue date can be set backwards, because the office had to start issuing documents earlier than the system was ready to hold a complete data set.
The declaration number lands next to the line on the sales document. The customer then links the delivery to the document without calling the office — and that was one of the reasons the client wanted this at all: so customers would stop phoning for paperwork.
An immutable archive, or why a folder is not enough
Documentation and declarations are kept for five years for single-use packaging and ten for reusable. That is not a feature, it is an obligation — and it is what breaks a network-drive solution. A customer asks for the document they received in March. If the supplier changed the grammage in the meantime, a document generated today from the same data will be different.
So issuing a document stores the rendered PDF together with its checksum, not just the data behind it. After issue, editing is blocked — a correction goes out as a new version with its own number and the old one is closed. We verified this directly: changing a material's grammage in the database does not change the bytes of a document that has already gone out.
A rule that is not a feature
The most important decision in this rollout is not about code. It is about what the generator refuses to do. The tools and templates circulating in the industry fill in fields with no source — and the signature at the bottom belongs to the manufacturer, not to whoever wrote the template.
- Values come from the material supplier's declaration, never from a guess. The generator has no licence to write something that appears in no source document.
- A field with no backing stays empty or reads „to be confirmed”. Never „Yes”.
- A default value, adopted by the client on their own responsibility, is marked with a footnote on the document — otherwise six months later nobody can tell it apart from a value backed by a document.
How we built it
The application runs on Open Mercato, our open foundation for bespoke business systems. Three domain modules were created: the material database, the construction dictionary and the document generator. The module names are generic rather than client-specific, because the same set will serve the next packaging manufacturer without a rewrite — a cheap investment in an option, not a separate project.
The PDF is rendered by headless Chromium from the same template you see in the preview — one layout instead of two implementations drifting apart. Permissions separate the office from the shop floor: production has no access to datasheets, because a datasheet is a customer document and the floor works from the notes on the work order. That call shortened the scope.
The client set the pace and it was the right call. September is his peak, so the horizon for standing up the whole program spread across months rather than weeks. We roll out in stages, piloting on one customer and one machine — instead of a big launch after which the system sits unused. Which is exactly the pattern they wanted to avoid.
What it does not do
An honest list of limits is part of this rollout, not a footnote to it. Three things are explicitly out of scope:
- Responsibility for the substance of the documents. We provide the engine, the formulas and the templates. What the company declares is its statement and its risk.
- Interpreting the rules. We are not a law firm. The standards speak, among other things, about the permitted share of empty space in transport packaging, and an inspector may challenge the choice of board itself — no generator settles that.
- Data that does not exist. Until declarations arrive from some suppliers, the corresponding fields stay empty. We do not guess.
The client's own safeguard is standardisation: one supplier per material and fewer board grades. Fewer combinations means fewer documents to issue and to defend — and that is a business decision, not a technical one.
What comes next
Documents were the first stage, chosen precisely because they are the shortest route to something that works. But the data that had to be created along the way — the board grade database, the construction dictionary, the link between customer and document — is the foundation of the rest of the system, not a one-off patch for a deadline. The same records will serve production orders, labels and stock.
Next in the queue is a document repository grouped by customer, and after that a portal where the customer downloads their own documents. More on how we approach systems for manufacturing on the manufacturing page, and a short summary of the rollout in the portfolio entry.
Mateusz Kozłowski
Founder of flowbiz · Process automation expert
I implement automations, integrations and AI in mid-sized companies across Pomerania and Kuyavia-Pomerania.
