Sector · Print and Forms
A print product does not exist before the order. Format, paper, colours, print run and finishing together are what create the product and the price in the first place. We build the systems behind that: configurators with dependencies, pricing rule sets with print run scales, print data upload with automatic analysis, and OCI punch-out into the procurement systems of the banking sector. Demonstrated at bank-formular.de for Lijnco and plotplus.de for Küper Digital.
An A5 flyer on 170 gsm coated paper, four colours on both sides, 2,500 copies, trimmed and bundled into packs, is not an article. It is a calculation with five inputs. The article master data that a standard shop relies on has no equivalent for this. What is needed is a rule set that calculates, not a table that looks things up.
Print run costs consist of set-up and running production, so twice the quantity never costs twice as much. And occasionally the higher quantity costs less, because from that point a different process applies. Technically correct, but the person ordering assumes an error. Jumps like these need to be explained in the price scale, not smoothed over.
With a large-format printing service, half the order sits in the file: pages, dimensions, printed area. Upload and analysis therefore belong in the ordering process, not in an email afterwards. Anyone who only calculates after accepting the order negotiates price and deadline a second time.
In the banking sector, purchasing does not happen freely on the internet. Budgets, cost centres and approval levels sit in the customer's procurement system. A supplier shop standing next to it creates breaks in the process: retyping, separate approval, double entry. This is why OCI punch-out in the forms business is less a feature than a condition of access.
The difference from every other product range starts before the order: what the customer buys does not exist yet at that point. With a supplier of screws, the article number comes first and the price sits next to it. With a printing company, five or six inputs come first — format, paper type and weight, colours, print run, finishing, occasionally personalisation — and only from those does a product with a price emerge. A shop system that internally assumes well-maintained article master data is working against the market at this point.
Anyone who tries it anyway with a variant matrix notices the problem at the second paper type. Six formats, eight papers, four colour options, twelve print run levels and five finishing options add up to more than eleven thousand combinations. Each one would need a record, an article number and a maintained price. A considerable share of them cannot be produced at all: this paper does not run in this format, this embossing only from a minimum print run, this fold type not at this paper weight. The matrix does not maintain itself, and it does not know these rules.
A configurator turns this around. It holds the options and their dependencies, blocks impossible combinations instead of offering them, and creates the article only in the basket. One detail that is often forgotten matters a great deal in practice: a configuration state should be linkable. The internal sales team needs the ability to send a finished configuration to the customer by email, and the customer needs the ability to find it again next time. As soon as the configuration exists only in the form state of a session, quotation, follow-up question and reprint are manual work every single time.
Print run costs have two parts. One is incurred once: set-up, plates or prepress, make-ready time on the press, setting up the finishing. The other runs along with the job: sheets, ink, running production, cutting, packing. This is why twice the print run never costs twice as much, and why the smallest print run is always expensive in relative terms. A price scale that does not reflect this degression is either unsellable in small quantities or loss-making in large ones. Both only become apparent after months, when someone works through the retrospective costing.
Then there are the jumps. Above a certain print run, a format sits differently on the printing sheet because a different layout of copies per sheet pays off. Above a certain quantity, offset printing becomes cheaper than digital printing. A larger press brings a different sheet price with it. The result is points in the price scale where the higher quantity costs less than the lower one. To the person ordering, that looks like an error, and they do what people do when they suspect an error: call or abandon the order. The answer to this is not a different price but a note on the price scale — the next higher quantity is cheaper, and this is the reason. That takes queries away from the internal sales team without anyone bending the numbers.
That leaves the question of where this calculation sits. The shop needs the price in real time, otherwise there is no configurator. Whether the rules are maintained in the web system or come through an interface from the plant's own costing depends on who owns them in business terms. At plotplus.de we built the rule set to be configurable, so that new materials can be added without a code change; the pricing logic itself sits in our own code and can be adjusted there when the range changes. More important than the placement is having a single source: two calculations in parallel — one in the shop, one in the ERP — is the mistake that costs the most to correct.
In print services, nobody sells articles. What is sold is a process. At plotplus.de of Küper Digital GmbH & Co. KG this is the starting point of the whole system: what the customer orders sits in the file they upload. Page count, formats, printed area, ink coverage. Only from that does it follow what the order covers and what it costs. The application also accepts large print files, places them in a queue, analyses them and, together with material, output type and quantity, creates the order items including the price. Without this analysis, the price is only fixed once someone has opened the file and measured it — and that does not scale with the order volume.
Technically this has consequences for the architecture. Processing runs in background jobs, decoupled from the web server, so that one large order does not slow down the service for everyone else. During processing, the person ordering sees a progress state instead of running into a timeout. Storage is designed for large volumes of files, not for product images. Operation and deployment run in containers on our own servers in Germany — which with print data is less a marketing question than one of transfer volume and of being able to give the customer clear answers.
The data check has to be kept separate from the analysis. It is not an automatic part of every project but a decision of its own — and where it is required, this applies: page format and bleed allowance, colour space, image resolution, embedded fonts, page count and overprint settings can be checked formally. What cannot be checked is whether the content is correct. What matters, therefore, is what the system does with the check result. A log that the person ordering sees and confirms carries more weight than a silent correction in the background — and it is the document people refer to when a complaint is discussed later. Anyone who straightens files out automatically without saying so only moves the discussion further back.
Forms printing for banks, savings banks and public authorities is a different business from advertising print, even if the same press is running. There is no campaign and no launch date, but an inventory that is topped up. The articles are fixed, often for years, frequently with their own layout and their own numbering per institution. And purchasing does not happen on the internet but in a procurement system that holds budgets, cost centres and approval levels. A supplier shop that stands outside this system creates exactly the breaks in the process that the procurement department wanted to get rid of: retyping, separate approval, double entry.
bank-formular.de of Lijnco is our evidence for this, in the banking sector. The basis is Shopware, set up for B2B: customer groups with their own terms, ranges released for specific customers, order history, reordering of known forms, product configurations for print runs, versions and variants — in the forms business right through to carbonless copy sets. The core of the project is the OCI plugin. The buyer starts in their procurement system, is logged in to the shop by punch-out with the credentials that were passed over, and sees the range released for them at their own prices. The completed basket is not triggered as an order but returned in OCI field format to the hook URL of the procurement system — with article number, description, quantity, price and unit. Approval and cost centre assignment stay with the customer.
The effort does not sit in the standard but in the particular counterpart system. Field assignments, character sets and return procedures differ in practice, which is why every connection is tested against the real customer system and not against an assumption. Once the first connection is built, the second tends to become a configuration task rather than a separate project. How this works technically in detail is described on our service page on OCI and punch-out; what belongs here is only the market finding: without this connection, a forms supplier cannot reach certain customers, and with it the shop next to it remains perfectly usable for everyone who has no procurement system.
The first order is acquisition. The money is made on repetition. A form rarely changes, the print run changes constantly; a brochure goes into a second and third round; a poster design is reprinted for the next branch. This is exactly the point at which it is decided whether a customer stays. If reordering means that someone in internal sales has to look up the old order, reconstruct the configuration and fetch the file from a mailbox, then it takes hours, and the customer orders from the supplier where it takes two clicks — even if that supplier was more expensive on the first order.
Technically this is a question of data storage, not of the interface. An order archive has to store more than the order: the complete configuration with all chosen options, and the print file in exactly the version that was printed. The reprint then consists of two inputs, print run and deadline, and the price is recalculated, because it depends on the quantity. Versioning belongs with this, so that it stays traceable which state ran in which order — with forms containing legally relevant text, that is not a convenience but the reason for archiving in the first place. And an honest calculation of the storage requirement belongs with it too, because print data is large and retention periods are long.
The special case in the forms business is call-off delivery. The contracted total quantity is printed once, and delivery happens on call-off over months. For this the shop has to know two quantities — the agreed quantity and the remainder in the warehouse — display the remaining quantity and give a warning before it runs out. This is warehouse logic in a shop front end and is not provided for in standard systems. What we have evidence for in our projects so far is the reordering of known forms from the order history; the call-off logic depends on the individual framework agreement and is built for it. Whether a module on an existing shop is enough for that or a separate application is needed is something we look at beforehand. If your system already carries this at its core and only the reordering is missing, we say so — even if a rebuild would be the bigger job.
Because it assumes article master data. A print product only comes into being when the order is placed, out of format, paper, colours, print run and finishing. Setting up these combinations as variants leads to five-figure article counts even for medium-sized ranges, and some of those combinations cannot be produced at all. What is needed is a configurator with a rule set and a calculation that computes — not a table that looks things up.
As long as the number of combinations stays manageable and each one justifies its own record, a variant matrix works. As soon as dependencies come into play — this paper not in this format, this finishing only from this print run upwards — the matrix becomes a maintenance trap, because it does not know these rules. At that point the configurator is the cheaper solution, even if it looks like more work at the start.
From two components: one-off costs for prepress, plates and set-up time, and running costs per sheet or per copy. This is why twice the print run never costs twice as much. On top of that come jumps, when a format sits differently on the printing sheet, when production switches from digital to offset printing, or when a different press makes more sense. A pricing rule set has to reflect these jumps, not smooth them over.
Because the higher quantity occasionally costs less than the lower one. Technically this is correct: from a certain print run upwards, a different process applies. To the person ordering it looks like a bug, so they call or abandon the order. The answer is not a different price but a note on the price scale: the next higher quantity is cheaper, and here is the reason. That takes queries away from the internal sales team.
The shop needs the price in real time, otherwise there is no configurator. Whether the rules are maintained in the web system or come through an interface from the plant's own costing depends on who owns them in business terms. If pricing authority sits in production, we collect it from there. If it sits in sales, a configurable rule set in the system itself is the shorter route. Two parallel calculations are the mistake in either case.
Yes. At plotplus.de of Küper Digital GmbH & Co. KG the upload is in fact the starting point of the calculation: the system accepts large print files, places them in a queue, analyses pages, dimensions and printed area, and derives the order items from that together with material, output type and quantity. Processing runs decoupled from the web server, so that one large order does not slow down the service for everyone else.
The formal aspects can be checked automatically: page format and bleed allowance, colour space, image resolution, embedded fonts, page count. What cannot be checked is whether the content is correct. In our existing projects, the automatic step is the analysis of the file for order scope and price; a preflight check is a separate building block and is decided project by project. What matters then is what the system does with the result: a check log that the person ordering sees and confirms carries more weight than a silent correction — above all when a complaint is discussed later.
OCI is a standard for electronic procurement established by SAP. The buyer jumps from their procurement system into the supplier shop, assembles the basket and transfers it back in structured form; the order itself is placed in their own system, with its budgets, cost centres and approval levels. In banks and public authorities, purchasing does not happen freely on the internet, which is why this connection is a condition of access there. The technical sequence is described on our service page on OCI and punch-out.
bank-formular.de of Lijnco is a Shopware shop for forms and print solutions in the banking sector. Through an OCI plugin the buyer is logged in with the credentials that were passed over, sees the range released for them at their own terms, and the completed basket goes back to the hook URL of the procurement system in OCI field format. Every connection is tested against the real customer system, because field assignments, character sets and return procedures differ in practice.
In the forms business this is not an extra function but the foundation. Every customer has their own articles, often with their own layout, their own numbering and their own terms from a framework agreement. A form belonging to one institution has no purpose outside that customer and should not be findable there either. This is implemented through customer groups with released ranges and customer-specific prices.
The prerequisite is an order archive that stores not only the order but the complete configuration and the print file in the version that was printed. The reprint then consists of two inputs, print run and deadline, and the price is recalculated, because it depends on the quantity. Anyone who has reorders taken down by hand instead loses the customer to the supplier where it takes two clicks.
The contracted total quantity is printed once, and delivery happens on call-off. For this the shop has to know two quantities: the agreed quantity and the remainder in the warehouse. The person ordering calls off, sees the remaining quantity and is warned before it runs out. What we have evidence for so far is the reordering of known forms from the order history; the call-off logic depends on the rules of the individual framework agreement and is built for it. This is warehouse logic in a shop front end and is not provided for in standard systems — but it is the point at which forms suppliers keep their customers.
Only if it knows the production schedule. A delivery date comes out of the order cut-off time, the production days for the chosen finishing, the shipping method and public holidays — not out of a text field. As long as these values do not come from planning, the honest option is a range with confirmation after the data has been checked. A firm commitment that production cannot keep costs more than a cautious statement.
It depends on where the weight lies. If sales is at the centre — customer groups, terms, B2B ordering process, punch-out — then Shopware is the viable foundation; that is how bank-formular.de runs. If processing is at the centre, meaning file in and calculation out, then a separate application alongside a TYPO3 website is the cleaner split; that is how plotplus.de runs. We look at what is already in place first. If a rebuild does not pay off, we say so.
Send us one product page from your range and the price scale behind it. On that basis, one conversation is enough to clarify whether configuration is sufficient or development is needed. Mon–Fri 9:00–16:00, +49 441 21 21 63 0.