Loading

Managing prices in web-to-print solutions are for many, a significant challenge. With more than 800 solutions available globally, I, of course, should be careful not to generalize, but most offer the following or similar functionality.

1) prices in defined steps, i.e., 100, 200, 300, 400, 500, etc.
2) prices per pcs in defined steps, i.e., 1-100, 100-200, 200-300, etc.
3) prices in batches
4) prices based on size (typically used in large format, etc.)

Most solutions offer additional prices so that you can have variations, various paper types, finishing types, etc.

The matrix you achieve this way is HUGE. Some solutions offer exceptions, combinations, and other ways to manage prices.

For solutions offering private/corporate stores, the matrix becomes overwhelming.

All solutions offer CSV/XLS data import/export enabling the pricing to be done externally - or checked, updated, or managed.

Some solutions let you add SKU numbers when you create a product, but this also raises some issues that we will touch upon later.

Almost every solution allows you to bulk-update prices.

When you talk to printers, some want to integrate their web-to-print solution with their MIS or ERP system.

In your MIS/ERP system, you often calculate prices based on a full-cost model, combining variable cost with overhead, to at least give you an idea about your cost-base.

If you want to integrate your MIS/ERP system with a web-to-print solution, the system should be able to deliver tables of data, like the one described above. No MIS/ERP systems can provide tables of prices based on one SKU/product.

SKU's are used as unique identifiers. To give you an example of why SKU's and how products in ERP solutions and web-to-print solutions is something to take very seriously!

Product: 8 pages brochure
Version 1: 90g uncoated paper
Version 2: 100g coated paper
Version 3: 130g coated paper
Version 4: Cover 170g coated paper + 90g uncoated paper for content
Version 5: Cover 170g coated paper + 100g coated paper for content
Version 6: Cover 170g coated paper + 130g coated paper for content
Etc.

You can imagine further variants with laminations, varnishes, foils, spot UV, etc. or what color options, like 1+1, 4+0, 4+4, 5+5, etc. and add one more dimension - format. You would surely create this product in A6, A5, A4 - and maybe even some square formats, or M-formats as well.

This one product becomes extremely complex and will have a product matrix quite large.

The web-to-print solutions I have seen have a quite flexible product setup, which is good - and REALLY bad at the same time.

Let me explain. From a user perspective, we want everything to be as simple as usual. Every printer can have different opinions about what logic to follow - one could be:

Choose a product -> Brochure
Choose a format -> A5
Choose page numbers -> 8
Choose paper variant -> 170/130
Choose print variant -> 4+4
Choose enhancement -> Lamination

In your web-to-print solution, this is one product, with variables/parameters (simplified). In your ERP system, this exact version is one product. In most ERP systems, you will, therefore, end up with 10-15-30-100 thousand SKUs representing your shop.

I called Kit Tomshøj from PrintVis to get this verified - and this is true in case you use SKUs as identifiers. PrintVis can combine templates and internal pricelists and rules to avoid the overwhelming number of SKUs.

If your ERP system uses the SKUs to manage prices, it makes as little sense managing prices in your ERP system as doing it in spreadsheets or the web-to-print solution.

I don't know anybody who has solved this problem, but I can suggest a few things that might be interesting to consider.

The first and most important is defining a price-exchange standard - likely based on JDF/XJDF or similar - where MIS/ERP systems can exchange relevant data for creating a price matrix for a web-to-print solution.

Another solution could also be to create a dynamic price request, so every time a page is generated in your web-to-print solution, the prices are calculated and fetched from the ERP system.

The reason why we want accurate data is, of course, for many reasons. First data should be handled where it makes the most sense, and also where it's managed as easy as possible. Managing products/data/prices in your ERP system is mostly not very good either.

Example:
If we simplify the ERP system, it has the following data:
SKU · Product Name · Product Description (often limited space) · Cost Price · Sales Price · and often a supplier reference.

The print product contains WAY more information, some marketing related, some production-related, and some financially related.

The data needs to come from somewhere, and you can argue that you manage everything about your product in one place. Then integrated systems exchange the necessary data into respectable systems.

In one of the following chapters, we will be talking about the job-flow, which will continue some of the discussions raised here. STAY TUNED.

Add/View comments for this article →
0 Comments
user